Proposal: Change to library proposal process

Simon Marlow marlowsd at
Wed Jan 5 11:02:02 CET 2011

On 03/01/2011 11:20, Ian Lynagh wrote:
> On Sun, Jan 02, 2011 at 10:04:16AM +0000, Malcolm Wallace wrote:
>>>        A link to a patch implementing the change should be included.
>>>        Patches may be hosted anywhere
>> This "somewhere on the Internet" thing almost guarantees that the patch
>> will not be archived for posterity alongside the discussion.  It makes
>> future web-searches less useful than they could be.
> How about attaching them to
> then?
> (It doesn't look like you can attach files to a particular page on the
> wiki, whereas I believe you can on a trac wiki).

And if we follow this discussion to its conclusion, we end up back where 
we started: modifying a wiki page is error prone and we need more 
automation, so we use the ticket system instead.

I'm all for making the process more lightweight.  Why not just attach 
patches to the proposal email?  Updated proposals can be made with new 
patches attached.

This mailing-list-only process would help address the concerns that the 
process is too much of a burden for the developers/maintainers 
themselves.  Someone with commit access need not create the ticket at 
all: they just make a proposal on the list, and as long as it isn't 
controversial they commit after the discussion period.  It's a small 
step from here to committing *before* the discussion, which is what some 
people want.  I don't feel strongly about that, as long as we have an 
established protocol for discussing changes to these core APIs.


More information about the Libraries mailing list