[OPEN-ILS-GENERAL] 3.2 Release schedule extension (was: feature freeze and more)

[Bill Erickson]

On Tue, Aug 28, 2018 at 7:39 PM Dan Wells <dbw2 at 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-bounces at list.georgialibraries.org>
> on behalf of Bill Erickson <berickxx at gmail.com>
> Sent: Tuesday, August 28, 2018 6:11:01 PM
> To: Public Open-ILS tech discussion
> Cc: open-ils-general at 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 <klussier at masslnc.org
> <mailto:klussier at 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
> klussier at masslnc.org<mailto:klussier at masslnc.org>
>
>
> On Mon, Aug 27, 2018 at 6:47 PM Bill Erickson <berickxx at gmail.com<mailto:
> berickxx at gmail.com>> wrote:
> Hi Scott,
>
> On Mon, Aug 27, 2018 at 5:24 PM scott.thomas at sparkpa.org<mailto:
> scott.thomas at sparkpa.org> <scott.thomas at sparkpa.org<mailto:
> scott.thomas at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20180829/95d1260f/attachment.html>