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 18:51:37 GMT

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


maybe a ./history dir with all status files like they were at the time 
of a minor version (>bigfix) release?

So we would have



Are there other needs that should be addressed?

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

View raw message