Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
Am 26.04.2010 15:34, schrieb Lennart Regebro: 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. :) Reviewing the checkins is not work, then? Georg ___ 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, Apr 27, 2010 at 09:18, Georg Brandl g.bra...@gmx.net wrote: Am 26.04.2010 15:34, schrieb Lennart Regebro: 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. :) Reviewing the checkins is not work, then? Well, yes, so OK, not half. But quite a lot of the checkins need to be bad for the amount of work the established commiters need to do per bug fixed to increase when you add a newbie. Yes, maybe the workload in total increases in the beginning, but that's because the newbie is actually fixing bugs, and as Stephen mentions, it's often itches no one else (read the established committers) cares about, because they didn't encounter that particular issue. I have a problem seeing that as a bad thing. -- 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] what to do if you don't want your module in Debian
On Tue, Apr 27, 2010 at 1:24 AM, Toshio Kuratomi a.bad...@gmail.com wrote: On Mon, Apr 26, 2010 at 05:46:55PM -0400, Barry Warsaw wrote: On Apr 26, 2010, at 09:39 PM, Tarek Ziadé wrote: You should be permissive on that one. Until we know how to describe resource files properly, __file__ is what developer use when they need their projects to be portable.. Until then, isn't pkg_resources the best practice for this? (I'm pretty sure we've talked about this before.) I would have to say no to this. Best practice from the Linux packager POV would be something like this foo/ foo/__init__.py foo/paths.py:: # Global paths where resources are installed HELPDIR='/usr/share/foo/help' TEMPLATEDIR='/usr/share/foo/templates' CACHEDIR='/var/cache/foo' DBDIR='/var/lib/foo/db' PRIVATEMODDIR='/usr/share/foo/foolib' PLUGINDIR='/usr/lib/foo/plugins' LOCALEDIR='/usr/share/locale' foo/do_things.py:: import foo.paths import os.path # connect to the db db = foo_connect(os.path.join(foo.paths.DBDIR, 'foodb.sqlite')) Using this strategy, you, the developer, can set the default paths to whatever makes the most sense for your target but the packager can go through and patch new locations in a single file that are used throughout your program. You are making the assumption that the developers know what are the global paths on each platform. I don't think people would do that unless we provide these paths already, and that's basically the goal of the next PEP. Maybe a step toward this goal would be to provide a document that explains the role of each path, for each platform from the *python developer POV* Until then, the only approach a developer has to make sure he can access to his resource files, is to have them alongside the code. 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] what to do if you don't want your module in Debian
On Tue, Apr 27, 2010 at 2:43 AM, David Cournapeau courn...@gmail.com wrote:
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,
That resembles a lot to what we want to achieve in the next PEP:
at installation time, a file that contains all the prefix will be generated,
combined with a global list of variables found in Python.
Then, instead of importing these values (in our plans, the variables
are statically defined), developers will do:
pkgutil.open('MANPATH', 'foo'), where foo.txt is a file under
/somefunkypath in your example
Since you are building your own tool, it would be great to have you
working with us in the upcoming PEP,
since it aims to provide an interoperability ground to install and
consume resource files.
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.
On Mon, 26 Apr 2010 14:15:01 -0400, Steve Holden st...@holdenweb.com wrote: 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? The people who are potential new contributors but don't currently know anyone in the Python community. (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. This discussion has never been about dangerjim's qualifications, as far as I can tell. I believe we all fully expect him to be a valuable contributor within a very short time, because Sean is recommending him, and we welcome him to the community, The discussion, in my view, is about the process in general, and how to make sure that it continues to promote good, inclusive community, by holding everyone to the same standards. (And the discussion, then, is should we change the current standard.) (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. I have not read any of the comments as unwelcoming (although I could be misremembering), so I'm not sure why you heard that. We are talking about process and what works best for community building (which includes increasing the number of people in the developer community). And I at least am in the mode of *discussing* it, not speaking from a position set in stone...if the consensus that develops is that the familiarization period can be skipped in certain cases, I'm not going to block that consensus or get mad about it...but I don't think we have a developing consensus right now, and I'm not sure how to move forward on that. For the record, note that both Antoine and I have been instrumental in bringing more than one new person into both the triage and the committer ranks. We (along with others) *are* the ones doing the welcoming and the mentoring and the growing of the developer community. -- R. David Murray www.bitdance.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
[Python-Dev] spam on b.p.o
Terry Reedy tjreedy at udel.edu writes: 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. Speaking of which, what is the procedure to delete a spam message and remove a spamming user? We have an example here: http://bugs.python.org/user12283 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.
R. David Murray wrote: On Mon, 26 Apr 2010 14:15:01 -0400, Steve Holden st...@holdenweb.com wrote: [...] For the record, note that both Antoine and I have been instrumental in bringing more than one new person into both the triage and the committer ranks. We (along with others) *are* the ones doing the welcoming and the mentoring and the growing of the developer community. For which work I am truly grateful, as I am sure are many others. Please forgive any prickliness I may have evinced in this conversation. It *is* important to make people feel welcome, and I am happy to see the development community growing. As regards the procedural discussions, while I may have my opinions it's clearly best if the procedures are maintained by those operating them. I am usually fine with that happening, and this is no exception. 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] spam on b.p.o
Antoine Pitrou solipsis at pitrou.net writes: Speaking of which, what is the procedure to delete a spam message and remove a spamming user? Well, for some reason I hadn't seen the remove button message... As for deleting the user, I suppose an admin can do it. 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] Assigned To field usage (was: Enhanced tracker privileges)
On Mon, 26 Apr 2010 14:23:00 -0400, Terry Reedy tjre...@udel.edu wrote: On 4/26/2010 2:12 AM, Sean Reifschneider wrote: 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? Well, in my recent experience there are two things the assignee gets used for. The first is someone claiming an issue, saying, in effect, I'm going to work this issue until it is closed. The other is to do exactly what Sean did, assign it to the next person whose decision or input is needed in order to move the issue forward. However, as you say, I think the latter is done generally when the issue *can't* move forward without that person's input (or at least not without giving them a significant opportunity to provide input). Usually this is done by the person who previously had the issue assigned to them. My perception is that making someone nosy on an issue is preferred to assigning it to them (allowing them to assign it to themselves if they think that is appropriate), unless the issue is of higher priority or someone actively working on the issue really needs the other person's input in order to move forward. But these are my own rules of thumb, and a discussion of how best to use this field may be appropriate. -- R. David Murray www.bitdance.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] Make 'normal' the default tracker priority level
On Mon, 26 Apr 2010 22:39:39 +0200, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= 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. +1 This will make the default grouping more useful, since now critical issues will appear at the top, instead of several pages in! -- R. David Murray www.bitdance.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.
R. David Murray wrote: And I at least am in the mode of *discussing* it, not speaking from a position set in stone...if the consensus that develops is that the familiarization period can be skipped in certain cases, I'm not going to block that consensus or get mad about it...but I don't think we have a developing consensus right now, and I'm not sure how to move forward on that. Having a recommendation officially mean accelerating-but-not-skipping the familiarisation period doesn't seem to have met with any significant objections. We basically do that anyway, this would just mean adding a note about it to the getting involved documentation. 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] Anyone can do patch reviews (was: Enhanced tracker privileges...)
On Tue, 27 Apr 2010 11:15:49 +1000, Steven D'Aprano st...@pearwood.info wrote: 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? It is very very helpful for *anyone* to review patches. Let's see if I can clarify the process a little. (This is, of course, my take on it, others can chime in if they think I got anything wrong.) Someone submits a bug. Someone submits a patch to fix that bug (or add the enhancement). Is that patch ready for commit? No. Is it ready for *commit review* (ie: someone with commit privileges to look at it with an eye toward committing it)? Probably not. What makes a patch ready for commit review? The patch should: 1) conform to pep 7/8 2) have unit tests that fail before the patch and succeed after 3) have documentation updates if needed 4) have a py3k port *if and only if* the port is non-trivial (well, if someone wants to add one when it is trivial that's OK, but it probably won't get used) 5) if it is at all likely to have system dependencies, be tested on at least linux and windows Making sure that these items are true does not require any in-depth expertise. In many cases it doesn't even require much time. 'Trusted' or 'untrusted' doesn't really come in to it, though doing these sorts of reviews will build trust. If you can in addition look at the patch content and critique it, so much the better. Again, *any* critique is useful, even if you can't review the whole patch in detail, because it gets it that much closer to being commit ready. And there are enough uncommitted patches in the tracker that it ought to be possible for almost anyone to find something they can usefully do a content critique on. The goal is to make the commit review step as simple and fast for the committer as possible. The more eyes on the patch before hand, the faster the commit review will be. And those people who do a good job making patches commit ready will be on the fast track to getting commit privileges. -- R. David Murray www.bitdance.com PS: note that I'm using 'commit review' above with a different sense than that value is currently defined to have in the workflow. I'm thinking about advocating that the definition in the workflow be changed, and indeed we (the informal triage crew) have already occasionally used that setting with the meaning I give it above. ___ 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] Assigned To field usage
R. David Murray wrote: Well, in my recent experience there are two things the assignee gets used for. The first is someone claiming an issue, saying, in effect, I'm going to work this issue until it is closed. The other is to do exactly what Sean did, assign it to the next person whose decision or input is needed in order to move the issue forward. However, as you say, I think the latter is done generally when the issue *can't* move forward without that person's input (or at least not without giving them a significant opportunity to provide input). Usually this is done by the person who previously had the issue assigned to them. My perception is that making someone nosy on an issue is preferred to assigning it to them (allowing them to assign it to themselves if they think that is appropriate), unless the issue is of higher priority or someone actively working on the issue really needs the other person's input in order to move forward. But these are my own rules of thumb, and a discussion of how best to use this field may be appropriate. That sounds like a fair description of the way I use it as well. The most common case where I will assign a bug directly to someone is if I want a yea or nay from the release manager in deciding whether or not something is acceptable for inclusion in a beta or rc release. 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 Tue, 27 Apr 2010 23:34:48 +1000, Nick Coghlan ncogh...@gmail.com wrote: R. David Murray wrote: And I at least am in the mode of *discussing* it, not speaking from a position set in stone...if the consensus that develops is that the familiarization period can be skipped in certain cases, I'm not going to block that consensus or get mad about it...but I don't think we have a developing consensus right now, and I'm not sure how to move forward on that. Having a recommendation officially mean accelerating-but-not-skipping the familiarisation period doesn't seem to have met with any significant objections. We basically do that anyway, this would just mean adding a note about it to the getting involved documentation. Sounds good to me. -- R. David Murray www.bitdance.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
[Python-Dev] bug tracker permissions request
May I have enhanced permissions on the bug tracker, so that I can perform the following tasks? - Assign issues to myself that I plan to write a patch for - Update the Stage to patch review after writing a patch - Occasional bug triage My login name on the tracker is stutzbach. I only find the time to produce patches once in awhile, but when I have the time I usually produce more than one. Assigning bugs to myself will increase my motivation to write patches, as I will feel that I've made a commitment to fixing them. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC http://stutzbachenterprises.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] what to do if you don't want your module in Debian
On Tue, Apr 27, 2010 at 09:41:02AM +0200, Tarek Ziadé wrote:
On Tue, Apr 27, 2010 at 1:24 AM, Toshio Kuratomi a.bad...@gmail.com wrote:
On Mon, Apr 26, 2010 at 05:46:55PM -0400, Barry Warsaw wrote:
On Apr 26, 2010, at 09:39 PM, Tarek Ziadé wrote:
You should be permissive on that one. Until we know how to describe
resource
files properly, __file__ is what developer use when they need their
projects
to be portable..
Until then, isn't pkg_resources the best practice for this? (I'm pretty
sure
we've talked about this before.)
I would have to say no to this. Best practice from the Linux packager POV
would be something like this
foo/
foo/__init__.py
foo/paths.py::
# Global paths where resources are installed
HELPDIR='/usr/share/foo/help'
TEMPLATEDIR='/usr/share/foo/templates'
CACHEDIR='/var/cache/foo'
DBDIR='/var/lib/foo/db'
PRIVATEMODDIR='/usr/share/foo/foolib'
PLUGINDIR='/usr/lib/foo/plugins'
LOCALEDIR='/usr/share/locale'
foo/do_things.py::
import foo.paths
import os.path
# connect to the db
db = foo_connect(os.path.join(foo.paths.DBDIR, 'foodb.sqlite'))
Using this strategy, you, the developer, can set the default paths to
whatever makes the most sense for your target but the packager can go
through and patch new locations in a single file that are used throughout
your program.
You are making the assumption that the developers know what are the
global paths on each platform.
No, I'm not. The developer needs to establish sane categories, but doesn't
need to worry about the exact paths. For instance, this would be perfectly
fine:
foo/path.py::
HELPDIR=os.path.join(os.dirname(__file__), 'help')
TEMPLATEDIR=pkg_resources.resource_filename('foo', 'templates')
CACHEDIR=os.path.join(os.environ.get('HOME', '/tmp'), 'foocache')
Then the individual platform packagers can patch the single file, paths.py
according to the neecds oftheir platform.
I don't think people would do that unless we
provide these paths already, and that's basically the goal of the next PEP.
s/paths/categories/ and I'll agree. As I said, the PEP does a lot of
things right in this area. We're able to push decisions about filesystem
paths out to a higher level using the PEP whereas the current state of the
art has us needing to figure it all out as individual developers :-(
[...]
Until then, the only approach a developer has to make sure he can access to
his
resource files, is to have them alongside the code.
I don't think so -- but this scheme certainly allows that. I think that
many developers who are targeting Linux will find it more natural to specify
FHS compliant paths for their files. Someone who is developing an app to be
portable will likely find that placing files alongside code is more natural
(although even this isn't truly portable -- CACHEDIR and other stateful
files will break under the assumption that you can write to a file/directory
alongside the module).
And like I say, this is just about the best workaround available now.
Implementation of the PEP makes this area much better.
-Toshio
pgpKhyjpUdu25.pgp
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] Anyone can do patch reviews (was: Enhanced tracker privileges...)
On 01:38 pm, rdmur...@bitdance.com wrote: On Tue, 27 Apr 2010 11:15:49 +1000, Steven D'Aprano st...@pearwood.info wrote: 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? It is very very helpful for *anyone* to review patches. Let's see if I can clarify the process a little. (This is, of course, my take on it, others can chime in if they think I got anything wrong.) Someone submits a bug. Someone submits a patch to fix that bug (or add the enhancement). Is that patch ready for commit? No. Is it ready for *commit review* (ie: someone with commit privileges to look at it with an eye toward committing it)? Probably not. What makes a patch ready for commit review? The patch should: 1) conform to pep 7/8 2) have unit tests that fail before the patch and succeed after 3) have documentation updates if needed 4) have a py3k port *if and only if* the port is non-trivial (well, if someone wants to add one when it is trivial that's OK, but it probably won't get used) 5) if it is at all likely to have system dependencies, be tested on at least linux and windows This list would make a good addition to one of the cpython development pages. If potential contributors could find this information, then they'd be much more likely to participate by doing reviews. 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] bug tracker permissions request
On Tue, Apr 27, 2010 at 09:22, Daniel Stutzbach dan...@stutzbachenterprises.com wrote: May I have enhanced permissions on the bug tracker, so that I can perform the following tasks? - Assign issues to myself that I plan to write a patch for - Update the Stage to patch review after writing a patch - Occasional bug triage My login name on the tracker is stutzbach. I only find the time to produce patches once in awhile, but when I have the time I usually produce more than one. Assigning bugs to myself will increase my motivation to write patches, as I will feel that I've made a commitment to fixing them. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC http://stutzbachenterprises.com +1 from me. Daniel has had good input on many issues, has written quality patches, and if this would help him do more, I'm for 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] bug tracker permissions request
On Tue, 27 Apr 2010 09:22:07 -0500, Daniel Stutzbach dan...@stutzbachenterprises.com wrote: May I have enhanced permissions on the bug tracker, so that I can perform the following tasks? Done. I agree with Brian, Daniel has been making valuable contributions for quite some time now. I/we will keep an eye on his triage, of course. -- R. David Murray www.bitdance.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] Anyone can do patch reviews (was: Enhanced tracker privileges...)
On Apr 27, 2010, at 02:40 PM, exar...@twistedmatrix.com wrote:
On 01:38 pm, rdmur...@bitdance.com wrote:
2) have unit tests that fail before the patch and succeed after
This list would make a good addition to one of the cpython development
pages. If potential contributors could find this information, then
they'd be much more likely to participate by doing reviews.
It would be kind of cool if there were some best practices for running said
unittest both with and without the patch enabled. Kind of like using #ifdefs
in C but without all the commenting-out-commenting-in error proneness. I
guess you could do something like
if os.getenv('BUG1234'):
# Patch the frobnicator to not bloviate.
Maybe more trouble than it's worth, and not always feasible of course, but I'm
wondering how (or maybe if) people do things this way.
With Bazaar, I often use a loom with two threads - a bottom one that contains
the test that fails, and a top one that contains the fix for the test. It's a
great way to develop a patch, but you lose that once you flatten the code for
review.
-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] bug tracker permissions request
On Tue, Apr 27, 2010 at 10:14 AM, R. David Murray rdmur...@bitdance.comwrote: Done. I agree with Brian, Daniel has been making valuable contributions for quite some time now. I/we will keep an eye on his triage, of course. Thanks. Is there a document that describes the meaning of all of the different fields in the bug tracker? I've read http://www.python.org/dev/workflow/, but it doesn't cover everything. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC http://stutzbachenterprises.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] Anyone can do patch reviews (was: Enhanced tracker privileges...)
On Tue, 27 Apr 2010 11:16:51 -0400, Barry Warsaw ba...@python.org wrote:
It would be kind of cool if there were some best practices for running said
unittest both with and without the patch enabled. Kind of like using #ifdefs
in C but without all the commenting-out-commenting-in error proneness. I
guess you could do something like
if os.getenv('BUG1234'):
# Patch the frobnicator to not bloviate.
Maybe more trouble than it's worth, and not always feasible of course, but I'm
wondering how (or maybe if) people do things this way.
With Bazaar, I often use a loom with two threads - a bottom one that contains
the test that fails, and a top one that contains the fix for the test. It's a
great way to develop a patch, but you lose that once you flatten the code for
review.
Well, the way I do it for review is brute force: I download the patch,
delete everything except the unit test, apply that, run it, revert,
apply the original patch, run it.
For developing, I generally write the unit test first grin, but when
the fix is confined to one file I can just revert the file for testing
the tests while keeping the fixed copy in my edit buffer (or a save file
if I'm feeling paranoid, like when it is a substantial fix). For more
complex fixes I generate separate patch files for the tests and the fix
as a whole, and do a revert-patch-revert-patch dance to test things.
I wonder if it would be better to encourage people to post the unit
tests and the fix as separate patch files.
--
R. David Murray www.bitdance.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] Anyone can do patch reviews (was: Enhanced tracker privileges...)
On Tue, Apr 27, 2010 at 5:16 PM, Barry Warsaw ba...@python.org wrote:
On Apr 27, 2010, at 02:40 PM, exar...@twistedmatrix.com wrote:
On 01:38 pm, rdmur...@bitdance.com wrote:
2) have unit tests that fail before the patch and succeed after
This list would make a good addition to one of the cpython development
pages. If potential contributors could find this information, then
they'd be much more likely to participate by doing reviews.
It would be kind of cool if there were some best practices for running said
unittest both with and without the patch enabled. Kind of like using
#ifdefs
in C but without all the commenting-out-commenting-in error proneness. I
guess you could do something like
if os.getenv('BUG1234'):
# Patch the frobnicator to not bloviate.
When I'm writing the patch it's usually easy, I write the tests, see that
they fail, write the fix, see that they pass.
When I'm reviewing the patch, I apply the patch, see that the tests pass,
svn revert the fix, check that they fail.
Most of the patches affect just a couple of files, so applying the whole
patch and then revert is usually trivial and probably easier than having to
deal with two separate files for patch and tests.
___
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] bug tracker permissions request
On Tue, 27 Apr 2010 10:34:16 -0500, Daniel Stutzbach dan...@stutzbachenterprises.com wrote: Thanks. Is there a document that describes the meaning of all of the different fields in the bug tracker? I've read http://www.python.org/dev/workflow/, but it doesn't cover everything. I think it is on Brett's list to update that doc, but maybe we should help him out :). Can you list what's missing? We should fill in the gaps. -- R. David Murray www.bitdance.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
[Python-Dev] Two small PEP ideas
I have two somewhat unrelated thoughts about PEPs. * Accepted: header When PEP 3147 was accepted, I had a few folks ask that this be recorded in the PEP by including a link to the BDFL pronouncement email. I realized that there's no formal way to express this in a PEP, and many PEPs in fact don't record more than the fact that it was accepted. I'd like to propose officially adding an Accepted: header which should include a URL to the email or other web resource where the PEP is accepted. I've come as close as possible to this (without modifying the supporting scripts or PEP 1) in PEP 3147: http://www.python.org/dev/peps/pep-3147/ I'd be willing to update things if there are no objections. * EOL schedule for older releases. We have semi-formal policies for the lifetimes of Python releases, though I'm not sure this policy is written down in any of the existing informational PEPs. However, we have release schedule PEPs going back to Python 1.6. It seems reasonable to me that we include end-of-life information in those PEPs. For example, we could state that Python 2.4 is no longer even being maintained for security, and we could state the projected date that Python 2.6 will go into security-only maintenance mode. I would not mandate that we go back and update all previous PEPs for either of these ideas. We'd adopt them moving forward and allow anyone who's motivated to backfill information opportunistically. Thoughts? -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] bug tracker permissions request
On Tue, Apr 27, 2010 at 11:16 AM, R. David Murray rdmur...@bitdance.comwrote: I think it is on Brett's list to update that doc, but maybe we should help him out :). Can you list what's missing? We should fill in the gaps. Sure, here's what I've noticed: The page doesn't document the Resolution or Status fields. For the Keywords field, the page only documents the easy keyword. Also, some of the headings in the page are enclosed in square brackets, while others are not. It's not clear to me what the brackets are intended to designate. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC http://stutzbachenterprises.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] Anyone can do patch reviews (was: Enhanced tracker privileges...)
On Apr 27, 2010, at 11:43 AM, R. David Murray wrote: I wonder if it would be better to encourage people to post the unit tests and the fix as separate patch files. I think this is not bad idea for larger fixes, where it's not trivial to manually edit the diff. -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] Two small PEP ideas
Sounds good to me (from my phone on my way to WWW2010). On Apr 27, 2010 10:49 AM, Barry Warsaw ba...@python.org wrote: I have two somewhat unrelated thoughts about PEPs. * Accepted: header When PEP 3147 was accepted, I had a few folks ask that this be recorded in the PEP by including a link to the BDFL pronouncement email. I realized that there's no formal way to express this in a PEP, and many PEPs in fact don't record more than the fact that it was accepted. I'd like to propose officially adding an Accepted: header which should include a URL to the email or other web resource where the PEP is accepted. I've come as close as possible to this (without modifying the supporting scripts or PEP 1) in PEP 3147: http://www.python.org/dev/peps/pep-3147/ I'd be willing to update things if there are no objections. * EOL schedule for older releases. We have semi-formal policies for the lifetimes of Python releases, though I'm not sure this policy is written down in any of the existing informational PEPs. However, we have release schedule PEPs going back to Python 1.6. It seems reasonable to me that we include end-of-life information in those PEPs. For example, we could state that Python 2.4 is no longer even being maintained for security, and we could state the projected date that Python 2.6 will go into security-only maintenance mode. I would not mandate that we go back and update all previous PEPs for either of these ideas. We'd adopt them moving forward and allow anyone who's motivated to backfill information opportunistically. Thoughts? -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/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] Anyone can do patch reviews
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 R. David Murray wrote: On Tue, 27 Apr 2010 11:15:49 +1000, Steven D'Aprano st...@pearwood.info wrote: 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? It is very very helpful for *anyone* to review patches. Let's see if I can clarify the process a little. (This is, of course, my take on it, others can chime in if they think I got anything wrong.) Someone submits a bug. Someone submits a patch to fix that bug (or add the enhancement). Is that patch ready for commit? No. Is it ready for *commit review* (ie: someone with commit privileges to look at it with an eye toward committing it)? Probably not. What makes a patch ready for commit review? The patch should: 1) conform to pep 7/8 2) have unit tests that fail before the patch and succeed after 3) have documentation updates if needed 4) have a py3k port *if and only if* the port is non-trivial (well, if someone wants to add one when it is trivial that's OK, but it probably won't get used) 5) if it is at all likely to have system dependencies, be tested on at least linux and windows This is an excellent set of guidelines. The only drawback I see here is that the current VCS situation makes doing the review more tedious than it should be, especially for non-committers. Or maybe the Hg mirrors are truly up-to-date and working? Last I looked, they were lagging or unavailable. Making sure that these items are true does not require any in-depth expertise. In many cases it doesn't even require much time. 'Trusted' or 'untrusted' doesn't really come in to it, though doing these sorts of reviews will build trust. If you can in addition look at the patch content and critique it, so much the better. Again, *any* critique is useful, even if you can't review the whole patch in detail, because it gets it that much closer to being commit ready. And there are enough uncommitted patches in the tracker that it ought to be possible for almost anyone to find something they can usefully do a content critique on. The goal is to make the commit review step as simple and fast for the committer as possible. The more eyes on the patch before hand, the faster the commit review will be. And those people who do a good job making patches commit ready will be on the fast track to getting commit privileges. -- R. David Murray www.bitdance.com PS: note that I'm using 'commit review' above with a different sense than that value is currently defined to have in the workflow. I'm thinking about advocating that the definition in the workflow be changed, and indeed we (the informal triage crew) have already occasionally used that setting with the meaning I give it above. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvXLtkACgkQ+gerLs4ltQ79DACbB35/XFGyiYjd79OtTx+kgoNl mcsAnA4TNlM1ARjyrDrQIwv4KG48w/7h =1hGI -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] Anyone can do patch reviews
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
On Apr 27, 2010, at 02:40 PM, exar...@twistedmatrix.com wrote:
On 01:38 pm, rdmur...@bitdance.com wrote:
2) have unit tests that fail before the patch and succeed after
This list would make a good addition to one of the cpython development
pages. If potential contributors could find this information, then
they'd be much more likely to participate by doing reviews.
It would be kind of cool if there were some best practices for running said
unittest both with and without the patch enabled. Kind of like using #ifdefs
in C but without all the commenting-out-commenting-in error proneness. I
guess you could do something like
if os.getenv('BUG1234'):
# Patch the frobnicator to not bloviate.
Maybe more trouble than it's worth, and not always feasible of course, but I'm
wondering how (or maybe if) people do things this way.
With Bazaar, I often use a loom with two threads - a bottom one that contains
the test that fails, and a top one that contains the fix for the test. It's a
great way to develop a patch, but you lose that once you flatten the code for
review.
You can always shelve the part of the patch which isn't the test: I
do that pretty frequently in the Zope tree, where I am now doing most
development with bzr.
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkvXLuMACgkQ+gerLs4ltQ5HBQCgw7kqJ52kPz+0cwNSpyVUkCFA
yQUAoLHJiYi+59Cc7BCeL46hA+Wygo66
=93vQ
-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] Anyone can do patch reviews
Tres Seaver tseaver at palladion.com writes: This is an excellent set of guidelines. The only drawback I see here is that the current VCS situation makes doing the review more tedious than it should be, especially for non-committers. Or maybe the Hg mirrors are truly up-to-date and working? Last I looked, they were lagging or unavailable. If you only a review a patch (rather than say maintain and evolve it), there's no point in using hg rather than SVN. However, the mirrors are most of the time alive and up-to-date (sync period is around 5 minutes): http://code.python.org/hg (perhaps you're thinking about http://hg.python.org/, which is an experimental conversion of the SVN repo, not really meant for daily use) 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] Two small PEP ideas
On Tue, Apr 27, 2010 at 10:46 AM, Barry Warsaw ba...@python.org wrote: I have two somewhat unrelated thoughts about PEPs. * Accepted: header When PEP 3147 was accepted, I had a few folks ask that this be recorded in the PEP by including a link to the BDFL pronouncement email. I realized that there's no formal way to express this in a PEP, and many PEPs in fact don't record more than the fact that it was accepted. I'd like to propose officially adding an Accepted: header which should include a URL to the email or other web resource where the PEP is accepted. I've come as close as possible to this (without modifying the supporting scripts or PEP 1) in PEP 3147: http://www.python.org/dev/peps/pep-3147/ I'd be willing to update things if there are no objections. I'd rather not build a single point of failure into the process. Instead of insisting on BDFL pronouncement, the community should switch do something like last call for objections. There should also be a timeline so that unproductive discussion can't be dragged on forever. * EOL schedule for older releases. We have semi-formal policies for the lifetimes of Python releases, though I'm not sure this policy is written down in any of the existing informational PEPs. However, we have release schedule PEPs going back to Python 1.6. It seems reasonable to me that we include end-of-life information in those PEPs. For example, we could state that Python 2.4 is no longer even being maintained for security, and we could state the projected date that Python 2.6 will go into security-only maintenance mode. I would not mandate that we go back and update all previous PEPs for either of these ideas. We'd adopt them moving forward and allow anyone who's motivated to backfill information opportunistically. SGTM. -- --Guido van Rossum (python.org/~guido) ___ 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] Anyone can do patch reviews
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Antoine Pitrou wrote: Tres Seaver tseaver at palladion.com writes: This is an excellent set of guidelines. The only drawback I see here is that the current VCS situation makes doing the review more tedious than it should be, especially for non-committers. Or maybe the Hg mirrors are truly up-to-date and working? Last I looked, they were lagging or unavailable. If you only a review a patch (rather than say maintain and evolve it), there's no point in using hg rather than SVN. Hmm, it feels exactly the other way around to me: working with the DVCS tools while reviewiing a patch allows me to be more productive (e.g., using 'bzr shelve' or the equivalent hg subcommand). Making a local branch / clone for each issue also feels more natural than working in a read-only SVN checkout. However, the mirrors are most of the time alive and up-to-date (sync period is around 5 minutes): http://code.python.org/hg That was the URL I was trying to work with: it has been a couple of months since I last tried, however. (perhaps you're thinking about http://hg.python.org/, which is an experimental conversion of the SVN repo, not really meant for daily use) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvXOacACgkQ+gerLs4ltQ6ZTwCfQ96RYQ6h/zdMOnFUJU3MkSC1 +o8An2CqK7fbpiCM3gBWZuRReG46xv+U =iWug -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] Anyone can do patch reviews
On Tue, Apr 27, 2010 at 03:23:19PM -0400, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Antoine Pitrou wrote: Tres Seaver tseaver at palladion.com writes: This is an excellent set of guidelines. The only drawback I see here is that the current VCS situation makes doing the review more tedious than it should be, especially for non-committers. Or maybe the Hg mirrors are truly up-to-date and working? Last I looked, they were lagging or unavailable. If you only a review a patch (rather than say maintain and evolve it), there's no point in using hg rather than SVN. Hmm, it feels exactly the other way around to me: working with the DVCS tools while reviewiing a patch allows me to be more productive (e.g., using 'bzr shelve' or the equivalent hg subcommand). Making a local branch / clone for each issue also feels more natural than working in a read-only SVN checkout. +1. I find it to be an excellent way to muck around with patches and make my own changes / diffs / etc. for a review process. (Not that I do any Python reviews, note. But it's a great technique in general.) It's also fantastically simple and esay to interact with patches that are branches on someone's bitbucket or github repo; much better than uploading and downloading patch files while in the middle of a discussion. cheers, --titus -- C. Titus Brown, c...@msu.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] Anyone can do patch reviews
On Apr 27, 2010, at 02:37 PM, Tres Seaver wrote: You can always shelve the part of the patch which isn't the test: I do that pretty frequently in the Zope tree, where I am now doing most development with bzr. Yes definitely. bzr-loom just makes that much easier to manage. -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] Make 'normal' the default tracker priority level
R. David Murray wrote: On Mon, 26 Apr 2010 22:39:39 +0200, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= 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. +1 This will make the default grouping more useful, since now critical issues will appear at the top, instead of several pages in! Done! 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
On Tue, Apr 27, 2010 at 4:38 PM, Martin v. Löwis mar...@v.loewis.de wrote: Done! Thanks, Martin! -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry 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] spam on b.p.o
Antoine Pitrou wrote: Antoine Pitrou solipsis at pitrou.net writes: Speaking of which, what is the procedure to delete a spam message and remove a spamming user? Well, for some reason I hadn't seen the remove button message... As for deleting the user, I suppose an admin can do it. For true spam (off-topic links, porn, advertisements, etc), please don't remove. Instead, people in the Coordinator role also have a mark as spam button, which causes SpamBayes training of the message, and also makes the message unreadable for anonymous users (including search engines). People posting spam for SEO thus get truly blocked. A mere remove will just detach the message - the message URL in itself remains accessible. In the specific case (msg104314), remove was probably the right thing, since it isn't real spam, but just non-sensical. I don't think the user needs to be banned from the tracker. 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] Assigned To field usage
My perception is that making someone nosy on an issue is preferred to assigning it to them (allowing them to assign it to themselves if they think that is appropriate), unless the issue is of higher priority or someone actively working on the issue really needs the other person's input in order to move forward. But these are my own rules of thumb, and a discussion of how best to use this field may be appropriate. I personally think issues should not get assigned unless the person it is being assigned to is known to accept such assignments, e.g. by having asked for them to happen. For example, I would prefer not to be assigned any issues, because I'm unlikely to act on them in the six months - unless, as David says, I'm the *only* person who could move the issue forward in that time. 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] Anyone can do patch reviews
Hmm, it feels exactly the other way around to me: working with the DVCS tools while reviewiing a patch allows me to be more productive (e.g., using 'bzr shelve' or the equivalent hg subcommand). Just try using Subversion for some time again, and you'll see that it is not difficult at all. Start with a clean sandbox, then apply the patch. If you want to go back to the state without patch, revert the sandbox, if you need it again, apply it again. It's really simple. 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] bug tracker permissions request
The page doesn't document the Resolution or Status fields. The resolutions are the same as the ones on SourceForge. You only have resolutions on closed issues, and they explain why an issue was closed. If any specific one is unclear in that context, please be more specific. On the status, I hope open/closed are clear, and these are the ones you should be using. Pending is meant as auto-close in two weeks unless there is follow-up, and its unimplemented. For languishing, click on the label Status left of the field. For the Keywords field, the page only documents the easy keyword. So which ones you don't understand? Also, some of the headings in the page are enclosed in square brackets, while others are not. It's not clear to me what the brackets are intended to designate. Not sure what this is referring to - I don't see any square brackets. 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] spam on b.p.o
Martin v. Löwis martin at v.loewis.de writes: In the specific case (msg104314), remove was probably the right thing, since it isn't real spam, but just non-sensical. I don't think the user needs to be banned from the tracker. The message was a copy of a previous message by someone else, with an additional HTML link in the middle. The target of that link was clearly the kind that would pay to increase its Google rank through whatever means (bogus diploma stuff, IIRC). 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] Anyone can do patch reviews
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin v. Löwis wrote: Hmm, it feels exactly the other way around to me: working with the DVCS tools while reviewiing a patch allows me to be more productive (e.g., using 'bzr shelve' or the equivalent hg subcommand). Just try using Subversion for some time again, and you'll see that it is not difficult at all. Start with a clean sandbox, then apply the patch. If you want to go back to the state without patch, revert the sandbox, if you need it again, apply it again. It's really simple. I use Subversion daily as a committer on multiple projects. Keeping multiple readon-only checkouts around to evaluate patches is much clunkier than maintaining DVCS branches for the same purpose. As a non-committer, what I would miss most is the ability to make local commits. Features like shelve, log -p, etc., are aslo extremely useful when analyzing a patch. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvXVV8ACgkQ+gerLs4ltQ7JqwCfVZPkm8/3XUuuzpm/N+08x2RI KWYAn004cLJS3poYZ/4BvSFOGzMpwNuC =j3lH -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] spam on b.p.o
The message was a copy of a previous message by someone else, with an additional HTML link in the middle. The target of that link was clearly the kind that would pay to increase its Google rank through whatever means (bogus diploma stuff, IIRC). Ah, I missed that. I've marked it as spam now. 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] Anyone can do patch reviews
Ezio Melotti wrote: When I'm writing the patch it's usually easy, I write the tests, see that they fail, write the fix, see that they pass. When I'm reviewing the patch, I apply the patch, see that the tests pass, svn revert the fix, check that they fail. Most of the patches affect just a couple of files, so applying the whole patch and then revert is usually trivial and probably easier than having to deal with two separate files for patch and tests. This would be pretty close to my typical workflow as well (*looks at list of assigned bugs that hasn't moved in weeks* well, it is the workflow when I actually *do* some Python coding...) 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] Two small PEP ideas
Guido van Rossum wrote: When PEP 3147 was accepted, I had a few folks ask that this be recorded in the PEP by including a link to the BDFL pronouncement email. I realized that there's no formal way to express this in a PEP, and many PEPs in fact don't record more than the fact that it was accepted. I'd like to propose officially adding an Accepted: header which should include a URL to the email or other web resource where the PEP is accepted. I've come as close as possible to this (without modifying the supporting scripts or PEP 1) in PEP 3147: http://www.python.org/dev/peps/pep-3147/ I'd be willing to update things if there are no objections. I'd rather not build a single point of failure into the process. Instead of insisting on BDFL pronouncement, the community should switch do something like last call for objections. There should also be a timeline so that unproductive discussion can't be dragged on forever. I believe the more important part of Barry's suggested change here is requiring a link to the archived message (usually from python-dev) where the PEP was accepted (be it directly by you as BDFL, or by consensus from a sufficient number of core developers). This will likely also help with reminding people to announce on python-dev when PEPs are accepted by consensus (or by you) somewhere like PyCon or a sprint. I would not mandate that we go back and update all previous PEPs for either of these ideas. We'd adopt them moving forward and allow anyone who's motivated to backfill information opportunistically. SGTM. +1 to both ideas from me, too. 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] Anyone can do patch reviews
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27/04/10 17:16, Barry Warsaw wrote: It would be kind of cool if there were some best practices for running said unittest both with and without the patch enabled. Kind of like using #ifdefs in C but without all the commenting-out-commenting-in error proneness. I guess you could do something like Mercurial queues are very useful here. You apply/deapply patches with a single command: http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html I am using python SVN mercurial mirror and MQ (Mercurial Queues) for development, waiting for the real thing (Mercurial native working). - -- 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/ iQCVAwUBS9dofJlgi5GaxT1NAQIyAQP/avvYJxxlY4lr58nHbjsuoROz1rQi7RrR qd8G3grsS9NXlYbygw0rERJyg9UgjDhJrZbwYEPGJkxTIUd/Vcnw/fIB6J+xuLlY sRnmh0P6ILOFTHYoZZZ/hxtfdMiZxqiMHO3Pfs8uBc5bGC0f23cqiTOFY0+ze7mU 3vUIcljhuRE= =oyQb -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 dange rjim to do triage.
On Tue, 27 Apr 2010 12:59:26 pm Stephen J. Turnbull wrote: 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'm not sure that is a relevant division between the two camps. I think both sides recognise the need to increase the number of contributors without compromising on their quality. I haven't heard anyone say that we have enough people to do the work that needs doing, or that we should take any warm body who can spell PC. As I see it, the two camps are divided purely on the question of how to get increased privileges. Both sides agree that merit is a requirement, but the disagreement is on how to prove you have such merit. One side insists that the only way to prove merit is to go through a period of untrusted, unprivileged contributions, with no exceptions. One argument for this is that unless we treat everyone identically, some would-be contributors will see the process as nepotism, or otherwise be offended that they didn't get the special treatment. I believe this misses the point that we *don't* treat people identically, nor can we in a meritocracy. People are treated differently according to not just the quality of their patches, but also the speed at which they submit them, and even more importantly, their ability to gain recognition for their merit. It's not enough to be good at what you do, people have to know it. Ten high-quality patches for high-profile bugs in a week may get you enhanced privileges, while thirty high-quality patches for low-profile bugs in six years might not, simply because nobody notices you. The other side says that a second way of proving merit is through reputation and having a trusted contributor vouch for you, and offer to mentor you. The major difference here is that it's not mandatory to prove your merit to the entire community, but sufficient to prove it to a single trusted member of the community who is willing to stake his own reputation on your ability to perform. Suppose the PSF were to hire somebody specifically to work on patches in the tracker, chances are they would be somebody well-known to the community. But suppose they weren't -- suppose the hirer read dozens of CVs, performed interviews, and determined that the best person for the job was somebody utterly unknown to the community, somebody who had been working quietly away doing brilliant things in Python but with no public profile, and offered her the job of committing patches. Would she get elevated privileges immediately? [...] *By definition*, a community is not diverse in the most fundamental sense. I think you're using a definition of community that doesn't appear in any dictionary I'm aware of, nor do I understand what you mean by most fundamental sense of diverse. Talking about diversity within a single community is not an oxymoron. As long as Pythonicity is important to Python, there is danger as well as opportunity in more rapid influx of newcomers. This at least is true. I can't dispute that. -- 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] Make 'normal' the default tracker priority level
On 4/27/2010 4:38 PM, Martin v. Löwis wrote: Done! When I open http://bugs.python.org/iss...@template=item priority is (still) set at no selection. Is this my local cache (which I do not know how to clear in FF) or is 'normal' filled in after submission? I do verify that searching for any issue with priority 'not selected' returns an empty list. 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
