<p dir="ltr"><br>
On 25 May 2013 13:05, "R. David Murray" <<a href="mailto:rdmurray@bitdance.com">rdmurray@bitdance.com</a>> wrote:<br>
><br>
> On Fri, 24 May 2013 15:16:24 -0600, "Gregory P. Smith" <<a href="mailto:greg@krypto.org">greg@krypto.org</a>> wrote:<br>
> > On May 24, 2013 2:55 PM, "Antoine Pitrou" <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
> > ><br>
> > > Le vendredi 24 mai 2013 à 16:22 -0400, Brett Cannon a écrit :<br>
> > > > ><br>
> > > > > I don't understand why it's painful to backport. Can you explain?<br>
> > > ><br>
> > > > If I make a very minor fix to the docs I have to:<br>
> > > ><br>
> > > > # In a 3.3 checkout<br>
> > > > Fix docs<br>
> > > > Compile docs<br>
> > > > Add Misc/NEWS entry<br>
> > > > hg ci -m "repeat what I just said in Misc/NEWS"<br>
> > > > hg push<br>
> > > > cd ../default<br>
> > > > hg merge 3.3<br>
> > > > Fix/revert Misc/NEWS (at least)<br>
> > > > Compile docs (if fix is needed)<br>
> > > > hg ci<br>
> > > > hg push<br>
> > ><br>
> > > I honestly don't understand why you would mention doc fixes (even major<br>
> > > ones) in Misc/NEWS. It's not a useful piece of information to have<br>
> > > there. People want to know about bug fixes because they are affected by<br>
> > > bugs, but doc fixes??<br>
> ><br>
> > I think you misunderstood what he meant. Misc/NEWS is documentation. I<br>
> > believe he meant he won't fix typos in NEWS due to the make pain involved.<br>
><br>
> No, he really meant he created a news entry for a doc change.  For a<br>
> reasonable reason, in the example he gave :)<br>
><br>
> But you certainly don't need a news entry for typos, or most other<br>
> doc changes, IMO.<br>
><br>
> > I'm the same way. I want nothing to do with news when making my changes<br>
> > because it ALWAYS gets in the way for any change not being done on<br>
> > head/default/tip only. If anything I prefer to leave news entries out of<br>
> > the commit they are related to to avoid news merges going wrong from<br>
> > messing up the real change. Hopefully I remember to write a news entry for<br>
> > it after the fact.<br>
><br>
> In the subversion days almost every merge I did had a NEWS conflict.<br>
> With hg, I only get a merge conflict if the most recent change to NEWS<br>
> is a 3.3-only entry.  So, maybe half the time.  (I suppose if people<br>
> are really sticking entries in randomly I might start seeing more<br>
> conflicts...)<br>
><br>
> I have no objection to the process being improved if someone is willing<br>
> to do the scripting to improve it.  I personally would prefer not to<br>
> simply have the files have different names, meaning I'd have to copy the<br>
> news entry all the time instead of half the time.  But my objection is<br>
> only about -0.25, so if more people prefer making the file names different<br>
> in the absence of a better scripted solution, I'll live with it :)<br>
> I just hope we don't start losing NEWS entries as as result.<br>
><br>
> Oh, and my news entries are almost never the same as my commit one-lines,<br>
> partly because I keep the commit line to *one* line, whereas the NEWS<br>
> entry is typically two to three.  Keeping the first commit line to one<br>
> line makes reading the log easier, IMO; but I suppose since not everybody<br>
> does that it's really just a quirk :)<br>
><br>
> But even without that the messages would different.  As someone else<br>
> mentioned, I feel that the audiences are different...and in the commit<br>
> message I assume that you are seeing the list of changed files as well,<br>
> to give you context for the commit message that isn't present in the<br>
> NEWS entry.</p>
<p dir="ltr">Yep, that's my view of commit vs NEWS as well.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> --David<br>
><br>
> _______________________________________________<br>
> python-committers mailing list<br>
> <a href="mailto:python-committers@python.org">python-committers@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/python-committers">http://mail.python.org/mailman/listinfo/python-committers</a><br>
><br>
</p>