Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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 feelings one way or another on the initial request. But, the answers to your questions above may make it more clear why I was looking for the enhanced privileges. James (dangerjim) has *NO* knowledge of Python -- he has done primarily C and Java coding. He *DOES* have time on his hands. This is why I proposed to him to do tracker triage. However, as I started walking him through some examples of triage, I realized that regular accounts don't have the privileges to do any of the things I was proposing. For example: Go into the list of task tasks and look at the ones with no priority. Read through the description and any follow-ups and try to figure out what priority to give it. In most cases it will be normal. However, for some issues it will be clear they should be a higher or lower priority, even to someone who doesn't know Python. Then we went on to issue 5575 and read through it. In reading this one to determine the priority, it was clear that the ball was back in Collin's court, so I showed that I would look to see if Collin was a valid assignee (which he was) and assign it to him, with a comment about why. Go into old bugs that have patches, and see if the patches cleanly apply against the trunk. If they do, do a make and make test. Add a comment with the outcome. 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. But, as I said above, I'm fine with having him push those changes through me and I can make them when he can't. Thanks, Sean -- It was a sneaky lawyer's trick, and I fell for it. Because... She's much smarter than me. -- _High_Fidelity_ Sean Reifschneider, Member of Technical Staff j...@tummy.com tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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, and that is work. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
Sounds good. Why is the barrier for this permission any higher than someone asking for it? Is there really a need to protect against contributors with malicious intent? 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 modifications; sometimes this rejection happens for overly formal reasons, and b) they assign issues to someone who might be formally in charge, but is unlikely to act on the issue in a reasonable amount of time. Of course, long-term contributors can and do also make the same mistakes; it's just that new people are often unfamiliar with the conventions. This was all in the abstract, independent of dangerjim (whom I don't know). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
On Mon, Apr 26, 2010 at 08:33, Martin v. Löwis mar...@v.loewis.de 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 modifications; sometimes this rejection happens for overly formal reasons, and b) they assign issues to someone who might be formally in charge, but is unlikely to act on the issue in a reasonable amount of time. Sure. But these errors can be fixed, just as a checkin can be reverted. That's what I mean with the risk being low, you can't make permanent damage. The Zope community gives commit access by recommendation. This works well. The easier it is to contribute, the more people contributes. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
On 26 April 2010 07:12, Sean Reifschneider j...@tummy.com 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 things, rather than asking for escalated privileges for one individual? (Or more likely, as well as doing so, as changing the default is likely to be a longer discussion...) Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
-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 likely, as well as doing so, as changing the default is likely to be a longer discussion...) 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. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B A wise man that walks in the dark with a blindfold on, is not much of a wise man... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376
On Thu, Apr 22, 2010 at 6:05 PM, Tarek Ziadé ziade.ta...@gmail.com wrote: 2010/4/22 P.J. Eby p...@telecommunity.com: 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 (for instance the Zip issues described by PJE). But I would like to go ahead and propose PEP 376 for acceptance. One final (optional) question/suggestion... should we change from this (in RECORD files): lib/python2.6/site-packages/docutils/__init__.pyc to this: lib/python2.6/site-packages/docutils/__init__.pyc,, In this way, reader code can be written as: for path, hash, size in csv.reader(...): It's not a high-priority thing, but if anybody is writing code to parse RECORD files outside the provided API implementation (eg. system packaging tool authors), they'll probably appreciate this. ;-) Yes, of course. the RECORD file is supposed to be iterable using the csv reader, so that's a mistake in the PEP. Thanks for noticing, I'll fix it later today This is fixed. Guido told me in private he's now accepting the PEP since there's consensus. The next step is to finish PEP 376 implementation in distutils2, and pkgutil. There will be a full backport of the new pkgutil in distutils2, so third party projects that wants to be compatible with this new standard will be able to start doing it before Python 3.2 is out. Thanks to all the folks that helped in this process ! Regards Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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 community has been evident too long, I think. 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). And processes are delicate; they should be changed only when the people involved in them have the time and inclination to work on rebalancing them. 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 still *work*, and it's work for *somebody else*. The person who made the mistake is unlikely to detect it, and needs to be told to fix it, if they even fix it themselves. Giving people rights to a bugtracker or versioning system is not dangerous, and should not be hard. As someone who does a lot more managing of shared resources than coding in the projects I'm active in, I disagree about the danger. Enthusiastic newbies can do a lot of minor damage in a short period of time, and cleaning that up is *work*. This danger is almost entirely mitigated by a small amount of mentoring -- which is precisely what the current process requires -- not only of the recomending party, but also of the existing workers. I'm not claiming that the current balance is right. Just that it's not obvious that it's *wrong*, and therefore the decision should be left up to the people who will do the mentoring, the supervision, and -- if necessary -- the cleanup. If the existing tracker crew is happy with Sean's recommendation, and similar recommendations in the future, I'm happy too. But it is a process change, and they should be comfortable with it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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 have patches and issues in the tracker that may have responses but will never get properly looked at because no-one on the core team is interested or has the mental bandwidth, we have possibly hundreds of modules in the standard library without a maintainer. 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 enthusiastic (and good) core developers there is an awful lot (more) we could achieve. All the best, Michael Foord Just that it's not obvious that it's *wrong*, and therefore the decision should be left up to the people who will do the mentoring, the supervision, and -- if necessary -- the cleanup. If the existing tracker crew is happy with Sean's recommendation, and similar recommendations in the future, I'm happy too. But it is a process change, and they should be comfortable with it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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 enthusiastic (and good) core developers there is an awful lot (more) we could achieve. I certainly agree we should try to attract more good-willed and competent contributors. I also agree with Stephen that, in a project with a non-trivial amount of complexity such as CPython, not having (tracker or commit) privileges is not the real barrier to entry. You have to learn how the software works, how its development works, who are the people working on it, etc. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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 still *work*, and it's work for *somebody else*. The person who made the mistake is unlikely to detect it, and needs to be told to fix it, if they even fix it themselves. As someone who's main contribution these days (other than kibbitzing here) is reviewing checkins that go by on python-checkins, there generally *is* a slight uptick in that workload when someone new is given commit privileges (e.g. reminders to update docs, NEWS, tests, what's new, ACKS, pointing out potential cross-platform or backwards compatibility problems, reminders to check with active maintainers for some modules). It usually doesn't last long, because those people are currently familiar with the basics of the process from submitting patches to the tracker and seeing them applied for a while before commit privileges are granted. Actually having to revert commits and rerun the test suite to make sure everything is back the way it should be can probably be taken as a 1-for-1 loss in patches applied without being too far off the mark (fortunately, that is rather rare under the current system - I expect it would be significantly more common if we were more casual about handing out commit privileges). However, I will also point out that a large chunk of the motivation in moving to a DVCS is to make life easier for *non-committers*. Existing devs get some benefit in being able to use something less clunky than svnmerge to manage the maintenance branches, but that is pretty minor compared to the gain in usability for everyone else. If the existing tracker crew is happy with Sean's recommendation, and similar recommendations in the future, I'm happy too. But it is a process change, and they should be comfortable with it. Agreed that it is the existing triage team that really needs to OK this (since they'll likely be the ones cleaning up any mistakes). Getting someone to do things the clunky way for a couple of weeks still seems like a decent way for them to show they understand the basics of our tracker management policies (since merely commenting on issues can't cause a mess the way inadvertent misuse of tracker privileges can). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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 with several more committed and enthusiastic (and good) core developers there is an awful lot (more) we could achieve. I certainly agree we should try to attract more good-willed and competent contributors. I also agree with Stephen that, in a project with a non-trivial amount of complexity such as CPython, not having (tracker or commit) privileges is not the real barrier to entry. You have to learn how the software works, how its development works, who are the people working on it, etc. I'd like to respond to Michael's comment about the possibly hundreds of modules in the standard library without a maintainer. My own experience (issue5949) has been positive despite the lack of a dedicated maintainer. When I had my own itch to scratch, nobody stopped me from scratching it.. some people told me when I could scratch it and how they'd like it scratched.. but I wasn't ignored or rejected despite the lack of a maintainer. Thanks to RDM for giving my issue attention. -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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, and that is work. Well, I'm sorry to have put you to the work of penning that reply, when you could have used the effort instead to triage a bug. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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* to accept the status quo, but with several more committed and enthusiastic (and good) core developers there is an awful lot (more) we could achieve. I certainly agree we should try to attract more good-willed and competent contributors. I also agree with Stephen that, in a project with a non-trivial amount of complexity such as CPython, not having (tracker or commit) privileges is not the real barrier to entry. You have to learn how the software works, how its development works, who are the people working on it, etc. I'd like to respond to Michael's comment about the possibly hundreds of modules in the standard library without a maintainer. My own experience (issue5949) has been positive despite the lack of a dedicated maintainer. When I had my own itch to scratch, nobody stopped me from scratching it.. some people told me when I could scratch it and how they'd like it scratched.. but I wasn't ignored or rejected despite the lack of a maintainer. Thanks to RDM for giving my issue attention. Right, but finding counterexamples is not at all hard... Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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 with several more committed and enthusiastic (and good) core developers there is an awful lot (more) we could achieve. I certainly agree we should try to attract more good-willed and competent contributors. I also agree with Stephen that, in a project with a non-trivial amount of complexity such as CPython, not having (tracker or commit) privileges is not the real barrier to entry. You have to learn how the software works, how its development works, who are the people working on it, etc. 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 be acceptable. It should be stated as part of our standard procedure however rather than being an exception to our standard procedure. All the best, Michael Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] argparse suggestion
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 it, and I think it would be of sufficient general
interest to include it with the standard library.
import argparse
import re
def boolean(string):
string = string.lower()
if string in ['0', 'f', 'false', 'no', 'off']:
return False
elif string in ['1', 't', 'true', 'yes', 'on']:
return True
else:
raise ValueError()
class ConfigureAction(argparse.Action):
def __init__(self,
option_strings,
dest,
default=None,
required=False,
help=None,
metavar=None,
positive_prefixes=['--', '--with-', '--enable-'],
negative_prefixes=['--no-', '--without-', '--disable-']):
strings = []
self.positive_strings = set()
self.negative_strings = set()
for string in option_strings:
assert re.match(r'--[A-z]+', string)
suffix = string[2:]
for positive_prefix in positive_prefixes:
self.positive_strings.add(positive_prefix + suffix)
strings.append(positive_prefix + suffix)
for negative_prefix in negative_prefixes:
self.negative_strings.add(negative_prefix + suffix)
strings.append(negative_prefix + suffix)
super(ConfigureAction, self).__init__(
option_strings=strings,
dest=dest,
nargs='?',
const=None,
default=default,
type=boolean,
choices=None,
required=required,
help=help,
metavar=metavar)
def __call__(self, parser, namespace, value, option_string=None):
if value is None:
value = option_string in self.positive_strings
elif option_string in self.negative_strings:
value = not value
setattr(namespace, self.dest, value)
if __name__ == '__main__':
parser = argparse.ArgumentParser()
parser.add_argument('--fun', action=ConfigureAction)
assert parser.parse_args([]).fun == None
assert parser.parse_args(['--fun']).fun == True
assert parser.parse_args(['--with-fun']).fun == True
assert parser.parse_args(['--enable-fun']).fun == True
assert parser.parse_args(['--no-fun']).fun == False
assert parser.parse_args(['--without-fun']).fun == False
assert parser.parse_args(['--disable-fun']).fun == False
print parser.parse_args()
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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, actually; I assume it's things like setting Actually there already is such a page: http://www.python.org/dev/contributing/ . Excerpt: If you have helped out in the issue tracker for a little while or have been a good participant on python-dev you may ask for Developer privileges on the tracker which allow you to change any and all metadata on an issue. Please don't be shy about asking for the privilege! We are more liberal with giving out this ability than with commit privileges, so you don't need to have been contributing for a year to gain this ability. And with Developer privileges you can work more autonomously and be an even greater help by narrowing down what issues on the tracker deserve the most attention at any one time. Issue workflow is specified in http://www.python.org/dev/workflow/. Suggestions for text improvements/changes are welcomed. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse suggestion
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 that case, you might just file a bug against argparse at bugs.python.org. -- Senthil BOFH excuse #138: BNC (brain not connected) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse suggestion
Senthil Kumaran orsenthil at gmail.com writes:
On Mon, Apr 26, 2010 at 08:20:10AM -0400, Neal Becker wrote:
steven.bethard at 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 that case, you might just file a bug against argparse at
bugs.python.org.
I would argue that since argparse is now in the standard library, it should be
primarily maintained on {bugs, svn}.python.org.
We have enough synchronization problems with externally maintained modules.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
On Mon, Apr 26, 2010 at 12:58, Stephen J. Turnbull step...@xemacs.org 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, that's true, all to often a project is controlled by a few developers with no intent of sharing access ever. 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 work. :) As someone who does a lot more managing of shared resources than coding in the projects I'm active in, I disagree about the danger. Enthusiastic newbies can do a lot of minor damage in a short period of time, and cleaning that up is *work*. This danger is almost entirely mitigated by a small amount of mentoring -- which is precisely what the current process requires -- not only of the recomending party, but also of the existing workers. And I'm saying that the recommending party is enough. If an established developer says this guy will not fuck things up, then that is enough guarantee that he won't fuck things up. But it is a process change, and they should be comfortable with it. Of course. I'm just arguing for that this process change is correct, and that the current balance is wrong, and that a change is comfortable and safe. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
On Mon, Apr 26, 2010 at 7:05 AM, Michael Foord fuzzy...@voidspace.org.uk 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 number of people doing bug triaging is currently good but also small. We have patches and issues in the tracker that may have responses but will never get properly looked at because no-one on the core team is interested or has the mental bandwidth, we have possibly hundreds of modules in the standard library without a maintainer. 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 enthusiastic (and good) core developers there is an awful lot (more) we could achieve. [snip] 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/22/why-arent-you-contributing-to-python/ http://www.reddit.com/r/Python/comments/burio/why_arent_you_contributing_to_python/ http://news.ycombinator.com/item?id=1285897 I'm going to avoid summarizing the comments - ignoring my original post, I can honestly say I received an alarming amount of feedback some of which was private, but most of which is sitting there for us to possible consume and act on. jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
On Mon, Apr 26, 2010 at 5:31 AM, Jeroen Ruigrok van der Werven asmo...@in-nomine.org 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 comment area is a more attractive target for spam bots than random form field values such as assignee or priority. (Note that assignee values that a default user can set may be limited to themselves and previous assignees. This will reasonably protect this field from abuse and allow better tracking of whose court the ball is in.) Among the form fields, I would think nosy list would be targeted the most because it allows effectively turning the tracker into a mail relay, but I don't remember ever seeing it abused. 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. +1 on giving dangerjim requested privileges and using his experience to review and change the default privileges. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse suggestion
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-foo --no-foo --foo=yes --foo=no I've been happily using it, and I think it would be of sufficient general interest to include it with the standard library. +1. This would be a very nice addition to argparse in the stdlib. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
On Mon, 26 Apr 2010 12:45:34 +0100, Michael Foord fuzzy...@voidspace.org.uk 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 commitment to mentoring by an established contributor would be enough. But it seems to me that there are a couple of arguments against it being sufficient in the wider picture. 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 may feel (especially to the non privileged) like a kind of nepotism. (It's not what you contribute, it's who you know). The second is in some ways a subtle variation on the first. If a new person, even with a well respected mentor standing behind them, first approaches the tracker by reviewing and commenting without privileges, it does two things: it allows people in the community who are not the mentor to get a sense of them, and it gives them the benefit of input from people other than the mentor, and all of this happens *before* they have the opportunity (and the worry) of making mistakes(*). Both of these things serve to build community, and the second, IMO, results in a stronger, more confident contributor. I think that someone who has a mentor sponsoring them from the first should be able to go from zero to privileged in a very short period of time (a couple weeks perhaps, mostly depending on their activity level). Someone without a pre-existing mentor could do the same, if their activity level is high enough, and would probably pick up a mentor along the way...or be mentored by #python-dev as a whole if they hang out there. 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. -- R. David Murray www.bitdance.com (*) Even a seasoned developer from another project will make mistakes because some of our development process is a part of our culture and not written down, and even that which is written down is not necessarily easy for a newcomer to absorb by reading. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
On Tue, 27 Apr 2010 01:42:10 am R. David Murray wrote: On Mon, 26 Apr 2010 12:45:34 +0100, Michael Foord fuzzy...@voidspace.org.uk 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 commitment to mentoring by an established contributor would be enough. But it seems to me that there are a couple of arguments against it being sufficient in the wider picture. 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 may feel (especially to the non privileged) like a kind of nepotism. (It's not what you contribute, it's who you know). Hang on, are we talking about paying these people? Giving them keys to the executive washroom? Flying them around the world on First Class flights on expensive junkets? Fame and fortune? What privileges are we giving them? Oh yeah, the privilege of working for nothing in a thankless job that takes time and effort and returns nothing but a bullet point on your resume and the knowledge that you've given back to an Open Source project. 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? I think we worry too much about them -- they complain about everything, and have the attention span of a gnat. (Yes, I have had a bad day, why do you ask? *wink*) Other committers? I would hope that, being members of good standing in a meritocracy, they can recognise the difference between I want my mate to be given triaging privileges because he's my mate, and I want him to have triaging privileges because I trust him to do a good job. As I see it, the only people who might have a valid reason to be offended or annoyed are those who have volunteered but were rejected for some reason --perhaps because their skills aren't good enough, perhaps because nobody could vouch that their skills are good enough. Well, life is hard, get over it. In a meritocracy it isn't enough to be good at what you do, you also have to be known to be good. DangerJim has (apparently -- I don't know him myself) spent years building *both* his technical skills and his reputation. Sean is willing to vouch for him and mentor him, and if Sean himself has a sufficiently high reputation that Python-Dev is willing to trust his judgement, then I can't see any reason to reject the offer. What's the worst that could happen? He'll do a bad job of triaging bugs, other committers will have to step in and fix it, and Sean will be embarrassed. Nothing irreparable, except possibly Sean's reputation as a judge of others. I don't see this as a high risk move: we're not making him BDFL on Sean's say-so. The second is in some ways a subtle variation on the first. If a new person, even with a well respected mentor standing behind them, first approaches the tracker by reviewing and commenting without privileges, it does two things: it allows people in the community who are not the mentor to get a sense of them, Yes, they will have the opportunity, but will they take it? I've submitted two recent patches which have apparently been swallowed by the black hole of too much to do, too little time to do it. Am I bitter? No, of course not -- I understand that the committers have much to do, I'm a comparative unknown, and while the patches scratch my itch, they obviously don't scratch anyone else's. But this does demonstrate that just because people have the opportunity to get a sense of them, doesn't mean that they actually will do so -- if anything, the opposite is the case. By increasing the number of untrusted contributors relative to trusted committers, you increase the burden on committers and lower the chances that they will actually review patches. This in turn discourages people from contributing, and the cycle continues. Instead of this vicious circle, I believe that fast-tracking people on the strength of recommendations from *trusted* members is a good way of getting a virtuous circle: more people available to review patches, which means more competent contributors will gain enough of a reputation to be given committer privileges. and it gives them the benefit of input from people other than the mentor, and all of this happens *before* they have the opportunity (and the worry) of making mistakes(*). Both of these things serve to build community, and the second, IMO, results in a stronger, more confident contributor. Surely this will depend on the personality of the contributor? Not everyone appreciates being examined like that, even in an informal ad-hoc way, and while they might suck it up and accept
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] argparse suggestion
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 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 it, and I think it would be of sufficient general interest to include it with the standard library. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com -- Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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 be acceptable. It should be stated as part of our standard procedure however rather than being an exception to our standard procedure. Asking that one make public comments on a minimum of, say, 5 issues is hardly onerous. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
Steven D'Aprano steve at 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 and advice on the tracker. There isn't just the committers and the passive masses. (oh, and following your logic, we should ignore your advice, unless you actually contribute to the unglamourous work - do you?) In a meritocracy it isn't enough to be good at what you do, you also have to be known to be good. If this were the criterion then the answer would be simple: nobody seems to knows dangerjim in the Python community. (to make it clear: this is not a shot intended at him, rather at your own logic) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Should we drop active support of OSF/1?
-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 supporting Tru64 yet, but we don't have any buildbot running any of this systems... Deprecated systems are documented in PEP-11. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBS9XT9Zlgi5GaxT1NAQJkVgP9G6mj+Cm3BoXrAYQQXqfGevGWQhwQENgI ONH2B4XzOQZv9JTorDcWjU9Onf7s3YJ0AZk5pBxuekDOoblFKEz0yU3X40HLhU3N 8dxJ6aRNYBpPLYFbJp2tuGb2rs/VpfuKPAlmKxcRKUvC7heyxokFyXJnnXy2i50r XnHYwfz5PG8= =SseK -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
Antoine Pitrou wrote: Steven D'Aprano steve at 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 and advice on the tracker. There isn't just the committers and the passive masses. 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? (oh, and following your logic, we should ignore your advice, unless you actually contribute to the unglamourous work - do you?) In a meritocracy it isn't enough to be good at what you do, you also have to be known to be good. 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 about him, preferring to exercise their various prejudices in preference to taking a PSF member's word that he's a potentially valuable contributor along with an offer of supervision. I didn't realize we had so much effort available that we can ignore such offers. (to make it clear: this is not a shot intended at him, rather at your own logic) To make it clear: this is not intended as a criticism of you personally, rather of those who do not seem to feel that increasing the developer community is important. Perhaps diversity is just something you write in a statement. Some of the comments in this thread have seemed positively unwelcoming, even though I doubt that was the authors' intention. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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 feelings one way or another on the initial request. Of course, much of the discussion has little to do with the particulars of your request ;-). But, the answers to your questions above may make it more clear why I was looking for the enhanced privileges. James (dangerjim) has *NO* knowledge of Python -- he has done primarily C and Java coding. He *DOES* have time on his hands. This is why I proposed to him to do tracker triage. However, as I started walking him through some examples of triage, I realized that regular accounts don't have the privileges to do any of the things I was proposing. For example: Go into the list of task tasks and look at the ones with no priority. No priority effectively means normal priority. I will separately suggest that the latter be made the default so there is no need for anyone to make such busywork changes. Read through the description and any follow-ups and try to figure out what priority to give it. In most cases it will be normal. 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. What a boring thing to give to a newcomer. However, for some issues it will be clear they should be a higher or lower priority, even to someone who doesn't know Python. After years on the tracker, *I* do not try to make such judgemnts, so I am dubious about the ability of a non-Python newcomer to do so terribly sensibly. Then we went on to issue 5575 and read through it. In reading this one to determine the priority, it was clear that the ball was back in Collin's court, so I showed that I would look to see if Collin was a valid assignee (which he was) and assign it to him, with a comment about why. To my understanding, the 'asignee' is the person who will make a decision on the issue, which usually is the maintainer of the component. Who maintains the sqlite, hashlib and ssl modules? I do not know that 'asignee' should change every time the ball moves to another's court. I thought it stayed constant except when the assignee cannot deal with the issue. Is my understanding obsolete? Go into old bugs that have patches, and see if the patches cleanly apply against the trunk. If they do, do a make and make test. Add a comment with the outcome. This, and related C patch review activities, which do not require escalated privileges, would be *much* more useful, and probably more interesting to your C coding friend. 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. But, as I said, one of those two should be fixed, and I believe auto-assignment is gradually being improved. The most useful things a C coder can do he can do now. Issues are stalled by lack of review, not by blank priority fields. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
On Mon, Apr 26, 2010 at 17:42, R. David Murray rdmur...@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 of the recommendation of another person Since the recommendation is based on the persons merit, I fail to see the difference. may feel (especially to the non privileged) like a kind of nepotism. (It's not what you contribute, it's who you know). That is only a problem if we break the rules for certain people. But this discussion isn't about breaking the rules, but changing them. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
Jesse Noller jnoller at 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/22/why-arent-you-contributing-to-python/ http://www.reddit.com/r/Python/comments/burio/why_arent_you_contributing_to_python/ http://news.ycombinator.com/item?id=1285897 I have read most of the comments there and I haven't seen anyone suggest that privileges should be given earlier or more easily. (on the other hand, a clearer process perhaps wouldn't hurt) Does your private feedback suggest otherwise? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] merit
Lennart Regebro regebro at gmail.com writes: On Mon, Apr 26, 2010 at 17:42, R. David Murray rdmurray at 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 of the recommendation of another person Since the recommendation is based on the persons merit, I fail to see the difference. 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. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
On Mon, Apr 26, 2010 at 2:27 PM, Antoine Pitrou solip...@pitrou.net wrote: Jesse Noller jnoller at 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/22/why-arent-you-contributing-to-python/ http://www.reddit.com/r/Python/comments/burio/why_arent_you_contributing_to_python/ http://news.ycombinator.com/item?id=1285897 I have read most of the comments there and I haven't seen anyone suggest that privileges should be given earlier or more easily. (on the other hand, a clearer process perhaps wouldn't hurt) Does your private feedback suggest otherwise? I brought this up in the context of lowering the barrier to contribution; not as a value statement surrounding whether or not we should give out privileges sooner rather than later - most of the comments echo the sentiment of it's hard or unapproachable to become part of this project. I personally feel that if a person is willing to do the work, and someone vouches for them and is willing to be their mentor, there's no reason to wave our hands and say no. jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Make 'normal' the default tracker priority level
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 Smith (*8538), and Mark Dickenson (*8540). If possible, I think 'normal' should be the default in the hox or else there should be some sort of auto replacement. Currently, there are tracker maintainers spending time doing the replacement by hand. Sean R. has even requested privileges for someone in part just so he can do so too. Such activily strikes me as silly. I think it should be made unnecessary either by improving the tracker or by being declared to be unneeded. The only time a person should set the field to change it from normal (or to reverse such a change). Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] merit
On Mon, Apr 26, 2010 at 20:30, Antoine Pitrou solip...@pitrou.net wrote: Lennart Regebro regebro at gmail.com writes: On Mon, Apr 26, 2010 at 17:42, R. David Murray rdmurray at 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 of the recommendation of another person Since the recommendation is based on the persons merit, I fail to see the difference. 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, that's a blow against the merit-based position then. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Make 'normal' the default tracker priority level
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 Smith (*8538), and Mark Dickenson (*8540). You neglected my 2 dupes at 8537 and 8539! :) 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. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Make 'normal' the default tracker priority level
Terry Reedy tjreedy at 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/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] what to do if you don't want your module in Debian
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 tests), * bundle local copies of 3rd party modules and do not send your changes upstream, never document your changes in upstream code, * break API in every release, * break ABI in every second release, * do not ship all files needed to build the extension/docs/etc. in the source tarball, * do not list required dependencies in install_requires or INSTALL/README files, * if you list them, make sure you set the minimum required version to the one released yesterday, even if module works fine with version released 2 years ago, * create your own versioning schema (do not follow PEP-0386!), change it from time to time, * hardcode paths in the code and do it in as many places as you can (add new ones every few releases, that will teach them to not patch your code), * ignore FHS (you're using Windows after all); use __file__ whenever you can, * make sure there's nothing about license in LICENSE file or in file headers, * if you have some free time, create your own license, avoid BSD/MIT/(L)GPL, * if you use GPL, do not include full content of the license in the tarball, * release different tarballs with the same version number, * use waf as build-system, * release a new version without testing it with your own unit tests first to ensure that it will fail when your favourite Debian Developer tries to build it ;-) [debian-pyt...@l.d.o BCCed] -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
On Tue, 27 Apr 2010 03:45:39 am Antoine Pitrou wrote: Steven D'Aprano steve at 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 and advice on the tracker. There isn't just the committers and the passive masses. Yes, I know, I'm one of those contributors who have submitted patches. Only a couple, so far, but provided I'm not discouraged by the lack of anyone with the time or motivation to review them, there will probably be more in time. (By the way, if anyone wants to review issues 4037 and 8128, I'd be grateful.) (oh, and following your logic, we should ignore your advice, unless you actually contribute to the unglamourous work - do you?) That depends on what you call unglamourous work. No, I don't triage bugs. I don't have commit privileges, so I can't. Does hand-holding newbies who don't know the difference between a list and a dict count as unglamourous work? I'm not looking for a medal, I'm just trying to give back whatever little I'm able. In a meritocracy it isn't enough to be good at what you do, you also have to be known to be good. If this were the criterion then the answer would be simple: nobody seems to knows dangerjim in the Python community. Sean is nobody? We trust Sean to check in code. We trust him not to hand his username and password to dangerjim and let him loose. But do we trust his judgement that dangerjim is ready, willing and able to triage bugs? I think we can all take it as a given that commit privileges shouldn't be just given out to anyone. I think we can all agree that one good way to gain that trust is to submit lots of high-quality patches. But what I don't understand is why there is so much resistance to the idea of accepting a personal recommendation from somebody who is trusted with commit privileges, even in principle. The reasons given don't strike me as convincing, especially the idea that it is nepotistic. It's not like commit privileges is a reward that is valuable in and of itself, or that they can't be revoked if dangerjim turns out not to have the chops that Sean said. Dangerjim doesn't know Python, he can't contribute by writing patches, but he could make a valuable contribution by reviewing them. Sean has said he'll mentor him. Meritocracies are reputation-based, and the thing about reputation-based systems is that reputation propagates: I trust Alice because I've seen direct evidence of her merit, and I trust Bob on the basis that Alice vouches for him and I trust her to be a good judge of merit. Such propagation is lossy, of course. I trust Alice more than Bob. The further away from direct evidence of merit, the less confidence I have. -- Steven D'Aprano ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Drop OS/2 support?
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 and deal with the issue on OS/2. I realized that the code was broken on OS/2 because it calls bytes2str(path) whereas this function takes two mandatory arguments. My patch factorize the creation of envlist, so fixing OS/2 should now be easier. The issue is now closed. The 3.x branch needs quite a bit of work on OS/2 to deal with Unicode, as OS/2 was one of the earlier OSes with full multiple language support and IBM developed a unique API. I'm still struggling to come to terms with this, partly because I myself don't need it. Ah ok, Python3 doesn't work on OS/2 :-) -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
Steven D'Aprano steve at 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 believe) said, it's certainly as useful as changing form values and checkboxes :) By the way, it isn't about commit privileges, but tracker rights. I don't think we would consider giving commit rights to someone who hasn't ever participated in the community, and apparently isn't a Python user. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Mon, Apr 26, 2010 at 9:19 PM, Piotr Ożarowski pi...@debian.org 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... and they could make a good section in the Hitchhiker's guide to packaging ;) [...] * ignore FHS (you're using Windows after all); use __file__ whenever you can, 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.. Notice that we have started to work on fixing this - http://hg.python.org/distutils2/file/tip/docs/design/wiki.rst Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should we drop active support of OSF/1?
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 easy-to-remove configure error in 3.2, and remove the support in 3.3. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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 about him, Ahem. As I indicated in my first response to Sean, the first thing I did was to check the tracker for issues listing 'damgerjim' on the nosy list. (Simce people who post messages get auto-added to such and I do not see a message versus issue search page.) I found none and asked Sean for more info. When Sean provided more, I made more particular-to-the-situation responses. I separately posted, in a new thread, a suggestion that we change the tracker to eliminate busywork rather than recruit new people to do it for us. What a way to drive new recruits away. === Several people have asked what danger?. The most delicate part of triage is closing issues that should never have been opened, either because they ask questions that belong on python-list or make foolish bug claims. These come from newbies who could be driven away from Python by less than polite responses from someone with 'official' status. So, again, I think someone should actively exhibit the ability to politely respond to strangers before being given 'official' power to close issues. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
[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 (you're using Windows after all); use __file__ whenever you can, 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.. Notice that we have started to work on fixing this - http://hg.python.org/distutils2/file/tip/docs/design/wiki.rst 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 using __file__ again) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
On Mon, Apr 26, 2010 at 01:19, Paul Moore p.f.mo...@gmail.com wrote: On 26 April 2010 07:12, Sean Reifschneider j...@tummy.com 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 things, rather than asking for escalated privileges for one individual? (Or more likely, as well as doing so, as changing the default is likely to be a longer discussion...) No, the permission levels are purposefully where they are. I have personally had back-and-forths with bug submitters over the priority of an issue because they just happened to think it was more important than it really was. It gets really annoying when you start to get constant bug updates because someone chose to change the priority on their own. Besides the fields under discussion are for developers, not the bug submitters. Sean's friend can start off easily by simply commenting on an issue saying this issue should probably have a normal priority and someone with Developer privileges can then go in and either set it or disagree. As he does that more and more he will get noticed and recommended for elevated privileges or he can ask for them. -Brett Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Make 'normal' the default tracker priority level
On Mon, Apr 26, 2010 at 12:01, Antoine Pitrou solip...@pitrou.net wrote: Terry Reedy tjreedy at 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 code change as I can't see how to do it through the web API. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Mon, Apr 26, 2010 at 10:10 PM, Piotr Ożarowski pi...@debian.org 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.html http://wiki.debian.org/GettingPackaged Will check these, thx [...] * ignore FHS (you're using Windows after all); use __file__ whenever you can, 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.. Notice that we have started to work on fixing this - http://hg.python.org/distutils2/file/tip/docs/design/wiki.rst 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 using __file__ again) Sounds like a good advice to help packagers changing it, we'll add something about that in the guide. Also if you have some time to read it, your feedback as a packager would be appreciated http://guide.python-distribute.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Make 'normal' the default tracker priority level
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 currently unset? I would do that behind roundup, so that it appears as if the issue was already created with that priority. That way, those issues don't appear as if they had recent activity. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Make 'normal' the default tracker priority level
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/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Make 'normal' the default tracker priority level
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 which have them currently unset? I think the only risk is for issues that had a priority and were then deliberately changed to unset. Given how unlikely that is, I think you can go ahead and do this. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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 the difference between a list and a dict count as unglamourous work? Whether on python-list or tracker issues (which possibly should not have been opened), yes. I'm not looking for a medal, I'm just trying to give back whatever little I'm able. I would not want you to drop hand-holding to do tracker admin. I don't understand is why there is so much resistance to the idea of accepting a personal recommendation from somebody who is trusted with commit privileges, even in principle. Python tracker admins represent the core community to the larger Python world. There are two skills needed for such a responsibility. One is the ability to categorize in accord with vague norms. The other is social sensitivity in responding to strangers, especially tracker newbies. These are quite orthogonal to the ability to code or be someone's good buddy. Since one can do hard-to-repair damage, I think minimal evidence of these two needed skills is appropriate. Dangerjim doesn't know Python, he can't contribute by writing patches, but he could make a valuable contribution by reviewing them. Which he can do now, without tracker admin privileges. If successful, that would be more helpful than busywork admin. Actually, I can imagine a C coder writing certain C patches, given a decent spec, without really knowing Python. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Make 'normal' the default tracker priority level
On Mon, Apr 26, 2010 at 13:39, Martin v. Löwis mar...@v.loewis.de 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 which have them currently unset? I would do that behind roundup, so that it appears as if the issue was already created with that priority. That way, those issues don't appear as if they had recent activity. I say yes. Might as well just clean up that field now while we are thinking about it. -Brett Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Make 'normal' the default tracker priority level
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 see '- no selection -' for a new new-issue, but thank you for attending to this. This will fix a minor but long-standing annoyance. Shall I also set the priority on all past issues to normal which have them currently unset? I think the only risk is for issues that had a priority and were then deliberately changed to unset. Given how unlikely that is, I think you can go ahead and do this. To me, the priority should never be unset, so please go ahead. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Make 'normal' the default tracker priority level
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 priority on all past issues to normal which have them currently unset? I think the only risk is for issues that had a priority and were then deliberately changed to unset. Given how unlikely that is, I think you can go ahead and do this. I can also filter them out: roundup_tracker= select distinct id from _issue, issue__journal where id=nodeid and _priority is null and action='set' and params like '%priority%'; id -- 1404 1601 3947 5249 5273 5334 6150 6453 7540 I will try to expand this to a proper update query, but only tomorrow. Regards, Martin P.S. Interestingly, it was tjreedy who unset the priority on issue 6453 where it was previously normal :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Make 'normal' the default tracker priority level
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 issues. Shall I also set the priority on all past issues to normal which have them currently unset? I think the only risk is for issues that had a priority and were then deliberately changed to unset. Given how unlikely that is, I think you can go ahead and do this. I can also filter them out: roundup_tracker= select distinct id from _issue, issue__journal where id=nodeid and _priority is null and action='set' and params like '%priority%'; id -- 1404 1601 3947 5249 5273 5334 6150 6453 7540 I will try to expand this to a proper update query, but only tomorrow. Regards, Martin P.S. Interestingly, it was tjreedy who unset the priority on issue 6453 where it was previously normal :-) An accident. As I wrote in the next message: Must have been random glitch. I certainly did not change state and priority. David Murray replies I wonder if your browser is doing something weird with the form field settings. Or it may have as you say been a random thing...I know that has happened to me once or twice where I refreshed the page in an odd order and reset some fields I wasn't intending to reset. 7540, 5334, 5273, 5249, 3947, 1404 are release blocker or other higher-than-normal priority issue whose high priorities were cleared when and as the issue was closed. Hirokazu Yamamoto (ocean-city), in particular, seems to think that higher-than-normal priorities should be cleared when issues are closed. I presume this is a mis-understanding. A critical open issue should just become a closed critical issue. If so, the clearings should be undone. 6150 had release-blocker set and cleared the day before closing. Not sure on this one whether it is case of above or below. It hardly matters though. 1601 had priority set to high and reverted on same day by different people. It should have been set back to normal. I am willing to fix all of the above by hand, if you want, but refrained for the moment because of the spurious message-to-nosy-list spew. Is there anyway to make unsetting not possible? Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
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 were being sarcastic. :) I almost starting writing an email asking why anyone would seriously want that. This is a great list. Something I have been thinking about lately dovetails with this, but from a different direction. Let's ask why the problems you enumerate occur, and what can we do about them? 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 and/or library template for this which would make it easy to start a new project automating as much as possible, and doing things The Right Way. It may also be worthwhile putting very obvious carrots (rather than sticks) out there to encourage people to write packages using best practices. For example, once snakebite is operational, I could imagine some kind of automated testing suite for PyPI packages. IOW, if you play by rules A, B and C, we'll automatically grab your new package, build it, run the test suite, and put a gold star on your PyPI page. Some things of course, we can't automate, but I think the HGtP should provide clear examples of best practices, and tools to adhere to them where possible. It is okay (in fact encouraged) to be opinionated and not provide a lot of variation. Advanced developers can figure out how to do complex things correctly, but let's make it easy for the simpler 80% of packages out there. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
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 sure we've talked about this before.) -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
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 the best practice for this? (I'm pretty sure we've talked about this before.) 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/ subdirectory. Writing portable libraries (with portable setup.py files!) is difficult to do that way, though. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Mon, Apr 26, 2010 at 11:45 PM, Barry Warsaw ba...@python.org 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 and/or library template for this which would make it easy to start a new project automating as much as possible, and doing things The Right Way. Related things : - Sean started mkpkg in distutils2, which asks you questions and creates a setup.py file. - Srid created a Paste-based script that creates a project skeleton Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Mon, Apr 26, 2010 at 11:46 PM, Barry Warsaw ba...@python.org 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 the best practice for this? (I'm pretty sure we've talked about this before.) For setuptools-based project I guess it is yes, so you can read them in zipped eggs. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Apr 27, 2010, at 12:03 AM, Tarek Ziadé wrote: On Mon, Apr 26, 2010 at 11:45 PM, Barry Warsaw ba...@python.org 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 and/or library template for this which would make it easy to start a new project automating as much as possible, and doing things The Right Way. Related things : - Sean started mkpkg in distutils2, which asks you questions and creates a setup.py file. - Srid created a Paste-based script that creates a project skeleton I knew about Srid's but not Sean's. Thanks, I'll take a look. I don't want to stifle innovation here, but let's see if there are commonalities we can share. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
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 projects to be portable.. Until then, isn't pkg_resources the best practice for this? (I'm pretty sure we've talked about this before.) 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/ subdirectory. Writing portable libraries (with portable setup.py files!) is difficult to do that way, though. Tarek pointed to the rest page that captured some of the thinking on this developed at Pycon. There's really two sides to it - what does the programmer write and how does that integrate with the system? I really don't think the developer should go through any contortions to make it work right for the platform. For one thing, there's no way they can do it for every platform their code might end up on. It's a lose to attempt it. Tarek's design allows for separation of concerns and indirection so the programmer can worry about the parts they care about, and the platform packagers can worry about the parts they care about. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Mon, Apr 26, 2010 at 11:56 PM, Robert Kern robert.k...@gmail.com 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/ subdirectory. Writing portable libraries (with portable
setup.py files!) is difficult to do that way, though.
Well, the only portable way to read a resource file these days in
Python is to put it in your
project source tree so you know for sure you can access it the same way
no matter what the platform is. Thus, using __file__.
The key to fix this is to have a registered list of paths for each
platform at Python level.
Roughly summarized : the work we are doing will consist of defining
variables that points to target paths for each platform (like
/usr/shared in linux) at Python level, and let the developers define
that a file is under a path
defined by a variable (like shared).
For example, a project will be able to read/write the foo.txt file
using: pkgutil.open('shared', 'foo.txt')
pkgutil will look in Python for the path corresponding to shared and
expand it. The result will vary depending
on the platform, and the os packagers will be able to change that path
globally in Python or locally in the project.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Tue, Apr 27, 2010 at 9:15 AM, David Malcolm dmalc...@redhat.com 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 confirm, from bitter experience, that your list is also highly applicable to Fedora and RHEL... Honestly, it's enough to publish your python application/library/module to pypi (at least this is true for my work). Re-packing some xyz Linux distribution's package mangement system just seems useless and a waste of time (with exceptions ofc). --James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On 27/04/2010 00:26, James Mills wrote: On Tue, Apr 27, 2010 at 9:15 AM, David Malcolmdmalc...@redhat.com 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 confirm, from bitter experience, that your list is also highly applicable to Fedora and RHEL... Honestly, it's enough to publish your python application/library/module to pypi (at least this is true for my work). Re-packing some xyz Linux distribution's package mangement system just seems useless and a waste of time (with exceptions ofc). The point of the discussion has been how you can structure your package so that Linux distribution maintainers can repackage it *for you* whilst still remaining portable to other platforms. Even if you never intend to repackage your project yourself following these best practises seems like a good idea. (Unless you *really* don't want them packaged for debian - in which case you now have a handy guide telling you how you can ensure this.) All the best, Michael --James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what to do if you don't want your module in Debian
On Tue, Apr 27, 2010 at 5:10 AM, Piotr Ożarowski pi...@debian.org 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 using __file__ again) May I ask why this is not actually the solution to resources location ? For example, let's say we have (hypothetic version of distutils supporting autoconf paths): python setup.py install --prefix=/usr --datadir=/var/lib/foo --manpath=/somefunkypath Then the install step would generate a file __install_path.py such as: PREFIX = /usr DATADIR = /var/lib/foo MANPATH = /somfunkypath There remains then the problem of relocatable packages, but solving this would be easy through a conditional in this generated file: if RELOCATABLE: PREFIX = $prefix ... else: and define $prefix and co from __file__ if necessary. All this would be an implementation detail, so that the package developer effectively do from mypkg.file_paths import PREFIX, DATADIR, etc... This is both simple and flexible: it is not mandatory, it does not make life more complicated for python developers who don't care about platform X. FWIW, that's the scheme I intend to support in my own packaging solution, cheers, David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
On Tue, 27 Apr 2010 05:37:31 am Antoine Pitrou wrote: Steven D'Aprano steve at 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. No, of course not. There are always other reasons, the biggest is too many things to do and not enough time to do it. If I did review patches, would they be accepted on the strength on my untrusted reviews? But this isn't about my reasons for not being more active on the bug tracker. This is about how we decided whether or not to give tracker rights to a volunteer. I think that being vouched for by a trusted member of good standing who offers to act as mentor should be sufficient grounds for giving tracker rights to the volunteer. Apparently some disagree. How do we resolve this, since we're obviously not persuading each other. Put it to a vote? Ask the BDFL? By the way, it isn't about commit privileges, but tracker rights. I don't think we would consider giving commit rights to someone who hasn't ever participated in the community, and apparently isn't a Python user. Correction noted, thank you. -- Steven D'Aprano ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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 close to synonymous (I find it hard to imagine that people specify priority: normal in searches very often), but it's not synonymous to the reporter in most cases. I've had users tell me that unselected looks untidy, so except for assignee, where not assigned is very significant information, I either provide a default (which is not hard to do), or require that the user provide values in my tracker (where I've managed to reduce those fields to two, the issue summary line and the component). What a boring thing to give to a newcomer. [...] Issues are stalled by lack of review, not by blank priority fields. Sure, some people would be massively turned off by such duty, but others hardly mind it at all. The newcomer can always just say no. I don't think the point was to find a person to be Priority-Setter- for-Life, but rather to familiarize dangerjim with the bug tracker, the issues, and do something at least a little bit useful. Agreed, I doubt that setting priority would increase the amount of review done, since developers will generally disagree with the reporter (and non-dev third parties) about priority anyway. But getting bugs assigned to people so that they would appear in my bugs might help a little bit. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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 the way things are now. I was attracted to the Python community, in part, because the development model seemed so mature and well specified. I felt that it was clear from the current documented policies on how I could contribute -- do these things and get these privileges. That simple. Moreover, by having the different stages (do these things to get tracker privileges, do these other things to get commit privileges, etc...) it was more clear how I could set personal milestones for myself to become a contributing member of the community. I find these stages useful for the current community to somewhat gauge an unknown person's ability, but also for that unknown person to develop and learn about the community at a reasonable pace. Yes, I know that the issue in question involves not a _completely_ unknown person, but someone who is known by an existing member of the community. However, this is about a community choice and not just one person's choice. Not to mention the fact that most anyone could have already submitted the amount of comments needed to get enhanced tracker privileges in the amount of time that has been spent on this thread :-) -- Meador ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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 commented, I don't think anybody is worrying about offending anybody; there is an understanding that there's a process issue to be resolved. The question is how best to build the community. There are two camps, the quantity camp (low cost of contribution means more contributors, and that's good), and the quality camp (more interaction within the community, especially of experienced developers with newcomers, means more effective contributors and that's good). I didn't realize we had so much effort available that we can ignore such offers. Steve, calm down; nobody contributing to the thread is ignoring the offer, and the status quo terms seem to be acceptable to both Sean and dangerjim. They correctly asked for more privilege so that the proposed work can be done more efficiently. Equally correctly, there is a discussion of whether an exception to past practice should be made here, and whether it's worth changing that past practice. I find RDM's argument quite compelling, that the current policy does impose some costs on the newcomer and the mentor, but that on the other hand it does strongly encourage interactions which both build community in the sense of interpersonal relationships and improve the mentoring process for the actual work being done. He concludes that the small costs involved (including the possibility of discouraging some potential contributors) are more than compensated for by the quality of the product. Where do you disagree with that logic? To make it clear: this is not intended as a criticism of you personally, rather of those who do not seem to feel that increasing the developer community is important. Perhaps diversity is just something you write in a statement. *By definition*, a community is not diverse in the most fundamental sense. As long as Pythonicity is important to Python, there is danger as well as opportunity in more rapid influx of newcomers. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] merit
Lennart Regebro writes: On Mon, Apr 26, 2010 at 20:30, Antoine Pitrou solip...@pitrou.net 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, that's a blow against the merit-based position then. :) Not at all. Merit is determined not by absolute competence, but by fitness for the range of tasks to be performed. I don't really understand how someone who is not familiar with Python internals or with the Python community can be expected to have any *immediate* merit beyond fast learner. Until a newcomer does that learning, what's the hurry in granting privileges? Note that this discussion has brought up a number of fine points about tracker work (cf Terry Reedy's posts) that Sean may not have been aware of. Had tracker privilege been granted without discussion, he still would not know about them! *Nor would I.* The discussion has had educational benefits beyond the newcomer. This is RDM's thesis about growing the community in action. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
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 work. :) Counting checkins is not the appropriate way to measure work here, and there are externalities. In my experience (in other projects, I suspect it applies to Python, too), most patches produced by newcomers scratch very personal itches that almost nobody else cares about. Many of their bugs, however, affect a large number of users. Similarly, but much less seriously, I suspect that issue triage by newcomers will not result in very Pythonic decisions. I won't say that setting priority or assignee inappropriately fucks things up, but they do increase entropy of the project. Terry Reedy disagreed with Sean's judgment about setting priority and assignee, a useful discussion that would *not* have happened with the policy you propose. It might be preferable for that discussion to have happened on the tracker-discuss list, of course, but IMHO it's good for such threads to happen somewhere that tracker workers can see it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
