Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.

2010-04-27 Thread Georg Brandl 
Am 26.04.2010 15:34, schrieb Lennart Regebro:
> On Mon, Apr 26, 2010 at 12:58, Stephen J. Turnbull  wrote:
>> It is entirely *not* evident to me that it's too hard to get
>> privileges in the Python development community (Python's development
>> process works -- and it works really well by comparison to 99% of the
>> processes out there).
> 
> Well, 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
[email protected]
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-04-27 Thread Lennart Regebro 
On Tue, Apr 27, 2010 at 09:18, Georg Brandl  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
[email protected]
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

2010-04-27 Thread Tarek Ziadé 
On Tue, Apr 27, 2010 at 1:24 AM, Toshio Kuratomi  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
[email protected]
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

2010-04-27 Thread Tarek Ziadé 
On Tue, Apr 27, 2010 at 2:43 AM, David Cournapeau  wrote:
> On Tue, Apr 27, 2010 at 5:10 AM, Piotr Ożarowski  wrote:
>
>> if there's no other way (--install-data is ignored right now, and I know
>> you're doing a great work to change that, thanks BTW), one could always
>> use it in *one* place and later import the result in other parts of
>> the code (instead of 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
[email protected]
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-04-27 Thread R. David Murray 
On Mon, 26 Apr 2010 14:15:01 -0400, Steve Holden  wrote:
> Antoine Pitrou wrote:
> > Steven D'Aprano  pearwood.info> writes:
> >> Who are we worried about offending? The crowds on the Internet who never 
> >> volunteer for anything, who never submit patches, let alone offer to do 
> >> the unglamourous work?
> > 
> > Perhaps you should look more carefully. We do have 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
[email protected]
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

2010-04-27 Thread Antoine Pitrou 
Terry Reedy  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
[email protected]
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-04-27 Thread Steve Holden 
R. David Murray wrote:
> On Mon, 26 Apr 2010 14:15:01 -0400, Steve Holden  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
[email protected]
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

2010-04-27 Thread Antoine Pitrou 
Antoine Pitrou  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
[email protected]
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)

2010-04-27 Thread R. David Murray 
On Mon, 26 Apr 2010 14:23:00 -0400, Terry Reedy  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
[email protected]
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

2010-04-27 Thread R. David Murray 
On Mon, 26 Apr 2010 22:39:39 +0200, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= 
 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
[email protected]
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-04-27 Thread Nick Coghlan 
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   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
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...)

2010-04-27 Thread R. David Murray 
On Tue, 27 Apr 2010 11:15:49 +1000, Steven D'Aprano  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
[email protected]
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

2010-04-27 Thread Nick Coghlan 
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   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
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-04-27 Thread R. David Murray 
On Tue, 27 Apr 2010 23:34:48 +1000, Nick Coghlan  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
[email protected]
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

2010-04-27 Thread Daniel Stutzbach 
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 
___
Python-Dev mailing list
[email protected]
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

2010-04-27 Thread Toshio Kuratomi 
On Tue, Apr 27, 2010 at 09:41:02AM +0200, Tarek Ziadé wrote:
> On Tue, Apr 27, 2010 at 1:24 AM, Toshio Kuratomi  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
[email protected]
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...)

2010-04-27 Thread exarkun 

On 01:38 pm, [email protected] wrote:
On Tue, 27 Apr 2010 11:15:49 +1000, Steven D'Aprano 
 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
[email protected]
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

2010-04-27 Thread Brian Curtin 
On Tue, Apr 27, 2010 at 09:22, Daniel Stutzbach <
[email protected]> 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 
>
+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
[email protected]
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

2010-04-27 Thread R. David Murray 
On Tue, 27 Apr 2010 09:22:07 -0500, Daniel Stutzbach 
 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
[email protected]
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...)

2010-04-27 Thread Barry Warsaw 
On Apr 27, 2010, at 02:40 PM, [email protected] wrote:

>On 01:38 pm, [email protected] 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
[email protected]
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

2010-04-27 Thread Daniel Stutzbach 
On Tue, Apr 27, 2010 at 10:14 AM, R. David Murray wrote:

> 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 
___
Python-Dev mailing list
[email protected]
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...)

2010-04-27 Thread R. David Murray 
On Tue, 27 Apr 2010 11:16:51 -0400, 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
> 
> 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 , 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
[email protected]
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...)

2010-04-27 Thread Ezio Melotti 
On Tue, Apr 27, 2010 at 5:16 PM, Barry Warsaw  wrote:

> On Apr 27, 2010, at 02:40 PM, [email protected] wrote:
>
> >On 01:38 pm, [email protected] 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
[email protected]
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

2010-04-27 Thread R. David Murray 
On Tue, 27 Apr 2010 10:34:16 -0500, Daniel Stutzbach 
 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
[email protected]
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

2010-04-27 Thread Barry Warsaw 
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
[email protected]
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

2010-04-27 Thread Daniel Stutzbach 
On Tue, Apr 27, 2010 at 11:16 AM, R. David Murray wrote:

> 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 
___
Python-Dev mailing list
[email protected]
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...)

2010-04-27 Thread Barry Warsaw 
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
[email protected]
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

2010-04-27 Thread Brett Cannon 
Sounds good to me (from my phone on my way to WWW2010).

On Apr 27, 2010 10:49 AM, "Barry Warsaw"  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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/brett%40python.org
___
Python-Dev mailing list
[email protected]
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

2010-04-27 Thread Tres Seaver 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

R. David Murray wrote:
> On Tue, 27 Apr 2010 11:15:49 +1000, Steven D'Aprano  
> 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  [email protected]
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

iEYEARECAAYFAkvXLtkACgkQ+gerLs4ltQ79DACbB35/XFGyiYjd79OtTx+kgoNl
mcsAnA4TNlM1ARjyrDrQIwv4KG48w/7h
=1hGI
-END PGP SIGNATURE-

___
Python-Dev mailing list
[email protected]
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

2010-04-27 Thread Tres Seaver 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Barry Warsaw wrote:
> On Apr 27, 2010, at 02:40 PM, [email protected] wrote:
> 
>> On 01:38 pm, [email protected] 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  [email protected]
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

iEYEARECAAYFAkvXLuMACgkQ+gerLs4ltQ5HBQCgw7kqJ52kPz+0cwNSpyVUkCFA
yQUAoLHJiYi+59Cc7BCeL46hA+Wygo66
=93vQ
-END PGP SIGNATURE-

___
Python-Dev mailing list
[email protected]
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

2010-04-27 Thread Antoine Pitrou 
Tres Seaver  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
[email protected]
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

2010-04-27 Thread Guido van Rossum 
On Tue, Apr 27, 2010 at 10:46 AM, Barry Warsaw  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
[email protected]
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

2010-04-27 Thread Tres Seaver 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Antoine Pitrou wrote:
> Tres Seaver  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  [email protected]
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

iEYEARECAAYFAkvXOacACgkQ+gerLs4ltQ6ZTwCfQ96RYQ6h/zdMOnFUJU3MkSC1
+o8An2CqK7fbpiCM3gBWZuRReG46xv+U
=iWug
-END PGP SIGNATURE-

___
Python-Dev mailing list
[email protected]
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

2010-04-27 Thread C. Titus Brown 
On Tue, Apr 27, 2010 at 03:23:19PM -0400, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Antoine Pitrou wrote:
> > Tres Seaver  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, [email protected]
___
Python-Dev mailing list
[email protected]
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

2010-04-27 Thread Barry Warsaw 
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
[email protected]
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

2010-04-27 Thread Martin v. Löwis 
R. David Murray wrote:
> On Mon, 26 Apr 2010 22:39:39 +0200, 
> =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=  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
[email protected]
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

2010-04-27 Thread Fred Drake 
On Tue, Apr 27, 2010 at 4:38 PM, "Martin v. Löwis"  wrote:
> Done!

Thanks, Martin!


  -Fred

-- 
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Miller
___
Python-Dev mailing list
[email protected]
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

2010-04-27 Thread Martin v. Löwis 
Antoine Pitrou wrote:
> Antoine Pitrou  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
[email protected]
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

2010-04-27 Thread Martin v. Löwis 

> 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
[email protected]
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

2010-04-27 Thread Martin v. Löwis 
> 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
[email protected]
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

2010-04-27 Thread Martin v. Löwis 
> 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
[email protected]
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

2010-04-27 Thread Antoine Pitrou 
Martin v. Löwis  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
[email protected]
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

2010-04-27 Thread Tres Seaver 
-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  [email protected]
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

iEYEARECAAYFAkvXVV8ACgkQ+gerLs4ltQ7JqwCfVZPkm8/3XUuuzpm/N+08x2RI
KWYAn004cLJS3poYZ/4BvSFOGzMpwNuC
=j3lH
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
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

2010-04-27 Thread Martin v. Löwis 
> 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
[email protected]
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

2010-04-27 Thread Nick Coghlan 
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   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
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

2010-04-27 Thread Nick Coghlan 
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   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
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

2010-04-27 Thread Jesus Cea 
-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:



I am using python SVN mercurial mirror and MQ (Mercurial Queues) for
development, waiting for the "real thing" (Mercurial native working).

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
[email protected] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:[email protected] _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"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
[email protected]
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.

2010-04-27 Thread Steven D'Aprano 
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
[email protected]
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

2010-04-27 Thread Terry Reedy 

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
[email protected]
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

2010-04-27 Thread Martin v. Löwis 

> 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?

It is filled in after submission.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com