[dev] [commits] Horde branch master updated. content-1.0.0alpha1-55-g737d6d8

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>>
>>>> Quoting Jan Schneider <jan at horde.org>:
>>>>
>>>> Sounds like Gunnar is working out the details of his solution.   
>>>> But I am NOT going to manually enter entries into both CHANGELOG  
>>>> and package.xml.  You are asking for *3* separate descriptions  
>>>> for a commit (the commit message itself, CHANGELOG, and  
>>>> package.xml).  We should be writing 1, or at most 2, messages.   
>>>> Adding yet another place to maintain this information is a giant  
>>>> step backward.
>>>
>>> Until we have a solution, please update both, otherwise we're  
>>> going to really mess up with this many package.xml files we have  
>>> now.
>>
>> Is there a reason why this can't be done when preparing a release  
>> (like we have done for years)?
>
> Despite Gunnar's great components tools, releasing is still a *lot*  
> of manual work. This is error prone and it's easy to forget a step,  
> a file, or even a complete application (like timeobjects for the  
> alpha releases).
>
> Beside that, depending on whether you only update package.xml or  
> only CHANGES, the release master has either to go through 74  
> package.xml files to update CHANGES, or even worse, go through  
> CHANGES and split up the notes to the correct one of 74 package.xml  
> files.
>
> I'm really not asking too much, updating two files is a  
> 5-seconds-cut-and-paste action.

Still would like to see this automated.  But since I am not the one  
preparing the releases (much thanks btw), I will do what you request.

>>>> Either CHANGELOG needs to be automatically generated from  
>>>> package.xml or vice versa.  At a minimum, we should chop all old  
>>>> CHANGELOG entries anyway (e.g. H3 and previous), or at least move  
>>>> these changes to a different file (CHANGELOG.OLD).
>>>
>>> I'm not sure what that one has to do with the other. And I don't  
>>> see a reason why we shouldn't keep the complete changelogs in a  
>>> single file.
>>
>> Why do we care about changelog entries from Horde version 1 in the  
>> current release?  It's just unnecessary bloat.  Makes it difficult  
>> to search/grep the file also, since you will get all sorts of false  
>> positives for things that became irrelevant years ago.
>
> A complete changelog is a proud sign of a long history IMHO and  
> still informative in many cases. And moving part of this to a  
> different file doesn't help you with false positives when doing  
> search/grep.

Sure it does.  Say there is a reference to foo in version 2.1 of the  
Horde change log.  Doing this:

fgrep -l foo doc/*

With the current CHANGES would give:

doc/CHANGES: [xxx] ...foo...

Splitting into a separate file gives:

doc/CHANGES.OLD: [xxx] ...foo...

So I would know I don't need to touch the changelog based on the filename.

Changelogs are good, but 100K+ changelogs don't help anyone out.  We  
should provide access/links to old changes (this alleviates the  
concerns you raise above) but I am entirely unconvinced by your  
argument that we need to keep around all these very VERY old changelog  
entries.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]