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.



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 <[EMAIL PROTECTED]>:
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:

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.


Reply via email to