This all sounds good to me. Kathy
-- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) [email protected] On Wed, Aug 29, 2018 at 11:19 AM Bill Erickson <[email protected]> wrote: > > On Tue, Aug 28, 2018 at 7:39 PM Dan Wells <[email protected]> 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 < >> [email protected]> on behalf of Bill >> Erickson <[email protected]> >> Sent: Tuesday, August 28, 2018 6:11:01 PM >> To: Public Open-ILS tech discussion >> Cc: [email protected] >> 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 <[email protected] >> <mailto:[email protected]>> 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 >> [email protected]<mailto:[email protected]> >> >> >> On Mon, Aug 27, 2018 at 6:47 PM Bill Erickson <[email protected]<mailto: >> [email protected]>> wrote: >> Hi Scott, >> >> On Mon, Aug 27, 2018 at 5:24 PM [email protected]<mailto: >> [email protected]> <[email protected]<mailto: >> [email protected]>> 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 >> >> >>
