[tei-council] another agenda item

[Christian Wittern]

Syd Bauman <Syd_Bauman at Brown.edu> writes:

>>  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.

Did we have this policy?  If not, I assume we should introduce it:-)

To me, anything above 2 is merely derived and does not need additional
authorization or whatever, it just needs to be part of the workflow.
Most of that could be triggered automatically, I assume.  The timing
of 7, on the other hand would presumably not depend on the release
state, but more on the need to have such a beast at a certain time
(e.g. for classes, conference, members meeting etc.)
Roma OTOH would quite closely follow the CVS version, right?
>
> 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.

Bug fixes go inot CVS immediately.  They do not necessarily trigger a
new release -- maybe a minor release if they are serious.


> 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.

Thas sounds goot to me.

>
>
>> (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.

Then you might end up with frequent new snapshots, which might be of
mixed quality (cf the eXist development model).  I assume that people
interested that much in the day-to-day development could as easily
follow the CVS.

Apart from that, I think it would make sense to delegate the timings
of the other releases to Sebastian (or whoever is involved), they do
not seem to fall directly into the area of the work the council is
supervising.
 

All the best,

Christian

-- 

 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN