Re: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

[Ned Deily]

On May 23, 2018, at 09:13, Ned Deily  wrote:
> On May 23, 2018, at 07:45, Serhiy Storchaka  wrote:
>> Is it possible to add yet one beta instead?
>> CI was broken for few latest days, tests are not passed on my computer still 
>> (and fail on some buildbots), updating What's New exposed new features which 
>> need additional testing (and maybe fixing or reverting), and I'm not 
>> comfortable about some changes which would be harder to fix after the 
>> release.
> it is possible but there's no point in doing either another beta or a release 
> candidate until we understand and address the current blocking issues, like 
> the major buildbot failures.  We have another 24 hours until rc1 was planned 
> to be tagged.  Let's keep working on the known issues and we will make a 
> decision then.

An update: thanks to a lot of effort over the past day by a number of
people (including Victor, Serhiy, Christian, Zach, and others I'm sure
I'm forgetting - my apologies), we have addressed all of the "release
blocker" issues and all but one of the persistent failures on the 3.7
stable buildbots. We should have the couple of remaining "deferred
blockers" including the remaining stable buildbots in green status by
later today. At that point, we will be ready to tag 3.7.0rc1 and begin
producing the release candidate artifacts.

So this *is* really your last chance: if you know of any true releasing
blocking issues for 3.7.0, you have about 12 more hours to log it in
the bug tracker as a "release blocker". I'll send out an email once we
start the release manufacturing. Any merges to the 3.7 branch after
that will be released in 3.7.1 which we tentatively are planning to
ship sometime before the end of July (< 2018-07-31). If you do find a
critical problem in 3.7.0rc1 that you think needs to be fixed in 3.7.0,
please merge a fix into 3.7 (and other appropriate branches), leave the
issue open and marked as "release blocker", and add a note why you
think the fix needs to be cherry-picked into 3.7.0.

More later today!

--Ned

P.S. To address a few of the earlier comments on this thread:

Antoine: > Also there's https://bugs.python.org/issue33612 which
appears quite critical.

Resolved

Victor: > Can someone please have a look at my socketserver change?

Reviewed and merged

Victor: > I looked at buildbots and I confirm that many of the 3.x
buildbots are red:

Yes, but it's the 3.7 buildbots that are of interest now, not the 3.x
ones :) And, as noted above, I believe we have cleaned up (or will
shortly) the remaining 3.7 stable buildbot failures. Coincidentally,
we've also fixed some of the 3.x (master -> 3.8) buildbots.

Victor: > Ah, Python doesn't compile on Windows anymore :-)

Stale files on one of the Windows buildbots -> cleaned up

--
  Ned Deily
  n...@python.org -- []

___
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] [Python-Dev] FINAL WEEK FOR 3.7.0 CHANGES!

[Ned Deily]

On May 24, 2018, at 07:26, Victor Stinner  wrote:
> 2018-05-24 9:23 GMT+02:00 Ned Deily :
>> Any merges to the 3.7 branch after
>> that will be released in 3.7.1 which we tentatively are planning to
>> ship sometime before the end of July (< 2018-07-31).
> I recall that Python 3.6.0 was full of bugs, some functions like
> os.waitpid() on Windows (if I recall correctly) were completely
> broken.
> 
> We can do our best to test as much as possible, hope that more and
> more people use the "nightly" Python version to run their CI, but we
> always miss bugs. We always get the most testers when the final x.y.0
> version is released.
> 
> Why waiting two months to release bugfixes?

We're not planning on waiting two months.  First, 3.7.0 final is not
planned to release until 2018-06-15; if necessary, there could be one
or more emergency bug fixes in it.  Second, "before the end of July
(< 2018-07-31)" does not mean we have to wait until the end of July.
If necessary, it could be near the beginning of the month,
so closer to two weeks after the release.  Right now, our focus
should be on getting high-quality 3.7.0rc1 and 3.7.0 final releases
out there to our users and then we can focus on what comes next.

Getting close!

--
  Ned Deily
  n...@python.org -- []

___
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] FINAL WEEK FOR 3.7.0 CHANGES!

[Serhiy Storchaka]

24.05.18 10:23, Ned Deily пише:

So this *is* really your last chance: if you know of any true releasing
blocking issues for 3.7.0, you have about 12 more hours to log it in
the bug tracker as a "release blocker". I'll send out an email once we
start the release manufacturing. Any merges to the 3.7 branch after
that will be released in 3.7.1 which we tentatively are planning to
ship sometime before the end of July (< 2018-07-31). If you do find a
critical problem in 3.7.0rc1 that you think needs to be fixed in 3.7.0,
please merge a fix into 3.7 (and other appropriate branches), leave the
issue open and marked as "release blocker", and add a note why you
think the fix needs to be cherry-picked into 3.7.0.


I have doubts about two issues. I feel the responsibility for them 
because I had the opportunity to solve them before, but I lost it.


1. Changes in the AST. Few third-party projects was broken by it and 
already are fixed. I suppose yet few projects will be changed after 3.7 
be released. It is interesting that IPython was broken in different way 
than other projects. It was needed to reintroduce the docstring in the 
list of statements, effectively reverting the 3.7 change. IPython allows 
to enter several statements at prompt, and therefore it compiles them 
with the 'exec' mode instead of 'single' as the CPython REPL and IDLE 
shell. Currently CPython doesn't allow you to paste arbitrary script 
like the following:


if a:
    b
if c:
    d

You need to add an empty line between top-level complex statements. If 
one time CPython will add support of pasting several statements without 
empty lines between, it might need to add the same hack as IPython. I 
afraid that we might be needed to change AST again, in 3.7.1 or in 3.8.0.


2. Pickle support in typing is not perfect. I was going to fix it (I had 
almost ready code), but lost a chance of doing this before. It can be 
changed in 3.7.1, but this means that pickles of some derived typing 
types created in 3.7.0 will be not compatible with future versions (may 
be 3.7.1 will not break compatibility, but it will be broken in future 
because we will not specially supported compatibility with 3.7.0).


There is third issue, related to NetBSD, but it is less important.

I think two weeks will be enough for fixing these issues, but not at rc1 
stage.
___
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] FINAL WEEK FOR 3.7.0 CHANGES!

[Ned Deily]

On May 24, 2018, at 11:35, Serhiy Storchaka  wrote:
> I have doubts about two issues. I feel the responsibility for them because I 
> had the opportunity to solve them before, but I lost it.
[...]

Serhiy, what are the bugs.python.org issue numbers for these?  Are they marked 
as "release blocker"?

--
  Ned Deily
  n...@python.org -- []

___
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] FINAL WEEK FOR 3.7.0 CHANGES!

[Ivan Levkivskyi]

> 2. Pickle support in typing is not perfect. I was going to fix it (I had
almost ready code), but lost a chance of doing this before. It can be
changed in 3.7.1, but this means that pickles of some derived typing types
created in 3.7.0 will be not compatible with future versions (may be 3.7.1
will not break compatibility, but it will be broken in future because we
will not specially supported compatibility with 3.7.0).

I think I had fixed this one. At least the examples reported on typing
tracker are now fixed.
Do you have some other examples that still fail?

--
Ivan



On 24 May 2018 at 12:02, Ned Deily  wrote:

> On May 24, 2018, at 11:35, Serhiy Storchaka  wrote:
> > I have doubts about two issues. I feel the responsibility for them
> because I had the opportunity to solve them before, but I lost it.
> [...]
>
> Serhiy, what are the bugs.python.org issue numbers for these?  Are they
> marked as "release blocker"?
>
> --
>   Ned Deily
>   n...@python.org -- []
>
> ___
> 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] FINAL WEEK FOR 3.7.0 CHANGES!

[Serhiy Storchaka]

24.05.18 19:02, Ned Deily пише:

On May 24, 2018, at 11:35, Serhiy Storchaka  wrote:

I have doubts about two issues. I feel the responsibility for them because I 
had the opportunity to solve them before, but I lost it.

[...]

Serhiy, what are the bugs.python.org issue numbers for these?  Are they marked as 
"release blocker"?


For docstring in AST: https://bugs.python.org/issue32911

Inada's patch looked complex (actually it mostly restored the code 
before his previous change). We didn't know about IPython and we decided 
that it is not worth to change this code at this stage (after beta2). 
And definitely it will be later to do this after rc1.


For pickling of typing types: https://bugs.python.org/issue32873

Ivan fixed cases supported before 3.7. They now are backward and forward 
compatible. But cases not supported before 3.7 (like List[int]) now 
produce fragile pickles.


___
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] FINAL WEEK FOR 3.7.0 CHANGES!

[Ivan Levkivskyi]

> But cases not supported before 3.7 (like List[int]) now produce fragile
pickles.

List[int] pickled in 3.7 can't be un-pickled in 3.6, but I wouldn't worry
too much about this because it never worked in 3.6.
I remember you proposed using __getitem__ in __reduce__, but I am not sure
it is a better way, although it will fix the above problem.

I don't think this one is a blocker and we can move this discussion back to
b.p.o., unless you have some particular concerns.

The AST one however looks more serious.

--
Ivan



On 24 May 2018 at 12:26, Serhiy Storchaka  wrote:

> 24.05.18 19:02, Ned Deily пише:
>
>> On May 24, 2018, at 11:35, Serhiy Storchaka  wrote:
>>
>>> I have doubts about two issues. I feel the responsibility for them
>>> because I had the opportunity to solve them before, but I lost it.
>>>
>> [...]
>>
>> Serhiy, what are the bugs.python.org issue numbers for these?  Are they
>> marked as "release blocker"?
>>
>
> For docstring in AST: https://bugs.python.org/issue32911
>
> Inada's patch looked complex (actually it mostly restored the code before
> his previous change). We didn't know about IPython and we decided that it
> is not worth to change this code at this stage (after beta2). And
> definitely it will be later to do this after rc1.
>
> For pickling of typing types: https://bugs.python.org/issue32873
>
> Ivan fixed cases supported before 3.7. They now are backward and forward
> compatible. But cases not supported before 3.7 (like List[int]) now produce
> fragile pickles.
>
>
> ___
> 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] A different way to focus discussions

[Brett Cannon]

On Tue, 22 May 2018 at 13:10 Antoine Pitrou  wrote:

>
> Le 22/05/2018 à 22:06, Brett Cannon a écrit :
> >
> >
> > On Tue, 22 May 2018 at 12:07 Antoine Pitrou  > > wrote:
> >
> >
> > Le 22/05/2018 à 20:58, Barry Warsaw a écrit :
> > >
> > >> Thoughts? (We can dogfood this proposal too, if there's interest.
> :-)
> > >
> > > I don't know whether this will help focus rambling PEP
> > discussions.  I personally don't love the linearity of GH comments.
> > Threading is useful!
> >
> > What has become of the Discourse experiment?
> >
> >
> > A Discourse experiment was never started. If you mean Zulip it's still
> > going at python.zulipchat.com .
>
> I meant this, whatever it was: https://discuss.python.org/ :-)
>

Ah, that never went anywhere because it was just a short experiment that
the overload-sig did. If people wanted to do a serious experiment with it
then we can discuss it over on core-workflow.


>
> I don't think Zulip works for structured discussion.  I also find it
> slightly less usable than I expected.
>

Why specifically? Do you still find IRC more usable? Just trying to
understand how Discourse would be different enough to solve the issue
you're having.

-Brett


>
> 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/
>
___
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] A different way to focus discussions

[Brett Cannon]

On Tue, 22 May 2018 at 18:07 Steven D'Aprano  wrote:

> On Tue, May 22, 2018 at 05:58:39PM -0400, Donald Stufft wrote:
> >
> > > On May 22, 2018, at 5:50 PM, Victor Stinner 
> wrote:
> > >
> > > IMHO the discussions on the PEP 572 became a mess because nobody
> > > wanted to moderate the discussion. I asked on python-committers how to
> > > calm down the discussion, but no action has been taken and the flow of
> > > emails didn't stop.
> >
> > FWIW, I think this is a key thing— Mailing lists are not easily
> > moderatable.
>
> *Unmoderated* mailing lists are not easily moderated.
>
>
> > There’s no way to pause discussion, redirect, etc
>
> Does Github allow us to do these things? Not a rhetorical question.
>

Locking/pausing issues and PRs yes (both temporarily and permanently),
redirection not specifically beyond cross-referencing to another issue/PR
in a comment.

-Brett


>
>
> > besides
> > generating *more* email (and the tooling to do it is lackluster, it’s
> > pretty much just asking people to do something, and hope everyone
> > complies). Fracturing the discussion amongst multiple repos is one way
> > of handling that, another option is better tooling for moderation.
>
> It is one thing to identify a problem, another thing to state that
> something is a solution to that problem, and a completely different
> thing to actually solve the problem. How does fracturing the discussion
> help?
>
> One of the problems with PEP 372 was that the discussion was fractured
> across multiple threads on two mailing lists, leading to the same points
> being raised over and over again. (I think Chris was premature in taking
> it to Python-Dev while it was still be actively argued on Python-Ideas.)
>
> It seems to me that "fracturing the discussion amongst multiple repos"
> will have the same effect: increase the total volume, not decrease it,
> as well as increasing the chances that salient points will be missed. Am
> I wrong?
>
> As for better tooling for moderation, I asked earlier in this thread how
> moving to Github will help. What is this tooling?
>
>
> I think the problem with PEP 572 was that it was a perfect storm of a
> number of factors:
>
> - it relates to a feature simple enough that everyone has an opinion;
>
> - the statement/expression divide ("assignment is NOT an expression,
>   and that's a feature!") has been a point of distinction between
>   Python and "the competition" for 20+ years;
>
> - hence some very strong feelings;
>
> - legitimate concerns over complexity and the assign/equals bug;
>
> - bike-shedding and arguments over syntax;
>
> - distraction over unrelated proposal to change the way scoping works
>   inside classes;
>
> - lots of newcomers to the community.
>
> I count at least three discussions about this on Reddit:
>
> https://redd.it/8fpv3f
> https://redd.it/8fokpw
> https://redd.it/8ex72p
>
> Most PEPs don't get even one.
>
> Trialling Github with a simpler, less emotional and bike-sheddy PEP may
> not demonstrate how well the process works when everyone and their pet
> cat has an opinion.
>
>
>
> --
> Steve
> ___
> 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] FINAL WEEK FOR 3.7.0 CHANGES!

[Ned Deily]

On May 24, 2018, at 12:26, Serhiy Storchaka  wrote:
> 24.05.18 19:02, Ned Deily пише:
>> On May 24, 2018, at 11:35, Serhiy Storchaka  wrote:
>>> I have doubts about two issues. I feel the responsibility for them because 
>>> I had the opportunity to solve them before, but I lost it.
>> [...]
>> 
>> Serhiy, what are the bugs.python.org issue numbers for these?  Are they 
>> marked as "release blocker"?
> For docstring in AST: https://bugs.python.org/issue32911
> 
> Inada's patch looked complex (actually it mostly restored the code before his 
> previous change). We didn't know about IPython and we decided that it is not 
> worth to change this code at this stage (after beta2). And definitely it will 
> be later to do this after rc1.

We have had many discussions about this issue earlier and, while there were 
arguments made for more than one approach, I believe we reached agreement that 
this was a deliberate incompatibility that we and our users could live with.  
The issue has been closed since 2018-03-18.  At some point, we need to move on. 
 However, if additional exposure downstream has identified significant new 
problems, then the issue should be re-opened and a specific proposal made.  
BTW, do we know what the iPython folks think about this?  But there still seems 
to be disagreements about whether anything needs to be changed.  As I commented 
yesterday, I *really* don't want to keep revisiting this but I am not going to 
make a technical call.  Without an open "release blocker" issue, though, 
nothing is going to change for 3.7.0rc1.  If you (or anyone else) feels 
strongly enough about it, you should re-open the issue now and make it as a 
"release blocker" and we should discuss the implications and possible plans of 
action in the issue.

> For pickling of typing types: https://bugs.python.org/issue32873
> 
> Ivan fixed cases supported before 3.7. They now are backward and forward 
> compatible. But cases not supported before 3.7 (like List[int]) now produce 
> fragile pickles.

That issue was closed by Ivan and there have been no comments on it since 
2018-04-04.  I'll defer to his recent reply in this thread.

--
  Ned Deily
  n...@python.org -- []

___
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] A different way to focus discussions

[Brett Cannon]

On Tue, 22 May 2018 at 13:52 Barry Warsaw  wrote:

> On May 22, 2018, at 12:44, Guido van Rossum  wrote:
> >
> > Hm, what's the cost of those extra repos? As long as they have
> consistent names (e.g. pep-1234) they're easy to ignore right? Or does
> GitHub have a quota of repos per org?
>
> I think there is a quota for non-paying organizations, but I’m not sure.
> I was just thinking about clutter on https://github.com/python but maybe
> it won’t be so bad with…
>

I don't think there's a quota.

-Brett


>
> > I was thinking of a workflow where the pep author initially creates the
> repo under their own username and directs discussion there. Then when their
> PEP is accepted (or rejected!) they can donate their repo to the python
> org. I know such a thing is possible (we did it for the mypy and typeshed
> repos).
>
> … +1!
>
> > Ironically for me GitHub is less linear than email. It's easier to ask
> people to open a new issue than it is to ask them to start a new thread. So
> e.g. if a discussion starts about a survey of feature X in various
> languages, when it veers off into a tutorial for a specific language that
> could be a separate issue, and the meta-discussion on how the list of
> languages should be selected could be made another issue.
>
> I see what you’re saying.  Yes, that could work if the PEP author is
> really diligent about shunting detours into new issues.  I’ve just found
> that within PRs or issues, the linearity can be quite difficult to follow.
> (FWIW, IMHO, GitLab does better here, but that’s besides the point.)
>

You do realize you are very quickly volunteering to propose to write the
PEP for moving issues to GitLab, right? ;)


>
> > I think Mark Shannon volunteered PEP 576 (though so far he hasn't
> created a separate repo, he's just created a PR for the peps repo IIUC). I
> hope Nick will also volunteer PEP 577 for this.
>
> +1
>
> -Barry
> ___
> 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] A different way to focus discussions

[Antoine Pitrou]

Le 24/05/2018 à 18:54, Brett Cannon a écrit :
> 
> I don't think Zulip works for structured discussion.  I also find it
> slightly less usable than I expected.
> 
> Why specifically? Do you still find IRC more usable?

Um, no.  But I find Zulip's way of grouping discussions by day *then* by
topic makes things a bit confusing and not very easy to follow.  It
seems designed for people who log in every day.

> Just trying to
> understand how Discourse would be different enough to solve the issue
> you're having.

Which issue exactly?  Zulip is decent as a chat system.  It wouldn't
really work for PEP discussions, IMO.  That's why I asked about Discourse.

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/

[python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)

[Larry Hastings]

On 05/24/2018 10:08 AM, Ned Deily wrote:

If you (or anyone else) feels strongly enough about it, you should re-open the issue now 
and make it as a "release blocker" and we should discuss the implications and 
possible plans of action in the issue.


About that.  According to the Python Dev Guide:

   Whether a bug is a *release blocker* for the current release
   schedule is decided by the release manager. Triagers may recommend
   this priority and should add the release manager to the nosy list.

   https://devguide.python.org/triaging/#priority

Of course, a particular release manager (e.g. Ned here) can change the 
policy for their releases.  But by default, unless you're the release 
manager for release X, you should not mark issues as "Release Blocker" 
for release X.  This seems like a sensible policy to me, and effective 
immediately I'm going to hold to this policy for my releases (3.4 and 3.5).



//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] A different way to focus discussions

[Brett Cannon]

On Thu, 24 May 2018 at 10:45 Antoine Pitrou  wrote:

>
> Le 24/05/2018 à 18:54, Brett Cannon a écrit :
> >
> > I don't think Zulip works for structured discussion.  I also find it
> > slightly less usable than I expected.
> >
> > Why specifically? Do you still find IRC more usable?
>
> Um, no.  But I find Zulip's way of grouping discussions by day *then* by
> topic makes things a bit confusing and not very easy to follow.  It
> seems designed for people who log in every day.
>

Ah, you must be reading Zulip through "All Messages". I personally read
each topic individually by pressing "n" to navigate through each topic with
an unread message, otherwise I too lose too much context.


>
> > Just trying to
> > understand how Discourse would be different enough to solve the issue
> > you're having.
>
> Which issue exactly?  Zulip is decent as a chat system.  It wouldn't
> really work for PEP discussions, IMO.  That's why I asked about Discourse.
>

Fair enough. Would you want a PEPs section and then some naming convention
per thread to denote which PEP a thread is about?
___
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] A different way to focus discussions

[Antoine Pitrou]

Le 24/05/2018 à 20:02, Brett Cannon a écrit :
> > Just trying to
> > understand how Discourse would be different enough to solve the issue
> > you're having.
> 
> Which issue exactly?  Zulip is decent as a chat system.  It wouldn't
> really work for PEP discussions, IMO.  That's why I asked about
> Discourse.
> 
> Fair enough. Would you want a PEPs section and then some naming
> convention per thread to denote which PEP a thread is about?

That could work.  I'm not acquainted with Discourse, are there subsections?
___
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] A different way to focus discussions

[Donald Stufft]

> On May 24, 2018, at 2:05 PM, Antoine Pitrou  wrote:
> 
> 
> Le 24/05/2018 à 20:02, Brett Cannon a écrit :
>>> Just trying to
>>> understand how Discourse would be different enough to solve the issue
>>> you're having.
>> 
>>Which issue exactly?  Zulip is decent as a chat system.  It wouldn't
>>really work for PEP discussions, IMO.  That's why I asked about
>>Discourse.
>> 
>> Fair enough. Would you want a PEPs section and then some naming
>> convention per thread to denote which PEP a thread is about?
> 
> That could work.  I'm not acquainted with Discourse, are there subsections?


Yes, you can nest sections as deeply as you want, but the sections are 
typically static (I mean they can change over time, but making one per PEP 
would be a weird use of discourse).

___
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] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)

[Ned Deily]

On May 24, 2018, at 13:46, Larry Hastings  wrote:
> On 05/24/2018 10:08 AM, Ned Deily wrote:
>> If you (or anyone else) feels strongly enough about it, you should re-open 
>> the issue now and make it as a "release blocker" and we should discuss the 
>> implications and possible plans of action in the issue.
> 
> About that.  According to the Python Dev Guide:
> Whether a bug is a *release blocker* for the current release schedule is 
> decided by the release manager. Triagers may recommend this priority and 
> should add the release manager to the nosy list.
> 
> https://devguide.python.org/triaging/#priority
> Of course, a particular release manager (e.g. Ned here) can change the policy 
> for their releases.  But by default, unless you're the release manager for 
> release X, you should not mark issues as "Release Blocker" for release X.  
> This seems like a sensible policy to me, and effective immediately I'm going 
> to hold to this policy for my releases (3.4 and 3.5).

I think we're reading the same words a bit differently.  There's no question 
that the Release Manager makes the ultimate call whether an issue remains a 
"Release Blocker" or not.  But it seems to me that the safest and most reliable 
way to ensure that the Release Manager makes that decision is by having a 
triager or submitter *provisionally* set the priority to "release blocker".  It 
is then on the Release Manager's radar to accept or reject.  I think that 
policy is totally in the spirit of the Dev Guide wording but I'm fine with 
other release managers accepting differing interpretations for their releases ;)

As for 3.6.x and 3.7.x, I would much prefer to have too many proposed "release 
blocker" issues than to have too few.  And the sooner they are reported, the 
better.

--
  Ned Deily
  n...@python.org -- []

___
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] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)

[Matthias Klose]

On 24.05.2018 20:09, Ned Deily wrote:
> On May 24, 2018, at 13:46, Larry Hastings  wrote:
>> On 05/24/2018 10:08 AM, Ned Deily wrote:
>>> If you (or anyone else) feels strongly enough about it, you should re-open 
>>> the issue now and make it as a "release blocker" and we should discuss the 
>>> implications and possible plans of action in the issue.
>>
>> About that.  According to the Python Dev Guide:
>> Whether a bug is a *release blocker* for the current release schedule is 
>> decided by the release manager. Triagers may recommend this priority and 
>> should add the release manager to the nosy list.
>>
>> https://devguide.python.org/triaging/#priority
>> Of course, a particular release manager (e.g. Ned here) can change the 
>> policy for their releases.  But by default, unless you're the release 
>> manager for release X, you should not mark issues as "Release Blocker" for 
>> release X.  This seems like a sensible policy to me, and effective 
>> immediately I'm going to hold to this policy for my releases (3.4 and 3.5).
> 
> I think we're reading the same words a bit differently.  There's no question 
> that the Release Manager makes the ultimate call whether an issue remains a 
> "Release Blocker" or not.  But it seems to me that the safest and most 
> reliable way to ensure that the Release Manager makes that decision is by 
> having a triager or submitter *provisionally* set the priority to "release 
> blocker".  It is then on the Release Manager's radar to accept or reject.  I 
> think that policy is totally in the spirit of the Dev Guide wording but I'm 
> fine with other release managers accepting differing interpretations for 
> their releases ;)
> 
> As for 3.6.x and 3.7.x, I would much prefer to have too many proposed 
> "release blocker" issues than to have too few.  And the sooner they are 
> reported, the better.

Ned's interpretation is the one I'm using for submitting such issues (maybe not
twelve hours before a final release). What other documented ways would you have
to get the attention of a release manager.

Having different interpretations depending on the release manager doesn't look
very practically.

Matthias
___
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] 3.7.0rc1 Delayed [was] FINAL WEEK FOR 3.7.0 CHANGES!

[Ned Deily]

On May 24, 2018, at 03:23, Ned Deily  wrote:
> On May 23, 2018, at 09:13, Ned Deily  wrote:
>> On May 23, 2018, at 07:45, Serhiy Storchaka  wrote:
>>> Is it possible to add yet one beta instead?
>>> CI was broken for few latest days, tests are not passed on my computer 
>>> still (and fail on some buildbots), updating What's New exposed new 
>>> features which need additional testing (and maybe fixing or reverting), and 
>>> I'm not comfortable about some changes which would be harder to fix after 
>>> the release.
>> it is possible but there's no point in doing either another beta or a 
>> release candidate until we understand and address the current blocking 
>> issues, like the major buildbot failures.  We have another 24 hours until 
>> rc1 was planned to be tagged.  Let's keep working on the known issues and we 
>> will make a decision then.
> An update: thanks to a lot of effort over the past day by a number of
> people (including Victor, Serhiy, Christian, Zach, and others I'm sure
> I'm forgetting - my apologies), we have addressed all of the "release
> blocker" issues and all but one of the persistent failures on the 3.7
> stable buildbots. We should have the couple of remaining "deferred
> blockers" including the remaining stable buildbots in green status by
> later today. At that point, we will be ready to tag 3.7.0rc1 and begin
> producing the release candidate artifacts.

Further update: some good news and some changes.

The good news is that we have resolutions for all of the previous release and 
deferred blockers.  Thanks to a number of people for continuing to help get the 
remaining stable buildbot issues taken care of along with some lingering bugs. 

The not-quite-as-good news is that we have had more discussions about some 
unexpected incompatibilities that have shown up with downstream user testing 
with the AST docstrings changes in place (see bpo-32911).  We have had some 
previous discussions about the expected user impact and, earlier in the beta 
phase, I encouraged us to stay the course with the feature as implemented.  But 
I am now persuaded that we owe it to our users to take one more look at this to 
make sure we do not force them to make changes for 3.7 and then once again for 
3.8.  More details are in the bug tracker issue; I strongly encourage those of 
us who have been involved with this to "vote" there on the proposal to either 
(A) proceed with the release of the current implementation in 3.7.0 or (B) 
revert the feature in 3.7.0 and retarget for 3.8.  Should the consensus be to 
revert (B), we will plan to have one more fast-track beta release (b5) prior to 
the release candidate, in order to allow downstream users to tes
 t their projects with the removal.  PLEASE, keep the discussion about this on 
the bug tracker (and not here!) and keep it brief so we can move forward 
quickly.  Because of the upcoming 3-day holiday weekend in some countries, I 
have set Tue 2018-05-29 18:00 UTC as a cutoff for "voting" but, if a clear 
consensus emerges earlier, we will likely cut the discussion short.  So chime 
in now on the bug tracker if you have a stake in this issue.

https://bugs.python.org/issue32911

This does mean that yesterday's "last chance" has been extended a bit, at most 
a few days.  I will let you know as soon as we have made a decision about the 
feature and will provide updated 3.7.0 schedule info at that time.

--Ned

--
  Ned Deily
  n...@python.org -- []

___
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/