This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] powerpc: New feature - HWCAP/HWCAP2 bits in the TCB
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: munroesj at linux dot vnet dot ibm dot com, Rich Felker <dalias at libc dot org>, Roland McGrath <roland at hack dot frob dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, Carlos Eduardo Seo <cseo at linux dot vnet dot ibm dot com>, David Edelsohn <dje dot gcc at gmail dot com>
- Date: Fri, 03 Jul 2015 01:08:18 -0400
- Subject: Re: [PATCH] powerpc: New feature - HWCAP/HWCAP2 bits in the TCB
- Authentication-results: sourceware.org; auth=none
- References: <55760314 dot 6070601 at linux dot vnet dot ibm dot com> <20150609163835 dot GI17573 at brightrain dot aerifal dot cx> <1435777940 dot 7125 dot 132 dot camel at oc7878010663> <5595FFC1 dot 1050508 at redhat dot com>
On 07/02/2015 11:21 PM, Carlos O'Donell wrote:
> On 07/01/2015 03:12 PM, Steven Munroe wrote:
>> This discussion has metastasizes into so many side discussions, meta
>> discussion, personal opinions etc that i would like to start over at the
>> point where we where still discussing how to implement something
>> reasonable.
>
> I want to make few higher level comments as an FSF steward for the glibc project.
>
> * IBM has consistently provided hardware and developer resources to maintain
> POWER for glibc. IBM is the POWER maintainer, and the ultimate responsibility
> for the machine rests with IBM. Today that responsibility is with Steven Munroe
> (IBM) who is the POWER maintainer for glibc. The machine maintainership provides
> Steven with a veto for machine-specific features, ABIs and APIs, much like all
> the other machine port maintainers. Steven is expected to use this veto to
> further the goals of the glibc project, and serve the needs of POWER users, and
> balance the two.
>
> * Consensus need not be agreement, it may be that we discuss the options, find
> no sustained opposition, and move forward with a solution. People can disagree
> bitterly and we can still have consensus. Developers can have strong and polarizing
> opinions about exactly how to use the limited resource of `thread-pointer + offset`
> accessible data, but at the end of the day consensus can be reached.
>
> * Healthy and active discussion, like the discussion on this particular topic,
> are good for the community. Topics surrounding optimizations are rife with
> complex tradeoffs, and require discussion, summaries, and a developer to
> champion a position of consensus. I see nothing wrong with this kind of behaviour.
> The discussions should stay on point, be technical, provide feedback, and
> indicate clearly if the comment amounts to sustained opposition.
Fixed TO: Joseph Myers.
Cheers,
Carlos.