You bet. Looking forward to the hacking.html update!
On May 15, 2009, at 4:47, Gavin Baumanis <gavinb_at_thespidernet.com>
> Hi Stefan,
> Thanks for the review.
> The text itself wasn't really a patch as such... more-so the intent of
> what it was saying.
> I guess what I really was after was whether or not the information was
> useful to be documented... and if it was, then, where was the
> "right" place to document.
> Though with your review and Greg's comments... seems like I have some
> work to do!
> Thanks again for the help.
> On 15/05/2009, at 9:14 PM, Stefan Sperling wrote:
>> On Fri, May 15, 2009 at 11:50:39AM +1000, Gavin Baumanis wrote:
>>> My intent wasn't so much about any particular "thing".
>>> More a case of for my own documentation as the current PM and for
>>> next person who comes after me...
>>> it'd be nice to know - as opposed to guessing...
>>> "What do I do as PM - when the dev list receives a patch for XXX. "
>>> Perhaps even a list of (for want of a better word - though I know
>>> technically wrong) "root" directories...
>>> So a patch for HACKING under the PM role might be something like;
>> If you send a proper patch, I will commit it :)
>> But don't forget the log message ;)
>>> The following paths are Subversion Project managed.
>> "... managed by the Subversion project" ?
>> Everything except "contrib".
>>> Patch submissions that have not received a response should;
>>> * Be pinged on the dev mailing list.
>> I'd put this here instead of below:
>> * When pinging the dev list ensure that you CC the "owner" too.
>>> * Added to the issue tracker after (xxx) days of further silence.
>> Don't really know what a good value for xxx is. 14?
>>> The following paths are not managed by the Subversion Project.
>>> /PathA : managed by ProjectA/ListA - Contactme_at_projectA
>>> /PathB : managed by ProjectB/ListB - Contactme_at_projectB
>> Instead of splitting things up by path, you could recommend looking
>> into the COMMITTERS file. "Full committers" are responsible for
>> pretty much anything they want to be responsible for.
>> "Partial committers" have an "area" that they want to be responsible
>> for, which is noted in the COMMITTERS file.
>> The area can be a single file, or a collection of files in various
>> directories, or a branch.
>> COMMITTERS is the first place I'd look to get this kind of
>> And if it is not there, then the Subversion logs might help.
>> I don't think trying to split things up by path and maintaining that
>> list in HACKING is going to work in the long term.
>>> * When pinging the dev list ensure that you CC the "owner" too.
>>> * these patches do / do not (I don't know which) get added the issue
>> Put them all into the issue tracker, please.
>> There are good reasons for putting a patch that has gotten no
>> attention yet into the issue tracker. People will stumble upon
>> it every now and then while surfing issues, and the patch gets
>> a name (the issue ID).
>> The only time patches don't need to go into the tracker is when
>> there already is consensus on the dev list that the patch isn't
>> But note that developers don't always agree with one another.
>> Just one person dismissing the patch is not enough.
>> However, if two or three developers do it, it's a strong indication
>> that others will agree with them.
>> If in doubt, put it into the tracker. The worst thing that can
>> happen is that the issue will be closed.
>>> Just about everyone on the dev list has this knowledge inherently
>>> because you work in the code, you know what belongs where and who to
>>> speak with if you need extra assistance.
>>> A non-committer will not have this information. I currently do not
>>> have this knowledge either.
>> So keep asking questions :)
>> And I appreciate your efforts to document this in HACKING.
Received on 2009-05-15 22:26:36 CEST