On Mon, 2012-02-13 at 16:54 -0200, Ricardo Fabbri wrote:
> I would suggest having the separate Python binding repository hosted
> in the same VXL's sourceforge account. Multiple Git repositories can
> be set there. That way the two projects can maximize each other's
Yes, I agree. It makes sense for each of these repositories to be
co-located as part of the same sourceforge project.
> I am very much in favor of the move to Git and have pushed for it in
> the past. I currently use it with VXL SVN the same way Matt does:
> Moving to Git has the drawback that most users would have to download
> the entire history with a simple "git clone". For a project this big,
> a "git clone --bare" is an important thing to stress for casual users,
> otherwise the download may take too long. Of course, for developers it
> is a huge benefit to have the history locally accessible.
I think "git clone --bare" will still pull the entire history, but it
will not make a local working source tree. Maybe you are thinking of
"git clone --depth n" that will only checkout the last n commits.
Anyway, my current git clone of VXL is 112Mb. That's big, but not too
unreasonable for a one-time download. It's much worse when you run
git-svn yourself and git has to checkout every commit of VXL via the svn
interface. That can take all day. Once you built the initial git
history, standard git cloning isn't too much of a problem. We have a
git-svn clone of VXL on our internal network that keeps itself
synchronized to the upstream VXL. Then we can interact with it as if it
was a native git repository until we need to push change back upstream.
> I can also help occasionally with the Python move, if needed.
Thanks for the offer.
> On Mon, Feb 13, 2012 at 4:28 PM, Matt Leotta <matt.leotta@...> wrote:
> > Brendan,
> > I would also be in favor of splitting contrib off into a separate
> > repository, or even one repository per contributor. This would make
> > release management much easier. The official release would only contain
> > VXL core libraries. Each contributor would then have the responsibility
> > of making releases of their own contrib sections, if they care about
> > releases. The Python bindings could be another add-on repository.
> > At Kitware we would handle this setup with what we call "superbuilds".
> > A superbuild is a repository that refers to specific commits of various
> > other repositories. So you could checkout and build the various
> > projects separately if you want, but you can also checkout the
> > superbuild and it will checkout all the repositories you need and build
> > everything in one massive build. This allows for smaller sub-projects
> > that are easier to manage, but also makes it easy to do a single unified
> > build of everything if that is what you want.
> > I'm not sure if this can be done effectively with subversion, but it
> > works well with git using the git submodule feature. At Kitware we have
> > migrated all of our code repositories from svn and cvs to git. In fact
> > we do all our VXL work in git and push changes back upstream via the
> > git-svn interface. Git has a bit of a learning curve, but is so much
> > more powerful than svn or cvs that once you learn it is very hard to go
> > back.
> > What is the VXL community's feeling on moving to git? If a good portion
> > of developers are already familiar with git then it maybe it would make
> > sense to switch. I can see the possibility of Kitware migrating VXL to
> > git, splitting it into separate repositories, setting up the superbuild,
> > and then taking responsibility for making the stable releases of VXL
> > core. I can't promise anything right now because I have to check that
> > we can find funding to do this. However, we certainly have the
> > technical experience to do this migration if the community is in favor
> > of it.
> > Moving from svn to git is about more than the submodule feature. It's a
> > fundamental shift from centralized version control to distributed
> > version control. It requires a totally different mindset on version
> > control. I expect there will need to be a lot of debate about whether
> > or not to migrate to git and also what the work flow would be if we
> > adopted git. git supports various different development work flows, the
> > simplest of which is the linear, single-branch of history used by cvs
> > and svn. There are other work flows that are better suited toward
> > managing stable releases.
> > --Matt
> > On Mon, 2012-02-13 at 20:26 +1300, Brendan McCane wrote:
> >> Hi Matt,
> >> I am very much in support of this move. I can see benefits and
> >> draw-backs to both option 1 and 2 below. I have a slight preference for
> >> option 2, but in that case, I would prefer all of contrib to be split
> >> off into a separate project. This has the advantage of making official
> >> releases rather easier since core does not change often (but that's my
> >> bias showing both as the release guy and someone who has used very
> >> little of contrib).
> >> Either way, I'm strongly in favour of python bindings for vxl. I might
> >> be able to help a bit, but probably shouldn't be relied upon for any
> >> heavy lifting.
> >> On Thu, 2012-02-09 at 15:26 -0500, Matt Leotta wrote:
> >> > VXL users and maintainers,
> >> >
> >> > At Kitware we've toying with the idea of creating Python bindings for
> >> > VXL. The main goal would be to allow the use of VXL's core classes and
> >> > functions from Python. We also want to integrate vnl and vil tightly
> >> > with NumPy. OpenCV and many other C++ libraries have similar
> >> > functionality. We've done some proof of concept test and found that,
> >> > for example, we can wrap a vil_image_view as a NumPy array and
> >> > manipulate the underlying memory without deep copying. The reverse is
> >> > also possible.
> >> >
> >> > Before we invest much more effort into this I'd like to gauge developers
> >> > interest and acceptance of this idea. I suspect the interest from VXL
> >> > users would be high, but I'm less confident such bindings could actually
> >> > be committed back to the VXL repository without updating our policies.
> >> > We would be using Boost.Python to create the bindings since this is far
> >> > easier than manually doing it with Python's C interface. In addition to
> >> > Boost this would require linking to Python and NumPy libraries. I would
> >> > not want to have to put any of these in v3p. The code for these binding
> >> > would also make heavy use of modern C++ features, like namespaces, that
> >> > are generally frowned upon in VXL.
> >> >
> >> > I see this as an optional component to VXL, so either:
> >> >
> >> > 1) This code is contributed to the VXL repository, but lives in a
> >> > separate subdirectory, and is disabled in CMake by default. Building
> >> > Python bindings would require the user to provide Python, Boost.Python,
> >> > and NumPy.
> >> >
> >> > 2) The code is a separate project that depends on VXL and has its own
> >> > version control repository. It would probably use a newer version of
> >> > CMake, use "newer" C++ features (C++03, not C++11), and be maintained
> >> > separately.
> >> >
> >> > Either way, we would probably set up the framework and wrap just some
> >> > key classes and functions at first. Initial focus would be on vil and
> >> > vnl, secondary focus on vgl and vpgl. We would probably not go much
> >> > beyond that and allow the community to contribute additional bindings as
> >> > needed. There is no need to wrap some libraries like vpl and vul since
> >> > Python already has these capabilities.
> >> >
> >> > Does anyone have any opinions on this matter? Is anyone interested in
> >> > helping if we can get the ball rolling?
> >> >
> >> > Thanks,
> >> > Matt
> >> >
> >> >
> >> > ------------------------------------------------------------------------------
> >> > Virtualization & Cloud Management Using Capacity Planning
> >> > Cloud computing makes use of virtualization - but cloud computing
> >> > also focuses on allowing computing to be delivered as a service.
> >> > http://www.accelacomm.com/jaw/sfnl/114/51521223/
> >> > _______________________________________________
> >> > Vxl-maintainers mailing list
> >> > Vxl-maintainers@...
> >> > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
> > ------------------------------------------------------------------------------
> > Try before you buy = See our experts in action!
> > The most comprehensive online learning library for Microsoft developers
> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> > Metro Style Apps, more. Free future releases when you subscribe now!
> > http://p.sf.net/sfu/learndevnow-dev2
> > _______________________________________________
> > Vxl-maintainers mailing list
> > Vxl-maintainers@...
> > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers