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

2018-03-30 Thread 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

2018-03-30 Thread Kathy Lussier 
I like this. It addresses the core issue of bring important bugs to the 
attention of developers without resuming a practice of retargeting the 
milestones of a bunch of lower-priority bugs that may never get fixed.


+1

Kathy


On 03/30/2018 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


--
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
kluss...@masslnc.org
Twitter: http://www.twitter.com/kmlussier

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

2018-03-30 Thread 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

2018-03-30 Thread 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

2018-03-30 Thread 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

2018-03-30 Thread 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