[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: support for merged /usr in Debian

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

Attachment: pgpeaUCzeFhBG.pgp
Description: OpenPGP digital signature

Reply to: