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?). > > Best regards, Alexander > > -----Original Message----- > From: Vinod Kumar Vavilapalli [mailto:vino...@hortonworks.com] > Sent: Wednesday, April 22, 2015 2:59 PM > To: Patrick Wendell > Cc: Nicholas Chammas; Ganelin, Ilya; Mark Hamstra; Sean Owen; dev > Subject: Re: Should we let everyone set Assignee? > > > Last one for the day. > > Everyone, as I said clearly, I was "not alluding to anything fishy in > practice", I was describing how things go wrong in such an environment. > Sandy's email lays down some of these problems. > > Assigning a JIRA in other projects is not a reservation. It is a clear > intention of working on design or code. > > You don't need a new convention of signaling. In almost all other > projects, it is assigning tickets - that's how it is used. > > +Vinod > > On Apr 22, 2015, at 2:37 PM, Patrick Wendell <pwend...@gmail.com> wrote: > > > Sandy - I definitely agree with that. We should have a convention of > > signaling someone intends to work - for instance by commenting on the > > JIRA and we should document this on the contribution guide. The nice > > thing about having that convention is that multiple people can say > > they are going to work on something, whereas only one person can be > > given the assignee slot on a JIRA. > > > > > > On Wed, Apr 22, 2015 at 2:33 PM, Nicholas Chammas > > <nicholas.cham...@gmail.com> wrote: > >> To repeat what Patrick said (literally): > >> > >> If an issue is "assigned" to person X, but some other person Y > >> submits a great patch for it, I think we have some obligation to > >> Spark users and to the community to merge the better patch. So the > >> idea of reserving the right to add a feature, it just seems overall off > to me. > >> > >> No-one in the Spark community dictates who gets to do work. When an > >> issue is assigned to someone in JIRA, it's either because a) they did > >> the work and the issue is now resolved, or b) they are signaling to > >> others that they are working on it. > >> > >> In the case of b), nothing stops other people from working on the > >> issue and it's quite normal for other people to complete issues that > >> were technically assigned to someone else. There is no land grabbing > >> or stalling. Anyone who has contributed to Spark for any amount of time > knows this. > >> > >> Vinod, > >> > >> I want to take this opportunity to call out the approach to > >> communication you took here. > >> > >> As a random contributor to Spark and active participant on this list, > >> my reaction when I read your email was this: > >> > >> You do not know how the Spark community actually works. > >> You read a thread that contains some trigger phrases. > >> You wrote a lengthy response as a knee-jerk reaction. > >> > >> I'm not trying to mock, but I want to be direct and honest about how > >> you came off in this thread to me and probably many others. > >> > >> Why not ask questions first--many questions? Why not make doubly sure > >> that you understand the situation correctly before responding? > >> > >> In many ways this is much like filing a bug report. "I'm seeing this. > >> It seems wrong to me. Is this expected?" I think we all know from > >> experience that this kind of bug report is polite and will likely > >> lead to a productive discussion. On the other hand: "You're returning > >> a -1 here? This is obviously wrong! And, boy, lemme tell you how > >> wrong you are!!!" No-one likes to deal with bug reports like this. > >> More importantly, they get in the way of fixing the actual problem, if > there is one. > >> > >> This is not about the Apache Way or not. It's about basic etiquette > >> and effective communication. > >> > >> I understand that there are legitimate potential concerns here, and > >> it's important that, as an Apache project, Spark work according to > >> Apache principles. But when some person who has never participated on > >> this list pops up out of nowhere with a lengthy lecture on the Apache > >> Way and whatnot, I have to say that that is not an effective way to > >> communicate. Pretty much the same thing happened with Greg Stein on > >> an earlier thread some months ago about designating maintainers for > components. > >> > >> The concerns are legitimate, I'm sure, and we want to keep Spark in > >> line with the Apache Way. And certainly, there have been many times > >> when a project veered off course and needed to corrected. > >> > >> But when we want to make things right, I hope we can do it in a way > >> that respectfully and tactfully engages the community. These > >> "lectures delivered from above" -- which is how they come off -- are > not helpful. > >> > >> Nick > >> > >> > >> On Wed, Apr 22, 2015 at 4:31 PM Ganelin, Ilya > >> <ilya.gane...@capitalone.com> > >> wrote: > >>> > >>> As a contributor, I¹ve never felt shut out from the Spark community, > >>> nor have I seen any examples of territorial behavior. A few times > >>> I¹ve expressed interest in more challenging work and the response I > >>> received was generally ³go ahead and give it a shot, just understand > >>> that this is sensitive code so we may end up modifying the PR > >>> substantially.² Honestly, that seems fine, and in general, I think > >>> it¹s completely fair to go with the PR model - e.g. If a JIRA has an > >>> open PR then it¹s an active effort, otherwise it¹s fair game unless > >>> otherwise stated. At the end of the day, it¹s about moving the > >>> project forward and the only way to do that is to have actual code > >>> in the pipes -speculation and intent don¹t really help, and there¹s > >>> nothing preventing an interested party from submitting a PR against an > issue. > >>> > >>> Thank you, > >>> Ilya Ganelin > >>> > >>> > >>> > >>> > >>> > >>> > >>> On 4/22/15, 1:25 PM, "Mark Hamstra" <m...@clearstorydata.com> wrote: > >>> > >>>> Agreed. The Spark project and community that Vinod describes do > >>>> not resemble the ones with which I am familiar. > >>>> > >>>> On Wed, Apr 22, 2015 at 1:20 PM, Patrick Wendell > >>>> <pwend...@gmail.com> > >>>> wrote: > >>>> > >>>>> Hi Vinod, > >>>>> > >>>>> Thanks for you thoughts - However, I do not agree with your > >>>>> sentiment and implications. Spark is broadly quite an inclusive > >>>>> project and we spend a lot of effort culturally to help make > newcomers feel welcome. > >>>>> > >>>>> - Patrick > >>>>> > >>>>> On Wed, Apr 22, 2015 at 1:11 PM, Vinod Kumar Vavilapalli > >>>>> <vino...@hortonworks.com> wrote: > >>>>>> Actually what this community got away with is pretty much an > >>>>> anti-pattern compared to every other Apache project I have seen. > >>>>> And may I say in a not so Apache way. > >>>>>> > >>>>>> Waiting for a committer to assign a patch to someone leaves it as > >>>>>> a > >>>>> privilege to a committer. Not alluding to anything fishy in > >>>>> practice, but this also leaves a lot of open ground for > >>>>> self-interest. Committers defining notions of good fit / level of > >>>>> experience do not work, highly subjective and lead to group > >>>>> control. > >>>>>> > >>>>>> In terms of semantics, here is what most other projects (dare I > >>>>>> say > >>>>> every Apache project?) that I have seen do > >>>>>> - A new contributor comes in who is not yet added to the JIRA > >>>>> project. > >>>>> He/she requests one of the project's JIRA admins to add him/her. > >>>>>> - After that, he or she is free to assign tickets to themselves. > >>>>>> - What this means > >>>>>> -- Assigning a ticket to oneself is a signal to the rest of > >>>>>> the > >>>>> community that he/she is actively working on the said patch. > >>>>>> -- If multiple contributors want to work on the same patch, it > >>>>> needs > >>>>> to resolved amicably through open communication. On JIRA, or on > >>>>> mailing lists. Not by the whim of a committer. > >>>>>> - Common issues > >>>>>> -- Land grabbing: Other contributors can nudge him/her in case > >>>>>> of > >>>>> inactivity and take them over. Again, amicably instead of a > >>>>> committer making subjective decisions. > >>>>>> -- Progress stalling: One contributor assigns the ticket to > >>>>> himself/herself is actively debating but with no real code/docs > >>>>> contribution or with any real intention of making progress. Here > >>>>> workable, reviewable code for review usually wins. > >>>>>> > >>>>>> Assigning patches is not a privilege. Contributors at Apache are > >>>>>> a > >>>>> bunch > >>>>> of volunteers, the PMC should let volunteers contribute as they > >>>>> see fit. We do not assign work at Apache. > >>>>>> > >>>>>> +Vinod > >>>>>> > >>>>>> On Apr 22, 2015, at 12:32 PM, Patrick Wendell > >>>>>> <pwend...@gmail.com> > >>>>> wrote: > >>>>>> > >>>>>>> One over arching issue is that it's pretty unclear what > >>>>>>> "Assigned to X" in JIAR means from a process perspective. > >>>>>>> Personally I actually feel it's better for this to be more > >>>>>>> historical - i.e. who ended up submitting a patch for this > >>>>>>> feature that was merged - rather than creating an exclusive > >>>>>>> reservation for a particular user to work on something. > >>>>>>> > >>>>>>> If an issue is "assigned" to person X, but some other person Y > >>>>> submits > >>>>>>> a great patch for it, I think we have some obligation to Spark > >>>>>>> users and to the community to merge the better patch. So the > >>>>>>> idea of reserving the right to add a feature, it just seems > >>>>>>> overall off to > >>>>> me. > >>>>>>> IMO, its fine if multiple people want to submit competing > >>>>>>> patches for something, provided everyone comments on JIRA saying > >>>>>>> they are intending to submit a patch, and everyone understands > >>>>>>> there is duplicate effort. So commenting with an intention to > >>>>>>> submit a patch, IMO seems like the healthiest workflow since it > >>>>>>> is non exclusive. > >>>>>>> > >>>>>>> To me the main benefit of "assigning" something ahead of time is > >>>>>>> if you have a committer that really wants to see someone > >>>>>>> specific work > >>>>> on > >>>>>>> a patch, it just acts as a strong signal that there is someone > >>>>>>> endorsed to work on that patch. That doesn't mean no one else > >>>>>>> can submit a patch, but it is IMO more of a warning that there > >>>>>>> may be existing work which is likely to be high quality, to > >>>>>>> avoid duplicated effort. > >>>>>>> > >>>>>>> When it was really easy to assign features to themselves, I saw > >>>>>>> a lot of anti-patterns in the community that seemed unhealthy, > >>>>> specifically: > >>>>>>> > >>>>>>> - It was really unclear what it means semantically if someone is > >>>>>>> assigned to a JIRA. > >>>>>>> - People assign JIRA's to themselves that aren't a good fit, > >>>>>>> given > >>>>> the > >>>>>>> authors level of experience. > >>>>>>> - People expect if they assign JIRA's to themselves that others > >>>>>>> won't submit patches, and become upset if they do. > >>>>>>> - People are discouraged from working on a patch because someone > >>>>>>> else was officially assigned. > >>>>>>> > >>>>>>> - Patrick > >>>>>>> > >>>>>>> On Wed, Apr 22, 2015 at 11:13 AM, Sean Owen <so...@cloudera.com> > >>>>> wrote: > >>>>>>>> Anecdotally, there are a number of people asking to set the > >>>>>>>> Assignee field. This is currently restricted to Committers in > >>>>>>>> JIRA. I know > >>>>> the > >>>>>>>> logic was to prevent people from Assigning a JIRA and then > >>>>>>>> leaving > >>>>> it; > >>>>>>>> it also matters a bit for questions of "credit". > >>>>>>>> > >>>>>>>> Still I wonder if it's best to just let people go ahead and set > >>>>>>>> it, > >>>>> as > >>>>>>>> the lesser "evil". People can already do a lot like resolve > >>>>>>>> JIRAs > >>>>> and > >>>>>>>> set shepherd and critical priority and all that. > >>>>>>>> > >>>>>>>> I think the intent was to let "Developers" set this, but maybe > >>>>>>>> due > >>>>> to > >>>>>>>> an error, that's not how the current JIRA permission is > >>>>>>>> implemented. > >>>>>>>> > >>>>>>>> I ask because I'm about to ping INFRA to update our scheme. > >>>>>>>> > >>>>>>>> > >>>>> ------------------------------------------------------------------ > >>>>> --- > >>>>>>>> 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 > >>>>> > >>>>> > >>> > >>> ________________________________________________________ > >>> > >>> The information contained in this e-mail is confidential and/or > >>> proprietary to Capital One and/or its affiliates. The information > >>> transmitted herewith is intended only for use by the individual or > >>> entity to which it is addressed. If the reader of this message is > >>> not the intended recipient, you are hereby notified that any review, > >>> retransmission, dissemination, distribution, copying or other use > >>> of, or taking of any action in reliance upon this information is > >>> strictly prohibited. If you have received this communication in > >>> error, please contact the sender and delete the material from your > computer. > >>> > >>> > >>> -------------------------------------------------------------------- > >>> - 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 > >
