care of it, but I should have really just committed
the patch and marked the issue resolved. That is how we have been working so
far, and it has worked for us, so I don't think we need to change that.
Hadoop developers have a pretty elaborate JIRA workflow with a number of
specific states, b
svn annotates the jira logs, which is more than a comment, but still not
navigable
-Original Message-
From: Chris Hostetter [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 10:37 AM
To: java-dev@lucene.apache.org
Subject: RE: jira workflow
: Since that's not the cas
: Since that's not the case now, I'd suggest it's reasonable for a
: committer to commit w/o changing the assignee, only changing the state
: to resolved. Facilitates communication on issues that might arise later
: and helps gauge individual involvement.
I guess it depends on how we want to defi
Follow up on the workflow stuff:
With a larger group of people able to work at the Jira level, do we want
to have an approach to assignee? Otis was getting ready to commit a
patch I had shepherded through and assigned the issue to himself in the
process. This is what's always been done in the past
+1
Could we add a more generic signature to the unsubscribe signature on
the User mailing list, as well? Something like:
-
Please let us know what is important to you and vote on Lucene
issues at [URL]
To unsubscribe, e-mai
Everyone's busy, so I think what's needed is a reminder that 1) voting is
possible and 2) voting helps prioritize commits.
Is it possible to change the format/template of outgoing email when a new issue
is created?
If so, would it be possible to add a sentence about voting for issues to it?
Per
BTW, I added new fields to Lucene for "New" issues and "Patch
Available".
Cool. Shows up on the create and edit pages which seem to be the most
important.
It won't show up when creating a filter unless the filter already has
"Lucene Java" specified in the first entry because it's
: BTW, I added new fields to Lucene for "New" issues and "Patch
: Available". This is much lighter-weight than switching the workflow,
: although it doesn't seem to appear on all the screens yet. Perhaps it
: just takes a while...
Ah-HA! ... very cool.
FYI: if you click the "Configure your Iss
Yonik Seeley wrote:
On 10/18/06, Doug Cutting <[EMAIL PROTECTED]> wrote:
A quick glance at recent Jira activity suggests that
the following folks might be added to the lucene-developers group:
Doron Cohen
Karl Wettin
Michael McCandless
Michael Busch
Ning Li
+1 to these
Done.
On 10/18/06, Doug Cutting <[EMAIL PROTECTED]> wrote:
A quick glance at recent Jira activity suggests that
the following folks might be added to the lucene-developers group:
Doron Cohen
Karl Wettin
Michael McCandless
Michael Busch
Ning Li
+1 to these
Abdul Chaudhry
He open
Doug Cutting wrote:
Steven Parkes wrote:
I would like to be added to the Jira developer list.
I'm also happy to add other contributors, so that they can assign
themselves issues. A quick glance at recent Jira activity suggests that
the following folks might be added to the lucene-developers
Steven Parkes wrote:
I would like to be added to the Jira developer list.
Done.
Doug
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Steven Parkes wrote:
Just because you've gotten back doesn't mean the issue is gone.
No, just clarifying whose court the ball is in.
To make progress, an issue needs an advocate. If no one cares about it,
it will languish. If the advocate is not capable of doing the work
themselves
On 10/17/06, Doug Cutting <[EMAIL PROTECTED]> wrote:
So is Hadoop's workflow acceptable to all?
+1 for Hadoop's JIRA workflow.
As far as how that workflow should be used, I think we need a wiki page.
-Yonik
So is Hadoop's workflow acceptable to all?
+1
I can put the diagram up on Wiki if this is approved. Also, is there
a way to add links from JIRA?
-Grant
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands
r and
commenters are on the same page as to what, if anything, is
resolved/needs to be done.
But I'm thinking maybe there's nothing to be done here. It's not just
about the Jira workflow, it's also about the roles that dev participants
choose to take on. Nothing's stop
Steven Parkes wrote:
It wasn't really about having a list of needs clarification. It was more
about bounding open. I suppose it's my product development side showing.
Generally we tried not to leave issues open indefinitely, for fear of
not getting back to a customer. Perhaps there's nothing comp
The cases I'm thinking of are those issues, be they bug fixes or
critical functionality, that are submitted by non-contributors, people
that aren't going to do the coding themselves. I might be very
interested in some of those, probably the bugs in particular. I'm just
trying to figure out how I'll
A comment from a committer or contributor should be sufficient to
explain why something has not been committed, fixed or whatever,
and what action might next be needed. The scarcest resource is
committers. So we want to be able to focus their activities.
"Patch Available" is a call to
Steven Parkes wrote:
My main concern is that things get lost in lists that grow without
bound.
I've never been to concerned about the size of the open bug list. It
can be searched, if one wishes to find whether there's already an issue
before filing a new one. The lists I try to keep small
Looking at some currently closed issues, it looks like it should be
possible to add comments and links to closed issues. It provides the
comment button anyway. I haven't tried to push it. We could test on the
test SOLR issue.
Looking at the Jira docs, it looks like you can configure closed issues
Doug Cutting wrote:
I've attached an image of it to this message.
Well, that didn't work. Instead I added it to Hadoop's wiki:
http://wiki.apache.org/lucene-hadoop-data/attachments/JiraWorkflow/attachments/workflow.png
Doug
--
al Message-
From: Grant Ingersoll [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 17, 2006 11:20 AM
To: java-dev@lucene.apache.org
Subject: Re: jira workflow
Is it explicitly stated anywhere what the workflow is/should be?
-Grant
--
Grant Ingersoll wrote:
Is it explicitly stated anywhere what the workflow is/should be?
I can't see the workflow when I'm not logged in. I think you might have
to be a Jira administrator to view workflows. Some information about
them is up at:
http://www.atlassian.com/software/jira/docs/v
;s at least
some.)
+1
If there is agreement, I can gladly change Lucene Java to use
Hadoop's Jira workflow.
The other thing I was thinking of was the case where we say "if
you're
working on something, go ahead and submit a patch even if it's not
polished or you aren
Chris Hostetter wrote:
Perhaps we should have two new statuses: "rough patch available" and
"polished patch available" ?
The other thing i would like to see tracked better is the distinction
between issues that unit tests attached and issues that do not ... this is
somewhat orthoginal to patch a
Steven Parkes wrote:
Is there sufficient interest to consider this for Lucene Java? (I'd
write "any interest", but since I'm interested, there's at least some.)
+1
If there is agreement, I can gladly change Lucene Java to use Hadoop's
Jira workflow.
The oth
: "patch submitted" which, as it's used on Hadoop, seems to facilitate
: communication. State changes (open->patch submitted,
: patch-submitted->open) seem to help communications between contributors
: and reviewers. Looking at the Lucene Java Jira, sometimes "[patch]" is
: put at the beginning of
and swamped to manage
something like this myself currently. But I strongly support it!
Erik
On Oct 17, 2006, at 8:19 AM, Steven Parkes wrote:
As a member of a number of Lucene subprojects dev lists, I've been
comparing the way the Jira workflow is used on the different
pr
Erik
On Oct 17, 2006, at 8:19 AM, Steven Parkes wrote:
As a member of a number of Lucene subprojects dev lists, I've been
comparing the way the Jira workflow is used on the different projects.
In particular, I've been noting the difference between the workflows
that Lucene Java and Hado
As a member of a number of Lucene subprojects dev lists, I've been
comparing the way the Jira workflow is used on the different projects.
In particular, I've been noting the difference between the workflows
that Lucene Java and Hadoop use. Hadoop in particular has a state for
"
31 matches
Mail list logo
