<p dir="ltr"><br>
On May 25, 2013 8:29 AM, "Gregory P. Smith" <<a href="mailto:greg@krypto.org">greg@krypto.org</a>> wrote:<br>
><br>
><br>
> On May 25, 2013 1:40 AM, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> ><br>
> > On Sat, May 25, 2013 at 2:01 PM, Eric Snow <<a href="mailto:ericsnowcurrently@gmail.com">ericsnowcurrently@gmail.com</a>> wrote:<br>
> > > On Fri, May 24, 2013 at 9:46 PM, Raymond Hettinger<br>
> > > <<a href="mailto:raymond.hettinger@gmail.com">raymond.hettinger@gmail.com</a>> wrote:<br>
> > >> and it recognizes that users don't really need to look across merge<br>
> > >> boundaries.<br>
> > ><br>
> > > This is tricky though for any patch that is forward-ported to a<br>
> > > release branch (a la 3.2->3.3).  How can you tell from MISC/News in<br>
> > > which release (e.g. 3.3.0 or 3.3.1) of that branch the bug was fixed?<br>
> > > The entry would only show up in MISC/News for the previous release<br>
> > > (e.g. 3.2.3).<br>
> > ><br>
> > > Granted, this would impact much fewer patches than our current pain point does.<br>
> ><br>
> > Let's take a step back for a moment and define the workflows we want to handle.<br>
> ><br>
> > 1. Feature development<br>
> ><br>
> > - simplest case<br>
> > - just edit Misc/NEWS on default<br>
> ><br>
> > 2. Normal 3.x only bug fix<br>
> ><br>
> > - second simplest case<br>
> > - exit Misc/NEWS on 3.3<br>
> > - merge to default<br>
> > - frequently conflict (due to entries for new features and different<br>
> > release headers)<br>
> > ....<br>
> ><br>
> > OK, I'm going to stop enumerating the cases there, because it already<br>
> > suggests to me that splitting the *whole* NEWS file entirely by<br>
> > version is the wrong thing to do. Instead, we really only need to<br>
> > split the handling for NEWS items that haven't been released yet.<br>
> ><br>
> > To avoid needing to copy info from other branches between files when<br>
> > doing a merge, we could instead set up the following:<br>
> ><br>
> > 1. Add a new directory called NEWS.next<br>
> > 2. New NEWS entries go in version specific files in that directory<br>
> > 3. When a new release is made, ALL entries in NEWS.next are added to<br>
> > the top of the main NEWS file for the relevant (a script to help with<br>
> > the merging would be a good idea) and the contents of NEWS.next are<br>
> > cleared.<br>
> ><br>
> > So, suppose we're about to release 3.4.0a1. In the meantime, we have<br>
> > accumulated bug fixes for 3.3 and new features and bug fixes that<br>
> > couldn't be backported for 3.4. (The scheme could be extended to<br>
> > security branches too, but I'm assuming for the moment those will be<br>
> > handled via selective backporting rather than the normal forward<br>
> > porting path)<br>
> ><br>
> > The 3.3 branch layout would look like this:<br>
> ><br>
> >     NEWS.next/<br>
> >         3.3.txt  # Categorised changes<br>
> >     NEWS  # Existing partial entry for 3.3.x<br>
> ><br>
> > The default branch layout would look like this:<br>
> ><br>
> >     NEWS.next/<br>
> >         3.3.txt  # Forward ported categorised changes<br>
> >         3.4.txt  # Categorised changes<br>
> >    NEWS  # Existing partial entry for 3.4.0a1<br>
> ><br>
> > Any changes that were specific to 3.3 would be listed in<br>
> > NEWS.next/3.3.txt on that branch, but not on the default branch (since<br>
> > the associated null-merge would have skipped adding them)<br>
> ><br>
> > Now, we go to create 3.4.0a1. This will involve transferring *all* the<br>
> > NEWS.next entries on default into the main NEWS file and clearing the<br>
> > files in NEWS.next.<br>
> ><br>
> >     NEWS.next/<br>
> >         3.3.txt  # Empty file<br>
> >         3.4.txt  # Empty file<br>
> >    NEWS  # Complete entry for 3.4.0<br>
> ><br>
> > The part I'm not clear on is whether we'd then start getting conflicts<br>
> > when forwarding merging changes to NEWS.next/3.3.txt from the 3.3<br>
> > branch, or if Mercurial would be smart enough to cope with the<br>
> > deletion for the file contents and not try to add them back in. If it<br>
> > can't cope, then it would be possible to do the following on 3.3 when<br>
> > creating the initial 3.4.0a1 release:<br>
> ><br>
> >     NEWS.next/<br>
> >         3.3.txt  # Empty file<br>
> >    NEWS  # Longer partial entry for 3.3.x<br>
> ><br>
> > We then continuing accumulating NEWS.next entries in parallel during<br>
> > the 3.4 alpha and beta cycle, moving the entries into the appropriate<br>
> > NEWS files as releases are made.<br>
> ><br>
> > The other advantage of this is that it's an approach we can adopt<br>
> > *today*, so long as we acknowledge we'll need the tooling to merge the<br>
> > NEWS entries and clear NEWS.next before we can next do a release for<br>
> > 3.3 and 3.4, and Georg and Larry are happy with that notion.<br>
> ><br>
><br>
> I like where you're heading with this but it still leaves merges during Spruits and when a few people are working at once by putting stuff in a single file.</p>
<p dir="ltr">sprints</p>
<p dir="ltr">><br>
> Per news item / per issue files for each release that are riled up into the actual news file by a release manager run script & commit at release time make more sense.<br>
><br>
> > Cheers,<br>
> > Nick.<br>
> ><br>
> > --<br>
> > Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<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>
</p>