[python-committers] Paul Ganssle got the bug triage permission

2019-02-14 Thread Victor Stinner 
Hi,

Paul Ganssle just asked me to close a bug which he fixed. Instead, I
just gave him the bug triage permission :-)

Paul is the author of dateutil:
https://github.com/dateutil/dateutil

He is fixing more and more datetime issues for longer than 1 year,
including some tricky and very old issues:
https://github.com/python/cpython/commits?author=pganssle

For example, he implemented .fromisoformat() which was a long awaited feature:
https://docs.python.org/dev/library/datetime.html#datetime.date.fromisoformat

Recently, he got the approval to change how datetime subclasses are
handled, feature very useful for third-party libraries written on top
of datetime:
https://github.com/python/cpython/commit/89427cd0feae25bbc8693abdccfa6a8c81a2689c

I'm happy to see him helping Alexander Belopopsky (current datetime
maintainer), on maintaining datime, who is more busy these days. By
the way, they met each other ;-)

I sent Paul instructions how to triage bug and links into the devguide.
I asked him to ask me before closing a bug.

Congrats Paul ;-)

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Paul Ganssle got the bug triage permission

2019-02-14 Thread Victor Stinner 
Le jeu. 14 févr. 2019 à 17:27, Victor Stinner  a écrit :
> Paul is the author of dateutil:
> https://github.com/dateutil/dateutil

Correction: Gustavo Niemeyer is the dateutil original author, Paul is
the current maintainer.

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

Re: [python-committers] Paul Ganssle got the bug triage permission

2019-02-14 Thread Carol Willing 
Welcome Paul :D

Looking forward to working with you more.

> On Feb 14, 2019, at 8:27 AM, Victor Stinner  wrote:
> 
> Hi,
> 
> Paul Ganssle just asked me to close a bug which he fixed. Instead, I
> just gave him the bug triage permission :-)
> 
> Paul is the author of dateutil:
> https://github.com/dateutil/dateutil
> 
> He is fixing more and more datetime issues for longer than 1 year,
> including some tricky and very old issues:
> https://github.com/python/cpython/commits?author=pganssle
> 
> For example, he implemented .fromisoformat() which was a long awaited feature:
> https://docs.python.org/dev/library/datetime.html#datetime.date.fromisoformat
> 
> Recently, he got the approval to change how datetime subclasses are
> handled, feature very useful for third-party libraries written on top
> of datetime:
> https://github.com/python/cpython/commit/89427cd0feae25bbc8693abdccfa6a8c81a2689c
> 
> I'm happy to see him helping Alexander Belopopsky (current datetime
> maintainer), on maintaining datime, who is more busy these days. By
> the way, they met each other ;-)
> 
> I sent Paul instructions how to triage bug and links into the devguide.
> I asked him to ask me before closing a bug.
> 
> Congrats Paul ;-)
> 
> Victor
> -- 
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

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

Re: [python-committers] Paul Ganssle got the bug triage permission

2019-02-14 Thread Paul Moore 
Congratulations, Paul, and welcome. Glad to have your help!
Paul

On Thu, 14 Feb 2019 at 17:04, Carol Willing  wrote:
>
> Welcome Paul :D
>
> Looking forward to working with you more.
>
> > On Feb 14, 2019, at 8:27 AM, Victor Stinner  wrote:
> >
> > Hi,
> >
> > Paul Ganssle just asked me to close a bug which he fixed. Instead, I
> > just gave him the bug triage permission :-)
> >
> > Paul is the author of dateutil:
> > https://github.com/dateutil/dateutil
> >
> > He is fixing more and more datetime issues for longer than 1 year,
> > including some tricky and very old issues:
> > https://github.com/python/cpython/commits?author=pganssle
> >
> > For example, he implemented .fromisoformat() which was a long awaited 
> > feature:
> > https://docs.python.org/dev/library/datetime.html#datetime.date.fromisoformat
> >
> > Recently, he got the approval to change how datetime subclasses are
> > handled, feature very useful for third-party libraries written on top
> > of datetime:
> > https://github.com/python/cpython/commit/89427cd0feae25bbc8693abdccfa6a8c81a2689c
> >
> > I'm happy to see him helping Alexander Belopopsky (current datetime
> > maintainer), on maintaining datime, who is more busy these days. By
> > the way, they met each other ;-)
> >
> > I sent Paul instructions how to triage bug and links into the devguide.
> > I asked him to ask me before closing a bug.
> >
> > Congrats Paul ;-)
> >
> > Victor
> > --
> > Night gathers, and now my watch begins. It shall not end until my death.
> > ___
> > python-committers mailing list
> > [email protected]
> > https://mail.python.org/mailman/listinfo/python-committers
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Can we choose between mailing list and discuss.python.org?

2019-02-14 Thread Brett Cannon 
On Wed, Feb 13, 2019 at 12:17 PM Paul Moore  wrote:

> On Wed, 13 Feb 2019 at 19:56, Steve Dower  wrote:
> >
> > On 13Feb2019 1112, Brett Cannon wrote:
> > >
> > >
> > > On Wed, Feb 13, 2019 at 2:55 AM Paul Moore  > > > wrote:
> > >
> > > On Tue, 12 Feb 2019 at 22:00, Antoine Pitrou  > > > wrote:
> > >  > Here is a 161-message Discourse thread (at the time of this
> writing):
> > >  > https://discuss.python.org/t/pep-517-backend-bootstrapping/789
> > >
> > > As someone directly involved in that discussion, with a strong
> need to
> > > understand all of the points being made, that's a great example of
> > > both the benefits and the flaws of the discourse model.
> > >
> > >
> > > Can I ask if that entire thread is on topic, or is there a reasonable
> > > point in that discussion where side conversations could have been
> broken
> > > off into a separate topic(s)? When email threads tend to reach that
> > > length there have been side discussions that could have become their
> own
> > > topic if someone thought to change the subject and Discourse allows for
> > > having an admin break posts off at any point and I'm curious if it
> would
> > > have been helpful and people simply didn't think about it (I know I
> > > don't always think of it immediately yet).
> >
> > My feeling (as I followed the entire discussion from the start) is that
> > the side discussions all tied back, rather than diverging permanently.
> > So at best it would be "you 2-3 go and discuss this part separately and
> > come back when you agree", which as we know is often followed up by "you
> > other 2-3 re-discuss everything they already discussed since you weren't
> > part of the side discussion".
>
> Precisely this. I don't know *how* I would have split off a separate
> sub-thread in Discourse if needed (it's easy enough in email by
> changing the subject, I presume it's not much harder in Discourse?)
>

Nope, it's not hard. The process is:

   1. An admin notices/is asked to split a topic that has diverged
   2. The admin clicks the wrench icon and chooses to Select Posts
   3. You select posts either manually, post + all following, or post + all
   replies
   4. You then have the option to create a new topic for the selected
   posts, specifying category, title, labels, etc.

The pro to this compared to subject changing in an ML is it's retroactive.
The con is an admin needs to to it, but you can always @ mention 'admins'
-- maybe 'staff' group has the same abilities? -- to bring a thread to
their attention that needs splitting.
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Can we choose between mailing list and discuss.python.org?

2019-02-14 Thread Nathaniel Smith 
On Thu, Feb 14, 2019, 09:39 Brett Cannon 
>
> On Wed, Feb 13, 2019 at 12:17 PM Paul Moore  wrote:
>
>> On Wed, 13 Feb 2019 at 19:56, Steve Dower  wrote:
>> >
>> > On 13Feb2019 1112, Brett Cannon wrote:
>> > >
>> > >
>> > > On Wed, Feb 13, 2019 at 2:55 AM Paul Moore > > > > wrote:
>> > >
>> > > On Tue, 12 Feb 2019 at 22:00, Antoine Pitrou > > > > wrote:
>> > >  > Here is a 161-message Discourse thread (at the time of this
>> writing):
>> > >  > https://discuss.python.org/t/pep-517-backend-bootstrapping/789
>> > >
>> > > As someone directly involved in that discussion, with a strong
>> need to
>> > > understand all of the points being made, that's a great example of
>> > > both the benefits and the flaws of the discourse model.
>> > >
>> > >
>> > > Can I ask if that entire thread is on topic, or is there a reasonable
>> > > point in that discussion where side conversations could have been
>> broken
>> > > off into a separate topic(s)? When email threads tend to reach that
>> > > length there have been side discussions that could have become their
>> own
>> > > topic if someone thought to change the subject and Discourse allows
>> for
>> > > having an admin break posts off at any point and I'm curious if it
>> would
>> > > have been helpful and people simply didn't think about it (I know I
>> > > don't always think of it immediately yet).
>> >
>> > My feeling (as I followed the entire discussion from the start) is that
>> > the side discussions all tied back, rather than diverging permanently.
>> > So at best it would be "you 2-3 go and discuss this part separately and
>> > come back when you agree", which as we know is often followed up by "you
>> > other 2-3 re-discuss everything they already discussed since you weren't
>> > part of the side discussion".
>>
>> Precisely this. I don't know *how* I would have split off a separate
>> sub-thread in Discourse if needed (it's easy enough in email by
>> changing the subject, I presume it's not much harder in Discourse?)
>>
>
> Nope, it's not hard. The process is:
>
>1. An admin notices/is asked to split a topic that has diverged
>2. The admin clicks the wrench icon and chooses to Select Posts
>3. You select posts either manually, post + all following, or post +
>all replies
>4. You then have the option to create a new topic for the selected
>posts, specifying category, title, labels, etc.
>
> The pro to this compared to subject changing in an ML is it's retroactive.
> The con is an admin needs to to it, but you can always @ mention 'admins'
> -- maybe 'staff' group has the same abilities? -- to bring a thread to
> their attention that needs splitting.
>

Apparently you don't actually need an admin to do this – any user with
"trust level 4" can do it:
https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/

That includes admins and moderators, but we can also promote as many people
as we want to that level, and they don't have to sign up for moderator work
or count against our staff account cap.

-n

>
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Proposed dates for Python 3.4.10 and Python 3.5.7

2019-02-14 Thread Larry Hastings 


Howdy howdy!  It's time to make the next bugfix release of 3.5--and the 
/final/ release /ever/ of Python 3.4. Here's the schedule I propose:


   3.4.10rc1 and 3.5.7rc1 - Saturday March 2 2019
   3.4.10 final and 3.5.7 final - Saturday March 16 2019


What's going in these releases?  Not much.  I have two outstanding PRs 
against 3.5:


   bpo-33127 GH-10994: Compatibility patch for LibreSSL 2.7.0
   bpo-34623 GH-9933: XML_SetHashSalt in _elementtree

and one PR against 3.4:

   bpo-34623 GH-9953: Use XML_SetHashSalt in _elementtree

I expect to merge all three of those, I just need to get around to it.  
There's one more recent security fix (bpo-35746, GH-11569) that  I want 
in these releases that still needs backporting.



And that's the entire list.  bpo-34623 is the only current release 
blocker for either 3.4 or 3.5--I'm not aware of anything else in the 
pipeline.  If you have anything you think needs to go into the next 3.5, 
or the final 3.4, and it's /not/ listed above, please either file a 
GitHub PR, file a release-blocker bug on bpo, or email me directly.



Good night sweet Python 3.4, and flights of angels sing thee to thy rest!


//arry/

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