I think Ned's concerns are real, and the sunset-python-2 page could use some wordsmithing to explain that even though support ends on Jan 1, there will be a wrap-up release some time after that, but it won't incorporate any changes made or proposed after Jan 1.
Another place where that document could be improved is in clarifying the different uses of the word "volunteers". For me, that's the most confusing part as I was reading it. As near as I can tell, these are different groups, or at least largely disjoint:
* "We are volunteers who make and take care of the Python programming language" * "most volunteers will not help fix them" * "If you need free help from volunteers"
Unfortunately I'm heading out of town and don't have time to help clean this up.
On 9/10/2019 5:09 PM, Jacqueline Kazil wrote:
*RE: Ned's comments -- *That is the same reaction I had when I read through this thread.
*RE: Tal's comment - *I could see this making sense as an explanation.
*RE: Guido's comment* This makes me think that April 2020 is not a thing. And if Ben is supporting solo, then can people email him directly with issues? 😂😂😂
*On a serious note...* I would like clarification, so we (dev community and PSF) have a shared understanding of the direction and are sending the same messaging.
-Jackie PSF Board of Directors
On Tue, Sep 10, 2019 at 4:20 PM Tal Einat <firstname.lastname@example.org mailto:email@example.com> wrote:
On Tue, Sep 10, 2019 at 10:03 PM Ned Batchelder <firstname.lastname@example.org <mailto:email@example.com>> wrote: > > I'm not looking forward to answering questions from the public about why > the PSF is writing dire and specific warnings like "We have decided that > January 1, 2020, will be the day that we sunset Python 2," while the > core devs are planning a release four months after that. It won't help > Python's credibility, and may convince some people that they don't have > to take the date seriously.. To me it seems pretty clear: On Jan 1st 2020, the 2.7.x branch will no longer receive fixes for any *new* bugs or security issues, nor other improvements. I would expect that be the time of the code freeze for the first release candidate, not the time of the final release. While we will still fix issues *introduced in 2.7.18 since 2.7.17* before the final 2.7.18 release, we won't address any other bugs or security issues and won't backport anything *new* from 3.x. (I may have some details not exactly correct here, but I hope the gist is correct.) I'm sure the wording could be improved, but generally this seems entirely reasonable to me. - Tal Einat _______________________________________________ Python-Dev mailing list -- firstname.lastname@example.org <mailto:email@example.com> To unsubscribe send an email to firstname.lastname@example.org <mailto:email@example.com> https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://firstname.lastname@example.org/message/KSU2A5SDGDHCLPKA7BSW2PH5OIZVUOCB/
-- Jacqueline Kazil | @jackiekazil
Python-Dev mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://email@example.com/message/WOAYYHGI...