On Sun, Sep 13, 2009 at 8:54 AM, Matthias Klose <doko@debian.org> wrote:

On 06.04.2009 00:33, Matthias Klose wrote:

...

While looking at the diffs between the 261 release tags and the 26 branch, I noticed many items in Misc/NEWS appearing in the 2.6.1 or even 2.6 sections. I moved all of these to 2.6.2, after checking some of them, and found all of the checked ones be backported after the 2.6.1 release. Is there anything what could be done to avoid these wrong merges?

I plan to check the items on the 3.0 branch soon.

done again for the 2.6.3 (2.6 branch) and 3.1.2 (3.1 branch) entries. I didn't check if these were inserted to earlier entries by intent except for the removal of the entry for issue #2522.

 Matthias

Thanks. One reason this happens is that our NEWS file is very difficult to navigate. svnmerge rarely works on it because the context is often different in the branch file but figuring out which version's section of the bazillion line file you are currently in is very tedious in a text editor.

brainstorm:

It'd be nicer if we could generate the file from another source, perhaps keep each releases news in its own file and merge it all together at release time?

Or have a NEWS.latest file that contains only updates since the previous release (part of making a release would be to prepend NEWS.latest to the NEWS file and truncate NEWS.latest)?

On Sun, 13 Sep 2009 at 13:15, Brett Cannon wrote:

On Sun, Sep 13, 2009 at 09:07, Gregory P. Smith <greg@krypto.org> wrote:

...

Thanks.  One reason this happens is that our NEWS file is very difficult to navigate.  svnmerge rarely works on it because the context is often different in the branch file but figuring out which version's section of the bazillion line file you are currently in is very tedious in a text editor.

brainstorm:

It'd be nicer if we could generate the file from another source, perhaps keep each releases news in its own file and merge it all together at release time?

Or have a NEWS.latest file that contains only updates since the previous release (part of making a release would be to prepend NEWS.latest to the NEWS file and truncate NEWS.latest)?

Or simply take the first line of each commit? I mean why do we enter it twice? If we have a commit that is unimportant we could come up with some convention to make it as such or simply have the comment start with a blank line.

I think it is often good to put more information into the commit message than should go into the NEWS entry. But having a way to mark up the NEWS entry inside the commit message might work.

We'd need a volunteer to implement it, though :)

--David

On Sun, Sep 13, 2009 at 13:26, Antoine Pitrou <solipsis@pitrou.net> wrote:

Le dimanche 13 septembre 2009 à 13:15 -0700, Brett Cannon a écrit :

...

Or simply take the first line of each commit? I mean why do we enter it twice? If we have a commit that is unimportant we could come up with some convention to make it as such or simply have the comment start with a blank line.

The NEWS file is often more carefully, or differently, worded than commit messages are.

Right, which is why only the first line would be used. All the other usual detail can be there, just do it on another line.

Trying to generate it automatically would probably involve some a posteriori maintenance, and I doubt it's really worth it (at worse, you save a copy / paste in the cases where the commit message is perfectly adequate as a NEWS entry).

I suspect we would have to start either at some golden revision or not until a release happens.

-Brett

Brett Cannon schrieb:

...

brainstorm:

It'd be nicer if we could generate the file from another source, perhaps keep each releases news in its own file and merge it all together at release time?

Or have a NEWS.latest file that contains only updates since the previous release (part of making a release would be to prepend NEWS.latest to the NEWS file and truncate NEWS.latest)?

Or simply take the first line of each commit? I mean why do we enter it twice? If we have a commit that is unimportant we could come up with some convention to make it as such or simply have the comment start with a blank line.

We should just switch to Mercurial :)

I've already hacked up a hg extension to automatically fill the commit message with the changes in a NEWS or CHANGELOG file. This works quite well -- you add the short but nice description to NEWS, do "hg commit", and the editor pops up where you can either accept the message consisting of only the changes in NEWS, or add some more stuff that's not interesting to users.

cheers, Georg

-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.