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 > >
