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

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.

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.

> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia
> _______________________________________________
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers