On Sun, Sep 13, 2009 at 09:07, Gregory P. Smith <g...@krypto.org> wrote: > On Sun, Sep 13, 2009 at 8:54 AM, Matthias Klose <d...@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)?
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. -Brett _______________________________________________ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers