I was going to write in reply to a recent post by Roman,
- but didn't want to hijack his thread with something not entirely
related to his patch submission.
Basically, the following text comes in response to a specific use-case.
A non-committer submits a patch to the project.
The patch is reviewed by another non-committer.
There may or may not be some corrections / amendments - but
ultimately, the patch is reviewed favorably.
The issue is this use-case, is that the patch submission now
languishes in a "void" of sorts.
It's been reviewed, but does not get committed.
"Normally" this isn't a problem though.
A full-committer normally involves themselves in patch submissions and
after relevant review / re-factoring etc (the full-committer) commits
the submission on behalf of the OP.
As PM I can simply ping the list and attempt to get the patch some
attention - but it is simply that - an attempt.
In my relative short time as PM, I have logged a few patch submissions
into the issue tracker, purely because they failed to get appropriate
"full-committer" attention - even after pinging the list 2 or 3 times
after their original submission.
Ultimately, my question is;
For the specific use-case above is it appropriate for the PM to commit
the "languishing" patch submission?
The following is a quick list of positives and negatives to help with
discussion / decision making.
Allows the PM to commit submissions that have been reviewed by non-
Assists full-committers - in sense of workload.
Allows us (the project) to keep the patch submitter enthusiastic about
the Subversion Project, as they see their work being incorporated.
The project uses Subversion, so at the very worst - any commit made in
error can be simply reverted.
Requires the PM to have commit access.
(Previously this may not have been issue. Eg. the previous PM, Daniel
Shahaf was a full-committer and as far as I know, it may well be
"expected" of the PM to do exactly what I am proposing anyway).
Against me personally is the fact that I do not extensively know about
At the moment, the very best I could do is;
- ensure the design standard is followed.
- an appropriate log message exists
- the patch has been favorably reviewed etc
and that's pretty much about it.
I could re-build a local copy of SVN with the patch - attempt the task
for which it (the patch) applies and ensure it works for it's intended
I could even run the test suite - but seriously I wouldn't know if a
test failure was specifically related to "this" submission or
Then there is a PM (role) issue.
Let's just assume that people feel favorably about me having commit
rights for the specific use-case above.
Would this be a something just for me? or would it now become an
expectation of the PM Role (if it isn't already) ?
On a selling point of me... I have just volunteered a spare windows
server box and a Mac to the buildbot farm and am currently working
with Lieven to get that happening.
So testing code will certainly be "easy enough" and I'd certainly like
to think that my svn "technical" skills will get better the more I am
involved, but is it enough?
Really, It's a case of whether or not you feel it is a task you want
the PM doing?
and finally, do you trust me (personally) enough to do it and grant me
the required rights?
Though realistically, rights can be revoked just as quickly as they're
given: and since we are using Subversion, any commit made in error can
be reverted too.
So is it a "real" risk in the scheme of things?
Anyway - I put it out there for discussion.
Received on 2009-07-12 17:33:31 CEST