On Sun, 17 Jan 2016 10:21:15 +0100 Marc Haber <mh+debian-devel@zugschlus.de> wrote: > On Sun, 17 Jan 2016 08:39:02 +0000, Neil Williams > <codehelp@debian.org> wrote: > >On Sun, 17 Jan 2016 09:07:56 +0100 > >Marc Haber <mh+debian-devel@zugschlus.de> wrote: > > > >> On Sun, 17 Jan 2016 00:20:33 +0100, Michael Biebl > >> <biebl@debian.org> wrote: > >> >Amen. I'm much happier how the last couple of releases were > >> >handled. The release team(s) did an outstanding job. > >> >And things like autoremovals are a god send. > >> > >> I am not opposed to autoremovals. I am opposed to removing packages > >> and not letting them back in after the bugs were fixed just > >> because we can. We have never done this, and we shold not do that > >> for stretch. > > > >That is just an untruth, sorry. > > > >At some point before the end of every freeze for every release, we > >have *always* done this. It is inevitable. It may be (and preferably > >will be) a short period at the very end of the freeze. > > Of course. What I have understood is that this will be general freeze > policy from the beginning for stretch. I might have misunderstood in > the talk, and I didn't find a general freeze policy document to read > up on this yet. Then the only reasonable basis is to use the past freeze policies, as linked by Tollef, as the reference for the talk. I fail to see why there is so much fuss over this, there will always be a time when autoremovals are not let back in and that time has proven to be fairly consistent in length over previous releases. It allows the release team to sort out the more complex issues, it allows time for DI to finalise and a raft of other essential tasks. If the total freeze period is shortened, as so many people want, the proportion of time taken up by this portion of the freeze process is likely to increase. So, therefore, it is right to remind people that a short freeze means that it is *more* likely that any one specific package is going to be affected by a removal which cannot be undone. A shorter timeframe for the release as a whole means that the ban on packages returning, RC bug fixes or not, becomes more noticeable and needs to be applied more overtly than before. The earlier that starts, the shorter the release process can become (although there is an element of diminishing returns as the release itself takes a finite amount of time and the archive keeps getting larger). Once upon a time, this removal process was manual and only done at the "soft" start of the freeze but it still continued after the point where returns were possible. We're permanently in that "soft" freeze by using automated removals, so the real freeze (where removed packages are unable to return) looks more severe. This "soft" freeze then isn't part of the freeze policy for stretch, it's already in place. The freeze itself becomes a period of time when automatic returns are initially slowed (only packages already in the queue), then restricted to RC fixes only (where most of the freeze time gets used up), then banned. Manual migrations to return removed packages stop at some point too. At another point, automated removals stop but manual removals continue - possibly right up until the very final steps of the release. Hence, removals (manual and automatic) will happen when there is no prospect of return. All the talk was doing was highlighting that this process will continue but will appear more prominently in a shorter total freeze. It may also affect more packages as the archive continues to grow. That is just mathematics, it is inevitable. We still release "when it's ready" but due to the size of the archive, there must be a threshold where the release team can decide that x percent of the archive being ready is enough, so that the release is not held hostage to particular packages. The value of x hasn't been 100 for a long time. Reality means that volunteers need to allocate time to do the release tasks, so a date needs to be set when people are available but the date isn't set until after the release team decide that the threshold has been met. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpeaUCzeFhBG.pgp
Description: OpenPGP digital signature