Lennart Regebro writes:
> > Sure, but that's still *work*, and it's work for *somebody else*.
>
> Yes, but only when the checkin was wrong. For all other checkins, it's
> *less* work. Hence, a committer needs to basically fudge up every
> second checkin to cause more work than he relieves wo
Lennart Regebro writes:
> On Mon, Apr 26, 2010 at 20:30, Antoine Pitrou wrote:
> > In an open source community, "merit" relates to that community.
> > We don't give Linus Torvalds all rights on the project just
> > because we know (or assume ;-)) he is tremendously competent.
>
> Well, tha
Steve Holden writes:
> Yes, in the last year in particular there has been some excellent effort
> of maintaining the issue tracker content. But the question still remains
> - who are we worried about offending?
In this thread, we did worry about offending Sean and dangerjim. Now
that Sean has
> In other words, I think the goal is not just to add new developers to
> the community, but to continue to build a strong community of developers.
FWIW, from a Python community newbie that has submitted a few patches and
commented on the tracker for a few months, I agree with this statement and
t
Terry Reedy writes:
> As said above, the need to do this should be fixed. In the meantime, if
> people really care about having 'no selection' replaced by 'normal', I
> could do more. I have not bothered because I regard the two as synonyms
> and have not bothered.
Technically they're very
On Tue, 27 Apr 2010 05:37:31 am Antoine Pitrou wrote:
> Steven D'Aprano pearwood.info> writes:
> > That depends on what you call unglamourous work. No, I don't triage
> > bugs. I don't have commit privileges, so I can't.
>
> Is this the sole reason? You could try to review patches which are
> prop
On Tue, Apr 27, 2010 at 5:10 AM, Piotr Ożarowski wrote:
> if there's no other way (--install-data is ignored right now, and I know
> you're doing a great work to change that, thanks BTW), one could always
> use it in *one* place and later import the result in other parts of
> the code (instead of
On 27/04/2010 00:26, James Mills wrote:
On Tue, Apr 27, 2010 at 9:15 AM, David Malcolm wrote:
On Mon, 2010-04-26 at 21:19 +0200, Piotr Ożarowski wrote:
Many Python module developers do not want their work to be distributed
by Debian (and probably by other Linux distributions), here's
On Tue, Apr 27, 2010 at 9:15 AM, David Malcolm wrote:
> On Mon, 2010-04-26 at 21:19 +0200, Piotr Ożarowski wrote:
>> Many Python module developers do not want their work to be distributed
>> by Debian (and probably by other Linux distributions), here's a list of
> Thanks! Not just Debian: I can
On Mon, Apr 26, 2010 at 05:46:55PM -0400, Barry Warsaw wrote:
> On Apr 26, 2010, at 09:39 PM, Tarek Ziadé wrote:
>
> >You should be permissive on that one. Until we know how to describe resource
> >files properly, __file__ is what developer use when they need their projects
> >to be portable..
>
On Mon, 2010-04-26 at 21:19 +0200, Piotr Ożarowski wrote:
> Hi,
>
> Many Python module developers do not want their work to be distributed
> by Debian (and probably by other Linux distributions), here's a list of
Thanks! Not just Debian: I can confirm, from bitter experience, that
your list is a
On Mon, Apr 26, 2010 at 11:56 PM, Robert Kern wrote:
[..]
>
> I don't think the OP is really speaking against using __file__ per se, but
> rather putting data into the package however it is accessed. The
> Linux-packager preferred practice is to install into the appropriate
> /usr/shared/ subdirec
On Apr 26, 2010, at 04:56 PM, Robert Kern wrote:
>On 4/26/10 4:46 PM, Barry Warsaw wrote:
>> On Apr 26, 2010, at 09:39 PM, Tarek Ziadé wrote:
>>
>>> You should be permissive on that one. Until we know how to describe resource
>>> files properly, __file__ is what developer use when they need their
On Apr 27, 2010, at 12:03 AM, Tarek Ziadé wrote:
>On Mon, Apr 26, 2010 at 11:45 PM, Barry Warsaw wrote:
>[..]
>>
>> For example, there's a nice tool called 'Quickly' that builds application
>> templates using best practices. It is opinionated, but designed for the
>> opportunistic programmer. I
On Mon, Apr 26, 2010 at 11:46 PM, Barry Warsaw wrote:
> On Apr 26, 2010, at 09:39 PM, Tarek Ziadé wrote:
>
>>You should be permissive on that one. Until we know how to describe resource
>>files properly, __file__ is what developer use when they need their projects
>>to be portable..
>
> Until then
On Mon, Apr 26, 2010 at 11:45 PM, Barry Warsaw wrote:
[..]
>
> For example, there's a nice tool called 'Quickly' that builds application
> templates using best practices. It is opinionated, but designed for the
> opportunistic programmer. I've been thinking about writing a Python
> application a
On 4/26/10 4:46 PM, Barry Warsaw wrote:
On Apr 26, 2010, at 09:39 PM, Tarek Ziadé wrote:
You should be permissive on that one. Until we know how to describe resource
files properly, __file__ is what developer use when they need their projects
to be portable..
Until then, isn't pkg_resources t
On Apr 26, 2010, at 09:39 PM, Tarek Ziadé wrote:
>You should be permissive on that one. Until we know how to describe resource
>files properly, __file__ is what developer use when they need their projects
>to be portable..
Until then, isn't pkg_resources the best practice for this? (I'm pretty s
On Apr 26, 2010, at 09:19 PM, Piotr Ożarowski wrote:
>Many Python module developers do not want their work to be distributed
>by Debian (and probably by other Linux distributions), here's a list of
>hints that will help you accomplish that goal:
Okay, it took me a few bullet items to realize you
On 4/26/2010 5:02 PM, "Martin v. Löwis" wrote:
Eric Smith wrote:
Martin v. Löwis wrote:
If possible, I think 'normal' should be the default in the hox or else
there should be some sort of auto replacement.
Makes sense to me.
I have now changed to make 'normal' the default priority for new is
Eric Smith wrote:
> Martin v. Löwis wrote:
If possible, I think 'normal' should be the default in the hox or else
there should be some sort of auto replacement.
>>> Makes sense to me.
>>
>> I have now changed to make 'normal' the default priority for new issues.
>> Shall I also set the pr
On 4/26/2010 4:41 PM, Eric Smith wrote:
Martin v. Löwis wrote:
If possible, I think 'normal' should be the default in the hox or else
there should be some sort of auto replacement.
Makes sense to me.
I have now changed to make 'normal' the default priority for new issues.
Just now, I still
On Mon, Apr 26, 2010 at 13:39, "Martin v. Löwis" wrote:
> >> If possible, I think 'normal' should be the default in the hox or else
> >> there should be some sort of auto replacement.
> >
> > Makes sense to me.
>
> I have now changed to make 'normal' the default priority for new issues.
> Shall I
On 4/26/2010 3:22 PM, Steven D'Aprano wrote:
That depends on what you call unglamourous work. No, I don't triage
bugs. I don't have commit privileges, so I can't.
Tracker 'privileges' (responsibilities, really) are different from
commit privileses.
> Does hand-holding
newbies who don't know
Martin v. Löwis wrote:
If possible, I think 'normal' should be the default in the hox or else
there should be some sort of auto replacement.
Makes sense to me.
I have now changed to make 'normal' the default priority for new issues.
Shall I also set the priority on all past issues to normal wh
> Same here. Unfortunately I think that requires a code change as I can't
> see how to do it through the web API.
You have to write an auditor, which I just did.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
>> If possible, I think 'normal' should be the default in the hox or else
>> there should be some sort of auto replacement.
>
> Makes sense to me.
I have now changed to make 'normal' the default priority for new issues.
Shall I also set the priority on all past issues to normal which have
them cu
On Mon, Apr 26, 2010 at 10:10 PM, Piotr Ożarowski wrote:
> [Tarek Ziadé, 2010-04-26]
>> Great hints, I'll try to follow them... and they could make a good
>> section in the Hitchhiker's guide to packaging ;)
>
> How about these two:
> http://us.pycon.org/media/2010/talkdata/PyCon2010/038/paper.htm
On Mon, Apr 26, 2010 at 12:01, Antoine Pitrou wrote:
> Terry Reedy udel.edu> writes:
> >
> > If possible, I think 'normal' should be the default in the hox or else
> > there should be some sort of auto replacement.
>
> Makes sense to me too.
>
Same here. Unfortunately I think that requires a co
On Mon, Apr 26, 2010 at 01:19, Paul Moore wrote:
> On 26 April 2010 07:12, Sean Reifschneider wrote:
> > Two of the 3 easiest things I came up with for an outsider to help out
> > with, are things that his account couldn't do.
>
> Would in not therefore be reasonable to question whether the *def
[Tarek Ziadé, 2010-04-26]
> Great hints, I'll try to follow them... and they could make a good
> section in the Hitchhiker's guide to packaging ;)
How about these two:
http://us.pycon.org/media/2010/talkdata/PyCon2010/038/paper.html
http://wiki.debian.org/GettingPackaged
> [...]
> > * ignore FHS
On 4/26/2010 2:15 PM, Steve Holden wrote:
If this were the criterion then the answer would be simple: nobody seems to
knows dangerjim in the Python community.
Except, of course, the person recommending him. And it seems from the
discussion that nobody is particularly bothered about finding out
> Maybe we can drop OSF/1 safely supporting Tru64 yet, but we don't have
> any buildbot running any of this systems...
Dropping support is fine with me, in the long term. If PEP 11 is truly
followed, we should deprecate support in one version, and drop it in the
next one. This would mean we add a
On Mon, Apr 26, 2010 at 9:19 PM, Piotr Ożarowski wrote:
> Hi,
>
> Many Python module developers do not want their work to be distributed
> by Debian (and probably by other Linux distributions), here's a list of
> hints that will help you accomplish that goal:
Great hints, I'll try to follow them.
Steven D'Aprano pearwood.info> writes:
>
> That depends on what you call unglamourous work. No, I don't triage
> bugs. I don't have commit privileges, so I can't.
Is this the sole reason? You could try to review patches which are proposed, or
give advice where you are competent. As Terry (I bel
Le samedi 17 avril 2010 05:19:36, Andrew MacIntyre a écrit :
> > My patch: http://bugs.python.org/issue8391 (os.execvpe() doesn't support
> > surrogates in env).
>
> I'll look at it when I get a chance, but I'm not expecting that my input
> should affect your patch and I'm not expecting you to try
On Tue, 27 Apr 2010 03:45:39 am Antoine Pitrou wrote:
> Steven D'Aprano pearwood.info> writes:
> > Who are we worried about offending? The crowds on the Internet who
> > never volunteer for anything, who never submit patches, let alone
> > offer to do the unglamourous work?
>
> Perhaps you should
Hi,
Many Python module developers do not want their work to be distributed
by Debian (and probably by other Linux distributions), here's a list of
hints that will help you accomplish that goal:
* depend on unstable or unreleased software (even if you
use it only to generate docs or do unit test
Terry Reedy udel.edu> writes:
>
> If possible, I think 'normal' should be the default in the hox or else
> there should be some sort of auto replacement.
Makes sense to me too.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
> Currently, the 'default' Priority for new tracker issues is '- no
> selection -'. This is, I believe, widely understood to be equivalent to
> 'normal'. Consequently, almost no one bothers to make a selection. This
> applies even to experienced people like (in the last hour) Jesus Crea
> (#8536),
On Mon, Apr 26, 2010 at 20:30, Antoine Pitrou wrote:
> Lennart Regebro gmail.com> writes:
>>
>> On Mon, Apr 26, 2010 at 17:42, R. David Murray bitdance.com>
> wrote:
>> > The first is that open source projects tend to be meritocracies.
>> > An otherwise unknown person being introduced to the com
Currently, the 'default' Priority for new tracker issues is '- no
selection -'. This is, I believe, widely understood to be equivalent to
'normal'. Consequently, almost no one bothers to make a selection. This
applies even to experienced people like (in the last hour) Jesus Crea
(#8536), Eric S
On Mon, Apr 26, 2010 at 2:27 PM, Antoine Pitrou wrote:
> Jesse Noller gmail.com> writes:
>>
>> Just to add fuel to the fire w.r.t this discussion about
>> process-improvements, lowering friction, etc. I'd like to point out
>> (unintentionally tooting my own horn) a discussion I started up on
>> t
Lennart Regebro gmail.com> writes:
>
> On Mon, Apr 26, 2010 at 17:42, R. David Murray bitdance.com>
wrote:
> > The first is that open source projects tend to be meritocracies.
> > An otherwise unknown person being introduced to the community and
> > immediately given privileges *just* because o
Jesse Noller gmail.com> writes:
>
> Just to add fuel to the fire w.r.t this discussion about
> process-improvements, lowering friction, etc. I'd like to point out
> (unintentionally tooting my own horn) a discussion I started up on
> this exact topic last week:
>
> http://jessenoller.com/2010/04
On Mon, Apr 26, 2010 at 17:42, R. David Murray wrote:
> The first is that open source projects tend to be meritocracies.
> An otherwise unknown person being introduced to the community and
> immediately given privileges *just* because of the recommendation of
> another person
Since the recommenda
On 4/26/2010 2:12 AM, Sean Reifschneider wrote:
On Sun, Apr 25, 2010 at 08:42:00PM -0400, Terry Reedy wrote:
What is *his* interest? How long has he known and used Python?
Good points have been made on both sides of the issue here. Despite my
having a vested interest, I really have no strong
Antoine Pitrou wrote:
> Steven D'Aprano pearwood.info> writes:
>> Who are we worried about offending? The crowds on the Internet who never
>> volunteer for anything, who never submit patches, let alone offer to do
>> the unglamourous work?
>
> Perhaps you should look more carefully. We do have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We don't have any buildbot backing this system.
OSF/1 last version was in 1994, was picked by Digital (Tru64 Unix). Last
version of Tru64 was released in late 2006. Now Digital is owned by HP
with its own Unix (HP-UX).
Maybe we can drop OSF/1 safely
Steven D'Aprano pearwood.info> writes:
> Who are we worried about offending? The crowds on the Internet who never
> volunteer for anything, who never submit patches, let alone offer to do
> the unglamourous work?
Perhaps you should look more carefully. We do have contributors who submit
patches
On 4/26/2010 7:45 AM, Michael Foord wrote:
So the question remains - for *tracker* privileges, should the
recommendation and commitment to mentor from an established commiter be
sufficient (and therefore a standard part of our process)?
I think this is a reasonable barrier for entry and should
Sounds good to me (subject to arguing about spellings, case
insensitivity, etc.). Just so it doesn't get lost, I created issue 8538
to track it.
Neal Becker wrote:
steven.beth...@gmail.com made a very nice module for me to enhance argparse
called argparse_bool.py, which contains ConfigureActio
On 4/26/2010 11:09 AM, Alexander Belopolsky wrote:
I also I don't remember ever seeing spam in the bugs.python.org
comments which suggests that the subscription process weeds bots
reasonably well.
And when it fails, spam is deleted just so no one does see it.
_
On Tue, 27 Apr 2010 01:42:10 am R. David Murray wrote:
> On Mon, 26 Apr 2010 12:45:34 +0100, Michael Foord
wrote:
> > So the question remains - for *tracker* privileges, should the
> > recommendation and commitment to mentor from an established
> > commiter be sufficient (and therefore a standard
On Mon, 26 Apr 2010 12:45:34 +0100, Michael Foord
wrote:
> So the question remains - for *tracker* privileges, should the
> recommendation and commitment to mentor from an established commiter be
> sufficient (and therefore a standard part of our process)?
I think that in a technical sense a com
On Apr 26, 2010, at 08:20 AM, Neal Becker wrote:
>steven.beth...@gmail.com made a very nice module for me to enhance argparse
>called argparse_bool.py, which contains ConfigureAction. This will allow a
>boolean value to be set very like the gnu configure style:
>
>--foo
>--with-foo
>--without-f
On Mon, Apr 26, 2010 at 5:31 AM, Jeroen Ruigrok van der Werven
wrote:
..
> Be careful. Trackers are often hit by spam bots which change random form
> field values. I cannot from memory recall whether or not we had this issue
> on either the tracker tracker or Python's tracker.
>
I would think a c
On Mon, Apr 26, 2010 at 7:05 AM, Michael Foord
wrote:
> On 26/04/2010 11:58, Stephen J. Turnbull wrote:
>>
>> [snip...]
>>
>> I'm not claiming that the current balance is right.
>
> Hmm... the core development team (those who make commits once a month or
> more frequently) is very small, the numbe
On Mon, Apr 26, 2010 at 12:58, Stephen J. Turnbull wrote:
> It is entirely *not* evident to me that it's too hard to get
> privileges in the Python development community (Python's development
> process works -- and it works really well by comparison to 99% of the
> processes out there).
Well, tha
Senthil Kumaran gmail.com> writes:
>
> On Mon, Apr 26, 2010 at 08:20:10AM -0400, Neal Becker wrote:
> > steven.bethard gmail.com made a very nice module for me to enhance
argparse
> > called argparse_bool.py, which contains ConfigureAction. This will allow a
>
> Would not it be a feature enh
On Mon, Apr 26, 2010 at 08:20:10AM -0400, Neal Becker wrote:
> steven.beth...@gmail.com made a very nice module for me to enhance argparse
> called argparse_bool.py, which contains ConfigureAction. This will allow a
Would not it be a feature enhancement request against argparse.py
itself? In th
On Mon, Apr 26, 2010 at 02:25:33AM -, exar...@twistedmatrix.com wrote:
> I think there should be a page on python.org that says all
> contributors are welcome, and one way to become a contributor is to
> wrangle the issue tracker, and explains what this involves (I don't
> really have any idea,
steven.beth...@gmail.com made a very nice module for me to enhance argparse
called argparse_bool.py, which contains ConfigureAction. This will allow a
boolean value to be set very like the gnu configure style:
--foo
--with-foo
--without-foo
--no-foo
--foo=yes
--foo=no
I've been happily using i
On 26/04/2010 12:24, Antoine Pitrou wrote:
Hello,
I think it is very much in the interest of Python to evolve our
processes in order to encourage more core-developers. Evolving means
experimenting *and* being willing to change. It is certainly less
*effort* to accept the status quo, but wit
On 26/04/2010 12:40, Scott Dial wrote:
On 4/26/2010 7:24 AM, Antoine Pitrou wrote:
I think it is very much in the interest of Python to evolve our
processes in order to encourage more core-developers. Evolving means
experimenting *and* being willing to change. It is certainly less
*effort* t
Martin v. Löwis wrote:
>> If adding people created work for already-busy developers then I'd be
>> against it*
>
> I most certainly does create work, but that could be as little as
> sending an email message to some administrator.
>
> There is no other way: somebody will have to make a decision,
On 4/26/2010 7:24 AM, Antoine Pitrou wrote:
>> I think it is very much in the interest of Python to evolve our
>> processes in order to encourage more core-developers. Evolving means
>> experimenting *and* being willing to change. It is certainly less
>> *effort* to accept the status quo, but wi
Stephen J. Turnbull wrote:
> > There is one privilege that should be hard to get: Permanent delete.
> > But being able to triage bugs isn't such a privilege. Heck, not even
> > commit access is, because of someone makes something bad, you can back
> > out the checkin.
>
> Sure, but that's stil
Hello,
> I think it is very much in the interest of Python to evolve our
> processes in order to encourage more core-developers. Evolving means
> experimenting *and* being willing to change. It is certainly less
> *effort* to accept the status quo, but with several more committed and
> enthus
On 26/04/2010 11:58, Stephen J. Turnbull wrote:
[snip...]
I'm not claiming that the current balance is right.
Hmm... the core development team (those who make commits once a month or
more frequently) is very small, the number of people doing bug triaging
is currently good but also small. We
Lennart Regebro writes:
> I'd say there is something wrong with the process. If a trusted
> developer can't get somebody more privilege on the tracker by
> saying that "I trust this guy", then a new process is needed.
> That's it's too hard to get privileges in the Python development
> commun
On Thu, Apr 22, 2010 at 6:05 PM, Tarek Ziadé wrote:
> 2010/4/22 P.J. Eby :
>> At 10:54 AM 4/22/2010 +0200, Tarek Ziadé wrote:
>>>
>>> Hello,
>>>
>>> I think I went through all the latest feedback regarding PEP 376.
>>>
>>> There will be still some work of course, on the implementation side
>>> (fo
-On [20100426 10:21], Paul Moore (p.f.mo...@gmail.com) wrote:
>Would in not therefore be reasonable to question whether the *default*
>privileges be changed to allow "outsiders" to do these things, rather
>than asking for escalated privileges for one individual? (Or more
>li
On 26 April 2010 07:12, Sean Reifschneider wrote:
> Two of the 3 easiest things I came up with for an outsider to help out
> with, are things that his account couldn't do.
Would in not therefore be reasonable to question whether the *default*
privileges be changed to allow "outsiders" to do these
On Mon, Apr 26, 2010 at 08:33, "Martin v. Löwis" wrote:
> There is a little risk. People doing triage can make two common
> mistakes, and both do happen in the Python tracker from time to time:
> a) they reject some contribution, even though a long-time contributor
> might have accepted it with
75 matches
Mail list logo
