Re: [python-committers] Requirements to get the "bug triage" permission?

On 06/12/17 23:17, Victor Stinner wrote: > My problem is that we don't have a long list of "awards" in Python: > the triage bit and the commit bit... > > I had some ideas to create badges, but before I come with something > concrete, I'm trying to build something with what we already have ;-) I h

[python-committers] Python workflow quirks with mercurial and hg-git extension

I plan to come back to python development (about time!) but I truly hates git. I am experimenting with mercurial + hg-git extension and it is quite usable (after the initial painfully slow clone time), but I am having small quirks that I would like to iron out with a fellow more experienced or also

[python-committers] Update PEP-373: Release schedule for Python 2.7

doesn't have the release date of 2.7.13 (already done) neither the scheduled date for 2.7.14. I could Pull Request the first, but I don't know about the second... -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es -

Re: [python-committers] I broke the 3.5 branch, apparently

On 03/06/16 23:50, R. David Murray wrote: > I don't understand how it happened, but apparently I got a merge commit > backward and merged 3.6 into 3.5 and pushed it without realizing what > had happened. If anyone has any clue how to reverse this cleanly, > please let me know. (There are a couple

Re: [python-committers] Guidance on merging(?)

On 08/05/16 15:31, Serhiy Storchaka wrote: > For future, you should first commit your patch in 3.5, and then merge > it in default. Yes, for the future, you should write the patch for the oldest branch appropriate and then just merge it to the next branches. Let's say you have a security fich for

Re: [python-committers] Anyone up for a core dev panel discussion at EuroPython 2016 ?

On 19/02/16 17:35, M.-A. Lemburg wrote: > at this year's EuroPython we'll have a new officially supported > feature, the panel discussion, and we (I'm one of the organizers) > thought it would be big fun to have a panel of core developers > talk about the merits of computed gotos, micro benchmarks,

Re: [python-committers] Would anyone STOP contributing to Python if we used GitHub?

On 15/12/15 18:11, Brett Cannon wrote: > I'm sorry if this came off as a threat that I'm holding over people to > scare them or it comes off as me trying to be a bully to people. I'm > simply trying to make sure I get answers to this question which are > truly sincere and the importance of the ans

[python-committers] I am nos selectable in the bugtracker

After sending my new SSH key I have recovered "push" abilities in the mercurial repository, but it looks like I am not present in the bug tracker "assigned to" field. Thanks for your time. -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es

[python-committers] Committer missing :)

I was trying to push a patch but it seems I am not a committer anymore. My name vanished of and the tracker. I guess I had a DSA key in hg.python.org and those are not valid anymore, but looks like I am not a documented committer anymore in order to send a ne

Re: [python-committers] getting help with the hgaccounts alias

On 03/08/15 07:12, Brett Cannon wrote: > I clarified the instructions in commit 68b06ae9aee4. Good improvement. Thanks. When is the HTML regenerated. I committed changes some days ago and they are not online yet :-?. -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@

Re: [python-committers] getting help with the hgaccounts alias

On 31/07/15 18:23, Barry Warsaw wrote: > This is likely an ssh problem on your end, not an hg problem. > > http://superuser.com/questions/187779/too-many-authentication-failures-for-username Apparently you MUST be added to the maintenance group BEFORE being able to clone the repository. I think t

Re: [python-committers] getting help with the hgaccounts alias

On 30/07/15 19:37, Brett Cannon wrote: > Thanks to Benjamin, we now have instructions in the devguide on how to > help out with adding SSH keys for > people: https://docs.python.org/devguide/developers.html#altering-access > . For those of you who expressed interest in helping out, now you can! ""

Re: [python-committers] "Gratuitous"? incompatibilities in the "fix only" releases

On 29/07/15 18:50, Guido van Rossum wrote: > I believe that in this particular case, the bug was fixed (by tightening > the requirements for headers) because the bug can lead to security > vulnerabilities. I think you can find more by Googling for keywords like > "http header injection". The more r

[python-committers] "Gratuitous"? incompatibilities in the "fix only" releases

Yesterday I upgraded one of my computer to 2.7.10 and a program working for years failed. The problem is this: """ http=httplib.HTTPConnection("127.0.0.1",8081) http.request("GET","/X/%f" %last_t, "", \ {"Authorization":"Basic %s" %base64.encodestring("%s:%s" %(a,b))}) """ base64.encodestr

Re: [python-committers] getting help with the hgaccounts alias

On 24/07/15 10:59, Nick Coghlan wrote: > > On 24 Jul 2015 01:38, "Jesus Cea" mailto:j...@jcea.es>> > wrote: >> >> I wonder about the new PSF "infraestructure/programming volunteers". >> Never heard of them and I am more than willing to help

Re: [python-committers] getting help with the hgaccounts alias

On 23/07/15 16:37, Brett Cannon wrote: > Thanks to David, Eric, and Kushal for volunteering (and Jesus for > willing to but there is no tutorial). I have asked the infrastructure > team how to grant you all access to the needed hg repo and get you on > the hgaccounts email alias. I am well versed

Re: [python-committers] MSDN subscriptions, Intel ICC licenses

I wonder if we could arrange something similar with Oracle?. Python support on Solaris is important, I guess... :-). Not a lot of hope, thought. I have fighting them to get a Solaris license for years because of my free work on Python's Oracle Berkeley DB bindings. No luck so far. I surrendered...

Re: [python-committers] getting help with the hgaccounts alias

On 22/07/15 19:23, Brett Cannon wrote: > Is anyone up for helping with adding SSH keys for people? It's basically > taking someone's key as an attachment in an email, making sure it's RSA > and not DSA, and then either creating a new file in a specific repo for > them or appending it to their exist

Re: [python-committers] Weak SSH keys

On 03/06/15 16:59, Benjamin Peterson wrote: > That's just how the SSH auth protocol works. The client offers keys > until the server finds one acceptable. I'm not sure how the order is > determined; it's probably arbitrary for OpenSSH. The server will accept the first key it can find a public key

Re: [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

Larry, could you comment about the impact in the buildbots?. I suppose option #1 could allows us to test both 3.5 and 3.6 changes. Would you confirm this? My votes: Workflow #0: -0 Workflow #1: +1 Workflow #2: +0 Would be great if we could host the branch for 3.5 ourselves instead of using BitBu

[python-committers] HEADS UP!: There is no v3.4.3 tag in the repository

Current repository doesn't have a "v3.4.3" tag. Please tag it and let me know when done :). Pay attention to tag the right version :) -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea

Re: [python-committers] "OpenID provider discovery failed"

On 12/11/14 12:35, Antoine Pitrou wrote: > I get "OpenID provider discovery failed" when trying to log in on > https://bugs.python.org. It used to work. Did something change recently? It works for me. I use "http://www.jcea.es/";, that is delegated to http://certifi.ca/. -- Jesús Cea Avión

Re: [python-committers] Mercurial 3.1 and 2.6 branches are not "inactive"

On 15/10/14 22:58, Barry Warsaw wrote: > On Oct 15, 2014, at 01:47 PM, Ned Deily wrote: > >> Since both 2.6 and 3.1 are now retired, their branches should be marked >> as closed at this point, like earlier retired releases. Barry? >> Benjamin? > > 2.6 for sure. I don't know what actually has

[python-committers] Mercurial 3.1 and 2.6 branches are not "inactive"

Mercurial branches 3.1 and 2.6 are not "inactive". They are not "merged": """ [jcea@babylon5 cpython]$ hg branches default93408:fd658692db3a 2.793384:7ba47bbfe38d 3.190584:c7b93519807a 2.690420:23a60d89dbd4

Re: [python-committers] [RELEASE] Python 3.4.2 is now available

On 08/10/14 13:23, Jesus Cea wrote: > On 08/10/14 10:57, Larry Hastings wrote: >>https://www.python.org/download/releases/3.4.2 > > First, congrats everybody!. > > Webpage <https://www.python.org/download/releases/3.4.2> says "Python > 3.4.2rc1 was releas

Re: [python-committers] [RELEASE] Python 3.4.2 is now available

On 08/10/14 10:57, Larry Hastings wrote: >https://www.python.org/download/releases/3.4.2 First, congrats everybody!. Webpage says "Python 3.4.2rc1 was released on October 8th, 2014.". Note the "rc1" reference. Changelog points to rc1 too. --

Re: [python-committers] new hg.python.org server

On 13/09/14 02:34, Benjamin Peterson wrote: > I just switched hg.python.org from a OSUOSL VM to a Rackspace VM. The > new VM is a bit beefier and has what I think is better network > connectivity, so hopefully that will improving the speed of repository > operations. We also now support HTTPS for r

Re: [python-committers] 3.4 buildbots??

On 17/03/14 15:16, "Martin v. Löwis" wrote: > However, I would advise against doing so now, and delay the addition > of the 3.4 branch until 3.3 is retired from bug fixing, and then > repurpose all 3.3 configuration for 3.4. Otherwise, some slaves might > run out of disk space. Are you actually ta

Re: [python-committers] default hg.python.org/cpython is now 3.5

On 17/03/14 09:51, Victor Stinner wrote: > Until when should we fix bugs in the branch 3.3? Branches 3.1 and 3.2 > only accept security fixes, right? Tradition says that until release *.1 is published. That is, 3.4.1 in this case. But release manager will tell. -- Jesús Cea Avión

[python-committers] 3.4 buildbots??

Do I need to do anything to create the 3.4 branch in the buildbots?. -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xm

Re: [python-committers] Status of the Derby, and request for another slip

On 25/01/14 19:33, Ethan Furman wrote: > On 01/25/2014 07:40 AM, Nick Coghlan wrote: >> >> Basically, I suggest implementing the current bug fixes & minor >> features AC patch you're working on, and then calling it done >> for 3.4, with only outright bugs in existing conversions to be >> fixed be

Re: [python-committers] PyCon Language Summit: Wednesday 9th April

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/12/13 00:22, M.-A. Lemburg wrote: > Like many other systems, Zope and Plone only support a few Python > versions for each release. If you want to upgrade to later Python > versions, you have to upgrade to newer Zope and Plone versions as > well.

Re: [python-committers] PyCon Language Summit: Wednesday 9th April

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/12/13 18:19, Antoine Pitrou wrote: >> Define "sunset" :) > > A romantic evening with the bsddb module perhaps? Then we tie it to > a weakref and throw it in the ocean. bsddb, Glup! :-). I can't attend the summit, but I would like to discuss DT

Re: [python-committers] Closing the 2.6 branch?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30/10/13 15:18, Benjamin Peterson wrote: > 2013/10/30 Barry Warsaw : >> Now that 2.6.9 is out, I wonder if there's anything we can or >> should do to the Mercurial repository to explicitly prevent >> commits to the 2.6 branch? We have we done to

[python-committers] Inconsistency in Mercurial repository

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pristine clone from http://hg.python.org/cpython/ """ [jcea@babylon5 cpython]$ hg verify checking changesets checking manifests crosschecking files in changesets and manifests checking files 9928 files, 85259 changesets, 188148 total revisions [jcea@

[python-committers] Timeframe for 2.7.6

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is there any release date/estimation for 2.7.6?. - -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/

Re: [python-committers] SSH key changed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/08/13 20:19, Antoine Pitrou wrote: > Le mardi 13 août 2013 à 19:05 +0200, Jesus Cea a écrit : >> I would like to replace my 1024 bit SSH key with a brand new 2048 >> bit key. What would be the procedure? > > You can jus

[python-committers] SSH key changed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I would like to replace my 1024 bit SSH key with a brand new 2048 bit key. What would be the procedure? I am talking about "hg.python.org". I don't think I have any other SSH access under python.org. Please, confirm. Thanks!. - -- Jesús Cea Avión

Re: [python-committers] Policy for committing to 2.7

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22/06/13 22:39, R. David Murray wrote: > My understanding is that there is an additional category that we > allow beyond what Barry mentioned: things that add support for > "stuff" that is analogous to the build enhancements: platform > changes we

Re: [python-committers] 3.2 -> 3.3 merge pending?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29/05/13 16:41, R. David Murray wrote: > I asked about this on IRC and was told that 3.2 is now a > standalone branch like 2.7. Security fixes will be applied by the > release manager only, and Georg doesn't see any point in null > merging the comm

Re: [python-committers] Relicensing source code for inclusion in Python

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/13 18:30, Antoine Pitrou wrote: > I wrote to the authors (Brendan Cully and Mads Kiilerich) and got > their informal approval for relicensing and inclusion in Python. They could sign the contributor agreement and then propose a patch for incl

Re: [python-committers] Please don't commit to 3.2 branch anymore

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30/03/13 16:10, Jesus Cea wrote: > Something simple would be for the hook to refuse any commit in > that branch UNLESS it is coming from the maintainer. BTW, are the hooks available anywhere. I am interested in the "create patch"

Re: [python-committers] Please don't commit to 3.2 branch anymore

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30/03/13 15:15, R. David Murray wrote: > This is the first time we've been in the situation of having a > security-only branch in Mercurial (other than 2.7, which is its own > head). So I don't believe we have articulated a procedure yet. I am ask

Re: [python-committers] Please don't commit to 3.2 branch anymore

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/03/13 08:55, Georg Brandl wrote: > with 3.2.4 being the last regular 3.2 maintenance release and the > rc out of the door, the 3.2 branch should only be committed to for > security releases. So please don't commit anything there anymore. > To he

Re: [python-committers] MSDN subscriptions - new or renew

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was wondering if we could ask Oracle (pufff) about Solaris 10/11 patch support :-?. - -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j.

Re: [python-committers] Anatoly Techtonik's contribution

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/12/12 17:38, Brian Curtin wrote: > On Wed, Dec 26, 2012 at 10:20 AM, Ezio Melotti > wrote: >> And a side effect of being welcoming is that you get every kind >> of people. Different people have different behaviors and skills. >> I don't think hi

Re: [python-committers] Branches support status (Re: 3.3 branch created in main repository)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/12 02:25, R. David Murray wrote: >> 3.3 will receive bugfix updates approximately every 4-6 months >> until one release after the release of 3.4.0 final. After that, >> security [...] > As a native English speaker it is not immediately obviou

Re: [python-committers] Branches support status (Re: 3.3 branch created in main repository)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/10/12 14:23, Georg Brandl wrote: > I've now added lifespan information to the 3.2 and 3.3 release > schedule PEPs, perhaps Barry and Benjamin could do the same for > 2.6 to 3.1. http://python.org/dev/peps/pep-0398/ """ 3.3 Lifespan 3.3 will r

[python-committers] Branches support status (Re: 3.3 branch created in main repository)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29/09/12 10:35, Georg Brandl wrote: > Until the last ordinary 3.2 bugfix release is done (which will be > soon), the usual procedure for 3.x will be to check into 3.2, merge > into 3.3, and then merge into default, except of course for a) > fixes of

Re: [python-committers] Alexander Belopolsky

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/09/12 13:26, Georg Brandl wrote: > May I note that it's commonly considered bad practice to put the > name of a person in the subject without any explication? E.g. > "Commit privileges for Chris Jerdonek" is fine, "Alexander > Belopolsky" is not

Re: [python-committers] Alexander Belopolsky

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21/09/12 03:09, Alexander Belopolsky wrote: > FWIW, here is what Martin wrote to me ~ 1.5 years ago. If the > form has not been found by now, it probably cannot be found at all. > I have no problem resubmitting it again if necessary. I had to send

[python-committers] Alexander Belopolsky

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Belopolsky is a core developer but the bugtracker doesn't have a "contributor form received" flag for him? An oversight?. Can anybody check the forms and change the flag? Check: Thanks!. - --

Re: [python-committers] Cutting 3.3 branch now. Why not?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29/06/12 10:07, Georg Brandl wrote: > And as Ross says: you *can* use the buildbots for personal > branches. I missed that. How is it done?. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es

[python-committers] Cutting 3.3 branch now. Why not?

!). No need to "press me" with an ¿obsolete? technical limitation. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ .

Re: [python-committers] Mercurial upgrade

on. I am fine with that, if somebody with access takes care to do a "hg verify" frequently :). - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://w

Re: [python-committers] Mercurial upgrade

is... quite experimental and not garanteed:). And yes, I have read your posts to HG development mailinglist in May, and I have big hopes for "generaldelta" or something close to it. But I will wait until is "official" (luckily activate per default for new repositories/network c

Re: [python-committers] 3.2.1 rc 2

one week later. Would you comment about the push policy to 3.2 branch?. Are you doing the release work in a separate clone?. Can we push to 3.2 with no restrictions?. That would be a very nice side effect of mercurial migration. - -- Jesus Cea Avion _/_/ _/_/_/

Re: [python-committers] English 'precise' is only an adjective, not a verb.

Don't ask me for the plural of "virus" in different lenguajes :-p. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/

Re: [python-committers] Committer rights for Nadeem Vawda

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/11 04:48, Jesus Cea wrote: > Too late. Being in the field for the last ~15 years cualifies me as > "please, don't ask me what I do for a living in your party, if you > expect to sleep comfy tonight". Do not ask me e

Re: [python-committers] Committer rights for Nadeem Vawda

ere can I find your PhD online? :). (Congrats for your recent PhD!) - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/

Re: [python-committers] Committer rights for Nadeem Vawda

ly pointless considering you already have > commit privs... When I -slowly and sneaky- trojanize socket module and, additionally, add all the buildbots to my spambot network, I will not use my own SSH key. I promise :). I should quit IT security and grow vegetables somewher

Re: [python-committers] Committer rights for Nadeem Vawda

t...@python.org? > Or? What is preventing me to send a fake SSH key to that acount, from a gmail address, saying "hi, this is Nadeem. You are waiting for this" ;-). - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@

Re: [python-committers] PEPs repo converted

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 PEP 0001 still lists SVN as the way to checkout/commit PEPs. I guess that place would be the right place to document the details about keywords & mercurial. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jce

Re: [python-committers] PEPs repo converted

ne other than python.org. > Those who edit the PEPs just need to keep the $Revision$ and $Date$ > intact. So, must I disable the extension KW again?. I am confused. Maybe editors simply must keep "$Revision$" and "$Date$", since those keywords are expanded in the

Re: [python-committers] PEPs repo converted

documented somewhere... :). BTW, can I actually push to "hg.python.org/peps", as indicated?. I would expect something like "ssh://h...@hg.python.org/peps". - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea

Re: [python-committers] [PSF-Members] [Fwd: Re: Push rights for Ross Lagerwall]

and investing time being sure everything is ok. That said, I have used the same PGP key for 15 years. Would be nice if a digital signature would be enough. I am probably an exception, nevertheless. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es -

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

d it over. Could I read it too?. I have been using HG for the last three years, at least. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@j

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/02/11 01:07, Antoine Pitrou wrote: > > Le samedi 05 février 2011 à 01:00 +0100, Jesus Cea a écrit : >>> Someone could sit and produce a >>> written proposal evaluating the various possibilities, and we can >>&

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

want the option to include arbitrary repositories around in the buildbot infraestructure for, let say, developing long term features. 2.7: maintenance branch. 2.7.x: clone of 2.7 to host patches for 2.7.x when 2.7 is closed (RC state) getting ready for releasing 2.7.(x-1). - -- Jesus Ce

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

3.x fixes to 2.7, of even worse, developing your patches in 2.7 and "up-porting to 3.x"... That is an entirely different topic. With current python-dev commitment, any bug discovered in 3.1 that affect 2.7, should be solved in both. In fact, 2.7 fixing should more priori

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

is still hanging around. Or you can force this via a push "hook": no heads left behind! :-) I just wrote an email about this. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ ja

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

e in trunk). Solving this conflict is trivial (just drop that change), and now you can retry merging again, this time successfully. Ideally, when you push to the repository, you push your patches *AND* the merges, all in an atomic operation. So you don't move the merge burden to somebod

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

Not sure if this should be a real rule, but if "old" and "new" reside in the same repository (for instance, named branches), you can check this in the push "hook" living in the server. That is, the hook check that the changesets you are pushing don't create a new

Re: [python-committers] Create a Mercurial repository with a branch per issue

es [...] - -M --no-merges do not show merges [...] """ Would be interesting that "bisect" would be "improved" to follow only the first parent in a merge. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - h

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

;F->G->H When you merge you have: A->B->C->D->I \ / \->E->F->G->H-/ Code in "I" contains all "B", "C", "D", "E", "F", "G" and "H". This merging is "a

Re: [python-committers] Create a Mercurial repository with a branch per issue

ributors is > going to grow with Python under a DVCS +1. But first we need the mercurial switchover to be done and to get some first hand experience before writing down the best practices *wiki* :). - -- Jesus Cea Avion _/_/ _/_/_/

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

candidate. Patching is very restricted. If we had a 3.2.0 release candidate clone, MUST SHIP changes would be in the 3.2.0rc repository, but patches planned for 3.2.1 would be being already being committed the clone. When 3.2.0 is released and the branch is marked as "maintenance", the 3.2.

Re: [python-committers] Create a Mercurial repository with a branch per issue

on has a patch in his own repository, and you try to merge back, you will get again the original changeset list, two heads, etc. As a general rule, rebase should be done ONLY in personal clones not shared by anybody. Or, in this particular case, a clone

Re: [python-committers] Create a Mercurial repository with a branch per issue

Rebasing is good before committing to the "real" repository, but anybody with a checkout clone will suffer. I guess the clone should be automatically destroyed as soon as the clone is merged back to the real repository. - -- Jesus Cea Avion

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

s, doing thing "the right way" would help too. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/11 10:54, Nick Coghlan wrote: > On Fri, Feb 4, 2011 at 1:17 PM, Jesus Cea wrote: >> "Up-porting" CAN'T be forgotten because it is done "automagically" vía >> mercurial merges. That is the point... &g

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

it is done "automagically" vía mercurial merges. That is the point... - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/02/11 13:04, Nick Coghlan wrote: > On Thu, Feb 3, 2011 at 10:37 AM, Jesus Cea wrote: >> In fact, "up-porting" is usually better, because you don't have to think >> if you must downport or not. Versión "n+1&quo

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

that a patch is already manually committed in both lines, and cope with that gracefully when merging. I am sure we are not alone with these issues, and I hope somebody is actually doing something about it. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.e

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

t there only things that MUST be in 3.3.0. For general development, commit to "py3k"". Anybody can merge from "beta" *TO* "py3k", for "up porting". The trick here is to patch the oldest supported version, and "up

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

try to merge back (same patch present in both lines, but no metadata saying so). But that seems an issue with current HG/cherrypick extension, not with an abstract mercurial inability. In fact, python could be a push to improve that in HG. - -- Jesus Cea Avion

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

"backports" from the main development line (that is, backport to candidate release from the mainline), those "doesn't count" to the complexity. Ideally, a release candidate clone would have very few patches, and most of them coming from the main development (or main bra

Re: [python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

ycon 2011 will mark the second anniversary of Guido's pronouncement. If we > do nothing else in Atlanta, can we *please* *please* *please* come away from > there with the conversion operationally completed? +inf!. - -- Jesus Cea Avion _/_/ _/_/_/

Re: [python-committers] New contributors, don't forget to send in a contributor form!

; form: http://www.python.org/psf/contrib/ ASAP. Maybe would be a good idea to write down a checklist for new committers: get a mentor, send the SSH key, be sure have signed the contributor agreement, subscribe to the right mailing lists... - -- Jes

Re: [python-committers] Partial commit privileges

ifference between core committers and external developers will diffuse. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _

Re: [python-committers] Blocking feature backports

deferral of beta1 until mercurial migration. Anything pushing mercurial migration would be good. But Beta1 is already out... Would be shameful to manage 3.2.x using svn... - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea

Re: [python-committers] Providing .tgz sources

know about xz yet (not to mention old Debian / RHEL > machines). So I would vote to continue providing .tar.bz2 and/or .tgz > tarballs. Providing XZ files *IN ADDITION* to gz/bz2 will increase the mindshare for the format. I am checking the webpage and installing the XZ tools just now :-

Re: [python-committers] Blocking feature backports

ars since Mercurial decision was done, let me daydream a bit :-). And I do actually have confidence that the people on charge of this migration have set a realistic milestone. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es -

Re: [python-committers] Blocking feature backports

g our own > patches, but otherwise I think that it isn't being used. Remember that after 12th December, with Mercurial becoming the primary version system, the dynamic will change a lot. Still 12 days to go. I will be very happy :). - -- Jesus Cea Avion _/_/ _/_/_

Re: [python-committers] New hg repo ssh URIs

onsidered preferable. Are those repositories read/write?. What is their use TODAY?. Only for being ready for 12 december?. The push will be thru SSH only?. No option for HTTPS pushing?. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://ww

Re: [python-committers] trunk is open

remains intact. All these will be meaningless after we finish the mercurial migration. God, it is about time :-). - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/

Re: [python-committers] Mercurial Status?

aking the > repositories the main development ones. Ok. Thanks for providing a schedule :). Good luck (and justice!) with your (both) thesis. Uhmmm, what is the plural for thesis, in english?. In Spanish it is the same word, changing the prefix article: "la tesis"/"las tesis&

[python-committers] Mercurial Status?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 How is migration to Mercurial going?. Showstoppers?. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org

Re: [python-committers] PEP checkin process

e to work by > overriding PYTHON as Benjamin suggests). Not only that, but the > makefile builds all the PEPs when I generally only care about the PEP > I'm working on and PEP 0. The "make" should include dependency information to only

Re: [python-committers] 2.7 almost out the door

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/07/10 17:45, Benjamin Peterson wrote: > 2.7 has been tagged, and I have uploaded docs and the source tarballs > to python.org. I will wait on binaries before announcing the release. The end of an era. Congratulations to all. - -- Jes

  1   2   >