Re: [Patches] What to do when a patch is ignored (Re: [PATCH] Make sys/timerfd.h usable without __USE_POSIX199309)

[Maxim Kuvyrkov <maxim@xxxxxxxxxxxxxxxx>]

On 3/11/2011, at 5:56 PM, Jonathan Nieder wrote:

> Hi glibc helpers and eglibc people,
> 
> Jonathan Nieder wrote:
> 
>> 	sys/timerfd.h:46:28: error: unknown type name ‘clockid_t’
>> 
>> I sent three patches, any one of which would address that.
>> 
>> - http://article.gmane.org/gmane.comp.lib.glibc.alpha/16687
>> - http://article.gmane.org/gmane.comp.lib.glibc.alpha/16806
>> - http://article.gmane.org/gmane.comp.lib.glibc.alpha/16828
> 
> Simple bug report, simple patch.  Ulrich Drepper doesn't seem to like
> it.  If there's no way to get this kind of thing in, then glibc will
> end up filled with papercuts and traps for the unwary and there will
> be no way for new contributors to get started.  Am I misunderstanding?
> 
> I believe Drepper et al have done some wonderful work, and honestly
> I'm surprised at the cold response this got.  It's certainly possible
> the patches are lousy (but how can anyone tell and learn from that?).
> I wish I knew to move forward.
> 
> Advice?

Grow a thicker skin :-).  Some open-source projects are more brutal than others and it takes perseverance to get your contributions included.  Sometimes maintainers and reviewers punt on changes that feel wrong to them.  In such cases it is often that both sides have good arguments in support of their position, and something needs to break the tie.  Project experience and general wisdom of a maintainer usually makes their gut more trustworthy than that of a new contributor, so sometimes the right thing to do is just to accept the "wisdom" and move on to the next problem.

That said, I disagree with Ulrich's all-or-nothing approach to this specific problem.  Fixing just one header is better than fixing none; so I'm supportive of your either 2nd or 3rd patch.  Fixing one header now would make a positive precedent to incrementally fix the overall problem, instead of making a negative precedent of declining this and all future increment fixes to other affected headers.  So next time someone submits a patch for a similar problem in another header, we could point at this discussion and tell that someone to make the patch consistent with the approach we select here.

Thank you,

--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics


_______________________________________________
Patches mailing list
Patches@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/patches