Re: [OPEN-ILS-DEV] Proposed XUL bugfix merge policy for 3.0 and beyond

[Forrest, Stuart]

+1 here

***
Stuart Forrest PhD
Library Systems Specialist
Beaufort County Library System
843 255 6450
sforr...@bcgov.net

www.beaufortcountylibrary.org

For Leisure, For Learning, For Life


-Original Message-
From: Open-ils-dev [mailto:open-ils-dev-boun...@list.georgialibraries.org] On 
Behalf Of Boyer, Jason A
Sent: Thursday, August 03, 2017 12:11 PM
To: Evergreen Development Discussion List
Subject: Re: [OPEN-ILS-DEV] Proposed XUL bugfix merge policy for 3.0 and beyond

+1 From me. 

--
Jason Boyer
MIS Supervisor
Indiana State Library
http://library.in.gov/

> -Original Message-
> From: Open-ils-dev 
> [mailto:open-ils-dev-boun...@list.georgialibraries.org] On Behalf Of 
> Galen Charlton
> Sent: Wednesday, August 02, 2017 4:50 PM
> To: Evergreen Development Discussion List  d...@list.georgialibraries.org>
> Subject: [OPEN-ILS-DEV] Proposed XUL bugfix merge policy for 3.0 and 
> beyond
> 
>  This is an EXTERNAL email. Exercise caution. DO NOT open 
> attachments or click links from unknown senders or unexpected email. 
>  
> 
> Hi,
> 
> Following the discussion during the development meeting today, here's 
> a draft of a policy on merging XUL bugfixes once 3.0 is released, in 
> conjunction with the planned deprecation of the XUL staff client:
> 
>  START 
> Starting with the release of 3.0.0, patches that fix XUL bugs will not 
> be merged into master or backported unless they meet one or more of 
> the following conditions:
> 
> (a) the bug is a security issue
> (b) the bug involves the destruction of data
> (c) the bug is a regression of functionality in the XUL staff client 
> introduced by other work done to Evergreen
> 
> Under no circumstances will XUL staff client feature enhancements be merged.
> 
> This policy will continue through the 3.0.x and 3.1.x maintenance 
> release cycles, and will become moot upon the release of 3.2.0, when 
> the XUL staff client is slated to be entirely removed.
> --- END ---
> 
> One goal of a policy like this is to minimize scarce developer time 
> spent on fixing XUL issues in favor of having that time spent on 
> improving the web staff client. A secondary goal is to encourage 
> Evergreen sites to upgrade to 3.0 or 3.1 as soon as they can.
> 
> An implication of this, particularly if we adhere to a strict 
> interpretation of this policy (as I recommend we do) is that any XUL 
> client bugs on Launchpad that don't meet any of those criteria would 
> have their status changed to "won't fix". A further implication is 
> that if you want to get a particular XUL-only bugfix into Evergreen, 
> you have until the 3.0.0 release candidate is cut on 27 September to 
> get it in.
> 
> Of course, a strict interpretation of this policy presumes that 
> showstopper issues with the web staff client are addressed by 3.0.0, 
> or at least early in the 3.0.x maintenance release cycle.
> 
> Your feedback is requested. I am intentionally circulating this to 
> open-ils-dev first, but will subsequently make a broader announcement 
> once we have achieved consensus here.
> 
> Regards,
> 
> Galen
> --
> Galen Charlton
> Infrastructure and Added Services Manager Equinox Open Library 
> Initiative
> phone:  1-877-OPEN-ILS (673-6457)
> email:  g...@equinoxinitiative.org
> web:  https://equinoxInitiative.org
> direct: +1 770-709-5581
> cell:   +1 404-984-4366

Re: [OPEN-ILS-DEV] Proposed XUL bugfix merge policy for 3.0 and beyond

[Galen Charlton]

Hi,

On Thu, Aug 3, 2017 at 11:40 AM, Kathy Lussier  wrote:
> This was briefly discussed during yesterday's meeting, but to properly
> identify these showstopper issues, should we be setting showstopper web
> client bugs to a priority of 'high' in Launchpad? Or is there another way we
> should be identifying them?

For now, I suggest marking them as high. There may also be a use for a
releaseblocker tag or the like, but not until after the beta.

>> A further implication is
>> that if you want to get a particular XUL-only bugfix into Evergreen,
>> you have until the 3.0.0 release candidate is cut on 27 September to
>> get it in.
>
> I recently used a xulclient tag for bugs with a pullrequest tag where the
> fix only applied to the xul client. I thought it would be useful for
> identifying these bugs during the Feedback Fest where quicker action might
> be needed so that they are merged before the 3.0 release. There were only
> two bugs at the time, and one has since been merged. If future XUL-only bug
> fixes are submitted, it might be useful to use this tag to bring some
> attention to the bug before the September 27 cutoff.

Sounds like a good idea to me.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366

Re: [OPEN-ILS-DEV] Proposed XUL bugfix merge policy for 3.0 and beyond

[Boyer, Jason A]

+1 From me. 

--
Jason Boyer
MIS Supervisor
Indiana State Library
http://library.in.gov/

> -Original Message-
> From: Open-ils-dev [mailto:open-ils-dev-boun...@list.georgialibraries.org] On
> Behalf Of Galen Charlton
> Sent: Wednesday, August 02, 2017 4:50 PM
> To: Evergreen Development Discussion List  d...@list.georgialibraries.org>
> Subject: [OPEN-ILS-DEV] Proposed XUL bugfix merge policy for 3.0 and beyond
> 
>  This is an EXTERNAL email. Exercise caution. DO NOT open attachments or
> click links from unknown senders or unexpected email. 
> 
> 
> Hi,
> 
> Following the discussion during the development meeting today, here's
> a draft of a policy on merging XUL bugfixes once 3.0 is released, in
> conjunction with the planned deprecation of the XUL staff client:
> 
>  START 
> Starting with the release of 3.0.0, patches that fix XUL bugs will not
> be merged into master or backported unless they meet one or more of
> the following conditions:
> 
> (a) the bug is a security issue
> (b) the bug involves the destruction of data
> (c) the bug is a regression of functionality in the XUL staff client
> introduced by other work done to Evergreen
> 
> Under no circumstances will XUL staff client feature enhancements be merged.
> 
> This policy will continue through the 3.0.x and 3.1.x maintenance
> release cycles, and will become moot upon the release of 3.2.0, when
> the XUL staff client is slated to be entirely removed.
> --- END ---
> 
> One goal of a policy like this is to minimize scarce developer time
> spent on fixing XUL issues in favor of having that time spent on
> improving the web staff client. A secondary goal is to encourage
> Evergreen sites to upgrade to 3.0 or 3.1 as soon as they can.
> 
> An implication of this, particularly if we adhere to a strict
> interpretation of this policy (as I recommend we do) is that any XUL
> client bugs on Launchpad that don't meet any of those criteria would
> have their status changed to "won't fix". A further implication is
> that if you want to get a particular XUL-only bugfix into Evergreen,
> you have until the 3.0.0 release candidate is cut on 27 September to
> get it in.
> 
> Of course, a strict interpretation of this policy presumes that
> showstopper issues with the web staff client are addressed by 3.0.0,
> or at least early in the 3.0.x maintenance release cycle.
> 
> Your feedback is requested. I am intentionally circulating this to
> open-ils-dev first, but will subsequently make a broader announcement
> once we have achieved consensus here.
> 
> Regards,
> 
> Galen
> --
> Galen Charlton
> Infrastructure and Added Services Manager
> Equinox Open Library Initiative
> phone:  1-877-OPEN-ILS (673-6457)
> email:  g...@equinoxinitiative.org
> web:  https://equinoxInitiative.org
> direct: +1 770-709-5581
> cell:   +1 404-984-4366

Re: [OPEN-ILS-DEV] Proposed XUL bugfix merge policy for 3.0 and beyond

[Kathy Lussier]

+1 from me too, with a couple of follow-up questions/comments:


Of course, a strict interpretation of this policy presumes that
showstopper issues with the web staff client are addressed by 3.0.0,
or at least early in the 3.0.x maintenance release cycle.
This was briefly discussed during yesterday's meeting, but to properly 
identify these showstopper issues, should we be setting showstopper web 
client bugs to a priority of 'high' in Launchpad? Or is there another 
way we should be identifying them?



A further implication is
that if you want to get a particular XUL-only bugfix into Evergreen,
you have until the 3.0.0 release candidate is cut on 27 September to
get it in.
I recently used a xulclient tag for bugs with a pullrequest tag where 
the fix only applied to the xul client. I thought it would be useful for 
identifying these bugs during the Feedback Fest where quicker action 
might be needed so that they are merged before the 3.0 release. There 
were only two bugs at the time, and one has since been merged. If future 
XUL-only bug fixes are submitted, it might be useful to use this tag to 
bring some attention to the bug before the September 27 cutoff.


Thanks Galen!


On 08/03/2017 11:32 AM, Jason Etheridge wrote:

+1 from me as well :)



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

Re: [OPEN-ILS-DEV] Proposed XUL bugfix merge policy for 3.0 and beyond

[Jason Etheridge]

+1 from me as well :)

-- 
Jason Etheridge
Community and Migration Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  ja...@equinoxinitiative.org
web:  http://EquinoxInitiative.org