[tei-council] Jenkins config changes

[Gabriel Bodard]

I think we need to think in terms not only of release blocking bugs vs 
typos etc., but of fixes that are, shall we say, infrastructural (such 
as XSLT or Ant fixes) that would restart the clock on the one-week 
freeze, and the vast majority of content-only bugs that can be fixed any 
time in the one-week period (up to a final 24-hour deep freeze)...

On 2012-10-29 15:58, Martin Holmes wrote:
> On 12-10-28 03:34 PM, James Cummings wrote:
>> On 28/10/12 21:58, Sebastian Rahtz wrote:
>>> i think a more important rule is to have a week's freeze before a release,
>>> and an action on everyone to check the lastSuccessfulArtefacts
>>> in Jenkins for oddities.
>>
>> 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
>
>    - If release-blocking bug is found, release date is moved and the
> one-week freeze starts again once the bug is fixed.
>
> 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.?
>
> 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.
>
> Cheers,
> Martin
>
>>> it wasn't the 2.1.0 per se which was wrong in the files, but
>>> the wrong content.....
>>
>> Is this now fixed? When can we be ready for a maintenance release?
>>
>> -James
>>
>

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

T: +44 (0)20 7848 1388
F: +44 (0)20 7848 2980
E: gabriel.bodard at kcl.ac.uk

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/