[tei-council] respond by 1 May: summary of and path forward for "no longer recommended" and "deprecated" practices

[Kevin Hawkins]

On 4/19/13 11:27 AM, Kevin Hawkins wrote:
>> On 4/19/2013 6:47 AM, Gabriel Bodard wrote:
>>> On 2013-04-19 09:42, Sebastian Rahtz wrote:
>>>    b) we can automate the check in 3. of the wiki page. i.e. don't
>>> ask people to go grepping, but instead add to the build checks so
>>> that a validUntil which is less than 6 months away from todays date
>>> generates a warning and a validUntil which is after todays date
>>> generates an error. This will cause Jenkins to fail the build if we
>>> ignore a validUntil date.
>>>     c) for 1 B, i would suggest a formal process whereby the release
>>> notes have a section listing all the Specs waiting on death row, with
>>> their date. so we write a script
>>> to generate a section for inclusion in the notes. anything which cane
>>> be automated, lets automate...
>>
>> Agreed. Neither of these means that no human has to look at the
>> deprecation and take an action (meaning that decisions can and will be
>> reviewed), but they also help to make sure we don't lose sight of things
>> we've planned to do or people we should have warned.
>
> Sebastian's idea is a good one.  I've noted in the wiki.

While implementing those past deprecations according to our policy, I 
set some @validUntil dates that are in the past.  These yielded 
Schematron errors that cause Jenkins to fail, so it appears Sebastian 
implemented something he suggested back in April.

If everyone is satisfied with the way this is working and feels that 
we've given enough notice for deprecation on these (despite not having 
Schematron warnings as part of our releases for the past two years) I 
suggest we actually go ahead and remove these deprecated things.

K.