+1 for new issues in dev list Отправлено с iPhone
> 24 апр. 2015 г., в 11:13, Reynold Xin <r...@databricks.com> написал(а): > > I like that idea (having a new-issues list instead of directly forwarding > them to dev). > > > 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
