This is the mail archive of the
mailing list for the glibc project.
Re: Rolling master branch
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 30 Sep 2014 12:09:14 -0400
- Subject: Re: Rolling master branch
- Authentication-results: sourceware.org; auth=none
- References: <20140929082252 dot GB2217 at spoyarek dot pnq dot redhat dot com> <54295333 dot 8040205 at redhat dot com> <CAAHN_R3ki6T08PVXOOUr3TEDAusBKiCf_O_Si1ZEp+HjvBsWug at mail dot gmail dot com> <542995A6 dot 8010807 at redhat dot com> <20140930045208 dot GC2217 at spoyarek dot pnq dot redhat dot com> <542ABE1B dot 408 at redhat dot com> <20140930153301 dot GF2217 at spoyarek dot pnq dot redhat dot com>
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.