Re: svn management, git, etc
Ok, I think it's time to take stock of it all and lay down some policy:
On Sat, Aug 05, 2006 at 06:12:19PM +0000, David Nusinow wrote:
> Hi everyone,
>
> So we need to talk about how we manage the svn archive and plans for the
> future. Given upstream's move, I think it's pretty apparent that if we are
> going to change our repository, it's going to be to git. Since a number of
> people are clamoring for that, I think it's a safe bet that it needs to
> happen. The problem is that we almost completely lack experience with git.
> Andres has some experience with it, although I'm not sure he knows about
> certain details like repository conversion, and how our repo would convert
> over to a git repo. We may need to solicit Keith for advice on this, since
> he's got a lot of experience. Either way, I'm 100% unwilling to do any sort
> of switch until after we're frozen for etch, and even then there are issues
> like where to host it that need to be solved.
As per http://lists.debian.org/debian-devel/2006/08/msg00599.html we now
can use git.debian.org to hook in to alioth and do our work. We don't have
any projects set up yet, and I'm not sure exactly how this will go down,
but the biggest barrier outside of our own knowledge has fallen. If people
are really chomping at the bit, I'm willing to start putting something like
the apps in to git so we can get started learning it. The apps may prove to
be a big challenge though, since we're bundling them.
> As such, we need to make some decisions on certain things:
>
> 1) Do we keep using the vendor branches?
Since no one spoke up in favor of vendor branches, vendor is essentially
dead now. Commit directly to the branch of interest.
> 2) Do we keep putting the upstream tree in our svn repo?>
While I'd love to have automated tools and such to make it easy to keep the
upstream tree out of the repo, svn-buildpackage doesn't work with our
current setup as far as I can see. Rather than worry about adapting to it,
or adapting it to our needs, I'd rather just push ahead and get moving
towards git. Once we're there and more experienced with it, let's
re-evaluate.
> 3) Do we need to keep using quilt?
The answer to this seems to be an unequivocal yes. We'll have to
re-evaluate when we move to git. stgit may prove to be a good replacement
for quilt, since we'll definitely want to keep a stack of patches that we
don't push upstream, for example to handle non-free bits of drivers.
However, I don't know how good git will be at managing this on its own. The
quilt stuff we've got is proven and workable and it seems to make many of
us very happy, so we can keep using it for now.
Other things I'd like to implement in the future, given people's comments,
are:
1) Naming branches based on either a feature being implemented (such as
autodetection) or else based on Debian archive. Using upstream katamari
release numbers seems to be a pretty good policy for things like the
xorg package, but it just gets confusing for our branches. We'll name
them "experimental" and such instead. trunk should stay as trunk
though, corresponding to whatever is in unstable.
2) Whittle away at xsfbs. This involves pushing the quilt stuff to the
quilt package, and whatever else we can come up with, maybe even
dh_xdriver or something.
3) Write or support git-buildpackage. Not only would this prevent me from
risking carpal tunnel every time upstream rolls a new katamari, but it
would allow us to only keep the debian packaging in our repo if we so
choose. I think that git provides benefits to keeping the tree in-repo
though, since we can just pull from upstream directly, but this will
still prove to be a valuable tool.
4) Set up a second list, probably on lists.debian.net that pasc announced
a little while ago, for repository commit mails. We're all probably
filtering them with procmail anyway, so moving them out of the way to
make it easier for people browsing the list that aren't subscribed is
probably wise. We may also want to stop providing diffs for the
changes. I use them constantly, but it's a lot of mail and they can be
really annoying at times.
> Please reply and let me know what you want and why you want it that way.
> Again, I don't care so much about the details provided that we are working
> in the best way possible. If what we're doing now isn't working for people,
> then we need to find a solution.
Thanks to everyone who replied. If anyone wants to take the lead on any of
these, please feel free to do so. If not, I'll get on it when I'm content
with our status for the release.
- David Nusinow
Reply to: