[python-committers] what's going on with Misc/NEWS?

R. David Murray rdmurray at bitdance.com
Fri May 24 19:33:17 CEST 2013

On Fri, 24 May 2013 18:39:16 +0200, "Antoine Pitrou" <solipsis at pitrou.net> wrote:
> Brett wrote:
> >> Of course, we've talked about doing something like this before, it's
> >> just never irritated anyone enough for them to sit down and *write*
> >> the associated NEWS file generator, or the code to split the existing
> >> NEWS file for the active branches :)
> >
> > I think that's overly complicated.
> Agreed. I'm not surprised Twisted uses something like that :-), but we
> don't need
> that level of complexity.
> > I don't see why we need anything
> > more than simply NEWS/3.4, NEWS/3.3, etc. and just split the files per
> > feature release since that's the interest (and merge) boundary.
> You'll have to copy stuff by hand, though, if you don't want to rely on the
> merge machinery. So we have two possible file layouts:
> * (current) a single Misc/NEWS is merged from branch to branch. Pro: hg merge
> copies the text for you. Con: hg merge sometimes screws up and you have to
> clean up a large conflict.
> * a dedicated Misc/NEWS-x.y per major version. Pro: no merge conflicts ever.
> Con: you have to copy the message by hand when merging a bug fix to the upper
> branch. Con: it's easy to forget to copy the message (hg won't yell if you
> don't
> do it), so people *will* forget (and it's annoying grunt work for those who
> notice it).
> The major con with the current scheme *might* be solved by a dedicated hg
> extension, but someone needs to have enough free time and passion to try and
> write it :-)

I agree with Antoine here.  I'd rather deal with the occasional conflicts
(which goes: revert Misc/NEWS change, copy news entry) and get automatic
merge some of the time, rather than have to *always* remember to copy
the news entry, with no warning if I forget.  The current way either
the merge works[*], or you get an error reminding you you have to do the
revert/copy dance.


[*] So far I haven't had a case of what sometimes happened in svn,
where the merge would appear to work but would be in the wrong
section. I think this is because we moved stuff to HISTORY, or it
may be that hg merge is just smarter than svn merge.

More information about the python-committers mailing list