This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Rolling master branch

On 09/30/2014 11:33 AM, Siddhesh Poyarekar wrote:
> On Tue, Sep 30, 2014 at 10:28:43AM -0400, Carlos O'Donell wrote:
>> 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.
> This really needs to change.  I'd like to think that we're a very
> receptive community now and downstream hasn't had this excuse now for
> a couple of years at least.  I guess we are seeing some changes with
> people from other projects slowly starting to contact us instead of
> just hacking in workarounds, so hopefully in another year or so this
> won't be a problem.

I'm crossing my fingers, but think it will be another couple of years
before we are fully understood to be functioning. The more people give
public presentations the better :-)

>> 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.
> Fair enough, I wasn't hoping for things to change right away anyway.
> It was just something I thought of and figured it might be useful to
> get other people's opinions.

It is *always* good to talk about issues like this. Every time we talk
about it we refine our opinions and thoughts on how to handle this.

>> Notice this is less technical and more psychological than we usually
>> talk on libc-alpha :-)
> I found it useful so I hope some others did too.  Now let's talk about
> getting rid of ChangeLogs ;)

Sorry, I did not mean to imply that the conversation was inappropriate
for libc-alpha, only that it is a non-technical issue, and therefore
even more complex than normal.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]