Re: svn layout confusion
On Tue, Sep 06, 2005 at 10:06:45AM -0400, Andres Salomon wrote:
> On Tue, 2005-09-06 at 15:20 +0200, Sven Luther wrote:
> > On Tue, Sep 06, 2005 at 08:51:06AM -0400, Andres Salomon wrote:
> > > Ok, so now that we have dists/sid and dists/trunk (which is for development
> > > and experimental stuff); how is this actually supposed to work? I understand
> > > the scenario when we have 2.6.12 in sid and 2.6.13rc in trunk; stick
> > > any new development stuff in trunk, backport to sid if desired, do sid
> > > releases from dists/sid, and experimental releases from dists/trunk. What
> >
> > Indeed.
> >
> > > about the case where we have 2.6.13 in both? Are we supposed to do all
> > > releases from trunk, and branch/cp to sid? Are we supposed to do releases
> > > from sid, and keep trunk ready for 2.6.14 development; regularly
> > > forward-porting changelogs and stuff?
> >
> > The plan, as i see it, is that as soon as 2.6.12 is in etch, we are going to
> > upload 2.6.13 kernels anyway to sid, and continue to make 2.6.12 bug-fix
> > uploads to etch by t-p-u (if this is not still broken).
> >
>
> I wouldn't really consider 2.6.12 to be etch release-material until the
> packaging changes settle down; more of something for d-i and etch users
> to use while we finalize the packaging. I wouldn't want to see etch
> actually release w/ -6.
We don't care, 2.6.11 has to go, and 2.6.12 has to move to etch, this does not
mean that we will release it as is, but that this is what we want to release
when etch is ready. While 2.6.12 is not in etch, this means that all etch
d-i installs are broken, and 2.6.8 or whatever cannot go.
> But yes, your explanation makes sense for 2.6.13 (assuming we want to
> release with it). Also, we'll probably be doing uploads to
> testing-security more often than t-p-u.
Hehe.
> > So, the natural thing to do then, is to svn mv dists/sid to /dists/etch at
> > that time, and svn cp dists/trunk as dists/sid.
>
> cp or mv? If we only cp, dists/trunk gets stale as we work on
> dists/sid, and would need to be manually synched.
My idea was that at a given time trunk would be the 2.6.13 release candidate,
and once we start uploading it to sid, then this one becomes the main work for
sid, and trunk is forked from there for future follow-2.6.14-rc-whatever
development, once 2.6.14 is released, hopefulyl 2.6.13 will have made it to
testing, and we can then do the above dance once more.
> > Then we make 2.6.13 releases in dists/sid, while 2.6.12 is slowly phased out,
> > and make brand-new-out-of-git 2.6.14-rc or whatever uploads to experimental
> > from dists/trunk.
>
> How often do we intend to do those? I don't like the idea of two
> possible development trees getting out of synch; if dists/sid only
> contains patch updates, that's fine. However, if dists/sid contains
> packaging updates (ie, fixes to gencontrol.py and such), then keeping
> dists/trunk in synch with that will become troublesome..
That is indeed a problem. We could manage the packaging fixes in a single
repo, and link to there from it, not sure if this is possible wih svn though.
Or maybe even copy it from there when building ?
The patches and configs are essentially what will need to be forked for the
different tree, and i guess that there is no chance for it to work for all
three dists anyway.
> It sounds to me like dists/trunk should be a branch of dists/sid,
> created whenever there's experimental packaging or patch work being
> done.
Indeed.
> > That said, i believe that the single linux-2.6 thingy is maybe not the best
> > idea after all, but maybe we can, if t-p-u is still broken, as it seems to be
> > as far as i remember, do linux-2.6.12 uploads out of dists/etch, in parallel
> > to linux-2.6 uploads (which will be 2.6.13) out of dists/sid.
> >
>
> Yea, the dists/etch thing makes sense.
Cool,
Friendly,
Sven Luther
Reply to: