Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)
On 24 Apr, 2010, at 18:15, Michael Foord wrote: > On 18/04/2010 15:13, Ronald Oussoren wrote: >> On 14 Apr, 2010, at 23:37, Michael Foord wrote: >> >> >>> On 14/04/2010 23:32, Greg Ewing wrote: >>> Michael Foord wrote: > Building Python requires, I believe, the XCode development tools to be > installed. Even then, building a full version of Python - with *all* the > C extensions that are part of a Python release - is not a trivial task. > What's non-trivial about it? I usually find that the normal "./configure; make; make install" sequence works fine without any further intervention. If you want a framework installation you have to read the README and use a couple of extra options, but it still works very smoothly. >>> A build on my machine produces output similar to: >>> >>> >>> Python build finished, but the necessary bits to build these modules were >>> not found: >>> _bsddb dl gdbm >>> imageoplinuxaudiodev ossaudiodev >>> readline spwd sunaudiodev >>> To find the necessary bits, look in setup.py in detect_modules() for the >>> module's name. >>> >>> >>> Failed to build these modules: >>> _tkinter >>> >>> Obviously many of those are not meant to be built and I usually build >>> Python for running the test suite - so I don't care about not having >>> Tkinter. A new user of Python would most certainly care about not having >>> Tkinter. >>> >> >> What's the OS version? Do you have a copy of Tcl/Tk in /Library/Frameworks? >> > > 10.6.3 and yes I have Tcl and Tk in /Library/Frameworks. How do I determine > which versions they are? $ ls -l /Library/Frameworks/Tcl.framework/Versions total 8 drwxr-xr-x 9 sysadmin admin 306 Oct 6 2009 8.5 lrwxr-xr-x 1 sysadmin admin3 Oct 25 2009 Current -> 8.5 As you can see, my system has Tcl 8.5. Ronald smime.p7s Description: S/MIME cryptographic 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
[Python-Dev] Property inheritance in Python
Hi Python experts. [It should be obvious, but you can run the code in this message via python -m doctest body.txt if you saved it as body.txt] In an application I develop on I want to use properties instead of the getter/setter paradigm. I ran into a problem overriding a property in a subclass. While I know how to do it with current Python, I propose changing the behaviour to be more consistent. For presentation, here is a stupid example using getters and setters: >>> class BaseGetterSetter(object): ... def get_p(self): ... return self._p ... def set_p(self, value): ... self._p = value >>> class DerivedGetterSetter(BaseGetterSetter): ... def get_p(self): ... return super(DerivedGetterSetter, self).get_p() * 2 ... def set_p(self, value): ... super(DerivedGetterSetter, self).set_p(value / 2) >>> d = DerivedGetterSetter() >>> d.set_p(42) >>> d._p 21 >>> d.get_p() 42 When translating this to use properties, I would come up with something like this: >>> class BaseProp(object): ... @property ... def p(self): ... return self._p ... @p.setter ... def p(self, value): ... self._p = value >>> class DerivedProp(BaseProp): ... @property ... def p(self): ... return super(DerivedProp, self).p * 2 ... @p.setter ... def p(self, value): ... super(DerivedProp, self).p = value / 2 >>> d = DerivedProp() >>> d._p = 21 >>> d.p 42 >>> d.p = 50 Traceback (most recent call last): ... AttributeError: 'super' object has no attribute 'p' As can be seen, using super like in the getter/setter approach above works for fget but not for fset. Support for using the getter via super() was added for Python 2.3 according to http://mail.python.org/pipermail/python-dev/2003-April/034702.html I think it would be more consistent to be able to access the __set__ call via super() as well. Working around -- The problematic code boils down to >>> super(DerivedProp, d).p = 1 Traceback (most recent call last): ... AttributeError: 'super' object has no attribute 'p' which can be worked around like this: >>> BaseProp.p.fset(d, 25) >>> BaseProp.p.__set__(d, 10) I'd rather use the method resolution order computed by Python so that mixin classes can extend the behaviour of properties. For that, one can extend super: >>> class duper(super): ... def __setattr__(self, name, value): ... mro = self.__self_class__.__mro__ ... for pos in xrange(len(mro)): ... if mro[pos] == self.__thisclass__: ... break ... for pos in xrange(pos+1, len(mro)): ... tmp = mro[pos] ... if isinstance(tmp, type) and name in tmp.__dict__: ... desc = tmp.__dict__[name] ... desc.__set__(self.__self__, value) ... return >>> duper(DerivedProp, d).p = 100 >>> d.p 200 Extending super --- I wrote a test case for the super() behaviour as I would like it to be and implemented the __setattr__ of duper above into super's C implementation. The code is not of production quality and there are some open questions. But I figured that I'd rather ask for opinions before spending even more time on this. The code is available on launchpad at this URL: https://code.launchpad.net/~torsten/python/descr-set-via-super What do you think, do you agree with my understanding or am I completely wrong? Hoping for some insightful comments, Torsten ___ 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] Enhanced tracker privileges for "dangerjim" to do triage.
I'm trying to get a good friend of mine to start doing bug triage on Python. As part of my trying to mentor him on it, I've found that many of the common things I do in triage, like setting a priority for priorityless bugs, assigning them to people who obviously are the next step, requires enhanced privileges. He has no reputation in the Python community, so I'd be up for getting him started on things that require fewer privileges like verifying older patches still apply against newer Pythons, or maybe summarizing priority/assignment changes to the list and having someone (possibly me) make the changes, etc... However, I will step up for him and say that I've known him a decade, and he's very trustworthy. He has been the president (we call that position Maximum Leader) of our Linux Users Group here for 5 years or so. Thoughts? Thanks, Sean -- Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability signature.asc Description: OpenPGP 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.
Sean> However, I will step up for him and say that I've known him a Sean> decade, and he's very trustworthy. He has been the president (we Sean> call that position Maximum Leader) of our Linux Users Group here Sean> for 5 years or so. Given that Sean is vouching for him I'm fine with it. Skip ___ 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.
pobox.com> writes: > > > Sean> However, I will step up for him and say that I've known him a > Sean> decade, and he's very trustworthy. He has been the president (we > Sean> call that position Maximum Leader) of our Linux Users Group here > Sean> for 5 years or so. > > Given that Sean is vouching for him I'm fine with it. I'm not sure I agree. Of course it could be argued the risk is minimal, but I think it's better if all people go through the same path of proving their motivation and quality of work. And if there's something wrong with that process we'd better address it than give random privileges to people we like :) 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.
>> Given that Sean is vouching for him I'm fine with it. Antoine> I'm not sure I agree. Of course it could be argued the risk is Antoine> minimal, but I think it's better if all people go through the Antoine> same path of proving their motivation and quality of work. And Antoine> if there's something wrong with that process we'd better Antoine> address it than give random privileges to people we like :) Let me expand on my original message. Sean has been an integral part of the Python community for many years, keeping much of our hardware and software humming and providing critical network expertise at PyCon. I don't think we have to be such slaves to a set of rules that we can't use an implicit trust network to make decisions in certain cases. I trust Sean's judgement. Skip ___ 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.
2010/4/25 : > > >> Given that Sean is vouching for him I'm fine with it. > > Antoine> I'm not sure I agree. Of course it could be argued the risk is > Antoine> minimal, but I think it's better if all people go through the > Antoine> same path of proving their motivation and quality of work. And > Antoine> if there's something wrong with that process we'd better > Antoine> address it than give random privileges to people we like :) > > Let me expand on my original message. Sean has been an integral part of the > Python community for many years, keeping much of our hardware and software > humming and providing critical network expertise at PyCon. I don't think we > have to be such slaves to a set of rules that we can't use an implicit trust > network to make decisions in certain cases. I trust Sean's judgement. I don't think Antoine is questioning Sean's judgement but rather that we should get into the habit of giving some people "shortcuts" through the regular process. -- Regards, Benjamin ___ 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 09:39 pm, solip...@pitrou.net wrote: pobox.com> writes: Sean> However, I will step up for him and say that I've known him a Sean> decade, and he's very trustworthy. He has been the president (we Sean> call that position Maximum Leader) of our Linux Users Group here Sean> for 5 years or so. Given that Sean is vouching for him I'm fine with it. I'm not sure I agree. Of course it could be argued the risk is minimal, but I think it's better if all people go through the same path of proving their motivation and quality of work. And if there's something wrong with that process we'd better address it than give random privileges to people we like :) +1 As others have said, I don't have any problem with Sean's judgement. That's not what's being questioned here. Jean-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.
Le Sun, 25 Apr 2010 16:59:14 -0500, Benjamin Peterson a écrit : > > I don't think Antoine is questioning Sean's judgement but rather that we > should get into the habit of giving some people "shortcuts" through the > regular process. Yes, exactly. If we often take shortcuts with our own process, it can appear unfair and demotivating to regular people (who must go through the normal process). I'm sure we all know people who are demonstrably competent in other communities, still we don't give them privileges right away. ___ 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.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Antoine Pitrou wrote: > pobox.com> writes: >> >> Sean> However, I will step up for him and say that I've known him a >> Sean> decade, and he's very trustworthy. He has been the president (we >> Sean> call that position Maximum Leader) of our Linux Users Group here >> Sean> for 5 years or so. >> >> Given that Sean is vouching for him I'm fine with it. > > I'm not sure I agree. Of course it could be argued the risk is minimal, but I > think it's better if all people go through the same path of proving their > motivation and quality of work. > And if there's something wrong with that process we'd better address it than > give random privileges to people we like :) I think there is a definite "unpriced externality" to keeping the process barriers high here. I don't belive from conversations at the language summit / PyCon that the community is being overrun with hordes of unworthies clamoring to triage Python bugs: rather the opposite, in fact. It seems to me that backing from an established community member ought to be enough to get a prospective triageur at least provisional roles to do the work, with the caveat that it might be revoked it it didn't turn out well. If it does turn out well, then look to *expand* that user's roles in the community, with a nice helping of public acclaim to go with it. I am not arguing for "making exceptions for friends" here; rather that the acknowledged issues with inclusiveness / espansion of the developer community require making changes to the rules to encourage more participation. BTW, language like "prov[ing] their motivation" is itself demotivating, and likely contributes to the status quo ante. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvUxqMACgkQ+gerLs4ltQ7Z9gCgn9Rox2dPLR/Vkj9WLMziUdcl 9a8AoLgzXSIUAKsibm1e2ww9feBNd3P/ =iHgN -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.
Tres Seaver wrote: > Antoine Pitrou wrote: >> pobox.com> writes: >>> Sean> However, I will step up for him and say that I've known him a >>> Sean> decade, and he's very trustworthy. He has been the president (we >>> Sean> call that position Maximum Leader) of our Linux Users Group here >>> Sean> for 5 years or so. >>> >>> Given that Sean is vouching for him I'm fine with it. >> I'm not sure I agree. Of course it could be argued the risk is minimal, but I >> think it's better if all people go through the same path of proving their >> motivation and quality of work. >> And if there's something wrong with that process we'd better address it than >> give random privileges to people we like :) > > I think there is a definite "unpriced externality" to keeping the > process barriers high here. I don't belive from conversations at the > language summit / PyCon that the community is being overrun with hordes > of unworthies clamoring to triage Python bugs: rather the opposite, in > fact. It seems to me that backing from an established community member > ought to be enough to get a prospective triageur at least provisional > roles to do the work, with the caveat that it might be revoked it it > didn't turn out well. If it does turn out well, then look to *expand* > that user's roles in the community, with a nice helping of public > acclaim to go with it. > > I am not arguing for "making exceptions for friends" here; rather that > the acknowledged issues with inclusiveness / espansion of the developer > community require making changes to the rules to encourage more > participation. > > BTW, language like "prov[ing] their motivation" is itself demotivating, > and likely contributes to the status quo ante. With my PSF hat on I'd like to support Tres here (and, by extension, Sean's proposal). Lowering the barriers of entry is a desirable goal. If adding people created work for already-busy developers then I'd be against it*, but with Sean offering to mentor his new protege and ensure that he limits his role to triage initially that doesn't seem to be an issue. Maybe it's time to review the way people "prove their motivation and the quality of their work"? regards Steve * I'd be against it, but I'd fight to change the development process so that adding new people *didn't* create work. We should, in my opinion, be looking for a continual influx of new worker bees. -- 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 00:18, Steve Holden wrote: Tres Seaver wrote: Antoine Pitrou wrote: pobox.com> writes: Sean> However, I will step up for him and say that I've known him a Sean> decade, and he's very trustworthy. He has been the president (we Sean> call that position Maximum Leader) of our Linux Users Group here Sean> for 5 years or so. Given that Sean is vouching for him I'm fine with it. I'm not sure I agree. Of course it could be argued the risk is minimal, but I think it's better if all people go through the same path of proving their motivation and quality of work. And if there's something wrong with that process we'd better address it than give random privileges to people we like :) I think there is a definite "unpriced externality" to keeping the process barriers high here. I don't belive from conversations at the language summit / PyCon that the community is being overrun with hordes of unworthies clamoring to triage Python bugs: rather the opposite, in fact. It seems to me that backing from an established community member ought to be enough to get a prospective triageur at least provisional roles to do the work, with the caveat that it might be revoked it it didn't turn out well. If it does turn out well, then look to *expand* that user's roles in the community, with a nice helping of public acclaim to go with it. I am not arguing for "making exceptions for friends" here; rather that the acknowledged issues with inclusiveness / espansion of the developer community require making changes to the rules to encourage more participation. BTW, language like "prov[ing] their motivation" is itself demotivating, and likely contributes to the status quo ante. With my PSF hat on I'd like to support Tres here (and, by extension, Sean's proposal). Lowering the barriers of entry is a desirable goal. If adding people created work for already-busy developers then I'd be against it*, but with Sean offering to mentor his new protege and ensure that he limits his role to triage initially that doesn't seem to be an issue. Maybe it's time to review the way people "prove their motivation and the quality of their work"? Perhaps mentoring by an established committer could become a *standard* acceptable way to gain tracker privileges. It makes a lot of sense for the barriers to entry for bug triaging to be substantially lower than for commit privileges. I agree that we should try and establish straightforward and consistent procedures, but also agree that those procedures should serve the community rather than vice-versa. All the best, Michael regards Steve * I'd be against it, but I'd fight to change the development process so that adding new people *didn't* create work. We should, in my opinion, be looking for a continual influx of new worker bees. -- 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 Sun, Apr 25, 2010 at 10:18:47PM +, Antoine Pitrou wrote: > > I don't think Antoine is questioning Sean's judgement but rather that we > > should get into the habit of giving some people "shortcuts" through the > > regular process. > > Yes, exactly. > If we often take shortcuts with our own process, it can appear unfair and > demotivating to regular people (who must go through the normal process). I agree with Antoine's point here. As much as I respect Sean and his contributions, it is important to consider the implications as it may appear to others. If you look at Daniel Diniz, who has enhanced tracker privileges, he started off by using the normal tracker privilege commenting on bugs, patches and within *weeks*, he started triaging bugs with enhanced privs. That kind of seems to me a middle-way, as in you start off triaging in a normal mode with a backing of mentor, it becomes a easy way to upgrade very soon. -- Senthil Man must shape his tools lest they shape him. -- Arthur R. Miller ___ 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/25/2010 4:31 PM, Sean Reifschneider wrote: I'm trying to get a good friend of mine to start doing bug triage on Python. What is *his* interest? How long has he known and used Python? As part of my trying to mentor him on it, I've found that many of the common things I do in triage, like setting a priority for priorityless bugs, assigning them to people who obviously are the next step, requires enhanced privileges. And enhanced knowledge of the process (and people, for assigning). He has no reputation in the Python community, so I'd be up for getting him started on things that require fewer privileges like verifying older patches still apply against newer Pythons, or maybe summarizing priority/assignment changes to the list and having someone (possibly me) make the changes, etc... To me, this seems the appropriate way to start. Has he registered for the tracker yet? With his real name? How many issues has he commented on? I searched for issues with 'dangerjim' on the nosy list and found none. I think someone should have read at least, say, 10 issues and commented on at least, say, 5, to show real interest and sanity before being elevated. However, I will step up for him and say that I've known him a decade, and he's very trustworthy. He has been the president (we call that position Maximum Leader) of our Linux Users Group here for 5 years or so. Thoughts? I consider particular knowledge and interest to be as important and trustworthness. 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 25 Apr, 11:18 pm, st...@holdenweb.com wrote: Tres Seaver wrote: Antoine Pitrou wrote: pobox.com> writes: Sean> However, I will step up for him and say that I've known him a Sean> decade, and he's very trustworthy. He has been the president (we Sean> call that position Maximum Leader) of our Linux Users Group here Sean> for 5 years or so. Given that Sean is vouching for him I'm fine with it. I'm not sure I agree. Of course it could be argued the risk is minimal, but I think it's better if all people go through the same path of proving their motivation and quality of work. And if there's something wrong with that process we'd better address it than ^^^ Don't overlook this part of Antoine's post. give random privileges to people we like :) I think there is a definite "unpriced externality" to keeping the process barriers high here. I don't belive from conversations at the language summit / PyCon that the community is being overrun with hordes of unworthies clamoring to triage Python bugs: rather the opposite, in fact. It seems to me that backing from an established community member ought to be enough to get a prospective triageur at least provisional roles to do the work, with the caveat that it might be revoked it it didn't turn out well. If it does turn out well, then look to *expand* that user's roles in the community, with a nice helping of public acclaim to go with it. I am not arguing for "making exceptions for friends" here; rather that the acknowledged issues with inclusiveness / espansion of the developer community require making changes to the rules to encourage more participation. BTW, language like "prov[ing] their motivation" is itself demotivating, and likely contributes to the status quo ante. With my PSF hat on I'd like to support Tres here (and, by extension, Sean's proposal). Lowering the barriers of entry is a desirable goal. If adding people created work for already-busy developers then I'd be against it*, but with Sean offering to mentor his new protege and ensure that he limits his role to triage initially that doesn't seem to be an issue. Maybe it's time to review the way people "prove their motivation and the quality of their work"? 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? 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 the owner of new tickets to someone who might actually fix it, things that would happen automatically if roundup had the right information), and then anyone who steps up gets the necessary access. Jean-Paul regards Steve * I'd be against it, but I'd fight to change the development process so that adding new people *didn't* create work. We should, in my opinion, be looking for a continual influx of new worker bees. -- Steve Holden +1 571 484 6266 +1 800 494 3119 ___ 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.
Tres Seaver writes: > I think there is a definite "unpriced externality" to keeping the > process barriers high here. The proposed trial period is not a high barrier, except to those who really didn't want to being doing the work anyway. Note that There is also an externality to having accounts with unused privileges lying around the server. The fact is that there just aren't very many people willing to do the work. I've considered doing it (especially since Daniel has gone out of his way to inform me of fixes to the Python tracker, since I maintain a couple of Roundup instances for other projects), but I just don't have the time. Both personally and in general, I really don't think this barrier is high enough that removal would make a significant difference. The example of Daniel Diniz *is* salient. A couple of weeks of doing things the long way (which forces the mentor to look at them, among other things), a week for discussion by the people who work most closely with the candidate and the administrators of the host/tracker where privileges will be granted -- if this matters in the grand scheme of things, the person probably didn't want to be doing the work in the first place. They should find a way to contribute more suited to their capabilities and interests. > I am not arguing for "making exceptions for friends" here; rather that > the acknowledged issues with inclusiveness / espansion of the developer > community require making changes to the rules to encourage more > participation. > > BTW, language like "prov[ing] their motivation" is itself demotivating, > and likely contributes to the status quo ante. Unlikely IMHO. Yes, if you allow anybody to make changes, you'll get more contributions. You'll also create a lot of janitorial work for the people who take care of project hygiene, and *they* will lose incentive. That is a *really* big risk. Remember, because of the sexiness/mission criticality of the Linux kernel, a couple of *hundred* people world wide get paid to spend significant amounts of time on it. That's not the comparison to make here; Python is a great language, but there are several reasonable alternatives, and it's not suited to all projects. Look at the 99.5% of Sourceforge projects (or the fact that GNU Savannah can't attract contributions to get the "official" GNU VCS -- Bazaar -- working properly), and you'll see that Python actually has a really well- functioning, attractive process. ___ 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.
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. 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. Giving people rights to a bugtracker or versioning system is not dangerous, and should not be hard. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.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 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 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
