After more thought, I think that separating the 2.7 and 3.2 releases
is not as big of an issue as I once thought. Therefore, I'd like to
adopt the schedule I posted a few weeks back for 2.7 only.
This only means some other lucky victi... I mean volunteer can do 3.2. :)
--
Regards,
Benjamin
_
On Sun, 2009-11-15 at 12:42 +, Antoine Pitrou wrote:
> Tarek Ziadé gmail.com> writes:
> >
> > This cannot work on all platforms, when our Makefile is not shipped
> > with python but python-devel. (like Fedora)
>
> This practice is stupid anyway, because it means you have to install
> python-
Has anyone else looked at using Coccinelle/spatch[1] on CPython source
code?
It's a GPL-licensed tool for matching semantic patterns in C source
code. It's been used on the Linux kernel for detecting and fixing
problems, and for autogenerating patches when refactoring
(http://coccinelle.lip6.fr/im
On Sun, Nov 15, 2009 at 03:35:00AM +0100, Christian Heimes wrote:
>
> Do we really want to change distutils to solve a problem of a third
> party packaging system when the problem was created by the very same
> third party in the first place? In other words: Should you spend your
> precious develo
2009/11/16 Tres Seaver :
>> Which is bizarre, since Paul belongs to the group of people you say
>> you care most about - i.e., those people browsing the index and
>> looking for packages. The *consumers* of the comments, in other words.
>
> I agree with Martin that anonymous votes, like anonymous
On Sun, Nov 15, 2009 at 11:27:29PM -0500, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Tarek Ziadé wrote:
> > On Sun, Nov 15, 2009 at 3:35 AM, Christian Heimes wrote:
> > [..]
> >> Do we really want to change distutils to solve a problem of a third
> >> party packaging
Martin v. Löwis wrote:
Michael Foord wrote:
Martin v. Löwis wrote:
Would it be possible to detect a change of provider and then offer the
option to migrate the account to the new provider (so long as it does
not conflict with another account)?
That would be possible - but
On Sun, Nov 15, 2009 at 02:31:45PM +0100, Georg Brandl wrote:
> Antoine Pitrou schrieb:
> > Tarek Ziadé gmail.com> writes:
> >>
> >> This cannot work on all platforms, when our Makefile is not shipped
> >> with python but python-devel. (like Fedora)
> >
> > This practice is stupid anyway, becaus
Michael Foord wrote:
> Martin v. Löwis wrote:
>>> Would it be possible to detect a change of provider and then offer the
>>> option to migrate the account to the new provider (so long as it does
>>> not conflict with another account)?
>>>
>>
>> That would be possible - but again complicate the
Martin v. Löwis wrote:
Would it be possible to detect a change of provider and then offer the
option to migrate the account to the new provider (so long as it does
not conflict with another account)?
That would be possible - but again complicate the UI.
Why? You should only need to pr
> Would it be possible to detect a change of provider and then offer the
> option to migrate the account to the new provider (so long as it does
> not conflict with another account)?
That would be possible - but again complicate the UI.
Regards,
Martin
Martin v. Löwis wrote:
Even not having provider changes supported would still allow me to use
my openid with PyPI which would be great. The only problem with changing
provider that I can see is when the provider a user changes to would
then be a duplicate - in which case I think just refusing to
On Sat, Nov 14, 2009 at 4:34 PM, Arc Riley wrote:
>
>> +1
>>
>> Having a "Repository-URL", "Repository-Browse-URL" and a
>> "Bug-Tracker-URL" field in PyPI would be a lot more usefule then
>> comments and ratings.
>>
>
> +1
You mean in the Metadata ? We are currenty working on adding fields in th
13 matches
Mail list logo
