cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Building useful release notes (was Re: [GT2003] heads up: Hackathon schedule updated)
Date Fri, 03 Oct 2003 14:29:33 GMT

On Friday, Oct 3, 2003, at 11:40 Europe/Rome, Sylvain Wallez wrote:

> Antonio Gallardo wrote:
>> Sylvain Wallez dijo:
>>> Bertrand Delacretaz wrote:
>>>>> I currently don't have much access except email so can anyone tell 
>>>>> me
>>>>> whether we have change notes for the new version or where Steve can
>>>>> find them?
>>>> ?
>>> The change list is really too much low-level and hardly readable by
>>> someone that doesn't follow the dev list every day.
>>> We could classify changes with a new attibute
>>> importance="minor|medium|major" so that we can build usable release
>>> notes automatically. Of course, the changes going in the release 
>>> notes
>>> will have to be in "clear" text in order to be understood by the
>>> majority of people with average Cocoon knowledge.
>>> Something that's needed also is categorizing the changes to easily
>>> identify the area of Cocoon where a change occured. A simple way to
>>> achieve that would be for each block to have it's own status.xml file
>>> (this will be needed anyway when blocks will have their own CVS 
>>> repo).
>>> With these two simple categorization criteria, building some useful
>>> release notes will become really easy.
>>> What do you think ?
>> Yes in general. But all the changes are important, sometimes somebody 
>> is
>> looking for a very simple fix that for him it is the most important.
>> I also read the link above. I think we really need a better release 
>> notice
>> with a changelog. :)
>> [RT] We already have a clasification: add, update, fix.
>> Maybe we does not need to introduce a new clasification. We can show
>> change in the follwing order: Add, updates, fixes.
>> If we add a new clasification (current + proposed), it will add
>> complexity. We will have at the end 3x3 categories of bugs. That is 
>> not a
>> good idea.
>> My proposal is to create a change autogenerated based in the current
>> categories.
>> Is that OK?
> No, because add/update/fix is related to the kind of activity that 
> happened, but not to its importance regarding the evolution of the 
> whole Cocoon system.
> People looking for a particular bug fix are those that can read the 
> current kilometer-long release notes. We need a higer-level release 
> note that shows the global direction in which Cocoon is evolving.

I agree with Sylvain here: there are two concerns (activity, 
importance) and they should be orthogonal.


View raw message