Subject: Re: Releases: 2.2.1 and 2.3 - msg#00669

Previous Message by Date: click to view message preview

bugs.sakaiproject.org not responding

JIRA has not been responding for the past couple hours. Sorry if this was a planned outage. Jim Jim Eng jimeng@xxxxxxxxx ---------------------- This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Development site. You can modify how you receive notifications at My Workspace > Preferences.

Next Message by Date: click to view message preview

Re: Releases: 2.2.1 and 2.3

2006/7/29, Glenn R. Golden <ggolden@xxxxxxxxx>: 2.2.1 was not "rushed". It was a 4 week maintenance release, which could be quite normal. We might find we want more time, such as 6 weeks, but in either case, we cannot call it rushed ... ... <snip> ... I don't see any justification for "diminished confidence" in this release. I have to say I'm a bit surprised at this. There were nine weeks between the releases of 2.0.0 and 2.0.1, eleven weeks between the releases of 2.1.0 and 2.1.1. The first QA tag for 2.2.1 was cut this last Wednesday, and code freeze is this coming Tuesday. There will be just shy of three weeks between the first QA tag and the release. If it's not concerning, it is at least remarkable. We might also in our reckoning add to the shortness of time a shortage of QA resources. Now perhaps there are other, ameliorating factors, and the final assessment is one about which reasonable people may differ, but I think we have to acknowledge that there is justification for doubt. 2.2.2 *will* follow 4-6 weeks later, right on schedule. Don't let this new way of handling maintenance releases interfere with our feature release (i.e. 2.3) plans. I don't mean to make it sound like an interference (and I'm sorry if it does), but rather a positive attempt to apply limited resources to where they will be most profitable. There are positive developments in the testing sphere - ranging from Linda's push for load testing, through Alan Berg's code reviews, to Megan's push to do QA with actual production data. These are initiatives that should be harnessed, they could take a little time to sort out, and I don't want to see us rush past all that, either. I want to see us make the most of it. * * * The 2.3 release, which would be released in November, is really for lots of different folks. The brave (foolish?) will use it for winter term. The slightly reserved could use it for spring/summer '07 term. Those with more deliberation in their process might use it for the fall 07 term. It would help to know what the 2.3 release would include, and that may be a perspective I'm missing. All I'm able to see is the request of the development teams to try to identify what they can accomplish in the way of new features between now and mid-September. I can't help but wonder if our results might be more impressive for the coming year if we said that our next code freeze would be in March, and for the Fall the dev teams - while beginning their feature work - would also be encouraged to address a code review of the sort that Alan Berg has been so assiduously refining. We could even promote it as a "Q" cycle (as opposed to "QA"). This wouldn't seem like an interference to me, but a really positive step forward. This community needs to get used to working feature releases at the same time as maintenance releases, and get used to working on many different maintenance branches. Why? Because this is what we want. Or is it? That is up to us to decide, and to reflect in our release document. And if we decide that we want it, we also have to commit to doing it. The new schedule is appealing in the abstract, but I find something unnerving in the planning: how it doesn't seem to be taking into account our practical history and limitations (e.g. the perpetual 4-6 week maintenance release cycle). It has the vague feel of writing checks against an account we're not balancing. Abstracted. There is an emphasis on round figures and schedules over more pragmatic questions of available resources and a cycle that can harness our particular volunteers. I don't think we can, for example, simply say that there is a 4-6 week maintenance release cycle which can occur whenever it's scheduled. The length of time is not really as significant as the scope of the volunteer effort. I think many people make a special effort for the QA of a release, and it's not the sort of special effort they can afford to make year-round. Releases drain people. We need to think about making the most of them during the time when it makes the most sense to them - i.e., when it can fit in more neatly with local work they need to be doing. Perhaps a discussion of what we want should also be accompanied by a discussion of what we can afford. ~Clay 2006/7/29, Glenn R. Golden <ggolden@xxxxxxxxx>: I encourage this discussion, but I am concerned about some of the point that you make, Clay. I want to challenge some of them, and also want to clarify some more about the details and reasonings behind the release document currently in review. * * * 2.2.1 was not "rushed". It was a 4 week maintenance release, which could be quite normal. We might find we want more time, such as 6 weeks, but in either case, we cannot call it rushed. This is how a maintenance release will happen - a short period of bug fixes, then packaging and verification and release. Meanwhile the next short period is happening, etc. Why? Because this is what we as a community wants to have, and what we as a community are willing to do. Or is it? Lets get that clear in our release document. I don't see any justification for "diminished confidence" in this release. It is a fine example of a maintenance release. 2.2.2 *will* follow 4-6 weeks later, right on schedule. Don't let this new way of handling maintenance releases interfere with our feature release (i.e. 2.3) plans. * * * The 2.3 release, which would be released in November, is really for lots of different folks. The brave (foolish?) will use it for winter term. The slightly reserved could use it for spring/summer '07 term. Those with more deliberation in their process might use it for the fall 07 term. The point is that we want to start establishing a regular series of features releases with known fixed (and not slipped) dates so folks can make their plans. * * * The 2.3 release plans are not "hurried". They would just be over a shorter time period. 2.3 will have fewer new features than it would have had we started working on it in March. 2.4, which, if we follow the proposed schedule, we will work on from Sep 15 till next Mar 15, will likely have more features. * * * 2.3 will not slip past the deadline. We will make sure of that. It may shrink, but we will meet the timeline. In some sense, the timeline is more important than specific features, but less important than quality. * * * This community needs to get used to working feature releases at the same time as maintenance releases, and get used to working on many different maintenance branches. Why? Because this is what we want. Or is it? That is up to us to decide, and to reflect in our release document. And if we decide that we want it, we also have to commit to doing it. * * * Ok, now I'll lobby for 2.3 in Nov '06. I think the best reason to do this, other than to get on track with our proposed schedule, is to get *some* features into a packaged release before next March. This is to help us adjust to BUG FIX ONLY maintenance releases. If we have to wait for 2.3 till next March to get on our schedule, it will be hard to resist temptation to put in "just a few" features into the 2.2.x maintenance releases and branch. And we have seen in the past how that makes maintenance releases fail to deliver their mission, and fail to deliver quickly, and blur into feature releases. - Glenn Glenn R. Golden Software Architect, University Of Michigan ggolden@xxxxxxxxx [see attachment: "message0.html", size: 4853 bytes] Attachments: message0.html https://collab.sakaiproject.org//access/content/attachment/4ee742de-3db1-42c8-00ca-e66d8576209e/message0.html ---------------------- This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Development site. You can modify how you receive notifications at My Workspace > Preferences. ---------------------- This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Development site. You can modify how you receive notifications at My Workspace > Preferences.

Previous Message by Thread: click to view message preview

Re: Releases: 2.2.1 and 2.3

These are solid points Clay. I'm in favor of this approach and would be interested in fleshing it out or understanding why it's not feasible. Chris. On 7/29/06 8:49 AM, "Clay Fenlason" <clayf@xxxxxx> wrote: > I want to float an idea: what if we forego a 2.3 release, and instead > put all the extra development energy into actually meeting a code > freeze in the Spring? My reasons are as follows: > > 1) Since the time is so short, and people are otherwise preoccupied, I > fear the inevitable result of a hurried 2.3 schedule is yet another > code freeze slippage, so that instead of adjusting to a new schedule > we'll simply be reinforcing a bad pattern. > > 2) There are reasons to have diminished confidence in the hurried > 2.2.1 maintenance release, such that another maintenance release is > probably desired. > > 3) A 2.2.2 maintenance release - with an all-hands-on-deck QA cycle - > is probably more valuable for the community than a 2.3 release with a > terse feature introduction. Only a handful of deploying schools are > already on 2.2, and the ones that did just make that move are unlikely > to want to hop to a new feature release so soon, especially with few > new features to argue for it. > > 4) Winter upgrades (for those in the Northern hemisphere) are now > generally considered unwise, especially with a *.0 release. > > 5) If this is all the case, and a majority of schools are more > interested in 2.2 maintenance than 2.3, QA data points and volunteers > will be more easy to come by for a 2.2.2 release than a 2.3.0 release, > since the volunteer work will dovetail more nicely with local needs > and pressures. > > I can certainly understand and favor the desire to adapt to an > improved schedule, but I'm not sure that this 2.3 hop, following a > hurried 2.2.1, is the best foot forward. > > ~Clay > > 2006/7/28, Glenn R. Golden <ggolden@xxxxxxxxx>: >> We are in the process of getting two releases ready. Please take a >> look a the release document that the SCP is currently working to >> refine and get community acceptance: >> >> http://bugs.sakaiproject.org/confluence/display/SCP/Sakai+Releases >> >> Based on the ideas in the document... >> >> * * * >> >> Sakai 2.2.1 >> >> We are planning on releasing the first maintenance release of the 2.2 >> feature release on August 15. Code freeze for this is August 1. Our >> goal in making this release work is to continue working on fixes (bug >> fixes only) until August 1. At that point, we are DONE with work on >> making fixes for 2.2.1. The two weeks following August 1 are to >> verify and package the release. >> >> August 15 has been identified as an important date for folks using >> 2.2 this fall. >> >> If we find that we have introduced a new problem into the 2.2.1 code >> as of August 1, we have the option to REMOVE the change that caused >> it from the 2.2.1 release, in effect reverting that part of the code >> back to 2.2.0. Otherwise we are just verifying what fixes we have >> made so we know what to tell folks. >> >> This process of removal only is to assure that we can verify and >> package in the two weeks we are giving this. It is also a >> recognition that the next maintenance release is only 4-6 weeks later >> (yet to be determined), and that the maintenance branch (2.2.x) is >> available for those needing something that is not in the verified and >> packaged release. >> >> Work for 2.2.1 is done first in the trunks, and then selectively >> merged by either the application teams or the release manager (Lance) >> into the 2.2.x branches. >> >> After August 1, fixes can continue to be added to the trunks and >> branches, but they will not end up in the 2.2.1 release. >> >> On August 1 we will make a tag from the 2.2.x branch for the 2.2.1 >> release. If we find we need to make further changes, we can do so >> from the tag. >> >> * * * >> >> Sakai 2.3 >> >> The next feature release is 2.3, scheduled for a Sep 15 code freeze, >> and a Nov 1 release. This is a shorter than usual period, since 2.2 >> got a late end, but I encourage us to do it anyway to get into the >> proposed schedule. Even if it is just a small feature set release. >> >> I would like the application teams to figure out what new features >> and fixes they can get done by Sep 15, and post this to the >> management site in confluence and email it to the dev list. This >> will tell us what we will in have in 2.3. >> >> http://bugs.sakaiproject.org/confluence/display/MGT/Sakai+Project >> +Management+and+Coordination >> >> I think this site needs some re-organization and updating to reflect >> our current top level organization of the software and the teams that >> are taking care of these, as well as new date information, but this >> is the place to get all this collected and right. >> >> All work for 2.3 is done in the trunks. All bug fixes for 2.2.x, if >> still appropriate, are also done on the trunk and will be part of >> 2.3. 2.3 will be from the trunk, NOT from the 2.2.x code base. >> >> After the Sep 15 code freeze, we have a 6 week period to verify. >> Problems found in the new features and fixes can be addressed in this >> period. Any new feature that does not look good to complete by Sep >> 15, or looks like it won't be ready based on verifications done after >> Sep 15, can be removed from 2.3 and aimed at 2.4 instead. >> >> Once we release 2.3 on Nov 1, we will start the 2.3.x maintenance >> branch, and plan the 2.3 maintenance releases. >> >> * * * >> >> 2.1.x, 2.2.x, 2.3.x >> >> Based on our still-in-progress release document (see link above), we >> will support maintenance branches for a year after the release. This >> means that the 2.2.x maintenance release will be supported until July >> 19, 2007. >> >> This means that WE ALL have to support our Sakai software's 2.2.x >> version for this year (there are no magic elves). I suggest that as >> bugs are found in 2.2.x, we fix them in our trunks, and then apply >> similar fixes as appropriate to the set of maintenance branches we >> are supporting. >> >> 2.3, if released on time, will support a 2.3.x maintenance branch >> until Nov 1, 2007. >> >> 2.1 was released Dec 1, 2005, so we should continue the 2.1.x >> maintenance branch till Dec 1, 2006. >> >> (Here's a question - does anyone plan to still be running 2.1.x past >> Dec 1 of this year? If so, the idea is that we form a sub-community >> and take over (or hire out) the continuation of the maintenance of >> 2.1.x code... how does that sound?) >> >> * * * >> >> Please participate in the SCP process so we can write and accept a >> release document that meets our needs and that we are willing to let >> guide our work. Get those last fixes in for 2.2.1 before next >> tuesday. And plan and document your contributions to 2.3. >> >> Thanks! >> >> - Glenn >> >> Glenn R. Golden >> Software Architect, University Of Michigan >> ggolden@xxxxxxxxx >> >> >> >> [see attachment: "message0.html", size: 7406 bytes] >> >> >> Attachments: >> >> message0.html >> https://collab.sakaiproject.org//access/content/attachment/54f12235-c0cd-495e >> -8012-d6da0c2ad95f/message0.html >> >> ---------------------- >> This automatic notification message was sent by Sakai Collab >> (https://collab.sakaiproject.org//portal) from the DG: Development site. >> You can modify how you receive notifications at My Workspace > Preferences. >> >> > > ---------------------- > This automatic notification message was sent by Sakai Collab > (https://collab.sakaiproject.org//portal) from the DG: Development site. > You can modify how you receive notifications at My Workspace > Preferences. > ---------------------- This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Development site. You can modify how you receive notifications at My Workspace > Preferences.

Next Message by Thread: click to view message preview

Re: Releases: 2.2.1 and 2.3

2006/7/29, Glenn R. Golden <ggolden@xxxxxxxxx>: 2.2.1 was not "rushed". It was a 4 week maintenance release, which could be quite normal. We might find we want more time, such as 6 weeks, but in either case, we cannot call it rushed ... ... <snip> ... I don't see any justification for "diminished confidence" in this release. I have to say I'm a bit surprised at this. There were nine weeks between the releases of 2.0.0 and 2.0.1, eleven weeks between the releases of 2.1.0 and 2.1.1. The first QA tag for 2.2.1 was cut this last Wednesday, and code freeze is this coming Tuesday. There will be just shy of three weeks between the first QA tag and the release. If it's not concerning, it is at least remarkable. We might also in our reckoning add to the shortness of time a shortage of QA resources. Now perhaps there are other, ameliorating factors, and the final assessment is one about which reasonable people may differ, but I think we have to acknowledge that there is justification for doubt. 2.2.2 *will* follow 4-6 weeks later, right on schedule. Don't let this new way of handling maintenance releases interfere with our feature release (i.e. 2.3) plans. I don't mean to make it sound like an interference (and I'm sorry if it does), but rather a positive attempt to apply limited resources to where they will be most profitable. There are positive developments in the testing sphere - ranging from Linda's push for load testing, through Alan Berg's code reviews, to Megan's push to do QA with actual production data. These are initiatives that should be harnessed, they could take a little time to sort out, and I don't want to see us rush past all that, either. I want to see us make the most of it. * * * The 2.3 release, which would be released in November, is really for lots of different folks. The brave (foolish?) will use it for winter term. The slightly reserved could use it for spring/summer '07 term. Those with more deliberation in their process might use it for the fall 07 term. It would help to know what the 2.3 release would include, and that may be a perspective I'm missing. All I'm able to see is the request of the development teams to try to identify what they can accomplish in the way of new features between now and mid-September. I can't help but wonder if our results might be more impressive for the coming year if we said that our next code freeze would be in March, and for the Fall the dev teams - while beginning their feature work - would also be encouraged to address a code review of the sort that Alan Berg has been so assiduously refining. We could even promote it as a "Q" cycle (as opposed to "QA"). This wouldn't seem like an interference to me, but a really positive step forward. This community needs to get used to working feature releases at the same time as maintenance releases, and get used to working on many different maintenance branches. Why? Because this is what we want. Or is it? That is up to us to decide, and to reflect in our release document. And if we decide that we want it, we also have to commit to doing it. The new schedule is appealing in the abstract, but I find something unnerving in the planning: how it doesn't seem to be taking into account our practical history and limitations (e.g. the perpetual 4-6 week maintenance release cycle). It has the vague feel of writing checks against an account we're not balancing. Abstracted. There is an emphasis on round figures and schedules over more pragmatic questions of available resources and a cycle that can harness our particular volunteers. I don't think we can, for example, simply say that there is a 4-6 week maintenance release cycle which can occur whenever it's scheduled. The length of time is not really as significant as the scope of the volunteer effort. I think many people make a special effort for the QA of a release, and it's not the sort of special effort they can afford to make year-round. Releases drain people. We need to think about making the most of them during the time when it makes the most sense to them - i.e., when it can fit in more neatly with local work they need to be doing. Perhaps a discussion of what we want should also be accompanied by a discussion of what we can afford. ~Clay 2006/7/29, Glenn R. Golden <ggolden@xxxxxxxxx>: I encourage this discussion, but I am concerned about some of the point that you make, Clay. I want to challenge some of them, and also want to clarify some more about the details and reasonings behind the release document currently in review. * * * 2.2.1 was not "rushed". It was a 4 week maintenance release, which could be quite normal. We might find we want more time, such as 6 weeks, but in either case, we cannot call it rushed. This is how a maintenance release will happen - a short period of bug fixes, then packaging and verification and release. Meanwhile the next short period is happening, etc. Why? Because this is what we as a community wants to have, and what we as a community are willing to do. Or is it? Lets get that clear in our release document. I don't see any justification for "diminished confidence" in this release. It is a fine example of a maintenance release. 2.2.2 *will* follow 4-6 weeks later, right on schedule. Don't let this new way of handling maintenance releases interfere with our feature release (i.e. 2.3) plans. * * * The 2.3 release, which would be released in November, is really for lots of different folks. The brave (foolish?) will use it for winter term. The slightly reserved could use it for spring/summer '07 term. Those with more deliberation in their process might use it for the fall 07 term. The point is that we want to start establishing a regular series of features releases with known fixed (and not slipped) dates so folks can make their plans. * * * The 2.3 release plans are not "hurried". They would just be over a shorter time period. 2.3 will have fewer new features than it would have had we started working on it in March. 2.4, which, if we follow the proposed schedule, we will work on from Sep 15 till next Mar 15, will likely have more features. * * * 2.3 will not slip past the deadline. We will make sure of that. It may shrink, but we will meet the timeline. In some sense, the timeline is more important than specific features, but less important than quality. * * * This community needs to get used to working feature releases at the same time as maintenance releases, and get used to working on many different maintenance branches. Why? Because this is what we want. Or is it? That is up to us to decide, and to reflect in our release document. And if we decide that we want it, we also have to commit to doing it. * * * Ok, now I'll lobby for 2.3 in Nov '06. I think the best reason to do this, other than to get on track with our proposed schedule, is to get *some* features into a packaged release before next March. This is to help us adjust to BUG FIX ONLY maintenance releases. If we have to wait for 2.3 till next March to get on our schedule, it will be hard to resist temptation to put in "just a few" features into the 2.2.x maintenance releases and branch. And we have seen in the past how that makes maintenance releases fail to deliver their mission, and fail to deliver quickly, and blur into feature releases. - Glenn Glenn R. Golden Software Architect, University Of Michigan ggolden@xxxxxxxxx [see attachment: "message0.html", size: 4853 bytes] Attachments: message0.html https://collab.sakaiproject.org//access/content/attachment/4ee742de-3db1-42c8-00ca-e66d8576209e/message0.html ---------------------- This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Development site. You can modify how you receive notifications at My Workspace > Preferences. ---------------------- This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Development site. You can modify how you receive notifications at My Workspace > Preferences.