lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <ser...@gmail.com>
Subject Re: Pruning down roadmap for 3.2
Date Mon, 23 May 2011 03:28:20 GMT
>
> my point is just that when bulk editing these things,
> we should just un-set instead of rolling forward
>

+1. Before 3.1 I reviewed the list of issues that were not updated since Jan
1st 2009, and closed most of them (those that looked like they're either
solved or not of interest anymore). Some issues that were updated post that
date were not commented on, or had a patch update or something, but their
update date attribute was affected by version changes and the like. So if we
unset the version flag going forward, it will be clearer (and easier) to
determine which issues are really old and can be closed.

: personally, when i set these versions on issues, i set versions
> : 3.x+4.0 usually to indicate that I think its applicable to both the
> : stable branch and trunk (versus 4.0-only indicating its not the kind
> : of thing that should be backported).
>
> that makes sense too -- personally I think we should be stricter about it
> ... we should only mark something as fix for 3.3 if we think (at the time
> we are reviewing/updating the issue) that we really shouldn't release 3.3
> w/o this fix/feature.
>

Actually both approaches make sense to me :). I personally set the version
flag of every issue I report, but I will try to avoid that, and set the flag
for issues I'm sure I'll have time to work on for the next release, or are
important enough for the next release. Otherwise, important issues will fall
between the cracks and forgotten (until one day my giant old-issues-sweeping
broom will get rid of them :)).

Shai

On Fri, May 20, 2011 at 10:27 PM, Chris Hostetter
<hossman_lucene@fucit.org>wrote:

> : personally, when i set these versions on issues, i set versions
> : 3.x+4.0 usually to indicate that I think its applicable to both the
> : stable branch and trunk (versus 4.0-only indicating its not the kind
> : of thing that should be backported).
>
> that makes sense too -- personally I think we should be stricter about it
> ... we should only mark something as fix for 3.3 if we think (at the time
> we are reviewing/updating the issue) that we really shouldn't release 3.3
> w/o this fix/feature.
>
> obviously things change ... one day we think something should definitely
> be in a release, two weeks later we might decide that it's too much work,
> or too complex to try and shoehorn in, and we conciously change it the
> version.
>
> I'm not suggesting that anyone change their current practice of how/when
> they choose what version to mark on a jira issue when they are reviewing a
> particular issue -- my point is just that when bulk editing these things,
> we should just un-set instead of rolling forward:  If some issues have
> fallen by the way-side to the point that we are bulk editing them out of
> blocking the current release, that's a pretty good indicator that they
> aren't a priority for the next release unless someone steps forward and
> deliberately says they should be.
>
>
> -Hoss
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Mime
View raw message