On Tue, Dec 19, 2006 at 02:32:48PM +0100, Thierry Reding wrote:
> First of all is the question of the repository layout. What was clear from
> the start is that we'd like to mirror the directory structure from upstream.
> The second issue is what to do with the upstream sources. So far the
> alternatives we've been discussing are 1) having selected upstream branches
> cloned into our repositories and 2) leaving it up to the packager to use
> upstream branches in their local clones of the Debian repositories. Does any
> of these alternatives have a significant advantage over the other? Is there
> perhaps a different approach that would work even better?
To me, the most important thing is consistency. Having to do two or three
different things depending on the packager is just going to be an
irritating barrier to getting anything done, especially if we want to
attract new people. From my experience, we definitely want to keep
attracting people.
Also, I'm in favor of option 1 myself. Given the toolset, it seems to be
the easiest option and the one with the least surprise. There's several
advantages to it that I see:
1) Anyone who clones our repository will get the whole source code, making
it easier to see what's going on. It also makes it easier to do work on
the package right away. Encouraging people who aren't normally involved
to get involved, if for nothing else than to submit a single patch, is
something we should place as a high priority. It also has the side
benefit of helping ensure that we all have the same repositories.
2) It allows us to easily cherry-pick from upstream. If we don't keep the
source tree in the repo, we have to apply all changes using quilt the
way we do now. This is extra hassle, and it's kind of silly given that
we don't need to keep these patches separate from the mainline codebase
across upstream revisions, which really is the primary benefit from
using quilt.
Now for the other option, keeping just the debian directory in the repo by
default. The advantages that I see for this are
1) Less to download for the user who just wants to look at the packaging.
Honestly though, I see this as a very small gain because most people
will probably be interested in the code. The alioth guys don't have a
problem with us keeping the whole repo there, so server space isn't an
issue. And as keithp likes to harp on, disk space is cheap :-)
2) Fairly simple integration in to existing git repos. This is similar to
the first, in that x.org developers who already have upstream git
checkouts need only add our repo to their remotes and check out the
minimum necessary to build the debian package. Then they can do
whatever customization they like. Again, this is a minimal gain,
and can be potentially harmful since we aren't ensuring that that
person has what the packaging claims by default.
I was actually pretty well in favor of this option originally, but after
exploring the actual mechanics of how it would work, I think importing the
source in to our repo is a good idea. git-buildpackage requires you to
import the source in to the repo anyway (git-import-orig does this) and
then merges it to master to build, so our scripting requires the source to
be in the tree anyhow. My feeling is that we should just do this once and
keep it in the repo so everyone building the package doesn't have to repeat
the work.
- David Nusinow
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
