Re: Rolling master branch

["Carlos O'Donell" <carlos at redhat dot com>]

On 09/30/2014 12:52 AM, Siddhesh Poyarekar wrote:
> On Mon, Sep 29, 2014 at 01:23:50PM -0400, Carlos O'Donell wrote:
>> We already have something like this but not fully formalized, the
>> list of blocker issues is the list of things we need to fix.
> 
> It's not the same thing.  Identifying blockers is one thing and
> setting thresholds on the number of P1/P2/P3 bugs that remain open is
> another thing.  The latter is aimed at chanelling developer efforts
> towards reducing the bug backlog.
> 
>> Perhaps Allan's comments are more on-point here, particularly coming
>> up with a strict definition of blocker would help.
>>
>> Blocker:
>> - ABI defects that would cause an application compiled with
>>   a previous version of glibc to fail to run with the new version.
>> - API defects that would cause an application to fail to compile
>>   with the new version of glibc.
> 
> Unfortunately, both ideas have somewhat contradictory goals.  The
> blockers approach aims at reducing time to release, while the bug
> threshold idea that gcc folks have aim to improve the quality of the
> release.  We can do both, but we just need to figure out how to set up
> our timelines for it.

I don't think we can or should follow gcc's model. Why? I don't think
we have enough "carrot" on the "stick." The idea in gcc's model is to
force developers into fixing bugs (the stick) in order to get trunk
open faster for more development work (the carrot).

In glibc the community has been dysfunctional for so long that the
carrot is gone, and downstream accepted a long time ago that they would
have to carry lots and lots of custom glibc patches. It became the new
normal to have a heavily patched glibc. So if we block master from
reopening until all P1 bugs are fixed, people will, IMO, just patch
locally and ignore upstream.

Thus I think the other way around, frequent, fast, on-time, releases
makes downstream trust us more. On top of that we need to send all of
our fixes upstream first and keep the value in staying in sync with
upstream. If we do this for long enough the carrot grows back, and then
we might change the model.

The present problem is that we're trying to do too much per release
and we should instead make the blocker definition very strick and very
narrow, and keep releasing frequently and on time.

$0.02.

Notice this is less technical and more psychological than we usually
talk on libc-alpha :-)

Cheers,
Carlos.