[tei-council] another agenda item

[Syd Bauman]

>  1. on Sourceforge, in CVS. any one monitoring CVS gets the gory
>     fixes, which are not even guarenteed to be internally consistent
>  2. on Sourceforge, as file releases. these are zip files containing the
>     P5 materials in a supposedly runtime tree structure
>  3. on the TEI web site, in the form of the HTML version of the Guidelines
>  4. on the web, as the eXist database behind Roma, also used for
>     the /Query/tag.xq?name=foo interface; noting that Roma
>     conceptually lives on both tei.oucs.ox.ac.uk and on tei-c.org.uk,
>     which can be kept apart
>  5. in Debian packages
>  6. bundled in TEI Emacs
>  7. in TEI Knoppix CDs and DVDs

> of these, only the first and second are clear; #1 happens when
> anyone makes a change; and #2 happens when the Council authorizes a
> new numbered release.

One thing missing here is the issue of where bug fixes fit in. It makes 
sense for the editors to be able to push out file releases of this sort 
without pestering the Council.

We also haven't distinguish between the fairly frequent "releases"
that happen as we make minor updates (especially within the
development process) and the more formal increments (e.g. P5.1, P6,
etc.). It seems to me that the Council should be directly involved in
the major updates (e.g., new chapter, significant change to class
system, etc.), and not involved in the minor development updates or
bug-fix updates. Not so sure about the intermediate ones.


> (since only #1 is really a Release").

I don't think #1 is a release -- it's the current work repository. #2
is the only thing that is really a "release" at the moment. What is
lacking is an agreement on what should trigger a new file release in
Sourceforge (i.e., a new #2). I'd propose that in this pre-release
protion of P5's lifecycle, pretty much any significant change
(including bug fixes) that results in a self-consistent, self-
validating, working version of the Guidelines should trigger a new
release on Sourceforge. 

Whether or not Council should be directly involved in this triggering
is an open question in my mind. I'm inclined to say no for small
things, yes for larger things, and just to trust the editors'
judgement as to what's small and what's large.

Personally I would like to see 3 & 4 follow 2 fairly quickly; i.e.,
shortly (hopefully measured in minutes to hours) after a new
Sourceforge file release is made available, that version is
propagated to the TEI website, both as HTML and in the eXist
database.

I presume that our build process all but requires that 5 follow 1. As
for 6 & 7 these are "products" of your making, and it seems to me you
get to decide what version of the pre-release of P5 they use.
Personally I'd be inclined to have them follow #2, also, but at
whatever pace you determine.