Re: pkg-gnome SVN layout
On Wed, Mar 14, 2007, Josselin Mouette wrote:
> > I see two reasons to have a trunk:
> > - we currently have no defined merge process, so we commit some changes
> > in unstable and other changes in experimental; we then have to guess
> > how to merge the branches together: merge from unstable to
> > experimental, or the other way around, or both ways... This is
> > suboptimal and risky.
> We'll still have to merge things from the trunk to the other branches.
> What exactly would it bring?
Not only would it be clear in which way you have to do the merge -- and
hence more scriptable -- but also the responsability of the merge would
IMO be clearer. Of course, as Sjoerd reminded us, we should document
the process better, but currently we all commit stuff in whatever
branch we're doing an upload, but we do not always merge to the other
branches. In the case of a trunk, it would be clear that each
packaging change which is not specific to a dist should be made or
merged in trunk, and dist specific changes would only be done in the
dist branch, not in trunk. It makes it clearer which changes are
specific to a dist or not, and it encourages making this distinction at
the time the change is made ... instead of scratching one's head at the
time of the merge.
> > - we have no place to prepare the latest upstream development releases,
> > experimental only allows for one more GNOME series which is
> > currently GNOME 2.16
> This, I disagree with. We have experimental for that purpose. We should
> not make the current situation (experimental as a staging area for
> already stable upstream packages) the norm.
Unfortunately, with our current release strategy, there will always be
a problem between a 6 months upstream version freeze in Debian and a 6
months release cycle upstream.
Also, we have no place to prepare packages of development versions
which we do not want to publish to everybody. I think we need a place
to prepare the latest available tarballs -- and perhaps upload these to
a private archive, such as on alioth -- to be ready to do massive
uploads of a new GNOME release. This can also serve to confirm a bug
has been fixed upstream or to test development releases of GNOME before
uploading them to an official archive (even if it's experimental).
> I agree it would be nice to have, but without some automation it won't
> be as helpful. We already often forget to commit what we upload or to
> upload what we commit. If there is one more step, we're likely to forget
> it even more often, or, like it happened when branching for the last
> stable, to tag the wrong version.
svn-buildpackage supposedly has such support; I'm not too happy with it
(#414564), but once fixed it should be good enough.
> Layout (3) is more elegant, but I agree that for everyday use layout (1)
> is the simplest.
What do you think of layout 2 which is somewhat between 1 and 3 in
terms of hashing? It's sjoerd's and my preferred one, and close to the
current one (the name are a bit more explicit in my example than in the
current repository, with official = admin + bindings + desktop +
devtools + platform). Especially the concept of "extra" is used in
a lot of teams.
--
Loïc Minier <lool@dooz.org>
Reply to: