Quoting Svante Signell (2013-01-12 13:59:02) > On Fri, 2013-01-11 at 16:05 +0100, Stefano Zacchiroli wrote: > > [ dropping -www, setting Mail-Followup-To: cut-team ] > > > > On Thu, Jan 10, 2013 at 04:06:00PM -0500, Michael Gilbert wrote: > > > On Sat, Jan 5, 2013 at 12:36 AM, Thomas Goirand wrote: > > > > On 01/05/2013 01:28 AM, alberto fuentes wrote: > > > >> The few people on the list seems happy with it. If this is > > > >> working well, it needs a little more love on debian.org and a > > > >> 'testing-cut' link in the repos pointing to latest cut, so it > > > >> can be set on sources.list and forgotten > > > > > > > > Yes, we need to advertize more about CUT. CC-ing > > > > debian-www@lists.d.o in the hope the www team can link to CUT > > > > install instructions from our home page. > > > > > > I probably should have already sent a message a while ago on this, > > > but yes the monthly snapshots have been put on hiatus during the > > > freeze. The official d-i betas and release candidates are > > > recommended now so that they get sufficient testing and feedback > > > before the release. > > > > Doesn't this diminish significantly the advantages of CUT? Back in > > the days of the CUT discussion, one of the main "issues" associated > > to testing is that it stops rolling during freezes. > > As unstable does! As a user of testing and unstable I think it is very > unfortunate that packages in unstable practically stop rolling and no > new (or bug-fixed, except RC) packages are uploaded. Only backported > packages fixing the RC bugs in unstable are updated to get them into > testing (and eventually stable). Of course the maintainers should > concentrate on the release, but I assume very many of them are idling > until the next stable is released. Some are forced to stop by the > freeze. Additionally, not everybody is able to solve all kinds of RC > bugs. > > Is there a way to solve this problem? For example, when the freeze > happens, packages in unstable are marked as presumptive packages in > the new stable release. Then these packages are branched off to > something that could be called pre-testing or whatever, and sid goes > on as before the freeze. > > Unfortunately experimental does not solve this issue, I think it could > remain as a staging area for packages that can break things if they > were uploaded to unstable directly. Ignoring that issue of "maintainers should concentrate on the release" for a moment, the purpose of "unstable" really is "packages considered stable enough to potentially be part of next stable release", and "testing" is "packages proven stable enough interacting with each other for at least 10 days". Reason unstable slows down suring freeze is that otherwise above logic would change during freeze: There would not be the normal transition period of 10 days only among packages all of them targeted next stable release, followed by a staging area of only packages that have all had that initial 10 days. I recommend instead of redefining logic of unstable, branch off new suites with new logic. ...and then back to that issue of "maintainers should concentrate on the release" again: I do sincerely worry that additional suites _will_ affect how many of us developers will concentrate on getting the release out. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature