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

Reply via email to