Re: [OPEN-ILS-GENERAL] 3.2 Release schedule extension (was: feature freeze and more)
Hi, On Tue, Aug 28, 2018 at 6:11 PM Bill Erickson wrote: > Feature freeze pushed to Sept 4th. > XUL and Angular merge freeze Sept 7th. > Bug Squashing Sept 10-14 > Beta Sept 19th (remaining targets pushed back 2 weeks as well). I am for this revision to the schedule and also agree with Dan Wells' suggestions. Regards, Galen -- Galen Charlton Implementation and 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-GENERAL] 3.2 Release schedule extension (was: feature freeze and more)
This all sounds good to me. Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128kluss...@masslnc.org On Wed, Aug 29, 2018 at 11:19 AM Bill Erickson wrote: > > On Tue, Aug 28, 2018 at 7:39 PM Dan Wells wrote: > >> Bill, I think this sounds fine, but would make two possible suggestions. >> > > Thanks for the feedback, Dan. > > >> >> 1) I think we should get some kind of release built before bug-squashing >> week, to be usable for anyone wanting that sort of testing path during the >> following week. That could easily happen late on the 7th, or we could >> XUL/Angular merge on the 6th and have the 7th to build. Whether this is >> branded as an alpha or a beta1 doesn't matter too much, though if it is >> "feature complete", beta1 seems more correct. >> > > Good point. XUL merging will happen later, but again that should be a > relatively small change at the code level, so I'm fine calling the Sept 7 > build Beta 1. > > >> >> 2) It is reasonable to expect this might lead to a need for a beta2, but >> my preference would be to make that call a little later on, as needed. It >> is easy to add more delays, but assuming we'll need them all now means >> we'll never get the time back :) >> >> > Schedule update v3: > > Feature freeze Sept 4th. > Angular merge by Sept 6th. > Beta 1 Sept 7th. > Bug Squashing Sept 10-14 > XUL vote (and subsequent patching if approved) Sept 17th. > Remaining milestones TBD. > > -b > > >> Just my two cents. >> >> Dan >> >> >> From: Open-ils-general < >> open-ils-general-boun...@list.georgialibraries.org> on behalf of Bill >> Erickson >> Sent: Tuesday, August 28, 2018 6:11:01 PM >> To: Public Open-ILS tech discussion >> Cc: open-ils-general@list.georgialibraries.org >> Subject: [OPEN-ILS-GENERAL] 3.2 Release schedule extension (was: feature >> freeze and more) >> >> Breaking this message out specifically to discuss extending the 3.2 >> release schedule. >> >> We have a lot of competing priorities at the moment. This week really >> should be about wrapping up feature merges, but the pending Beta is forcing >> us to address a number of outstanding issues, and each depends on the other. >> >> Extending the release schedule seems perfectly reasonable to me. My only >> concern is determining how best to leverage the Sept 10-14 bug squashing >> week. Ideally, all major changes would be merged so we can work out the >> kinks during the group bug squashing. >> >> That means features, XUL removal, and Angular merging would need to be >> done by the end of next week, with time to spare to ensure all this chaos >> leaves us with a usable code base for testers. >> >> To buy us some breathing room in the short term, I'll make this proposal: >> >> Feature freeze pushed to Sept 4th. >> XUL and Angular merge freeze Sept 7th. >> Bug Squashing Sept 10-14 >> Beta Sept 19th (remaining targets pushed back 2 weeks as well). >> >> This may not be the extension you were hoping for Kathy, and we can >> certainly modify this, but this at least gives us a little time to focus >> specifically on wrapping up the big ticket items before bug squashing >> ensues. >> >> Suitable compromise for now? Thoughts? >> >> Thanks, >> >> -b >> >> >> >> >> On Tue, Aug 28, 2018 at 2:39 PM Kathy Lussier > <mailto:kluss...@masslnc.org>> wrote: >> Hi Bill, >> >> In looking at the list of showstoppers, I see one has a pullrequest, so >> it seems reasonable it could be tested and merged soon. For the other bugs, >> does anyone have a sense of whether any are particularly complex? Or are >> they mostly straightforward bugs that just haven't been addressed yet due >> to lack of tuits? If it's the latter, could we consider delaying the full >> release (with xul removal) until the showstoppers are fixed? >> >> I'm concerned about the breakage that is likely to occur the longer we >> continue to make the xul client available in our releases, but these bugs >> were identified as real issues in getting libraries to adopt the web >> client. At this time, there are just a handful of remaining showstoppers, >> and if we can commit to getting them resolved before the full release, I >> think it will make a smoother transition to 3.2 for our libraries. >> >> Kathy >> >> -- >> Kathy Lussier >> Project Coordina
Re: [OPEN-ILS-GENERAL] 3.2 Release schedule extension (was: feature freeze and more)
On Tue, Aug 28, 2018 at 7:39 PM Dan Wells wrote: > Bill, I think this sounds fine, but would make two possible suggestions. > Thanks for the feedback, Dan. > > 1) I think we should get some kind of release built before bug-squashing > week, to be usable for anyone wanting that sort of testing path during the > following week. That could easily happen late on the 7th, or we could > XUL/Angular merge on the 6th and have the 7th to build. Whether this is > branded as an alpha or a beta1 doesn't matter too much, though if it is > "feature complete", beta1 seems more correct. > Good point. XUL merging will happen later, but again that should be a relatively small change at the code level, so I'm fine calling the Sept 7 build Beta 1. > > 2) It is reasonable to expect this might lead to a need for a beta2, but > my preference would be to make that call a little later on, as needed. It > is easy to add more delays, but assuming we'll need them all now means > we'll never get the time back :) > > Schedule update v3: Feature freeze Sept 4th. Angular merge by Sept 6th. Beta 1 Sept 7th. Bug Squashing Sept 10-14 XUL vote (and subsequent patching if approved) Sept 17th. Remaining milestones TBD. -b > Just my two cents. > > Dan > > > From: Open-ils-general > on behalf of Bill Erickson > Sent: Tuesday, August 28, 2018 6:11:01 PM > To: Public Open-ILS tech discussion > Cc: open-ils-general@list.georgialibraries.org > Subject: [OPEN-ILS-GENERAL] 3.2 Release schedule extension (was: feature > freeze and more) > > Breaking this message out specifically to discuss extending the 3.2 > release schedule. > > We have a lot of competing priorities at the moment. This week really > should be about wrapping up feature merges, but the pending Beta is forcing > us to address a number of outstanding issues, and each depends on the other. > > Extending the release schedule seems perfectly reasonable to me. My only > concern is determining how best to leverage the Sept 10-14 bug squashing > week. Ideally, all major changes would be merged so we can work out the > kinks during the group bug squashing. > > That means features, XUL removal, and Angular merging would need to be > done by the end of next week, with time to spare to ensure all this chaos > leaves us with a usable code base for testers. > > To buy us some breathing room in the short term, I'll make this proposal: > > Feature freeze pushed to Sept 4th. > XUL and Angular merge freeze Sept 7th. > Bug Squashing Sept 10-14 > Beta Sept 19th (remaining targets pushed back 2 weeks as well). > > This may not be the extension you were hoping for Kathy, and we can > certainly modify this, but this at least gives us a little time to focus > specifically on wrapping up the big ticket items before bug squashing > ensues. > > Suitable compromise for now? Thoughts? > > Thanks, > > -b > > > > > On Tue, Aug 28, 2018 at 2:39 PM Kathy Lussier <mailto:kluss...@masslnc.org>> wrote: > Hi Bill, > > In looking at the list of showstoppers, I see one has a pullrequest, so it > seems reasonable it could be tested and merged soon. For the other bugs, > does anyone have a sense of whether any are particularly complex? Or are > they mostly straightforward bugs that just haven't been addressed yet due > to lack of tuits? If it's the latter, could we consider delaying the full > release (with xul removal) until the showstoppers are fixed? > > I'm concerned about the breakage that is likely to occur the longer we > continue to make the xul client available in our releases, but these bugs > were identified as real issues in getting libraries to adopt the web > client. At this time, there are just a handful of remaining showstoppers, > and if we can commit to getting them resolved before the full release, I > think it will make a smoother transition to 3.2 for our libraries. > > Kathy > > -- > Kathy Lussier > Project Coordinator > Massachusetts Library Network Cooperative > (508) 343-0128 > kluss...@masslnc.org<mailto:kluss...@masslnc.org> > > > On Mon, Aug 27, 2018 at 6:47 PM Bill Erickson beric...@gmail.com>> wrote: > Hi Scott, > > On Mon, Aug 27, 2018 at 5:24 PM scott.tho...@sparkpa.org scott.tho...@sparkpa.org> scott.tho...@sparkpa.org>> wrote: > Hi Bill, > I have two questions about this: > > > 1. You mentioned a vote. Who is the “we” that votes? > > Good question. This would be a core developer vote. I started typing > this as a developer list message, then added the general list just before > sending... > > From my perspective, this vote is more about getting
Re: [OPEN-ILS-GENERAL] 3.2 Release schedule extension (was: feature freeze and more)
Bill, I think this sounds fine, but would make two possible suggestions. 1) I think we should get some kind of release built before bug-squashing week, to be usable for anyone wanting that sort of testing path during the following week. That could easily happen late on the 7th, or we could XUL/Angular merge on the 6th and have the 7th to build. Whether this is branded as an alpha or a beta1 doesn't matter too much, though if it is "feature complete", beta1 seems more correct. 2) It is reasonable to expect this might lead to a need for a beta2, but my preference would be to make that call a little later on, as needed. It is easy to add more delays, but assuming we'll need them all now means we'll never get the time back :) Just my two cents. Dan From: Open-ils-general on behalf of Bill Erickson Sent: Tuesday, August 28, 2018 6:11:01 PM To: Public Open-ILS tech discussion Cc: open-ils-general@list.georgialibraries.org Subject: [OPEN-ILS-GENERAL] 3.2 Release schedule extension (was: feature freeze and more) Breaking this message out specifically to discuss extending the 3.2 release schedule. We have a lot of competing priorities at the moment. This week really should be about wrapping up feature merges, but the pending Beta is forcing us to address a number of outstanding issues, and each depends on the other. Extending the release schedule seems perfectly reasonable to me. My only concern is determining how best to leverage the Sept 10-14 bug squashing week. Ideally, all major changes would be merged so we can work out the kinks during the group bug squashing. That means features, XUL removal, and Angular merging would need to be done by the end of next week, with time to spare to ensure all this chaos leaves us with a usable code base for testers. To buy us some breathing room in the short term, I'll make this proposal: Feature freeze pushed to Sept 4th. XUL and Angular merge freeze Sept 7th. Bug Squashing Sept 10-14 Beta Sept 19th (remaining targets pushed back 2 weeks as well). This may not be the extension you were hoping for Kathy, and we can certainly modify this, but this at least gives us a little time to focus specifically on wrapping up the big ticket items before bug squashing ensues. Suitable compromise for now? Thoughts? Thanks, -b On Tue, Aug 28, 2018 at 2:39 PM Kathy Lussier mailto:kluss...@masslnc.org>> wrote: Hi Bill, In looking at the list of showstoppers, I see one has a pullrequest, so it seems reasonable it could be tested and merged soon. For the other bugs, does anyone have a sense of whether any are particularly complex? Or are they mostly straightforward bugs that just haven't been addressed yet due to lack of tuits? If it's the latter, could we consider delaying the full release (with xul removal) until the showstoppers are fixed? I'm concerned about the breakage that is likely to occur the longer we continue to make the xul client available in our releases, but these bugs were identified as real issues in getting libraries to adopt the web client. At this time, there are just a handful of remaining showstoppers, and if we can commit to getting them resolved before the full release, I think it will make a smoother transition to 3.2 for our libraries. Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org<mailto:kluss...@masslnc.org> On Mon, Aug 27, 2018 at 6:47 PM Bill Erickson mailto:beric...@gmail.com>> wrote: Hi Scott, On Mon, Aug 27, 2018 at 5:24 PM scott.tho...@sparkpa.org<mailto:scott.tho...@sparkpa.org> mailto:scott.tho...@sparkpa.org>> wrote: Hi Bill, I have two questions about this: 1. You mentioned a vote. Who is the “we” that votes? Good question. This would be a core developer vote. I started typing this as a developer list message, then added the general list just before sending... >From my perspective, this vote is more about getting a public record of >developer buy-in (or otherwise) as is typically the case before proceeding >with a large architectural change. It also acts as a "should we do this?" >safety valve. However, I call the vote now because in my opinion as RM we are >ready to proceed and I suspect that's what we'll decide. It's not done 'til >it's done, though. It's also worth reminding everyone we are also providing extended support for Evergreen 3.1, so users can continue using the XUL client for a longer period of time. Normally, a release is supported for 12 months of bug fixes, plus 3 months of security fixes. 3.1 will be supported for a longer period of time -- duration TBD -- so sites will have more time before needing to upgrade to 3.2. This will buy us more time in the community to continue squashing bugs as well. 2. If it is determined that not enough blocke
Re: [OPEN-ILS-GENERAL] 3.2 Release schedule extension (was: feature freeze and more)
It occurs to me the XUL removal patch will not be as architecturally significant as I had been thinking. We will not (yet) be deleting the entire directory tree, so the impact should be minimal for rest of the Evergreen code. Given that, extending the deadline for XUL removal a bit further makes sense. Updated proposal: Feature freeze Sept 4th. Angular merge by Sept 6th. Bug Squashing Sept 10-14 XUL vote (and subsequent removal if approved) Sept 17th. Beta Sept 19th (remaining targets pushed back 2 weeks as well). Perhaps we can squash some of these blockers during the bug squashing week. Comments welcome. -b On Tue, Aug 28, 2018 at 6:11 PM Bill Erickson wrote: > Breaking this message out specifically to discuss extending the 3.2 > release schedule. > > We have a lot of competing priorities at the moment. This week really > should be about wrapping up feature merges, but the pending Beta is forcing > us to address a number of outstanding issues, and each depends on the other. > > Extending the release schedule seems perfectly reasonable to me. My only > concern is determining how best to leverage the Sept 10-14 bug squashing > week. Ideally, all major changes would be merged so we can work out the > kinks during the group bug squashing. > > That means features, XUL removal, and Angular merging would need to be > done by the end of next week, with time to spare to ensure all this chaos > leaves us with a usable code base for testers. > > To buy us some breathing room in the short term, I'll make this proposal: > > Feature freeze pushed to Sept 4th. > XUL and Angular merge freeze Sept 7th. > Bug Squashing Sept 10-14 > Beta Sept 19th (remaining targets pushed back 2 weeks as well). > > This may not be the extension you were hoping for Kathy, and we can > certainly modify this, but this at least gives us a little time to focus > specifically on wrapping up the big ticket items before bug squashing > ensues. > > Suitable compromise for now? Thoughts? > > Thanks, > > -b > > > > > On Tue, Aug 28, 2018 at 2:39 PM Kathy Lussier > wrote: > >> Hi Bill, >> >> In looking at the list of showstoppers, I see one has a pullrequest, so >> it seems reasonable it could be tested and merged soon. For the other bugs, >> does anyone have a sense of whether any are particularly complex? Or are >> they mostly straightforward bugs that just haven't been addressed yet due >> to lack of tuits? If it's the latter, could we consider delaying the full >> release (with xul removal) until the showstoppers are fixed? >> >> I'm concerned about the breakage that is likely to occur the longer we >> continue to make the xul client available in our releases, but these bugs >> were identified as real issues in getting libraries to adopt the web >> client. At this time, there are just a handful of remaining showstoppers, >> and if we can commit to getting them resolved before the full release, I >> think it will make a smoother transition to 3.2 for our libraries. >> >> Kathy >> >> -- >> Kathy Lussier >> Project Coordinator >> Massachusetts Library Network Cooperative >> (508) 343-0128kluss...@masslnc.org >> >> >> >> On Mon, Aug 27, 2018 at 6:47 PM Bill Erickson wrote: >> >>> Hi Scott, >>> >>> On Mon, Aug 27, 2018 at 5:24 PM scott.tho...@sparkpa.org < >>> scott.tho...@sparkpa.org> wrote: >>> Hi Bill, I have two questions about this: 1. You mentioned a vote. Who is the “we” that votes? >>> Good question. This would be a core developer vote. I started typing >>> this as a developer list message, then added the general list just before >>> sending... >>> >>> From my perspective, this vote is more about getting a public record of >>> developer buy-in (or otherwise) as is typically the case before proceeding >>> with a large architectural change. It also acts as a "should we do this?" >>> safety valve. However, I call the vote now because in my opinion as RM we >>> are ready to proceed and I suspect that's what we'll decide. It's not done >>> 'til it's done, though. >>> >>> It's also worth reminding everyone we are also providing extended >>> support for Evergreen 3.1, so users can continue using the XUL client for a >>> longer period of time. Normally, a release is supported for 12 months of >>> bug fixes, plus 3 months of security fixes. 3.1 will be supported for a >>> longer period of time -- duration TBD -- so sites will have more time >>> before needing to upgrade to 3.2. This will buy us more time in the >>> community to continue squashing bugs as well. >>> 2. If it is determined that not enough blockers are fixed, does this mean that a 3.2 version of XUL will be made available and XUL will not be removed until 3.3 Yes, if the core developers vote not to proceed with XUL removal, it >>> would be delayed until the next release cycle (3.3). >>> >>> Just to offer some perspective, from the dev side it's not just a >>> question of how many web
[OPEN-ILS-GENERAL] 3.2 Release schedule extension (was: feature freeze and more)
Breaking this message out specifically to discuss extending the 3.2 release schedule. We have a lot of competing priorities at the moment. This week really should be about wrapping up feature merges, but the pending Beta is forcing us to address a number of outstanding issues, and each depends on the other. Extending the release schedule seems perfectly reasonable to me. My only concern is determining how best to leverage the Sept 10-14 bug squashing week. Ideally, all major changes would be merged so we can work out the kinks during the group bug squashing. That means features, XUL removal, and Angular merging would need to be done by the end of next week, with time to spare to ensure all this chaos leaves us with a usable code base for testers. To buy us some breathing room in the short term, I'll make this proposal: Feature freeze pushed to Sept 4th. XUL and Angular merge freeze Sept 7th. Bug Squashing Sept 10-14 Beta Sept 19th (remaining targets pushed back 2 weeks as well). This may not be the extension you were hoping for Kathy, and we can certainly modify this, but this at least gives us a little time to focus specifically on wrapping up the big ticket items before bug squashing ensues. Suitable compromise for now? Thoughts? Thanks, -b On Tue, Aug 28, 2018 at 2:39 PM Kathy Lussier wrote: > Hi Bill, > > In looking at the list of showstoppers, I see one has a pullrequest, so it > seems reasonable it could be tested and merged soon. For the other bugs, > does anyone have a sense of whether any are particularly complex? Or are > they mostly straightforward bugs that just haven't been addressed yet due > to lack of tuits? If it's the latter, could we consider delaying the full > release (with xul removal) until the showstoppers are fixed? > > I'm concerned about the breakage that is likely to occur the longer we > continue to make the xul client available in our releases, but these bugs > were identified as real issues in getting libraries to adopt the web > client. At this time, there are just a handful of remaining showstoppers, > and if we can commit to getting them resolved before the full release, I > think it will make a smoother transition to 3.2 for our libraries. > > Kathy > > -- > Kathy Lussier > Project Coordinator > Massachusetts Library Network Cooperative > (508) 343-0128kluss...@masslnc.org > > > > On Mon, Aug 27, 2018 at 6:47 PM Bill Erickson wrote: > >> Hi Scott, >> >> On Mon, Aug 27, 2018 at 5:24 PM scott.tho...@sparkpa.org < >> scott.tho...@sparkpa.org> wrote: >> >>> Hi Bill, >>> >>> I have two questions about this: >>> >>> >>> >>> 1. You mentioned a vote. Who is the “we” that votes? >>> >> Good question. This would be a core developer vote. I started typing >> this as a developer list message, then added the general list just before >> sending... >> >> From my perspective, this vote is more about getting a public record of >> developer buy-in (or otherwise) as is typically the case before proceeding >> with a large architectural change. It also acts as a "should we do this?" >> safety valve. However, I call the vote now because in my opinion as RM we >> are ready to proceed and I suspect that's what we'll decide. It's not done >> 'til it's done, though. >> >> It's also worth reminding everyone we are also providing extended support >> for Evergreen 3.1, so users can continue using the XUL client for a longer >> period of time. Normally, a release is supported for 12 months of bug >> fixes, plus 3 months of security fixes. 3.1 will be supported for a longer >> period of time -- duration TBD -- so sites will have more time before >> needing to upgrade to 3.2. This will buy us more time in the community to >> continue squashing bugs as well. >> >>> 2. If it is determined that not enough blockers are fixed, does >>> this mean that a 3.2 version of XUL will be made available and XUL will not >>> be removed until 3.3 >>> >>> Yes, if the core developers vote not to proceed with XUL removal, it >> would be delayed until the next release cycle (3.3). >> >> Just to offer some perspective, from the dev side it's not just a >> question of how many web staff blockers remain, but how much work is >> required to resolve each, who can sign up to fix them, how many sites they >> likely affect, how much developer time will be siphoned away from fixing >> these issues trying to maintain XUL in 3.2 (!), the fact the XUL is already >> a little bit broken in 3.2 based on the agreement it would it would be >> removed, etc, etc. >> >> Thanks, >> >> -b >> >> >>
