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 Tue, 19 Nov 2002 13:15:29 GMT

Diana Shannon wrote:
> On Monday, November 18, 2002, at 01:51  PM, 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 :-)
> No, **I'm** sorry, Ken. I was paraphrasing an email thread for which I 
> simply should have provided links.
> Here's the original thread:

Ah, ok, now I understrand the concept better... but still I remain 
ignorant on how to do it ;-(

> Perhaps we can transform the developer content out of the status.xml 
> file to create a mod file (for other dtds) with an entity defined for 
> all possible developer IDs (used as attributes in fixmes, for example). 
> IMHO this is a **minor** priority, though.

Actually it's quite important that references to developers are valid.
But having to create a DTD for developers... hmmm... doesn't seem that nice.
Is there a way we can reference elements in other xml files from an id?

BTW, why not (as previously done and retracted ;-) use the unix names as 
   NKB -> nicolaken
   SM  -> stefano


It's more consistent and has been already suggested by some (off my head 
IIRC PD, ahem I mean peter ;-)

>> 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
> Makes a lot of sense.
>>  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).
> Yes, and we have similar files (for doc-specific changes and todo) in 
> Cocoon's xdocs/plan directory which are sometiems overlooked by some 
> committers when updating or adding docs. Speaking of which, I added a 
> status-docs.xml top-level file to my trial run of a Forrest transition 
> for Cocoon. I'll post more today -- almost finished.

Some actually think that using commit messages to poplate the changes is 
the best hing to do, but this breaks the todo->changes->compatbreaks 
cycle introducing another way of inserting changes.

What I prefer doing is to put the changes in place and copy-paste the 
xml snippet in the commit message.

>> 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?
> I certainly didn't mean to imply it wasn't "good" -- but, yes, that it 
> would be big (in Cocoon's case).

Ok, I agree.

>> 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
> I like this idea. Really, though, I'm pretty agnostic about it. I just 
> want to make sure the file is "inviting" to update, that's all. I just 
> was wondering, out loud, if a large file may be less "inviting".

Good, then I think I understood it after all :-)

Seems that this solution (BTW, I read it from David's mails for the 
history), is the best one, given all POVs and needs.

Where should we put the "history"?
Make a ./history folder, or simply rely on CVS to keep old versions of 
the file?

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

View raw message