This is a great suggestion - definitely makes sense to have it. Regards, Mridul
On Fri, Apr 24, 2015 at 11:08 AM, Patrick Wendell <pwend...@gmail.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
