Re: glibc release process

["Andreas K. Huettel" <dilfridge@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2347 bytes --]

Hi Carlos, 

> >>> 3) Branch: 2 weeks before release
> >>> Master is opened for development
> >>> Release branch only accepts obvious and simple bugfixes and/or fixes for
> >>> issues found during machine testing
> >>
> >> This seems to contradict implementing fixes that are issues for slower 
> >> targets?
> > 
> > Maybe I expressed myself wrong here. The main idea is, let's keep the
> > release branch running for two more weeks under bugfix only rules.
> > We have a chance to still address problems that are found during additional
> > machine testing.
> > 
> > [One could even think of cutting x.y_rc tarballs at this time
> > to promote further testing.]
> 
> I do not agree with (3) because it doesn't support objective A.
> 
> I think we can branch *any time* we want if testing is complete for the long
> running arches.

When is "testing complete"?

It's not as if we are working against a well-defined list of configurations
here. We can't really say, here's a 100-item list of supported hardware, supported
compiler flags, and supported configuration option combinations, we go through this
list with autobuilders and regression tests and if nothing pops up we're good.

I'm trying to address the issues that fall outside such a grid and can't be caught
by brute-force (i.e. throwing money and CI at it).

> 
> Lets try it out.
> 
> Lets do 2 weeks of extra freeze time, but focus on getting all machine results
> and see if we can cut and release EARLY. :-)
> 

We have this semi-strict rule in Gentoo that a package version can't enter "Gentoo
stable" unless it's been around without significant changes for 4 weeks. One point
of it is that no amount of automated testing will catch all bugs in all combinations,
but our hordes of happy-go-lucky experimenting users using "Gentoo testing" will very
likely stumble on some of them. Just waiting helps to make sure we're good.

This is why I'm against the speed focus.

And even if we re-open master for development, the release branch and the master code
will most likely be tried and tested by different people (distributions and packagers on
one side, glibc developers on the other).

Cheers,
Andreas

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]