-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen J. Turnbull wrote:

"Martin v. Löwis" writes:

...

I'm not sure that the concept of a "trunk" branch still exists in Mercurial. PEP 385 apparently doesn't have resolved the branch strategy for Mercurial yet. With cloned branches, I think the concept of a "trunk" becomes irrelevant.

"Trunk" exists as a technical restriction in CVS, and maybe to some extent in Subversion. Of course that restriction is lifted by DVCSes.

But really "trunk" is a social concept. Most projects have a trunk. Even the anarchy known as GNU Arch converged on Tom Lord's version, just as the storm of turbulance known as "Linux kernel development" does on Linus's.

Python's 2.x/py3k division is a tour de force; I still can't believe my eyes that you've pulled it off. Consider Perl 6, LaTeX 3, and Zope 3, or Linux 3, for that matter. The first 3 are all facing the "what is trunk?" issue, in the case of Zope several years after the "point oh" release, and AFAIK there are no current plans for Linux 3 (a microkernel architecture, maybe?<1.01 wink>). Of course the issues faced by LaTeX, Zope, and the kernel are quite different from Python's, and I don't know enough about Perl internals to compare.

FWIW, it seems to be consensus in the Zope community that "Zope3" was a misnomer, reflecting a vision for the software (serving as the replacement / successor to Zope2) which it didn't grow to fulfill. At this point, the "reusable" bits now form a collection of separately-released packages referred to as the "Zope Toolkit,"[1] which is intended to be used by Zope2, Grok, and the folks still running the "pure" Zope3 appserver. A lot of the work involved in this effort has been in disentagling the dependencies among the various packages, precisely so that they can be used piecemeal, without pulling in all of the stack. [1] http://docs.zope.org/zopetoolkit/ Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKK7px+gerLs4ltQ4RAoMnAJ9WTL8zo3+bSop+SAXr+akp85tMZQCfS5oC y14j64VJPjgxDQzCb1p/iZo= =RCZa -----END PGP SIGNATURE-----

Lennart Regebro writes:

2009/6/7 Stephen J. Turnbull :

...

Python's 2.x/py3k division is a tour de force; I still can't believe my eyes that you've pulled it off.

Well, It's not pulled off until Python 3 has surpassed Python 2 in usage.

I'm referring only to the management of the dual-trunk workflow, not to whether Python3 will be the preferred path for the future. That workflow has its problems, but still it seems very successful in keeping what needs to be synced, synced, and what needs to be different, different.

Nick Coghlan wrote:

Martin v. Löwis wrote:

...

...

I have thought that 2.7 was now to come out instead with 3.2 and would include backported 3.2 new features. Others expect 2.7 to come out soon after 3.1 and to only contain new 3.1 features. So Guido or someone, please clarify: is 2.7 to be the counterpart of 3.1 or 3.2? Neither, nor. 2.7 will be released 18..24 months after 2.6, i.e. between April 2010 and October 2010. I think it's too early to speculate about a release schedule for 3.2.

I think Terry's underlying question is more basic than that. It can also be phrased as:

"Is 2.7 allowed to have new features which did not appear in 3.1?"

I don't think this is the question Terry meant to ask, and the answer to this question is a clear "Certainly, but you are asking the wrong question." The question that Terry really meant to ask is "why is there no release candidate for 2.7 already, when 3.1 is going to be released RSN?", and that question arises from the (incorrect) understanding that 2.x releases and 3.x releases will be lock-step. The question that you posed should have been phrased as "Is 2.7 allowed to have new features which don't also appear on the 3k branch?", to which the answer is a clear "No."

In previous discussions, a general policy has been articulated that having released Python 3.0, any new features should appear in a 3.x release before they appear in a 2.x release.

I don't think that the policy has been articulated in exactly that way, and it certainly wasn't implemented for 2.6/3.0. 2.6 was released with features that had not been released in any 3.x release, just because 3.x had not been released at all.

A. "No."

This answer means that 2.7 will only contain new features that are part of 3.1. If 2.7 sticks to a normal 18-24 month release cycle the only activities on the trunk for the next 12 months or so should be backports from 3.1 and bug fixes. New features added to the py3k branch for 3.2 should not be backported until after 2.7 is released. The other alternative in this case is to release 2.7 earlier than normal, but that creates problems in terms of the absolute duration of maintenance branch support for 2.6.

I think this makes it clear that the answer can't possibly be "No". Not allowing addition of new features even though the release is still 12 months away would be unreasonable, IMO - what's the point of freezing development now, and where should new features to 2.x be added if not to the trunk? Likewise, releasing 2.7 now is completely unacceptable.

B. "Yes."

This answer means that the 3.1 to 3.2 development cycle will need to be truncated by roughly 6 months so that 3.2 can be released before 2.7 with any new features of interest. The 3.2 and 2.7 releases should then occur within a few months of each other.

Assuming the policy "release new features for 2.x only after they got released for 3.x". I don't think such a policy actually exists. Regards, Martin

I'm neutral on time frames, but I think that it _should_ be a policy that new features only get released to the 2.x branch after they have been released in the 3.x branch. Or, rather, I though that policy was implicit in the idea that we weren't _automatically_ backporting features, specifically in order to encourage 3.x adoption.

I think "backporting" is an entirely different issue, let alone "automatic" backporting. What *is* policy (AFAIU) is "any feature in the trunk must also exist in the py3k branch". IMO, this is sufficient to encourage 3.x adoption, and it is a policy that is silent wrt. to release date ordering. By the policy you propose, we could not have released 2.6 in October 2008, which we really really wanted to because Apple wanted us to.

So if 2.7 is going to come out before 3.2, you'll have to convince me that having new features in 2.7 that aren't in 3.1 is a good idea :)

I don't see why the precise ordering of release dates matters at all. It seems you are happy with having 3.2 be released "around the same time" as 2.7. What is "the same time"? 3 months difference? 6 months difference? It certainly wouldn't be a year. Regards, Martin

R. David Murray wrote:

[snip...]

...

By the policy you propose, we could not have released 2.6 in October 2008, which we really really wanted to because Apple wanted us to.

I don't think the 2.6 release date is relevant to this discussion, since 3.x hadn't been released at all at that point. What I want to avoid is people writing new code for 2.7 instead of 3.1 because they want to take advantage of a nifty new feature that 3.1 doesn't have.

But 3.1 is in feature freeze (py3k trunk) and it is not possible to check-in code for 3.2. Following this policy it would mean a feature freeze on trunk for an indefinite period of time. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog

On Sun, 7 Jun 2009 at 21:55, Michael Foord wrote:

R. David Murray wrote:

...

[snip...]

...

By the policy you propose, we could not have released 2.6 in October 2008, which we really really wanted to because Apple wanted us to.

I don't think the 2.6 release date is relevant to this discussion, since 3.x hadn't been released at all at that point. What I want to avoid is people writing new code for 2.7 instead of 3.1 because they want to take advantage of a nifty new feature that 3.1 doesn't have.

But 3.1 is in feature freeze (py3k trunk) and it is not possible to check-in code for 3.2. Following this policy it would mean a feature freeze on trunk for an indefinite period of time.

As I said on IRC, that's not what I'm advocating. I'm advocating having 3.2 come out before 2.7, so that the new post-3.1 features get released to the public in 3.2 first, before appearing in 2.7. (Although "first" could alternatively mean the same day, if the community were up to for that). But like I said I'm not attached to the idea, just advocating it ;) --David

Martin v. Löwis wrote:

I don't think that the policy has been articulated in exactly that way, and it certainly wasn't implemented for 2.6/3.0. 2.6 was released with features that had not been released in any 3.x release, just because 3.x had not been released at all.

I don't think the idea of "3.x first" was raised explicitly until the discussions about having a short release cycle for 3.1 came up. Before then there was an assumption that 3.1 and 2.7 would come out at roughly the same time.

...

B. "Yes."

This answer means that the 3.1 to 3.2 development cycle will need to be truncated by roughly 6 months so that 3.2 can be released before 2.7 with any new features of interest. The 3.2 and 2.7 releases should then occur within a few months of each other.

Assuming the policy "release new features for 2.x only after they got released for 3.x". I don't think such a policy actually exists.

As RDM already mentioned, the potential problem such a policy is intended to address is the idea of being able to write 2.7 code that can't be forward ported to 3.x because no version with a corresponding feature set has been released yet. My last sentence above was actually deliberately ambiguous as to whether 2.7 or 3.2 ends up being released first - so long as the releases happen within a few months of each other and any new features that appear in 2.7 also appear in 3.2, then the migration path for different 2.x versions remains clear (i.e 2.6-only code can be migrated to 3.1, but 2.7 code may need to be migrated to 3.2 instead if it uses features that aren't in 3.1). The exact order and timing of 3.2/2.7 will no doubt depend on any specific issues relating to the two releases around the time that they come out. But in the interests of maintaining a coherent migration path from 2.x to 3.x, it makes sense to plan to release them at roughly the same time. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Terry Reedy wrote:

[snip...]

...

I don't think that's a novel idea though - I'm pretty sure it was suggested (and met with general approval) when the idea of a short release cycle for 3.1 was first brought up.

I presume because it has been stated before.

In addition to the question above, I am also trying to provoke thought on the nature and purpose of 2.7. Backporting features 'if someone feels like it' seems pretty haphazard. For someone wanting to maintain compatibility across multiple 2.x releases, a random new features may be nearly useless.

The "What's new in Python 2.7" list is already very impressive. :-) Michael

Terry Jan Reedy

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...

-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog

anatoly techtonik writes:

Just my 0.02 cents, but struggling with all warts of 2.5 subprocessing in Windows I would vote for more time for stabilizating things - not adding new features. Long awaited subprocess as replacement for os.popen() AFAIK is still incapable to asynchronously communicate with spawned processes on Windows. I would call this feature as critical even on 2.6 As a release testcase - try porting pyexpect module to this platform. Absence of native curses/console/readline module also makes Python one-way unix shell language while many users expect it to be crossplatform.

As always, patches and proposals are welcome! However, as far as the above issues are concerned, it seems to be less a matter of time between releases than of motivation to get things done (tm). I don't think a knowledgeable and determined Windows programmer would have much trouble solving each of them. Regards Antoine.

On Mon, Jun 8, 2009 at 11:01 PM, "Martin v. Löwis" wrote:

I am not quite sure whether you are for new features or not. Your first sentence ("vote for ... not adding new features") seems to suggest that you would not like to see new features, and your last sentence ("absence of native curses/console/readline module") suggests that you *do* want to see new features (namely, a native curses module, and a native readline module).

Which one is it?

I would like to see new features in Python, but only if they are cross-platform. Unfortunately, I do not possess C skills to make this happen, nor do I have deep understanding of Microsoft Visual Studio .project files to port Makefiles and GCC options even when codebase is available for windows. The level to make a contribution in this case is too high. The lack of free time makes it impossible to close the gap in one step leaving remnants of work-in-process that will make it harder to continue in future than to start from scratch. Perhaps the necessity to make it in one huge step could be compensated by incremental solution approach and development process if there was obvious centralized place to organize efforts AND provide clear visibility into progress made so far, initial plan, plan deviation and current status. Mailing lists are good for discussions, but that's all - information becomes outdated, text-too-much, no prompt reply often stops the progress. Perhaps I shift my problem from lack-of-skill into lack-of-tools direction, but being amazed by efforts people put into supporting this mailing list I most of the time unable to reply to emails I get mostly because replies require time for testing and proving facts. There is no definite proposal to solve problems of enabling OpenID or SSO for python.org, of porting curses to windows, of testing subprocessing etc., but there is an idea that some things could be given more visibility AND priority to allow people to see the big picture and focus on outstanding problems. Even though most people here know about big-things-to-fix, these things doesn't standout from the pile of issues in roundup. The thing I miss the most is ability to gather all information relevant to one problem in one place. This includes timeline with commits, branches, relevant issues, issue updates, relevant wiki edits, current focus URLs, _filtered_ threads and refactored comments. The problem is to ensure that this information is up to date and provide easy way/instruction how to bring it up to date in case something is broken. It is not necessary to meet the bus to experience the effect of bus factor. -- anatoly t.