[core-workflow] GSoC idea: bug.python.org improvements

[Nick Coghlan]

On 26 March 2015 at 19:05, Ezio Melotti <ezio.melotti at gmail.com> wrote:
> This is actually something that I wanted to bring up on python-dev.
> Currently our workflow is mostly patch-based, but adding support for
> pull requests from BitBucket/GitHub is one of the things that we are
> considering adding during GSoC.  In addition, the GSoC students will
> work on a separate clone of the tracker, likely hosted on BitBucket.
> While we could still use the patch-based approach for GSoC, this would
> be a good chance to experiment with a more modern approach and also
> test on the meta-tracker both the new workflow and the code that will
> enable it.  If successful, the same approach can also be adopted for
> CPython.

I managed to forget about the idea of allowing roundup patch
generation direct from GitHub/BitBucket, so in that case it definitely
makes sense to pursue some of this for the current bugs.python.org
workflow. It especially makes sense as both forge.python.org proposal
target the support repos first (devguide, peps, etc), so regardless of
which of those moves forward, it's going to be a long time before it
impacts the CPython workflows. By contrast, improvements to Roundup's
integration with other services can start being helpful as soon as
they get deployed.

> One of the main issues is, as you mentioned, how to track both the
> committer and the author.  This is both a technical and a
> "philosophical" issue -- that's why I wanted to bring it up on
> python-dev.

I think there's plenty of precedent from the Git/Gerrit world here,
but agree there should be a discussion to check for any disagreement
with us following that precedent.

> Another issue is establishing a policy regarding branches and rebases
> (rebasements?).

In terms of actually *make* changes, I think we'd still want changes
to effectively involve apply patches until we're able to adopt a more
capable repo hosting service with integrated review management.

> These issues might eventually be solved by Kallithea/Phabricator, but
> I expect a transition period where different workflows will be used. I
> would like our repo to be still intact by the time we settle on the
> new workflow.

Agreed.

> IIUC hgcommitter adds extra metadata to the changeset, and if we go
> down this route we might also consider adding metadata for the issue
> number and tweak hgweb to display both.

The other possible direction to go is the direction Gerrit and the
Linux kernel go, which is to just have a footer on commit messages for
relevant key:value data fields, rather than using VCS metadata. This
has the benefit of being easy to port to new VCS's later, since
"committer & commit message" is setting the "what metadata does the
VCS track?" quite low.

So your commit message might look like:

    Apples are no longer counted as oranges

    Apples were being counted as oranges in some cases. They're now
always counted as apples.

    Issue: 12345
    Contributed-by: Pat Chauthor <pat at chauthor.invalid>

Cheers,
Nick.

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