On Wed, Oct 3, 2012 at 5:16 PM, Larry Hastings wrote:

I don't agree. It's my understanding that the alphas are largely ignored, and having them earlier would hardly make them more relevant.

I would appreciate it you stopped promoting this myth. Each step in the release process widens the pool of people providing feedback. Some are providing feedback (and patches!) right the way through by building their own copy of Python from source, a few start poking around with the first alpha, more wait for feature freeze, we get a whole slew of people that wait until the release candidates come out, and then we get even more that don't check for backwards incompatible changes until after the final release (so they have to wait until the x.y.1 release before they can upgrade). Yes, the pool is substantially smaller in the early phases, but phrases like "largely ignored" do a grave disservice to our alpha testers that provide early feedback when we have plenty of time to fix problems, rather than leaving their checks to the last minute and forcing us to choose between delaying the release and shipping with known defects.

I'm not saying "no"--but I'd definitely want to see more people than just you clamoring for the early alphas before I agree to anything.

Python 3.4 will almost certainly include significant changes to main module and sys.path initialisation as well as the way import failures are reported at the command line (and perhaps in the interactive interpreter), along with some adjustments to the Unicode handling feature set and the disassembly support. I *can't* effectively trial those changes on PyPI (except perhaps some of the disassembly changes), and I don't have the resources to create and distribute Windows and Mac OS X installers on my own. That means, before the release of 3.4a1, any feedback on most of these changes will be limited to those developers with the wherewithal to build Python from source. Regardless of when the first alpha happens, I'll be promoting the hell out of it, begging for feedback on any of these changes that are available by then (which should be quite a few, given the preceding PyCon US sprints). However, I would *like* to have months rather than weeks to act on any feedback we do receive. I'm not asking the release team to do any more work - I'm just asking for a chunk of it to be brought forward a few months. If I was asking for an *extra* release, I could understand resistance to the idea, but what's the concrete benefit of *delaying* the first alpha release by 4 months from when I'm hoping to see it happen? Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

If you can show me people who use the alphas who want them earlier, I'll consider it. So far the only person who's said they want them is you, and IIUC you won't be a consumer of the alpha per se.

Begging for feedback doesn't mean you'll get any,

I haven't done any Python core development work in quite awhile, but BITD, I always just used the current tip of whatever version control system we happened to be using. That would automatically get me all the pre-release versions. No need to beg. :-) Skip

On Wed, Oct 3, 2012 at 5:27 PM, Nick Coghlan wrote:

On Wed, Oct 3, 2012 at 8:43 PM, Larry Hastings wrote:

...

Begging for feedback doesn't mean you'll get any,

I received a fair number of complaints from people that wanted to experiment with yield from, but couldn't, because the first alpha wasn't out yet and they weren't sufficiently interested to go to the effort of building their own copy of Python.

How about having nightly builds then?

Nick Coghlan writes:

I proposed to Larry originally that we start the alphas 6 months after 3.3.0,

I like this idea better, even though to keep the total workload constant you'd need to more than double the interval between alphas. Still, a 10- or 12-month release schedule feels like a much bigger commitment to me (and I have managed a release that took 6 months, so I do know what that feels like for real).

but he didn't like that idea, so I since reduced it to simply doing alpha 1 early so that it din't mean any more work for the release team.

Heck, if you're only going to have *one* early alpha, you could do it yourself, and see if you can persuade the installer builders to volunteer one extra build.

On 10/03/2012 05:27 PM, Nick Coghlan wrote:

That's your prerogative as RM of course, but you haven't given any reason beyond the circular "I don't care about enabling feedback from people that can't or won't build from source, because people that can't or won't build from source don't provide useful feedback".

That's not quite what I said. I simply said that the alphas are largely ignored. My perspective is that most people ignore the alphas and only get interested when the software "solidifies". Having more alphas, or having earlier alphas, doesn't mean we'll have more people interested in the alphas. Adding more alphas (as you have previously suggested) adds additional workload on myself and the rest of the release team--I don't know what the Mac build is like, but I know Martin has to intercede manually to coax a Windows installer out of the build. I'm loathe to burn their time for what I perceive as little return. Changing an existing alpha to be earlier doesn't alter the workload, but I fear it makes the alpha less relevant. Evaluating alphas / betas takes an investment of time, and whether or not a potential alpha user makes that investment depends on what they expect to get out of testing the alpha. If they're doing it out of the goodness of their hearts, just to help Python--well, that's fabulous, and more / earlier alphas might actually interest them. But my suspicion is that most people who try the alphas are doing early integration testing with their own stuff. For those people, the earlier the alpha, the less interesting it probably is to them. Earlier means that the software will be less finished. It will be buggier, it won't have as many features as the beta will. As a result it won't be as revealing--or as relevant--as a later alpha or even a beta. If that's their perspective, I suspect they'll be less likely to try an earlier alpha. In short, I see the scheduling of alphas as a tradeoff between "early enough that we'll have time to fix things" and "late enough that the software is reasonably complete". What it really comes down to: I'm a first-time RM, and I lack the courage/wisdom to overrule what appears to be a reasonable status quo. I feel I don't have to defend the decision to maintain the status quo; I feel instead you have to make a case for changing it. So far all I recall seeing from you are assertions. I'd like to see some harder data. On 10/03/2012 05:28 PM, Brian Curtin wrote:

The webstats in April 2012 show 5628 downloads of 3.3a1 and 4946 downloads of 3.3a2 Windows installers.

I'd love to know how much feedback we got as a result of these downloads. Do we have any way of telling? And out of curiosity, how many 3.3.0 final Windows installers have been downloaded so far? On 10/03/2012 05:29 PM, Maciej Fijalkowski wrote:

How about having nightly builds then?

We simply don't have a fully-automated process to produce installers for all platforms. In fact, I fear we don't have a fully-automated process to produce installers for /any/ platforms. On 10/03/2012 05:40 PM, Paul Moore wrote:

FWIW, I *will* be downloading and installing the 3.4 alphas as soon as they come out. How much I'll *use* them depends on what issues I find with them - but that's the whole point, I'll feed back my experiences.

Excellent, thanks for the data! As long as you're volunteering interesting data ;-), what platform will you be testing on? And what is your purpose in downloading the alphas--just Good Samaritan-ism, or integration testing with software you care about, or what? //arry/

On Wed, 03 Oct 2012 11:19:57 -0500, Brian Curtin wrote:

On Wed, Oct 3, 2012 at 11:02 AM, Larry Hastings wrote:

...

On 10/03/2012 05:28 PM, Brian Curtin wrote:

The webstats in April 2012 show 5628 downloads of 3.3a1 and 4946 downloads of 3.3a2 Windows installers.

I'd love to know how much feedback we got as a result of these downloads. Do we have any way of telling?

Not really, but I guess we could query the tracker for the time frame the alphas were fresh and poke around.

There *were* bug reports during the alpha phase. A number of regressions were caught. Also, there were more alpha-phase bug reports than I remember getting for 3.2. I remember thinking, "wow, cool, we're actually getting regression bug reports during the alpha phase, people must actually be testing this time". --David

On Wed, 03 Oct 2012 18:02:03 +0200, Larry Hastings wrote:

Changing an existing alpha to be earlier doesn't alter the workload, but I fear it makes the alpha less relevant. Evaluating alphas / betas takes an investment of time, and whether or not a potential alpha user makes that investment depends on what they expect to get out of testing the alpha. If they're doing it out of the goodness of their hearts, just to help Python--well, that's fabulous, and more / earlier alphas might actually interest them. But my suspicion is that most people who try the alphas are doing early integration testing with their own stuff. For those people, the earlier the alpha, the less interesting it probably is to them. Earlier means that the software will be less finished. It will be buggier, it won't have as many features as the beta will. As a result it won't be as revealing--or as relevant--as a later alpha or even a beta. If that's their perspective, I suspect they'll be less likely to try an earlier alpha.

In my perception (again, I can't point to any raw data) there is an opposite dynamic that happens in stable projects that produce alphas throughout the release cycle. In those projects, people will often run the alphas, even in production[1], in order to get the new features sooner. Python is a stable project. Even our alphas do not as a rule brown bag, though their suitability for specific projects depends on the bugs found. I think Python *could* be in this camp, if we wanted to be. (I'm not addressing release-team load here, I'm just making an observation.) --David [1] I am *not* advocating running an alpha in production, but for some projects "production" is a small enough audience that they can get away with it.)

On 03.10.12 19:02, Larry Hastings wrote:

But my suspicion is that most people who try the alphas are doing early integration testing with their own stuff. For those people, the earlier the alpha, the less interesting it probably is to them. Earlier means that the software will be less finished. It will be buggier, it won't have as many features as the beta will. As a result it won't be as revealing--or as relevant--as a later alpha or even a beta. If that's their perspective, I suspect they'll be less likely to try an earlier alpha.

I wholeheartedly agree with Larry. Personally I looked for the first time near Python 3.3 after release of the first alpha (before a lot of years followed the development from a distance), but if alpha came out much earlier and would be less mature, I would have probably ignored it. Of course, this is only my personal case, I can't speak for other people.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/10/12 17:27, Nick Coghlan wrote:

I received a fair number of complaints from people that wanted to experiment with yield from, but couldn't, because the first alpha wasn't out yet and they weren't sufficiently interested to go to the effort of building their own copy of Python.

In my job, we do "alpha" releases quite frequently. The promises for alpha is: a) no feature complete, b) the API, etc , can change before release, c) features included are useable. The point is to use them and experiment with them. We don't call them "alphas", but "engineering previews". And they expires after six months. Delivering useable alphas requires to do a "minimal" of release engineering, like disabling features half done, documenting known bugs, etc. So yes, it it a bit of extra work. In Python context, the idea of somebody using a "alpha" in production is scary, and I have a few bad experiences doing a "make install" of a alpha and when installing the final release keeping some alpha files around causing erratic behaviour until I did a "\rm -r /usr/local/SOME" and reinstall again. I think it happened to me with 2.6 :). There are some consequences here, like bytecode (pyc) changes, modules renaming or vanishing before the final release, etc. - -- Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQCVAwUBUG2P6Jlgi5GaxT1NAQJLBgP9GRnurLjdx2IIcrnbjGuRC0EoQF5ISh5p nVQldPRefb3c3MEpsVK0pmTDiPY0Nelepg8j8YMjZeri87AKHojMQ6Teu6NGvx/5 ZMRFsBve8YKfkqAr0ygVl8RlscOMXZsCq2iUHhc8I4L2Nqx7H7yoUDlMcak8JB4t VxYAhugWOmE= =/2aa -----END PGP SIGNATURE-----

On Wed, Oct 3, 2012 at 8:58 PM, Brian Curtin wrote:

This doesn't answer the question of the users wanting the alphas earlier, but they're certainly more than largely ignored...

The webstats in April 2012 show 5628 downloads of 3.3a1 and 4946 downloads of 3.3a2 Windows installers.

So, there's 5000 people that could provide advance feedback that I would then have a few months to act on? Sounds useful to me. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 2012-10-03 16:28, Brian Curtin wrote:

On Wed, Oct 3, 2012 at 10:13 AM, Larry Hastings wrote:

...

On 10/03/2012 04:55 PM, Nick Coghlan wrote:

Regardless of when the first alpha happens, I'll be promoting the hell out of it, begging for feedback on any of these changes that are available by then (which should be quite a few, given the preceding PyCon US sprints).

If you can show me people who use the alphas who want them earlier, I'll consider it. So far the only person who's said they want them is you, and IIUC you won't be a consumer of the alpha per se.

Begging for feedback doesn't mean you'll get any,

This doesn't answer the question of the users wanting the alphas earlier, but they're certainly more than largely ignored...

The webstats in April 2012 show 5628 downloads of 3.3a1 and 4946 downloads of 3.3a2 Windows installers.

I downloaded the alphas to test the support for PEP 393 I'd added to the regex module. Not having to build Python 3.3 from source certainly helped _me_! :-)

Executive summary: Larry admits that doing an early alpha is a plausible experiment, he just has reasons not to do it himself. OTOH, Nick has a reason for wanting to do it in *this* release cycle. It's Larry's call; we should restrict ourselves to giving him the information he requests to make a decision on which reasons are more important to him. Serhiy Storchaka writes:

On 03.10.12 20:10, MRAB wrote:

...

I downloaded the alphas to test the support for PEP 393 I'd added to the regex module.

Hardly alpha would be useful to you if it released before PEP 393 implementation.

Of course not. But Nick is requesting this precisely because the PEPs he wants to get extra testing are already implemented, or very close to it, and presumably his (implied) promise to have "reasonably complete" implementations available by alpha 1 is credible. So your counterfactual is hardly relevant. MRAB's example of how alphas are useful is relevant because it's a real example, with rationale, of the kind of third-party integration testing Larry suspects *won't happen* if an alpha is released way early.

On Wed, 03 Oct 2012 20:25:17 +0530, Nick Coghlan wrote:

On Wed, Oct 3, 2012 at 5:16 PM, Larry Hastings wrote:

...

I don't agree. It's my understanding that the alphas are largely ignored, and having them earlier would hardly make them more relevant.

I would appreciate it you stopped promoting this myth. Each step in the release process widens the pool of people providing feedback. Some are providing feedback (and patches!) right the way through by building their own copy of Python from source, a few start poking around with the first alpha, more wait for feature freeze, we get a whole slew of people that wait until the release candidates come out, and then we get even more that don't check for backwards incompatible changes until after the final release (so they have to wait until the x.y.1 release before they can upgrade).

Yes, the pool is substantially smaller in the early phases, but phrases like "largely ignored" do a grave disservice to our alpha testers that provide early feedback when we have plenty of time to fix problems, rather than leaving their checks to the last minute and forcing us to choose between delaying the release and shipping with known defects.

I don't have any data to back this up, but it is my impression that more distributions are providing access to alpha releases in their "testing" package trees. As Python continues to grow in importance[1], the number of people interacting with Python on the distribution development teams[2] increases, and therefor the number of people likely to run alphas for testing increases. So even if Larry were right *now*, he isn't right for the future, and we should do all we can to nurture an increasing culture of alpha-testing. --David [1] in case anyone hasn't noticed, we *are* a growing community, regardless of where various analytics put us relative to other languages :) [2] I include things like macports in this category, though I have no experience myself with their culture

On Wed, Oct 3, 2012 at 8:55 AM, Nick Coghlan wrote:

I *can't* effectively trial those changes on PyPI (except perhaps some of the disassembly changes), and I don't have the resources to create and distribute Windows and Mac OS X installers on my own. That means, before the release of 3.4a1, any feedback on most of these changes will be limited to those developers with the wherewithal to build Python from source.

Would it help to have automated nightly builds that include those installers (if that's even feasible)? I'm not opposed to an earlier alpha as well, but some of the concern you have would be additionally addressed by such nightly builds. -eric

martin@v.loewis.de writes:

We once had nightly builds of the Windows installers. It required a dedicated buildbot operator, since the process tended to break.

For what it's worth, I'd be willing to try to re-institute the daily Windows installer builds if they'd see usage, but I suspect I'll need assistance with any initial issues with the packaging process, which is where the issues are most likely to be. At the time we shut them down (Dec 2008 I think) they had been failing for about 6 months without anyone noticing, so it didn't seem repairing it again. -- David

On Wed, 3 Oct 2012 20:05:24 +0200 Antoine Pitrou wrote:

On Wed, 3 Oct 2012 20:25:17 +0530 Nick Coghlan wrote:

...

On Wed, Oct 3, 2012 at 5:16 PM, Larry Hastings wrote:

...

I don't agree. It's my understanding that the alphas are largely ignored, and having them earlier would hardly make them more relevant.

I would appreciate it you stopped promoting this myth. Each step in the release process widens the pool of people providing feedback.

Well, if you look at the download statistics at http://www.python.org/webstats/ or even at the bug influx when publishing an alpha, it seems clear to me that alphas have almost no impact.

Erm, I hadn't seen Brian's reply before sending this. Apparently there *are* people who download the alphas, which for some reason I had overlooked in the stats pages. My mistake, sorry. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net

In article <20121003203328.Horde.Za5_TqGZi1VQbIT43MHBgoA@webmail.df.eu>, martin@v.loewis.de wrote:

I wouldn't mind having alpha 1 in April 2013, and alpha 2 in October 2013. I share Larry's skepticism, and actually fear that it may confuse users (which find that they test something completely different from what gets released). However, I don't mind supporting this strategy anyway as an experiment.

I'm certainly also game to supporting earlier alphas. Perhaps not on April 1, though. -- Ned Deily, nad@acm.org

On 10/03/2012 01:54 PM, Larry Hastings wrote:

On 10/03/2012 01:45 PM, Skip Montanaro wrote:

...

Is there a rough list of changes for 3.4 written down somewhere, or is that only to be inferred based on PEPs whose Python-Version header reads "3.4"? How confident are you that the schedule you've proposed gives enough time for proposed changes to be implemented and to stablize?

Here's a short list of proposed changes for 3.4--basically all the stuff that didn't make it in to 3.3:

Candidate PEPs:

* PEP 395: Qualified Names for Modules * PEP 3143: Standard daemon process library * PEP 3154: Pickle protocol version 4

Other proposed large-scale changes:

* Breaking out standard library and docs in separate repos * Addition of the "packaging" module, deprecating "distutils" * Addition of the "regex" module * Email version 6 * A standard event-loop interface (PEP by Jim Fulton pending)

As for the rest of it, my understanding was that there is no longer any great plan written in the stars for Python releases. Python releases are comprised of whatever features people propose, implement, and are willing to support, that they can get done in time for the beta cutoff. From that perspective, the schedule drives the features more than the other-way around.

The schedule proposes six weeks between feature-freeze and release.

Looks more like 3 months, which is fine. Georg

On Thu, 04 Oct 2012 03:14:11 +0200, =?ISO-8859-1?Q?Giampaolo_Rodol=E0?= wrote:

2012/10/3 Larry Hastings :

...

Other proposed large-scale changes: [...] * A standard event-loop interface (PEP by Jim Fulton pending)

Really? Was this discussed somewhere? I'd like to know more about it.

I believe it was discussed at the Language Summit at the last Pycon. As I recall there was at least one other person interested in helping with it, but I don't remember who. --David

Hello :) That PEP is indeed pining to the fjords. I may be able to contribute (and hopefully I can with the preliminary research and talking-to-people-about-what-they-want that I've already done that maybe hasn't made it into the draft PEP versions), but I can not currently spare the cycles to carry it forth from its current state to a completed implemented in 3.4 PEP. cheers lvh On Thu, Oct 4, 2012 at 8:00 AM, Hynek Schlawack wrote:

Am 04.10.2012 um 03:38 schrieb R. David Murray :

...

...

...

Other proposed large-scale changes: [...] * A standard event-loop interface (PEP by Jim Fulton pending)

Really? Was this discussed somewhere? I'd like to know more about it.

I believe it was discussed at the Language Summit at the last Pycon. As I recall there was at least one other person interested in helping with it, but I don't remember who.

T’was lvh and I remember doing some cheap spelling checking on it back at EuroPython 20_11_ but the work seems to has stalled 9 months ago.

Adding him to the loop.

On Thu, Oct 4, 2012 at 12:32 PM, Christian Heimes wrote:

Two days ago NIST announced the SHA-3 contest winner. My wrapper of keccak https://bitbucket.org/tiran/pykeccak/ is almost ready and just needs some cleanup and more tests. Once it's done I'll remove the Python 3.2 and 2.x compatibility code and integrate it into 3.4.

See also https://github.com/bjornedstrom/python-sha3. Cheers, Dirkjan

On Oct 03, 2012, at 06:45 AM, Skip Montanaro wrote:

Is there a rough list of changes for 3.4 written down somewhere

Let the wild rumpus begin! -Barry