[tei-council] Jenkins config changes

[James Cummings]

On 29/10/12 15:58, Martin Holmes wrote:
>> I certainly support that.  If no one disagrees, can we just make
>> that Council policy?  I.e. all intentional changes done a week
>> before the scheduled release date, and then it be proofread by
>> cancel before release? (i.e. only mistakes introduced by the
>> recent changes or typos changed after that)  Can anyone think of
>> a reason why we shouldn't do that (aside from it forcing us to
>> stick to our deadlines)?
>
> That would definitely be good, but what actually happened on release day
> was that someone reported a crucial bug which couldn't be allowed into
> the release, so Sebastian had to leap in and start changing things. So I
> think what we have to say is:
>
>    - Freeze one week ahead

Agreed. (minimum 1 week)

>    - If release-blocking bug is found, release date is moved and the
> one-week freeze starts again once the bug is fixed.

Agreed.

> Also, if people DO diligently check stuff during the one-week freeze,
> they will _inevitably_ find things that need fixing. Do we fix such
> things or not? If so, do we restart the freeze for typo-fixes etc.?

No, I think that the only things that need to re-start the freeze 
are release-blocking bugs.  A release could go out with a typo, 
but since we've noticed it then we might as well correct it.  So 
I'd argue that corrigible bugs are ok, but things which either 
introduce new changes to the schema or change the _intent_ of the 
release are forbidden.  (i.e. I can change a typo, or having 
noticed we've changed the schema without changing the prose, 
update the prose to reflect our intent, but I shouldn't be doing 
a *new* ticket/change)

> Although the particular issue that caused our problem this time
> shouldn't occur again, I still think it's a bit of a wake-up call, and
> even given a week's time for everyone to check the release, we should
> still be looking at some automated checking of the release package
> contents, to make sure all dates and versions are correct, etc. We
> should also be trying to imagine as many possible problems as we can,
> and seeing if we can check for them automatically.

Agreed.

-James
-- 
Dr James Cummings, researchsupport at it.ox.ac.uk
Research Support, IT Services, University of Oxford