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

[Ezio Melotti]

On Thu, Mar 26, 2015 at 9:10 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 22 March 2015 at 23:16, Ezio Melotti <ezio.melotti at gmail.com> wrote:
>> On Sun, Mar 22, 2015 at 9:50 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> I did just remember another small item though - hooking up searching
>>> by Real Name in addition to Username when adding someone to the nosy
>>> list (not everyone uses the first.last naming convention for their
>>> username, especially if they have an already established username
>>> they're bringing over from other services)
>>>
>>
>> That should already work, but the autocomplete only includes people in
>> the expert list and committers.
>
> Aye, that part is great, the specific part I'm referring to is the
> search dialogue that pops up when you click on the "(list)" link.
>

I haven't really used that since I added the autocomplete -- I even
considered removing it before forgetting about its existence.  Once
the REST API for Roundup is in place, these things can easily be
improved (and new things can also be added -- e.g. searching related
issues as you type the title of a new one).

> I also wondered whether there might be a few enhancements that could
> be gathered under a "Improved mentoring support" theme, like being
> able to check how many patches someone has uploaded vs how many of the
> related issues have been resolved, or helping mentors keep a record of
> who's patches they've accepted recently.
>

This will likely require two changes:
1) add more metadata in the db (possibly determined automatically by
Roundup/HG/Kallithea/etc.);
2) retrieving and presenting them to the user (this will be easier
once the REST API is there).
FWIW there are already plans about analyzing patches and adding to the
DB the list of affected files and possibly other fields to signal if
the patch contains tests and docs.

> At the moment we can track commits fairly well, but there isn't really
> much of a link back to the uploaded patches outside the NEWS file and
> commit message, which automated tools tend not to read. (We could also
> look at using "hg commit -u" more to credit patch authors in the
> metadata, and something
> https://bitbucket.org/ede/committer/src/default/hgcommitter.py to
> track the committer info. On the other hand, it may not be worth doing
> that given the expected future work on forge.python.org based
> workflows, regardless of whether that's Kallithea or Phabricator
> based)
>

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.

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.
Another issue is establishing a policy regarding branches and rebases
(rebasements?).
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.

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.

Best Regards,
Ezio Melotti

>>>>   * since some of the Roundup devs said they would be available to
>>>> help, one option would be to find a core Python mentor for this
>>>> project (Nick?) and then the student can still interact with the
>>>> Roundup guys (including me) and get help from other devs as well.
>>>
>>> I'm already trying to figure out how to gracefully hand at least some
>>> of my current projects over to other people, so I won't be
>>> volunteering for anything new any time soon :)
>>
>> If you figure that out let me know, or else I'll have to take the
>> cloning route again :)
>
> Taking into account the many things I'd like to eventually see fixed
> upstream when figuring out what I want to do with my professional
> career helps, but I can certainly see the attraction of the cloning
> option :)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia