Re: Fix version

[Maximilian Michels <mx...@apache.org>]

Hi Greg,

I agree that we should encourage people to use the "fix version" field
more carefully. I think we need to agree on how we use "fix version".
How about going through the existing "fix version" tagged issues
instead of just removing the tag? I do think that the tagged issues
represent overall more pressing issues than the non-tagged.

Cheers,
Max

On Thu, Feb 25, 2016 at 10:21 AM, Robert Metzger <rm...@apache.org> wrote:
> Hi Greg,
>
> I agree with you that the "fix version" field for unresolved issues is
> probably used by issue creators to express their wish for fast resolution.
> I also saw some cases where issues were reopened.
>
> I agree with your suggestion to clear the "fix version" field once 1.0.0
> has been released.
>
> On Mon, Feb 22, 2016 at 4:43 PM, Greg Hogan <co...@greghogan.com> wrote:
>
>> Hi,
>>
>> With 1.0.0 imminent there are 112 tickets with a "fix version" of 1.0.0,
>> the earliest from 2014. From the ticket logs it looks like we typically
>> bump the fix version once the target release has passed. Would it be better
>> to wait to assign a fix version until achieving some combination of
>> severity, acceptance, and imminence?
>>
>> For example, a new feature might go unscheduled until a pull request is
>> available, whereas a blocker is by definition intended for the next
>> release.
>>
>> A corollary would be to unschedule all open / in progress / reopened
>> tickets once their "fix version" has been released. This would present a
>> clean slate for the next round of commits.
>>
>> Greg
>>

Re: Fix version

[Greg Hogan <co...@greghogan.com>]

Hi Max,

You are right, there is no need to unlabel old fix versions.

My thought was to treat the fix version like "inbox zero". There is already
an emphasis on closing blockers, but few bugs and fewer features are that
severe. Pull requests can be long lived and require a ready resolution.

Comparing the number of scheduled and unscheduled issues, I think this is
already the common practice.

Greg

On Tue, Mar 1, 2016 at 5:20 AM, Maximilian Michels <mx...@apache.org> wrote:

> Hi Greg,
>
> I agree that we should encourage people to use the "fix version" field
> more carefully. I think we need to agree on how we use "fix version".
> How about going through the existing "fix version" tagged issues
> instead of just removing the tag? I do think that the tagged issues
> represent overall more pressing issues than the non-tagged.
>
> Cheers,
> Max
>
> On Thu, Feb 25, 2016 at 10:21 AM, Robert Metzger <rm...@apache.org>
> wrote:
> > Hi Greg,
> >
> > I agree with you that the "fix version" field for unresolved issues is
> > probably used by issue creators to express their wish for fast
> resolution.
> > I also saw some cases where issues were reopened.
> >
> > I agree with your suggestion to clear the "fix version" field once 1.0.0
> > has been released.
> >
> > On Mon, Feb 22, 2016 at 4:43 PM, Greg Hogan <co...@greghogan.com> wrote:
> >
> >> Hi,
> >>
> >> With 1.0.0 imminent there are 112 tickets with a "fix version" of 1.0.0,
> >> the earliest from 2014. From the ticket logs it looks like we typically
> >> bump the fix version once the target release has passed. Would it be
> better
> >> to wait to assign a fix version until achieving some combination of
> >> severity, acceptance, and imminence?
> >>
> >> For example, a new feature might go unscheduled until a pull request is
> >> available, whereas a blocker is by definition intended for the next
> >> release.
> >>
> >> A corollary would be to unschedule all open / in progress / reopened
> >> tickets once their "fix version" has been released. This would present a
> >> clean slate for the next round of commits.
> >>
> >> Greg
> >>
>