forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: status.xml versus separate files
Date Mon, 18 Nov 2002 19:04:03 GMT

Nicola Ken Barozzi wrote:
> Diana Shannon wrote:
>> On Monday, November 18, 2002, at 03:01  AM, Nicola Ken Barozzi wrote:
>>> The reasons why I preferred to use one file only is:
>>>  1) it could replace STATUS
>>>  2) it's a single location for community-related stuff
>>>  3) <developers> are referenced in both changes and todos,
>>>     thus I reckoned it better to have them all in the same file
>> Remember, we use developer info elsewhere too, for example in fixme 
>> elements and in other todo/changes docs (e.g. related specifically to 
>> docs). See Cocoon's plan directory.
>> We had this discussion on cocoon-dev earlier, and Stefano suggested 
>> having the dtd aggregate the committers list. Can that help?
> Errr, sorry Diana, but my brain is loosing language cycles and I don't 
> understand what you mean... can you please explain more in detail what 
> could be a solution? Thanks :-)
> Anyway, I've remembered two other reasons why I aggergated originally 
> todos and changes:
>  4) it's tipical to add a change and have to remove a todo, and
>     if they are in the same file it's more possible that it's done;
>     this is also why I put todos before changes, so I had to
>     scroll them to get to the changes
>  5) newbie users complained that with all these files in top-level
>     cluttered the module, while if we put them in the docs, they
>     are hard to find (seem strange but actually I had problems
>     myself at teh beginning).
> This is not to say that status.xml has to remain as-is, but to try and 
> explain the design decisions that were taken, so that other solutions 
> can address them too.
> I'm still not sure I understand all the reasons why a single file is not 
> good... is it because it becomes too big?
> If so, it's basically because changes and issues will become very big, 
> and will also if they are separated, so I don't see in this case the 
> advantage in separating them.
> Maybe making an "archive" file that contains all old entries could help...
> <thinking-out-loud>
> maybe a ./history dir with all status files like they were at the time 
> of a minor version (>bigfix) release?
> So we would have
>   status_1.0.xml
>   status_1.1.xml
>   status_1.2.xml
>   status_2.0.xml
>   status_3.0.xml
>   status_3.1.xml
>   ...
> </thinking-out-loud>

Stupid me, should have read the guidelines better 8-)

Taken from

Status Files

Each of the Project's active source code repositories contain a file 
named STATUS which is used to keep track of the agenda and plans for 
work within that repository. The status file includes information about 
release plans, a summary of code changes committed since the last 
release, a list of proposed changes that are under discussion, brief 
notes about items that individual developers are working on or want 
discussion about, and anything else that may be useful to help the group 
track progress.

Basically the proposed changes to status.xml roughly correspond to this 
part, but I missed this part: " a summary of code changes committed 
since the last release".

Seems that archiving old release notes and decisions is something to do.

The active status files are automatically posted to the developer 
mailing lists three times per week.

You know the bot I run on my machine for patch queue?
Seems like a status version of it is not a bad idea B-)

> Are there other needs that should be addressed?

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message