Re: svn management, git, etc
David 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.
For my part, I don't have a really strong preference for one system
over the other. I asked about git in a previous email just to hear what
others think. It makes a degree of sense to follow upstream in using
git, but we shouldn't feel obliged to have to do so. But I'm
comfortable with it if we do switch. By the way, I asked X.org why
they preferred git, and they pointed to the arguments at
http://lists.freedesktop.org/archives/xorg/2006-February/013113.html
>
> As such, we need to make some decisions on certain things:
>
> 1) Do we keep using the vendor branches? Are they worthwhile given that we
> keep all important patches in quilt? My sense is no, they're not,
> provided that we continue to use quilt this way.
Personally I don't truly understand what the vendor branch is for,
maybe I'm too new to the XSF to appreciate it? Is it a back-up measure
in case a holocaust strikes and all upstream copies of the original
source are completely lost? The only argument I've heard refers to the
autobuild system, I'll comment on that at point 2.
Like you, I tend to feel keeping explicitly separate patches makes for
a cleaner solution when dealing with upstream source the size of
X.org. Otherwise you've got to rabbit through the entire debian
diff.gz file to try to find what we changed from the upstream source.
Keeping separate patches makes it simpler to push particular fixes
upstream, I think.
That said, it does seem reasonable to me to keep a single copy of the
upstream tarball (i.e. orig.tar.gz) in our repository. And my comments
here are perhaps not quite so useful in the case where we wrap our own
orig.tar.gz tarball from the latest upstream git sources.
> 2) Do we keep putting the upstream tree in our svn repo? My sense is that
> we should continue to do so. The reason being that we regularly are
> patching the auto* build system from upstream. Keeping those generated
> files in-tree ensures that we have the same build system from machine to
> machine. This is a hideously fragile system as it is, and keeping things
> in-tree seems to provide some resiliancy. If someone has a good
> mechanism to get around this, I'm all ears, because it is a pain to keep
> it all in-tree.
I presume you mean here the upstream source in the working branch
copy? Don't patches apply well enough to the autobuild files as much
as the source files? I think I'd be comfortable keeping upstream
source in branches, but I suppose it's "cleaner" to extract upstream
source directly from the tarballs to ensure no patching is missed. Is
there any reason why any build-system changes can't be handled by
patches like any other change?
> 3) Do we need to keep using quilt? Branden's original plan was to keep the
> upstream source in-tree and not use dpatch or quilt or anything like it.
> This is an option, but if we go this route we need to keep using the
> vendor branch. I'm inclined towards quilt myself, as its proven and it
> works. On the other hand, we're carrying around quite a bit of code to
> make sure quilt works for us. My plan is to switch our system over to
> what's built-in to the quilt package to make the less of our problem,
> but some people still prefer to keep it all in the repository.
I feel like I'm starting to repeat myself now :) I like patching
because it declares explicitly what Debian has changed from upstream.
It lets us keep those changes in discrete units so we know what each
individual one is for. I'm inclined to think that makes it easier for
pushing the patches upstream.
In fact that was why I had chosen to use dbs for xprint - dbs keeps the
upstream source explicitly in its original pristine tarball which is
only unpacked at build time. Patches to that upstream source are
created separately and explicitly.
> 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.
Likewise, I don't really mind what we do, so long as the consensus is
documented so that we know what we're doing!
Drew
Reply to: