From bcannon at gmail.com  Tue Aug  4 00:07:22 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Mon, 03 Aug 2015 22:07:22 +0000
Subject: [core-workflow] Roundup query to find out who is active on the
	tracker?
Message-ID: <CAP1=2W7S0xgJQX9kQ2R8YffkHObic3z2=HHFSzNhix9t6+_Wbw@mail.gmail.com>

Up until now we have always handed out Developer privileges when someone
happens to notice a person is active on the issue tracker. Is there a
Roundup query we can run which will get us hard numbers so we don't have to
guess anymore? That way we can check the results of the query on occasion,
see who people think warrants Developer privileges, and then give those
privileges to them? That would let us get more people triaging which frees
up core dev time to do more of the committer reviews and actual committing
of patches.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150803/21d5a461/attachment.html>

From ezio.melotti at gmail.com  Tue Aug  4 01:27:56 2015
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Tue, 4 Aug 2015 02:27:56 +0300
Subject: [core-workflow] Roundup query to find out who is active on the
	tracker?
In-Reply-To: <CAP1=2W7S0xgJQX9kQ2R8YffkHObic3z2=HHFSzNhix9t6+_Wbw@mail.gmail.com>
References: <CAP1=2W7S0xgJQX9kQ2R8YffkHObic3z2=HHFSzNhix9t6+_Wbw@mail.gmail.com>
Message-ID: <CACBhJdF4kTq8ryYjgvOf80X8VRKDTfeST3Hn_2J7yPFe3K-J1w@mail.gmail.com>

On Tue, Aug 4, 2015 at 1:07 AM, Brett Cannon <bcannon at gmail.com> wrote:
> Up until now we have always handed out Developer privileges when someone
> happens to notice a person is active on the issue tracker. Is there a
> Roundup query we can run which will get us hard numbers so we don't have to
> guess anymore? That way we can check the results of the query on occasion,
> see who people think warrants Developer privileges, and then give those
> privileges to them? That would let us get more people triaging which frees
> up core dev time to do more of the committer reviews and actual committing
> of patches.
>

I don't think this is possible right now, unless you use xmlrpc and do
something similar to what the roundup-summary [0] does.
Once the REST API is added to Roundup it should be easier.

Best Regards,
Ezio Melotti

[0]: https://hg.python.org/tracker/python-dev/file/f82ad5af3cc2/scripts/roundup-summary

From bcannon at gmail.com  Wed Aug  5 00:26:45 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Tue, 04 Aug 2015 22:26:45 +0000
Subject: [core-workflow] Testing out proposed new workflows
Message-ID: <CAP1=2W50MBf9TrNJYoy+m6BhfE09z7VMwE=v6aD=3ZSG5Mwx6w@mail.gmail.com>

I have come to realize that asking for conversions of the devguide and peps
repos to test with really won't give an accurate representation of how the
workflows will apply to the cpython repository. Because of that I would
like to see a test repo that starts from the cpython repo at some point in
time that people can use to test things such as clean patch submissions,
merge conflict submissions, etc. I'm not expecting Roundup integration for
this nor that commits be integrated back into the repository of record.
Basically I want to be able to grab a patch from Roundup and somehow apply
it against a test repo to see how the workflow will work where I play both
submitter and committer (e.g., a GitHub test repo where I can submit my own
PRs against it that I know will fully succeed or have a merge conflict to
test how things will look on both ends).

Nick and Donald, do you think you can have such a test setup up and running
by October 31 (Halloween, 88 days away)? If you honestly need more time I
am willing to extend to November 15 (the cut-off in the retail industry to
consider something in stores for Christmas, 113 days away), but I only want
to do that if you honestly think the 15 extra days will make a difference.
These dates will be enough for me and any other core developers who are
interested to try out the test repos, give me feedback, and allow me to
make a decision no later than January 1, 2016 so we can start the new year
off towards getting our workflow back on track.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150804/097da5b5/attachment.html>

From ncoghlan at gmail.com  Wed Aug  5 14:05:34 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 5 Aug 2015 22:05:34 +1000
Subject: [core-workflow] Testing out proposed new workflows
In-Reply-To: <CAP1=2W50MBf9TrNJYoy+m6BhfE09z7VMwE=v6aD=3ZSG5Mwx6w@mail.gmail.com>
References: <CAP1=2W50MBf9TrNJYoy+m6BhfE09z7VMwE=v6aD=3ZSG5Mwx6w@mail.gmail.com>
Message-ID: <CADiSq7cNZ-rXpA4BFOG0w9KyeOBLQsW3vHxtVUJgoPAb9GR-NA@mail.gmail.com>

On 5 August 2015 at 08:26, Brett Cannon <bcannon at gmail.com> wrote:
> Nick and Donald, do you think you can have such a test setup up and running
> by October 31 (Halloween, 88 days away)?

I'm planning to use Kallithea as my guinea-pig project for user level
package management in Fedora, so this will be a good test case for
carrying patches that haven't been merged back upstream yet.

Since this won't need any of the integration-with-other-services
aspects, October 31 should definitely be doable.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Wed Aug  5 15:22:34 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 5 Aug 2015 23:22:34 +1000
Subject: [core-workflow] Testing out proposed new workflows
In-Reply-To: <CADiSq7cNZ-rXpA4BFOG0w9KyeOBLQsW3vHxtVUJgoPAb9GR-NA@mail.gmail.com>
References: <CAP1=2W50MBf9TrNJYoy+m6BhfE09z7VMwE=v6aD=3ZSG5Mwx6w@mail.gmail.com>
 <CADiSq7cNZ-rXpA4BFOG0w9KyeOBLQsW3vHxtVUJgoPAb9GR-NA@mail.gmail.com>
Message-ID: <CADiSq7dWLBm7SqEkbNXsRf+QUJJna0eePyvrC1MJx6CAeHzbZg@mail.gmail.com>

On 5 August 2015 at 22:05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 5 August 2015 at 08:26, Brett Cannon <bcannon at gmail.com> wrote:
>> Nick and Donald, do you think you can have such a test setup up and running
>> by October 31 (Halloween, 88 days away)?
>
> I'm planning to use Kallithea as my guinea-pig project for user level
> package management in Fedora, so this will be a good test case for
> carrying patches that haven't been merged back upstream yet.
>
> Since this won't need any of the integration-with-other-services
> aspects, October 31 should definitely be doable.

After merging a docs patch forward from 3.4 to 3.5 and hence to
default, I do have a related request for you or David, though: would
one of you have time to review the currently proposed options and
decide what we're going to do about autogenerating Misc/NEWS?

The status quo is already broken for Larry's "separate repo" approach
to release candidate preparation, and moving to a fully online review
workflow is going to make it broken in general. I suspect a moderately
unilateral "we are going to switch to generating Misc/NEWS <this way>"
from one of you is about the only way we're going to get over the
activation barrier.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From bcannon at gmail.com  Wed Aug  5 19:59:32 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Wed, 05 Aug 2015 17:59:32 +0000
Subject: [core-workflow] Testing out proposed new workflows
In-Reply-To: <CADiSq7dWLBm7SqEkbNXsRf+QUJJna0eePyvrC1MJx6CAeHzbZg@mail.gmail.com>
References: <CAP1=2W50MBf9TrNJYoy+m6BhfE09z7VMwE=v6aD=3ZSG5Mwx6w@mail.gmail.com>
 <CADiSq7cNZ-rXpA4BFOG0w9KyeOBLQsW3vHxtVUJgoPAb9GR-NA@mail.gmail.com>
 <CADiSq7dWLBm7SqEkbNXsRf+QUJJna0eePyvrC1MJx6CAeHzbZg@mail.gmail.com>
Message-ID: <CAP1=2W5nJv9d5MjcxA_8e_==YrE+5=cZX6z0ims+0NhZJoBeSQ@mail.gmail.com>

On Wed, Aug 5, 2015 at 6:22 AM Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 5 August 2015 at 22:05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > On 5 August 2015 at 08:26, Brett Cannon <bcannon at gmail.com> wrote:
> >> Nick and Donald, do you think you can have such a test setup up and
> running
> >> by October 31 (Halloween, 88 days away)?
> >
> > I'm planning to use Kallithea as my guinea-pig project for user level
> > package management in Fedora, so this will be a good test case for
> > carrying patches that haven't been merged back upstream yet.
> >
> > Since this won't need any of the integration-with-other-services
> > aspects, October 31 should definitely be doable.
>

Great! Just need to hear from Donald then on whether the dates work.


>
> After merging a docs patch forward from 3.4 to 3.5 and hence to
> default, I do have a related request for you or David, though: would
> one of you have time to review the currently proposed options and
> decide what we're going to do about autogenerating Misc/NEWS?
>
> The status quo is already broken for Larry's "separate repo" approach
> to release candidate preparation, and moving to a fully online review
> workflow is going to make it broken in general. I suspect a moderately
> unilateral "we are going to switch to generating Misc/NEWS <this way>"
> from one of you is about the only way we're going to get over the
> activation barrier.
>

I already assumed we were going to tweak how we did Misc/NEWS somehow,
whether it was separate files for each release/branch, somehow
automatically generating it from commits, etc. If David's up for hashing it
out with me I'm sure we can figure some solution out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150805/0c627e87/attachment.html>

From rdmurray at bitdance.com  Wed Aug  5 22:47:53 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 05 Aug 2015 16:47:53 -0400
Subject: [core-workflow] Testing out proposed new workflows
In-Reply-To: <CAP1=2W5nJv9d5MjcxA_8e_==YrE+5=cZX6z0ims+0NhZJoBeSQ@mail.gmail.com>
References: <CAP1=2W50MBf9TrNJYoy+m6BhfE09z7VMwE=v6aD=3ZSG5Mwx6w@mail.gmail.com>
 <CADiSq7cNZ-rXpA4BFOG0w9KyeOBLQsW3vHxtVUJgoPAb9GR-NA@mail.gmail.com>
 <CADiSq7dWLBm7SqEkbNXsRf+QUJJna0eePyvrC1MJx6CAeHzbZg@mail.gmail.com>
 <CAP1=2W5nJv9d5MjcxA_8e_==YrE+5=cZX6z0ims+0NhZJoBeSQ@mail.gmail.com>
Message-ID: <20150805204753.BE2E6250F07@webabinitio.net>

On Wed, 05 Aug 2015 17:59:32 -0000, Brett Cannon <bcannon at gmail.com> wrote:
> I already assumed we were going to tweak how we did Misc/NEWS somehow,
> whether it was separate files for each release/branch, somehow
> automatically generating it from commits, etc. If David's up for hashing it
> out with me I'm sure we can figure some solution out.

Yes, let's have at it and get that done.  I should have at least some
time for it this weekend, and emails before then if you want to start the
process.

--David

From bcannon at gmail.com  Thu Aug  6 07:30:02 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Thu, 06 Aug 2015 05:30:02 +0000
Subject: [core-workflow] the Misc/NEWS problem
Message-ID: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>

If we ever want to have a nice workflow where we can automate as much as
possible, we need to figure out a way deal with our most common merge
conflict: Misc/NEWS. Thanks to shifts in the format between different minor
versions the file is pretty much guaranteed to have a conflict when doing a
merge up a version.

So how do we solve this? I can remember 3 possible solutions that have been
proposed previously:

   1. A single file per entry
   2. A single file per release version of Python
   3. Automating it based on commit messages

I personally prefer #3 as I hate repeating myself since I just copy and
paste the first line(s) of my commits to Misc/NEWS as it is anyway
(basically up to the first pair of newlines). We would need a way to signal
that the commit message contains nothing useful for the to-be-generated
NEWS file when it's simply a fix for a previous commit (probably some
marker that is somewhat inconspicuous like a dash on its own line or
something). In terms of the section of the NEWS file that a commit belongs,
that can once again be a marker or honestly something we drop or infer
based on what files were edited in the commit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150806/788e7d24/attachment.html>

From zachary.ware+pydev at gmail.com  Thu Aug  6 07:43:40 2015
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Thu, 6 Aug 2015 00:43:40 -0500
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
Message-ID: <CAKJDb-Pa6rCDuafP6KzYzYf8SMiS4rU2RhN-raBk6nbZ=REfVg@mail.gmail.com>

On Thursday, August 6, 2015, Brett Cannon <bcannon at gmail.com> wrote:

> If we ever want to have a nice workflow where we can automate as much as
> possible, we need to figure out a way deal with our most common merge
> conflict: Misc/NEWS. Thanks to shifts in the format between different minor
> versions the file is pretty much guaranteed to have a conflict when doing a
> merge up a version.
>
> So how do we solve this? I can remember 3 possible solutions that have
> been proposed previously:
>
>    1. A single file per entry
>    2. A single file per release version of Python
>    3. Automating it based on commit messages
>
> I personally prefer #3 as I hate repeating myself since I just copy and
> paste the first line(s) of my commits to Misc/NEWS as it is anyway
> (basically up to the first pair of newlines). We would need a way to signal
> that the commit message contains nothing useful for the to-be-generated
> NEWS file when it's simply a fix for a previous commit (probably some
> marker that is somewhat inconspicuous like a dash on its own line or
> something). In terms of the section of the NEWS file that a commit belongs,
> that can once again be a marker or honestly something we drop or infer
> based on what files were edited in the commit.
>

See also http://bugs.python.org/issue18967, which even has a couple of
sample implementations.

--
Zach
(On an iPad)


-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150806/b44d14ee/attachment-0001.html>

From willingc at willingconsulting.com  Thu Aug  6 09:48:57 2015
From: willingc at willingconsulting.com (Carol Willing)
Date: Thu, 6 Aug 2015 00:48:57 -0700
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <CAKJDb-Pa6rCDuafP6KzYzYf8SMiS4rU2RhN-raBk6nbZ=REfVg@mail.gmail.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <CAKJDb-Pa6rCDuafP6KzYzYf8SMiS4rU2RhN-raBk6nbZ=REfVg@mail.gmail.com>
Message-ID: <55C31169.7030801@willingconsulting.com>

On 8/5/15 10:43 PM, Zachary Ware wrote:
> On Thursday, August 6, 2015, Brett Cannon <bcannon at gmail.com 
> <mailto:bcannon at gmail.com>> wrote:
>
>     If we ever want to have a nice workflow where we can automate as
>     much as possible, we need to figure out a way deal with our most
>     common merge conflict: Misc/NEWS. Thanks to shifts in the format
>     between different minor versions the file is pretty much
>     guaranteed to have a conflict when doing a merge up a version.
>
>     So how do we solve this? I can remember 3 possible solutions that
>     have been proposed previously:
>
>      1. A single file per entry
>      2. A single file per release version of Python
>      3. Automating it based on commit messages
>
>     I personally prefer #3 as I hate repeating myself since I just
>     copy and paste the first line(s) of my commits to Misc/NEWS as it
>     is anyway (basically up to the first pair of newlines). We would
>     need a way to signal that the commit message contains nothing
>     useful for the to-be-generated NEWS file when it's simply a fix
>     for a previous commit (probably some marker that is somewhat
>     inconspicuous like a dash on its own line or something). In terms
>     of the section of the NEWS file that a commit belongs, that can
>     once again be a marker or honestly something we drop or infer
>     based on what files were edited in the commit.
>
>
> See also http://bugs.python.org/issue18967, which even has a couple of 
> sample implementations.

Thanks Zach. This issue has interesting reading.

The crux of that issue's discussion balances: a) the desire for 
automation of generating the NEWS file with b) the desire to provide 
useful information to the users.

Something similar to Firefox's approach 
https://www.mozilla.org/en-US/firefox/39.0/releasenotes/ may be 
reasonable. Putting implementation and display aside for the moment, the 
Firefox approach gives: 1) user friendly info on a subset of 
news/release items and 2) a link to a comprehensive list of changes.

Even if one wanted a text file similar to the current NEWS file, one 
could still take the Firefox approach. Put user friendly highlights for 
a subset of key issues (which would require some manual intervention 
though much less than now) and follow that with a comprehensive list of 
changes using one of the proposed options based on commit messages.

Carol

>
> --
> Zach
> (On an iPad)
>
>
> -- 
> Sent from Gmail Mobile
>
>
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct


-- 
*Carol Willing*
Developer | Willing Consulting
https://willingconsulting.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150806/e61f59b0/attachment.html>

From mal at egenix.com  Thu Aug  6 11:59:48 2015
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 06 Aug 2015 11:59:48 +0200
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
Message-ID: <55C33014.40708@egenix.com>

On 06.08.2015 07:30, Brett Cannon wrote:
> If we ever want to have a nice workflow where we can automate as much as
> possible, we need to figure out a way deal with our most common merge
> conflict: Misc/NEWS. Thanks to shifts in the format between different minor
> versions the file is pretty much guaranteed to have a conflict when doing a
> merge up a version.
> 
> So how do we solve this? I can remember 3 possible solutions that have been
> proposed previously:
> 
>    1. A single file per entry
>    2. A single file per release version of Python
>    3. Automating it based on commit messages

I had mentioned a fourth one:

     4. Add a NEWS field to the issue tracker and use it's content
        for the file entry

This is how eGenix does it and it's been working great so far.
We simply have our issue tracker generate a report and use
this as basis for the change log when cutting a release.

The advantage over checkin messages is that you are not stuck
if you have multiple checkins for a single issue which should
only have a single entry in the change log.

Without using the issue tracker, this is similar to approach
#2 you mentioned above, but with only creating that file
once during the release process instead of patching it up with
every single checkin.

> I personally prefer #3 as I hate repeating myself since I just copy and
> paste the first line(s) of my commits to Misc/NEWS as it is anyway
> (basically up to the first pair of newlines). We would need a way to signal
> that the commit message contains nothing useful for the to-be-generated
> NEWS file when it's simply a fix for a previous commit (probably some
> marker that is somewhat inconspicuous like a dash on its own line or
> something). In terms of the section of the NEWS file that a commit belongs,
> that can once again be a marker or honestly something we drop or infer
> based on what files were edited in the commit.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 06 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> mxODBC Plone/Zope Database Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From ncoghlan at gmail.com  Thu Aug  6 13:07:29 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 6 Aug 2015 21:07:29 +1000
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <55C33014.40708@egenix.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C33014.40708@egenix.com>
Message-ID: <CADiSq7fNikAsUWZy6vMykbnzvin6KCEPqyto6fzohwJdZJ9FKg@mail.gmail.com>

On 6 August 2015 at 19:59, M.-A. Lemburg <mal at egenix.com> wrote:
> I had mentioned a fourth one:
>
>      4. Add a NEWS field to the issue tracker and use it's content
>         for the file entry
>
> This is how eGenix does it and it's been working great so far.
> We simply have our issue tracker generate a report and use
> this as basis for the change log when cutting a release.
>
> The advantage over checkin messages is that you are not stuck
> if you have multiple checkins for a single issue which should
> only have a single entry in the change log.
>
> Without using the issue tracker, this is similar to approach
> #2 you mentioned above, but with only creating that file
> once during the release process instead of patching it up with
> every single checkin.

This is fairly similar to the way Red Hat does it for downstream
products - the docs team figure out the Errata text for end users
based on the bug, then that's mapped to the right places accordingly.

Eventually pursuing that approach would give us a few rich tiers of information:

* full commit logs
* commit logs filtered to just be those which mention bug numbers
* issue tracker NEWS items mentioned in commit entries
* the What's New documentation

However, given that we're always going to be able to generate full
commit logs, and the filtered logs that mention issues, I think that
makes for a good place to start, even if we end up adding a new field
to the tracker later. After all, we'll always need to write commit
messages regardless of what else we do.

Something I *would* like to address up front is how we're going to
deal with errors in commit messages (especially cases where we've
failed to mention an issue number, or have mentioned the wrong one).
However, having a commit log based generator offers a relatively
decent way to deal with that: a Misc/NEWS.overrides directory, with
filename prefixes based on the commit hashes to be overridden.

Dealing with the forward merges will also be necessary - existing
projects https://pypi.python.org/pypi/gitchangelog may provide useful
ideas on that front.

If we wanted to get particularly fancy, commits that added
versionadded and versionchanged tags to the documentation could also
be automatically highlighted.

Regardless, I think one thing I'm figuring out from this discussion is
that there *shouldn't be* a NEWS file in the repo itself - the repo
will contain the source data, but the rendering can happen separately
rather than being done incrementally on each commit. This means that
the renderer can be developed in parallel with the current process,
with some seed data used to capture the state of the NEWS file as of a
particular commit.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From bcannon at gmail.com  Thu Aug  6 20:04:13 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Thu, 06 Aug 2015 18:04:13 +0000
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <55C33014.40708@egenix.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C33014.40708@egenix.com>
Message-ID: <CAP1=2W5oZ6YQSkorMnmsKyAsK2_Jv6iJURpgcjAujhH=1UzkpQ@mail.gmail.com>

On Thu, Aug 6, 2015 at 2:59 AM M.-A. Lemburg <mal at egenix.com> wrote:

> On 06.08.2015 07:30, Brett Cannon wrote:
> > If we ever want to have a nice workflow where we can automate as much as
> > possible, we need to figure out a way deal with our most common merge
> > conflict: Misc/NEWS. Thanks to shifts in the format between different
> minor
> > versions the file is pretty much guaranteed to have a conflict when
> doing a
> > merge up a version.
> >
> > So how do we solve this? I can remember 3 possible solutions that have
> been
> > proposed previously:
> >
> >    1. A single file per entry
> >    2. A single file per release version of Python
> >    3. Automating it based on commit messages
>
> I had mentioned a fourth one:
>
>      4. Add a NEWS field to the issue tracker and use it's content
>         for the file entry
>
> This is how eGenix does it and it's been working great so far.
> We simply have our issue tracker generate a report and use
> this as basis for the change log when cutting a release.
>

It also takes care of categorization since we can just grab that from the
Components field.


>
> The advantage over checkin messages is that you are not stuck
> if you have multiple checkins for a single issue which should
> only have a single entry in the change log.
>
> Without using the issue tracker, this is similar to approach
> #2 you mentioned above, but with only creating that file
> once during the release process instead of patching it up with
> every single checkin.
>

The only drawback I see to this is it will require an issue for every
change that should go into the changelog. Now I actually think that's a
good thing, but I can see some pushback from python-dev by those who don't
want the hassle. But I would argue that any change significant enough to
warrant an entry in the changelog warrants an issue to track it.

-Brett


>
> > I personally prefer #3 as I hate repeating myself since I just copy and
> > paste the first line(s) of my commits to Misc/NEWS as it is anyway
> > (basically up to the first pair of newlines). We would need a way to
> signal
> > that the commit message contains nothing useful for the to-be-generated
> > NEWS file when it's simply a fix for a previous commit (probably some
> > marker that is somewhat inconspicuous like a dash on its own line or
> > something). In terms of the section of the NEWS file that a commit
> belongs,
> > that can once again be a marker or honestly something we drop or infer
> > based on what files were edited in the commit.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source  (#1, Aug 06 2015)
> >>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
> >>> mxODBC Plone/Zope Database Adapter ...       http://zope.egenix.com/
> >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
> ________________________________________________________________________
>
> ::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::
>
>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>            Registered at Amtsgericht Duesseldorf: HRB 46611
>                http://www.egenix.com/company/contact/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150806/5d6d2a96/attachment.html>

From bcannon at gmail.com  Thu Aug  6 20:16:53 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Thu, 06 Aug 2015 18:16:53 +0000
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <CADiSq7fNikAsUWZy6vMykbnzvin6KCEPqyto6fzohwJdZJ9FKg@mail.gmail.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C33014.40708@egenix.com>
 <CADiSq7fNikAsUWZy6vMykbnzvin6KCEPqyto6fzohwJdZJ9FKg@mail.gmail.com>
Message-ID: <CAP1=2W7mo=XEEKccPyjcj6GdBc1n1DHQkUS1ryufL3EQgZnRow@mail.gmail.com>

On Thu, Aug 6, 2015 at 4:07 AM Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 6 August 2015 at 19:59, M.-A. Lemburg <mal at egenix.com> wrote:
> > I had mentioned a fourth one:
> >
> >      4. Add a NEWS field to the issue tracker and use it's content
> >         for the file entry
> >
> > This is how eGenix does it and it's been working great so far.
> > We simply have our issue tracker generate a report and use
> > this as basis for the change log when cutting a release.
> >
> > The advantage over checkin messages is that you are not stuck
> > if you have multiple checkins for a single issue which should
> > only have a single entry in the change log.
> >
> > Without using the issue tracker, this is similar to approach
> > #2 you mentioned above, but with only creating that file
> > once during the release process instead of patching it up with
> > every single checkin.
>
> This is fairly similar to the way Red Hat does it for downstream
> products - the docs team figure out the Errata text for end users
> based on the bug, then that's mapped to the right places accordingly.
>
> Eventually pursuing that approach would give us a few rich tiers of
> information:
>
> * full commit logs
> * commit logs filtered to just be those which mention bug numbers
> * issue tracker NEWS items mentioned in commit entries
> * the What's New documentation
>
> However, given that we're always going to be able to generate full
> commit logs, and the filtered logs that mention issues, I think that
> makes for a good place to start, even if we end up adding a new field
> to the tracker later. After all, we'll always need to write commit
> messages regardless of what else we do.
>

What is "that"? You forgot to specify which alternative you were proposing
to use as an interim to adding a field to the issue tracker.


>
> Something I *would* like to address up front is how we're going to
> deal with errors in commit messages (especially cases where we've
> failed to mention an issue number, or have mentioned the wrong one).
>

Does this mean you are talking about proposal #3 (generating from commit
message)?


> However, having a commit log based generator offers a relatively
> decent way to deal with that: a Misc/NEWS.overrides directory, with
> filename prefixes based on the commit hashes to be overridden.
>

This is making me prefer MAL's #4 solution.


>
> Dealing with the forward merges will also be necessary - existing
> projects https://pypi.python.org/pypi/gitchangelog may provide useful
> ideas on that front.
>

I would simply ignore merge commits. It's implied that anything fixed in
the previous minor release applies to the default branch. Once again, MAL's
approach helps with this as we would simply check the Versions field.


>
> If we wanted to get particularly fancy, commits that added
> versionadded and versionchanged tags to the documentation could also
> be automatically highlighted.
>
> Regardless, I think one thing I'm figuring out from this discussion is
> that there *shouldn't be* a NEWS file in the repo itself - the repo
> will contain the source data, but the rendering can happen separately
> rather than being done incrementally on each commit. This means that
> the renderer can be developed in parallel with the current process,
> with some seed data used to capture the state of the NEWS file as of a
> particular commit.
>

After this email I'm now supporting MAL's idea #4. We can make the field
required when the Resolution is set to Fixed. I would even potentially
argue for a dropdown for What's New inclusion to flag whether a What's New
mention is warranted. By making this a required field to set it would
greatly simplify the writing of that doc later by having a generated list
of all issues that require a mention, effectively creating a TODO list
instead of having to hunt through all commits or the entire changelog (and
I don't think we can ask non-core contributors to provide What's New text
if we want to keep the quality of that doc high).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150806/328a990e/attachment-0001.html>

From willingc at willingconsulting.com  Thu Aug  6 20:51:53 2015
From: willingc at willingconsulting.com (Carol Willing)
Date: Thu, 6 Aug 2015 11:51:53 -0700
Subject: [core-workflow] Semi-official GitHub Mirror of the devguide
Message-ID: <55C3ACC9.4000506@willingconsulting.com>

Since both CPython and the PEPs have GitHub mirrors, I believe it would 
be helpful to have the devguide as a semi-official mirror as well.

Please let me know what next steps need to be taken to make this happen.

Thanks,
Carol

From rdmurray at bitdance.com  Thu Aug  6 21:46:04 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 06 Aug 2015 15:46:04 -0400
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <CAP1=2W7mo=XEEKccPyjcj6GdBc1n1DHQkUS1ryufL3EQgZnRow@mail.gmail.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C33014.40708@egenix.com>
 <CADiSq7fNikAsUWZy6vMykbnzvin6KCEPqyto6fzohwJdZJ9FKg@mail.gmail.com>
 <CAP1=2W7mo=XEEKccPyjcj6GdBc1n1DHQkUS1ryufL3EQgZnRow@mail.gmail.com>
Message-ID: <20150806194604.D704D250FDE@webabinitio.net>

On Thu, 06 Aug 2015 18:16:53 -0000, Brett Cannon <bcannon at gmail.com> wrote:
> > However, having a commit log based generator offers a relatively
> > decent way to deal with that: a Misc/NEWS.overrides directory, with
> > filename prefixes based on the commit hashes to be overridden.
> >
> 
> This is making me prefer MAL's #4 solution.

I'm liking this solution as well...there's programming work to be done
regardless, and adding a tracker field isn't *that* hard.

However, the problem Nick points out above is really still an issue we
ought to address at some point even if we don't take NEWS info from the
commit messages, because it would be nice to be able to do some
automated checks about the relationships between issues and commits, and
to do that we have to have some way to "edit" the commit messages where
we specify the wrong issue number.

Could there be some sort of Mercurial solution for that problem?

In addition to the "NEWS relevant changes *must* have a tracker issue"
(which I agree is good anyway), another thing to keep in mind for the
tracker based proposal is that it will make the versions and resolution
fields more meaningful, and thus more care must be taken with those
fields.  I don't see this as a bad thing either, but it is something we
need to recognize and deal with if we deploy this solution.

Oh, and it does mean that the technique we have sometimes used of
removing versions from the list once the fix is committed to that
version would have to be changed.  So that involves some retraining
as well.

--David

From bcannon at gmail.com  Thu Aug  6 22:06:46 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Thu, 06 Aug 2015 20:06:46 +0000
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <20150806194604.D704D250FDE@webabinitio.net>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C33014.40708@egenix.com>
 <CADiSq7fNikAsUWZy6vMykbnzvin6KCEPqyto6fzohwJdZJ9FKg@mail.gmail.com>
 <CAP1=2W7mo=XEEKccPyjcj6GdBc1n1DHQkUS1ryufL3EQgZnRow@mail.gmail.com>
 <20150806194604.D704D250FDE@webabinitio.net>
Message-ID: <CAP1=2W6Xvc9CV05hZ0YV_LOa_kUx4C1jxFivxHzcu6f7p36j=A@mail.gmail.com>

On Thu, Aug 6, 2015 at 12:46 PM R. David Murray <rdmurray at bitdance.com>
wrote:

> On Thu, 06 Aug 2015 18:16:53 -0000, Brett Cannon <bcannon at gmail.com>
> wrote:
> > > However, having a commit log based generator offers a relatively
> > > decent way to deal with that: a Misc/NEWS.overrides directory, with
> > > filename prefixes based on the commit hashes to be overridden.
> > >
> >
> > This is making me prefer MAL's #4 solution.
>
> I'm liking this solution as well...there's programming work to be done
> regardless, and adding a tracker field isn't *that* hard.
>
> However, the problem Nick points out above is really still an issue we
> ought to address at some point even if we don't take NEWS info from the
> commit messages, because it would be nice to be able to do some
> automated checks about the relationships between issues and commits, and
> to do that we have to have some way to "edit" the commit messages where
> we specify the wrong issue number.


> Could there be some sort of Mercurial solution for that problem?
>
>
Short or an errata file for commit messages I don't think there is thanks
to Mercurial's strong stance on immutable commit data. Does git even allow
editing the commit message after the fact?


> In addition to the "NEWS relevant changes *must* have a tracker issue"
> (which I agree is good anyway), another thing to keep in mind for the
> tracker based proposal is that it will make the versions and resolution
> fields more meaningful, and thus more care must be taken with those
> fields.  I don't see this as a bad thing either, but it is something we
> need to recognize and deal with if we deploy this solution.
>

Yep.


>
> Oh, and it does mean that the technique we have sometimes used of
> removing versions from the list once the fix is committed to that
> version would have to be changed.  So that involves some retraining
> as well.
>

Yes, it would mean either a second field to list what versions the fix has
been applied to (eww), or simply having to read through the messages of the
issue to keep track of where a fix still need to be applied and not
considering it fixed until all versions have received the fix.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150806/c5b6da75/attachment.html>

From donald at stufft.io  Thu Aug  6 22:12:10 2015
From: donald at stufft.io (Donald Stufft)
Date: Thu, 6 Aug 2015 16:12:10 -0400
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <CAP1=2W6Xvc9CV05hZ0YV_LOa_kUx4C1jxFivxHzcu6f7p36j=A@mail.gmail.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C33014.40708@egenix.com>
 <CADiSq7fNikAsUWZy6vMykbnzvin6KCEPqyto6fzohwJdZJ9FKg@mail.gmail.com>
 <CAP1=2W7mo=XEEKccPyjcj6GdBc1n1DHQkUS1ryufL3EQgZnRow@mail.gmail.com>
 <20150806194604.D704D250FDE@webabinitio.net>
 <CAP1=2W6Xvc9CV05hZ0YV_LOa_kUx4C1jxFivxHzcu6f7p36j=A@mail.gmail.com>
Message-ID: <9A6DC12E-91EB-4301-8580-86E411423CF5@stufft.io>


> On Aug 6, 2015, at 4:06 PM, Brett Cannon <bcannon at gmail.com> wrote:
> 
> 
> 
> On Thu, Aug 6, 2015 at 12:46 PM R. David Murray <rdmurray at bitdance.com <mailto:rdmurray at bitdance.com>> wrote:
> On Thu, 06 Aug 2015 18:16:53 -0000, Brett Cannon <bcannon at gmail.com <mailto:bcannon at gmail.com>> wrote:
> > > However, having a commit log based generator offers a relatively
> > > decent way to deal with that: a Misc/NEWS.overrides directory, with
> > > filename prefixes based on the commit hashes to be overridden.
> > >
> >
> > This is making me prefer MAL's #4 solution.
> 
> I'm liking this solution as well...there's programming work to be done
> regardless, and adding a tracker field isn't *that* hard.
> 
> However, the problem Nick points out above is really still an issue we
> ought to address at some point even if we don't take NEWS info from the
> commit messages, because it would be nice to be able to do some
> automated checks about the relationships between issues and commits, and
> to do that we have to have some way to "edit" the commit messages where
> we specify the wrong issue number. 
> 
> Could there be some sort of Mercurial solution for that problem?
> 
> 
> Short or an errata file for commit messages I don't think there is thanks to Mercurial's strong stance on immutable commit data. Does git even allow editing the commit message after the fact?

You can edit it sure, but it will create a new commit and divergent histories so it?s not going to do something generally useful for already pushed commits.

>  
> In addition to the "NEWS relevant changes *must* have a tracker issue"
> (which I agree is good anyway), another thing to keep in mind for the
> tracker based proposal is that it will make the versions and resolution
> fields more meaningful, and thus more care must be taken with those
> fields.  I don't see this as a bad thing either, but it is something we
> need to recognize and deal with if we deploy this solution.
> 
> Yep.
>  
> 
> Oh, and it does mean that the technique we have sometimes used of
> removing versions from the list once the fix is committed to that
> version would have to be changed.  So that involves some retraining
> as well.
> 
> Yes, it would mean either a second field to list what versions the fix has been applied to (eww), or simply having to read through the messages of the issue to keep track of where a fix still need to be applied and not considering it fixed until all versions have received the fix.
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org <mailto:core-workflow at python.org>
> https://mail.python.org/mailman/listinfo/core-workflow <https://mail.python.org/mailman/listinfo/core-workflow>
> This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct <https://www.python.org/psf/codeofconduct>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150806/0fe4c702/attachment-0001.html>

From ncoghlan at gmail.com  Fri Aug  7 04:17:21 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 7 Aug 2015 12:17:21 +1000
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <20150806194604.D704D250FDE@webabinitio.net>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C33014.40708@egenix.com>
 <CADiSq7fNikAsUWZy6vMykbnzvin6KCEPqyto6fzohwJdZJ9FKg@mail.gmail.com>
 <CAP1=2W7mo=XEEKccPyjcj6GdBc1n1DHQkUS1ryufL3EQgZnRow@mail.gmail.com>
 <20150806194604.D704D250FDE@webabinitio.net>
Message-ID: <CADiSq7cxPSzqbg1jR=YkSjR5oyKLASjjA6q5ttCuqeFuRc+pyg@mail.gmail.com>

On 7 August 2015 at 05:46, R. David Murray <rdmurray at bitdance.com> wrote:
> On Thu, 06 Aug 2015 18:16:53 -0000, Brett Cannon <bcannon at gmail.com> wrote:
>> > However, having a commit log based generator offers a relatively
>> > decent way to deal with that: a Misc/NEWS.overrides directory, with
>> > filename prefixes based on the commit hashes to be overridden.
>> >
>>
>> This is making me prefer MAL's #4 solution.
>
> I'm liking this solution as well...there's programming work to be done
> regardless, and adding a tracker field isn't *that* hard.
>
> However, the problem Nick points out above is really still an issue we
> ought to address at some point even if we don't take NEWS info from the
> commit messages, because it would be nice to be able to do some
> automated checks about the relationships between issues and commits, and
> to do that we have to have some way to "edit" the commit messages where
> we specify the wrong issue number.

One of the interesting aspects of Gerrit's workflow is that you get to
review the commit message in addition to the change itself, and I
think GitHub/BitBucket PRs allow that as well. This means that by the
time a change is merged, the correct issue reference will almost
always be there.

For Beaker, that "the commit message is covered by the review process"
aspect let us write
https://git.beaker-project.org/cgit/beaker-administrivia/tree/checkbugs.py
to audit the Gerrit review state against the corresponding Bugzilla
state, and investigate any anomalies to see whether it was the BZ
metadata or the Gerrit change proposal commit message that needed
updating. (Side note: creating a cpython-administrivia repo for easier
discoverability of workflow management utility scripts may not be a
bad idea, especially as we start making use of the REST API support
being added to Roundup)

In the Roundup+Mercurial case, I think we can deal with this more
comprehensively by actually storing our canonical issue->commit
reference in *Roundup*, and mentioning an issue number in a commit
would just be a way of creating those associations automatically. That
way, if we get it wrong at commit time (mentioning the wrong issue,
not mentioning an issue at all, creating an issue after we've already
done the work), then we can edit the commit associations on the
affected issues *in Roundup* to ensure the appropriate change info is
reported. If multiple commits were made referencing the same issue,
then we'd still only get one news entry for that issue, and if one
commit addresses multiple issues, then we'd get multiple news entries
(one per issue).

Since Mercurial associates commits with named branches, this would
also mean we'd be able to use the issue->commit tracking to determine
where a change had been applied, rather than the existing versions
field, so we'd be free to keep using the latter to keep track of
branches that still require updating.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From bcannon at gmail.com  Sat Aug  8 00:25:26 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Fri, 07 Aug 2015 22:25:26 +0000
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <CADiSq7cxPSzqbg1jR=YkSjR5oyKLASjjA6q5ttCuqeFuRc+pyg@mail.gmail.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C33014.40708@egenix.com>
 <CADiSq7fNikAsUWZy6vMykbnzvin6KCEPqyto6fzohwJdZJ9FKg@mail.gmail.com>
 <CAP1=2W7mo=XEEKccPyjcj6GdBc1n1DHQkUS1ryufL3EQgZnRow@mail.gmail.com>
 <20150806194604.D704D250FDE@webabinitio.net>
 <CADiSq7cxPSzqbg1jR=YkSjR5oyKLASjjA6q5ttCuqeFuRc+pyg@mail.gmail.com>
Message-ID: <CAP1=2W6RxTv+A5epYz8s8XCWTPTuPbJW+EE=BJ=GF-3PRO2NpA@mail.gmail.com>

On Thu, Aug 6, 2015 at 7:17 PM Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 7 August 2015 at 05:46, R. David Murray <rdmurray at bitdance.com> wrote:
> > On Thu, 06 Aug 2015 18:16:53 -0000, Brett Cannon <bcannon at gmail.com>
> wrote:
> >> > However, having a commit log based generator offers a relatively
> >> > decent way to deal with that: a Misc/NEWS.overrides directory, with
> >> > filename prefixes based on the commit hashes to be overridden.
> >> >
> >>
> >> This is making me prefer MAL's #4 solution.
> >
> > I'm liking this solution as well...there's programming work to be done
> > regardless, and adding a tracker field isn't *that* hard.
> >
> > However, the problem Nick points out above is really still an issue we
> > ought to address at some point even if we don't take NEWS info from the
> > commit messages, because it would be nice to be able to do some
> > automated checks about the relationships between issues and commits, and
> > to do that we have to have some way to "edit" the commit messages where
> > we specify the wrong issue number.
>
> One of the interesting aspects of Gerrit's workflow is that you get to
> review the commit message in addition to the change itself, and I
> think GitHub/BitBucket PRs allow that as well. This means that by the
> time a change is merged, the correct issue reference will almost
> always be there.
>

Yes, they both let you edit the commit message before accepting a PR.


>
> For Beaker, that "the commit message is covered by the review process"
> aspect let us write
> https://git.beaker-project.org/cgit/beaker-administrivia/tree/checkbugs.py
> to audit the Gerrit review state against the corresponding Bugzilla
> state, and investigate any anomalies to see whether it was the BZ
> metadata or the Gerrit change proposal commit message that needed
> updating. (Side note: creating a cpython-administrivia repo for easier
> discoverability of workflow management utility scripts may not be a
> bad idea, especially as we start making use of the REST API support
> being added to Roundup)
>
> In the Roundup+Mercurial case, I think we can deal with this more
> comprehensively by actually storing our canonical issue->commit
> reference in *Roundup*, and mentioning an issue number in a commit
> would just be a way of creating those associations automatically. That
> way, if we get it wrong at commit time (mentioning the wrong issue,
> not mentioning an issue at all, creating an issue after we've already
> done the work), then we can edit the commit associations on the
> affected issues *in Roundup* to ensure the appropriate change info is
> reported. If multiple commits were made referencing the same issue,
> then we'd still only get one news entry for that issue, and if one
> commit addresses multiple issues, then we'd get multiple news entries
> (one per issue).
>

So are you saying you want a field to paste in the commit numbers to do the
tracking? I assume you would want commit messages listing an issue to
automatically append to that field but have it editable to fix any typos in
the commit message.


>
> Since Mercurial associates commits with named branches, this would
> also mean we'd be able to use the issue->commit tracking to determine
> where a change had been applied, rather than the existing versions
> field, so we'd be free to keep using the latter to keep track of
> branches that still require updating.
>

Yes, and depending on how fancy we got, we could even decorate the Versions
field with some marker to show when a commit had been applied to a branch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150807/6e452e76/attachment.html>

From ncoghlan at gmail.com  Sat Aug  8 05:13:15 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 8 Aug 2015 13:13:15 +1000
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <CAP1=2W6RxTv+A5epYz8s8XCWTPTuPbJW+EE=BJ=GF-3PRO2NpA@mail.gmail.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C33014.40708@egenix.com>
 <CADiSq7fNikAsUWZy6vMykbnzvin6KCEPqyto6fzohwJdZJ9FKg@mail.gmail.com>
 <CAP1=2W7mo=XEEKccPyjcj6GdBc1n1DHQkUS1ryufL3EQgZnRow@mail.gmail.com>
 <20150806194604.D704D250FDE@webabinitio.net>
 <CADiSq7cxPSzqbg1jR=YkSjR5oyKLASjjA6q5ttCuqeFuRc+pyg@mail.gmail.com>
 <CAP1=2W6RxTv+A5epYz8s8XCWTPTuPbJW+EE=BJ=GF-3PRO2NpA@mail.gmail.com>
Message-ID: <CADiSq7caQivvyjQbDip9Nu9Q6YHYWAq9P5eeAkt773HDdVKqsA@mail.gmail.com>

On 8 August 2015 at 08:25, Brett Cannon <bcannon at gmail.com> wrote:
> On Thu, Aug 6, 2015 at 7:17 PM Nick Coghlan <ncoghlan at gmail.com> wrote:
>> In the Roundup+Mercurial case, I think we can deal with this more
>> comprehensively by actually storing our canonical issue->commit
>> reference in *Roundup*, and mentioning an issue number in a commit
>> would just be a way of creating those associations automatically. That
>> way, if we get it wrong at commit time (mentioning the wrong issue,
>> not mentioning an issue at all, creating an issue after we've already
>> done the work), then we can edit the commit associations on the
>> affected issues *in Roundup* to ensure the appropriate change info is
>> reported. If multiple commits were made referencing the same issue,
>> then we'd still only get one news entry for that issue, and if one
>> commit addresses multiple issues, then we'd get multiple news entries
>> (one per issue).
>
> So are you saying you want a field to paste in the commit numbers to do the
> tracking? I assume you would want commit messages listing an issue to
> automatically append to that field but have it editable to fix any typos in
> the commit message.

Yep, exactly. Longer term, once we have a repo hosting solution that
*also* has a REST API, then the UX could be updated to better
integrate the two (e.g. displaying the summary line from the commit in
the Roundup UI, display the titles of all linked issues in the repo
hosting UI), but the simplest possible way to get started is with a
free text comma separated field (akin to the nosy list, dependency and
superceder fields) that we can audit with an offline script and set
from the existing Roundup notification commit hook.

>> Since Mercurial associates commits with named branches, this would
>> also mean we'd be able to use the issue->commit tracking to determine
>> where a change had been applied, rather than the existing versions
>> field, so we'd be free to keep using the latter to keep track of
>> branches that still require updating.
>
> Yes, and depending on how fancy we got, we could even decorate the Versions
> field with some marker to show when a commit had been applied to a branch.

I was more thinking in terms of listing the branches against the
displayed commits, but yeah, marking up the versions field might be a
nice way to go, too.

In my "Can I have a pony?" moments, I start wondering how we might be
able to work https://taiga.io/ into the mix to help coordinate more
complex activities (like the release process, or some of our
infrastructure updates). Fedora now have an instance of that up at
http://taiga.cloud.fedoraproject.org/ (that instance requires a Fedora
account to log in, but those are freely available:
https://admin.fedoraproject.org/accounts/user/new).

Baby steps, though, baby steps... :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From pierre-yves.david at ens-lyon.org  Sat Aug  8 07:25:44 2015
From: pierre-yves.david at ens-lyon.org (Pierre-Yves David)
Date: Fri, 07 Aug 2015 22:25:44 -0700
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
Message-ID: <55C592D8.3080203@ens-lyon.org>



On 08/05/2015 10:30 PM, Brett Cannon wrote:
> If we ever want to have a nice workflow where we can automate as much as
> possible, we need to figure out a way deal with our most common merge
> conflict: Misc/NEWS. Thanks to shifts in the format between different
> minor versions the file is pretty much guaranteed to have a conflict
> when doing a merge up a version.
>
> So how do we solve this? I can remember 3 possible solutions that have
> been proposed previously:
>
>  1. A single file per entry
>  2. A single file per release version of Python
>  3. Automating it based on commit messages
>
> I personally prefer #3 as I hate repeating myself since I just copy and
> paste the first line(s) of my commits to Misc/NEWS as it is anyway
> (basically up to the first pair of newlines). We would need a way to
> signal that the commit message contains nothing useful for the
> to-be-generated NEWS file when it's simply a fix for a previous commit
> (probably some marker that is somewhat inconspicuous like a dash on its
> own line or something). In terms of the section of the NEWS file that a
> commit belongs, that can once again be a marker or honestly something we
> drop or infer based on what files were edited in the commit.

(I'm a bit late to the party here, sorry).

You have another solution (5) having a dedicated merge script for 
misc/NEWS that knows how to parse the format and generate a good merge. 
It should not be too complicated to achieve. I've successfully used such 
script for similarish file in the past.

The main issue of (3) is that you will make mistake. Either wrong commit 
message or change flagged as News worthy but later backed out or changed 
so much than the initial message is irrelevant.

(Mercurial will have not problem editing commit message as long as they 
did not made it to the main public repo, however be sure that you will 
let mistake slip through).

-- 
Pierre-Yves David

From ezio.melotti at gmail.com  Sat Aug  8 14:05:02 2015
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Sat, 8 Aug 2015 15:05:02 +0300
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <55C592D8.3080203@ens-lyon.org>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C592D8.3080203@ens-lyon.org>
Message-ID: <CACBhJdGHYi9doZWhy=iDCKRasLVsfAL495iw0n3SWfMZaFjWgA@mail.gmail.com>

On Sat, Aug 8, 2015 at 8:25 AM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
>
> On 08/05/2015 10:30 PM, Brett Cannon wrote:
>>
>> If we ever want to have a nice workflow where we can automate as much as
>> possible, we need to figure out a way deal with our most common merge
>> conflict: Misc/NEWS. Thanks to shifts in the format between different
>> minor versions the file is pretty much guaranteed to have a conflict
>> when doing a merge up a version.
>>
>> So how do we solve this? I can remember 3 possible solutions that have
>> been proposed previously:
>>
>>  1. A single file per entry
>>  2. A single file per release version of Python
>>  3. Automating it based on commit messages
>>
>> I personally prefer #3 as I hate repeating myself since I just copy and
>> paste the first line(s) of my commits to Misc/NEWS as it is anyway
>> (basically up to the first pair of newlines). We would need a way to
>> signal that the commit message contains nothing useful for the
>> to-be-generated NEWS file when it's simply a fix for a previous commit
>> (probably some marker that is somewhat inconspicuous like a dash on its
>> own line or something). In terms of the section of the NEWS file that a
>> commit belongs, that can once again be a marker or honestly something we
>> drop or infer based on what files were edited in the commit.
>
>
> (I'm a bit late to the party here, sorry).
>
> You have another solution (5) having a dedicated merge script for misc/NEWS
> that knows how to parse the format and generate a good merge. It should not
> be too complicated to achieve. I've successfully used such script for
> similarish file in the past.
>

A merge script is already attached to the aforementioned issue: see
http://bugs.python.org/issue18967#msg217079 and
http://bugs.python.org/file35032/newsmerge.py
I think you were the one who convinced and helped me implementing it :)

Best Regards,
Ezio Melotti

> The main issue of (3) is that you will make mistake. Either wrong commit
> message or change flagged as News worthy but later backed out or changed so
> much than the initial message is irrelevant.
>
> (Mercurial will have not problem editing commit message as long as they did
> not made it to the main public repo, however be sure that you will let
> mistake slip through).
>
> --
> Pierre-Yves David
>

From ncoghlan at gmail.com  Sat Aug  8 16:40:23 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 9 Aug 2015 00:40:23 +1000
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <CACBhJdGHYi9doZWhy=iDCKRasLVsfAL495iw0n3SWfMZaFjWgA@mail.gmail.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C592D8.3080203@ens-lyon.org>
 <CACBhJdGHYi9doZWhy=iDCKRasLVsfAL495iw0n3SWfMZaFjWgA@mail.gmail.com>
Message-ID: <CADiSq7f3naibh-ksvYaTSKhV5+Ojr6Y0Uymizvc_c=EhWm9OjA@mail.gmail.com>

On 8 August 2015 at 22:05, Ezio Melotti <ezio.melotti at gmail.com> wrote:
> On Sat, Aug 8, 2015 at 8:25 AM, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org> wrote:
>> You have another solution (5) having a dedicated merge script for misc/NEWS
>> that knows how to parse the format and generate a good merge. It should not
>> be too complicated to achieve. I've successfully used such script for
>> similarish file in the past.
>
> A merge script is already attached to the aforementioned issue: see
> http://bugs.python.org/issue18967#msg217079 and
> http://bugs.python.org/file35032/newsmerge.py
> I think you were the one who convinced and helped me implementing it :)

Right, the merge script would be a good option if we were otherwise
happy with the checked-in NEWS file as the data entry format for user
facing messages. We aren't particularly happy with that though, so it
makes sense to tackle the larger problem. That said, the merge script
might still be a good tactical solution in the interim to alleviate
some of the current irritations in merging forward bug fixes.

In relation to the bugs.python.org based approach, it occurs to me
that we could move patch contributor acknowledgements for merged
patches there as well, so they can be more readily queried
programmatically than they are today.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From bcannon at gmail.com  Sat Aug  8 19:36:25 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Sat, 08 Aug 2015 17:36:25 +0000
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <CADiSq7f3naibh-ksvYaTSKhV5+Ojr6Y0Uymizvc_c=EhWm9OjA@mail.gmail.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C592D8.3080203@ens-lyon.org>
 <CACBhJdGHYi9doZWhy=iDCKRasLVsfAL495iw0n3SWfMZaFjWgA@mail.gmail.com>
 <CADiSq7f3naibh-ksvYaTSKhV5+Ojr6Y0Uymizvc_c=EhWm9OjA@mail.gmail.com>
Message-ID: <CAP1=2W65wEDDBSy_k39VA-UDFi+kpO3SGg_0Wmhkg=NNANO7DQ@mail.gmail.com>

On Sat, Aug 8, 2015, 07:40 Nick Coghlan <ncoghlan at gmail.com> wrote:

On 8 August 2015 at 22:05, Ezio Melotti <ezio.melotti at gmail.com> wrote:
> On Sat, Aug 8, 2015 at 8:25 AM, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org> wrote:
>> You have another solution (5) having a dedicated merge script for
misc/NEWS
>> that knows how to parse the format and generate a good merge. It should
not
>> be too complicated to achieve. I've successfully used such script for
>> similarish file in the past.
>
> A merge script is already attached to the aforementioned issue: see
> http://bugs.python.org/issue18967#msg217079 and
> http://bugs.python.org/file35032/newsmerge.py
> I think you were the one who convinced and helped me implementing it :)

Right, the merge script would be a good option if we were otherwise
happy with the checked-in NEWS file as the data entry format for user
facing messages. We aren't particularly happy with that though, so it
makes sense to tackle the larger problem. That said, the merge script
might still be a good tactical solution in the interim to alleviate
some of the current irritations in merging forward bug fixes.

In relation to the bugs.python.org based approach, it occurs to me
that we could move patch contributor acknowledgements for merged
patches there as well, so they can be more readily queried
programmatically than they are today.

One thing at a time, but yes. Once we have push button merges we can easily
record who contributed the patch to make sure ACKS is always up-to-date.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150808/4de19409/attachment.html>

From bcannon at gmail.com  Sat Aug  8 19:44:04 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Sat, 08 Aug 2015 17:44:04 +0000
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <CADiSq7caQivvyjQbDip9Nu9Q6YHYWAq9P5eeAkt773HDdVKqsA@mail.gmail.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C33014.40708@egenix.com>
 <CADiSq7fNikAsUWZy6vMykbnzvin6KCEPqyto6fzohwJdZJ9FKg@mail.gmail.com>
 <CAP1=2W7mo=XEEKccPyjcj6GdBc1n1DHQkUS1ryufL3EQgZnRow@mail.gmail.com>
 <20150806194604.D704D250FDE@webabinitio.net>
 <CADiSq7cxPSzqbg1jR=YkSjR5oyKLASjjA6q5ttCuqeFuRc+pyg@mail.gmail.com>
 <CAP1=2W6RxTv+A5epYz8s8XCWTPTuPbJW+EE=BJ=GF-3PRO2NpA@mail.gmail.com>
 <CADiSq7caQivvyjQbDip9Nu9Q6YHYWAq9P5eeAkt773HDdVKqsA@mail.gmail.com>
Message-ID: <CAP1=2W7ZwXogBwS5iTuP3r=TFgGGqynq--=Y5gguyPkPzrh47w@mail.gmail.com>

On Fri, Aug 7, 2015, 20:13 Nick Coghlan <ncoghlan at gmail.com> wrote:

On 8 August 2015 at 08:25, Brett Cannon <bcannon at gmail.com> wrote:
> On Thu, Aug 6, 2015 at 7:17 PM Nick Coghlan <ncoghlan at gmail.com> wrote:
>> In the Roundup+Mercurial case, I think we can deal with this more
>> comprehensively by actually storing our canonical issue->commit
>> reference in *Roundup*, and mentioning an issue number in a commit
>> would just be a way of creating those associations automatically. That
>> way, if we get it wrong at commit time (mentioning the wrong issue,
>> not mentioning an issue at all, creating an issue after we've already
>> done the work), then we can edit the commit associations on the
>> affected issues *in Roundup* to ensure the appropriate change info is
>> reported. If multiple commits were made referencing the same issue,
>> then we'd still only get one news entry for that issue, and if one
>> commit addresses multiple issues, then we'd get multiple news entries
>> (one per issue).
>
> So are you saying you want a field to paste in the commit numbers to do
the
> tracking? I assume you would want commit messages listing an issue to
> automatically append to that field but have it editable to fix any typos
in
> the commit message.

Yep, exactly. Longer term, once we have a repo hosting solution that
*also* has a REST API, then the UX could be updated to better
integrate the two (e.g. displaying the summary line from the commit in
the Roundup UI, display the titles of all linked issues in the repo
hosting UI), but the simplest possible way to get started is with a
free text comma separated field (akin to the nosy list, dependency and
superceder fields) that we can audit with an offline script and set
from the existing Roundup notification commit hook.


OK, assuming David's in agreement then I think this approach wins with the
comma-separated field for commits that the hg hook for Roundup auto-appends
to and of course the field to enter the NEWS entry.

Now the next question is how easy/hard is it to implement this, how long
will it take, and who is willing to do the work? With this in hand we can
propose it to python-committers for 3.6 since the NEWS file should be easy
enough to back-fill to this approach while its still small.

-Brett

>> Since Mercurial associates commits with named branches, this would
>> also mean we'd be able to use the issue->commit tracking to determine
>> where a change had been applied, rather than the existing versions
>> field, so we'd be free to keep using the latter to keep track of
>> branches that still require updating.
>
> Yes, and depending on how fancy we got, we could even decorate the
Versions
> field with some marker to show when a commit had been applied to a branch.

I was more thinking in terms of listing the branches against the
displayed commits, but yeah, marking up the versions field might be a
nice way to go, too.

In my "Can I have a pony?" moments, I start wondering how we might be
able to work https://taiga.io/ into the mix to help coordinate more
complex activities (like the release process, or some of our
infrastructure updates). Fedora now have an instance of that up at
http://taiga.cloud.fedoraproject.org/ (that instance requires a Fedora
account to log in, but those are freely available:
https://admin.fedoraproject.org/accounts/user/new).

Baby steps, though, baby steps... :)

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150808/ffe5dba1/attachment-0001.html>

From rdmurray at bitdance.com  Sat Aug  8 22:17:55 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 08 Aug 2015 16:17:55 -0400
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <CAP1=2W7ZwXogBwS5iTuP3r=TFgGGqynq--=Y5gguyPkPzrh47w@mail.gmail.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C33014.40708@egenix.com>
 <CADiSq7fNikAsUWZy6vMykbnzvin6KCEPqyto6fzohwJdZJ9FKg@mail.gmail.com>
 <CAP1=2W7mo=XEEKccPyjcj6GdBc1n1DHQkUS1ryufL3EQgZnRow@mail.gmail.com>
 <20150806194604.D704D250FDE@webabinitio.net>
 <CADiSq7cxPSzqbg1jR=YkSjR5oyKLASjjA6q5ttCuqeFuRc+pyg@mail.gmail.com>
 <CAP1=2W6RxTv+A5epYz8s8XCWTPTuPbJW+EE=BJ=GF-3PRO2NpA@mail.gmail.com>
 <CADiSq7caQivvyjQbDip9Nu9Q6YHYWAq9P5eeAkt773HDdVKqsA@mail.gmail.com>
 <CAP1=2W7ZwXogBwS5iTuP3r=TFgGGqynq--=Y5gguyPkPzrh47w@mail.gmail.com>
Message-ID: <20150808201755.8198A250FB5@webabinitio.net>

On Sat, 08 Aug 2015 17:44:04 -0000, Brett Cannon <bcannon at gmail.com> wrote:
> OK, assuming David's in agreement then I think this approach wins with the
> comma-separated field for commits that the hg hook for Roundup auto-appends
> to and of course the field to enter the NEWS entry.
> 
> Now the next question is how easy/hard is it to implement this, how long
> will it take, and who is willing to do the work? With this in hand we can
> propose it to python-committers for 3.6 since the NEWS file should be easy
> enough to back-fill to this approach while its still small.

Yes I agree this is the best approach, assuming we can get it
implemented.  The advantage of #4, though, is that Ezio already did the
work.

I'm *willing* to do the roundup work, but I don't know as I have the
required time, at least for the next month.  Part of the trick is the
need to get a test instance set up...there was work done at PyCon and
after at making a tracker-in-a-box, so I'd need to find out where that
was at and learn how to use it (or finish it, if needed).  The code
itself is probably a half-day job, probably including enhancing the hook
to update the commits field.  But together with getting a working test
instance we're talking a couple days work at least.

Writing the NEWS generating script is a not exactly trivial job, but
probably wants to wait until we have the REST API.  So we'd have
upgrading our Roundup to that when it lands on the list as well, with a
3.6 Beta 1 deadline on getting it all done.

--David

From bcannon at gmail.com  Sat Aug  8 23:25:44 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Sat, 08 Aug 2015 21:25:44 +0000
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <20150808201755.8198A250FB5@webabinitio.net>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C33014.40708@egenix.com>
 <CADiSq7fNikAsUWZy6vMykbnzvin6KCEPqyto6fzohwJdZJ9FKg@mail.gmail.com>
 <CAP1=2W7mo=XEEKccPyjcj6GdBc1n1DHQkUS1ryufL3EQgZnRow@mail.gmail.com>
 <20150806194604.D704D250FDE@webabinitio.net>
 <CADiSq7cxPSzqbg1jR=YkSjR5oyKLASjjA6q5ttCuqeFuRc+pyg@mail.gmail.com>
 <CAP1=2W6RxTv+A5epYz8s8XCWTPTuPbJW+EE=BJ=GF-3PRO2NpA@mail.gmail.com>
 <CADiSq7caQivvyjQbDip9Nu9Q6YHYWAq9P5eeAkt773HDdVKqsA@mail.gmail.com>
 <CAP1=2W7ZwXogBwS5iTuP3r=TFgGGqynq--=Y5gguyPkPzrh47w@mail.gmail.com>
 <20150808201755.8198A250FB5@webabinitio.net>
Message-ID: <CAP1=2W7ERNLQvDgv-hwaYNvmpQVW0AzoPHxiVMMz6K1swNTA4w@mail.gmail.com>

On Sat, Aug 8, 2015 at 1:18 PM R. David Murray <rdmurray at bitdance.com>
wrote:

> On Sat, 08 Aug 2015 17:44:04 -0000, Brett Cannon <bcannon at gmail.com>
> wrote:
> > OK, assuming David's in agreement then I think this approach wins with
> the
> > comma-separated field for commits that the hg hook for Roundup
> auto-appends
> > to and of course the field to enter the NEWS entry.
> >
> > Now the next question is how easy/hard is it to implement this, how long
> > will it take, and who is willing to do the work? With this in hand we can
> > propose it to python-committers for 3.6 since the NEWS file should be
> easy
> > enough to back-fill to this approach while its still small.
>
> Yes I agree this is the best approach, assuming we can get it
> implemented.  The advantage of #4, though, is that Ezio already did the
> work.
>
> I'm *willing* to do the roundup work, but I don't know as I have the
> required time, at least for the next month.  Part of the trick is the
> need to get a test instance set up...there was work done at PyCon and
> after at making a tracker-in-a-box, so I'd need to find out where that
> was at and learn how to use it (or finish it, if needed).  The code
> itself is probably a half-day job, probably including enhancing the hook
> to update the commits field.  But together with getting a working test
> instance we're talking a couple days work at least.
>

Perk of getting the tracker-in-a-box working is it's a one-time cost that
will be beneficial long term.

I also don't think there is a rush since we still have to convince
python-committers that this is the right solution. I plan to propose it on
Monday to the list to make sure we have buy-in.


> Writing the NEWS generating script is a not exactly trivial job, but
> probably wants to wait until we have the REST API.  So we'd have
> upgrading our Roundup to that when it lands on the list as well, with a
> 3.6 Beta 1 deadline on getting it all done.
>

Yeah, so we have a bit of time to worry about the generation script.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150808/2d81e433/attachment.html>

From bcannon at gmail.com  Tue Aug 11 00:39:03 2015
From: bcannon at gmail.com (Brett Cannon)
Date: Mon, 10 Aug 2015 22:39:03 +0000
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <CAP1=2W7ERNLQvDgv-hwaYNvmpQVW0AzoPHxiVMMz6K1swNTA4w@mail.gmail.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C33014.40708@egenix.com>
 <CADiSq7fNikAsUWZy6vMykbnzvin6KCEPqyto6fzohwJdZJ9FKg@mail.gmail.com>
 <CAP1=2W7mo=XEEKccPyjcj6GdBc1n1DHQkUS1ryufL3EQgZnRow@mail.gmail.com>
 <20150806194604.D704D250FDE@webabinitio.net>
 <CADiSq7cxPSzqbg1jR=YkSjR5oyKLASjjA6q5ttCuqeFuRc+pyg@mail.gmail.com>
 <CAP1=2W6RxTv+A5epYz8s8XCWTPTuPbJW+EE=BJ=GF-3PRO2NpA@mail.gmail.com>
 <CADiSq7caQivvyjQbDip9Nu9Q6YHYWAq9P5eeAkt773HDdVKqsA@mail.gmail.com>
 <CAP1=2W7ZwXogBwS5iTuP3r=TFgGGqynq--=Y5gguyPkPzrh47w@mail.gmail.com>
 <20150808201755.8198A250FB5@webabinitio.net>
 <CAP1=2W7ERNLQvDgv-hwaYNvmpQVW0AzoPHxiVMMz6K1swNTA4w@mail.gmail.com>
Message-ID: <CAP1=2W5Ua29087HU69Gfa=2nubD8t-cmcoE05c=+0bZUzPFgDQ@mail.gmail.com>

I have told python-committers of our plan to make sure it won't lead to a
revolt.

On Sat, 8 Aug 2015 at 14:25 Brett Cannon <bcannon at gmail.com> wrote:

> On Sat, Aug 8, 2015 at 1:18 PM R. David Murray <rdmurray at bitdance.com>
> wrote:
>
>> On Sat, 08 Aug 2015 17:44:04 -0000, Brett Cannon <bcannon at gmail.com>
>> wrote:
>> > OK, assuming David's in agreement then I think this approach wins with
>> the
>> > comma-separated field for commits that the hg hook for Roundup
>> auto-appends
>> > to and of course the field to enter the NEWS entry.
>> >
>> > Now the next question is how easy/hard is it to implement this, how long
>> > will it take, and who is willing to do the work? With this in hand we
>> can
>> > propose it to python-committers for 3.6 since the NEWS file should be
>> easy
>> > enough to back-fill to this approach while its still small.
>>
>> Yes I agree this is the best approach, assuming we can get it
>> implemented.  The advantage of #4, though, is that Ezio already did the
>> work.
>>
>> I'm *willing* to do the roundup work, but I don't know as I have the
>> required time, at least for the next month.  Part of the trick is the
>> need to get a test instance set up...there was work done at PyCon and
>> after at making a tracker-in-a-box, so I'd need to find out where that
>> was at and learn how to use it (or finish it, if needed).  The code
>> itself is probably a half-day job, probably including enhancing the hook
>> to update the commits field.  But together with getting a working test
>> instance we're talking a couple days work at least.
>>
>
> Perk of getting the tracker-in-a-box working is it's a one-time cost that
> will be beneficial long term.
>
> I also don't think there is a rush since we still have to convince
> python-committers that this is the right solution. I plan to propose it on
> Monday to the list to make sure we have buy-in.
>
>
>> Writing the NEWS generating script is a not exactly trivial job, but
>> probably wants to wait until we have the REST API.  So we'd have
>> upgrading our Roundup to that when it lands on the list as well, with a
>> 3.6 Beta 1 deadline on getting it all done.
>>
>
> Yeah, so we have a bit of time to worry about the generation script.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150810/7753db1c/attachment.html>

From ezio.melotti at gmail.com  Tue Aug 11 06:12:38 2015
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Tue, 11 Aug 2015 07:12:38 +0300
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <CAP1=2W7ERNLQvDgv-hwaYNvmpQVW0AzoPHxiVMMz6K1swNTA4w@mail.gmail.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C33014.40708@egenix.com>
 <CADiSq7fNikAsUWZy6vMykbnzvin6KCEPqyto6fzohwJdZJ9FKg@mail.gmail.com>
 <CAP1=2W7mo=XEEKccPyjcj6GdBc1n1DHQkUS1ryufL3EQgZnRow@mail.gmail.com>
 <20150806194604.D704D250FDE@webabinitio.net>
 <CADiSq7cxPSzqbg1jR=YkSjR5oyKLASjjA6q5ttCuqeFuRc+pyg@mail.gmail.com>
 <CAP1=2W6RxTv+A5epYz8s8XCWTPTuPbJW+EE=BJ=GF-3PRO2NpA@mail.gmail.com>
 <CADiSq7caQivvyjQbDip9Nu9Q6YHYWAq9P5eeAkt773HDdVKqsA@mail.gmail.com>
 <CAP1=2W7ZwXogBwS5iTuP3r=TFgGGqynq--=Y5gguyPkPzrh47w@mail.gmail.com>
 <20150808201755.8198A250FB5@webabinitio.net>
 <CAP1=2W7ERNLQvDgv-hwaYNvmpQVW0AzoPHxiVMMz6K1swNTA4w@mail.gmail.com>
Message-ID: <CACBhJdHzgLeUeZZFQZwwDAg-sL8tHk5_3QxkPPOAkuThFU4BSQ@mail.gmail.com>

On Sun, Aug 9, 2015 at 12:25 AM, Brett Cannon <bcannon at gmail.com> wrote:
>
>
> On Sat, Aug 8, 2015 at 1:18 PM R. David Murray <rdmurray at bitdance.com>
> wrote:
>>
>> On Sat, 08 Aug 2015 17:44:04 -0000, Brett Cannon <bcannon at gmail.com>
>> wrote:
>> > OK, assuming David's in agreement then I think this approach wins with
>> > the
>> > comma-separated field for commits that the hg hook for Roundup
>> > auto-appends
>> > to and of course the field to enter the NEWS entry.
>> >
>> > Now the next question is how easy/hard is it to implement this, how long
>> > will it take, and who is willing to do the work? With this in hand we
>> > can
>> > propose it to python-committers for 3.6 since the NEWS file should be
>> > easy
>> > enough to back-fill to this approach while its still small.
>>
>> Yes I agree this is the best approach, assuming we can get it
>> implemented.  The advantage of #4, though, is that Ezio already did the
>> work.
>>
>> I'm *willing* to do the roundup work, but I don't know as I have the
>> required time, at least for the next month.  Part of the trick is the
>> need to get a test instance set up...there was work done at PyCon and
>> after at making a tracker-in-a-box, so I'd need to find out where that
>> was at and learn how to use it (or finish it, if needed).  The code
>> itself is probably a half-day job, probably including enhancing the hook
>> to update the commits field.  But together with getting a working test
>> instance we're talking a couple days work at least.
>
>
> Perk of getting the tracker-in-a-box working is it's a one-time cost that
> will be beneficial long term.
>

FYI Shiyao (one of the GSoC students) has been working on
https://bitbucket.org/introom/docker-b.p.o/src .

Best Regards,
Ezio Melotti


> I also don't think there is a rush since we still have to convince
> python-committers that this is the right solution. I plan to propose it on
> Monday to the list to make sure we have buy-in.
>
>>
>> Writing the NEWS generating script is a not exactly trivial job, but
>> probably wants to wait until we have the REST API.  So we'd have
>> upgrading our Roundup to that when it lands on the list as well, with a
>> 3.6 Beta 1 deadline on getting it all done.
>
>
> Yeah, so we have a bit of time to worry about the generation script.
>

From rdmurray at bitdance.com  Tue Aug 11 15:34:04 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 11 Aug 2015 09:34:04 -0400
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <CACBhJdHzgLeUeZZFQZwwDAg-sL8tHk5_3QxkPPOAkuThFU4BSQ@mail.gmail.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C33014.40708@egenix.com>
 <CADiSq7fNikAsUWZy6vMykbnzvin6KCEPqyto6fzohwJdZJ9FKg@mail.gmail.com>
 <CAP1=2W7mo=XEEKccPyjcj6GdBc1n1DHQkUS1ryufL3EQgZnRow@mail.gmail.com>
 <20150806194604.D704D250FDE@webabinitio.net>
 <CADiSq7cxPSzqbg1jR=YkSjR5oyKLASjjA6q5ttCuqeFuRc+pyg@mail.gmail.com>
 <CAP1=2W6RxTv+A5epYz8s8XCWTPTuPbJW+EE=BJ=GF-3PRO2NpA@mail.gmail.com>
 <CADiSq7caQivvyjQbDip9Nu9Q6YHYWAq9P5eeAkt773HDdVKqsA@mail.gmail.com>
 <CAP1=2W7ZwXogBwS5iTuP3r=TFgGGqynq--=Y5gguyPkPzrh47w@mail.gmail.com>
 <20150808201755.8198A250FB5@webabinitio.net>
 <CAP1=2W7ERNLQvDgv-hwaYNvmpQVW0AzoPHxiVMMz6K1swNTA4w@mail.gmail.com>
 <CACBhJdHzgLeUeZZFQZwwDAg-sL8tHk5_3QxkPPOAkuThFU4BSQ@mail.gmail.com>
Message-ID: <20150811133405.83960250FF9@webabinitio.net>

On Tue, 11 Aug 2015 07:12:38 +0300, Ezio Melotti <ezio.melotti at gmail.com> wrote:
> On Sun, Aug 9, 2015 at 12:25 AM, Brett Cannon <bcannon at gmail.com> wrote:
> >
> >
> > On Sat, Aug 8, 2015 at 1:18 PM R. David Murray <rdmurray at bitdance.com>
> > wrote:
> >>
> >> On Sat, 08 Aug 2015 17:44:04 -0000, Brett Cannon <bcannon at gmail.com>
> >> wrote:
> >> > OK, assuming David's in agreement then I think this approach wins with
> >> > the
> >> > comma-separated field for commits that the hg hook for Roundup
> >> > auto-appends
> >> > to and of course the field to enter the NEWS entry.
> >> >
> >> > Now the next question is how easy/hard is it to implement this, how long
> >> > will it take, and who is willing to do the work? With this in hand we
> >> > can
> >> > propose it to python-committers for 3.6 since the NEWS file should be
> >> > easy
> >> > enough to back-fill to this approach while its still small.
> >>
> >> Yes I agree this is the best approach, assuming we can get it
> >> implemented.  The advantage of #4, though, is that Ezio already did the
> >> work.
> >>
> >> I'm *willing* to do the roundup work, but I don't know as I have the
> >> required time, at least for the next month.  Part of the trick is the
> >> need to get a test instance set up...there was work done at PyCon and
> >> after at making a tracker-in-a-box, so I'd need to find out where that
> >> was at and learn how to use it (or finish it, if needed).  The code
> >> itself is probably a half-day job, probably including enhancing the hook
> >> to update the commits field.  But together with getting a working test
> >> instance we're talking a couple days work at least.
> >
> >
> > Perk of getting the tracker-in-a-box working is it's a one-time cost that
> > will be beneficial long term.

Yes.  I just have to find time to get over that initial hump :)

> FYI Shiyao (one of the GSoC students) has been working on
> https://bitbucket.org/introom/docker-b.p.o/src .

And this will help, I hope!

--David

From i at introo.me  Tue Aug 11 16:36:22 2015
From: i at introo.me (Shiyao Ma)
Date: Tue, 11 Aug 2015 22:36:22 +0800
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <20150811133405.83960250FF9@webabinitio.net>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C33014.40708@egenix.com>
 <CADiSq7fNikAsUWZy6vMykbnzvin6KCEPqyto6fzohwJdZJ9FKg@mail.gmail.com>
 <CAP1=2W7mo=XEEKccPyjcj6GdBc1n1DHQkUS1ryufL3EQgZnRow@mail.gmail.com>
 <20150806194604.D704D250FDE@webabinitio.net>
 <CADiSq7cxPSzqbg1jR=YkSjR5oyKLASjjA6q5ttCuqeFuRc+pyg@mail.gmail.com>
 <CAP1=2W6RxTv+A5epYz8s8XCWTPTuPbJW+EE=BJ=GF-3PRO2NpA@mail.gmail.com>
 <CADiSq7caQivvyjQbDip9Nu9Q6YHYWAq9P5eeAkt773HDdVKqsA@mail.gmail.com>
 <CAP1=2W7ZwXogBwS5iTuP3r=TFgGGqynq--=Y5gguyPkPzrh47w@mail.gmail.com>
 <20150808201755.8198A250FB5@webabinitio.net>
 <CAP1=2W7ERNLQvDgv-hwaYNvmpQVW0AzoPHxiVMMz6K1swNTA4w@mail.gmail.com>
 <CACBhJdHzgLeUeZZFQZwwDAg-sL8tHk5_3QxkPPOAkuThFU4BSQ@mail.gmail.com>
 <20150811133405.83960250FF9@webabinitio.net>
Message-ID: <CAJQX3DypdrUXTtQ8g2wA3yWGZXOaG0XyfkLsC7rTPMqkFBF8=Q@mail.gmail.com>

Hi,

>
> Yes.  I just have to find time to get over that initial hump :)
>
> > FYI Shiyao (one of the GSoC students) has been working on
> > https://bitbucket.org/introom/docker-b.p.o/src .
>
> And this will help, I hope!

Let me see if I can do anything to help on this.

Take care that the oic package introduces some  troublesome package
and the roundup will not work.

Regards.



-- 

????????????????https://introo.me?

From willingc at willingconsulting.com  Tue Aug 11 16:44:48 2015
From: willingc at willingconsulting.com (Carol Willing)
Date: Tue, 11 Aug 2015 07:44:48 -0700
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <CAJQX3DypdrUXTtQ8g2wA3yWGZXOaG0XyfkLsC7rTPMqkFBF8=Q@mail.gmail.com>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C33014.40708@egenix.com>
 <CADiSq7fNikAsUWZy6vMykbnzvin6KCEPqyto6fzohwJdZJ9FKg@mail.gmail.com>
 <CAP1=2W7mo=XEEKccPyjcj6GdBc1n1DHQkUS1ryufL3EQgZnRow@mail.gmail.com>
 <20150806194604.D704D250FDE@webabinitio.net>
 <CADiSq7cxPSzqbg1jR=YkSjR5oyKLASjjA6q5ttCuqeFuRc+pyg@mail.gmail.com>
 <CAP1=2W6RxTv+A5epYz8s8XCWTPTuPbJW+EE=BJ=GF-3PRO2NpA@mail.gmail.com>
 <CADiSq7caQivvyjQbDip9Nu9Q6YHYWAq9P5eeAkt773HDdVKqsA@mail.gmail.com>
 <CAP1=2W7ZwXogBwS5iTuP3r=TFgGGqynq--=Y5gguyPkPzrh47w@mail.gmail.com>
 <20150808201755.8198A250FB5@webabinitio.net>
 <CAP1=2W7ERNLQvDgv-hwaYNvmpQVW0AzoPHxiVMMz6K1swNTA4w@mail.gmail.com>
 <CACBhJdHzgLeUeZZFQZwwDAg-sL8tHk5_3QxkPPOAkuThFU4BSQ@mail.gmail.com>
 <20150811133405.83960250FF9@webabinitio.net>
 <CAJQX3DypdrUXTtQ8g2wA3yWGZXOaG0XyfkLsC7rTPMqkFBF8=Q@mail.gmail.com>
Message-ID: <55CA0A60.6090808@willingconsulting.com>



On 8/11/15 7:36 AM, Shiyao Ma wrote:
> Hi,
>
>> Yes.  I just have to find time to get over that initial hump :)
>>
>>> FYI Shiyao (one of the GSoC students) has been working on
>>> https://bitbucket.org/introom/docker-b.p.o/src .
>> And this will help, I hope!
> Let me see if I can do anything to help on this.
>
> Take care that the oic package introduces some  troublesome package
> and the roundup will not work.
>
> Regards.
>
Shiyao, Keep up the good work for the home stretch of GSoC. I would be 
interested in reading your end of project report.

Ezio, Thanks for mentoring GSoC. I'm also mentoring a student for 
another organization. Please let me know if you need any help with docs 
of these projects after GSoC wraps up.

Warmly,
Carol