Re: [Python-Dev] Request for CPython 3.5.3 release
On 03.07.2016 16:39, Guido van Rossum wrote: Another thought recently occurred to me. Do releases really have to be such big productions? A recent ACM article by Tom Limoncelli[1] reminded me that we're doing releases the old-fashioned way -- infrequently, and with lots of manual labor. Maybe we could (eventually) try to strive for a lighter-weight, more automated release process? I can only recommend such an approach. We use it internally for years now and the workload for releasing, quality assurance and final deployment dropped significantly. We basically automated everything. The devs are pretty happy with it now and sometimes "mis-use" it for some of its side-products; but that's okay as it's very convenient to use. For some parts we use pip to install/upgrade the dependencies but CPython might need to use a different tooling for the stdlib and its C-dependencies. If you need some assistance here, let me know. It would be less work, and it would reduce stress for authors of stdlib modules and packages -- there's always the next release. I would think this wouldn't obviate the need for carefully planned and timed "big deal" feature releases, but it could make the bug fix releases *less* of a deal, for everyone. [1] http://cacm.acm.org/magazines/2016/7/204027-the-small-batches-principle/abstract (sadly requires login) Best, Sven ___ 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] Request for CPython 3.5.3 release
On 7/4/16, 3:32 AM, "Python-Dev on behalf of Sven R. Kunze" wrote: >On 03.07.2016 16:39, Guido van Rossum wrote: >> Another thought recently occurred to me. Do releases really have to be >> such big productions? A recent ACM article by Tom Limoncelli[1] >> reminded me that we're doing releases the old-fashioned way -- >> infrequently, and with lots of manual labor. Maybe we could >> (eventually) try to strive for a lighter-weight, more automated >> release process? > >I can only recommend such an approach. We use it internally for years >now and the workload for releasing, quality assurance and final >deployment dropped significantly. We basically automated everything. >The devs are pretty happy with it now and sometimes "mis-use" it for >some of its side-products; but that's okay as it's very convenient to use. > >For some parts we use pip to install/upgrade the dependencies but >CPython might need to use a different tooling for the stdlib and its >C-dependencies. > > >If you need some assistance here, let me know. I also offer my help with setting up CI and automated builds. :) I've actually done build automation for a number of the projects I've worked on in the past. In every case, doing so gave benefits that far outweighed the work needed to get it going. Regards, Kevin >> It would be less work, and it would reduce stress for >> authors of stdlib modules and packages -- there's always the next >> release. I would think this wouldn't obviate the need for carefully >> planned and timed "big deal" feature releases, but it could make the >> bug fix releases *less* of a deal, for everyone. >> >> [1] >> http://cacm.acm.org/magazines/2016/7/204027-the-small-batches-principle/abstract >> (sadly requires login) >> > >Best, >Sven >___ >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/kevin-lists%40theolliviers.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] Request for CPython 3.5.3 release
On 03.07.2016 06:09, Nick Coghlan wrote: > On 2 July 2016 at 16:17, Ludovic Gasc wrote: >> Hi everybody, >> >> I fully understand that AsyncIO is a drop in the ocean of CPython, you're >> working to prepare the entire 3.5.3 release for December, not yet ready. >> However, you might create a 3.5.2.1 release with only this AsyncIO fix ? > > That would be more work than just doing a 3.5.3 release, though - the > problem isn't with the version number bump, it's with asking the > release team to do additional work without clearly explaining the > rationale for the request (more on that below). While some parts of > the release process are automated, there's still a lot of steps to run > through by a number of different people: > https://www.python.org/dev/peps/pep-0101/. > > The first key question to answer in this kind of situation is: "Is > there code that will run correctly on 3.5.1 that will now fail on > 3.5.2?" (i.e. it's a regression introduced by the asyncio and > coroutine changes in the point release rather than something that was > already broken in 3.5.0 and 3.5.1). I don't know about 3.5.1 exactly, but at least things worked on the branch early April, which were broken by 3.5.2 final. I was trying to prepare for an update to 3.5.2 for Ubuntu 16.04 LTS, and found some regressions, documented at https://launchpad.net/bugs/1586673 (comment #6). It looks like that at least the packages nuitka, python-websockets and urwid fail to build with the 3.5.2 release. Still need to investigate. Unless I'm missing things, there is unfortunately no issue in the Python bug tracker, and there is no patch for the 3.5 branch either. My understanding is that it's not yet decided what to do about the issue. Matthias ___ 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] Request for CPython 3.5.3 release
On 04Jul2016 0822, Kevin Ollivier wrote: On 7/4/16, 3:32 AM, "Python-Dev on behalf of Sven R. Kunze" wrote: If you need some assistance here, let me know. I also offer my help with setting up CI and automated builds. :) I've actually done build automation for a number of the projects I've worked on in the past. In every case, doing so gave benefits that far outweighed the work needed to get it going. It's actually not that much effort - we already have a fleet of buildbots that automatically build, test and report on Python's stability on a range of platforms. Once a build machine is configured, producing a build is typically a single command. The benefit we get from the heavyweight release procedures is that someone trustworthy (the Release Manager) has controlled the process, reducing the rate of change and ensuring stability over the end of the process. Also that trustworthy people (the build managers) have downloaded, built and signed the code without modifying it or injecting unauthorised code. As a result of these, people trust official releases to be correct and stable. It's very hard to put the same trust in an automated system (and it's a great way to lose signing certificates). I don't believe the release procedures are too onerous (though Benjamin, Larry and Ned are welcome to disagree :) ), and possibly there is some more scripting that could help out, but there's really nothing in the direct process that we need to do more releases. More frequent releases would mean more frequent feature freezes and more time in "cherry-picking" mode (where the RM has to approve and merge each individual fix), which affects all contributors. Shorter cycles make it harder to get changes reviewed, merged and tested. This is the limiting factor. So don't worry about offering skills/effort for CI systems (unless you want to maintain a few buildbots, in which case read https://www.python.org/dev/buildbot/) - go and help review and improve some patches instead. The shorter the cycle between finding a need and committing the patch, and the more often issues are found *before* commit, the more frequently we can do releases. 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] Request for CPython 3.5.3 release
I should quickly mention that future workflow-related stuff in regards to https://www.python.org/dev/peps/pep-0512 and the move to GitHub (e.g. CI), happens on the core-workflow mailing list. On Mon, 4 Jul 2016 at 15:35 Steve Dower wrote: > On 04Jul2016 0822, Kevin Ollivier wrote: > > On 7/4/16, 3:32 AM, "Python-Dev on behalf of Sven R. Kunze" > srku...@mail.de> wrote: > >> > >> If you need some assistance here, let me know. > > > > I also offer my help with setting up CI and automated builds. :) I've > actually done build automation for a number of the projects I've worked on > in the past. In every case, doing so gave benefits that far outweighed the > work needed to get it going. > > It's actually not that much effort - we already have a fleet of > buildbots that automatically build, test and report on Python's > stability on a range of platforms. Once a build machine is configured, > producing a build is typically a single command. > > The benefit we get from the heavyweight release procedures is that > someone trustworthy (the Release Manager) has controlled the process, > reducing the rate of change and ensuring stability over the end of the > process. Also that trustworthy people (the build managers) have > downloaded, built and signed the code without modifying it or injecting > unauthorised code. > > As a result of these, people trust official releases to be correct and > stable. It's very hard to put the same trust in an automated system (and > it's a great way to lose signing certificates). > > I don't believe the release procedures are too onerous (though Benjamin, > Larry and Ned are welcome to disagree :) ), and possibly there is some > more scripting that could help out, but there's really nothing in the > direct process that we need to do more releases. > > More frequent releases would mean more frequent feature freezes and more > time in "cherry-picking" mode (where the RM has to approve and merge > each individual fix), which affects all contributors. Shorter cycles > make it harder to get changes reviewed, merged and tested. This is the > limiting factor. > > So don't worry about offering skills/effort for CI systems (unless you > want to maintain a few buildbots, in which case read > https://www.python.org/dev/buildbot/) - go and help review and improve > some patches instead. The shorter the cycle between finding a need and > committing the patch, and the more often issues are found *before* > commit, the more frequently we can do releases. > > 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] release cadence (was: Request for CPython 3.5.3, release)
On 07/03/2016 09:39 AM, Guido van Rossum wrote: Do releases really have to be such big productions? A recent ACM article by Tom Limoncelli[1] reminded me that we're doing releases the old-fashioned way -- infrequently, and with lots of manual labor. Maybe we could (eventually) try to strive for a lighter-weight, more automated release process? Glyph suggested this as part of his presentation at the 2015 Language Summit: https://lwn.net/Articles/640181/ I won't summarize his comments here, as Jake already did that for us ;-) //arry/ ___ 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] [Webmaster] Unsafe listing by Norton's "File Insight"
Hi Peter, While the humble webmasters can do little about this it's possible the developers can, so I am forwarding your email to their mailing list. regards Steve Steve Holden On Tue, Jul 5, 2016 at 3:30 AM, Peter via Webmaster wrote: > Hi > I'm a heavy user of Python on Windows, am a Basic PSF member and have > contributed to core Python. > The Python 2.7.12 Windows installer download is being marked as untrusted > by Norton Internet Security. I've been on chat with Symantec, and they've > said that I can't do anything about that rating, but that the site owner > can. > I've been pointed to: > https://safeweb.norton.com/help/site_owners > Interestingly, the 3.5.2 download is flagged as safe. > Hoping to get more Python out to users! > Thanks > Peter > > ___ > Webmaster mailing list > webmas...@python.org > https://mail.python.org/mailman/listinfo/webmaster > ___ 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
