> Disclaimer: I'm only just joining this community so I absolutely want
> those of you with more experience developing/fixing bugs in Hudson and
> elsewhere to chime in on this conversation.  What I want to do is try
> to come to some consensus on how Hudson bugs are to be identified,
> disambiguated, prioritized, and ultimately, scheduled (more or less)
> for a release.  This is part of what I hope will be a larger overall
> effort to bring the Technical Debt I've observed since diving into the
> source code into check.

> As of right now there are 1853 open bugs in Hudson, of which the
> average age is just under a year at 359 days.  Some users, myself
> included, have been getting discouraged with cycle time on bugs,
> particularly when the Continuous Integration server is supposed to be
> the one thing you can most rely on.  When teams make their CI system
> the heart and soul of their day-to-day development, testing,
> configuration management, and release processes, they need to able to
> rely on it.  If any tool can be categorized as mission-critical, it's
> the CI system.

> Here is what I am proposing:

> 1. Users submit bug reports at issues.hudson-ci.org like they always
> have.
> 2. At some frequency (daily?, weekly?, as they pop up?), developers go
> out and perform the following procedure:
>    a. Pick the oldest non-triaged bug.
>    b. Check whether or not the bug is a duplicate with another bug.
> This will likely require aid from the more seasoned Hudson
> contributors.
>      i. If a duplicate exists but it has been resolved, I would
> recommend not reopening it, but just linking the two issues together
> so the person who goes to fix the current incantation of the bug can
> use it as a resource if necessary.  Continue to the next step.
>      ii. If a duplicate exists, but is still open, link the two issues
> for future reference, Close the new one as Duplicate, and redirect all
> users to the older one.  Go back to 2.a.
>      iii. If no duplicate exists, continue.
>    c. Is the bug reproducible in the most recent version of Hudson?  I
> don't think it's worth verifying the bug in their reported version
> since they'll ultimately have to upgrade to get the bug fix anyway, so
> we might as well work towards the shortest path.
>      i. If the bug is not reproducible in the latest version, close as
> Cannot Reproduce and inform the user(s) that it appears to have been
> fixed in version X, and go back to 2.a.
>      ii. If the bug appears to still exist in the current version, note
> which version it was verified in and continue.
>    d. Gather as much information as possible from users.  What version
> of the system is this bug occurring in?  What environment are they
> using?  Did this error start occurring after an upgrade?  What version
> did they upgrade to/from?  Are they able to work around the issue or
> has it stopped their usage of Hudson in its tracks?  Ask any questions
> that might help isolate the commit that introduced the bug, and help
> other contributors make the best possible prioritization decisions.
>    e. Set the priority of the issue based on some criteria.  I need
> some suggestions from the community about what would be the best
> criteria.  I would actually suggest trying to get an open source
> license of GreenHopper from Atlassian.  Their ranking functionality
> within GreenHopper works very well for this purpose since you rank
> items relative to each other, not just with priorities.
>    f. Mark the bug as triaged and if there are still non-triaged issues
> go back to 2.a.
> 3. Contributors grab the highest (relative) priority bug to fix and
> get to it.  Votes should also contribute to deciding which bug to fix
> since that information is real-time and earlier triage information can
> become more and more out of date.

> I'm extremely interested in getting some feedback about these
> procedures.  I'm sure I missed some opportunity in this process or
> overlooked something, so please let me know what you think.  I hope
> that by unifying these procedures across the community we can work
> towards reducing that "average age" stat to below a month or two.  I'm
> not saying it will be easy, but I'm certain this community can do it.

> Thanks,
> Matt

> In my experience most of the very old bugs fall into one of these
> scenarios:

> - happen only under very rare circumstances. Developer cannot reproduce it
> easily
> - are not reproducible because reporter didn't provide enough details (and
> often doesn't respond to questions about details)
> - fix would break some other functionality and/or would mean serious
> re-engineering of some parts of Hudson
> - are related to a plugin which is not (really) maintained any more

> And then there are of course the 'normal' bugs, but I think they are the
> minority.

> This is just my very subjective feeling why there are so many old bugs.

> What we can do easily IMHO:

> - search actively for duplicates and close them

> - ask reporters about more details
>  - if bug is old and reporter doesn't respond in a timely manner, then
> close it as 'not reproducible'

> - And what I really like to see, is a prominent message for reporters of
> new bugs to provide as much details as possible ALREADY WHEN they enter the
> bug initially.
> So much time is wasted by asking for details and waiting for the answer.
> Your list in 2d is very good. I'd like to add console output and logfile to
> it.

> Am 30.01.2011 18:13, schrieb mlb5000:

>  Hi All,

>> Disclaimer: I'm only just joining this community so I absolutely want
>> those of you with more experience developing/fixing bugs in Hudson and
>> elsewhere to chime in on this conversation.  What I want to do is try
>> to come to some consensus on how Hudson bugs are to be identified,
>> disambiguated, prioritized, and ultimately, scheduled (more or less)
>> for a release.  This is part of what I hope will be a larger overall
>> effort to bring the Technical Debt I've observed since diving into the
>> source code into check.

>> As of right now there are 1853 open bugs in Hudson, of which the
>> average age is just under a year at 359 days.  Some users, myself
>> included, have been getting discouraged with cycle time on bugs,
>> particularly when the Continuous Integration server is supposed to be
>> the one thing you can most rely on.  When teams make their CI system
>> the heart and soul of their day-to-day development, testing,
>> configuration management, and release processes, they need to able to
>> rely on it.  If any tool can be categorized as mission-critical, it's
>> the CI system.

>> Here is what I am proposing:

>> 1. Users submit bug reports at issues.hudson-ci.org like they always
>> have.
>> 2. At some frequency (daily?, weekly?, as they pop up?), developers go
>> out and perform the following procedure:
>>   a. Pick the oldest non-triaged bug.
>>   b. Check whether or not the bug is a duplicate with another bug.
>> This will likely require aid from the more seasoned Hudson
>> contributors.
>>     i. If a duplicate exists but it has been resolved, I would
>> recommend not reopening it, but just linking the two issues together
>> so the person who goes to fix the current incantation of the bug can
>> use it as a resource if necessary.  Continue to the next step.
>>     ii. If a duplicate exists, but is still open, link the two issues
>> for future reference, Close the new one as Duplicate, and redirect all
>> users to the older one.  Go back to 2.a.
>>     iii. If no duplicate exists, continue.
>>   c. Is the bug reproducible in the most recent version of Hudson?  I
>> don't think it's worth verifying the bug in their reported version
>> since they'll ultimately have to upgrade to get the bug fix anyway, so
>> we might as well work towards the shortest path.
>>     i. If the bug is not reproducible in the latest version, close as
>> Cannot Reproduce and inform the user(s) that it appears to have been
>> fixed in version X, and go back to 2.a.
>>     ii. If the bug appears to still exist in the current version, note
>> which version it was verified in and continue.
>>   d. Gather as much information as possible from users.  What version
>> of the system is this bug occurring in?  What environment are they
>> using?  Did this error start occurring after an upgrade?  What version
>> did they upgrade to/from?  Are they able to work around the issue or
>> has it stopped their usage of Hudson in its tracks?  Ask any questions
>> that might help isolate the commit that introduced the bug, and help
>> other contributors make the best possible prioritization decisions.
>>   e. Set the priority of the issue based on some criteria.  I need
>> some suggestions from the community about what would be the best
>> criteria.  I would actually suggest trying to get an open source
>> license of GreenHopper from Atlassian.  Their ranking functionality
>> within GreenHopper works very well for this purpose since you rank
>> items relative to each other, not just with priorities.
>>   f. Mark the bug as triaged and if there are still non-triaged issues
>> go back to 2.a.
>> 3. Contributors grab the highest (relative) priority bug to fix and
>> get to it.  Votes should also contribute to deciding which bug to fix
>> since that information is real-time and earlier triage information can
>> become more and more out of date.

>> I'm extremely interested in getting some feedback about these
>> procedures.  I'm sure I missed some opportunity in this process or
>> overlooked something, so please let me know what you think.  I hope
>> that by unifying these procedures across the community we can work
>> towards reducing that "average age" stat to below a month or two.  I'm
>> not saying it will be easy, but I'm certain this community can do it.

>> Thanks,
>> Matt

> Vivien

> On Sun, Jan 30, 2011 at 8:25 PM, Christoph Kutzinski <ku...@gmx.de> wrote:

>> I think this is a very nice proposal.
>> Some comments:

>> In my experience most of the very old bugs fall into one of these
>> scenarios:

>> - happen only under very rare circumstances. Developer cannot reproduce it
>> easily
>> - are not reproducible because reporter didn't provide enough details (and
>> often doesn't respond to questions about details)
>> - fix would break some other functionality and/or would mean serious
>> re-engineering of some parts of Hudson
>> - are related to a plugin which is not (really) maintained any more

>> And then there are of course the 'normal' bugs, but I think they are the
>> minority.

>> This is just my very subjective feeling why there are so many old bugs.

>> What we can do easily IMHO:

>> - search actively for duplicates and close them

>> - ask reporters about more details
>>  - if bug is old and reporter doesn't respond in a timely manner, then
>> close it as 'not reproducible'

>> - And what I really like to see, is a prominent message for reporters of
>> new bugs to provide as much details as possible ALREADY WHEN they enter the
>> bug initially.
>> So much time is wasted by asking for details and waiting for the answer.
>> Your list in 2d is very good. I'd like to add console output and logfile
>> to it.

>> Am 30.01.2011 18:13, schrieb mlb5000:

>>  Hi All,

>>> Disclaimer: I'm only just joining this community so I absolutely want
>>> those of you with more experience developing/fixing bugs in Hudson and
>>> elsewhere to chime in on this conversation.  What I want to do is try
>>> to come to some consensus on how Hudson bugs are to be identified,
>>> disambiguated, prioritized, and ultimately, scheduled (more or less)
>>> for a release.  This is part of what I hope will be a larger overall
>>> effort to bring the Technical Debt I've observed since diving into the
>>> source code into check.

>>> As of right now there are 1853 open bugs in Hudson, of which the
>>> average age is just under a year at 359 days.  Some users, myself
>>> included, have been getting discouraged with cycle time on bugs,
>>> particularly when the Continuous Integration server is supposed to be
>>> the one thing you can most rely on.  When teams make their CI system
>>> the heart and soul of their day-to-day development, testing,
>>> configuration management, and release processes, they need to able to
>>> rely on it.  If any tool can be categorized as mission-critical, it's
>>> the CI system.

>>> Here is what I am proposing:

>>> 1. Users submit bug reports at issues.hudson-ci.org like they always
>>> have.
>>> 2. At some frequency (daily?, weekly?, as they pop up?), developers go
>>> out and perform the following procedure:
>>>   a. Pick the oldest non-triaged bug.
>>>   b. Check whether or not the bug is a duplicate with another bug.
>>> This will likely require aid from the more seasoned Hudson
>>> contributors.
>>>     i. If a duplicate exists but it has been resolved, I would
>>> recommend not reopening it, but just linking the two issues together
>>> so the person who goes to fix the current incantation of the bug can
>>> use it as a resource if necessary.  Continue to the next step.
>>>     ii. If a duplicate exists, but is still open, link the two issues
>>> for future reference, Close the new one as Duplicate, and redirect all
>>> users to the older one.  Go back to 2.a.
>>>     iii. If no duplicate exists, continue.
>>>   c. Is the bug reproducible in the most recent version of Hudson?  I
>>> don't think it's worth verifying the bug in their reported version
>>> since they'll ultimately have to upgrade to get the bug fix anyway, so
>>> we might as well work towards the shortest path.
>>>     i. If the bug is not reproducible in the latest version, close as
>>> Cannot Reproduce and inform the user(s) that it appears to have been
>>> fixed in version X, and go back to 2.a.
>>>     ii. If the bug appears to still exist in the current version, note
>>> which version it was verified in and continue.
>>>   d. Gather as much information as possible from users.  What version
>>> of the system is this bug occurring in?  What environment are they
>>> using?  Did this error start occurring after an upgrade?  What version
>>> did they upgrade to/from?  Are they able to work around the issue or
>>> has it stopped their usage of Hudson in its tracks?  Ask any questions
>>> that might help isolate the commit that introduced the bug, and help
>>> other contributors make the best possible prioritization decisions.
>>>   e. Set the priority of the issue based on some criteria.  I need
>>> some suggestions from the community about what would be the best
>>> criteria.  I would actually suggest trying to get an open source
>>> license of GreenHopper from Atlassian.  Their ranking functionality
>>> within GreenHopper works very well for this purpose since you rank
>>> items relative to each other, not just with priorities.
>>>   f. Mark the bug as triaged and if there are still non-triaged issues
>>> go back to 2.a.
>>> 3. Contributors grab the highest (relative) priority bug to fix and
>>> get to it.  Votes should also contribute to deciding which bug to fix
>>> since that information is real-time and earlier triage information can
>>> become more and more out of date.

>>> I'm extremely interested in getting some feedback about these
>>> procedures.  I'm sure I missed some opportunity in this process or
>>> overlooked something, so please let me know what you think.  I hope
>>> that by unifying these procedures across the community we can work
>>> towards reducing that "average age" stat to below a month or two.  I'm
>>> not saying it will be easy, but I'm certain this community can do it.

>>> Thanks,
>>> Matt

> Cheers

> Arnaud

> On Sun, Jan 30, 2011 at 8:56 PM, vtintillier <

> vtintillier.private...@gmail.com> wrote:
> > I am also really in favor of introducing a backlog with priorities. For the
> > moment, we just have no ideas when things will be fixed (or not). The
> > Greenhoper plugin is easy to use in Jira.

> > Vivien

> > On Sun, Jan 30, 2011 at 8:25 PM, Christoph Kutzinski <ku...@gmx.de> wrote:

> >> I think this is a very nice proposal.
> >> Some comments:

> >> In my experience most of the very old bugs fall into one of these
> >> scenarios:

> >> - happen only under very rare circumstances. Developer cannot reproduce it
> >> easily
> >> - are not reproducible because reporter didn't provide enough details (and
> >> often doesn't respond to questions about details)
> >> - fix would break some other functionality and/or would mean serious
> >> re-engineering of some parts of Hudson
> >> - are related to a plugin which is not (really) maintained any more

> >> And then there are of course the 'normal' bugs, but I think they are the
> >> minority.

> >> This is just my very subjective feeling why there are so many old bugs.

> >> What we can do easily IMHO:

> >> - search actively for duplicates and close them

> >> - ask reporters about more details
> >>  - if bug is old and reporter doesn't respond in a timely manner, then
> >> close it as 'not reproducible'

> >> - And what I really like to see, is a prominent message for reporters of
> >> new bugs to provide as much details as possible ALREADY WHEN they enter the
> >> bug initially.
> >> So much time is wasted by asking for details and waiting for the answer.
> >> Your list in 2d is very good. I'd like to add console output and logfile
> >> to it.

> >> Am 30.01.2011 18:13, schrieb mlb5000:

> >>  Hi All,

> >>> Disclaimer: I'm only just joining this community so I absolutely want
> >>> those of you with more experience developing/fixing bugs in Hudson and
> >>> elsewhere to chime in on this conversation.  What I want to do is try
> >>> to come to some consensus on how Hudson bugs are to be identified,
> >>> disambiguated, prioritized, and ultimately, scheduled (more or less)
> >>> for a release.  This is part of what I hope will be a larger overall
> >>> effort to bring the Technical Debt I've observed since diving into the
> >>> source code into check.

> >>> As of right now there are 1853 open bugs in Hudson, of which the
> >>> average age is just under a year at 359 days.  Some users, myself
> >>> included, have been getting discouraged with cycle time on bugs,
> >>> particularly when the Continuous Integration server is supposed to be
> >>> the one thing you can most rely on.  When teams make their CI system
> >>> the heart and soul of their day-to-day development, testing,
> >>> configuration management, and release processes, they need to able to
> >>> rely on it.  If any tool can be categorized as mission-critical, it's
> >>> the CI system.

> >>> Here is what I am proposing:

> >>> 1. Users submit bug reports at issues.hudson-ci.org like they always
> >>> have.
> >>> 2. At some frequency (daily?, weekly?, as they pop up?), developers go
> >>> out and perform the following procedure:
> >>>   a. Pick the oldest non-triaged bug.
> >>>   b. Check whether or not the bug is a duplicate with another bug.
> >>> This will likely require aid from the more seasoned Hudson
> >>> contributors.
> >>>     i. If a duplicate exists but it has been resolved, I would
> >>> recommend not reopening it, but just linking the two issues together
> >>> so the person who goes to fix the current incantation of the bug can
> >>> use it as a resource if necessary.  Continue to the next step.
> >>>     ii. If a duplicate exists, but is still open, link the two issues
> >>> for future reference, Close the new one as Duplicate, and redirect all
> >>> users to the older one.  Go back to 2.a.
> >>>     iii. If no duplicate exists, continue.
> >>>   c. Is the bug reproducible in the most recent version of Hudson?  I
> >>> don't think it's worth verifying the bug in their reported version
> >>> since they'll ultimately have to upgrade to get the bug fix anyway, so
> >>> we might as well work towards the shortest path.
> >>>     i. If the bug is not reproducible in the latest version, close as
> >>> Cannot Reproduce and inform the user(s) that it appears to have been
> >>> fixed in version X, and go back to 2.a.
> >>>     ii. If the bug appears to still exist in the current version, note
> >>> which version it was verified in and continue.
> >>>   d. Gather as much information as possible from users.  What version
> >>> of the system is this bug occurring in?  What environment are they
> >>> using?  Did this error start occurring after an upgrade?  What version
> >>> did they upgrade to/from?  Are they able to work around the issue or
> >>> has it stopped their usage of Hudson in its tracks?  Ask any questions
> >>> that might help isolate the commit that introduced the bug, and help
> >>> other contributors make the best possible prioritization decisions.
> >>>   e. Set the priority of the issue based on some criteria.  I need
> >>> some suggestions from the community about what would be the best
> >>> criteria.  I would actually suggest trying to get an open source
> >>> license of GreenHopper from Atlassian.  Their ranking functionality
> >>> within GreenHopper works very well for this purpose since you rank
> >>> items relative to each other, not just with priorities.
> >>>   f. Mark the bug as triaged and if there are still non-triaged issues
> >>> go back to 2.a.
> >>> 3. Contributors grab the highest (relative) priority bug to fix and
> >>> get to it.  Votes should also contribute to deciding which bug to fix
> >>> since that information is real-time and earlier triage information can
> >>> become more and more out of date.

> >>> I'm extremely interested in getting some feedback about these
> >>> procedures.  I'm sure I missed some opportunity in this process or
> >>> overlooked something, so please let me know what you think.  I hope
> >>> that by unifying these procedures across the community we can work
> >>> towards reducing that "average age" stat to below a month or two.  I'm
> >>> not saying it will be easy, but I'm certain this community can do it.

> >>> Thanks,
> >>> Matt

> On Jan 30, 3:49 pm, Arnaud Héritier <arnaud.herit...@exoplatform.com>
> wrote:
> > For that we should try to improve our Jira usage and especially using
> > versions (affect vs fix for).
> > To have this working we need to split the big jira into small pieces (one
> > per plugin + 1 for core).

> > Cheers

> > Arnaud

> > On Sun, Jan 30, 2011 at 8:56 PM, vtintillier <

> > vtintillier.private...@gmail.com> wrote:
> > > I am also really in favor of introducing a backlog with priorities. For
> the
> > > moment, we just have no ideas when things will be fixed (or not). The
> > > Greenhoper plugin is easy to use in Jira.

> > > Vivien

> > > On Sun, Jan 30, 2011 at 8:25 PM, Christoph Kutzinski <ku...@gmx.de>
> wrote:

> > >> I think this is a very nice proposal.
> > >> Some comments:

> > >> In my experience most of the very old bugs fall into one of these
> > >> scenarios:

> > >> - happen only under very rare circumstances. Developer cannot
> reproduce it
> > >> easily
> > >> - are not reproducible because reporter didn't provide enough details
> (and
> > >> often doesn't respond to questions about details)
> > >> - fix would break some other functionality and/or would mean serious
> > >> re-engineering of some parts of Hudson
> > >> - are related to a plugin which is not (really) maintained any more

> > >> And then there are of course the 'normal' bugs, but I think they are
> the
> > >> minority.

> > >> This is just my very subjective feeling why there are so many old
> bugs.

> > >> What we can do easily IMHO:

> > >> - search actively for duplicates and close them

> > >> - ask reporters about more details
> > >>  - if bug is old and reporter doesn't respond in a timely manner, then
> > >> close it as 'not reproducible'

> > >> - And what I really like to see, is a prominent message for reporters
> of
> > >> new bugs to provide as much details as possible ALREADY WHEN they
> enter the
> > >> bug initially.
> > >> So much time is wasted by asking for details and waiting for the
> answer.
> > >> Your list in 2d is very good. I'd like to add console output and
> logfile
> > >> to it.

> > >> Am 30.01.2011 18:13, schrieb mlb5000:

> > >>  Hi All,

> > >>> Disclaimer: I'm only just joining this community so I absolutely want
> > >>> those of you with more experience developing/fixing bugs in Hudson
> and
> > >>> elsewhere to chime in on this conversation.  What I want to do is try
> > >>> to come to some consensus on how Hudson bugs are to be identified,
> > >>> disambiguated, prioritized, and ultimately, scheduled (more or less)
> > >>> for a release.  This is part of what I hope will be a larger overall
> > >>> effort to bring the Technical Debt I've observed since diving into
> the
> > >>> source code into check.

> > >>> As of right now there are 1853 open bugs in Hudson, of which the
> > >>> average age is just under a year at 359 days.  Some users, myself
> > >>> included, have been getting discouraged with cycle time on bugs,
> > >>> particularly when the Continuous Integration server is supposed to be
> > >>> the one thing you can most rely on.  When teams make their CI system
> > >>> the heart and soul of their day-to-day development, testing,
> > >>> configuration management, and release processes, they need to able to
> > >>> rely on it.  If any tool can be categorized as mission-critical, it's
> > >>> the CI system.

> > >>> Here is what I am proposing:

> > >>> 1. Users submit bug reports at issues.hudson-ci.org like they always
> > >>> have.
> > >>> 2. At some frequency (daily?, weekly?, as they pop up?), developers
> go
> > >>> out and perform the following procedure:
> > >>>   a. Pick the oldest non-triaged bug.
> > >>>   b. Check whether or not the bug is a duplicate with another bug.
> > >>> This will likely require aid from the more seasoned Hudson
> > >>> contributors.
> > >>>     i. If a duplicate exists but it has been resolved, I would
> > >>> recommend not reopening it, but just linking the two issues together
> > >>> so the person who goes to fix the current incantation of the bug can
> > >>> use it as a resource if necessary.  Continue to the next step.
> > >>>     ii. If a duplicate exists, but is still open, link the two issues
> > >>> for future reference, Close the new one as Duplicate, and redirect
> all
> > >>> users to the older one.  Go back to 2.a.
> > >>>     iii. If no duplicate exists, continue.
> > >>>   c. Is the bug reproducible in the most recent version of Hudson?  I
> > >>> don't think it's worth verifying the bug in their reported version
> > >>> since they'll ultimately have to upgrade to get the bug fix anyway,
> so
> > >>> we might as well work towards the shortest path.
> > >>>     i. If the bug is not reproducible in the latest version, close as
> > >>> Cannot Reproduce and inform the user(s) that it appears to have been
> > >>> fixed in version X, and go back to 2.a.
> > >>>     ii. If the bug appears to still exist in the current version,
> note
> > >>> which version it was verified in and continue.
> > >>>   d. Gather as much information as possible from users.  What version
> > >>> of the system is this bug occurring in?  What environment are they
> > >>> using?  Did this error start occurring after an upgrade?  What
> version
> > >>> did they upgrade to/from?  Are they able to work around the issue or
> > >>> has it stopped their usage of Hudson in its tracks?  Ask any
> questions
> > >>> that might help isolate the commit that introduced the bug, and help
> > >>> other contributors make the best possible prioritization decisions.
> > >>>   e. Set the priority of the issue based on some criteria.  I need
> > >>> some suggestions from the community about what would be the best
> > >>> criteria.  I would actually suggest trying to get an open source
> > >>> license of GreenHopper from Atlassian.  Their ranking functionality
> > >>> within GreenHopper works very well for this purpose since you rank
> > >>> items relative to each other, not just with priorities.
> > >>>   f. Mark the bug as triaged and if there are still non-triaged
> issues
> > >>> go back to 2.a.
> > >>> 3. Contributors grab the highest (relative) priority bug to fix and
> > >>> get to it.  Votes should also contribute to deciding which bug to fix
> > >>> since that information is real-time and earlier triage information
> can
> > >>> become more and more out of date.

> > >>> I'm extremely interested in getting some feedback about these
> > >>> procedures.  I'm sure I missed some opportunity in this process or
> > >>> overlooked something, so please let me know what you think.  I hope
> > >>> that by unifying these procedures across the community we can work
> > >>> towards reducing that "average age" stat to below a month or two.
>  I'm
> > >>> not saying it will be easy, but I'm certain this community can do it.

> > >>> Thanks,
> > >>> Matt

> In my experience most of the very old bugs fall into one of these scenarios:

> - happen only under very rare circumstances. Developer cannot reproduce
> it easily
> - are not reproducible because reporter didn't provide enough details
> (and often doesn't respond to questions about details)
> - fix would break some other functionality and/or would mean serious
> re-engineering of some parts of Hudson
> - are related to a plugin which is not (really) maintained any more

> And then there are of course the 'normal' bugs, but I think they are the
> minority.

> This is just my very subjective feeling why there are so many old bugs.

> What we can do easily IMHO:

> - search actively for duplicates and close them

> - ask reporters about more details
>    - if bug is old and reporter doesn't respond in a timely manner, then
> close it as 'not reproducible'

> - And what I really like to see, is a prominent message for reporters of
> new bugs to provide as much details as possible ALREADY WHEN they enter
> the bug initially.
> So much time is wasted by asking for details and waiting for the answer.
> Your list in 2d is very good. I'd like to add console output and logfile
> to it.

> Am 30.01.2011 18:13, schrieb mlb5000:

> > Hi All,

> > Disclaimer: I'm only just joining this community so I absolutely want
> > those of you with more experience developing/fixing bugs in Hudson and
> > elsewhere to chime in on this conversation.  What I want to do is try
> > to come to some consensus on how Hudson bugs are to be identified,
> > disambiguated, prioritized, and ultimately, scheduled (more or less)
> > for a release.  This is part of what I hope will be a larger overall
> > effort to bring the Technical Debt I've observed since diving into the
> > source code into check.

> > As of right now there are 1853 open bugs in Hudson, of which the
> > average age is just under a year at 359 days.  Some users, myself
> > included, have been getting discouraged with cycle time on bugs,
> > particularly when the Continuous Integration server is supposed to be
> > the one thing you can most rely on.  When teams make their CI system
> > the heart and soul of their day-to-day development, testing,
> > configuration management, and release processes, they need to able to
> > rely on it.  If any tool can be categorized as mission-critical, it's
> > the CI system.

> > Here is what I am proposing:

> > 1. Users submit bug reports at issues.hudson-ci.org like they always
> > have.
> > 2. At some frequency (daily?, weekly?, as they pop up?), developers go
> > out and perform the following procedure:
> >    a. Pick the oldest non-triaged bug.
> >    b. Check whether or not the bug is a duplicate with another bug.
> > This will likely require aid from the more seasoned Hudson
> > contributors.
> >      i. If a duplicate exists but it has been resolved, I would
> > recommend not reopening it, but just linking the two issues together
> > so the person who goes to fix the current incantation of the bug can
> > use it as a resource if necessary.  Continue to the next step.
> >      ii. If a duplicate exists, but is still open, link the two issues
> > for future reference, Close the new one as Duplicate, and redirect all
> > users to the older one.  Go back to 2.a.
> >      iii. If no duplicate exists, continue.
> >    c. Is the bug reproducible in the most recent version of Hudson?  I
> > don't think it's worth verifying the bug in their reported version
> > since they'll ultimately have to upgrade to get the bug fix anyway, so
> > we might as well work towards the shortest path.
> >      i. If the bug is not reproducible in the latest version, close as
> > Cannot Reproduce and inform the user(s) that it appears to have been
> > fixed in version X, and go back to 2.a.
> >      ii. If the bug appears to still exist in the current version, note
> > which version it was verified in and continue.
> >    d. Gather as much information as possible from users.  What version
> > of the system is this bug occurring in?  What environment are they
> > using?  Did this error start occurring after an upgrade?  What version
> > did they upgrade to/from?  Are they able to work around the issue or
> > has it stopped their usage of Hudson in its tracks?  Ask any questions
> > that might help isolate the commit that introduced the bug, and help
> > other contributors make the best possible prioritization decisions.
> >    e. Set the priority of the issue based on some criteria.  I need
> > some suggestions from the community about what would be the best
> > criteria.  I would actually suggest trying to get an open source
> > license of GreenHopper from Atlassian.  Their ranking functionality
> > within GreenHopper works very well for this purpose since you rank
> > items relative to each other, not just with priorities.
> >    f. Mark the bug as triaged and if there are still non-triaged issues
> > go back to 2.a.
> > 3. Contributors grab the highest (relative) priority bug to fix and
> > get to it.  Votes should also contribute to deciding which bug to fix
> > since that information is real-time and earlier triage information can
> > become more and more out of date.

> > I'm extremely interested in getting some feedback about these
> > procedures.  I'm sure I missed some opportunity in this process or
> > overlooked something, so please let me know what you think.  I hope
> > that by unifying these procedures across the community we can work
> > towards reducing that "average age" stat to below a month or two.  I'm
> > not saying it will be easy, but I'm certain this community can do it.

> > Thanks,
> > Matt

> On Mon, Jan 31, 2011 at 2:32 AM, mlb5000 <baker.mat...@gmail.com> wrote:
> > @Arnaud, I completely agree that each Hudson plugin should receive its
> > own "Project" in the Hudson Jira instance.  It's weird that they're
> > split into components, but maybe there's a reason for it?

> > On Jan 30, 3:49 pm, Arnaud Héritier <arnaud.herit...@exoplatform.com>
> > wrote:
> > > For that we should try to improve our Jira usage and especially using
> > > versions (affect vs fix for).
> > > To have this working we need to split the big jira into small pieces (one
> > > per plugin + 1 for core).

> > > Cheers

> > > Arnaud

> > > On Sun, Jan 30, 2011 at 8:56 PM, vtintillier <

> > > vtintillier.private...@gmail.com> wrote:
> > > > I am also really in favor of introducing a backlog with priorities. For
> > the
> > > > moment, we just have no ideas when things will be fixed (or not). The
> > > > Greenhoper plugin is easy to use in Jira.

> > > > Vivien

> > > > On Sun, Jan 30, 2011 at 8:25 PM, Christoph Kutzinski <ku...@gmx.de>
> > wrote:

> > > >> I think this is a very nice proposal.
> > > >> Some comments:

> > > >> In my experience most of the very old bugs fall into one of these
> > > >> scenarios:

> > > >> - happen only under very rare circumstances. Developer cannot
> > reproduce it
> > > >> easily
> > > >> - are not reproducible because reporter didn't provide enough details
> > (and
> > > >> often doesn't respond to questions about details)
> > > >> - fix would break some other functionality and/or would mean serious
> > > >> re-engineering of some parts of Hudson
> > > >> - are related to a plugin which is not (really) maintained any more

> > > >> And then there are of course the 'normal' bugs, but I think they are
> > the
> > > >> minority.

> > > >> This is just my very subjective feeling why there are so many old
> > bugs.

> > > >> What we can do easily IMHO:

> > > >> - search actively for duplicates and close them

> > > >> - ask reporters about more details
> > > >>  - if bug is old and reporter doesn't respond in a timely manner, then
> > > >> close it as 'not reproducible'

> > > >> - And what I really like to see, is a prominent message for reporters
> > of
> > > >> new bugs to provide as much details as possible ALREADY WHEN they
> > enter the
> > > >> bug initially.
> > > >> So much time is wasted by asking for details and waiting for the
> > answer.
> > > >> Your list in 2d is very good. I'd like to add console output and
> > logfile
> > > >> to it.

> > > >> Am 30.01.2011 18:13, schrieb mlb5000:

> > > >>  Hi All,

> > > >>> Disclaimer: I'm only just joining this community so I absolutely want
> > > >>> those of you with more experience developing/fixing bugs in Hudson
> > and
> > > >>> elsewhere to chime in on this conversation.  What I want to do is try
> > > >>> to come to some consensus on how Hudson bugs are to be identified,
> > > >>> disambiguated, prioritized, and ultimately, scheduled (more or less)
> > > >>> for a release.  This is part of what I hope will be a larger overall
> > > >>> effort to bring the Technical Debt I've observed since diving into
> > the
> > > >>> source code into check.

> > > >>> As of right now there are 1853 open bugs in Hudson, of which the
> > > >>> average age is just under a year at 359 days.  Some users, myself
> > > >>> included, have been getting discouraged with cycle time on bugs,
> > > >>> particularly when the Continuous Integration server is supposed to be
> > > >>> the one thing you can most rely on.  When teams make their CI system
> > > >>> the heart and soul of their day-to-day development, testing,
> > > >>> configuration management, and release processes, they need to able to
> > > >>> rely on it.  If any tool can be categorized as mission-critical, it's
> > > >>> the CI system.

> > > >>> Here is what I am proposing:

> > > >>> 1. Users submit bug reports at issues.hudson-ci.org like they always
> > > >>> have.
> > > >>> 2. At some frequency (daily?, weekly?, as they pop up?), developers
> > go
> > > >>> out and perform the following procedure:
> > > >>>   a. Pick the oldest non-triaged bug.
> > > >>>   b. Check whether or not the bug is a duplicate with another bug.
> > > >>> This will likely require aid from the more seasoned Hudson
> > > >>> contributors.
> > > >>>     i. If a duplicate exists but it has been resolved, I would
> > > >>> recommend not reopening it, but just linking the two issues together
> > > >>> so the person who goes to fix the current incantation of the bug can
> > > >>> use it as a resource if necessary.  Continue to the next step.
> > > >>>     ii. If a duplicate exists, but is still open, link the two issues
> > > >>> for future reference, Close the new one as Duplicate, and redirect
> > all
> > > >>> users to the older one.  Go back to 2.a.
> > > >>>     iii. If no duplicate exists, continue.
> > > >>>   c. Is the bug reproducible in the most recent version of Hudson?  I
> > > >>> don't think it's worth verifying the bug in their reported version
> > > >>> since they'll ultimately have to upgrade to get the bug fix anyway,
> > so
> > > >>> we might as well work towards the shortest path.
> > > >>>     i. If the bug is not reproducible in the latest version, close as
> > > >>> Cannot Reproduce and inform the user(s) that it appears to have been
> > > >>> fixed in version X, and go back to 2.a.
> > > >>>     ii. If the bug appears to still exist in the current version,
> > note
> > > >>> which version it was verified in and continue.
> > > >>>   d. Gather as much information as possible from users.  What version
> > > >>> of the system is this bug occurring in?  What environment are they
> > > >>> using?  Did this error start occurring after an upgrade?  What
> > version
> > > >>> did they upgrade to/from?  Are they able to work around the issue or
> > > >>> has it stopped their usage of Hudson in its tracks?  Ask any
> > questions
> > > >>> that might help isolate the commit that introduced the bug, and help
> > > >>> other contributors make the best possible prioritization decisions.
> > > >>>   e. Set the priority of the issue based on some criteria.  I need
> > > >>> some suggestions from the community about what would be the best
> > > >>> criteria.  I would actually suggest trying to get an open source
> > > >>> license of GreenHopper from Atlassian.  Their ranking functionality
> > > >>> within GreenHopper works very well for this purpose since you rank
> > > >>> items relative to each other, not just with priorities.
> > > >>>   f. Mark the bug as triaged and if there are still non-triaged
> > issues
> > > >>> go back to 2.a.
> > > >>> 3. Contributors grab the highest (relative) priority bug to fix and
> > > >>> get to it.  Votes should also contribute to deciding which bug to fix
> > > >>> since that information is real-time and earlier triage information
> > can
> > > >>> become more and more out of date.

> > > >>> I'm extremely interested in getting some feedback about these
> > > >>> procedures.  I'm sure I missed some opportunity in this process or
> > > >>> overlooked something, so please let me know what you think.  I hope
> > > >>> that by unifying these procedures across the community we can work
> > > >>> towards reducing that "average age" stat to below a month or two.
> >  I'm
> > > >>> not saying it will be easy, but I'm certain this community can do it.

> > > >>> Thanks,
> > > >>> Matt

> On Jan 30, 8:36 pm, Arnaud Héritier <arnaud.herit...@exoplatform.com>
> wrote:
> > It is historical
> > less things to administrate and manage ...
> > It is easier to automate the add of a component than creating a new
> project.

> > On Mon, Jan 31, 2011 at 2:32 AM, mlb5000 <baker.mat...@gmail.com> wrote:
> > > @Arnaud, I completely agree that each Hudson plugin should receive its
> > > own "Project" in the Hudson Jira instance.  It's weird that they're
> > > split into components, but maybe there's a reason for it?

> > > On Jan 30, 3:49 pm, Arnaud Héritier <arnaud.herit...@exoplatform.com>
> > > wrote:
> > > > For that we should try to improve our Jira usage and especially using
> > > > versions (affect vs fix for).
> > > > To have this working we need to split the big jira into small pieces
> (one
> > > > per plugin + 1 for core).

> > > > Cheers

> > > > Arnaud

> > > > On Sun, Jan 30, 2011 at 8:56 PM, vtintillier <

> > > > vtintillier.private...@gmail.com> wrote:
> > > > > I am also really in favor of introducing a backlog with priorities.
> For
> > > the
> > > > > moment, we just have no ideas when things will be fixed (or not).
> The
> > > > > Greenhoper plugin is easy to use in Jira.

> > > > > Vivien

> > > > > On Sun, Jan 30, 2011 at 8:25 PM, Christoph Kutzinski <ku...@gmx.de

> > > wrote:

> > > > >> I think this is a very nice proposal.
> > > > >> Some comments:

> > > > >> In my experience most of the very old bugs fall into one of these
> > > > >> scenarios:

> > > > >> - happen only under very rare circumstances. Developer cannot
> > > reproduce it
> > > > >> easily
> > > > >> - are not reproducible because reporter didn't provide enough
> details
> > > (and
> > > > >> often doesn't respond to questions about details)
> > > > >> - fix would break some other functionality and/or would mean
> serious
> > > > >> re-engineering of some parts of Hudson
> > > > >> - are related to a plugin which is not (really) maintained any
> more

> > > > >> And then there are of course the 'normal' bugs, but I think they
> are
> > > the
> > > > >> minority.

> > > > >> This is just my very subjective feeling why there are so many old
> > > bugs.

> > > > >> What we can do easily IMHO:

> > > > >> - search actively for duplicates and close them

> > > > >> - ask reporters about more details
> > > > >>  - if bug is old and reporter doesn't respond in a timely manner,
> then
> > > > >> close it as 'not reproducible'

> > > > >> - And what I really like to see, is a prominent message for
> reporters
> > > of
> > > > >> new bugs to provide as much details as possible ALREADY WHEN they
> > > enter the
> > > > >> bug initially.
> > > > >> So much time is wasted by asking for details and waiting for the
> > > answer.
> > > > >> Your list in 2d is very good. I'd like to add console output and
> > > logfile
> > > > >> to it.

> > > > >> Am 30.01.2011 18:13, schrieb mlb5000:

> > > > >>  Hi All,

> > > > >>> Disclaimer: I'm only just joining this community so I absolutely
> want
> > > > >>> those of you with more experience developing/fixing bugs in
> Hudson
> > > and
> > > > >>> elsewhere to chime in on this conversation.  What I want to do is
> try
> > > > >>> to come to some consensus on how Hudson bugs are to be
> identified,
> > > > >>> disambiguated, prioritized, and ultimately, scheduled (more or
> less)
> > > > >>> for a release.  This is part of what I hope will be a larger
> overall
> > > > >>> effort to bring the Technical Debt I've observed since diving
> into
> > > the
> > > > >>> source code into check.

> > > > >>> As of right now there are 1853 open bugs in Hudson, of which the
> > > > >>> average age is just under a year at 359 days.  Some users, myself
> > > > >>> included, have been getting discouraged with cycle time on bugs,
> > > > >>> particularly when the Continuous Integration server is supposed
> to be
> > > > >>> the one thing you can most rely on.  When teams make their CI
> system
> > > > >>> the heart and soul of their day-to-day development, testing,
> > > > >>> configuration management, and release processes, they need to
> able to
> > > > >>> rely on it.  If any tool can be categorized as mission-critical,
> it's
> > > > >>> the CI system.

> > > > >>> Here is what I am proposing:

> > > > >>> 1. Users submit bug reports at issues.hudson-ci.org like they
> always
> > > > >>> have.
> > > > >>> 2. At some frequency (daily?, weekly?, as they pop up?),
> developers
> > > go
> > > > >>> out and perform the following procedure:
> > > > >>>   a. Pick the oldest non-triaged bug.
> > > > >>>   b. Check whether or not the bug is a duplicate with another
> bug.
> > > > >>> This will likely require aid from the more seasoned Hudson
> > > > >>> contributors.
> > > > >>>     i. If a duplicate exists but it has been resolved, I would
> > > > >>> recommend not reopening it, but just linking the two issues
> together
> > > > >>> so the person who goes to fix the current incantation of the bug
> can
> > > > >>> use it as a resource if necessary.  Continue to the next step.
> > > > >>>     ii. If a duplicate exists, but is still open, link the two
> issues
> > > > >>> for future reference, Close the new one as Duplicate, and
> redirect
> > > all
> > > > >>> users to the older one.  Go back to 2.a.
> > > > >>>     iii. If no duplicate exists, continue.
> > > > >>>   c. Is the bug reproducible in the most recent version of
> Hudson?  I
> > > > >>> don't think it's worth verifying the bug in their reported
> version
> > > > >>> since they'll ultimately have to upgrade to get the bug fix
> anyway,
> > > so
> > > > >>> we might as well work towards the shortest path.
> > > > >>>     i. If the bug is not reproducible in the latest version,
> close as
> > > > >>> Cannot Reproduce and inform the user(s) that it appears to have
> been
> > > > >>> fixed in version X, and go back to 2.a.
> > > > >>>     ii. If the bug appears to still exist in the current version,
> > > note
> > > > >>> which version it was verified in and continue.
> > > > >>>   d. Gather as much information as possible from users.  What
> version
> > > > >>> of the system is this bug occurring in?  What environment are
> they
> > > > >>> using?  Did this error start occurring after an upgrade?  What
> > > version
> > > > >>> did they upgrade to/from?  Are they able to work around the issue
> or
> > > > >>> has it stopped their usage of Hudson in its tracks?  Ask any
> > > questions
> > > > >>> that might help isolate the commit that introduced the bug, and
> help
> > > > >>> other contributors make the best possible prioritization
> decisions.
> > > > >>>   e. Set the priority of the issue based on some criteria.  I
> need
> > > > >>> some suggestions from the community about what would be the best
> > > > >>> criteria.  I would actually suggest trying to get an open source
> > > > >>> license of GreenHopper from Atlassian.  Their ranking
> functionality
> > > > >>> within GreenHopper works very well for this purpose since you
> rank
> > > > >>> items relative to each other, not just with priorities.
> > > > >>>   f. Mark the bug as triaged and if there are still non-triaged
> > > issues
> > > > >>> go back to 2.a.
> > > > >>> 3. Contributors grab the highest (relative) priority bug to fix
> and
> > > > >>> get to it.  Votes should also contribute to deciding which bug to
> fix
> > > > >>> since that information is real-time and earlier triage
> information
> > > can
> > > > >>> become more and more out of date.

> > > > >>> I'm extremely interested in getting some feedback about these
> > > > >>> procedures.  I'm sure I missed some opportunity in this process
> or
> > > > >>> overlooked something, so please let me know what you think.  I
> hope
> > > > >>> that by unifying these procedures across the community we can
> work
> > > > >>> towards reducing that "average age" stat to below a month or two.
> > >  I'm
> > > > >>> not saying it will be easy, but I'm certain this community can do
> it.

> > > > >>> Thanks,
> > > > >>> Matt

> Disclaimer: I'm only just joining this community so I absolutely want
> those of you with more experience developing/fixing bugs in Hudson and
> elsewhere to chime in on this conversation.  What I want to do is try
> to come to some consensus on how Hudson bugs are to be identified,
> disambiguated, prioritized, and ultimately, scheduled (more or less)
> for a release.  This is part of what I hope will be a larger overall
> effort to bring the Technical Debt I've observed since diving into the
> source code into check.

> As of right now there are 1853 open bugs in Hudson, of which the
> average age is just under a year at 359 days.  Some users, myself
> included, have been getting discouraged with cycle time on bugs,
> particularly when the Continuous Integration server is supposed to be
> the one thing you can most rely on.  When teams make their CI system
> the heart and soul of their day-to-day development, testing,
> configuration management, and release processes, they need to able to
> rely on it.  If any tool can be categorized as mission-critical, it's
> the CI system.

> Here is what I am proposing:

> 1. Users submit bug reports at issues.hudson-ci.org like they always
> have.
> 2. At some frequency (daily?, weekly?, as they pop up?), developers go
> out and perform the following procedure:
>   a. Pick the oldest non-triaged bug.
>   b. Check whether or not the bug is a duplicate with another bug.
> This will likely require aid from the more seasoned Hudson
> contributors.
>     i. If a duplicate exists but it has been resolved, I would
> recommend not reopening it, but just linking the two issues together
> so the person who goes to fix the current incantation of the bug can
> use it as a resource if necessary.  Continue to the next step.
>     ii. If a duplicate exists, but is still open, link the two issues
> for future reference, Close the new one as Duplicate, and redirect all
> users to the older one.  Go back to 2.a.
>     iii. If no duplicate exists, continue.
>   c. Is the bug reproducible in the most recent version of Hudson?  I
> don't think it's worth verifying the bug in their reported version
> since they'll ultimately have to upgrade to get the bug fix anyway, so
> we might as well work towards the shortest path.
>     i. If the bug is not reproducible in the latest version, close as
> Cannot Reproduce and inform the user(s) that it appears to have been
> fixed in version X, and go back to 2.a.
>     ii. If the bug appears to still exist in the current version, note
> which version it was verified in and continue.
>   d. Gather as much information as possible from users.  What version
> of the system is this bug occurring in?  What environment are they
> using?  Did this error start occurring after an upgrade?  What version
> did they upgrade to/from?  Are they able to work around the issue or
> has it stopped their usage of Hudson in its tracks?  Ask any questions
> that might help isolate the commit that introduced the bug, and help
> other contributors make the best possible prioritization decisions.
>   e. Set the priority of the issue based on some criteria.  I need
> some suggestions from the community about what would be the best
> criteria.  I would actually suggest trying to get an open source
> license of GreenHopper from Atlassian.  Their ranking functionality
> within GreenHopper works very well for this purpose since you rank
> items relative to each other, not just with priorities.
>   f. Mark the bug as triaged and if there are still non-triaged issues
> go back to 2.a.
> 3. Contributors grab the highest (relative) priority bug to fix and
> get to it.  Votes should also contribute to deciding which bug to fix
> since that information is real-time and earlier triage information can
> become more and more out of date.

> I'm extremely interested in getting some feedback about these
> procedures.  I'm sure I missed some opportunity in this process or
> overlooked something, so please let me know what you think.  I hope
> that by unifying these procedures across the community we can work
> towards reducing that "average age" stat to below a month or two.  I'm
> not saying it will be easy, but I'm certain this community can do it.

> Thanks,
> Matt

> At any rate, does anyone have any (further) suggestions for how to
> handle these older bugs reports without having to go through them one
> by one?  Just to provide some perspective, 494 (http://issues.jenkins-
> ci.org/secure/IssueNavigator.jspa?mode=hide&requestId=10243) of the
> 1862 currently unresolved bug reports (http://issues.jenkins-ci.org/
> secure/IssueNavigator.jspa?mode=hide&requestId=10244) are considered
> stale.

> Also, would someone who has administrative privileges in the Jenkins
> Jira instance be able to add a Boolean field to the Bug issue type for
> marking whether or not a bug report has been Triaged, or does anyone
> have another way to keep track of whether a bug report has been
> vetted?

> On Jan 30, 12:13 pm, mlb5000 <baker.mat...@gmail.com> wrote:

> > Hi All,

> > Disclaimer: I'm only just joining this community so I absolutely want
> > those of you with more experience developing/fixing bugs in Hudson and
> > elsewhere to chime in on this conversation.  What I want to do is try
> > to come to some consensus on how Hudson bugs are to be identified,
> > disambiguated, prioritized, and ultimately, scheduled (more or less)
> > for a release.  This is part of what I hope will be a larger overall
> > effort to bring the Technical Debt I've observed since diving into the
> > source code into check.

> > As of right now there are 1853 open bugs in Hudson, of which the
> > average age is just under a year at 359 days.  Some users, myself
> > included, have been getting discouraged with cycle time on bugs,
> > particularly when the Continuous Integration server is supposed to be
> > the one thing you can most rely on.  When teams make their CI system
> > the heart and soul of their day-to-day development, testing,
> > configuration management, and release processes, they need to able to
> > rely on it.  If any tool can be categorized as mission-critical, it's
> > the CI system.

> > Here is what I am proposing:

> > 1. Users submit bug reports at issues.hudson-ci.org like they always
> > have.
> > 2. At some frequency (daily?, weekly?, as they pop up?), developers go
> > out and perform the following procedure:
> >   a. Pick the oldest non-triaged bug.
> >   b. Check whether or not the bug is a duplicate with another bug.
> > This will likely require aid from the more seasoned Hudson
> > contributors.
> >     i. If a duplicate exists but it has been resolved, I would
> > recommend not reopening it, but just linking the two issues together
> > so the person who goes to fix the current incantation of the bug can
> > use it as a resource if necessary.  Continue to the next step.
> >     ii. If a duplicate exists, but is still open, link the two issues
> > for future reference, Close the new one as Duplicate, and redirect all
> > users to the older one.  Go back to 2.a.
> >     iii. If no duplicate exists, continue.
> >   c. Is the bug reproducible in the most recent version of Hudson?  I
> > don't think it's worth verifying the bug in their reported version
> > since they'll ultimately have to upgrade to get the bug fix anyway, so
> > we might as well work towards the shortest path.
> >     i. If the bug is not reproducible in the latest version, close as
> > Cannot Reproduce and inform the user(s) that it appears to have been
> > fixed in version X, and go back to 2.a.
> >     ii. If the bug appears to still exist in the current version, note
> > which version it was verified in and continue.
> >   d. Gather as much information as possible from users.  What version
> > of the system is this bug occurring in?  What environment are they
> > using?  Did this error start occurring after an upgrade?  What version
> > did they upgrade to/from?  Are they able to work around the issue or
> > has it stopped their usage of Hudson in its tracks?  Ask any questions
> > that might help isolate the commit that introduced the bug, and help
> > other contributors make the best possible prioritization decisions.
> >   e. Set the priority of the issue based on some criteria.  I need
> > some suggestions from the community about what would be the best
> > criteria.  I would actually suggest trying to get an open source
> > license of GreenHopper from Atlassian.  Their ranking functionality
> > within GreenHopper works very well for this purpose since you rank
> > items relative to each other, not just with priorities.
> >   f. Mark the bug as triaged and if there are still non-triaged issues
> > go back to 2.a.
> > 3. Contributors grab the highest (relative) priority bug to fix and
> > get to it.  Votes should also contribute to deciding which bug to fix
> > since that information is real-time and earlier triage information can
> > become more and more out of date.

> > I'm extremely interested in getting some feedback about these
> > procedures.  I'm sure I missed some opportunity in this process or
> > overlooked something, so please let me know what you think.  I hope
> > that by unifying these procedures across the community we can work
> > towards reducing that "average age" stat to below a month or two.  I'm
> > not saying it will be easy, but I'm certain this community can do it.

> > Thanks,
> > Matt

> I fully agree with you that obsolete bugs should be closed, in order
> for most users to know what are really the current issues and in order
> for most developers to know what has to be fixed.
> But I think that the 494 stale bugs can't be closed like that.
> For example, a large number of issues were written by Kohsuke for
> things to check or for things to fix (for example issue 5036).
> A bug having a low priority for one year probably doesn't mean that it
> doesn't need to be fixed.

> I currently suggest that some, if not all, developers read each one of
> the stale bugs in

> http://issues.jenkins-ci.org/secure/IssueNavigator.jspa?mode=hide&req...
> and that we close them when necessary.

> I will try to do that myself (instead of sleeping) and as Christoph
> said:
> - search actively for duplicates and close them [we may also read the
> changelogs of releases]

> Matt: Because you are already a user, please choose some issues to be
> tested and write your test results in the issues : it will save most
> of the time needed by the developers to know if the stale issues can
> be closed ! (and it may help you later to submit patchs)

> bye,
> Emeric

> On 7 fév, 00:29, mlb5000 <baker.mat...@gmail.com> wrote:
> > Things haven't completely calmed down since the rename yet, but I'd
> > like to get started closing out some of these old issues if at all
> > possible.  I noticed there was a "!CLOSED && STALE" query already on
> > issues.jenkins-ci.org and I was wondering how we want to handle Bug
> > reports that fall into this category.  An issue is considered STALE if
> > it hasn't been updated within the last year.  I'd say that's a pretty
> > good criteria for just calling it and closing the issue without
> > discretion, but I don't personally have any insight into what some of
> > those older bug reports might be, and the last thing I want is to
> > upset the users.

> > At any rate, does anyone have any (further) suggestions for how to
> > handle these older bugs reports without having to go through them one
> > by one?  Just to provide some perspective, 494 (http://issues.jenkins-
> > ci.org/secure/IssueNavigator.jspa?mode=hide&requestId=10243) of the
> > 1862 currently unresolved bug reports (http://issues.jenkins-ci.org/
> > secure/IssueNavigator.jspa?mode=hide&requestId=10244) are considered
> > stale.

> > Also, would someone who has administrative privileges in the Jenkins
> > Jira instance be able to add a Boolean field to the Bug issue type for
> > marking whether or not a bug report has been Triaged, or does anyone
> > have another way to keep track of whether a bug report has been
> > vetted?

> > On Jan 30, 12:13 pm, mlb5000 <baker.mat...@gmail.com> wrote:

> > > Hi All,

> > > Disclaimer: I'm only just joining this community so I absolutely want
> > > those of you with more experience developing/fixing bugs in Hudson and
> > > elsewhere to chime in on this conversation.  What I want to do is try
> > > to come to some consensus on how Hudson bugs are to be identified,
> > > disambiguated, prioritized, and ultimately, scheduled (more or less)
> > > for a release.  This is part of what I hope will be a larger overall
> > > effort to bring the Technical Debt I've observed since diving into the
> > > source code into check.

> > > As of right now there are 1853 open bugs in Hudson, of which the
> > > average age is just under a year at 359 days.  Some users, myself
> > > included, have been getting discouraged with cycle time on bugs,
> > > particularly when the Continuous Integration server is supposed to be
> > > the one thing you can most rely on.  When teams make their CI system
> > > the heart and soul of their day-to-day development, testing,
> > > configuration management, and release processes, they need to able to
> > > rely on it.  If any tool can be categorized as mission-critical, it's
> > > the CI system.

> > > Here is what I am proposing:

> > > 1. Users submit bug reports at issues.hudson-ci.org like they always
> > > have.
> > > 2. At some frequency (daily?, weekly?, as they pop up?), developers go
> > > out and perform the following procedure:
> > >   a. Pick the oldest non-triaged bug.
> > >   b. Check whether or not the bug is a duplicate with another bug.
> > > This will likely require aid from the more seasoned Hudson
> > > contributors.
> > >     i. If a duplicate exists but it has been resolved, I would
> > > recommend not reopening it, but just linking the two issues together
> > > so the person who goes to fix the current incantation of the bug can
> > > use it as a resource if necessary.  Continue to the next step.
> > >     ii. If a duplicate exists, but is still open, link the two issues
> > > for future reference, Close the new one as Duplicate, and redirect all
> > > users to the older one.  Go back to 2.a.
> > >     iii. If no duplicate exists, continue.
> > >   c. Is the bug reproducible in the most recent version of Hudson?  I
> > > don't think it's worth verifying the bug in their reported version
> > > since they'll ultimately have to upgrade to get the bug fix anyway, so
> > > we might as well work towards the shortest path.
> > >     i. If the bug is not reproducible in the latest version, close as
> > > Cannot Reproduce and inform the user(s) that it appears to have been
> > > fixed in version X, and go back to 2.a.
> > >     ii. If the bug appears to still exist in the current version, note
> > > which version it was verified in and continue.
> > >   d. Gather as much information as possible from users.  What version
> > > of the system is this bug occurring in?  What environment are they
> > > using?  Did this error start occurring after an upgrade?  What version
> > > did they upgrade to/from?  Are they able to work around the issue or
> > > has it stopped their usage of Hudson in its tracks?  Ask any questions
> > > that might help isolate the commit that introduced the bug, and help
> > > other contributors make the best possible prioritization decisions.
> > >   e. Set the priority of the issue based on some criteria.  I need
> > > some suggestions from the community about what would be the best
> > > criteria.  I would actually suggest trying to get an open source
> > > license of GreenHopper from Atlassian.  Their ranking functionality
> > > within GreenHopper works very well for this purpose since you rank
> > > items relative to each other, not just with priorities.
> > >   f. Mark the bug as triaged and if there are still non-triaged issues
> > > go back to 2.a.
> > > 3. Contributors grab the highest (relative) priority bug to fix and
> > > get to it.  Votes should also contribute to deciding which bug to fix
> > > since that information is real-time and earlier triage information can
> > > become more and more out of date.

> > > I'm extremely interested in getting some feedback about these
> > > procedures.  I'm sure I missed some opportunity in this process or
> > > overlooked something, so please let me know what you think.  I hope
> > > that by unifying these procedures across the community we can work
> > > towards reducing that "average age" stat to below a month or two.  I'm
> > > not saying it will be easy, but I'm certain this community can do it.

> > > Thanks,
> > > Matt

> On Mon, Feb 7, 2011 at 2:27 AM, evernat <ever...@free.fr> wrote:

>> Hi Matt,

>> I fully agree with you that obsolete bugs should be closed, in order
>> for most users to know what are really the current issues and in order
>> for most developers to know what has to be fixed.
>> But I think that the 494 stale bugs can't be closed like that.
>> For example, a large number of issues were written by Kohsuke for
>> things to check or for things to fix (for example issue 5036).
>> A bug having a low priority for one year probably doesn't mean that it
>> doesn't need to be fixed.

>> I currently suggest that some, if not all, developers read each one of
>> the stale bugs in

>> http://issues.jenkins-ci.org/secure/IssueNavigator.jspa?mode=hide&req...
>> and that we close them when necessary.

>> I will try to do that myself (instead of sleeping) and as Christoph
>> said:
>> - search actively for duplicates and close them [we may also read the
>> changelogs of releases]

> We could ask to have a free version of suggestimate to find duplicates.
> It helps also users to not open issues which are already existing.
> http://www.suggestimate.com/?r=view

> WDYT ?

>> - ask reporters about more details [if needed]
>>    - if bug is old and reporter doesn't respond in a timely manner,
>> then close it as 'not reproducible'

>> Matt: Because you are already a user, please choose some issues to be
>> tested and write your test results in the issues : it will save most
>> of the time needed by the developers to know if the stale issues can
>> be closed ! (and it may help you later to submit patchs)

>> bye,
>> Emeric

>> On 7 fév, 00:29, mlb5000 <baker.mat...@gmail.com> wrote:
>> > Things haven't completely calmed down since the rename yet, but I'd
>> > like to get started closing out some of these old issues if at all
>> > possible.  I noticed there was a "!CLOSED && STALE" query already on
>> > issues.jenkins-ci.org and I was wondering how we want to handle Bug
>> > reports that fall into this category.  An issue is considered STALE if
>> > it hasn't been updated within the last year.  I'd say that's a pretty
>> > good criteria for just calling it and closing the issue without
>> > discretion, but I don't personally have any insight into what some of
>> > those older bug reports might be, and the last thing I want is to
>> > upset the users.

>> > At any rate, does anyone have any (further) suggestions for how to
>> > handle these older bugs reports without having to go through them one
>> > by one?  Just to provide some perspective, 494 (http://issues.jenkins-
>> > ci.org/secure/IssueNavigator.jspa?mode=hide&requestId=10243) of the
>> > 1862 currently unresolved bug reports (http://issues.jenkins-ci.org/
>> > secure/IssueNavigator.jspa?mode=hide&requestId=10244) are considered
>> > stale.

>> > Also, would someone who has administrative privileges in the Jenkins
>> > Jira instance be able to add a Boolean field to the Bug issue type for
>> > marking whether or not a bug report has been Triaged, or does anyone
>> > have another way to keep track of whether a bug report has been
>> > vetted?

>> > On Jan 30, 12:13 pm, mlb5000 <baker.mat...@gmail.com> wrote:

>> > > Hi All,

>> > > Disclaimer: I'm only just joining this community so I absolutely want
>> > > those of you with more experience developing/fixing bugs in Hudson and
>> > > elsewhere to chime in on this conversation.  What I want to do is try
>> > > to come to some consensus on how Hudson bugs are to be identified,
>> > > disambiguated, prioritized, and ultimately, scheduled (more or less)
>> > > for a release.  This is part of what I hope will be a larger overall
>> > > effort to bring the Technical Debt I've observed since diving into the
>> > > source code into check.

>> > > As of right now there are 1853 open bugs in Hudson, of which the
>> > > average age is just under a year at 359 days.  Some users, myself
>> > > included, have been getting discouraged with cycle time on bugs,
>> > > particularly when the Continuous Integration server is supposed to be
>> > > the one thing you can most rely on.  When teams make their CI system
>> > > the heart and soul of their day-to-day development, testing,
>> > > configuration management, and release processes, they need to able to
>> > > rely on it.  If any tool can be categorized as mission-critical, it's
>> > > the CI system.

>> > > Here is what I am proposing:

>> > > 1. Users submit bug reports at issues.hudson-ci.org like they always
>> > > have.
>> > > 2. At some frequency (daily?, weekly?, as they pop up?), developers go
>> > > out and perform the following procedure:
>> > >   a. Pick the oldest non-triaged bug.
>> > >   b. Check whether or not the bug is a duplicate with another bug.
>> > > This will likely require aid from the more seasoned Hudson
>> > > contributors.
>> > >     i. If a duplicate exists but it has been resolved, I would
>> > > recommend not reopening it, but just linking the two issues together
>> > > so the person who goes to fix the current incantation of the bug can
>> > > use it as a resource if necessary.  Continue to the next step.
>> > >     ii. If a duplicate exists, but is still open, link the two issues
>> > > for future reference, Close the new one as Duplicate, and redirect all
>> > > users to the older one.  Go back to 2.a.
>> > >     iii. If no duplicate exists, continue.
>> > >   c. Is the bug reproducible in the most recent version of Hudson?  I
>> > > don't think it's worth verifying the bug in their reported version
>> > > since they'll ultimately have to upgrade to get the bug fix anyway, so
>> > > we might as well work towards the shortest path.
>> > >     i. If the bug is not reproducible in the latest version, close as
>> > > Cannot Reproduce and inform the user(s) that it appears to have been
>> > > fixed in version X, and go back to 2.a.
>> > >     ii. If the bug appears to still exist in the current version, note
>> > > which version it was verified in and continue.
>> > >   d. Gather as much information as possible from users.  What version
>> > > of the system is this bug occurring in?  What environment are they
>> > > using?  Did this error start occurring after an upgrade?  What version
>> > > did they upgrade to/from?  Are they able to work around the issue or
>> > > has it stopped their usage of Hudson in its tracks?  Ask any questions
>> > > that might help isolate the commit that introduced the bug, and help
>> > > other contributors make the best possible prioritization decisions.
>> > >   e. Set the priority of the issue based on some criteria.  I need
>> > > some suggestions from the community about what would be the best
>> > > criteria.  I would actually suggest trying to get an open source
>> > > license of GreenHopper from Atlassian.  Their ranking functionality
>> > > within GreenHopper works very well for this purpose since you rank
>> > > items relative to each other, not just with priorities.
>> > >   f. Mark the bug as triaged and if there are still non-triaged issues
>> > > go back to 2.a.
>> > > 3. Contributors grab the highest (relative) priority bug to fix and
>> > > get to it.  Votes should also contribute to deciding which bug to fix
>> > > since that information is real-time and earlier triage information can
>> > > become more and more out of date.

>> > > I'm extremely interested in getting some feedback about these
>> > > procedures.  I'm sure I missed some opportunity in this process or
>> > > overlooked something, so please let me know what you think.  I hope
>> > > that by unifying these procedures across the community we can work
>> > > towards reducing that "average age" stat to below a month or two.  I'm
>> > > not saying it will be easy, but I'm certain this community can do it.

>> > > Thanks,
>> > > Matt

> Richard.

> 2011/2/7 Arnaud Héritier <arnaud.herit...@exoplatform.com>

>> On Mon, Feb 7, 2011 at 2:27 AM, evernat <ever...@free.fr> wrote:

>>> Hi Matt,

>>> I fully agree with you that obsolete bugs should be closed, in order
>>> for most users to know what are really the current issues and in order
>>> for most developers to know what has to be fixed.
>>> But I think that the 494 stale bugs can't be closed like that.
>>> For example, a large number of issues were written by Kohsuke for
>>> things to check or for things to fix (for example issue 5036).
>>> A bug having a low priority for one year probably doesn't mean that it
>>> doesn't need to be fixed.

>>> I currently suggest that some, if not all, developers read each one of
>>> the stale bugs in

>>> http://issues.jenkins-ci.org/secure/IssueNavigator.jspa?mode=hide&req...
>>> and that we close them when necessary.

>>> I will try to do that myself (instead of sleeping) and as Christoph
>>> said:
>>> - search actively for duplicates and close them [we may also read the
>>> changelogs of releases]

>> We could ask to have a free version of suggestimate to find duplicates.
>> It helps also users to not open issues which are already existing.
>> http://www.suggestimate.com/?r=view

>> WDYT ?

>>> - ask reporters about more details [if needed]
>>>    - if bug is old and reporter doesn't respond in a timely manner,
>>> then close it as 'not reproducible'

>>> Matt: Because you are already a user, please choose some issues to be
>>> tested and write your test results in the issues : it will save most
>>> of the time needed by the developers to know if the stale issues can
>>> be closed ! (and it may help you later to submit patchs)

>>> bye,
>>> Emeric

>>> On 7 fév, 00:29, mlb5000 <baker.mat...@gmail.com> wrote:
>>> > Things haven't completely calmed down since the rename yet, but I'd
>>> > like to get started closing out some of these old issues if at all
>>> > possible.  I noticed there was a "!CLOSED && STALE" query already on
>>> > issues.jenkins-ci.org and I was wondering how we want to handle Bug
>>> > reports that fall into this category.  An issue is considered STALE if
>>> > it hasn't been updated within the last year.  I'd say that's a pretty
>>> > good criteria for just calling it and closing the issue without
>>> > discretion, but I don't personally have any insight into what some of
>>> > those older bug reports might be, and the last thing I want is to
>>> > upset the users.

>>> > At any rate, does anyone have any (further) suggestions for how to
>>> > handle these older bugs reports without having to go through them one
>>> > by one?  Just to provide some perspective, 494 (http://issues.jenkins-
>>> > ci.org/secure/IssueNavigator.jspa?mode=hide&requestId=10243) of the
>>> > 1862 currently unresolved bug reports (http://issues.jenkins-ci.org/
>>> > secure/IssueNavigator.jspa?mode=hide&requestId=10244) are considered
>>> > stale.

>>> > Also, would someone who has administrative privileges in the Jenkins
>>> > Jira instance be able to add a Boolean field to the Bug issue type for
>>> > marking whether or not a bug report has been Triaged, or does anyone
>>> > have another way to keep track of whether a bug report has been
>>> > vetted?

>>> > On Jan 30, 12:13 pm, mlb5000 <baker.mat...@gmail.com> wrote:

>>> > > Hi All,

>>> > > Disclaimer: I'm only just joining this community so I absolutely want
>>> > > those of you with more experience developing/fixing bugs in Hudson
>>> and
>>> > > elsewhere to chime in on this conversation.  What I want to do is try
>>> > > to come to some consensus on how Hudson bugs are to be identified,
>>> > > disambiguated, prioritized, and ultimately, scheduled (more or less)
>>> > > for a release.  This is part of what I hope will be a larger overall
>>> > > effort to bring the Technical Debt I've observed since diving into
>>> the
>>> > > source code into check.

>>> > > As of right now there are 1853 open bugs in Hudson, of which the
>>> > > average age is just under a year at 359 days.  Some users, myself
>>> > > included, have been getting discouraged with cycle time on bugs,
>>> > > particularly when the Continuous Integration server is supposed to be
>>> > > the one thing you can most rely on.  When teams make their CI system
>>> > > the heart and soul of their day-to-day development, testing,
>>> > > configuration management, and release processes, they need to able to
>>> > > rely on it.  If any tool can be categorized as mission-critical, it's
>>> > > the CI system.

>>> > > Here is what I am proposing:

>>> > > 1. Users submit bug reports at issues.hudson-ci.org like they always
>>> > > have.
>>> > > 2. At some frequency (daily?, weekly?, as they pop up?), developers
>>> go
>>> > > out and perform the following procedure:
>>> > >   a. Pick the oldest non-triaged bug.
>>> > >   b. Check whether or not the bug is a duplicate with another bug.
>>> > > This will likely require aid from the more seasoned Hudson
>>> > > contributors.
>>> > >     i. If a duplicate exists but it has been resolved, I would
>>> > > recommend not reopening it, but just linking the two issues together
>>> > > so the person who goes to fix the current incantation of the bug can
>>> > > use it as a resource if necessary.  Continue to the next step.
>>> > >     ii. If a duplicate exists, but is still open, link the two issues
>>> > > for future reference, Close the new one as Duplicate, and redirect
>>> all
>>> > > users to the older one.  Go back to 2.a.
>>> > >     iii. If no duplicate exists, continue.
>>> > >   c. Is the bug reproducible in the most recent version of Hudson?  I
>>> > > don't think it's worth verifying the bug in their reported version
>>> > > since they'll ultimately have to upgrade to get the bug fix anyway,
>>> so
>>> > > we might as well work towards the shortest path.
>>> > >     i. If the bug is not reproducible in the latest version, close as
>>> > > Cannot Reproduce and inform the user(s) that it appears to have been
>>> > > fixed in version X, and go back to 2.a.
>>> > >     ii. If the bug appears to still exist in the current version,
>>> note
>>> > > which version it was verified in and continue.
>>> > >   d. Gather as much information as possible from users.  What version
>>> > > of the system is this bug occurring in?  What environment are they
>>> > > using?  Did this error start occurring after an upgrade?  What
>>> version
>>> > > did they upgrade to/from?  Are they able to work around the issue or
>>> > > has it stopped their usage of Hudson in its tracks?  Ask any
>>> questions
>>> > > that might help isolate the commit that introduced the bug, and help
>>> > > other contributors make the best possible prioritization decisions.
>>> > >   e. Set the priority of the issue based on some criteria.  I need
>>> > > some suggestions from the community about what would be the best
>>> > > criteria.  I would actually suggest trying to get an open source
>>> > > license of GreenHopper from Atlassian.  Their ranking functionality
>>> > > within GreenHopper works very well for this purpose since you rank
>>> > > items relative to each other, not just with priorities.
>>> > >   f. Mark the bug as triaged and if there are still non-triaged
>>> issues
>>> > > go back to 2.a.
>>> > > 3. Contributors grab the highest (relative) priority bug to fix and
>>> > > get to it.  Votes should also contribute to deciding which bug to fix
>>> > > since that information is real-time and earlier triage information
>>> can
>>> > > become more and more out of date.

>>> > > I'm extremely interested in getting some feedback about these
>>> > > procedures.  I'm sure I missed some opportunity in this process or
>>> > > overlooked something, so please let me know what you think.  I hope
>>> > > that by unifying these procedures across the community we can work
>>> > > towards reducing that "average age" stat to below a month or two.
>>>  I'm
>>> > > not saying it will be easy, but I'm certain this community can do it.

>>> > > Thanks,
>>> > > Matt

>> Disclaimer: I'm only just joining this community so I absolutely want
>> those of you with more experience developing/fixing bugs in Hudson and
>> elsewhere to chime in on this conversation.  What I want to do is try
>> to come to some consensus on how Hudson bugs are to be identified,
>> disambiguated, prioritized, and ultimately, scheduled (more or less)
>> for a release.  This is part of what I hope will be a larger overall
>> effort to bring the Technical Debt I've observed since diving into the
>> source code into check.

>> As of right now there are 1853 open bugs in Hudson, of which the
>> average age is just under a year at 359 days.  Some users, myself
>> included, have been getting discouraged with cycle time on bugs,
>> particularly when the Continuous Integration server is supposed to be
>> the one thing you can most rely on.  When teams make their CI system
>> the heart and soul of their day-to-day development, testing,
>> configuration management, and release processes, they need to able to
>> rely on it.  If any tool can be categorized as mission-critical, it's
>> the CI system.

>> Here is what I am proposing:

>> 1. Users submit bug reports at issues.hudson-ci.org like they always
>> have.
>> 2. At some frequency (daily?, weekly?, as they pop up?), developers go
>> out and perform the following procedure:
>>    a. Pick the oldest non-triaged bug.
>>    b. Check whether or not the bug is a duplicate with another bug.
>> This will likely require aid from the more seasoned Hudson
>> contributors.
>>      i. If a duplicate exists but it has been resolved, I would
>> recommend not reopening it, but just linking the two issues together
>> so the person who goes to fix the current incantation of the bug can
>> use it as a resource if necessary.  Continue to the next step.
>>      ii. If a duplicate exists, but is still open, link the two issues
>> for future reference, Close the new one as Duplicate, and redirect all
>> users to the older one.  Go back to 2.a.
>>      iii. If no duplicate exists, continue.
>>    c. Is the bug reproducible in the most recent version of Hudson?  I
>> don't think it's worth verifying the bug in their reported version
>> since they'll ultimately have to upgrade to get the bug fix anyway, so
>> we might as well work towards the shortest path.
>>      i. If the bug is not reproducible in the latest version, close as
>> Cannot Reproduce and inform the user(s) that it appears to have been
>> fixed in version X, and go back to 2.a.
>>      ii. If the bug appears to still exist in the current version, note
>> which version it was verified in and continue.
>>    d. Gather as much information as possible from users.  What version
>> of the system is this bug occurring in?  What environment are they
>> using?  Did this error start occurring after an upgrade?  What version
>> did they upgrade to/from?  Are they able to work around the issue or
>> has it stopped their usage of Hudson in its tracks?  Ask any questions
>> that might help isolate the commit that introduced the bug, and help
>> other contributors make the best possible prioritization decisions.
>>    e. Set the priority of the issue based on some criteria.  I need
>> some suggestions from the community about what would be the best
>> criteria.  I would actually suggest trying to get an open source
>> license of GreenHopper from Atlassian.  Their ranking functionality
>> within GreenHopper works very well for this purpose since you rank
>> items relative to each other, not just with priorities.
>>    f. Mark the bug as triaged and if there are still non-triaged issues
>> go back to 2.a.
>> 3. Contributors grab the highest (relative) priority bug to fix and
>> get to it.  Votes should also contribute to deciding which bug to fix
>> since that information is real-time and earlier triage information can
>> become more and more out of date.

>> I'm extremely interested in getting some feedback about these
>> procedures.  I'm sure I missed some opportunity in this process or
>> overlooked something, so please let me know what you think.  I hope
>> that by unifying these procedures across the community we can work
>> towards reducing that "average age" stat to below a month or two.  I'm
>> not saying it will be easy, but I'm certain this community can do it.

>> Thanks,
>> Matt

> I fully agree with you that obsolete bugs should be closed, in order
> for most users to know what are really the current issues and in order
> for most developers to know what has to be fixed.
> But I think that the 494 stale bugs can't be closed like that.
> For example, a large number of issues were written by Kohsuke for
> things to check or for things to fix (for example issue 5036).
> A bug having a low priority for one year probably doesn't mean that it
> doesn't need to be fixed.

> I currently suggest that some, if not all, developers read each one of
> the stale bugs inhttp://issues.jenkins-ci.org/secure/IssueNavigator.jspa?mode=hide&req...
> and that we close them when necessary.

> I will try to do that myself (instead of sleeping) and as Christoph
> said:
> - search actively for duplicates and close them [we may also read the
> changelogs of releases]
> - ask reporters about more details [if needed]
>    - if bug is old and reporter doesn't respond in a timely manner,
> then close it as 'not reproducible'

> Matt: Because you are already a user, please choose some issues to be
> tested and write your test results in the issues : it will save most
> of the time needed by the developers to know if the stale issues can
> be closed ! (and it may help you later to submit patchs)

> bye,
> Emeric

> On 7 fév, 00:29, mlb5000 <baker.mat...@gmail.com> wrote:

> > Things haven't completely calmed down since the rename yet, but I'd
> > like to get started closing out some of these old issues if at all
> > possible.  I noticed there was a "!CLOSED && STALE" query already on
> > issues.jenkins-ci.org and I was wondering how we want to handle Bug
> > reports that fall into this category.  An issue is considered STALE if
> > it hasn't been updated within the last year.  I'd say that's a pretty
> > good criteria for just calling it and closing the issue without
> > discretion, but I don't personally have any insight into what some of
> > those older bug reports might be, and the last thing I want is to
> > upset the users.

> > At any rate, does anyone have any (further) suggestions for how to
> > handle these older bugs reports without having to go through them one
> > by one?  Just to provide some perspective, 494 (http://issues.jenkins-
> > ci.org/secure/IssueNavigator.jspa?mode=hide&requestId=10243) of the
> > 1862 currently unresolved bug reports (http://issues.jenkins-ci.org/
> > secure/IssueNavigator.jspa?mode=hide&requestId=10244) are considered
> > stale.

> > Also, would someone who has administrative privileges in the Jenkins
> > Jira instance be able to add a Boolean field to the Bug issue type for
> > marking whether or not a bug report has been Triaged, or does anyone
> > have another way to keep track of whether a bug report has been
> > vetted?

> > On Jan 30, 12:13 pm, mlb5000 <baker.mat...@gmail.com> wrote:

> > > Hi All,

> > > Disclaimer: I'm only just joining this community so I absolutely want
> > > those of you with more experience developing/fixing bugs in Hudson and
> > > elsewhere to chime in on this conversation.  What I want to do is try
> > > to come to some consensus on how Hudson bugs are to be identified,
> > > disambiguated, prioritized, and ultimately, scheduled (more or less)
> > > for a release.  This is part of what I hope will be a larger overall
> > > effort to bring the Technical Debt I've observed since diving into the
> > > source code into check.

> > > As of right now there are 1853 open bugs in Hudson, of which the
> > > average age is just under a year at 359 days.  Some users, myself
> > > included, have been getting discouraged with cycle time on bugs,
> > > particularly when the Continuous Integration server is supposed to be
> > > the one thing you can most rely on.  When teams make their CI system
> > > the heart and soul of their day-to-day development, testing,
> > > configuration management, and release processes, they need to able to
> > > rely on it.  If any tool can be categorized as mission-critical, it's
> > > the CI system.

> > > Here is what I am proposing:

> > > 1. Users submit bug reports at issues.hudson-ci.org like they always
> > > have.
> > > 2. At some frequency (daily?, weekly?, as they pop up?), developers go
> > > out and perform the following procedure:
> > >   a. Pick the oldest non-triaged bug.
> > >   b. Check whether or not the bug is a duplicate with another bug.
> > > This will likely require aid from the more seasoned Hudson
> > > contributors.
> > >     i. If a duplicate exists but it has been resolved, I would
> > > recommend not reopening it, but just linking the two issues together
> > > so the person who goes to fix the current incantation of the bug can
> > > use it as a resource if necessary.  Continue to the next step.
> > >     ii. If a duplicate exists, but is still open, link the two issues
> > > for future reference, Close the new one as Duplicate, and redirect all
> > > users to the older one.  Go back to 2.a.
> > >     iii. If no duplicate exists, continue.
> > >   c. Is the bug reproducible in the most recent version of Hudson?  I
> > > don't think it's worth verifying the bug in their reported version
> > > since they'll ultimately have to upgrade to get the bug fix anyway, so
> > > we might as well work towards the shortest path.
> > >     i. If the bug is not reproducible in the latest version, close as
> > > Cannot Reproduce and inform the user(s) that it appears to have been
> > > fixed in version X, and go back to 2.a.
> > >     ii. If the bug appears to still exist in the current version, note
> > > which version it was verified in and continue.
> > >   d. Gather as much information as possible from users.  What version
> > > of the system is this bug occurring in?  What environment are they
> > > using?  Did this error start occurring after an upgrade?  What version
> > > did they upgrade to/from?  Are they able to work around the issue or
> > > has it stopped their usage of Hudson in its tracks?  Ask any questions
> > > that might help isolate the commit that introduced the bug, and help
> > > other contributors make the best possible prioritization decisions.
> > >   e. Set the priority of the issue based on some criteria.  I need
> > > some suggestions from the community about what would be the best
> > > criteria.  I would actually suggest trying to get an open source
> > > license of GreenHopper from Atlassian.  Their ranking functionality
> > > within GreenHopper works very well for this purpose since you rank
> > > items relative to each other, not just with priorities.
> > >   f. Mark the bug as triaged and if there are still non-triaged issues
> > > go back to 2.a.
> > > 3. Contributors grab the highest (relative) priority bug to fix and
> > > get to it.  Votes should also contribute to deciding which bug to fix
> > > since that information is real-time and earlier

> As with stale bugs I would add a comment here and give the reporter a chance
> to give more detail.. there are a lot of environment specific issues out
> there.

> @arnaud I've never used that tool, but if you think it might help make
> a dent in discovering duplicate bug reports it can't hurt, especially
> if it doesn't cost anything.  It might be difficult to decide who the
> Open Source license gets assigned to until the Jenkins Governance
> group gets the project under a legal umbrella.

> QUESTION: Does anyone know who the custodian on Open Source software
> licenses for Jenkins is?

> @ulli Just to be clear, I'm only focusing on bug reports right now,
> not the other issue types like Feature or Improvement.  By your same
> query there are 709 unresolved bug reports that have no one assigned
> to them.  It seems like this list would be a good place to start.  As
> far as the Jira request, what I'm looking for is a way that multiple
> people can tackle this problem at once without stepping on each
> other's toes and duplicating work.  Perhaps simply posting a comment
> saying "Trying to reproduce" while you work on it, and "Bug Reproduced
> in version X" or "Bug not reproducible in version X" will suffice?
> That should at least be enough to keep people from trying to do the
> same thing, right?  Making sure a bug is assigned to the right
> "component" is also a good idea.  That way we the developers can
> prioritize the work that needs to be done, particularly if a bug is
> associated with a plugin like you describe.

> QUESTION: Who should have the authority to mark a bug as Resolved and
> then Closed in Jira?  I don't want to feel like I'm encroaching by
> going in there and changing the state of a bunch of open issues
> without getting some direction first.  I personally believe that bugs
> marked as Resolved should have a second step where someone else
> verifies that a bug no longer exists, but how should we handle it if a
> bug is not reproducible at all in the current version?  Should we
> Close as "Cannot Reproduce" right away, or make a note that it is not
> reproducible on some version and then have someone else do the same
> check just to be safe?  I'm sure it will also have a lot to do with
> who reported that it was not reproducible.  I'm sure the community
> would be much less likely to trust me than Kohsuke.

> @Alan, would you suggest that we take some of the more stale issues
> and post a comment asking the reporter(s) if they're still having the
> problem in the latest version?  It seems like the general idea I'm
> getting from everyone is that we should make an effort to confirm a
> bug's existence in these cases as well.

> On Feb 6, 8:27 pm, evernat <ever...@free.fr> wrote:
>> Hi Matt,

>> I fully agree with you that obsolete bugs should be closed, in order
>> for most users to know what are really the current issues and in order
>> for most developers to know what has to be fixed.
>> But I think that the 494 stale bugs can't be closed like that.
>> For example, a large number of issues were written by Kohsuke for
>> things to check or for things to fix (for example issue 5036).
>> A bug having a low priority for one year probably doesn't mean that it
>> doesn't need to be fixed.

>> I currently suggest that some, if not all, developers read each one of
>> the stale bugs inhttp://issues.jenkins-ci.org/secure/IssueNavigator.jspa?mode=hide&req...
>> and that we close them when necessary.

>> I will try to do that myself (instead of sleeping) and as Christoph
>> said:
>> - search actively for duplicates and close them [we may also read the
>> changelogs of releases]
>> - ask reporters about more details [if needed]
>>    - if bug is old and reporter doesn't respond in a timely manner,
>> then close it as 'not reproducible'

>> Matt: Because you are already a user, please choose some issues to be
>> tested and write your test results in the issues : it will save most
>> of the time needed by the developers to know if the stale issues can
>> be closed ! (and it may help you later to submit patchs)

>> bye,
>> Emeric

>> On 7 fév, 00:29, mlb5000 <baker.mat...@gmail.com> wrote:

>> > Things haven't completely calmed down since the rename yet, but I'd
>> > like to get started closing out some of these old issues if at all
>> > possible.  I noticed there was a "!CLOSED && STALE" query already on
>> > issues.jenkins-ci.org and I was wondering how we want to handle Bug
>> > reports that fall into this category.  An issue is considered STALE if
>> > it hasn't been updated within the last year.  I'd say that's a pretty
>> > good criteria for just calling it and closing the issue without
>> > discretion, but I don't personally have any insight into what some of
>> > those older bug reports might be, and the last thing I want is to
>> > upset the users.

>> > At any rate, does anyone have any (further) suggestions for how to
>> > handle these older bugs reports without having to go through them one
>> > by one?  Just to provide some perspective, 494 (http://issues.jenkins-
>> > ci.org/secure/IssueNavigator.jspa?mode=hide&requestId=10243) of the
>> > 1862 currently unresolved bug reports (http://issues.jenkins-ci.org/
>> > secure/IssueNavigator.jspa?mode=hide&requestId=10244) are considered
>> > stale.

>> > Also, would someone who has administrative privileges in the Jenkins
>> > Jira instance be able to add a Boolean field to the Bug issue type for
>> > marking whether or not a bug report has been Triaged, or does anyone
>> > have another way to keep track of whether a bug report has been
>> > vetted?

>> > On Jan 30, 12:13 pm, mlb5000 <baker.mat...@gmail.com> wrote:

>> > > Hi All,

>> > > Disclaimer: I'm only just joining this community so I absolutely want
>> > > those of you with more experience developing/fixing bugs in Hudson and
>> > > elsewhere to chime in on this conversation.  What I want to do is try
>> > > to come to some consensus on how Hudson bugs are to be identified,
>> > > disambiguated, prioritized, and ultimately, scheduled (more or less)
>> > > for a release.  This is part of what I hope will be a larger overall
>> > > effort to bring the Technical Debt I've observed since diving into the
>> > > source code into check.

>> > > As of right now there are 1853 open bugs in Hudson, of which the
>> > > average age is just under a year at 359 days.  Some users, myself
>> > > included, have been getting discouraged with cycle time on bugs,
>> > > particularly when the Continuous Integration server is supposed to be
>> > > the one thing you can most rely on.  When teams make their CI system
>> > > the heart and soul of their day-to-day development, testing,
>> > > configuration management, and release processes, they need to able to
>> > > rely on it.  If any tool can be categorized as mission-critical, it's
>> > > the CI system.

>> > > Here is what I am proposing:

>> > > 1. Users submit bug reports at issues.hudson-ci.org like they always
>> > > have.
>> > > 2. At some frequency (daily?, weekly?, as they pop up?), developers go
>> > > out and perform the following procedure:
>> > >   a. Pick the oldest non-triaged bug.
>> > >   b. Check whether or not the bug is a duplicate with another bug.
>> > > This will likely require aid from the more seasoned Hudson
>> > > contributors.
>> > >     i. If a duplicate exists but it has been resolved, I would
>> > > recommend not reopening it, but just linking the two issues together
>> > > so the person who goes to fix the current incantation of the bug can
>> > > use it as a resource if necessary.  Continue to the next step.
>> > >     ii. If a duplicate exists, but is still open, link the two issues
>> > > for future reference, Close the new one as Duplicate, and redirect all
>> > > users to the older one.  Go back to 2.a.
>> > >     iii. If no duplicate exists, continue.
>> > >   c. Is the bug reproducible in the most recent version of Hudson?  I
>> > > don't think it's worth verifying the bug in their reported version
>> > > since they'll ultimately have to upgrade to get the bug fix anyway, so
>> > > we might as well work towards the shortest path.
>> > >     i. If the bug is not reproducible in the latest version, close as
>> > > Cannot Reproduce and inform the user(s) that it appears to have been
>> > > fixed in version X, and go back to 2.a.
>> > >     ii. If the bug appears to still exist in the current version, note
>> > > which version it was verified in and continue.
>> > >   d. Gather as much information as possible from users.  What version
>> > > of the system is this bug occurring in?  What environment are they
>> > > using?  Did this error start occurring after an upgrade?  What version
>> > > did they upgrade to/from?  Are they able to work around the issue or
>> > > has it stopped their usage of Hudson in its tracks?  Ask any questions
>> > > that might help isolate the commit that introduced the bug, and help
>> > > other contributors make the best possible prioritization decisions.
>> > >   e. Set the priority of the issue based on some criteria.  I need
>> > > some suggestions from the community about what would be the best
>> > > criteria.  I would actually suggest trying to get an open source
>> > > license of GreenHopper from Atlassian.  Their ranking functionality
>> > > within GreenHopper works very well for this purpose since you rank
>> > > items relative to each other, not just with priorities.
>> > >   f. Mark the bug as triaged and if

> Yes, that would be an option.

> What we can also do is a more formal issue submission and QA process  
> (that I used successfully in several projects): use an additional  
> status (e.g., Submitted) that will be assigned to all created  
> issues. All those submitted issues need to be verified by the  
> assignee and could be then moved to the state Open. And for those  
> issues that don't get an assignee: here we need some volunteers who  
> are evaluating these issues e.g. on a daily or weekly basis (trying  
> to reproduce or write a comment to request additional information  
> from the reporter). All of our old open and unassigned issues could  
> be moved back to the Submitted state.

> Ulli

> I really like the idea of the comment "Reproduced in version X" or
> "unable to reproduce on Y platform" because it gives much more details
> than just the version tag or the issue status.

> Is there any way for a user to quickly describe his environment?
> I was thinking of a simple link "get installation details" reporting
> info like:
> - OS version for the master and each node
> - JDK used
> - Version of Jenkins and all plugins
> - job type (and eventually plugins used)

> This could to reproduce the issues related to plugins or specific
> platform.

> Cheers,
> Francois

>> Hi all,

>> I really like the idea of the comment "Reproduced in version X" or "unable
>> to reproduce on Y platform" because it gives much more details than just the
>> version tag or the issue status.

>> Is there any way for a user to quickly describe his environment?
>> I was thinking of a simple link "get installation details" reporting info
>> like:
>> - OS version for the master and each node
>> - JDK used
>> - Version of Jenkins and all plugins
>> - job type (and eventually plugins used)

>> This could to reproduce the issues related to plugins or specific
>> platform.

>> Cheers,
>> Francois

> I think this is not possible out of the box.

> However, one can write a simple plug-in (or core feature) that does add a
> create issue link to a Jenkins installation, that will open a pre-filled
> Jira create issue screen when clicked. Maybe we could use such a feature to
> replace the current log message 'Please report this bug at the mailing
> list...'.