You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by Luciano Resende <lu...@gmail.com> on 2013/06/02 10:25:13 UTC
Jira Issues
I just noticed that ALL the Jira issues are assigned to a single owner. I
don't believe that all these issues are being worked at the moment, also,
if you put yourself in the shoes of a external contributor trying to find
issues that he can help the community, it seems that there is nothing
available that he could help.
IMO, it would be better to leave these issues unassigned, until someone is
actually working on them, so that there are opportunities for others to
come and help.
Also, it would be good to have some easy tasks available that can be used
for contributors that want to get started contributing to the project.
Thanks
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Jira Issues
Posted by Josh Elser <jo...@gmail.com>.
That can definitely be a problem with how we do things. So far, we
haven't had any significant problems with it, but I think we're past a
dozen or so people with commit rights now.
I don't think we've had to have more than a <bump> on a ticket before
someone took the time to work it, but we also haven't had many big
new-feature contributions. Most of our patches are somewhat
small/contained. People tend to enjoy creating projects using Accumulo
than create new features inside of Accumulo (or the example falls into a
contrib realm which has less concern for quality than our core code).
On 06/03/2013 07:32 PM, Jordan Zimmerman wrote:
> So, that would imply not acting on patches unless a committer has an interest in it, right? If a patch poster wants action and isn't getting it he/she would need to post on @dev to find a champion.
>
> -JZ
>
> On Jun 3, 2013, at 4:14 PM, Josh Elser <jo...@gmail.com> wrote:
>
>> Speaking with my Apache Accumulo hat on:
>>
>> Contributors will typically attach the patch to the corresponding Jira issue or use review board [1]
>>
>> The patch, ignoring very trivial changes, will typically hang around for a while (probably due to the time until a committer has a moment to look at it -- I like to think this gives everyone a chance to look at the changes to give feedback despite us being a CTR [2] project). A committer who is comfortable with the changes will typically be the "champion" behind it to ensure it's up to snuff (matches code-style, no compiler warnings, works as intended, has tests, etc), apply it, and merge it to any other branches as necessary.
>>
>> The only time a patch has come up for review/vote for us (as far as I remember) is when the patch creates a controversial feature or there is strong disagreement on the implementation of the changes.
>>
>> Hope that helps!
>>
>> [1] https://reviews.apache.org/dashboard/
>> [2] http://www.apache.org/foundation/glossary.html#CommitThenReview
>>
>> On 06/03/2013 05:08 PM, Jordan Zimmerman wrote:
>>> ZooKeeper auto-applies patches. It's nice in that it does a first pass validation automatically. It's worthwhile, IMO.
>>>
>>> On this subject, what should our policy be on patches? Should we vote on every single one? How do other projects handle it?
>>>
>>> -JZ
Re: Jira Issues
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Jun 3, 2013 at 4:32 PM, Jordan Zimmerman <jordan@jordanzimmerman.com
> wrote:
> So, that would imply not acting on patches unless a committer has an
> interest in it, right? If a patch poster wants action and isn't getting it
> he/she would need to post on @dev to find a champion.
>
>
Just have a frank and quick turnaround, if there is a patch for a feature
that the community thinks that Curator is not the right place for it, just
close the Jira with the appropriate feedback... Not acting on Jiras, in the
situation Curator is right now, won't help building a large community.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Jira Issues
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
So, that would imply not acting on patches unless a committer has an interest in it, right? If a patch poster wants action and isn't getting it he/she would need to post on @dev to find a champion.
-JZ
On Jun 3, 2013, at 4:14 PM, Josh Elser <jo...@gmail.com> wrote:
> Speaking with my Apache Accumulo hat on:
>
> Contributors will typically attach the patch to the corresponding Jira issue or use review board [1]
>
> The patch, ignoring very trivial changes, will typically hang around for a while (probably due to the time until a committer has a moment to look at it -- I like to think this gives everyone a chance to look at the changes to give feedback despite us being a CTR [2] project). A committer who is comfortable with the changes will typically be the "champion" behind it to ensure it's up to snuff (matches code-style, no compiler warnings, works as intended, has tests, etc), apply it, and merge it to any other branches as necessary.
>
> The only time a patch has come up for review/vote for us (as far as I remember) is when the patch creates a controversial feature or there is strong disagreement on the implementation of the changes.
>
> Hope that helps!
>
> [1] https://reviews.apache.org/dashboard/
> [2] http://www.apache.org/foundation/glossary.html#CommitThenReview
>
> On 06/03/2013 05:08 PM, Jordan Zimmerman wrote:
>> ZooKeeper auto-applies patches. It's nice in that it does a first pass validation automatically. It's worthwhile, IMO.
>>
>> On this subject, what should our policy be on patches? Should we vote on every single one? How do other projects handle it?
>>
>> -JZ
>
Re: Jira Issues
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Jun 3, 2013 at 5:18 PM, Josh Elser <jo...@gmail.com> wrote:
> Sorry if I'm stomping on your toes.
>
> I understand Curator is very much growing. I like what it provides and was
> just hoping to provide some insight to how we've scaled up from a much
> smaller developer base.
>
>
No stomping at all, it's good to have different perspectives, and I believe
more mature projects does behave more like you said, but I wanted to make a
point that this is probably not the best way to motivate contributors to
continue to keep providing patches and patches if they are not reviewed
promptly.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Jira Issues
Posted by Josh Elser <jo...@gmail.com>.
Sorry if I'm stomping on your toes.
I understand Curator is very much growing. I like what it provides and
was just hoping to provide some insight to how we've scaled up from a
much smaller developer base.
On 06/03/2013 07:56 PM, Luciano Resende wrote:
> First, I want to clarify the current scenario for Curator, we are talking
> about a podling with pretty much ONE active committer.
>
> Also, let me speak with my "Contributor"
Re: Jira Issues
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, Jun 5, 2013 at 5:08 PM, Patrick Hunt <ph...@apache.org> wrote:
> I'm not sure you're doing this currently, but I've found that
> assigning a resolved jira back to the person responsible for doing the
> majority of work on the patch (etc...) is a "good thing". It allows
> for easy review of "who's ready for committership" and it also gives
> the person submitting the patch a clear sense of value ("they are
> responsible for having fixed the issue").
>
> Patrick
>
>
+1
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Jira Issues
Posted by Patrick Hunt <ph...@apache.org>.
I'm not sure you're doing this currently, but I've found that
assigning a resolved jira back to the person responsible for doing the
majority of work on the patch (etc...) is a "good thing". It allows
for easy review of "who's ready for committership" and it also gives
the person submitting the patch a clear sense of value ("they are
responsible for having fixed the issue").
Patrick
On Tue, Jun 4, 2013 at 12:03 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Tue, Jun 4, 2013 at 11:54 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
>> I'm for CTR for Curator committers. I'm not sure how to handle
>> non-committer requests for changes.
>>
>> -JZ
>>
>>
> Non-committers always upload a patch to a JIRA.
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
Re: Jira Issues
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Jun 4, 2013 at 11:54 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> I'm for CTR for Curator committers. I'm not sure how to handle
> non-committer requests for changes.
>
> -JZ
>
>
Non-committers always upload a patch to a JIRA.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Jira Issues
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
I'm for CTR for Curator committers. I'm not sure how to handle non-committer requests for changes.
-JZ
On Jun 3, 2013, at 4:56 PM, Luciano Resende <lu...@gmail.com> wrote:
> But I think the question was more
> towards CTR versus RTC, and I'm definitely on the side of CTR.
Re: Jira Issues
Posted by Luciano Resende <lu...@gmail.com>.
First, I want to clarify the current scenario for Curator, we are talking
about a podling with pretty much ONE active committer.
Also, let me speak with my "Contributor"
On Mon, Jun 3, 2013 at 4:14 PM, Josh Elser <jo...@gmail.com> wrote:
> Speaking with my Apache Accumulo hat on:
>
> Contributors will typically attach the patch to the corresponding Jira
> issue or use review board [1]
>
+1, non committers without a CLA is required to attach a patch to JIRA to
properly give Apache the rights to use the contribution. Using review board
might be a plu as it has a more user friendly UI for reviewing the code.
>
> The patch, ignoring very trivial changes, will typically hang around for a
> while (probably due to the time until a committer has a moment to look at
> it -- I like to think this gives everyone a chance to look at the changes
> to give feedback despite us being a CTR [2] project). A committer who is
> comfortable with the changes will typically be the "champion" behind it to
> ensure it's up to snuff (matches code-style, no compiler warnings, works as
> intended, has tests, etc), apply it, and merge it to any other branches as
> necessary.
>
I think the "hang around for a while" is the biggest problem for a podling.
If I'm a new guy trying the project, find some issues and provide a fix,
and it hangs for awhile, I would either find another project that gives the
same thing, or fork the project and most likely take it to the direction I
want without caring about contributing the new changes Back.
I also think that, because of this, a lot of corporations that don't have a
lot of experience with OSS, might end up finding alternatives to handle the
slow turnaround of patches that they provide.
>
> The only time a patch has come up for review/vote for us (as far as I
> remember) is when the patch creates a controversial feature or there is
> strong disagreement on the implementation of the changes.
>
Yes, vote usually don't happen often. But I think the question was more
towards CTR versus RTC, and I'm definitely on the side of CTR. That's why
we should learn how to properly evaluate new committers, and make sure we
trust the new members of the project... once that relationship of trust is
stablished, you can review the new commits (usually more thoroughly at
the beginning) and discuss them in case of
disagreement.... Establishing good design discussion best practices, where
medium to small features should be discussed on the dev list first, having
good test coverage, that can flag even style type of errors are also good,
particularly when these are triggered before merge (e.g. in a gerrit x
jenkins workflow)
>
> Hope that helps!
>
> [1] https://reviews.apache.org/**dashboard/<https://reviews.apache.org/dashboard/>
> [2] http://www.apache.org/**foundation/glossary.html#**CommitThenReview<http://www.apache.org/foundation/glossary.html#CommitThenReview>
>
>
> On 06/03/2013 05:08 PM, Jordan Zimmerman wrote:
>
>> ZooKeeper auto-applies patches. It's nice in that it does a first pass
>> validation automatically. It's worthwhile, IMO.
>>
>> On this subject, what should our policy be on patches? Should we vote on
>> every single one? How do other projects handle it?
>>
>> -JZ
>>
>
>
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Jira Issues
Posted by Josh Elser <jo...@gmail.com>.
Speaking with my Apache Accumulo hat on:
Contributors will typically attach the patch to the corresponding Jira
issue or use review board [1]
The patch, ignoring very trivial changes, will typically hang around for
a while (probably due to the time until a committer has a moment to look
at it -- I like to think this gives everyone a chance to look at the
changes to give feedback despite us being a CTR [2] project). A
committer who is comfortable with the changes will typically be the
"champion" behind it to ensure it's up to snuff (matches code-style, no
compiler warnings, works as intended, has tests, etc), apply it, and
merge it to any other branches as necessary.
The only time a patch has come up for review/vote for us (as far as I
remember) is when the patch creates a controversial feature or there is
strong disagreement on the implementation of the changes.
Hope that helps!
[1] https://reviews.apache.org/dashboard/
[2] http://www.apache.org/foundation/glossary.html#CommitThenReview
On 06/03/2013 05:08 PM, Jordan Zimmerman wrote:
> ZooKeeper auto-applies patches. It's nice in that it does a first pass validation automatically. It's worthwhile, IMO.
>
> On this subject, what should our policy be on patches? Should we vote on every single one? How do other projects handle it?
>
> -JZ
Re: Jira Issues
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
ZooKeeper auto-applies patches. It's nice in that it does a first pass validation automatically. It's worthwhile, IMO.
On this subject, what should our policy be on patches? Should we vote on every single one? How do other projects handle it?
-JZ
Re: Jira Issues
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Jun 3, 2013 at 11:29 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
>
> On Jun 3, 2013, at 9:11 AM, Luciano Resende <lu...@gmail.com> wrote:
>
> > Also, I see that there are few open patches, that are waiting for more
> then
> > a week without any feedback. While we are trying to grow the community,
> > it's highly recommended that you have a quick turnaround on patches, etc
> to
> > take advantage of the momentum with the particular contributor…
>
> At minimum, I want to get the auto-apply patch service going. I'll try to
> do that soon.
>
> -JZ
What the auto-apply patch will provide ? Does this just build a patch on
top-of-trunk without applying ?
Ideally, a contributor would provide partial patches, even when it's not
compiling, so the feeedback turnaround is quick... and the design direction
in use is agreed by the community.... in this case, I'm not sure how
auto-apply would help.
IMO, I'd handle the current patches manually without any delays, and use
enhanced infrastructure when that is available....
Anyway, just my 0.2c...
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Jira Issues
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
On Jun 3, 2013, at 9:11 AM, Luciano Resende <lu...@gmail.com> wrote:
> Also, I see that there are few open patches, that are waiting for more then
> a week without any feedback. While we are trying to grow the community,
> it's highly recommended that you have a quick turnaround on patches, etc to
> take advantage of the momentum with the particular contributor…
At minimum, I want to get the auto-apply patch service going. I'll try to do that soon.
-JZ
Re: Jira Issues
Posted by Luciano Resende <lu...@gmail.com>.
On Sun, Jun 2, 2013 at 10:38 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> I updated the Jira admin to make the default unassigned. I didn't realize
> I was the default. I'll also update the issues until we decide to work on
> them.
>
>
Great, perfect.
Also, I see that there are few open patches, that are waiting for more then
a week without any feedback. While we are trying to grow the community,
it's highly recommended that you have a quick turnaround on patches, etc to
take advantage of the momentum with the particular contributor...
Thanks.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Jira Issues
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
I updated the Jira admin to make the default unassigned. I didn't realize I was the default. I'll also update the issues until we decide to work on them.
-JZ
On Jun 2, 2013, at 1:25 AM, Luciano Resende <lu...@gmail.com> wrote:
> I just noticed that ALL the Jira issues are assigned to a single owner. I
> don't believe that all these issues are being worked at the moment, also,
> if you put yourself in the shoes of a external contributor trying to find
> issues that he can help the community, it seems that there is nothing
> available that he could help.
>
> IMO, it would be better to leave these issues unassigned, until someone is
> actually working on them, so that there are opportunities for others to
> come and help.
>
> Also, it would be good to have some easy tasks available that can be used
> for contributors that want to get started contributing to the project.
>
> Thanks
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/