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