Re: [OPEN-ILS-GENERAL] Proposed Change to LP Bug Tracking

[Jason Stephenson]

Dan, et al.

I always assumed the RM has final say on bugs for their releases and
branches, so I don't really see this as a change.

So, sure. I think it is OK.

Jason

Re: [OPEN-ILS-GENERAL] Proposed Change to LP Bug Tracking

[Rogan Hamby]

Sounds sane to me.


Rogan Hamby, MLIS

Data and Project Analyst

Equinox Open Library Initiative

phone:  1-877-OPEN-ILS (673-6457)

email:  ro...@equinoxinitiative.org
web:  http://EquinoxInitiative.org

On Fri, Mar 30, 2018 at 10:35 AM, Bill Erickson  wrote:

> I like it, Dan.  Thanks for the proposal.
>
> -b
>
> On Fri, Mar 30, 2018 at 10:08 AM, Terran McCanna <
> tmcca...@georgialibraries.org> wrote:
>
>> I think that's an excellent plan.
>>
>> Terran McCanna
>> PINES Program Manager
>> Georgia Public Library Service
>> 1800 Century Place, Suite 150
>> 
>> Atlanta, GA 30345
>> 
>> 404-235-7138 <(404)%20235-7138>
>> tmcca...@georgialibraries.org
>>
>>
>> On Fri, Mar 30, 2018 at 10:00 AM, Daniel Wells  wrote:
>>
>>> Hello all,
>>>
>>> Our current practice is to only allow bugs to be targeted to a release
>>> only if there is code ready for testing.  This change was made several
>>> years back to help focus community efforts on testing of existing fixes,
>>> and also to avoid a lot of extra work in constantly moving huge numbers of
>>> bugs from milestone to milestone when no effort was being made to actually
>>> address them.  Overall, this change has worked as intended, and has greatly
>>> helped cases where branches would previously sit for months (or years)
>>> without inclusion into the shared codebase, or at least feedback.
>>>
>>> Unfortunately, this practice has also left a hole where some of our
>>> worst bugs are not getting the attention they deserve.  While we met our
>>> goal of satisfying all the "High" priority bugs targeted at 3.1 before
>>> final release, we currently have 25 other "High" priority bugs not targeted
>>> at any 3.1 milestone at all.  I am not sure how others work, but at least
>>> for me, as a release approaches, I am focused almost exclusively on the
>>> activity for bugs within the next release milestone, and it is therefore
>>> easy to lose track of important bugs where no branch has been offered (as
>>> those bugs, by current standards, remain untargeted).
>>>
>>> The natural solution, of course, is to target important bugs even before
>>> any solution exists.  (This does happen in some cases already.)  The
>>> challenge, then is to do this without again causing the issues we've faced
>>> in the past.  As stated, we currently have 25 such bugs, so it seems we
>>> aren't in imminent danger of a sudden deluge.  Still, I think we should
>>> have some modest standards to keep the bug flow reasonable and usable.
>>> With that in mind, here is a proposed starting point to work from:
>>>
>>> 1. Any bug with a status of "High" or "Critical" can be targeted to a
>>> milestone by the release manager/maintainer at any time.
>>> 2. Any High/Critical bug with at least 3 "affects me too" votes can be
>>> targeted to a milestone at any time by anyone.
>>> 3. A targeted High/Critical bug with no pullrequest is not a guarantee
>>> of inclusion the next release.  Timely releases are required for getting
>>> existing committed fixes to end users, so any delay for a High/Critical bug
>>> with no pullrequest will remain at the discretion of the release
>>> manager/maintainer.
>>>
>>> Overall, this is a very minor change, but given the cooperative nature
>>> of our community, there is little which can be done to actually force
>>> action on these bugs.  The goal, instead, is to make sure those responsible
>>> for releases are well aware of community needs, and also requiring us to at
>>> least confront any such bugs at each release time.
>>>
>>> Feedback is welcome!
>>>
>>> Sincerely,
>>> Dan
>>>
>>
>>
>

Re: [OPEN-ILS-GENERAL] Proposed Change to LP Bug Tracking

[Bill Erickson]

I like it, Dan.  Thanks for the proposal.

-b

On Fri, Mar 30, 2018 at 10:08 AM, Terran McCanna <
tmcca...@georgialibraries.org> wrote:

> I think that's an excellent plan.
>
> Terran McCanna
> PINES Program Manager
> Georgia Public Library Service
> 1800 Century Place, Suite 150
> 
> Atlanta, GA 30345
> 
> 404-235-7138 <(404)%20235-7138>
> tmcca...@georgialibraries.org
>
>
> On Fri, Mar 30, 2018 at 10:00 AM, Daniel Wells  wrote:
>
>> Hello all,
>>
>> Our current practice is to only allow bugs to be targeted to a release
>> only if there is code ready for testing.  This change was made several
>> years back to help focus community efforts on testing of existing fixes,
>> and also to avoid a lot of extra work in constantly moving huge numbers of
>> bugs from milestone to milestone when no effort was being made to actually
>> address them.  Overall, this change has worked as intended, and has greatly
>> helped cases where branches would previously sit for months (or years)
>> without inclusion into the shared codebase, or at least feedback.
>>
>> Unfortunately, this practice has also left a hole where some of our worst
>> bugs are not getting the attention they deserve.  While we met our goal of
>> satisfying all the "High" priority bugs targeted at 3.1 before final
>> release, we currently have 25 other "High" priority bugs not targeted at
>> any 3.1 milestone at all.  I am not sure how others work, but at least for
>> me, as a release approaches, I am focused almost exclusively on the
>> activity for bugs within the next release milestone, and it is therefore
>> easy to lose track of important bugs where no branch has been offered (as
>> those bugs, by current standards, remain untargeted).
>>
>> The natural solution, of course, is to target important bugs even before
>> any solution exists.  (This does happen in some cases already.)  The
>> challenge, then is to do this without again causing the issues we've faced
>> in the past.  As stated, we currently have 25 such bugs, so it seems we
>> aren't in imminent danger of a sudden deluge.  Still, I think we should
>> have some modest standards to keep the bug flow reasonable and usable.
>> With that in mind, here is a proposed starting point to work from:
>>
>> 1. Any bug with a status of "High" or "Critical" can be targeted to a
>> milestone by the release manager/maintainer at any time.
>> 2. Any High/Critical bug with at least 3 "affects me too" votes can be
>> targeted to a milestone at any time by anyone.
>> 3. A targeted High/Critical bug with no pullrequest is not a guarantee of
>> inclusion the next release.  Timely releases are required for getting
>> existing committed fixes to end users, so any delay for a High/Critical bug
>> with no pullrequest will remain at the discretion of the release
>> manager/maintainer.
>>
>> Overall, this is a very minor change, but given the cooperative nature of
>> our community, there is little which can be done to actually force action
>> on these bugs.  The goal, instead, is to make sure those responsible for
>> releases are well aware of community needs, and also requiring us to at
>> least confront any such bugs at each release time.
>>
>> Feedback is welcome!
>>
>> Sincerely,
>> Dan
>>
>
>

Re: [OPEN-ILS-GENERAL] Proposed Change to LP Bug Tracking

[Terran McCanna]

I think that's an excellent plan.

Terran McCanna
PINES Program Manager
Georgia Public Library Service
1800 Century Place, Suite 150
Atlanta, GA 30345
404-235-7138
tmcca...@georgialibraries.org


On Fri, Mar 30, 2018 at 10:00 AM, Daniel Wells  wrote:

> Hello all,
>
> Our current practice is to only allow bugs to be targeted to a release
> only if there is code ready for testing.  This change was made several
> years back to help focus community efforts on testing of existing fixes,
> and also to avoid a lot of extra work in constantly moving huge numbers of
> bugs from milestone to milestone when no effort was being made to actually
> address them.  Overall, this change has worked as intended, and has greatly
> helped cases where branches would previously sit for months (or years)
> without inclusion into the shared codebase, or at least feedback.
>
> Unfortunately, this practice has also left a hole where some of our worst
> bugs are not getting the attention they deserve.  While we met our goal of
> satisfying all the "High" priority bugs targeted at 3.1 before final
> release, we currently have 25 other "High" priority bugs not targeted at
> any 3.1 milestone at all.  I am not sure how others work, but at least for
> me, as a release approaches, I am focused almost exclusively on the
> activity for bugs within the next release milestone, and it is therefore
> easy to lose track of important bugs where no branch has been offered (as
> those bugs, by current standards, remain untargeted).
>
> The natural solution, of course, is to target important bugs even before
> any solution exists.  (This does happen in some cases already.)  The
> challenge, then is to do this without again causing the issues we've faced
> in the past.  As stated, we currently have 25 such bugs, so it seems we
> aren't in imminent danger of a sudden deluge.  Still, I think we should
> have some modest standards to keep the bug flow reasonable and usable.
> With that in mind, here is a proposed starting point to work from:
>
> 1. Any bug with a status of "High" or "Critical" can be targeted to a
> milestone by the release manager/maintainer at any time.
> 2. Any High/Critical bug with at least 3 "affects me too" votes can be
> targeted to a milestone at any time by anyone.
> 3. A targeted High/Critical bug with no pullrequest is not a guarantee of
> inclusion the next release.  Timely releases are required for getting
> existing committed fixes to end users, so any delay for a High/Critical bug
> with no pullrequest will remain at the discretion of the release
> manager/maintainer.
>
> Overall, this is a very minor change, but given the cooperative nature of
> our community, there is little which can be done to actually force action
> on these bugs.  The goal, instead, is to make sure those responsible for
> releases are well aware of community needs, and also requiring us to at
> least confront any such bugs at each release time.
>
> Feedback is welcome!
>
> Sincerely,
> Dan
>

[OPEN-ILS-GENERAL] Proposed Change to LP Bug Tracking

[Daniel Wells]

Hello all,

Our current practice is to only allow bugs to be targeted to a release only
if there is code ready for testing.  This change was made several years
back to help focus community efforts on testing of existing fixes, and also
to avoid a lot of extra work in constantly moving huge numbers of bugs from
milestone to milestone when no effort was being made to actually address
them.  Overall, this change has worked as intended, and has greatly helped
cases where branches would previously sit for months (or years) without
inclusion into the shared codebase, or at least feedback.

Unfortunately, this practice has also left a hole where some of our worst
bugs are not getting the attention they deserve.  While we met our goal of
satisfying all the "High" priority bugs targeted at 3.1 before final
release, we currently have 25 other "High" priority bugs not targeted at
any 3.1 milestone at all.  I am not sure how others work, but at least for
me, as a release approaches, I am focused almost exclusively on the
activity for bugs within the next release milestone, and it is therefore
easy to lose track of important bugs where no branch has been offered (as
those bugs, by current standards, remain untargeted).

The natural solution, of course, is to target important bugs even before
any solution exists.  (This does happen in some cases already.)  The
challenge, then is to do this without again causing the issues we've faced
in the past.  As stated, we currently have 25 such bugs, so it seems we
aren't in imminent danger of a sudden deluge.  Still, I think we should
have some modest standards to keep the bug flow reasonable and usable.
With that in mind, here is a proposed starting point to work from:

1. Any bug with a status of "High" or "Critical" can be targeted to a
milestone by the release manager/maintainer at any time.
2. Any High/Critical bug with at least 3 "affects me too" votes can be
targeted to a milestone at any time by anyone.
3. A targeted High/Critical bug with no pullrequest is not a guarantee of
inclusion the next release.  Timely releases are required for getting
existing committed fixes to end users, so any delay for a High/Critical bug
with no pullrequest will remain at the discretion of the release
manager/maintainer.

Overall, this is a very minor change, but given the cooperative nature of
our community, there is little which can be done to actually force action
on these bugs.  The goal, instead, is to make sure those responsible for
releases are well aware of community needs, and also requiring us to at
least confront any such bugs at each release time.

Feedback is welcome!

Sincerely,
Dan