Re: svn layout confusion
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.
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.
> 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.
>
> 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..
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.
>
> 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.
Reply to: