assigning JIRAs to non committers

[James Strachan <ja...@gmail.com>]

Just an idle observation as I'd never seen this workflow before on
JIRA so thought I'd ask :)

I've been watching some of the recent JIRA activity with interest.
I've seen a few JIRAs arrive, someone submits a test case who's not a
committer, then the issue gets assigned to the person who submitted
the patch. In some cases; when there may be many patches to assign
over time, I can understand it (e.g. ZOOKEEPER-78 could take a zillion
iterations before the feature is complete) - but in general if one
JIRA gets one patch from a non-committer, should the JIRA be left
unassigned - or assigned to a committer to review and apply or
reject-with-reason the patch?

i.e. lets say I raise a JIRA and attach a patch; once we're at that
stage I can't actually do anything else, not being a committer - other
than add another version of the patch :) So am not sure if its worth
assigning the issue to me. I guess the person who raised the issue &
submitted the patch can always mark it as unassigned :)

No biggie I just thought I'd ask if this was an intentional way you
guys had worked together in the past?

-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com

Re: assigning JIRAs to non committers

[Patrick Hunt <ph...@apache.org>]

Actually not your bad, I just added that page last night. ;-)

I really appreciate your (everyone) input and it's helping to shape our 
decisions as a new Apache project. I know that everyone is super excited 
to run with ZooKeeper, we (existing project members) are excited as 
well. Bear with us as we move our project & process from SF to Apache.

A bit of status/background: We are currently working towards 4 goals (in 
order or priority):

1) support/expand our user & contributor base
2) complete migration to ASF
3) 3.0 version of ZooKeeper
and just added recently
4) recipe implementation (which is a good thing IMO and also supports 1 
above)

SVN and Jira have been moved from SF to ASF. We are still working on the 
docs/site migration. There are a number of 3.0 issues currently 
unresolved, feel free to jump on those as we would like to push the 3.0 
release once ASF migration is completed.

Regards,

Patrick

James Strachan wrote:
> Cool thanks for the heads up! You live and learn :) Its funny how
> totally different all the various Apache projects are and how they get
> things done.
> 
> My bad for not reading the contributing section of the wiki yet :)
> 
> 2008/7/23 Patrick Hunt <ph...@apache.org>:
>> James Strachan wrote:
>>> Just an idle observation as I'd never seen this workflow before on
>>> JIRA so thought I'd ask :)
>> I'm new to JIRA as well...
>>
>>> I've been watching some of the recent JIRA activity with interest.
>>> I've seen a few JIRAs arrive, someone submits a test case who's not a
>>> committer, then the issue gets assigned to the person who submitted
>>> the patch. In some cases; when there may be many patches to assign
>>> over time, I can understand it (e.g. ZOOKEEPER-78 could take a zillion
>>> iterations before the feature is complete) - but in general if one
>>> JIRA gets one patch from a non-committer, should the JIRA be left
>>> unassigned - or assigned to a committer to review and apply or
>>> reject-with-reason the patch?
>> I believe the workflow is that the jira is assigned to the person resolving
>> the issue (ie submiting the patch). You/Hiram have been added as
>> "contributors" to jira, this means that jiras can be assigned to you. We
>> typically add ppl to the contributor list as soon as they submit a patch.
>>
>> After that point you do the back/forth in the comments trying to get
>> everyone to agree to a resolution. If this is a patch you then change the
>> status to "patch available" and ask for review/voting, after which if you
>> get a "+1" it's then up to a committer to commit to svn.
>>
>> full details here:
>> http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute
>>
>>> i.e. lets say I raise a JIRA and attach a patch; once we're at that
>>> stage I can't actually do anything else, not being a committer - other
>>> than add another version of the patch :) So am not sure if its worth
>>> assigning the issue to me. I guess the person who raised the issue &
>>> submitted the patch can always mark it as unassigned :)
>> It's assigned to the person who resolved the issue. If accepted it's up the
>> the committers to get it into svn, but you (the resolver) are still
>> responsible. This information is also important for reporting purposes.
>>
>>> No biggie I just thought I'd ask if this was an intentional way you
>>> guys had worked together in the past?
>> This is generally how Hadoop core/hbase do things.
>>
>> Patrick
>>
> 
> 
> 

Re: assigning JIRAs to non committers

[James Strachan <ja...@gmail.com>]

Cool thanks for the heads up! You live and learn :) Its funny how
totally different all the various Apache projects are and how they get
things done.

My bad for not reading the contributing section of the wiki yet :)

2008/7/23 Patrick Hunt <ph...@apache.org>:
> James Strachan wrote:
>>
>> Just an idle observation as I'd never seen this workflow before on
>> JIRA so thought I'd ask :)
>
> I'm new to JIRA as well...
>
>> I've been watching some of the recent JIRA activity with interest.
>> I've seen a few JIRAs arrive, someone submits a test case who's not a
>> committer, then the issue gets assigned to the person who submitted
>> the patch. In some cases; when there may be many patches to assign
>> over time, I can understand it (e.g. ZOOKEEPER-78 could take a zillion
>> iterations before the feature is complete) - but in general if one
>> JIRA gets one patch from a non-committer, should the JIRA be left
>> unassigned - or assigned to a committer to review and apply or
>> reject-with-reason the patch?
>
> I believe the workflow is that the jira is assigned to the person resolving
> the issue (ie submiting the patch). You/Hiram have been added as
> "contributors" to jira, this means that jiras can be assigned to you. We
> typically add ppl to the contributor list as soon as they submit a patch.
>
> After that point you do the back/forth in the comments trying to get
> everyone to agree to a resolution. If this is a patch you then change the
> status to "patch available" and ask for review/voting, after which if you
> get a "+1" it's then up to a committer to commit to svn.
>
> full details here:
> http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute
>
>> i.e. lets say I raise a JIRA and attach a patch; once we're at that
>> stage I can't actually do anything else, not being a committer - other
>> than add another version of the patch :) So am not sure if its worth
>> assigning the issue to me. I guess the person who raised the issue &
>> submitted the patch can always mark it as unassigned :)
>
> It's assigned to the person who resolved the issue. If accepted it's up the
> the committers to get it into svn, but you (the resolver) are still
> responsible. This information is also important for reporting purposes.
>
>> No biggie I just thought I'd ask if this was an intentional way you
>> guys had worked together in the past?
>
> This is generally how Hadoop core/hbase do things.
>
> Patrick
>



-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com

Re: assigning JIRAs to non committers

[Patrick Hunt <ph...@apache.org>]

James Strachan wrote:
> Just an idle observation as I'd never seen this workflow before on
> JIRA so thought I'd ask :)

I'm new to JIRA as well...

> I've been watching some of the recent JIRA activity with interest.
> I've seen a few JIRAs arrive, someone submits a test case who's not a
> committer, then the issue gets assigned to the person who submitted
> the patch. In some cases; when there may be many patches to assign
> over time, I can understand it (e.g. ZOOKEEPER-78 could take a zillion
> iterations before the feature is complete) - but in general if one
> JIRA gets one patch from a non-committer, should the JIRA be left
> unassigned - or assigned to a committer to review and apply or
> reject-with-reason the patch?

I believe the workflow is that the jira is assigned to the person 
resolving the issue (ie submiting the patch). You/Hiram have been added 
as "contributors" to jira, this means that jiras can be assigned to you. 
We typically add ppl to the contributor list as soon as they submit a patch.

After that point you do the back/forth in the comments trying to get 
everyone to agree to a resolution. If this is a patch you then change 
the status to "patch available" and ask for review/voting, after which 
if you get a "+1" it's then up to a committer to commit to svn.

full details here:
http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute

> i.e. lets say I raise a JIRA and attach a patch; once we're at that
> stage I can't actually do anything else, not being a committer - other
> than add another version of the patch :) So am not sure if its worth
> assigning the issue to me. I guess the person who raised the issue &
> submitted the patch can always mark it as unassigned :)

It's assigned to the person who resolved the issue. If accepted it's up 
the the committers to get it into svn, but you (the resolver) are still 
responsible. This information is also important for reporting purposes.

> No biggie I just thought I'd ask if this was an intentional way you
> guys had worked together in the past?

This is generally how Hadoop core/hbase do things.

Patrick