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
Received on 2009-05-15 13:14:39 CEST