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
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.
+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:
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.
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
; 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
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
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
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
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
I watch these lists, so I have a fair understanding of how things work around
here. I don't give direct input in the day to day activities though, like Greg
Stein on the other thread, so I can understand if it looks like it came from up
above. Apache Members come around and give opinions time
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
I think one of the benefits of assignee fields that I've seen in other
projects is their potential to coordinate and prevent duplicate work. It's
really frustrating to put a lot of work into a patch and then find out that
someone has been doing the same. It's helpful for the project etiquette to
I can get behind that point of view too. That's what I've told people
who expect Assignee is a necessary part of workflow. The existence of
a PR link is a signal someone's working on it.
In that case we need not do anything.
On Wed, Apr 22, 2015 at 8:32 PM, Patrick Wendell pwend...@gmail.com
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
Woh hold on a minute.
Spark has been among the projects that are the most welcoming to new
contributors. And thanks to this, the sheer number of activities in Spark
is much larger than other projects, and our workflow has to accommodate
this fact.
In practice, people just create pull requests on
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
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
I think you misread the thread, since that's the opposite of what
Patrick suggested. He's suggesting that *nobody ever waits* to be
assigned a JIRA to work on it; that anyone may work on a JIRA without
waiting for it to be assigned.
The point is: assigning JIRAs discourages others from doing work
If it is true what you say, what is the reason for this
committer-only-assigns-JIRA tickets policy? If anyone can send a pull request,
anyone should be able to assign tickets to himself/herself too.
+Vinod
On Apr 22, 2015, at 1:18 PM, Reynold Xin
r...@databricks.commailto:r...@databricks.com
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
21 matches
Mail list logo
