[Pkg-osg-devel] Project pkg-osg approved in Alioth

[Manuel A. Fernandez Montecelo]

Copyint this to the list...

On Thursday 30 December 2010 10:07:06 Alberto Luaces wrote:
> "Manuel A. Fernandez Montecelo" writes:
> > On Wednesday 29 December 2010 20:34:00 Alberto Luaces wrote:
> >> "Manuel A. Fernandez Montecelo" writes:
> >> > On Wednesday 29 December 2010 10:40:10 Alberto Luaces wrote:
> >> >> >> My vote goes for Git and slightly behind SVN, just because of
> >> >> >> familiarity, but I can easily accomodate to your preferences.
> >> >> > 
> >> >> > I vote for git and I'm strongly against SVN.
> >> >> 
> >> >> So git is the winner :)
> >> > 
> >> > I didn't recall that mercurial is the VCS used by OSG team. 
> >> > Basically I'm open to any suggestion except CVS, and tend to ignore
> >> > the ones that I don't know (like darcs or bazaar).  I worked a bit
> >> > with mercurial, if only a bit, but I don't think that I need a
> >> > superb knowledge of it to do a few commits and a couple of pushes.
> >> > 
> >> > So if it's good for some reason, such as synchronizing with
> >> > upstream, it's also a good reason to use it.
> >> 
> >> Indeed, OSG uses Subversion. Some discussion has taken place into the
> >> mailing list about that, but I think the fragile status of the servers
> >> they use made the idea lose speed.
> > 
> > Subversion?  I though that you told Mercurial for ease of syncing, so
> > we would update from their repositories maintaining the individual
> > commits and so on.
> > 
> > Or do you mean from some kind of repository for our debian/ dir that
> > you are already using?  I'm not aware of that, in fact I think that it
> > was me that created the last revision of it, and used previous
> > revision's .deb for that, not any repository.  (My bad?).
> 
> Sorry for being so terse. I thought you new about the Mercurial
> repository that Loic has set up for tracking the changes of debian/
> 
> http://2-8.openscenegraph.dachary.org/
> 
> Even you didn't use it, Loic was adding all the changes in the
> background :) The good part of using it, among other advantages, is that
> you can have every change that you make independent from the others, no
> matter the revision they are related to. I did that in my last
> submission, so for example, you can revert the Introspection patch
> easily in one changeset.
> 
> >> I thought we were talking about our repository, the one tracking the
> >> debian/ directory. For synching with upstream, I think we can just
> >> copy their files into our VCS or directly from the SVN tags with
> >> every upstream release.
> > 
> > Yes, we were talking about this one -- but apart from our debian/ dir,
> > it can contain the source too, instead of using a .zip for it.  Which
> > I don't know if it's a good idea, but that's what I understood and
> > what I was talking about.
> > 
> > I know that some people use {svn,git,others?}-buildpackage tools to
> > somehow put source and debian/ together in a repository, tracking
> > upstream and make the package from there, supposedly in a simpler or
> > better way.  So maybe that's why I was confused about the motivation
> > to have Mercurial -- again, I thought that it was because OSG folks
> > using it.
> 
> My motivation was the synchronization between our current Mercurial
> repository and the one in Alioth :) But this is also feasible with git.
> 
> So, to make it clear:
> 
> * We agreed on git for hosting our repository for debian/, porting all
>   the history from http://2-8.openscenegraph.dachary.org/ to Alioth.
> 
> * We have to decide how to do the synchronization with upstream's SVN:
>   copying just the files to our git repository, copying the .zip
>   releases, or using git-svn?

All right, we're set on Git then, I'm going to activate it right now.

About the synchronization with upstream, OSG is not the linux kernel or 
glibc -- I don't think that we'll worry about porting patches back and forth 
between releases, in general.  I think that we will simply use a given 
upstream version, be it stable or development; and only a selected few 
patches will be added on top.  That's why I think that tracking all upstream 
changes is unnecessary, and we can do either copying the .zip or file-by-
file, but not having to preserve upstream's history.

If we need finer-grained control later, we can do it, but I don't think that 
we need so much detail now.  But if you think otherwise, no problem for me.

Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>