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.
Gavin.
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 the
>> 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 its
>> 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" ?
>
>> /subversion/...
>> /build/...
>
> 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
> information.
> 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
>> tracker.
>
> 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
> useful.
> 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.
>
> Stefan
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2270202
Received on 2009-05-15 13:48:09 CEST