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
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 ('*')
gards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
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
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
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
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
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
,
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
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
have
different test cases, anyway.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://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
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
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
>> 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 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
> 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 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. [. . .]
>
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 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 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 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:
>
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 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
, latin spelling, first.last (although he might
prefer last.first instead - I suppose Yamamoto is the family name),
plus an ssh key.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
> It sounds like Wednesday August 13th will not be feasible, so we'll do
> beta 3 on Wednesday August 20th. I've updated both the PEP and the
> Google Calendar.
I'll be on vacation then, and not be able to produce Windows binaries
(until Septe
.
Are you also planning to produce a 2.4 security (source only) release?
Will the 2.5 release be the final bug fix release?
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/
eState might integrate
them into ActivePython; system vendors can also pick them up
(if they haven't already).
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
Jeroen Ruigrok van der Werven wrote:
> -On [20080812 08:28], "Martin v. Löwis" ([EMAIL PROTECTED]) wrote:
>> For the 2.5, the challenge is to produce AMD64 and Itanium binaries,
>> using vsextcomp (plus the usual problems of collecting all the
>> necessary package
that some patches don't get backported (arbitrarily, depending on how
relevant the committer views that policy).
> Having lockstep 2.x and 3.x release complicates things a bit, but
> because they are lockstep, I'm thinking of them more as the same release
> rather than separate on
ail/hang - it always did in 2.5.x.
> We're not shipping PGO builds for 2.5.x are we?
No. I don't think VS 2003 supported that. I don't do PGO for the AMD64
build of 2.6/3.0, either, because I also have a cross-compilation
environment which prevents that.
> Martin, not sure if
it.
I don't like the arbitrariness that this will produce.
>> I think this is an illusion. When did you last commit something to the
>> trunk, and forward-ported it to the 3.0 branch? When did you last run
>> "svnmerge avail"? Porting patches between 2.6 and 3.0 is any
For a closed branch, you'd open it for the security
> patches when the embargo is lifted, make the commits, then close it
> again. That would at least be a very strong clue that the branch is
> closed :).
That would be fairly easy to do. If there is consensus what branches
are close
part where I'm skeptical about such a policy is that there might
be a shortage of reviewers. What if a patch on Rietvield doesn't find
a reviewer for a month or so? Many patches in the tracker sit there
for years without any committer reviewing them.
Regards,
Martin
_
me machine it runs on itself, and only on that
machine.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
> I'm just thinking that we have a good code review app and a good ticket
> system, maybe we just need to use the code review system more
Rietveld will already send reviews into the bug tracker, assuming you
make the bug tracker a reviewer, or otherwise a message recipient.
Rega
> As far as I'm concerned, +1 for Gerhard being able to checkin vc6 related
> makefiles to the trunk without review (notwithstanding any other
> restrictions imposed by the release manager, etc.)
Hmm - it might be easier to just review them. What's the patch number agai
ly out of scope now.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
>> Press releases can lag behind, but I hope that this time the Windows
>> and OSX installers will be released together with the main tarball.
>
> I agree, but I have not heard from Ronald or Martin about that yet.
That's because you didn't ask, I guess.
> Ro
e same day. To have
binaries released on the scheduled day, the tag should be available
no later than 16:00 UTC (which still means that I'll have to stay in
office longer than usual).
Regards,
Martin
___
python-committers mailing list
python-co
> Yes, of course that makes sense. What would be a better time for you
> Martin? I would like to at least debug this aspect of the PEP so that
> next time we can coordinate better.
As I said: If you create the tag in your morning, I can do the binaries
before heading home. Please send
y that branch needs to be frozen (instead of the
mainline).
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
> You're absolutely right and that sounds good. I will update the PEP
> accordingly. Martin, Ronald, Sean, what timezones are you in? I am
> US/Eastern.
I'm in CET (Central European), that GMT+2 in DST, and GMT+1 otherwise.
As for Sean: Sean and me had agreed that we won&#x
actually get released, later?
IOW, what's the difference to a beta release?
(*) Consequently, there doesn't need to be much more time between
the release candidate and the final release except but a few days,
or, at most, a week.
Regards,
Martin
_
h Python 3.0
(although it looks like you might).
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
ars ago. It's just that
now, the way of addressing them is reconsidered (in the light of
other things having changed along, of course).
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
> At about the same time, Martin said:
>> I agree. I disagree that you should be able to do so with Python 3.0
>> (although it looks like you might).
>
> Why do you disagree that I should be able to do this with Python 3.0?
> (I can guess, but that just increases the
1? (and no, creating a branch just for
the release is no option, because that means you have to copy all
the changes you made on the branch back to the trunk)
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.
g it
releasable; during the release process, the version numbers get adjusted
throughout, and those changes get committed before the release tag is
made.
> Version control systems are built to avoid precisely the situation which
> is being discussed here - we should take
itted to the trunk (or the
maintenance branch), which gets tagged when they are all made. If
unrelated changed are made to the trunk, it can't be tagged anymore,
hence the trunk must be frozen.
Please study the commit logs in detail if its still
branching
>2 - build release kit from branch
>3 - tweak snapshot in branch if necessary, repeat from 2
>4 - when the kit is solid, tag the final branch
>5 - merge relevant changes back to trunk
It's more complicated th
7;m not really in a position to
> help with the above for that period...)
But please do file bug reports, preferably along with any patches to
distutils that you already have.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
ain
> to cut releases 3 weeks in a row?
It's a lot of effort, yes. Also for users, who will have barely
installed one release candidate when the next one comes out.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
h
ts fixed, I
think we need to agree on who is going to produce the binaries, and
using what schedule.)
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
> I thought the PSF had a 10.4 XServe box. Is it gone?
Yes, it's broken.
> Was it a G4 perhaps?
I've now turned it off, so I can't find out anymore.
Regards,
Martin
___
python-committers mailing list
python-commi
> Anyone who feels like biting his head off, go for it.
I think as a starting point, I'll revoke his access to the tracker
(although I guess he'll create a new account in response).
Regards,
Martin
___
python-committers mailing list
pyth
Alexandre Vassalotti wrote:
> On Sun, Jan 25, 2009 at 2:18 PM, "Martin v. Löwis" wrote:
>>> Anyone who feels like biting his head off, go for it.
>> I think as a starting point, I'll revoke his access to the tracker
>> (although I guess he'll create a n
that's now at XS4ALL, but
> currently unused?
Worse than that: it is broken. It can't stay up for more than 30
seconds, before some watchdog mechanism reboots it - too short for
me to find out what the problem is.
Regards,
Martin
___
python-co
idges to
> access the branches. Although I think in either case we could provide
> hosting support for core committers.
That's already the case, for bzr, right?
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
ht
ue (text mode and line endings) definitely
belongs into the list of issues that need to be resolved, and I
think it should be show-stopper if it isn't adequately resolved
(i.e. it needs to be at least as good as CVS and subversion).
Regards,
Martin
and when to use
dumbencode, though.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
eer maintainer
of such a service, though.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
eeded to host the website and the
PyPI sources). It doesn't cost anything to continue to run svn.
(perhaps if all the other projects except for stackless left svn,
I would ask you to "volunteer" some admin time into its operation).
Regards,
Martin
_
ant* that the PEP provides a complete specification right
from the start, or else discussion will revolve around the open issues,
with no conclusion. So I'd rather have the PEP suggest that we switch
to bzr (say), so that I can vote that down, instead of giving options
in
as long as the reason(s) for not switching remain
valid.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
tter, and I don't accept word-of-mouth as
a proof. My own personal experience tells me git and bzr are much
worse than subversion (each in different respects).
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http:/
nough log info to be able to
> determine how common it is that people pull down source kits using Svn?
With the limitation that svn urls are difficult to process, see
http://svn.python.org/webstats/
The actual logs themselves roll over after four da
s...@pobox.com wrote:
> Martin> My own personal experience tells me git and bzr are much worse
> Martin> than subversion (each in different respects).
>
> Perhaps you could relay these shortcomings to Brett or edit them into the
> PEP directly.
As I said: I refra
from whatever hosts)
So the number of visits is probably irrelevant for that site.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
with "we have svnmerge".
That's why I keep arguing that the committers making the original
commits should also merge their changes, individually, into the
respective branches. That way
- commits become separate, and reverting them becomes possible
- the load is shared a
Antoine Pitrou wrote:
> Le dimanche 01 mars 2009 à 00:11 +0100, "Martin v. Löwis" a écrit :
>> That's why I keep arguing that the committers making the original
>> commits should also merge their changes, individually, into the
>> respective branches. That w
> Martin v. Löwis wrote:
>> and that it takes forever
>
> Not sure about that - I *do* port my own changes, and while the merges
> are quicker than a full recompile or running the test suite, they're
> still far, far, slower than applying an equivalent patch or doing
7;m not sure about that. As I
> recall, I've never needed that step.
It should be needed every time you merge into the 3.0 branch, and
yes, it should be "resolved", not "revert".
Regards,
Martin
___
python-committers mai
> I've merged this into release26-maint in r71639. But in order to update
> Python2.6.2 binary, I think Martin's help is needed. Could you?
I won't be re-releasing 2.6.2. We should make a 2.6.3 release instead.
Regards,
Martin
t;make update";
I guess this was incorrect.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
Barry Warsaw wrote:
> On Apr 16, 2009, at 12:34 AM, Martin v. Löwis wrote:
>
>>> I've merged this into release26-maint in r71639. But in order to update
>>> Python2.6.2 binary, I think Martin's help is needed. Could you?
>>
>> I won't be re-rele
e is a single
person working on that transition, so progress is naturally slow.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
ple present at the language summit :-(
So people have continued to merge to 3.0. I think they deserve a 3.0.2
release.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
> TBH, I'm not sure there's enough interest in doing it.
Then announce, to the widest public possible, that there will not
be a 3.0.2 release ever. It's just that the status quo is unsatisfying.
Regards,
Martin
___
python-committers m
Python committers, since SF has stopped
using NIS, or any network user database, for that matter.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
, and so I
believe the problem is only of minor relevance.
I think posting a patch on the 3.1 release page would be sufficient
for now, along with a summary description on the circumstances that
may trigger the bug, and the consequences it may cause.
Regards,
Martin
roblems.
Fortunately, svn has been support --xml for "svn log" for a number of
releases. So svnmerge should switch to use that; it will allow parsing
arbitrary characters in a log message, independent of what the terminal
encoding is.
Regards,
Martin
__
It seems logging is broken in 2.6.3. Should we release
2.6.4 quickly?
http://bugs.python.org/issue7052
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
IW to the Windows gurus.
The final 2.6.3 release mistakenly identifies its svn tag as 263rc1.
It still actually is the final release, as can be seen when looking
at sys.version_info.
Regards,
Martin
___
python-committers mailing list
python-com
> Yes, but what I experienced is much worse - I was actually getting the
> 2.6.2 version of python26.dll due to shadowing, instead of the 2.6.3
> version.
Ah. Did you get a message "[TARGETDIR] exists. Are you sure you want to
overwrite existing files?&quo
ase, it cannot install into system32.
If you then do a "for all users" installation into the same location,
you get the behavior that you observed: python26.dll gets installed to
system32, and you end up with two copies of the DLL.
Regards,
Martin
___
if an 'all users'
> installation was being done, any python26.dll in c:\Python26 would be
> deleted?
Unfortunately, no. That's why the warning message is issued that this
kind of installation is probably the wrong thing to do.
Regards,
Martin
on Friday the 16th?
I'll likely be able to produce binaries only on Saturday (17th), but
otherwise, the schedule sounds find to me (in particular as I'm
travelling next week and won't be able to produce binaries between this
Saturday and next Friday).
Regards,
Martin
__
until 2.6.5 is released.
This also speaks against the patch. Anything being changed in this area
ideally should be the final state of affairs for the rest of 2.6.x.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http
) would cause severe problems. We
are still trying to recover from the switch to VS 2008. That said,
staying with VS 2003 really hadn't been an option, either. It's
just said that Microsoft has created a new DLL hell in their attempt
to fix the old one, and that they fail to a
it
"candidate". Since the code base of 2.6.4rc1 was not released as-is,
we would need to consider another candidate.
But then, Barry doesn't like release candidates in the first place.
Regards,
Martin
___
python-committers mailing list
pyth
w
that would fit into the "within the next day or two" plan.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
> That seems to argue for doing rc2 on Sunday the 18th. If I tag the
> release some time Saturday, you could have the binaries by Sunday
> right?
Correct.
Regards,
Martin
___
python-committers mailing list
python-committers@python
Also, ask him to submit a contributor agreement.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
myself when I forget to block changes.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
> The hold-up will ultimately be the EOL extension and the updated docs
> now that Dirkjan has a patch for sys.mercurial.
Is that patch published somewhere? I'd like to take a look.
Regards,
Martin
___
python-committers mailing list
python
e hg-eol extension for
> anyone that needs it and continuing on from there.
The risk, of course, is to lose Mark Hammond as a contributor.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
e. There are tons of other things to be
done, and nobody willing to do them - everybody just wants them to be done.
So people who want the Mercurial switch to happen now really need to
step forward and volunteer to work on it, or else it won't
ally generated, for all people who have ssh
keys installed.
Some of them are actually not supposed to commit to Python, but only to,
say, stackless.
Regards,
Martin
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
Barry Warsaw wrote:
> Martin, do you magic! :)
I have uploaded the files, and added the signatures. I have not changed
the content file; the relevant data are
3b47876d4dc3ab064926345eb76a61d2 15422464 python-2.6.5rc2.amd64.msi
e6b561ccf166aec5de4daa37a465e1c1 14886912 python-2.6.5rc2.msi
I
1 - 100 of 203 matches
Mail list logo
