On Sun, Mar 6, 2011 at 7:37 PM, ned.deily <python-checkins(a)python.org> wrote:
> changeset: 376:ad3278cfc5f6
> user: Ned Deily <nad(a)acm.org>
> date: Sun Mar 06 01:37:13 2011 -0800
> More miscellaneous review comments.
> diff --git a/committing.rst b/committing.rst
> --- a/committing.rst
> +++ b/committing.rst
> @@ -3,6 +3,9 @@
> Committing and Pushing Changes
> +.. TODO: include a checklist of items to be included in a commit?
> + e.g updated Misc/NEWS entry, tests, doc
For non-Windows, get people to run "make patchcheck". Windows devs
will need a manual checklist, though.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
On Sun, 6 Mar 2011 17:32:40 +0100 (CET)
martin.v.loewis <python-checkins(a)python.org> wrote:
> -def find_bases(data, rev):
> +def hg_splitpatch(data):
> + patches = 
> + filename = None
> + for line in data.splitlines(True):
> + if line.startswith('diff -r'):
Now I understand why you would like to discourage git diffs.
But, as I said back then, I don't think it's worthwhile to try and
compute the base rev. Most reviewable patches should apply cleanly
against the latest revision on "default", otherwise we're gonna ask the
poster to regenerate the patch anyway.
According to our security fix policy, Python 2.5 releases can happen
until September 2011. Since there are unreleased changes, I plan to
make a release "soon", which likely means April. I'll call this
tentatively the "final" release of Python 2.5, even though security
issues discovered after wards could require yet another release in
So if you have any pending security fixes that you want to get into 2.5,
please start committing them. Committing them into Mercurial is fine,
even though I'm going to make the release from Subversion (copying all
new changesets over as necessary).
What's the easiest way of finding which tests failed on buildbot builds? I mean,
is there anything easier than using the Web interface to browse to failing
builds and then looking at the stdio output in a browser?
In preparation for the hg switch, I would recommend that, if you have
any feature branches managed with svnmerge, you sync them with the py3k
branch before we switch. That way, it will make it easier to "bridge
the gap" when you create a new repository for your work after the
switch (the svnmerge information isn't retained in the converted repo).
For the record, and as mentioned in the updated PEP 385, we plan to do
the final conversion on the 5th (that is next Saturday).
For the record, the reason these emails look a bit strange (and appear
to be pushed by Dirkjan (sorry)) is that they were done directly on the
server with the settings of the local user "hg".
On Sun, 06 Mar 2011 02:36:25 +0100
dirkjan.ochtman <python-checkins(a)python.org> wrote:
> [0;33mchangeset: 48:d2aca4834bb9[0m
> user: Antoine Pitrou <solipsis(a)pitrou.net>
> date: Sun Mar 06 02:36:25 2011 +0100
> Hopefully fix the issue where notification of merges to buildbot
> wouldn't notify all changed files (because they are copied from
> the second parent). Untested still.
> diff --git a/hgbuildbot.py b/hgbuildbot.py
> --- a/hgbuildbot.py
> +++ b/hgbuildbot.py
> @@ -84,9 +84,18 @@
> manifest, user, (time, timezone), files, desc, extra = repo.changelog.read(node)
> parents = [p for p in repo.changelog.parents(node) if p != nullid]
> branch = extra['branch']
> - # merges don't always contain files, but at least one file is required by buildbot
> - if len(parents) > 1 and not files:
> - files = ["merge"]
> + if len(parents) > 1:
> + # Explicitly compare current with its first parent (otherwise
> + # some files might be "forgotten" if they are copied as-is from the
> + # second parent).
> + modified, added, removed, deleted = repo.status(rev, p)[:4]
> + files = set()
> + for l in (modified, added, removed, deleted):
> + files.extend(l)
> + files = sorted(files)
> + if not files:
> + # dummy merge, but at least one file is required by buildbot
> + files.append("Misc/merge")
> # add artificial prefix if configured
> files = [prefix + f for f in files]
> Repository URL: http://hg.python.org/hooks
-----BEGIN PGP SIGNED MESSAGE-----
I would rather prefer to promote the "-A" parameter to SSH (to use the
local SSH agent be used from the remote development machine) instead of
uploading private keys.
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
jabber / xmpp:email@example.com _/_/ _/_/ _/_/_/_/_/
. _/_/ _/_/ _/_/ _/_/ _/_/
"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://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
On Sat, Mar 5, 2011 at 10:40 AM, Guido van Rossum <guido(a)python.org> wrote:
> That's how I felt 20 years ago. But since then I've come to appreciate
> they as a much better alternative to either "he or she" or "he". Just
> get used to it.
If anyone wants to further explore this question, the Stack Exchange
on English usage is a decent place to start:
What it boils down to is that "their" is the least bad of all of the
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
I am trying to fix the hgeol settings for the vcproj files, with little
success so far. I created
which merely changes the .hgeol file. Now, if you enable the eol
extension, and check this branch out, you immediately get a report
(from hg status) that you have modified all these files. That is
surprising, since you didn't change any file at all.
So how can I fix this properly: so that all files have CRLF, but
are still attributed to whoever last modified them, rather than
having them attributed to me?
How should patches be applied to the cpython repository if they
land in more than one branch?
More specifically, assuming I want to patch all of 2.7, 3.1, 3.2, and
default - how do I apply the patches and how do I merge?