Re: jira issues falling off the radar -- "Next" JIRA version

["David Smiley (@MITRE.org)" <DS...@mitre.org>]

I don't think "Next" is necessarily dangerous; if used then "3.2", shouldn't
exist until it's time to release. Having both is dangerous. But sure, I'm in
favor of removing "Next". A committer would have to adjudicate all issues
and substitute either 3.2 or 4.0.  Speaking of which, I think simply
assigning a fix-version for "3.2" implies that it will be for any future
release (including 4.0) and so I don't see there's a point in assigning both
of these fix-versions.  There are rare exceptions to this and I am aware of
course that our dual-development branches implies having to make two
commits.

RE v1.5, fortunately, most of the issues are already assigned a suitable
fix-version other than 1.5 so those can be ignored. Once the few remainder
are addressed, v1.5 can be deleted.
RE Next, Any issue with a resolution status of "Fixed" should be re-assigned
a suitable fix-version if it doesn't have any.  There are very few of these
two worry about. Those without a resolution status should probably just be
assigned to 3.2 -- so yes I agree that's what we should do.  Then "Next" can
be deleted.

~ David Smiley


Michael McCandless-2 wrote:
> 
> On Fri, Apr 29, 2011 at 12:12 AM, David Smiley (@MITRE.org)
> <DSMILEY@mitre.org> wrote:
> 
>> (Comments on SOLR-2191 between Mark & I were starting to get off-topic
>> with
>> respect to the issue so I am continuing the conversation here)
>>
>> A lot of JIRA issues seem to fall off the radar, IMO. I'm talking about
>> issues that have patches and are basically ready to go.  There are
>> multiple
>> ways to address this but at the moment I am going to just bring up one.
>> Looking at the versions in JIRA one can assign an issue to
>> https://issues.apache.org/jira/browse/SOLR#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel
>> I see the version named "Next", with this description: "Placeholder for
>> commiters to track issues that are not ready to commit, but seem close
>> enough to being ready to warrant focus before the next feature release".
>> This version and what it implies is a common pattern in use of JIRA that
>> I
>> too use for projects I manage for my employer. It appears that for the
>> 3.1
>> release, nobody looked through the issues assigned to "Next", and
>> consequently, some issues like SOLR-2191 were forgotten despite being
>> ready
>> to go.  Looking through the wiki I see information on how to do a release
>> http://wiki.apache.org/solr/HowToRelease and release suggestions but no
>> information on what to do in advance of a release.  I also don't see any
>> administrative tasks on managing the "Next" version in JIRA.  So I think
>> either the "Next" version should be used effectively, or if that isn't
>> going
>> to happen then delete this version.
> 
> I agree Next is dangerous!
> 
> It'd be nice if Jira could auto-magically treat Next as whatever
> release really is "next".  EG, say we all agree 3.2 is our next
> release, then ideally Jira would treat all Next issues as if they were
> marked with 3.2.
> 
> But... lacking that, maybe we really shouldn't use Next at all, and
> just use 3.2?  Having to step through these issues and move them to
> the next release on releasing is also healthy, ie, it's good that we
> see/review them, think about why we didn't get it done on the current
> release, etc.
> 
>> On a related note, I don't know what to make of the "1.5" version, nor
>> what
>> to make of issues marked as Closed for "Next".  Some house cleaning is in
>> order.
> 
> We should clean these up.  Should we just roll them over to 3.2?
> 
> Mike
> 
> http://blog.mikemccandless.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
> 

----- Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book--
View this message in context: http://lucene.472066.n3.nabble.com/Re-jira-issues-falling-off-the-radar-Next-JIRA-version-tp2886427p2886427.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: jira issues falling off the radar -- "Next" JIRA version

[Chris Hostetter <ho...@fucit.org>]

: and substitute either 3.2 or 4.0.  Speaking of which, I think simply
: assigning a fix-version for "3.2" implies that it will be for any future
: release (including 4.0) and so I don't see there's a point in assigning both
: of these fix-versions.  There are rare exceptions to this and I am aware of
: course that our dual-development branches implies having to make two
: commits.

No ... that's not really true at all:  A bug might only exist on the 3x 
branch, in which case saying the fix was commited for the 3.2 release 
doesn't say anything about 4x releases at all; A bug might exist in 3.1 
and 4.0 but require completley different patches to fix it;  Once 4.0 
comes out, it will be entirely possible for a feature to be commited to 4x 
and backported to 3x such that it's in release 4.6 and 3.10 but does not 
exist in 4.0-4.5; etc....

I think it's definitley important to track exactly what version on *every* 
branch an issue is commited in.


-Hoss

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org