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

Wed Aug 29 11:22:56 EDT 2018

This all sounds good to me.

Kathy

-- 
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128klussier at masslnc.org

On Wed, Aug 29, 2018 at 11:19 AM Bill Erickson <berickxx at gmail.com> wrote:

>
> 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/f3960812/attachment-0001.html>