It's a bit of a digression - but Steve's suggestion that we have a mailing list for new issues is a great idea and we can do it easily. We could nave new-issues@s.a.o or something (we already have issues@s.a.o).
- Patrick On Fri, Apr 24, 2015 at 9:50 AM, Ted Yu <yuzhih...@gmail.com> wrote: > bq. get newly created JIRAs posted onto a list (dev?) > > +1 > > On Fri, Apr 24, 2015 at 3:02 AM, Steve Loughran <ste...@hortonworks.com> > wrote: > >> >> 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
