Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

[Victor Stinner]

Le mer. 15 mai 2019 à 20:46, Guido van Rossum  a écrit :
> But trust me that the SC didn't take this decision lightly. It was unanimous, 
> and we have all thought about this a great deal (and listened to long 
> arguments pro and con). It's also impossible to satisfy everyone -- some 
> people find GitHub unacceptable (I've heard about 1-2 people who refused to 
> create GitHub accounts), but others find bpo unusable (the need to have a bpo 
> account in order to accept the CLA has been brought up repeatedly).

Around me, many people told me that they were awaiting for the PEP 581
to be accepted,. They are now *very kind* that Python issues are
moving to GitHub.

Honestly, I don't understand why people are excited by bug tracker,
for me it's not the most exciting part of development :-) But it seems
like many people were unhappy with Roundup.

At least, I can say that I'm not a big fan of it's UI (maybe too
complex, too many fields) compared to GitHub. I can also understand
that it's annoying for contributor to have to create 2 separated
accounts (bugs.python.org and GitHub) and link them *carefully*
(mistakes are common, you can see that when a contributor waits for
the "CLA signed" label). Sometimes, they are some glitches with
bugs.python.org <=> GitHub integration: some notifications take longer
30 sec or simply never happen.

I understand that GitHub is better to *report* bugs (and maybe to
comment an issue), but maybe worse for bug triage, and that we want to
make sure that it's easier to contribute to Python for "regular
contributors".

I also know that GitHub isn't perfect and that it will take time to
build a new efficient workflow on top of GitHub.


> A successful migration will take a lot of work, and PEP 588 is where we keep 
> track of tasks to be accomplished. (There are more that haven't made it to 
> that PEP, e.g. the mechanics of the actual move.) We're also hoping to get 
> professional help managing the migration so that not everything relies on 
> volunteers.

That would be great! The migration of the code took something like 2
years and it was a little bit painful for everybody at the beginning.
Having someone paid for that would make the migration shorter and
maybe also smoother.

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

[Guido van Rossum]

IMO the text of PEP 581 could use some improvements to capture more of the
debate. For example:

- If people want to submit PRs to the peps repo that correct *factual*
mistakes in PEP 581, they're welcome to (and I will personally see that
they will be merged). For example, IIRC you *can* reply to a bpo issue via
email, so that bullet should probably be struck.

- If someone wants to volunteer a PR to the peps repo that adds a list of
objections against the move, e.g. losing certain bpo capabilities, or
specific undesirable behaviors or properties of GitHub, that will also be
entertained (but be reasonable).

But trust me that the SC didn't take this decision lightly. It was
unanimous, and we have all thought about this a great deal (and listened to
long arguments pro and con). It's also impossible to satisfy everyone --
some people find GitHub unacceptable (I've heard about 1-2 people who
refused to create GitHub accounts), but others find bpo unusable (the need
to have a bpo account in order to accept the CLA has been brought up
repeatedly).

A successful migration will take a lot of work, and PEP 588 is where we
keep track of tasks to be accomplished. (There are more that haven't made
it to that PEP, e.g. the mechanics of the actual move.) We're also hoping
to get professional help managing the migration so that not everything
relies on volunteers.

(Speaking of relying on volunteers, if you haven't seen Russel
Keith-Magee's keynote at the most recent PyCon US, please watch it. It is
an amazing thing. https://www.youtube.com/watch?v=ftP5BQh1-YM -- start at
21:00 to skip the conference opening remarks.)

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(why is my pronoun here?)*

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

[Brett Cannon]

On Wed, May 15, 2019 at 9:53 AM Steve Dower  wrote:

> On 15May2019 0240, Paul Moore wrote:
> > On Wed, 15 May 2019 at 09:51, Antoine Pitrou 
> wrote:
> >>
> >> On Tue, 14 May 2019 18:11:14 -0700
> >> Barry Warsaw  wrote:
> >>
> >>> As the BDFL-Delegate for PEP 581, and with the unanimous backing of
> the rest of the Steering Council, I hereby Accept this PEP.
> >>
> >> For future reference, is it possible to post the Steering Council's
> >> reflection and rationale on the PEP?
> >
> > Also, is there an archive of the discussions anywhere? The PEP says
> > discussions happened on Zulip, but I don't follow that and I don't
> > know where I can find an archived copy of the discussions.
>
> I think it would be ideal if the PEP itself summarised the major points
> of these discussions, or at least the links to the discussions (assuming
> we trust Zulip and Discourse to never lose them).
>
> Right now I have a lot of fundamental problems with this PEP as written.
> But I'm assured that the Steering Council gave it thorough consideration
>

Yes, sorry if that wasn't communicated better. This was in no way a
knee-jerk decision. Beyond all of us following this topic personally since
it was first brought up last year, we have also been discussing it nearly
every meeting in some form or another since we began discussing PEPs (which
would be probably since February).


> and that the discussions covered all relevant aspects, so I'm not going
> to create too much of a fuss about it. If they want to move us
> completely to GitHub, so be it!
>

I've added to our next meeting's agenda discussing potentially fleshing out
PEP 581 a bit more.

-Brett


>
> Cheers,
> Steve
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

[Steve Dower]

On 15May2019 0240, Paul Moore wrote:

On Wed, 15 May 2019 at 09:51, Antoine Pitrou  wrote:


On Tue, 14 May 2019 18:11:14 -0700
Barry Warsaw  wrote:


As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest of 
the Steering Council, I hereby Accept this PEP.


For future reference, is it possible to post the Steering Council's
reflection and rationale on the PEP?


Also, is there an archive of the discussions anywhere? The PEP says
discussions happened on Zulip, but I don't follow that and I don't
know where I can find an archived copy of the discussions.


I think it would be ideal if the PEP itself summarised the major points 
of these discussions, or at least the links to the discussions (assuming 
we trust Zulip and Discourse to never lose them).


Right now I have a lot of fundamental problems with this PEP as written. 
But I'm assured that the Steering Council gave it thorough consideration 
and that the discussions covered all relevant aspects, so I'm not going 
to create too much of a fuss about it. If they want to move us 
completely to GitHub, so be it!


Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

[Brett Cannon]

On Wed, May 15, 2019 at 5:38 AM Victor Stinner  wrote:

> Le mer. 15 mai 2019 à 11:31, Christian Heimes  a
> écrit :
> > What are the next step? Will there be another PEP that explores how we
> > are going to deal with migration, workflow changes, and how we plan to
> > map current BPO features to Github?
>
> Yes, it's the:
>
> PEP 588 -- GitHub Issues Migration Plan
> https://www.python.org/dev/peps/pep-0588/
>

And to be very clear here, PEP 588 is *not* accepted yet, so it's open for
changes.

I personally would consider the accepting of PEP 581 as a signal that the
SC thinks it's worth putting the effort into migrating to GitHub for issues
and so now we can focus our efforts as a team in trying to make this result
in the workflow that we want.

And I suspect everyone knows this, but just in case, I want to personally
state that I hope everyone understands that there is no way everyone will
be happy with the outcome of this transition and that's okay. :) Workflow
is one of those things where people are very often opinionated (just look
at all of us and our preference in programming language ;) . Obviously we
can all do what we can to be accommodating and come up with a solution that
works for as many people as possible (including external folks like
triagers and issue reporters), but I hope everyone goes into this being as
understanding as possible so we can try to get the best outcome we can.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

[Victor Stinner]

Le mer. 15 mai 2019 à 11:31, Christian Heimes  a écrit :
> What are the next step? Will there be another PEP that explores how we
> are going to deal with migration, workflow changes, and how we plan to
> map current BPO features to Github?

Yes, it's the:

PEP 588 -- GitHub Issues Migration Plan
https://www.python.org/dev/peps/pep-0588/

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

[Paul Moore]

On Wed, 15 May 2019 at 09:51, Antoine Pitrou  wrote:
>
> On Tue, 14 May 2019 18:11:14 -0700
> Barry Warsaw  wrote:
>
> > As the BDFL-Delegate for PEP 581, and with the unanimous backing of the 
> > rest of the Steering Council, I hereby Accept this PEP.
>
> For future reference, is it possible to post the Steering Council's
> reflection and rationale on the PEP?

Also, is there an archive of the discussions anywhere? The PEP says
discussions happened on Zulip, but I don't follow that and I don't
know where I can find an archived copy of the discussions.

It's not as if I'm going to object to the PEP (I'd have participated
in the discussions if I had a strong opinion) but I am curious.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

[Christian Heimes]

On 15/05/2019 10.55, Ivan Pozdeev via Python-Dev wrote:
> On 15.05.2019 11:48, Antoine Pitrou wrote:
>> On Tue, 14 May 2019 18:11:14 -0700
>> Barry Warsaw  wrote:
>>
>>> As the BDFL-Delegate for PEP 581, and with the unanimous backing of
>>> the rest of the Steering Council, I hereby Accept this PEP.
>> For future reference, is it possible to post the Steering Council's
>> reflection and rationale on the PEP?
> +1. Specifically, I'd like to know if the risks and the potential for
> GitHub missing any needed features were estimated. The PEP says nothing
> about this.

I'm not happy with the fact, that the PEP does not mention any arguments
or concerns that were raised against the current feature set of Github's
issue tracker. In the past, PEPs also listed risks and arguments against
a change, then weighted the arguments.

What are the next step? Will there be another PEP that explores how we
are going to deal with migration, workflow changes, and how we plan to
map current BPO features to Github?

Christian
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

[Ivan Pozdeev via Python-Dev]

On 15.05.2019 11:48, Antoine Pitrou wrote:

On Tue, 14 May 2019 18:11:14 -0700
Barry Warsaw  wrote:


As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest of 
the Steering Council, I hereby Accept this PEP.

For future reference, is it possible to post the Steering Council's
reflection and rationale on the PEP?
+1. Specifically, I'd like to know if the risks and the potential for GitHub missing any needed features were estimated. The PEP says 
nothing about this.

Thank you

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru


--
Regards,
Ivan

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

[Antoine Pitrou]

On Tue, 14 May 2019 18:11:14 -0700
Barry Warsaw  wrote:

> As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest 
> of the Steering Council, I hereby Accept this PEP.

For future reference, is it possible to post the Steering Council's
reflection and rationale on the PEP?

Thank you

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

[Antoine Pitrou]

On Wed, 15 May 2019 08:40:58 +0100
Steve Holden  wrote:
> As a mere user I'd like to thank the developer team for biting this bullet.
> Remembering the transition to Git I am sure that the further
> democratisation (?) of the development process will similarly increase the
> diversity and scope of the development effort.

"Similarly"?

We still lack some metrics on that point, IIRC.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

[Steve Holden]

As a mere user I'd like to thank the developer team for biting this bullet.
Remembering the transition to Git I am sure that the further
democratisation (?) of the development process will similarly increase the
diversity and scope of the development effort.

It will indeed be a significant effort to effect this migration. While it's
inevitable this will involve significant dev time, perhaps there roles can
be identified specifically as to be filled by _other_ than core devs.


On Wed, May 15, 2019 at 2:43 AM Victor Stinner  wrote:

> Congrats Mariatta :-)
>
> Victor
>
> Le mer. 15 mai 2019 à 03:14, Barry Warsaw  a écrit :
> >
> > As the BDFL-Delegate for PEP 581, and with the unanimous backing of the
> rest of the Steering Council, I hereby Accept this PEP.
> >
> > We would like to thank Mariatta for championing PEP 581, and to all the
> contributors to the discussion, both pro and con.  We appreciate your
> candor and respect for your fellow developers.  The SC believes that this
> migration is in the best interest of the Python community, and we look
> forward to the elaboration of the detailed migration plan (PEP 588).
> >
> > We also extend our heartfelt thanks Berker, Ezio, and everyone who has
> helped develop and maintain Roundup and bugs.python.org over the years.
> bpo has been a critical component for Python development for a very long
> time, and we all greatly appreciate the time, effort, and devotion you have
> put into this resource.
> >
> > https://www.python.org/dev/peps/pep-0581/
> >
> > Onward we go!  The migration will be a large effort, with much planning,
> development, and testing, and we welcome volunteers who wish to help make
> it a reality.  I look forward to your contributions on PEP 588 and the
> actual work of migrating issues to GitHub.
> >
> > Cheers,
> > -Barry (BDFL-Delegate, and on behalf of the Python Steering Council)
> >
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com
>
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/steve%40holdenweb.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

[Victor Stinner]

Congrats Mariatta :-)

Victor

Le mer. 15 mai 2019 à 03:14, Barry Warsaw  a écrit :
>
> As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest 
> of the Steering Council, I hereby Accept this PEP.
>
> We would like to thank Mariatta for championing PEP 581, and to all the 
> contributors to the discussion, both pro and con.  We appreciate your candor 
> and respect for your fellow developers.  The SC believes that this migration 
> is in the best interest of the Python community, and we look forward to the 
> elaboration of the detailed migration plan (PEP 588).
>
> We also extend our heartfelt thanks Berker, Ezio, and everyone who has helped 
> develop and maintain Roundup and bugs.python.org over the years.  bpo has 
> been a critical component for Python development for a very long time, and we 
> all greatly appreciate the time, effort, and devotion you have put into this 
> resource.
>
> https://www.python.org/dev/peps/pep-0581/
>
> Onward we go!  The migration will be a large effort, with much planning, 
> development, and testing, and we welcome volunteers who wish to help make it 
> a reality.  I look forward to your contributions on PEP 588 and the actual 
> work of migrating issues to GitHub.
>
> Cheers,
> -Barry (BDFL-Delegate, and on behalf of the Python Steering Council)
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

[Barry Warsaw]

As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest of 
the Steering Council, I hereby Accept this PEP.

We would like to thank Mariatta for championing PEP 581, and to all the 
contributors to the discussion, both pro and con.  We appreciate your candor 
and respect for your fellow developers.  The SC believes that this migration is 
in the best interest of the Python community, and we look forward to the 
elaboration of the detailed migration plan (PEP 588).

We also extend our heartfelt thanks Berker, Ezio, and everyone who has helped 
develop and maintain Roundup and bugs.python.org over the years.  bpo has been 
a critical component for Python development for a very long time, and we all 
greatly appreciate the time, effort, and devotion you have put into this 
resource.

https://www.python.org/dev/peps/pep-0581/

Onward we go!  The migration will be a large effort, with much planning, 
development, and testing, and we welcome volunteers who wish to help make it a 
reality.  I look forward to your contributions on PEP 588 and the actual work 
of migrating issues to GitHub.

Cheers,
-Barry (BDFL-Delegate, and on behalf of the Python Steering Council)



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

[Nick Coghlan]

On Fri, 8 Mar 2019 at 16:52, Karthikeyan  wrote:
> Personally, I think more people will love it once they get to use it so if 
> something like 100 issues can be migrated to a sample repo with labels, 
> content etc.

We're already using GitHub issues for pretty much everything in Python
core development that *isn't* CPython itself, and even for CPython,
folks experience the core issue management interface in the overview
page for pull requests.

One of the requests we made at the Language Summit discussion last
year was for Mariatta to enhance PEP 581 with additional discussion of
what would need to change to bring the Roundup instance up to the
point of being competitive with the GitHub issues user experience,
which she added:

* https://www.python.org/dev/peps/pep-0581/#issues-with-roundup-bpo
* 
https://www.python.org/dev/peps/pep-0581/#why-not-focus-on-improving-roundup-bpo

There's been plenty of time since then for folks to put forward a
competing proposal to modernise the Roundup UI directly instead of
migrating to a different issue tracking tool, but so far no such
proposal has emerged.

One of the other blockers was the fact that the Contributor Licensing
Agreement process was tightly coupled to some custom fields in b.p.o
[1], and that is now very close to being resolved thanks to Mariatta's
efforts (and provides a nice workflow improvement in its own right).

Cheers,
Nick.

[1] https://www.python.org/dev/peps/pep-0581/#update-the-cla-host

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

[Karthikeyan]

On Fri, Mar 8, 2019 at 12:41 AM Mariatta  wrote:

> I'd like to formally present to Python-dev PEP 581: Using GitHub Issues
> for CPython
>
> Full text: https://www.python.org/dev/peps/pep-0581/
>
>
Thanks a lot for doing this!

* The current bug tracker has low contributions and moving to a place like
GitHub would open up to a lot of opportunities like integrations, webhooks
where people can build custom workflow etc. along with reducing the
maintenance burden on the team.
* GitHub also allows markdown and syntax highlighting on code snippets
would be much easier to read compared to current tracker. In some cases
GitHub can even inline the code for a permalink to a single line which adds
more context. Also support for editing comments to fix minor typos links
are great. Emoji support :)
* The current bpo search is surprisingly very effective though it just does
substring search across comments and patches I believe. If not I can google
keywords with site:bugs.python.org to get relevant results. I expect search
to be better on GitHub but worth experimenting since searching to get
related issues/discussion helps a lot in triaging.

Some points worth considering and some of them are addressed in the PEP
already.

* Moving to GitHub also comes at a cost of accessibility where there might
be people posting questions that are more suitable for stackoverflow,
python-list etc. Thus there might be more incoming issues that would
require more effort on triaging.
* There could be explicit guidelines on when a triager should close an
issue and current bpo supports custom fields for resolution, state of the
issue (open/close/pending/needs-test/patch-review)  that are updated.
Besides closing the issue there could be labels or a comment format to
describe the rationale and resolution.
* There could also be guidelines on when to lock the thread since there
could be cases where security issues or issues that can trigger heated
arguments are posted. It could get even more attention when it's posted on
Reddit or hackernews attracting unwanted attention e.g. security issues in
npm posted to reddit. Someone can chime in to lock it but guidelines on
when to do this would be helpful so that decision is not based on personal
opinion to lock it.
* Extended discussions in some cases along with no proper support for
threading could result in lot of duplicated messages that would be hard to
scroll through. It's a problem with current tracker too but something that
can come up where people will use +1 comments instead of using thumbs up
emoji. Rust community had some similar concerns since they do RFC
discussions on GitHub that result in 200+ comments. Though we don't do PEP
discussions some bugs can result in this.
* I wish python-bug-list, weekly summary continues to be integrated with
GitHub too since some of us don't want to watch the repo to get all the
activity along with pull requests and just want to track activity on issues.
* Currently there is some link rot on bpo for svn related links, broken
patch file links etc. Moving to GitHub I guess they are handled like magic
links for PEPs, bpo-, etc. that are mentioned in the PEP 581.

Personally, I think more people will love it once they get to use it so if
something like 100 issues can be migrated to a sample repo with labels,
content etc. As a shameless plug I tried migrating around 150 issues in
current bpo to GitLab sometime back with components as labels. Though an
apple to oranges comparison (GitLab UI vs GitHub UI) I personally find the
UI (also GitHub UI) very easy to navigate in terms of clicking on labels,
search, sort, filter etc. in https://gitlab.com/tirkarthi/python-bugs/issues
and the issue is more easy to read with markdown support for code where I
added highlight to snippet
https://gitlab.com/tirkarthi/python-bugs/issues/140

-- 
Regards,
Karthikeyan S
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

[Brett Cannon]

I'll start by saying I don't think a history lesson is important for this
PEP. This is simply a matter of evaluating whether Roundup or GitHub issues
is better for us and in the future. There's no real mistakes to watch out
for or anything (and if there is it's that self-hosting has a cost ;) .

On Thu, Mar 7, 2019 at 3:38 PM Barry Warsaw  wrote:

> On Mar 7, 2019, at 14:36, Mariatta  wrote:
>
> > I was not involved in core Python development back then, so if it is
> really important and if people think such paragraph needs to be part of the
> PEP, then perhaps someone else more knowledgeable will need to help with
> this.
> >
> > Personally, I don't think it was a horrible mistake. I believe the core
> devs back then carefully considered all options and decided that
> bpo/roundup was the way to go. And I really don't want to give that
> impression to the readers of this PEP that "I" or "core devs" now think it
> was a horrible mistake. If there is specific parts of the PEP that gives
> people that impression, then I'd definitely want to work and improve that.
>
> I did a little bit of archive archeology (always a frightening and
> humbling black hole spelunking expedition), and here’s a brief history
> AFAICT.  Dates are approximate.
>
> 5/2000 - we move all development (CVS at the time, and bug tracking) to
> SourceForge.  This roughly coincided with PythonLabs leaving CNRI, so
> clearly we couldn’t continue running infra off of their systems.
>
> 10/2005 - we move to Subversion
>
> 9/2006 - we begin to discuss moving off of the SF bug tracker.  I believe
> that Thomas Wouters, Martin von Loewis, Brett Cannon (big surprise! :), and
> myself were involved in that effort, with Richard Jones (original author of
> Roundup) recusing himself.  The candidates were Roundup, Trac, Jira, and
> Launchpad.  I think Brett did the first round of feature reviews and
> comparisons.  David Goodger was also involved.  We did want it to be
> written in Python and we preferred running it on python.org infra, but
> neither of these were required criteria.
>

This was actually my first infrastructure project and how I ended up on the
PSF board and the head of the infrastructure group. :)


>
> Jira and Roundup made the first cuts, with Launchpad and Trac being
> discarded as “having issues” (I don’t have access in memory or emails to
> any of those details).  Jira was deemed pretty complex, but Atlassian
> offered hosting.  Roundup was “not as polished" back then, but that wasn’t
> necessarily a negative.  It was easy to use and host, and had a
> complimentary feature set, but we felt like we needed volunteers to help us
> keep it going.  Richard Jones of course did fantastic work on the software
> itself, and we did manage to, um, round up enough volunteers to make it a
> viable choice.
>
> 10/2006 - the decision was made to move to Roundup, and we decided to
> accept Upfront’s offer to host the instance.


You're missing the step of "the decision was made to move to Jira and
people flipped out." :) We actually said Jira was our choice unless enough
people came forward to volunteer to help support us using Roundup. In the
end enough people did step forward and people didn't like us using Java and
a closed-source solution, so we went with Roundup (this is when RMS got
involved and asked us to reconsider; this is also when I learned that
volunteers saying they will help with something doesn't mean they actually
will, especially when they have no established reputation ;) .

The original announcement can be found at
https://mail.python.org/pipermail/python-dev/2006-October/069139.html.

-Brett


> 3/2007 - new-bugs-announce was created and notifications of new bugs was
> redirected to that mailing list.
>
> I’ll disappear down that archive rabbit hole now, which in some cases goes
> back to 1995.  There are so many fun and scary paths to explore.  See you
> in 6 months.
>
> jeremy-is-salty-ly y’rs,
> -Barry
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

[Barry Warsaw]

On Mar 7, 2019, at 14:36, Mariatta  wrote:

> I was not involved in core Python development back then, so if it is really 
> important and if people think such paragraph needs to be part of the PEP, 
> then perhaps someone else more knowledgeable will need to help with this.
> 
> Personally, I don't think it was a horrible mistake. I believe the core devs 
> back then carefully considered all options and decided that bpo/roundup was 
> the way to go. And I really don't want to give that impression to the readers 
> of this PEP that "I" or "core devs" now think it was a horrible mistake. If 
> there is specific parts of the PEP that gives people that impression, then 
> I'd definitely want to work and improve that.

I did a little bit of archive archeology (always a frightening and humbling 
black hole spelunking expedition), and here’s a brief history AFAICT.  Dates 
are approximate.

5/2000 - we move all development (CVS at the time, and bug tracking) to 
SourceForge.  This roughly coincided with PythonLabs leaving CNRI, so clearly 
we couldn’t continue running infra off of their systems.

10/2005 - we move to Subversion

9/2006 - we begin to discuss moving off of the SF bug tracker.  I believe that 
Thomas Wouters, Martin von Loewis, Brett Cannon (big surprise! :), and myself 
were involved in that effort, with Richard Jones (original author of Roundup) 
recusing himself.  The candidates were Roundup, Trac, Jira, and Launchpad.  I 
think Brett did the first round of feature reviews and comparisons.  David 
Goodger was also involved.  We did want it to be written in Python and we 
preferred running it on python.org infra, but neither of these were required 
criteria.

Jira and Roundup made the first cuts, with Launchpad and Trac being discarded 
as “having issues” (I don’t have access in memory or emails to any of those 
details).  Jira was deemed pretty complex, but Atlassian offered hosting.  
Roundup was “not as polished" back then, but that wasn’t necessarily a 
negative.  It was easy to use and host, and had a complimentary feature set, 
but we felt like we needed volunteers to help us keep it going.  Richard Jones 
of course did fantastic work on the software itself, and we did manage to, um, 
round up enough volunteers to make it a viable choice.

10/2006 - the decision was made to move to Roundup, and we decided to accept 
Upfront’s offer to host the instance.

3/2007 - new-bugs-announce was created and notifications of new bugs was 
redirected to that mailing list.

I’ll disappear down that archive rabbit hole now, which in some cases goes back 
to 1995.  There are so many fun and scary paths to explore.  See you in 6 
months.

jeremy-is-salty-ly y’rs,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

[Mariatta]

I've made the PR about "not closing all issues":
https://github.com/python/peps/pull/917/files


ᐧ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

[Gregory P. Smith]

On Thu, Mar 7, 2019 at 2:12 PM Mariatta  wrote:

>
> On Thu, Mar 7, 2019 at 12:35 PM Matthew Woodcraft 
> wrote:
>
>>
>> One part of this PEP stands out to me:
>>
>> | We should not be moving all open issues to GitHub. Issues with little
>> | or no activity should just be closed. Issues with no decision made for
>> | years should just be closed.
>>
>> I strongly advise against closing bug reports just because they're old.
>>
>> I know that the Python developers value trying to be a welcoming
>> community. To many people, having a bug report that they put some effort
>> into closed for no reason other than the passage of time feels like a
>> slap in the face which stings harder than, for example, intemperate
>> words on a mailing list.
>>
>> This is even more true if there won't be an option to re-open the bug,
>> which seems to be what the PEP is saying will be the case.
>>
>> If a bug has been around for a long time and hasn't been fixed, the most
>> useful information for the bug tracker to contain is "this bug has been
>> around for a long time and it hasn't been fixed". Leaving the bug open
>> is the simplest way to achieve that.
>>
>> (I think the above only goes for issues which are actually reporting
>> bugs. Wishlist items are a different matter.)
>>
>> -M-
>>
>
>
> Thanks. A similar argument had been made by several other core devs in
> person during Language summit 2018 as well as during the drafting of PEP
> 581, that we shouldn't be closing issues blindly.
>
> I hear you (all) and I see the point. I agree that we shouldn't just be
> closing all issues. I will edit the PEP sometime later today (or later this
> weekend).
>

yay thanks! :)

*(because I fixed this SourceForge issue number era
bug https://bugs.python.org/issue1054041
 in 3.8 :)*
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

[Mariatta]

On Thu, Mar 7, 2019 at 2:02 PM Skip Montanaro 
wrote:

>  I think it would be worthwhile to mention a couple
> reasons, when the decision was made to use Roundup, etc. Without it, a
> casual reader might think the core devs made a horrible mistake way
> back when, and are only now getting around to correcting it.
>

I was not involved in core Python development back then, so if it is really
important and if people think such paragraph needs to be part of the PEP,
then perhaps someone else more knowledgeable will need to help with this.

Personally, I don't think it was a horrible mistake. I believe the core
devs back then carefully considered all options and decided that
bpo/roundup was the way to go. And I really don't want to give that
impression to the readers of this PEP that "I" or "core devs" now think it
was a horrible mistake. If there is specific parts of the PEP that gives
people that impression, then I'd definitely want to work and improve that.

ᐧ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

[Mariatta]

On Thu, Mar 7, 2019 at 12:36 PM Manuel Cerón  wrote:

>
> After some frustration with bpo, I decided to file some issues into the
> meta tracker, just to find out that the link [1] provided by the Python
> Developer's Guide [2] is broken, giving a connection timeout.
>
>
Sometime ago we've started experimenting moving the meta tracker to GitHub.
https://github.com/python/bugs.python.org I don't know whether this is now
the "official" place for it, but I've definitely been referring people to
this repo if they need to file issue about bpo.

Again I don't know if this is now official or not, and should we start
updating all documentations accordingly?

ᐧ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

[Mariatta]

On Thu, Mar 7, 2019 at 12:35 PM Matthew Woodcraft 
wrote:

>
> One part of this PEP stands out to me:
>
> | We should not be moving all open issues to GitHub. Issues with little
> | or no activity should just be closed. Issues with no decision made for
> | years should just be closed.
>
> I strongly advise against closing bug reports just because they're old.
>
> I know that the Python developers value trying to be a welcoming
> community. To many people, having a bug report that they put some effort
> into closed for no reason other than the passage of time feels like a
> slap in the face which stings harder than, for example, intemperate
> words on a mailing list.
>
> This is even more true if there won't be an option to re-open the bug,
> which seems to be what the PEP is saying will be the case.
>
> If a bug has been around for a long time and hasn't been fixed, the most
> useful information for the bug tracker to contain is "this bug has been
> around for a long time and it hasn't been fixed". Leaving the bug open
> is the simplest way to achieve that.
>
> (I think the above only goes for issues which are actually reporting
> bugs. Wishlist items are a different matter.)
>
> -M-
>


Thanks. A similar argument had been made by several other core devs in
person during Language summit 2018 as well as during the drafting of PEP
581, that we shouldn't be closing issues blindly.

I hear you (all) and I see the point. I agree that we shouldn't just be
closing all issues. I will edit the PEP sometime later today (or later this
weekend).


ᐧ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

[Skip Montanaro]

> I'd like to formally present to Python-dev PEP 581: Using GitHub Issues for 
> CPython
>
> Full text: https://www.python.org/dev/peps/pep-0581/

Thanks for doing this. I think there is a pretty strong argument to be
made that mature, widely adopted systems like GitHub (or GitLab or
Bitbucket) should be used where possible. One thing I didn't notice
was any sort of explanation about how CPython wound up on Roundup to
begin with. I think it would be worthwhile to mention a couple
reasons, when the decision was made to use Roundup, etc. Without it, a
casual reader might think the core devs made a horrible mistake way
back when, and are only now getting around to correcting it. I don't
recall when Roundup was adopted, but it was quite awhile ago, and the
issue tracker universe was a much different place. Here are a couple
things I recall (perhaps incorrectly). It's been awhile, but for the
digital spelunkers, I'm sure it's all in an email archive somewhere.
(I didn't find a PEP. Did that decision predate PEPs?)

* Back in the olden days, basically every candidate issue tracker
required modification to make it suitable for a particular project. I
don't rightly recall if Roundup was deemed easier to modify or if
there were just people willing to step up and make the necessary
changes.

* There was a desire to eat your own dog food, and I believe Roundup
is/was written in Python. That would be much less important today.
Plenty of people already eat Python brand Dog Food.™

Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

[Matthew Woodcraft]

On 07/03/2019 19.08, Mariatta wrote:

I'd like to formally present to Python-dev PEP 581: Using GitHub Issues
for CPython

Full text: https://www.python.org/dev/peps/pep-0581/

This is my first PEP, and in my opinion it is ready for wider
discussion.


One part of this PEP stands out to me:

| We should not be moving all open issues to GitHub. Issues with little
| or no activity should just be closed. Issues with no decision made for
| years should just be closed.

I strongly advise against closing bug reports just because they're old.

I know that the Python developers value trying to be a welcoming
community. To many people, having a bug report that they put some effort
into closed for no reason other than the passage of time feels like a
slap in the face which stings harder than, for example, intemperate
words on a mailing list.

This is even more true if there won't be an option to re-open the bug,
which seems to be what the PEP is saying will be the case.

If a bug has been around for a long time and hasn't been fixed, the most
useful information for the bug tracker to contain is "this bug has been
around for a long time and it hasn't been fixed". Leaving the bug open
is the simplest way to achieve that.

(I think the above only goes for issues which are actually reporting
bugs. Wishlist items are a different matter.)

-M-


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 581: Using GitHub Issues for CPython

[Mariatta]

I'd like to formally present to Python-dev PEP 581: Using GitHub Issues for
CPython

Full text: https://www.python.org/dev/peps/pep-0581/

This is my first PEP, and in my opinion it is ready for wider discussion. I
don't know if it is "ready for pronouncement" so I'm hoping to get more
guidance about it from other experienced core devs and steering council.

I also plan to open discussion about PEP 581 at Python Language Summit, and
since I'm one-half of the language summit chairs, it is quite likely this
discussion will happen.

On that note, you can still sign up for the language summit here:
https://us.pycon.org/2019/events/language-summit/

Note that unlike previous years, you do not need to be invited by a core
developer. Łukasz and I will be curating the content, and we want to
include more diverse perspectives into language summit discussions.

Thanks.

ᐧ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com