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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
