[python-committers] Comments on moving issues to GitHub

[Victor Stinner]

Hi,

I failed to get the microphone after Mariatta's secret talk about
moving Python issues from bugs.python.org (Roundup) to GitHub.

I just wanted to add that it's common (at least once per month) that
someone comes to #python-dev to report that they cannot connect to
bugs.python.org (the authentication is broken). Usually, I tried to
point them to the meta-bug tracker, but I hate doing that... The
concept of a meta-bug tracker blows my mind :-)

Right now, I tied to add a comment on an issue and I got the error:

"""
Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /issue32534.

Reason: Error reading from remote server


Apache/2.2.16 (Debian) Server at bugs.python.org Port 443
"""

Sometimes, I get a SSL error. I reported the issue 7 months ago, and
sometimes I still get the error:

https://github.com/python/psf-infra-meta/issues/4

It's a random error, but using a loop, it's easy to reproduce it.


I don't have a strong opinion about moving issues to GitHub. I just
wanted to point out that if we keep bugs.python.org, we need more
volunteers to maintain it. I would prefer to not have to redirect new
comers, who want to report a simple bug, to a "meta bug tracker"...


I don't plan to report the proxy error, since my previous bug report
(SSL error) is still not fixed and it's the first time that I got this
error.

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Comments on moving issues to GitHub

[M.-A. Lemburg]

Reading the comments in the thread and having used Github issues
myself for a few years now, I find the idea of moving from a
dedicated issue tracker we can easily customize to our needs
(or hire someone to do so via the PSF) to a simplistic tracker
add-on, which Github issues is, not a very promising approach.

Github issues are fine for simple projects, but I wouldn't even
want to use it for more than a hundred issues on Github.

As with many such proposals, if an existing system is seen to
be lacking in certain ways, the first thing people suggest is to
ditch it and move to this other new shiny thing or even
worse, suggest to build a new one.

I've rarely seen this work. Most of the time you end up having
a system with just different issues which leaves you with a
situation that's not better than before.

The time invested in migration and making sure that at least
part of the legacy will forward to the new solution is often
better invested in addressing the issues with the older system.

Yes, that's not as interesting and exciting as building something
new, but in the light of productivity and getting a working
solution, it's very often the better approach.

So if there is a real need to fix issues with bpo, then I'd
suggest to write up a proposal to get them fixed and find
a group of developers to work on these. Have the PSF provide
a grant to make it worthwhile and manage this project instead
of spending time with migrations.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jun 02 2018)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   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/
  http://www.malemburg.com/

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Antoine Pitrou]

Le 19/05/2018 à 02:10, Victor Stinner a écrit :
> Hi,
> 
> I failed to get the microphone after Mariatta's secret talk about
> moving Python issues from bugs.python.org (Roundup) to GitHub.

A "secret talk"? What is that?

> I don't have a strong opinion about moving issues to GitHub.

If that's on the table, it seems to me that categorization, sorting and
filtering on GitHub issues is rather poor, while the basic UI experience
(editing messages, etc.) is better.  Also, I think customization (e.g.
of the default view) is basically inexistent.

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Stefan Krah]

On Sun, May 20, 2018 at 10:56:21AM +0200, Antoine Pitrou wrote:
> If that's on the table, it seems to me that categorization, sorting and
> filtering on GitHub issues is rather poor, while the basic UI experience
> (editing messages, etc.) is better.  Also, I think customization (e.g.
> of the default view) is basically inexistent.

Also search via Google "site:bugs.python.org " usually gives quite
nice results, while the same for GitHub issues usually does not work at
all (far too many unrelated results).


Then there's the original promise of the GitHub migration that in the
case of GH bankruptcy or a sudden lockdown the tracker would still be
available.



Stefan Krah



___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Nathaniel Smith]

On Sun, May 20, 2018, 03:18 Antoine Pitrou  wrote:

>
> Le 19/05/2018 à 02:10, Victor Stinner a écrit :
> > Hi,
> >
> > I failed to get the microphone after Mariatta's secret talk about
> > moving Python issues from bugs.python.org (Roundup) to GitHub.
>
> A "secret talk"? What is that?
>

She gave a talk at the language summit to discuss what people thought of
the idea, and she had some fun making the topic a surprise so she could see
people's reactions. I don't think there's any secret beyond that.

IIRC, the general reaction was that it was definitely worth exploring, but
that it would be a lot of work and require solutions to a lot of problems
to make sure people's workflows weren't too impacted, so we'd need a much
more detailed proposal before any decision could be made.

-n
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Barry Warsaw]

On May 20, 2018, at 10:19, Nathaniel Smith  wrote:
> 
> IIRC, the general reaction was that it was definitely worth exploring, but 
> that it would be a lot of work and require solutions to a lot of problems to 
> make sure people's workflows weren't too impacted, so we'd need a much more 
> detailed proposal before any decision could be made.

Note too that Bryan Clark from GitHub, who I believe is a product manager 
there, was at the packaging mini-summit.  If/when we have a specific set of 
asks for the migration, we can reach out to him and see how they can help.  For 
example, I specifically asked about my favorite GitLab feature “commit when CI 
passes” and it sounded like they were working on that.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Brett Cannon]

On Sun, 20 May 2018 at 10:43 Barry Warsaw  wrote:

> On May 20, 2018, at 10:19, Nathaniel Smith  wrote:
> >
> > IIRC, the general reaction was that it was definitely worth exploring,
> but that it would be a lot of work and require solutions to a lot of
> problems to make sure people's workflows weren't too impacted, so we'd need
> a much more detailed proposal before any decision could be made.
>
> Note too that Bryan Clark from GitHub, who I believe is a product manager
> there, was at the packaging mini-summit.  If/when we have a specific set of
> asks for the migration, we can reach out to him and see how they can help.
> For example, I specifically asked about my favorite GitLab feature “commit
> when CI passes” and it sounded like they were working on that.
>

There was also general consensus that the state of maintenance for bpo is
subpar due to lack of staffing and that more people will need to come
forward to help maintain it if we decide to not transition to another issue
tracker like GitHub or GitLab.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Nick Coghlan]

On 21 May 2018 at 05:03, Brett Cannon  wrote:

>
>
> On Sun, 20 May 2018 at 10:43 Barry Warsaw  wrote:
>
>> On May 20, 2018, at 10:19, Nathaniel Smith  wrote:
>> >
>> > IIRC, the general reaction was that it was definitely worth exploring,
>> but that it would be a lot of work and require solutions to a lot of
>> problems to make sure people's workflows weren't too impacted, so we'd need
>> a much more detailed proposal before any decision could be made.
>>
>> Note too that Bryan Clark from GitHub, who I believe is a product manager
>> there, was at the packaging mini-summit.  If/when we have a specific set of
>> asks for the migration, we can reach out to him and see how they can help.
>> For example, I specifically asked about my favorite GitLab feature “commit
>> when CI passes” and it sounded like they were working on that.
>>
>
> There was also general consensus that the state of maintenance for bpo is
> subpar due to lack of staffing and that more people will need to come
> forward to help maintain it if we decide to not transition to another issue
> tracker like GitHub or GitLab.
>

Right, one of the outcomes of the discussion at the Summit was that any
proposal to migrate to a different issue tracker would need to present a
clear statement of the *problems intended to be solved*, such that the
folks that would prefer to see us stay on our own issue tracker could
present a competing proposal to solve those problems without a wholesale
migration to another system.

Some examples of problems that would benefit from attention:

- fixing the SSL/TLS connectivity issues
- making the issue tracker usable on mobile devices
- ability to edit the description for issues that evolve over time, not
just the title
- improved editing support for comments (both in initial formatting, and in
being able to correct errors)
- REST API access to tracker data
- simplifying account creation (especially for folks that already have
GitHub accounts)
- rationalising the metadata fields by asking which ones actually see
significant use

Some examples of problems that in-place enhancement of the tracker would
inherently avoid, but a migration proposal would need to address:

- preservation of existing incoming links to issues
- figuring out which issues to migrate automatically (all of them? None of
them? Open issues only?)
- figuring out a new way to track PSF CLA signatures
- figuring out a replacement for the Experts Index integration into the
Roundup nosy list
- figuring out replacements for the custom metadata fields that we actually
use regularly
- meeting our original GitHub migration commitment to continue offering a
way of engaging with the core development process without requiring
accounts with any entity other than the PSF

It's far from being a foregone conclusion that migrating to a new issue
tracker will be the preferred answer, but there are also genuine problems
with the status quo that need to be addressed somehow.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Barry Warsaw]

On May 21, 2018, at 03:24, Nick Coghlan  wrote:

> Right, one of the outcomes of the discussion at the Summit was that any 
> proposal to migrate to a different issue tracker would need to present a 
> clear statement of the *problems intended to be solved*, such that the folks 
> that would prefer to see us stay on our own issue tracker could present a 
> competing proposal to solve those problems without a wholesale migration to 
> another system.

I’d like to see multiple PEPs for this migration.  The first would clearly 
outline discussion points that apply regardless of where we migrate to, or 
whether we migrate at all.  This would include lists of common use cases, the 
problems with the current system, the features we like (and regularly use!) in 
the current system, and a list of key points that can be compared against any 
proposed solution.

E.g. for this latter, let’s say one of the points is “ability to easily ignore 
all discussions on tickets you don’t care about”.  You could imagine a row in a 
table that shows how any of the proposed solutions compare to what we have 
today.  You could color code this on a gradient, say from dark green (“it will 
be much better on system X”) to dark red (“it’ll be much more difficult on 
system Y”).

That would be one PEP, and it would be the baseline for making a decision.  
Additional PEPs would make specific proposals, e.g. move to GH, stay on bpo as 
is, significantly invest in bpo, etc.  They’d reference the baseline PEP and 
include that table with the color coded rows.

Then perhaps after the decision is made, there would maybe be an implementation 
PEP describing the steps it will take to migrate, and the ETA.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Larry Hastings]

On 05/20/2018 10:19 AM, Nathaniel Smith wrote:
On Sun, May 20, 2018, 03:18 Antoine Pitrou > wrote:



Le 19/05/2018 à 02:10, Victor Stinner a écrit :
> Hi,
>
> I failed to get the microphone after Mariatta's secret talk about
> moving Python issues from bugs.python.org
 (Roundup) to GitHub.

A "secret talk"? What is that?


She gave a talk at the language summit to discuss what people thought 
of the idea, and she had some fun making the topic a surprise so she 
could see people's reactions. I don't think there's any secret beyond 
that.


You have it exactly.  She wanted us (the Language Summit organizers) to 
keep the talk title a secret until she could reveal it herself in front 
of the audience.  I suggested the official title on the schedule be 
"Mariatta's Topic Of Mystery" and we collectively went with that.  At 
this point nothing about it is a secret.



//arry/
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Mariatta Wijaya]

Yup, the "mystery" was just for fun 😛
There is no secret. I've been thinking that we should start using GitHub
issues instead of the b.p.o.

I realized not everyone was able to get to the language summit, and I fully
intended to update python-committers with this idea.
I just haven't been reading the mailing list for sometime until today.

For those who missed it, some resources:

1. My language summit slides (
https://speakerdeck.com/mariatta/mariattas-python-language-summit-2018-presentation
)
There are 3 bonus slides at the end which I did not get to cover, because
we were running late and it was lunchtime. (in the end, we were 3 hrs
overtime.)
Those can be discussed in core-workflow.

2. LWN article: https://lwn.net/Articles/754779/
I will not be reading/responding to the comments in LWN. 🤐

3. My initial research into this topic:
https://docs.google.com/document/d/1b3H-OQaZ7oc5jI9l7CEx9b_zCpao6PfEV1tIg0vpgG8/edit?usp=sharing


Mariatta

ᐧ
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Antoine Pitrou]

Hi Mariatta,

Le 02/06/2018 à 01:07, Mariatta Wijaya a écrit :
> 
> For those who missed it, some resources:
> 
> 1. My language summit slides
> (https://speakerdeck.com/mariatta/mariattas-python-language-summit-2018-presentation)
> There are 3 bonus slides at the end which I did not get to cover,
> because we were running late and it was lunchtime. (in the end, we were
> 3 hrs overtime.)
> Those can be discussed in core-workflow.
> 
> 2. LWN article: https://lwn.net/Articles/754779/ 
> I will not be reading/responding to the comments in LWN. 🤐

Thanks for the pointers.

I agree with the UI concerns about b.p.o.  But I also agree with the
response mentioned in LWN.  Especially the lack of categorization in
Github issues.

I've used Github issues on other projects.  It's fine when you have a
small-to-medium number of open issues (say, no more than a couple
hundreds).  But I don't think it's usable for a project with several
thousands issues open.  At a micro level, the editing UI is pleasant to
use.  But at a more macro level, it's rather painful to navigate in a
large number of issues.

I wonder if other hosted services, such as Gitlab, offer a more
sophisticated issue tracker.

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Barry Warsaw]

On Jun 1, 2018, at 16:54, Antoine Pitrou  wrote:
> 
> I wonder if other hosted services, such as Gitlab, offer a more
> sophisticated issue tracker.

Not really.  Mailman has a little less than 200 open issues, but they are 
basically categorized in the same way as GitHub, i.e. via labels.

https://gitlab.com/mailman/mailman/issues

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Ivan Levkivskyi]

On 1 June 2018 at 20:29, Barry Warsaw  wrote:

> On Jun 1, 2018, at 16:54, Antoine Pitrou  wrote:
> >
> > I wonder if other hosted services, such as Gitlab, offer a more
> > sophisticated issue tracker.
>
>
Note that GitHub (and I think GitLab too) provides two additional ways to
categorise issues: project boards, and milestones.
I think together with labels this may simulate current b.p.o. structure to
certain extent. For example (approximately):
* We can have milestones for releases (including past releases)
* We can have "project boards" (slightly abusing this feature): new,
triaged, PR review
* Labels can be grouped using name prefix and color, for example (we have
similar structure in mypy):
  - priority-low
  - priority-normal
  - priority-etc...
  - kind-bug
  - kind-docs
  - kind-feature
  - topic-asincio
  - topic-etc..

This is still quite limited, but together with bots this can practically
replace current categorisation.

--
Ivan
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Terry Reedy]

On 6/1/2018 7:07 PM, Mariatta Wijaya wrote:

Yup, the "mystery" was just for fun 😛
There is no secret. I've been thinking that we should start using GitHub 
issues instead of the b.p.o.


I realized not everyone was able to get to the language summit, and I 
fully intended to update python-committers with this idea.

I just haven't been reading the mailing list for sometime until today.

For those who missed it, some resources:

1. My language summit slides 
(https://speakerdeck.com/mariatta/mariattas-python-language-summit-2018-presentation)


"Old and languishing issues should just be closed / ignored"

I disagree with doing this blindly, and I would be mightily annoyed if 
someone did so with IDLE issues and hide valuable ideas and code.  For 
example:


In Sept 2006, Tal Einat suggested that IDLE's class browser, based on 
the pyclbr module, should report nested classed.

https://bugs.python.org/issue1612262

In August 2009, Guilherme Polo submitted patches for pyclbr and IDLE 
that also supported nested functions.  https://bugs.python.org/issue6691

I discovered the issue and approved of the idea in Sept 2015

In June and July 2017, Cheryl Sabella and I updated, rewrote, finished, 
and merged both patches.


To deal with issues better, we need

1. More core developers, so more modules can have maintainers.

2. Better support for core developers in the tracker.

2a. The ability to tag issues with the module (or perhaps modules) that 
an issue more pertains to.


2b. Associated (linked) manager or dashboard for issues pertaining to a 
module or group of modules.


There are currently about 60 idlelib module and 250 IDLE issues.  To not 
go crazy or become paralyzed, I keep a list (in a file) organized by 
topics, which mostly correspond to modules.  Since I started this, I 
have closed perhaps 40-50 issues.  For one thing, collecting together 
issues pertaining to a topic/module makes it easy to spot out of date 
and duplicate issues.


If I could tag IDLE issues with module names and retrieve them by 
module, that would partly duplicate what I have done.  It would also be 
nice to have the line online, and public, with issue numbers linking 
back to issues.  It would be nice if tagging an issue caused it to be 
automatically added to the appropriate sublist.


Would moving to github make such a substantial improvement?

There are 3 bonus slides at the end which I did not get to cover, 
because we were running late and it was lunchtime. (in the end, we were 
3 hrs overtime.)


Automerge: should signal separate from 'I approve of this PR'.  Commit 
message can be put in a labelled comment.  I have started editing the 
initial commit message.


tjr


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Steve Dower]

I think boards have improved since I last used them, but when I tried they 
added nothing but overhead. Possibly useful for planning, if we had someone who 
was responsible for that (maybe individual planning? But then you can’t really 
expect contributors to keep it up to date for you).

Milestones are one-per-issue, and get rolled up in a way that is most useful 
for planning rather than search or review. I use these all the time on work 
projects.

A good set of tags (which unfortunately are shared with the set of tags you can 
put on a PR) and some automation to auto-subscribe the core devs associated 
with that tag is a bare minimum, as far as I’m concerned. It would be nice if 
issue search supported the OR operator as well, but it can only do AND.

I’m far from convinced that GitHub issues will work well for an active team as 
large as ours with as little coordination as we use. It doesn’t work well for 
the “bucket of bugs” I keep open on one of my work projects, even though the 
team is smaller, and our tracker is almost entirely a bucket of bugs.

Top-posted from my Windows 10 phone

From: Ivan Levkivskyi
Sent: Friday, June 1, 2018 18:05
To: Barry Warsaw
Cc: python-committers
Subject: Re: [python-committers] Comments on moving issues to GitHub

On 1 June 2018 at 20:29, Barry Warsaw  wrote:
On Jun 1, 2018, at 16:54, Antoine Pitrou  wrote:
> 
> I wonder if other hosted services, such as Gitlab, offer a more
> sophisticated issue tracker.

Note that GitHub (and I think GitLab too) provides two additional ways to 
categorise issues: project boards, and milestones.
I think together with labels this may simulate current b.p.o. structure to 
certain extent. For example (approximately):
* We can have milestones for releases (including past releases)
* We can have "project boards" (slightly abusing this feature): new, triaged, 
PR review
* Labels can be grouped using name prefix and color, for example (we have 
similar structure in mypy):
  - priority-low
  - priority-normal
  - priority-etc...
  - kind-bug
  - kind-docs
  - kind-feature
  - topic-asincio
  - topic-etc..

This is still quite limited, but together with bots this can practically 
replace current categorisation.

--
Ivan




___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Mariatta Wijaya]

>
> "Old and languishing issues should just be closed / ignored"
> I disagree with doing this blindly, and I would be mightily annoyed if
> someone did so with IDLE issues and hide valuable ideas and code.


Since you are IDLE's maintainer, I'll also be annoyed if other people
except yourself (or other IDLE maintainers) blindly close IDLE issues
without consulting you.

Many modules don't have maintainers anymore. If such issues have been
ignored for all these years, we'll probably never get to it. Might as well
close it.

The proposed idea is to provide a button that can copy over conversations
from a b.p.o issue to GitHub, and to continue discussions in GitHub. If
core devs have a list of issues they still care about, then they use this
not yet existing magic button.

The closed issue will still be in bpo, and anyone motivated enough can
migrate it to GitHub.

To deal with issues better, we need
> 1. More core developers, so more modules can have maintainers.


We need more core developers anyway, regardless of what tracker we're
using. That is a separate problem.

And perhaps this is to be discussed in a separate thread: even though in
the b.p.o we appear to have 170 committers, really there are 90 core devs
(people who has commit right to CPython on GitHub). and out of those 90, I
think only about half are currently active (since the migration to GitHub).
So yes, we need more (active) core devs.

2. Better support for core developers in the tracker.


Not sure what you mean by "support"? There are only two maintainers of the
bug tracker, they both are also Python core developers: Brett and Ezio. My
personal opinion is: they're more valuable elsewhere instead of supporting
the bug tracker. At its current state, the bug tracker is not ready to take
up new contributors, and it will not be easy effort to onboard new bpo
maintainers.

2b. Associated (linked) manager or dashboard for issues pertaining to a
> module or group of modules.


We can try the project boards as Ivan mentioned? https://help.github.com/
articles/about-project-boards/

* Labels can be grouped using name prefix and color, for example (we have
> similar structure in mypy):
>   - priority-low
>   - priority-normal
>   - priority-etc...
>   - kind-bug
>   - kind-docs
>   - kind-feature
>   - topic-asincio
>   - topic-etc..


I kinda like those!

I wonder if other hosted services, such as Gitlab, offer a more
> sophisticated issue tracker.


One thing I'm trying to avoid is having separate issue tracker and repo,
and needing different accounts.

Possibly useful for planning, if we had someone who was responsible for that
>


Perhaps for a project the size of Python we should have a dedicated Project
manager.


Mariatta
ᐧ
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Brett Cannon]

On Sat, 2 Jun 2018 at 12:47 Mariatta Wijaya 
wrote:

> [SNIP]
>
> 2. Better support for core developers in the tracker.
>
>
> Not sure what you mean by "support"? There are only two maintainers of the
> bug tracker, they both are also Python core developers: Brett and Ezio. My
> personal opinion is: they're more valuable elsewhere instead of supporting
> the bug tracker. At its current state, the bug tracker is not ready to take
> up new contributors, and it will not be easy effort to onboard new bpo
> maintainers.
>

I actually wouldn't list me as a maintainer of b.p.o. I only have passing
knowledge of the code due to reviewing Ezio's changes to support the CLA
bot. It used to be RDM, Ezio, and Maciej, then DRM got busy, and then
Maciej got busy with helping move our hosting over to OpenShift and off of
our previously free hosting provider who sold their business (I also think
Maciej is also busy with other things). I don't know what Ezio's
availability currently sits at, but I have not heard from him recently.

If you look at
https://hg.python.org/tracker/roundup/shortlog/bugs.python.org there has
not been an update to the repo's code in 8 months but there have been
reported issues as recently as yesterday:
http://psf.upfronthosting.co.za/roundup/meta/ .

IOW I consider b.p.o unmaintained ATM. Mark Mangoba and the PSF
infrastructure team can re-start the instance if it falls over, but no one
is working on e.g. fixing log-in issues or any of the various UX issues we
are all painfully aware that b.p.o has.

As I said at the language summit, if people want to keep b.p.o around then
we need to get some volunteers to staff it. I personally would like to see
three people step forward and say they will work to improve b.p.o to make
sure it functions as expected now and plan to improve it long-term. But I
personally would settle for just two people actively working towards making
b.p.o a tenable solution (the three person goal is just from experience of
always wanting at least one backup even if someone goes on vacation or does
an OSS detox).

But as of right now we have zero people supporting b.p.o (and GitHub has
one with Mariatta which puts GH ahead in my book). Because of this, in my
opinion this discussion shouldn't include b.p.o as an option until those
volunteers materialize. We can argue GitHub versus GitLab versus some other
issue tracker (open or closed source, self-hosted or service-hosted I
personally don't care; heck write it from scratch like Warehouse if that's
what it takes), but unless we get some people to step forward to help with
b.p.o then I personally consider it our temporary solution until we figure
out where we're going next with b.p.o and not a viable option in this
discussion.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Carol Willing]

Would it be possible to get a database(s) download of all of the b.p.o. data 
(redacting privacy information if needed)?

I would like to work on a proof of concept using the scientific python stack, 
particularly Pandas, to see if we can do a GitHub/GitLab (pick your favorite) 
for all new issues and a front end (Flask, Django, Pyramid, etc.) for 
historical data. This would be much easier to do with access to the underlying 
data.



> On Jun 2, 2018, at 1:26 PM, Brett Cannon  > wrote:
> 
> 
> 
> On Sat, 2 Jun 2018 at 12:47 Mariatta Wijaya  > wrote:
> [SNIP]
> 
> 2. Better support for core developers in the tracker.
> 
> Not sure what you mean by "support"? There are only two maintainers of the 
> bug tracker, they both are also Python core developers: Brett and Ezio. My 
> personal opinion is: they're more valuable elsewhere instead of supporting 
> the bug tracker. At its current state, the bug tracker is not ready to take 
> up new contributors, and it will not be easy effort to onboard new bpo 
> maintainers.
> 
> I actually wouldn't list me as a maintainer of b.p.o. I only have passing 
> knowledge of the code due to reviewing Ezio's changes to support the CLA bot. 
> It used to be RDM, Ezio, and Maciej, then DRM got busy, and then Maciej got 
> busy with helping move our hosting over to OpenShift and off of our 
> previously free hosting provider who sold their business (I also think Maciej 
> is also busy with other things). I don't know what Ezio's availability 
> currently sits at, but I have not heard from him recently.
> 
> If you look at https://hg.python.org/tracker/roundup/shortlog/bugs.python.org 
>  there has 
> not been an update to the repo's code in 8 months but there have been 
> reported issues as recently as yesterday: 
> http://psf.upfronthosting.co.za/roundup/meta/ 
>  .
> 
> IOW I consider b.p.o unmaintained ATM. Mark Mangoba and the PSF 
> infrastructure team can re-start the instance if it falls over, but no one is 
> working on e.g. fixing log-in issues or any of the various UX issues we are 
> all painfully aware that b.p.o has.
> 
> As I said at the language summit, if people want to keep b.p.o around then we 
> need to get some volunteers to staff it. I personally would like to see three 
> people step forward and say they will work to improve b.p.o to make sure it 
> functions as expected now and plan to improve it long-term. But I personally 
> would settle for just two people actively working towards making b.p.o a 
> tenable solution (the three person goal is just from experience of always 
> wanting at least one backup even if someone goes on vacation or does an OSS 
> detox).
> 
> But as of right now we have zero people supporting b.p.o (and GitHub has one 
> with Mariatta which puts GH ahead in my book). Because of this, in my opinion 
> this discussion shouldn't include b.p.o as an option until those volunteers 
> materialize. We can argue GitHub versus GitLab versus some other issue 
> tracker (open or closed source, self-hosted or service-hosted I personally 
> don't care; heck write it from scratch like Warehouse if that's what it 
> takes), but unless we get some people to step forward to help with b.p.o then 
> I personally consider it our temporary solution until we figure out where 
> we're going next with b.p.o and not a viable option in this discussion.
> ___
> python-committers mailing list
> python-committers@python.org 
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Ezio Melotti]

Hi,

On Sat, Jun 2, 2018 at 10:26 PM, Brett Cannon  wrote:
>
>
> On Sat, 2 Jun 2018 at 12:47 Mariatta Wijaya 
> wrote:
>>
>> [SNIP]
>>
>>> 2. Better support for core developers in the tracker.
>>
>>
>> Not sure what you mean by "support"? There are only two maintainers of the
>> bug tracker, they both are also Python core developers: Brett and Ezio. My
>> personal opinion is: they're more valuable elsewhere instead of supporting
>> the bug tracker. At its current state, the bug tracker is not ready to take
>> up new contributors, and it will not be easy effort to onboard new bpo
>> maintainers.
>
>
> I actually wouldn't list me as a maintainer of b.p.o. I only have passing
> knowledge of the code due to reviewing Ezio's changes to support the CLA
> bot. It used to be RDM, Ezio, and Maciej, then DRM got busy, and then Maciej
> got busy with helping move our hosting over to OpenShift and off of our
> previously free hosting provider who sold their business (I also think
> Maciej is also busy with other things). I don't know what Ezio's
> availability currently sits at, but I have not heard from him recently.
>

I haven't actively worked on the tracker, but I kept an eye on it and
acting when needed (e.g. yesterday I deployed a fix committed by
Berker :).
If needed I can pick it up again.
It should also be mentioned that before us, MvL also used to work on
the tracker, and he added the Rietveld and openid integration (and
these parts are not very well maintained now).

> If you look at
> https://hg.python.org/tracker/roundup/shortlog/bugs.python.org there has not
> been an update to the repo's code in 8 months but there have been reported
> issues as recently as yesterday:
> http://psf.upfronthosting.co.za/roundup/meta/ .
>

This is a bit misleading:
* that repo is updated only when Roundup is updated otherwise it sits
there waiting for a new release. Roundup 1.6 is going to be released
soon;
* the repo for our instance is
https://hg.python.org/tracker/python-dev/shortlog/default .  This also
didn't get many commits lately, however
* the meta tracker also didn't get many new issues.  Only 7 issues in
the metatracker have had any activity in the last 3 months, 2 are
about SSL failure/certificates, 3 are about email ending up in the
spam, one is about Google auth (however I'm not familiar with that
part of the code), and the last one is a minor issue with a simple fix
that needs to be tested/deployed.

IOW there aren't many commits because there aren't that many issues
with the code and because Roundup 1.6 hasn't been released yet.


As mentioned above, the Roundup team is about to release Roundup 1.6.
This release drops support for Python <2.7.
AFAIU the infra team wanted to move/upgrade the machine running b.p.o
(that is currently still running Python 2.6).  When that happens (and
once Roundup 1.6 is released) we will upgrade it.


> IOW I consider b.p.o unmaintained ATM. Mark Mangoba and the PSF
> infrastructure team can re-start the instance if it falls over, but no one
> is working on e.g. fixing log-in issues or any of the various UX issues we
> are all painfully aware that b.p.o has.
>
> As I said at the language summit, if people want to keep b.p.o around then
> we need to get some volunteers to staff it. I personally would like to see
> three people step forward and say they will work to improve b.p.o to make
> sure it functions as expected now and plan to improve it long-term. But I
> personally would settle for just two people actively working towards making
> b.p.o a tenable solution (the three person goal is just from experience of
> always wanting at least one backup even if someone goes on vacation or does
> an OSS detox).
>

It depends on what kind of maintenance we need.  In its current state
b.p.o is quite stable and requires little maintenance IMHO.
If instead we want to start adding (and fixing/maintaining) new
features, then the situation is different.

For the latter to happen, I would like to first see a PEP discussing
what desired features GitHub has that Roundup doesn't and vice versa
(Nick's list and Mariatta's slides and notes are a good starting
point, but they should be consolidated and include the feedback
expressed by other core devs on this thread).
>From there we can evaluate how difficult it would be to implement
those in Roundup and how this will compare with the difficulty of
switching to GitHub or some other system.

I already discussed with the Roundup devs about some of the features
listed by Nick, so I can comment on them:

> 
> Some examples of problems that would benefit from attention:
>
> - fixing the SSL/TLS connectivity issues

This is also being discussed at
https://github.com/python/psf-infra-meta/issues/4 (since it's an infra
issue).  One of the Roundup devs recently suggested a solution that
still needs to be tested.

> - making the issue tracker usable on mobile devices

The Roundup team has already some working prototype.

> - ability to edit the description f

Re: [python-committers] Comments on moving issues to GitHub

[Brett Cannon]

On Sat, 2 Jun 2018 at 14:58 Ezio Melotti  wrote:

> Hi,
>
> On Sat, Jun 2, 2018 at 10:26 PM, Brett Cannon  wrote:
> >
> >
> > On Sat, 2 Jun 2018 at 12:47 Mariatta Wijaya 
> > wrote:
> >>
> >> [SNIP]
> >>
> >>> 2. Better support for core developers in the tracker.
> >>
> >>
> >> Not sure what you mean by "support"? There are only two maintainers of
> the
> >> bug tracker, they both are also Python core developers: Brett and Ezio.
> My
> >> personal opinion is: they're more valuable elsewhere instead of
> supporting
> >> the bug tracker. At its current state, the bug tracker is not ready to
> take
> >> up new contributors, and it will not be easy effort to onboard new bpo
> >> maintainers.
> >
> >
> > I actually wouldn't list me as a maintainer of b.p.o. I only have passing
> > knowledge of the code due to reviewing Ezio's changes to support the CLA
> > bot. It used to be RDM, Ezio, and Maciej, then DRM got busy, and then
> Maciej
> > got busy with helping move our hosting over to OpenShift and off of our
> > previously free hosting provider who sold their business (I also think
> > Maciej is also busy with other things). I don't know what Ezio's
> > availability currently sits at, but I have not heard from him recently.
> >
>
> I haven't actively worked on the tracker, but I kept an eye on it and
> acting when needed (e.g. yesterday I deployed a fix committed by
> Berker :).
> If needed I can pick it up again.
>

Great! So now we're tied for GitHub and b.p.o maintenance. ;)


> It should also be mentioned that before us, MvL also used to work on
> the tracker, and he added the Rietveld and openid integration (and
> these parts are not very well maintained now).
>

Oh, the list of former contributors was not meant to be exhaustive, more
just who I could remember during the GitHub transition days.


>
> > If you look at
> > https://hg.python.org/tracker/roundup/shortlog/bugs.python.org there
> has not
> > been an update to the repo's code in 8 months but there have been
> reported
> > issues as recently as yesterday:
> > http://psf.upfronthosting.co.za/roundup/meta/ .
> >
>
> This is a bit misleading:
> * that repo is updated only when Roundup is updated otherwise it sits
> there waiting for a new release. Roundup 1.6 is going to be released
> soon;
>

Sorry about that, I just grabbed the URL the contribution docs say to work
from for Roundup and didn't notice the extra URL for configuration.


> * the repo for our instance is
> https://hg.python.org/tracker/python-dev/shortlog/default .  This also
> didn't get many commits lately, however
> * the meta tracker also didn't get many new issues.  Only 7 issues in
> the metatracker have had any activity in the last 3 months, 2 are
> about SSL failure/certificates, 3 are about email ending up in the
> spam, one is about Google auth (however I'm not familiar with that
> part of the code), and the last one is a minor issue with a simple fix
> that needs to be tested/deployed.
>
> IOW there aren't many commits because there aren't that many issues
> with the code and because Roundup 1.6 hasn't been released yet.
>
>
> As mentioned above, the Roundup team is about to release Roundup 1.6.
> This release drops support for Python <2.7.
> AFAIU the infra team wanted to move/upgrade the machine running b.p.o
> (that is currently still running Python 2.6).  When that happens (and
> once Roundup 1.6 is released) we will upgrade it.
>
>
> > IOW I consider b.p.o unmaintained ATM. Mark Mangoba and the PSF
> > infrastructure team can re-start the instance if it falls over, but no
> one
> > is working on e.g. fixing log-in issues or any of the various UX issues
> we
> > are all painfully aware that b.p.o has.
> >
> > As I said at the language summit, if people want to keep b.p.o around
> then
> > we need to get some volunteers to staff it. I personally would like to
> see
> > three people step forward and say they will work to improve b.p.o to make
> > sure it functions as expected now and plan to improve it long-term. But I
> > personally would settle for just two people actively working towards
> making
> > b.p.o a tenable solution (the three person goal is just from experience
> of
> > always wanting at least one backup even if someone goes on vacation or
> does
> > an OSS detox).
> >
>
> It depends on what kind of maintenance we need.  In its current state
> b.p.o is quite stable and requires little maintenance IMHO.
>

I would be more inclined to agree if we didn't have so many login problems
(e.g. I have needed to manually go in and set people's passwords to reset
it due to issues getting password reset emails).


> If instead we want to start adding (and fixing/maintaining) new
> features, then the situation is different.
>
> For the latter to happen, I would like to first see a PEP discussing
> what desired features GitHub has that Roundup doesn't and vice versa
> (Nick's list and Mariatta's slides and notes are a good starting
> point, but they should be consolidated and

Re: [python-committers] Comments on moving issues to GitHub

[Nick Coghlan]

On 3 June 2018 at 12:49, Brett Cannon  wrote:

>
> On Sat, 2 Jun 2018 at 14:58 Ezio Melotti  wrote:
>
> Even if the volunteers don't materialize (and I dematerialize), we
>> still have to determine if the cost of keep using b.p.o as is, is
>> greater than the cost of moving everything to a new system.
>>
>
> Yep.
>

Since even Mariatta's GitHub migration proposal is likely to require
changes to bugs.python.org (most notably adding the REST API to better
enable automated issue management), something that would be nice to see is
for b.p.o to migrate over to the common "Support repo" model we've adopted
(i.e. hosted on GitHub using the integrated issue tracker for repo-specific
issues).

I'll also email Maciej & EW Durbin ([1]) to see if they've had a chance to
discuss the rehosting plans for bugs.python.org yet.

Cheers,
Nick.

[1] the PSF's new Director of Infrastructure [2], who some folks may
already know from his extensive work on PyPI and other parts of the PSF
infrastructure, as well as chairing Python US in 2018/19
[2] https://twitter.com/EWDurbin/status/1001519029767561216

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Nick Coghlan]

On 3 June 2018 at 17:00, Nick Coghlan  wrote:

> I'll also email Maciej & EW Durbin ([1]) to see if they've had a chance to
> discuss the rehosting plans for bugs.python.org yet.
>

The status update here is that Maciej has been bringing Ernest up to speed
on the preparatory work that has already been done, but there's still some
further work to be done before they can provide an ETA for the actual
migration more precise than "in the not too distant future" (my
understanding is that the main items still being reviewed are the preferred
final destination for the PostgreSQL database, as well as how best to
actually execute the cutover).

Maciej also noted that while he's definitely interested in continuing to
work on bugs.python.org maintenance activities, he can't reply directly to
this thread since it's a CPython-committers-only list.

That's a very fair point, so I'd suggest that we move any further
discussion over to the core-workflow list. If folks don't want to subscribe
to yet-another-mailing-list, that's one that we've already migrated to
Mailman 3, so it has a web interface available at
https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ (my
recommendation is to use your GitHub account to sign in, but there are
other social-auth login options, as well as the traditional email+password
approach).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/