Menu
▾
▴
Re: [Bodington-developers] creationmenu.html problem
|
From: Colin T. <col...@co...> - 2005-07-25 07:59:53
|
Sean Mehan wrote: > I'm certain that I am misreading the tone of this, so I'll assume that > this is all positive. Yes! I'm happy to go with the plan as you suggest. My only request/suggestion is that we release it as a release candidate, and try to follow that up as quickly as possible with a release. We want to avoid people downloading the long-awaited version, only to be disappointed by some fairly obvious bug (as a result of our testing being a bit rushed). That way we would get some testing help from the early-adopters using the release candidate for a few days/a week/couple of weeks, and yet nobody thinks Bod is buggy. Colin > > On 22 Jul 2005, at 16:45, Peter Crowther wrote: > >>> From: [...] Sean Mehan >>> Why can't we work until Wed. On wed we chop off new stuff. This is >>> the plan as it presently stands. >>> >>> Then we can take a day or three to finish some quick testing. >>> >>> Then we can finalize this and have 2.6 out a week or so after we >>> said, which is pretty good. >>> >> >> OK. So this would be going straight for 2.6.0 with *no* 2.5.* testing >> or candidate releases before it - seems a bit odd to have been at the >> meeting in February where the new odd/even numbering scheme was >> described, but hey. > > > Why is the odd/even scheme odd. Seems fine to me. In fact, you'll see > that there are several tags of 2.5.x in the tree. > we are all currently writing to 2.5.x > > At some point, we need to split a 2.6 branch. One could just split and > clean that branch up, while other development continued, or, one could > stop > new code going into head (i.e. freeze) and test and clean up head for a > subsequent split to 2.6, which is what I was proposing. > >> >> I'm with Colin - releasing a half-baked build as 'production quality', >> burning CDs of it etc. isn't going to endear us to any prospects, nor is >> it going to help sell any next-generation system such as Tetra. >> > > half-baked. Hmm. I'll have to remind myself to stop trying to do things > half-baked again.... > > >> >>> We have already promised to deploy the 2.6 here at UHI mid >>> August. We >>> must adhere to this as people need access to the new tool set >>> at that >>> time. They have already planned on it (e.g. Bookmarks). >>> >> > > Well, what I should have made more explicit in my logic in this regard > was that > Bod.org has already agreed to two production releases per year, timed > for effective integration of said production releases > into the live environments of the deploying institutions. > > >> "The 2.6" or "the new version at that time"? >> >> If UHI has time constraints that mean it has to take an interim build in >> mid-August, then that is UHI's internal decision. However, one >> organisation's internal decision should not affect the declaration of a >> production quality release from a cross-institution development team >> such as the one for Bodington. If, as a result of their internal >> constraints, UHI wish to put in a lot of testing effort in order to >> validate their decision and meet their timescales... that's UHI's >> decision. UHI is not Bodington or bodington.org - at least, not unless >> the academic politics are *very* different from the public face - and >> the two organisations' objectives may legitimately differ. > > > Now, different institutions start terms at different times, so Bod.org > errs against the front end of that timescale and releases early rather > than late. > That, with the fact that we have been pushing the 2.6 into the public > domain for several months now as releasing this Summer, means that 2.6 > must come > out in that timeframe. > > If Bod.org is not able to make everything into a 2.6 release for the > time slated, we, with some little flexibility, chop what goes into 2.6. > We ship at the period that is > required, because, in this business, there are fixed windows. We MUST > deploy the product in downtime. We CANNOT change the product overmuch > during term, as students > and staff, the people who pay our wages, get very snotty when the > interface or fundamental behaviour of the system changes mid-stream. > > This is about institutional fit for bod. This is what it means to have > a University wide system, rather than something that you moodle with > your 22 students in your course. > > UHI is NOT Bod, but Bod IS about institutions LIKE UHI. > > As I stated previously, I would have thought that we could have stopped > things going in next Wed at end of day, spent the next week testing and > gotten something out for 3/8. But perhaps not, given the flux that some > people have been making of HEAD and wanting to redevelop things at the > last moment against what has been in the open for some time... > > However, I remain to be convinced that we should make an RC which leads > to a production deployment sometime in the middle of the Autumn > semester, soon to be followed by a 2.8 release in Dec. Or were you > proposing changing those timescales as well? > >> >> - Peter >> >> "The bitterness of poor quality remains long after the sweetness of >> meeting the deadline has gone." - somebody or other. > > >> ------------------------------------------------------- >> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >> from IBM. Find simple to follow Roadmaps, straightforward articles, >> informative Webcasts and more! Get everything you need to get up to >> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click >> _______________________________________________ >> Bodington-developers mailing list >> Bod...@li... >> https://lists.sourceforge.net/lists/listinfo/bodington-developers >> >> > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
