You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Billie J Rinaldi <bi...@ugov.gov> on 2011/10/12 17:37:25 UTC
JIRA assignees
I propose adding Jesse Yates (jesse_yates) to the accumulo-developers group on JIRA so that he can assign tickets to himself. :)
Billie
Re: JIRA assignees
Posted by Drew Farris <dr...@apache.org>.
I guess you'll just have to make him a committer then ;)
On Wed, Oct 12, 2011 at 12:25 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Oct 12, 2011, at 8:37 AM, Billie J Rinaldi wrote:
>
>> I propose adding Jesse Yates (jesse_yates) to the accumulo-developers group on JIRA so that he can assign tickets to himself. :)
>
> Sounds like an interesting idea. What do we hope to accomplish by letting a non-committer assign tickets to themselves?
>
>
> Regards,
> Alan
>
>
Re: JIRA assignees
Posted by Drew Farris <dr...@apache.org>.
On Wed, Oct 12, 2011 at 1:05 PM, Billie J Rinaldi
<bi...@ugov.gov> wrote:
> I am hoping to establish a process such as the one Todd describes. In addition to giving us a way to see what new developers (potential committers) have contributed, it may help give people a greater sense of responsibility for the things they are working on.
+1
Re: JIRA assignees
Posted by Todd Lipcon <to...@cloudera.com>.
On Thu, Oct 13, 2011 at 8:02 AM, Keith Turner <kt...@apache.org> wrote:
> I like this concept, but I am curious about something.
>
> Ultimately a committer needs to vet the patch and apply it.
In most of the Hadoop projects, we have a review-then-commit policy.
So, even if you're a committer, another committer needs to vet the
patch and provide a "+1" before the patch author can commit it.
Apparently this is abnormal for the ASF, though - most projects in the
foundation allow committers to commit without review, assuming that
another commit can ask for a revert if there is a big problem.
> For
> projects you have seen use this how does that happen? Does the
> contributor owning the ticket informally work w/ a committer? Does
> this happen organically, or did they setup something more structured?
It's pretty organic. The only structure is that there are some saved
links to the "patch available queue". Once the contributor feels the
patch is ready, they hit "Submit patch", which moves it to the PA
state. Then, hopefully, committers will triage this queue regularly to
review any items with available patches. If the patch looks good, it
gets committed. Otherwise, they will provide review feedback and move
it back to "Open" state.
The above is the theory. In some projects, the PA queue grows very
long. Here's an interesting graph:
http://people.apache.org/~tomwhite/hadoop-patch-queue.html
> In these projects, is it the contributor's responsibility to ensure
> the tickets assigned to them do not languish because of a lack of
> attention from a committer?
More experienced contributors (eg those who are working on the project
on a regular basis) tend to know who the expert is for each area of
the code, and often do off-list pings to solicit a review. Users who
happen to fix a small bug are often less tenacious - eg they just post
a patch and disappear, hoping it will eventually get reviewed and
committed. Hopefully any patch that a user contributes is a real fix
for a real problem, and worth the time to look over. Sometimes there
are patches uploaded that are just poor quality or really low
priority, and those tend to languish longer than others.
-Todd
--
Todd Lipcon
Software Engineer, Cloudera
Re: JIRA assignees
Posted by Keith Turner <kt...@apache.org>.
On Wed, Oct 12, 2011 at 12:49 PM, Todd Lipcon <to...@cloudera.com> wrote:
> In other projects I'm involved in, the JIRA workflow is that, the
> first time a new person uploads a patch, one of the committers will
> add them to the contributors group in JIRA and assign that JIRA to
> them. In the future, they are free to assign themselves any JIRAs they
> plan to work on.
>
Todd
I like this concept, but I am curious about something.
Ultimately a committer needs to vet the patch and apply it. For
projects you have seen use this how does that happen? Does the
contributor owning the ticket informally work w/ a committer? Does
this happen organically, or did they setup something more structured?
In these projects, is it the contributor's responsibility to ensure
the tickets assigned to them do not languish because of a lack of
attention from a committer?
Keith
Re: JIRA assignees
Posted by Adam Fuchs <ad...@ugov.gov>.
> If there's consensus on the project that this is the way to go I'm happy
to update the Accumulo Jira project.
+1
Adam
Re: JIRA assignees
Posted by Keith Turner <kt...@apache.org>.
> If there's consensus on the project that this is the way to go I'm happy to update the Accumulo Jira project.
+1
Re: mvn assembly
Posted by Drew Farris <dr...@apache.org>.
On Thu, Oct 20, 2011 at 9:32 AM, Aaron Cordova <aa...@cordovas.org> wrote:
>
> Should mvn assembly:assembly be installing completed jars into the local repo as it goes?
>
FWIW, assembly:assembly doesn't install the completed jars into the
local repo as it goes -- it resolves them as they are built in the
multi-module build process that happens prior to the assembly
executing.
The problem arises from the lack of interaction between the
maven-dependency-plugin and the multi-module build process (iirc
MNG-3283 is related). This cause the assembly to fail when package
isn't executed.
Drew
Re: mvn assembly
Posted by Billie J Rinaldi <bi...@ugov.gov>.
On Thursday, October 20, 2011 9:32:51 AM, "Aaron Cordova" <aa...@cordovas.org> wrote
> Maybe my maven's broken but I can't build all the way through
> assembly:assembly without manually adding the jars that are built to
> my local maven repo.
It should work if you remove them from your repo then execute mvn package assembly:assembly. See ACCUMULO-25 for a discussion of our use of mvn.
Billie
Re: mvn assembly
Posted by John W Vines <jo...@ugov.gov>.
----- Original Message -----
| From: "Aaron Cordova" <aa...@cordovas.org>
| To: accumulo-dev@incubator.apache.org
| Sent: Thursday, October 20, 2011 9:32:51 AM
| Subject: mvn assembly
| Maybe my maven's broken but I can't build all the way through
| assembly:assembly without manually adding the jars that are built to
| my local maven repo.
|
| So mvn assembly:assembly builds cloudtrace and accumulo-start jars,
| then fails
| If I add cloudtrace and accumulo-start to the local repo, then
| accumulo-core builds, then mvn fails
| I add accumulo-core to the local repo, mvn continues, then completes
| saying:
|
| [INFO] Reactor Summary:
| [INFO]
| [INFO] accumulo .......................................... SUCCESS
| [1:31.829s]
| [INFO] cloudtrace ........................................ SKIPPED
| [INFO] accumulo-start .................................... SKIPPED
| [INFO] accumulo-core ..................................... SKIPPED
| [INFO] accumulo-server ................................... SKIPPED
| [INFO] accumulo-examples ................................. SKIPPED
| [INFO]
| ------------------------------------------------------------------------
| [INFO] BUILD SUCCESS
| [INFO]
| ------------------------------------------------------------------------
|
|
| Should mvn assembly:assembly be installing completed jars into the
| local repo as it goes?
|
| Aaron
https://issues.apache.org/jira/browse/ACCUMULO-25
mvn assembly:assembly doesn't perform the action right and is deprecated. mvn assembly:single will assembly blindly without verifying functionality. Do a mvn package first and then mvn assembly(single or assembly should both work).
mvn assembly
Posted by Aaron Cordova <aa...@cordovas.org>.
Maybe my maven's broken but I can't build all the way through assembly:assembly without manually adding the jars that are built to my local maven repo.
So mvn assembly:assembly builds cloudtrace and accumulo-start jars, then fails
If I add cloudtrace and accumulo-start to the local repo, then accumulo-core builds, then mvn fails
I add accumulo-core to the local repo, mvn continues, then completes saying:
[INFO] Reactor Summary:
[INFO]
[INFO] accumulo .......................................... SUCCESS [1:31.829s]
[INFO] cloudtrace ........................................ SKIPPED
[INFO] accumulo-start .................................... SKIPPED
[INFO] accumulo-core ..................................... SKIPPED
[INFO] accumulo-server ................................... SKIPPED
[INFO] accumulo-examples ................................. SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
Should mvn assembly:assembly be installing completed jars into the local repo as it goes?
Aaron
Re: JIRA assignees
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Oct 17, 2011, at 12:03 PM, Billie J Rinaldi wrote:
> On Wednesday, October 12, 2011 1:35:55 PM, "Alan D. Cabrera" <li...@toolazydogs.com> wrote:
>> Subject: Re: JIRA assignees
>> On Oct 12, 2011, at 10:05 AM, Billie J Rinaldi wrote:
>>
>>> On Wednesday, October 12, 2011 12:49:04 PM, "Todd Lipcon"
>>> <to...@cloudera.com> wrote:
>>>> In other projects I'm involved in, the JIRA workflow is that, the
>>>> first time a new person uploads a patch, one of the committers will
>>>> add them to the contributors group in JIRA and assign that JIRA to
>>>> them. In the future, they are free to assign themselves any JIRAs
>>>> they
>>>> plan to work on.
>>>
>>> I am hoping to establish a process such as the one Todd describes.
>>> In addition to giving us a way to see what new developers (potential
>>> committers) have contributed, it may help give people a greater
>>> sense of responsibility for the things they are working on.
>>
>> If there's consensus on the project that this is the way to go I'm
>> happy to update the Accumulo Jira project.
>
> With +5 committers, I believe we have consensus on this. Please add jesse_yates to the accumulo-dev group on JIRA.
> Would it be possible to give JIRA ACCUMULO admins permission to add new people to that group, or is that ability restricted to mentors?
I've copied Hadoop's setup to Accumulo and added jesse_yates to the Contributors group.
Regards,
Alan
Re: JIRA assignees
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Oct 18, 2011, at 7:43 AM, Billie J Rinaldi wrote:
> On Monday, October 17, 2011 3:24:07 PM, "Alan D. Cabrera" <ad...@toolazydogs.com> wrote:
>> I'll see what I can dig up. Does anyone know what project Todd was
>> speaking of when he was discussing workflow alternatives?
>
> I suspect Todd was speaking of Hadoop or HBase.
Ok, I'll copy their setup to Accumulo today.
Regards,
Alan
Re: JIRA assignees
Posted by Billie J Rinaldi <bi...@ugov.gov>.
On Monday, October 17, 2011 3:24:07 PM, "Alan D. Cabrera" <ad...@toolazydogs.com> wrote:
> I'll see what I can dig up. Does anyone know what project Todd was
> speaking of when he was discussing workflow alternatives?
I suspect Todd was speaking of Hadoop or HBase.
Billie
Re: JIRA assignees
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
On Oct 17, 2011, at 12:03 PM, Billie J Rinaldi wrote:
> On Wednesday, October 12, 2011 1:35:55 PM, "Alan D. Cabrera" <li...@toolazydogs.com> wrote:
>> Subject: Re: JIRA assignees
>> On Oct 12, 2011, at 10:05 AM, Billie J Rinaldi wrote:
>>
>>> On Wednesday, October 12, 2011 12:49:04 PM, "Todd Lipcon"
>>> <to...@cloudera.com> wrote:
>>>> In other projects I'm involved in, the JIRA workflow is that, the
>>>> first time a new person uploads a patch, one of the committers will
>>>> add them to the contributors group in JIRA and assign that JIRA to
>>>> them. In the future, they are free to assign themselves any JIRAs
>>>> they
>>>> plan to work on.
>>>
>>> I am hoping to establish a process such as the one Todd describes.
>>> In addition to giving us a way to see what new developers (potential
>>> committers) have contributed, it may help give people a greater
>>> sense of responsibility for the things they are working on.
>>
>> If there's consensus on the project that this is the way to go I'm
>> happy to update the Accumulo Jira project.
>
> With +5 committers, I believe we have consensus on this. Please add jesse_yates to the accumulo-dev group on JIRA.
ok
> Would it be possible to give JIRA ACCUMULO admins permission to add new people to that group, or is that ability restricted to mentors?
I'll see what I can dig up. Does anyone know what project Todd was speaking of when he was discussing workflow alternatives?
Regards,
Alan
Re: JIRA assignees
Posted by Billie J Rinaldi <bi...@ugov.gov>.
On Wednesday, October 12, 2011 1:35:55 PM, "Alan D. Cabrera" <li...@toolazydogs.com> wrote:
> Subject: Re: JIRA assignees
> On Oct 12, 2011, at 10:05 AM, Billie J Rinaldi wrote:
>
> > On Wednesday, October 12, 2011 12:49:04 PM, "Todd Lipcon"
> > <to...@cloudera.com> wrote:
> >> In other projects I'm involved in, the JIRA workflow is that, the
> >> first time a new person uploads a patch, one of the committers will
> >> add them to the contributors group in JIRA and assign that JIRA to
> >> them. In the future, they are free to assign themselves any JIRAs
> >> they
> >> plan to work on.
> >
> > I am hoping to establish a process such as the one Todd describes.
> > In addition to giving us a way to see what new developers (potential
> > committers) have contributed, it may help give people a greater
> > sense of responsibility for the things they are working on.
>
> If there's consensus on the project that this is the way to go I'm
> happy to update the Accumulo Jira project.
With +5 committers, I believe we have consensus on this. Please add jesse_yates to the accumulo-dev group on JIRA.
Would it be possible to give JIRA ACCUMULO admins permission to add new people to that group, or is that ability restricted to mentors?
Thanks,
Billie
Re: JIRA assignees
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Oct 12, 2011, at 10:05 AM, Billie J Rinaldi wrote:
> On Wednesday, October 12, 2011 12:49:04 PM, "Todd Lipcon" <to...@cloudera.com> wrote:
>> In other projects I'm involved in, the JIRA workflow is that, the
>> first time a new person uploads a patch, one of the committers will
>> add them to the contributors group in JIRA and assign that JIRA to
>> them. In the future, they are free to assign themselves any JIRAs they
>> plan to work on.
>
> I am hoping to establish a process such as the one Todd describes. In addition to giving us a way to see what new developers (potential committers) have contributed, it may help give people a greater sense of responsibility for the things they are working on.
If there's consensus on the project that this is the way to go I'm happy to update the Accumulo Jira project.
Regards,
Alan
Re: JIRA assignees
Posted by Billie J Rinaldi <bi...@ugov.gov>.
On Wednesday, October 12, 2011 12:49:04 PM, "Todd Lipcon" <to...@cloudera.com> wrote:
> In other projects I'm involved in, the JIRA workflow is that, the
> first time a new person uploads a patch, one of the committers will
> add them to the contributors group in JIRA and assign that JIRA to
> them. In the future, they are free to assign themselves any JIRAs they
> plan to work on.
I am hoping to establish a process such as the one Todd describes. In addition to giving us a way to see what new developers (potential committers) have contributed, it may help give people a greater sense of responsibility for the things they are working on.
Billie
Re: JIRA assignees
Posted by Todd Lipcon <to...@cloudera.com>.
Standard ASF practice is that there are Committers, who have the
commit bit, and Contributors, who contribute code but do not have the
commit bit. Contributors rely on committers to review and commit their
code, and it's the committers' responsibility to do so in a reasonably
timely manner.
In other projects I'm involved in, the JIRA workflow is that, the
first time a new person uploads a patch, one of the committers will
add them to the contributors group in JIRA and assign that JIRA to
them. In the future, they are free to assign themselves any JIRAs they
plan to work on.
Of course if someone assigns a JIRA to themself and doesn't appear to
be making any progress, someone else can always ping them and ask to
take it over.
The above workflow is helpful when evaluating whether to make an
existing contributor into a committer - it's trivial to search JIRA
for tickets assigned to this person and resolved to see what they've
contributed so far.
-Todd
On Wed, Oct 12, 2011 at 9:25 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Oct 12, 2011, at 8:37 AM, Billie J Rinaldi wrote:
>
>> I propose adding Jesse Yates (jesse_yates) to the accumulo-developers group on JIRA so that he can assign tickets to himself. :)
>
> Sounds like an interesting idea. What do we hope to accomplish by letting a non-committer assign tickets to themselves?
>
>
> Regards,
> Alan
>
>
--
Todd Lipcon
Software Engineer, Cloudera
Re: JIRA assignees
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Oct 12, 2011, at 8:37 AM, Billie J Rinaldi wrote:
> I propose adding Jesse Yates (jesse_yates) to the accumulo-developers group on JIRA so that he can assign tickets to himself. :)
Sounds like an interesting idea. What do we hope to accomplish by letting a non-committer assign tickets to themselves?
Regards,
Alan
Re: JIRA assignees
Posted by Aaron Cordova <aa...@cordovas.org>.
+1
On Oct 12, 2011, at 11:37 AM, Billie J Rinaldi wrote:
> I propose adding Jesse Yates (jesse_yates) to the accumulo-developers group on JIRA so that he can assign tickets to himself. :)
>
> Billie
Re: JIRA assignees
Posted by Eric Newton <er...@gmail.com>.
+1
On Wed, Oct 12, 2011 at 11:37 AM, Billie J Rinaldi <
billie.j.rinaldi@ugov.gov> wrote:
> I propose adding Jesse Yates (jesse_yates) to the accumulo-developers group
> on JIRA so that he can assign tickets to himself. :)
>
> Billie
>