>> I'm trying to get the 3.3 and 3.4 branches so I can check my libraries
>> compatibility with older versions, but I do not see those branches as being
>> available:
>>
>> How can I get those?
>>
>>
>
>
> 3.3 and 3.4 existed before the migration from GitHub, so we don't have the
> branches.
>
>
On 12 April 2017 at 03:10, Mariatta Wijaya wrote:
> Back to the original issue with reviewing the PR
> https://github.com/python/cpython/pull/851
>
> Other than not being able to review the diff, is there any other problem?
> Can the PR be reviewed as is?
>
> Martin, you said
ship.
>>
>> On Mon, Apr 10, 2017 at 12:12 PM, Terry Reedy wrote:
>>>
>>> On 4/10/2017 12:54 PM, Guido van Rossum wrote:
>>>>
>>>> So the response from Martin Panter
>>>> (https://github.com/python/cpython/pull/851#issuecomment-29275
> On Mar 10, 2017, at 5:13 PM, Brett Cannon wrote:
> Is the mention bot helpful? (Our config is at
> https://github.com/python/cpython/blob/master/.mention-bot and the docs are
> at https://github.com/facebook/mention-bot)
> On Mar 10, 2017, at 8:38 PM, Martin Panter wrote:
>
> On Mar 10, 2017, at 5:13 PM, Brett Cannon wrote:
> Is the mention bot helpful? (Our config is at
> https://github.com/python/cpython/blob/master/.mention-bot and the docs are
> at https://github.com/facebook/mention-bot)
On 11 March 2017 at 00:32, Donald Stufft wrote:
> I’ve found it helpful t
>> On 11/22/2016 08:16 PM, Ned Deily wrote:
>> > On Nov 22, 2016, at 11:06, Xavier de Gaye wrote:
>> >> The configure file on the default and 3.6 branches have been generated
>> >> with autoconf 2.70 once again. This is annoying when you have to
>> >> maintain patches to this configure file in
On 24 June 2016 at 09:29, Matthias Klose wrote:
> On 24.06.2016 11:14, Larry Hastings wrote:
>> Heads up! This is a courtesy reminder from your friendly 3.4 and 3.5 release
>> manager. Here's a list of all the changes since 3.5.2rc1 that are currently
>> going into 3.5.2 final:
>>
>> * 155e6654
On 29 January 2016 at 21:59, Serhiy Storchaka wrote:
> On 29.01.16 21:56, Ezio Melotti wrote:
>> On Fri, Jan 29, 2016 at 8:00 PM, Serhiy Storchaka
>> wrote:
>>> Some deprecation can be documentation-only.
>>
>> Do you have examples where this has been done?
>
> An attribute of a module. [. . .]
>
> What and when to deprecate
> ==
>
> * The number of releases before an API is removed is decided
> on a case-by-case basis depending on widely used the API is
depending on [how] widely used
> * In general it's better to be conservative, and if the API is
> deprecated
On 3 September 2015 at 10:03, Senthil Kumaran wrote:
> I did a merge head with Victor's change in 2.7 before pushing my change.
> Can someone confirm if I did it right? If anything was wrong, how to correct
> it?
It looks like you did it right. If I compare the merge result with the
second merge
a repository URL and branch name
into the buildbot configuration, and a post-push hook on the repository
to trigger the build. It's actually possible to configure a bitbucket
POST hook to trigger a buildbot build, but we haven't yet integrated
that into the buildbot master.
Regards,
Martin
t to Verisign.
>
> When was that ? I never received such a request.
I sent the request to Jesse Noller, Noah Kantrowitz and Kurt Kaiser on
2014-03-17. On 2014-04-15, Jesse indicated that he had given up.
Regards,
Martin
___
python-committers
know if I can help providing PSF organization verification.
>
> I already completed that for the current cycle.
>
I had asked the PSF for a StartSSL certificate when the previous
certificate expired, and the PSF was not able to provide one. After
waiting several weeks for the PSF t
er to
do the release in early 2015.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Am 17.03.14 16:58, schrieb Jesus Cea:
> 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.
nly
>>> accept security fixes, right?
>>>
>>
>> Typically we do one last release before shutting the last bugfix branch
>> down, but that's Georg's call since 3.3.5 was released so recently.
>
> Given that, I propose 3.3 goes into security fix mode immediately.
d up, by targeting them to
http://hg.python.org/buildbot/empty/
once, and triggering a rebuild.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
lem).
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
code.
I also see
Reply
which really ought to fill out the in_reply_to field (with Message_2687)
If anybody wants to investigate: the source of this is at
http://hg.python.org/tracker/rietveld
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Am 27.01.14 21:24, schrieb Antoine Pitrou:
> As a sidenote, why is Larry green on this page?
Because he used the keyword LGTM.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listi
extended RC phase to play out.
The hope is that, instead of sitting idle, they actually start working
on bugs, and contributing to finishing the release.
With a DVCS, there is of course an alternative, where one could start
working on new features while
ne.
Patrick Koetter has requested a new certificate, which I have now installed.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Quoting "R. David Murray" :
You should have the necessary privileges on the tracker now, since I
think you ought to. (I don't have them on the meta-tracker, so Martin
will need to handle that one.)
I've restricted anatoly's access there; I've also given you
the "Anonymous" role (meaning that
it makes no difference whether you are logged in or not).
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
It is a problem. And choosing to not participate is a perfectly
rational and legitimate response. But it doesn't necessarily follow
that banning someone is a better response.
I think it is. Based on past experience, it would be temporarily anyway,
and it may buy us a year or
3b (geschlossen)
In addition, I *think* we have a hook on the master that prevents
further pushes to the branch.
> Also, can anybody think of anything in the devguide that needs to
> be updated?
Not the devguide. If anywhere, in PEP 101.
Regards,
Martin
___
have
different test cases, anyway.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
all unrealistic.
That, or some text explaining what to expect, would be good to have.
It's easy enough: the tag is likely to occur 24h before the scheduled release.
Regards,
Martin
___
python-committers mailing list
python-committers@pytho
ick the actual client
in providing the proper token that the server would verify, see e.g.
http://utcc.utoronto.ca/~cks/space/blog/tech/SshAndMitM
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
when it was transmitted from python.org to
Roger's SMTP server. So you really need to PGP sign it :-)
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
Am 26.03.13 13:56, schrieb Eric V. Smith:
> I completely agree. "We'll notice the damage" is not a great reason to
> avoid publishing the fingerprints.
IMO, the proper way is to publish SSHFP records in DNS. Unfortunately,
DynECT currently does not support RFC 6
.
The test suite is here of least concern, as there are thousands of
incoming links to various pages. These need to be preserved as much
as feasible (possibly using redirects).
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
;d propose the policy
- he must not reopen any issues. If he really thinks important
information was not considered, he can post them to the closed issue.
- he must not resubmit a duplicate of one of his closed issues.
Regards,
Martin
___
python-committers
antly avoid replies that convey the
same negative feelings.
I'm happy to ignore him on mailing lists (and have done so for some
time). On the bug tracker, I cannot ignore when he reopens issues or
resubmits new duplicate issues.
Regards,
Martin
___
p
neral for this kind of behavior: I still think he fits the
description in
http://www.youtube.com/watch?v=Q52kFL8zVoM&feature=gv
I think he is poisenous to the Python project. If you haven't
seen the video, please watch it all.
Regards,
Martin
,
and I really tried for a few days. Eventually, I gave up. Unlike Brett,
I actually shouted.
He cites his lack of mastery of English as his main problem, but I do
think there is much more.
So I think that path has already been investigated sufficient
ons in the most negative way.
For several times, I was close to banning him from certain systems I
care about, but rather chose to ignore him instead.
If the wiki maintainers want to ban him from modifying the wiki, they
have my support.
Regards,
Martin
_
ncies and them somebody
fixing them is something that could work.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
. The last BDFL decision (that I'm
aware of) is that 2.7 should be supported "indefinitely", which is
not "infinitely".
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
trol; he should just stick to committing where
he is supposed to (just as everybody else). Key managers are currently
Georg Brandl, Antoine Pitrou, and Brett Cannon. I keep forgetting whether
there is an email alias for them.
Regards,
Martin
___
py
ck to Barry Warsaw's passion for
detail and documentation).
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
ad
promotion of their product in mind, they actually do demonstrate
a real interest in free software.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
.org. Objections?
>
> None from me.
It's gone!
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
On 02.07.2012 00:48, "Martin v. Löwis" wrote:
> I'll report if we found something that can be considered a
> permanent solution.
Antoine managed to reduce the memory usage of Mercurial quite
drastically. Not sure which contributed most, but
a) hg was upgraded to 2.2
b) a
code.python.org was meant as a VCS-independent hostname for CPython;
PEP 385 chose to use hg.python.org instead.
I'd like to delete code.python.org. Objections?
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
port if we found something that can be considered a
permanent solution.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
We (primarily Antoine) just migrated hg.python.org to OSU/OSL.
Everything should continue to work as it did before, except that the
IP address of the machine has now changed.
If there are any issues, please let us know.
Regards,
Martin
___
python
retain copyright. If Google is a student's
sponsoring organization, then the student keeps copyright to her/his
code.
The Google blanket agreement only applies to Google employees (which
quite a number of core contributors are).
Regards,
M
tracker to represent company agreements
a priority.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
l, I would have put EungJun Yi into
Misc/ACKS (for doing the research), and asked him for a contributor
form.
If we are to require a signed agreement from smaller changes too, the
devguide should be updated.
Will do!
Regards,
Martin
___
python-committe
would
gain a desirable reduction of workload if Daniel could push changes himself).
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
s if these people had
individually submitted a contributor form.
Regards,
Martin
On 01.05.2012 17:32, Pat Campbell wrote:
Hi Maria:
Thank-you for submitting your CLA.
Pat
2012/4/30 Maria Lysek mailto:maria.ly...@allegro.pl>>
Hello,
__ __
I am pleased to send you CLA which
gards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
Zitat von Philip Jenvey :
On Apr 22, 2012, at 10:26 AM, Martin v. Löwis wrote:
You may wonder what changed between before and now: we (the PSF) now
have a good management of the forms, thanks to them being listed in
Roundup,
Where exactly is this listing?
It the asterisk ('*')
of the forms, thanks to them being listed in
Roundup, and thanks to Pat (Campbell) keeping track of all forms that
we receive. So we (the committers) are now in a position to actually
verify that we have a contrib form received before deciding whether or
not to commit a patch.
Regards,
Martin
I noticed that I don't have that fancy python logo next to my name
on the bug tracker, indicating that I am a committer. Is that
fixable? My user account is "krisvale".
Done!
Martin
___
python-committers mailing list
py
>> Am 24.02.2012 17:49, schrieb Benjamin Peterson:
>>> Hi Ned and Martin,
>>> 2.7.3rc1 and 3.2.3rc1 are tagged in the repo ready for binaries.
>>
>> 1b605fb13977c887a9554a9896b8 16081986 python-2.7.3rc1-pdb.zip
>> 53439ec0110345225f5f0951f00bc38
Am 24.02.2012 17:49, schrieb Benjamin Peterson:
> Hi Ned and Martin,
> 2.7.3rc1 and 3.2.3rc1 are tagged in the repo ready for binaries.
1b605fb13977c887a9554a9896b8 16081986 python-2.7.3rc1-pdb.zip
53439ec0110345225f5f0951f00bc387 17220674 python-2.7.3rc1.amd64-p
More than 5 years after its initial release, I have now closed the 2.5
maintenance branch. Please don't commit anything to it anymore.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/ma
just be a nice to have, so
> don't worry about it if it isn't trivial to add.
I think this would be a change to buildbot itself, rather than a
configuration parameter. Consider requesting it on the buildbot
tracker: http://trac.buildbot.net
Regards,
Martin
_
> It's also possible that we should be encouraging greater use of
> Mercurial Queues [1] and making them an official part of our
> development process.
Can you publish/push a patch queue to a remote repository?
Regards,
Martin
___
pyt
> Until mercurial has better tools to bundle multiple changesets into a
> single coherent group of changes, it's still preferable to do the
> export/import dance.
Why did we migrate to Mercurial, then?
Regards,
Martin
___
python-committer
t; Yes, go ahead.
Really??? I have some changes that I need to commit to 2.7 that do need
to go into 2.7.2. So how are you going to manage these?
I rather recommend that the 2.7 branch is frozen until the final
release, and any changes are only merged afterwards.
This is a mess.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
y change to that branch must have a NEWS entry (which
is not a new requirement), so after synching, NEWS should be identical
in svn and hg.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
push it.
For the 2.5 branch, I just accepted that hg and svn will differ in the
EOL representation of some files. So when comparing trees, use diff -w
or -b.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.p
ill have to be
applied.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
is blocked from
accepting commit unless they come from you or me.
It would be better, IMO, if there was a single developer who would
migrate changes to svn, or to have some semi-automatic procedure for
that.
Regards,
Martin
___
python-committers ma
> Martin, Ned: I would say it's not mandatory for the beta release to have
> binaries, but you might want to test out your toolchains against the new
> process too.
Indeed. I'd prefer if the release clone is public somewhere, so that I
can point my local clones to i
rm 'precisar'.
FWIW, we have "präzisieren", supposedly imported from the French word
in the 19th century. Too bad the Englishmen failed to accept that import
:-( The best the dictionaries come up with (besides "to specify")
is "to state more precisely", &quo
able to reconstruct the full history). So it
might have been possible to deal with it, had it been noticed.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
an't give reasonable file path names to such files. OTOH,
our approach to svn (i.e. multiple projects in one repository) is
so uncommon that the Mercurial people are likely to ignore problems
arising out of it.
Regards,
Martin
___
python-committers mailin
cannot "add" any past history in any case.
I propose that the redirector (hg.../lookup) redirects to the subversion
viewer if it can't find a matching hg revision.
Regards,
Martin
___
python-committers mailing list
python-committers@pytho
> Proposal: create a keymanagem...@python.org (or maybe just k...@python.org)
> alias that forwards to all current key managers (other than myself, these are
> Brett, Martin and a few others who haven't used the privilege recently).
I had meant to create such a list for the past f
ice of the editor.
In any case, the PEPs don't show up in docs.python.org (AFAIK), but
in http://www.python.org/dev/peps/.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
ed, I believe.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
etting updated
regularly.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
I added a boolean flag to the bug tracker indicating what user accounts
belong to committers. Please check that the flag is set in Your Details,
Is Committer. If it's not, please let me know.
Regards,
Martin
___
python-committers mailing list
p
So the next logical step would be to ask him. If Ross said that
he did send the form, that would be good enough for me to proceed.
That would also be a *solution*.
Martin, why don't you implement your solution yourself, if you think the
process is not a problem? That would be a good w
Am 10.03.11 00:45, schrieb Steve Holden:
On Mar 9, 2011, at 10:28 PM, Martin v. Löwis wrote:
We don't need an explanation, we need a *solution*.
Please speak for yourself only. Is it just you being upset to have
to use paper, or is Ross Lagerwall actively refusing to put his
signature
> We don't need an explanation, we need a *solution*.
Please speak for yourself only. Is it just you being upset to
have to use paper, or is Ross Lagerwall actively refusing to
put his signature on a piece of paper?
Regards,
Martin
__
it an svnmerge for
> py3k-cdecimal? Or is this now impossible?
It's impossible now; the repository is read-only (IIUC)
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
Am 24.02.2011 02:39, schrieb Brett Cannon:
> Not sure if Martin is the only person who can fix this, but it would be
> nice to have those URLs working.
I have added a redirect for 3.2.x. I haven't added one for 3.2.0, since
we currently don't have any redirects for X.Y.0, only f
if
> I see an update to a .in file, though I know that isn't always necessary).
At least the third one should be identical to your current setup, except
that
a) changes flow into the other direction, and
b) there is no server communication to move patches across branches
ch, one for the maintenance
branch which preserves backwards compatibility, and another version
that fixes it in the right way. I think I regularly contributes
two or three such changes to every feature release of Python.
I think a few other committers have als
. So with the new workflow, even more patches will be forgotten
wrt. backporting.
It would still be possible that somebody else backports for them,
but that will be more tedious than it is now with svnmerge (since
you first have to transplant, and then merge back the transplanted
patch, which shoul
olved, so merging becomes more difficult.
I guess it would be possible to send a daily report on pending
merges (no report if no pending merges), either to python-dev
or to the original committer (it might be also possible to determine
the original pusher, and send mail to him instead).
Regards
le test runs into this to your taste.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
(IIUC, the command is called "transplant").
I don't know whether hg keeps track of what patches have been
transplanted, but I doubt it.
In any case, this discussion reiterates my point that this
project (Mercurial migration) really needs a project lead,
who then will also pronounce
ot commit rights for a
specific module only, see Misc/developers.txt. This is nowhere enforced,
but since committers know what they are supposed to work on, and since
everything is traceable, they stick to the rules.
Regards,
Martin
___
python-committe
s SSH key and subscribe to the committers list, and give any
instructions you deem necessary.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
ported
anymore. I'd say anything since Solaris 9 (released 2002) needs to
be supported. Unfortunately, I don't have any installation of that
anymore, so I'm not sure whether it had bzip2 - I doubt it, but
it is certainly possible to obtain a bzip2 binary from S
n to make sure
> people notice it. I'd also vote for listing the file size on the
> download page, but that's just another step for release managers that
> I don't want to burden them with.
You would also need to specify what page you refer to as "the download
page".
cope with the tgz just fine.
Per svn:eol-style, the files that need to be CRLF are marked so,
and should remain usable even with a Unix export. The C and
Python files will have LF only, which VS and Python can deal with
just fine. Only notepad would do nonsense when trying to open such
a file.
Am 05.12.2010 20:40, schrieb Jeroen Ruigrok van der Werven:
> -On [20101205 20:23], "Martin v. Löwis" (mar...@v.loewis.de) wrote:
>> For those of us involved in the release process, every single file is a
>> big problem, indeed. Seriously.
>
> Correct me if wrong, b
ening that would happen if we switch
to Mercurial in the middle of release candidates. I expect the initial
release using Mercurial to just not work, plus I plan to need several
days to make the release. Doing so under the time pressure of a release
candidate is not something I look
s of downloads:
Python-2.7.tgz 32059
Python-2.7.tar.bz2 24986
python-2.7.msi577240
In November, the numbers were
Python-2.7.tgz 24535
Python-2.7.tar.bz2 20797
python-2.7.msi 569328
Regards,
Martin
___
python-committers mailing list
pyt
> I mean, seriously, is providing some extra files in a particular compression
> format the biggest of our problems?
For those of us involved in the release process, every single file is a
big problem, indeed. Seriously.
Regards,
Martin
___
27;d still like to defer beta1 until after the Mercurial
switch (or alternatively, do the final 3.2 release from subversion
as Raymond suggested).
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
t possibly make the switch in 8 days from now.
More likely, the switch will happen next year.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
s in comments and a few specific encoding test cases.”
>>
>> You seem to have missed part of the sentence.
>
> No, I didn't. Try again.
Ok, my try: You deliberately have chosen to ignore it. Right?
If it's not that, I can't guess what you may have meant.
Reg
1 - 100 of 203 matches
Mail list logo
