[tei-council] (was Re: tei release under way, watch out)

Kevin Hawkins kevin.s.hawkins at ultraslavonic.info
Mon Feb 21 17:39:52 EST 2011

On 2/21/2011 5:34 PM, Martin Holmes wrote:
>>>>> An idea then comes to my mind. Could we think of automatically
>>>>> compile
>>>>> release notes from SF, taking into account tickets in "fixed" status
>>>>> over a certain period. This would in turn force all of us at paying
>>>>> attention to the wording of ticket headings. If I'm asking too much,
>>>>> do not hesitate to tell…
>>>> That is a good idea, if someone can take the time to write the
>>>> script;
>>>> I assume there is an API to SF's bug trackers?
>>>> This needs a volunteer to make a proof of concept, I suggest. Not me,
>>>> I am afraid.
>>> While it sounds like a fun idea, remember that anyone is allowed
>>> to submit FR/Bugs to sourceforge... so unless you are suggesting
>>> that when we change the 'Resolution' to be Fixed (or another
>>> value) that we also rename the ticket to what it was *actually*
>>> about?  Might that not be confusing for the person who submitted
>>> it?
>> Not a big issue to my view (the guy will get a message when the change
>> is made anyhow). But look at the capacity it gives us at really
>> boasting the work we do...
> Judging from the tickets I've been involved in, this would be very
> problematic. The "fix" made in the end (usually after a lot of
> discussion) often only partially "resolves" the request or report
> originally made, and sometimes the solution enacted is very different
> from what was originally suggested or requested in the ticket. Some
> tickets are also forked into multiple children, and others are closed in
> order to be replaced by re-worked requests. Any code that could make
> helpful sense of this would be impressive indeed.
> I think it would be more useful to keep detailed revisionDesc
> annotations as changes are made to the source, but having just looked
> through some of the source, it's not clear to me where that stuff should
> be kept.

What if we instead use the log entries in Subversion?  See some examples 
of these:


If we do this, those editing the Guidelines should keep in mind when 
writing log entries that they will be more likely to be seen by the 
outside world as part of a change log.  But this would be the more 
proper way to do things in a world with version control systems.

More information about the tei-council mailing list