On Jan 4, 2007, at 3:04 AM, Mark Brouwer wrote:
Phil Steitz wrote:
> And maybe I'm completely out of bounds here but I think that
even some
> form of issue planning (in what version to expect what) can be
> beneficial as well, JIRA is great for that too.
Yep. It is. But be careful to keep things as open and welcoming to
volunteers. Rigid process is off-putting to some people.
+1
There is a balance here to be struck. The process that I outlined
was for
submissions by non-committers, which requires that patches be
submitted and
I think it is in general much better to have the patches attached
to Jira
tickets than to have them arrive in emails.
I personally favor a uniform way of working between committers and
non-committers, the only difference is that committers have checkin
permissions, the ability to resolve issues in JIRA [1] and assuming we
want all committers to be part of the PMC a binding vote if that turns
out to be valuable.
+1
[1] as the ASF runs the Enterprise edition of JIRA I assume we can
setup our own permission schemes, etc. for the project?
Also can somebody show me a good project where they use JIRA for
submitting the patches by (non-)committers, I have the tendency to
always pick the wrong ones for my samples.
The majority of the patches submitted in the Hadoop community (http://
lucene.apache.org/hadoop) are submitted by non-committers: http://
issues.apache.org/jira/browse/HADOOP
The submitter marks a patch as "Patch Available" when it has been
code review and tested. Those with commit rights can then look over
and commit patches that are in this state. From my short experience
with this community, it seems to work well.
Cheers,
Nige
