Re: [Bodington-developers] creationmenu.html problem

[Sean M. <se...@sm...>]

I'm certain that I am misreading the tone of this, so I'll assume =20
that this is all positive.


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 =20=

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 =20
and clean that branch up, while other development continued, or, one =20
could stop
new code going into head (i.e. freeze) and test and clean up head for =20=

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, =20
> 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 =20
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 =20
regard was that
Bod.org has already agreed to two production releases per year, timed =20=

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 =20
> build in
> mid-August, then that is UHI's internal decision.  However, one
> organisation's internal decision should not affect the declaration =20
> 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 =20
> 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 =20
Bod.org errs against the front end of that timescale and releases =20
early rather than late.
That, with the fact that we have been pushing the 2.6 into the public =20=

domain for several months now as releasing this Summer, means that =20
2.6 must come
out in that timeframe.

If Bod.org is not able to make everything into a 2.6 release for the =20
time slated, we, with some little flexibility, chop what goes into =20
2.6. We ship at the period that is
required, because, in this business, there are fixed windows. We MUST =20=

deploy the product in downtime. We CANNOT change the product overmuch =20=

during term, as students
and staff, the people who pay our wages, get very snotty when the =20
interface or fundamental behaviour of the system changes mid-stream.

This is about institutional fit for bod. This is what it means to =20
have a University wide system, rather than something that you moodle =20
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 =20
stopped things going in next Wed at end of day, spent the next week =20
testing and gotten something out for 3/8. But perhaps not, given the =20
flux that some people have been making of HEAD and wanting to =20
redevelop things at the last moment against what has been in the open =20=

for some time...

However, I remain to be convinced that we should make an RC which =20
leads to a production deployment sometime in the middle of the Autumn =20=

semester, soon to be followed by a 2.8 release in Dec. Or were you =20
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_id=16492&op=3Dclick
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>
>