forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diana Shannon <shan...@apache.org>
Subject Re: status.xml versus separate files
Date Tue, 19 Nov 2002 12:57:19 GMT

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:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102312955715731&w=2

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.

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

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

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

Diana


Mime
View raw message