Re: [OPEN-ILS-GENERAL] 2.8 release scheduling
On Thu, Dec 18, 2014 at 2:20 PM, Mike Rylander wrote: > > On Thu, Dec 18, 2014 at 12:11 PM, Bill Erickson > wrote: >> >> >> On Thu, Dec 18, 2014 at 8:29 AM, Mike Rylander >> wrote: >>> >>> Bill, >>> >>> First, thanks for putting out a timeline. >>> >>> I am a little concerned about the pre-beta feature freeze. In the past, >>> the merge deadline for features has always been "whatever makes it into the >>> beta release", and I don't see cutting that back by a week helping things >>> to get done faster -- we just end up with a week less features in 2.8, and >>> that last week is often (us being humans, and whatnot) the critical push >>> time for things that are almost there. Do you have something in mind that >>> I'm not seeing for the change there? >>> >> >> The feature freeze basically is the beta. (I recall now this was called >> the "beta cut-off" during the 2.6 cycle. I'll use this terminology going >> forward). The interval between the cut-off and beta release cutting is our >> chance to let the dust settle after the merge rush so we're not cutting a >> buggy beta. If Feb 18th is too soon, we can certainly push the beta back. >> >> > I won't fight you hard on the week between cut-off and beta wrapping, but > IMO it doesn't serve much purpose. Believe me, I know better than most that > betas often don't get the attention they deserve, and because of that it > feels (again, to me and maybe not to anyone else) like a week of doldrums. > But if you feel that week will help you shake things out as RM, I'll > mentally s/25/18/ the beta date > I didn't really explain my expectations of the cut-off interval very well. It's definitely helpful for the RM (finalizing the DB upgrade, compiling release notes, misc. cleanup, etc.), but to me it's more about developers testing this shiny new thing that we're about to call the Beta, particularly since it's the first time some of the features will be living together. A group sniff test, if you will. (e). I see your point about the doldrums, though. A week is probably too long. Let's push the beta cut-off up to the 20th? -b >
Re: [OPEN-ILS-GENERAL] 2.8 release scheduling
On Thu, Dec 18, 2014 at 12:11 PM, Bill Erickson wrote: > > > On Thu, Dec 18, 2014 at 8:29 AM, Mike Rylander > wrote: >> >> Bill, >> >> First, thanks for putting out a timeline. >> >> I am a little concerned about the pre-beta feature freeze. In the past, >> the merge deadline for features has always been "whatever makes it into the >> beta release", and I don't see cutting that back by a week helping things >> to get done faster -- we just end up with a week less features in 2.8, and >> that last week is often (us being humans, and whatnot) the critical push >> time for things that are almost there. Do you have something in mind that >> I'm not seeing for the change there? >> > > The feature freeze basically is the beta. (I recall now this was called > the "beta cut-off" during the 2.6 cycle. I'll use this terminology going > forward). The interval between the cut-off and beta release cutting is our > chance to let the dust settle after the merge rush so we're not cutting a > buggy beta. If Feb 18th is too soon, we can certainly push the beta back. > > I won't fight you hard on the week between cut-off and beta wrapping, but IMO it doesn't serve much purpose. Believe me, I know better than most that betas often don't get the attention they deserve, and because of that it feels (again, to me and maybe not to anyone else) like a week of doldrums. But if you feel that week will help you shake things out as RM, I'll mentally s/25/18/ the beta date > With my proposed schedule, the post-freeze period for 2.8 is already 2 > weeks shorter than it was for 2.7. So, if we push the beta back, we should > push back the mid-march release date as well. > Point taken. I'll consent that the winter time loss (vacations and such) is surely causing more time crunch than that week. > > >> >> I did note that the feature target deadline is not a hard deadline, but >> for my part I can say that with the schedule only being clarified over what >> amounts to 3 months (the remainder of December through release in >> mid-March), the middle of January will be a tight squeeze to target things >> by then. Being one that does a good bit of feature development, I expect >> to be begging leave to target features after the scheduled date on several >> smaller features, as dev time permits in January and February. I just want >> to set that expectation now, so it's not a surprise if it ends up >> happening... >> > > I am definitely expecting new features to emerge after the LP target > deadline. This deadline serves two purposes in my mind. 1. If you know > about it, document it, so others will know about it. 2. If you want to > introduce large architectural changes after this date, be prepared for > additional community scrutiny. > > Understood, and that makes sense, thanks. I was thinking of small things, not big architectural stuff, with my "head's up". > I was in no particular rush to publish the schedule with the assumption > that release schedules are highly predictable. Release mid-March/October, > beta cut-off a month before that, and everything else is gravy. For my own > sake and that of future RM's, is that not a reasonable assumption? > > I agree that should be a reasonable assumption. While it may just be a matter of terminology and taste, it seemed like there were some departures from the past (feature cutoff and beta wrapping offset, no alpha (which I agree with you on, fwiw)), so it felt less predictable (predicted?) to me. Thanks! --miker Thanks, > > -b > > > >> >> Thanks! >> >> >> -- >> Mike Rylander >> | President >> | Equinox Software, Inc. / The Open Source Experts >> | phone: 1-877-OPEN-ILS (673-6457) >> | email: mi...@esilibrary.com >> | web: http://www.esilibrary.com >> >> >> On Fri, Dec 12, 2014 at 4:07 PM, Bill Erickson >> wrote: >> >>> Hi All, >>> >>> I'm attempting to sketch out the release schedule for Evergreen 2.8, so >>> I'd like to run some dates/thoughts by everyone. >>> >>> For starters, unless someone requests it, I'm not planning to cut an >>> Alpha release. I've never seen anyone install one :). I'm happy to cut >>> one if desired, though. >>> >>> Proposed schedule: >>> >>> * Jan 14 2015: Feature Target Deadline >>> >>> This is the date where all features we expect to get into 2.8 are >>> documented in LP and targeted to 2.8. They do not have to be coded or >>> tagged as pull requests by this date. They just need to be documented. As >>> before, this is a strong recommendation, but not a hard deadline. >>> >>> Feb 18 2015: Feature Freeze >>> >>> From this date forward, only bug fixes may be committed to master. Any >>> un-merged features will be booted to 2.9. >>> >>> Feb 25 2015: 2.8.beta1 Release >>> >>> March 9 2015: 2.8.rc1 Release >>> >>> March 18 2015: 2.8.0 Release >>> >>> Comments/suggestions welcome. >>> >>> Note that in the future I'll avoid cross-posting to both -general and >>> -dev lists and just send 2.8 updates to -general to cut down on noise. >
Re: [OPEN-ILS-GENERAL] 2.8 release scheduling
Moving towards a more solidly time-based release has been a constant challenge, but predictably having a March / September (not October, heh) with a beta cut-off a month before actual RC and release seems to lay out the timeline pretty thoroughly. With some minor wiggle room applied by each release manager as they see fit based on what's actually happening at the time. I've been thinking about raising the idea of setting rough milestone objectives for the next whole year ahead of time so that there aren't any surprises about this, regardless of who's elected RM (and especially if the election of the RM takes longer and cuts into the 6 months allotted for each major release). Having an interval of time between cutting the first beta and stabilizing things post-merge sounds like a very smart idea. I ended up doing this by accident (or on purpose?) with my own one week delays in cutting releases after announcing business closed on merging. Officially the dates were listed out for 2.7, but unofficially, I ended up spending the follow-up week bug fixing / testing last details before actually cutting the releases. Having the time table established and announced this way lends more time for the broader community to participate in the testing process that we should be encouraging to occur. So I'm +1 to keeping this concept in place, if perhaps making minor adjustments to the dates. As far as pushing back the mid-March release date, that's not something I'm opposed with doing. Community-wise, we've never made any explicit promise for a release to occur by middle of the month, it's just nicer that way. That said, these are almost arbitrary lines in the sand sometimes. No matter what date we suggest, we'll still end up with unfinished, hanging threads that need to be cut and moved on to the next major milestone. That said, whenever we schedule the next developer meeting (maybe January now?), I think I'd like to re-raise the idea of evaluating whether March/September has worked out well for the major release months of the year. For myself, I still like the idea of April/October. But again...arbitrary lines in the sand. :) -- Ben On Thu, Dec 18, 2014 at 12:11 PM, Bill Erickson wrote: > > On Thu, Dec 18, 2014 at 8:29 AM, Mike Rylander wrote: >> >> Bill, >> >> First, thanks for putting out a timeline. >> >> I am a little concerned about the pre-beta feature freeze. In the past, >> the merge deadline for features has always been "whatever makes it into the >> beta release", and I don't see cutting that back by a week helping things to >> get done faster -- we just end up with a week less features in 2.8, and that >> last week is often (us being humans, and whatnot) the critical push time for >> things that are almost there. Do you have something in mind that I'm not >> seeing for the change there? > > > The feature freeze basically is the beta. (I recall now this was called the > "beta cut-off" during the 2.6 cycle. I'll use this terminology going > forward). The interval between the cut-off and beta release cutting is our > chance to let the dust settle after the merge rush so we're not cutting a > buggy beta. If Feb 18th is too soon, we can certainly push the beta back. > > With my proposed schedule, the post-freeze period for 2.8 is already 2 weeks > shorter than it was for 2.7. So, if we push the beta back, we should push > back the mid-march release date as well. > >> >> >> I did note that the feature target deadline is not a hard deadline, but >> for my part I can say that with the schedule only being clarified over what >> amounts to 3 months (the remainder of December through release in >> mid-March), the middle of January will be a tight squeeze to target things >> by then. Being one that does a good bit of feature development, I expect to >> be begging leave to target features after the scheduled date on several >> smaller features, as dev time permits in January and February. I just want >> to set that expectation now, so it's not a surprise if it ends up >> happening... > > > I am definitely expecting new features to emerge after the LP target > deadline. This deadline serves two purposes in my mind. 1. If you know > about it, document it, so others will know about it. 2. If you want to > introduce large architectural changes after this date, be prepared for > additional community scrutiny. > > I was in no particular rush to publish the schedule with the assumption that > release schedules are highly predictable. Release mid-March/October, beta > cut-off a month before that, and everything else is gravy. For my own sake > and that of future RM's, is that not a reasonable assumption? > > Thanks, > > -b > > >> >> >> Thanks! >> >> >> -- >> Mike Rylander >> | President >> | Equinox Software, Inc. / The Open Source Experts >> | phone: 1-877-OPEN-ILS (673-6457) >> | email: mi...@esilibrary.com >> | web: http://www.esilibrary.com >> >> >> On Fri, Dec 12, 2014 at 4:07 PM, Bill E
Re: [OPEN-ILS-GENERAL] 2.8 release scheduling
On Thu, Dec 18, 2014 at 8:29 AM, Mike Rylander wrote: > > Bill, > > First, thanks for putting out a timeline. > > I am a little concerned about the pre-beta feature freeze. In the past, > the merge deadline for features has always been "whatever makes it into the > beta release", and I don't see cutting that back by a week helping things > to get done faster -- we just end up with a week less features in 2.8, and > that last week is often (us being humans, and whatnot) the critical push > time for things that are almost there. Do you have something in mind that > I'm not seeing for the change there? > The feature freeze basically is the beta. (I recall now this was called the "beta cut-off" during the 2.6 cycle. I'll use this terminology going forward). The interval between the cut-off and beta release cutting is our chance to let the dust settle after the merge rush so we're not cutting a buggy beta. If Feb 18th is too soon, we can certainly push the beta back. With my proposed schedule, the post-freeze period for 2.8 is already 2 weeks shorter than it was for 2.7. So, if we push the beta back, we should push back the mid-march release date as well. > > I did note that the feature target deadline is not a hard deadline, but > for my part I can say that with the schedule only being clarified over what > amounts to 3 months (the remainder of December through release in > mid-March), the middle of January will be a tight squeeze to target things > by then. Being one that does a good bit of feature development, I expect > to be begging leave to target features after the scheduled date on several > smaller features, as dev time permits in January and February. I just want > to set that expectation now, so it's not a surprise if it ends up > happening... > I am definitely expecting new features to emerge after the LP target deadline. This deadline serves two purposes in my mind. 1. If you know about it, document it, so others will know about it. 2. If you want to introduce large architectural changes after this date, be prepared for additional community scrutiny. I was in no particular rush to publish the schedule with the assumption that release schedules are highly predictable. Release mid-March/October, beta cut-off a month before that, and everything else is gravy. For my own sake and that of future RM's, is that not a reasonable assumption? Thanks, -b > > Thanks! > > > -- > Mike Rylander > | President > | Equinox Software, Inc. / The Open Source Experts > | phone: 1-877-OPEN-ILS (673-6457) > | email: mi...@esilibrary.com > | web: http://www.esilibrary.com > > > On Fri, Dec 12, 2014 at 4:07 PM, Bill Erickson wrote: > >> Hi All, >> >> I'm attempting to sketch out the release schedule for Evergreen 2.8, so >> I'd like to run some dates/thoughts by everyone. >> >> For starters, unless someone requests it, I'm not planning to cut an >> Alpha release. I've never seen anyone install one :). I'm happy to cut >> one if desired, though. >> >> Proposed schedule: >> >> * Jan 14 2015: Feature Target Deadline >> >> This is the date where all features we expect to get into 2.8 are >> documented in LP and targeted to 2.8. They do not have to be coded or >> tagged as pull requests by this date. They just need to be documented. As >> before, this is a strong recommendation, but not a hard deadline. >> >> Feb 18 2015: Feature Freeze >> >> From this date forward, only bug fixes may be committed to master. Any >> un-merged features will be booted to 2.9. >> >> Feb 25 2015: 2.8.beta1 Release >> >> March 9 2015: 2.8.rc1 Release >> >> March 18 2015: 2.8.0 Release >> >> Comments/suggestions welcome. >> >> Note that in the future I'll avoid cross-posting to both -general and >> -dev lists and just send 2.8 updates to -general to cut down on noise. >> >> Thanks, everyone. >> >> -b >> >
Re: [OPEN-ILS-GENERAL] 2.8 release scheduling
Bill, First, thanks for putting out a timeline. I am a little concerned about the pre-beta feature freeze. In the past, the merge deadline for features has always been "whatever makes it into the beta release", and I don't see cutting that back by a week helping things to get done faster -- we just end up with a week less features in 2.8, and that last week is often (us being humans, and whatnot) the critical push time for things that are almost there. Do you have something in mind that I'm not seeing for the change there? I did note that the feature target deadline is not a hard deadline, but for my part I can say that with the schedule only being clarified over what amounts to 3 months (the remainder of December through release in mid-March), the middle of January will be a tight squeeze to target things by then. Being one that does a good bit of feature development, I expect to be begging leave to target features after the scheduled date on several smaller features, as dev time permits in January and February. I just want to set that expectation now, so it's not a surprise if it ends up happening... Thanks! -- Mike Rylander | President | Equinox Software, Inc. / The Open Source Experts | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com | web: http://www.esilibrary.com On Fri, Dec 12, 2014 at 4:07 PM, Bill Erickson wrote: > > Hi All, > > I'm attempting to sketch out the release schedule for Evergreen 2.8, so > I'd like to run some dates/thoughts by everyone. > > For starters, unless someone requests it, I'm not planning to cut an Alpha > release. I've never seen anyone install one :). I'm happy to cut one if > desired, though. > > Proposed schedule: > > * Jan 14 2015: Feature Target Deadline > > This is the date where all features we expect to get into 2.8 are > documented in LP and targeted to 2.8. They do not have to be coded or > tagged as pull requests by this date. They just need to be documented. As > before, this is a strong recommendation, but not a hard deadline. > > Feb 18 2015: Feature Freeze > > From this date forward, only bug fixes may be committed to master. Any > un-merged features will be booted to 2.9. > > Feb 25 2015: 2.8.beta1 Release > > March 9 2015: 2.8.rc1 Release > > March 18 2015: 2.8.0 Release > > Comments/suggestions welcome. > > Note that in the future I'll avoid cross-posting to both -general and -dev > lists and just send 2.8 updates to -general to cut down on noise. > > Thanks, everyone. > > -b >
Re: [OPEN-ILS-GENERAL] 2.8 release scheduling
Hi Bill, Dates look reasonable to me. Having gone through the alpha cutting stage myself now, I may agree with you that very few people tend to test them and provide feedback with the majority often waiting for the beta when more features have been added of note or substance. Or you know... just running directly off master and testing all along the way. ;) I am +1 to your proposed dates; it'll certainly help that we'll be coordinating the main release cutting alongside the current maintenance release dates. Looks like that'll help with the bug wrangling and getting happier releases out the door in general. Looking forward to seeing what's in the pipeline for 2.8! -- Ben On Fri, Dec 12, 2014 at 4:07 PM, Bill Erickson wrote: > Hi All, > > I'm attempting to sketch out the release schedule for Evergreen 2.8, so I'd > like to run some dates/thoughts by everyone. > > For starters, unless someone requests it, I'm not planning to cut an Alpha > release. I've never seen anyone install one :). I'm happy to cut one if > desired, though. > > Proposed schedule: > > * Jan 14 2015: Feature Target Deadline > > This is the date where all features we expect to get into 2.8 are documented > in LP and targeted to 2.8. They do not have to be coded or tagged as pull > requests by this date. They just need to be documented. As before, this is > a strong recommendation, but not a hard deadline. > > Feb 18 2015: Feature Freeze > > From this date forward, only bug fixes may be committed to master. Any > un-merged features will be booted to 2.9. > > Feb 25 2015: 2.8.beta1 Release > > March 9 2015: 2.8.rc1 Release > > March 18 2015: 2.8.0 Release > > Comments/suggestions welcome. > > Note that in the future I'll avoid cross-posting to both -general and -dev > lists and just send 2.8 updates to -general to cut down on noise. > > Thanks, everyone. > > -b -- Benjamin Shum Evergreen Systems Manager Bibliomation, Inc. 24 Wooster Ave. Waterbury, CT 06708 203-577-4070, ext. 113
[OPEN-ILS-GENERAL] 2.8 release scheduling
Hi All, I'm attempting to sketch out the release schedule for Evergreen 2.8, so I'd like to run some dates/thoughts by everyone. For starters, unless someone requests it, I'm not planning to cut an Alpha release. I've never seen anyone install one :). I'm happy to cut one if desired, though. Proposed schedule: * Jan 14 2015: Feature Target Deadline This is the date where all features we expect to get into 2.8 are documented in LP and targeted to 2.8. They do not have to be coded or tagged as pull requests by this date. They just need to be documented. As before, this is a strong recommendation, but not a hard deadline. Feb 18 2015: Feature Freeze >From this date forward, only bug fixes may be committed to master. Any un-merged features will be booted to 2.9. Feb 25 2015: 2.8.beta1 Release March 9 2015: 2.8.rc1 Release March 18 2015: 2.8.0 Release Comments/suggestions welcome. Note that in the future I'll avoid cross-posting to both -general and -dev lists and just send 2.8 updates to -general to cut down on noise. Thanks, everyone. -b
