On Tue, Aug 28, 2018 at 7:39 PM Dan Wells <d...@calvin.edu> 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 <beric...@gmail.com> > 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 <kluss...@masslnc.org > <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<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> <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 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 > > >