I actually think the assignee JIRA issue is a minor detail; what really matters is do things get in and how.
So far, in the bits I've worked on, I've not encountered any problems. And as I've stated in the hadoop-dev lists, my main concern there is long-standing patches that languish because nobody invests the time to look at other people's patches unless/until they are on the critical path or part of a late-night-emergency-patch event (e.g. HADOOP-11730). I'm as guilty there as everyone else -and I know that a reason is that a lot of those external patches come without good test coverage; getting something in usually involves dealing with that. So far, so good -and I'd like to praise Sean Owen here, as not only has he put in effort, being in the same TZ means I get feedback faster. Sean, I owe you beer the next time you are in Bristol. If some JIRA has someone say "I'm working on it" and then nothing happens, it's moot whether its in a drop-down list or a comment on the bottom. If someone else wants to take it up, unless they like duplicating effort, starting off other people's work -collaborating- is the best way to produce quality code. The only thing I would change is somehow get newly created JIRAs posted onto a list (dev?) that doesn't have the firehose of every other JIRA; issues@ is too noisy. -Steve > On 23 Apr 2015, at 23:31, Sean Owen <so...@cloudera.com> wrote: > > The merge script automatically updates the linked JIRA after merging the PR > (why it is important to put the JIRA in the title). It can't auto assign > the JIRA since usernames dont match up but it is an easy reminder to set > the Assignee. I do right after and I think other committers do too. > > I'll search later for Fixed and Unassigned JIRAs in case there are any. > Feel free to flag any. > > In practice I think it is pretty rare that 2 people work on one JIRA > accidentally and can't remember a case where there was disagreement about > how to proceed. So I dont think a 'lock' is necessary in practice and don't > think even signaling has been a problem. > On Apr 23, 2015 6:14 PM, "Ulanov, Alexander" <alexander.ula...@hp.com> > wrote: > >> My thinking is that current way of assigning a contributor after the patch >> is done (or almost done) is OK. Parallel efforts are also OK until they are >> discussed in the issue's thread. Ilya Ganelin made a good point that it is >> about moving the project forward. It also adds means of competition "who >> make it faster/better" which is also good for the project and community. My >> only concern is about the throughput of Databricks folks who monitor >> issues, check patches and assign a contributor. Monitoring should be done >> on a constant basis (weekly?). >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
