[SciPy-Dev] "ok to apply" permission request

David Goldsmith d.l.goldsmith@gmail....
Sat Jun 19 13:49:57 CDT 2010


On Fri, Jun 18, 2010 at 8:35 PM, Ralf Gommers
<ralf.gommers@googlemail.com>wrote:

>
> On Sat, Jun 19, 2010 at 5:49 AM, David Goldsmith <d.l.goldsmith@gmail.com>wrote:
>
>> On Fri, Jun 18, 2010 at 2:38 PM, Pauli Virtanen <pav@iki.fi> wrote:
>>
>>> Fri, 18 Jun 2010 13:44:11 -0700, David Goldsmith wrote:
>>> [clip]
>>> > I don't understand: if they're going to commit the changes, why do they
>>> > need to be able to mark that they're going to commit the changes?  To
>>> > help them remember which ones they've screened as possessing nothing
>>> > "absurd" in case they can't commit the changes immediately after
>>> they've
>>> > decided to commit the changes?
>>>
>>> The point is that you typically commit a huge batch of docstring changes
>>> at once, and reading through a long patch listing makes your eyes glaze
>>> over really fast.
>>>
>>
>> OK, I understand that, and it makes sense during the regular course of the
>> year when docstring changes aren't happening as frequently, but, something
>> to consider, perhaps through the course of the Summer Marathon, "OK to
>> apply"s should be merged once per week or some such?
>>
>
> It always makes sense. "OK to apply" should only be used by (a) someone who
> is about to commit to svn or (b) someone who is 200% sure what this means.
>
> A few weeks ago I was committing all scipy changes and found many "OK to
> apply" ones that couldn't actually be committed, for various reasons. This
> meant I had to go back and recheck everything, including ones I had checked
> as OK myself before.
>
> So a rough sanity check is much easier to do in the web system, and the
>>> burden can be distributed across multiple people if necessary. Currently
>>> ok-to-apply is married with the Reviewer permissions.
>>>
>>> At least this is what I used and intended the feature for. I'm not sure
>>> if anyone else actually understands it the same way, especially as this
>>> is not written down anywhere :)
>>>
>>> > > Typically the way to just indicate that stuff is "done", is to mark
>>> is
>>> > > as "Needs review", at the moment.
>>> >
>>> > I guess then I'm really unclear as to the need for the "OK to apply";
>>> my
>>> > understanding was that it was there for the editor to signal to the
>>> > commitor that, even thought the docstring is technically *not* ready
>>> for
>>> > review (e.g., it's still missing an Example, say, or a needed
>>> > Reference), it still represents a big enough improvement over what's in
>>> > SVN that, in the editor's opinion, it is "OK to apply".  If "Needs
>>> > review" is necessary and sufficient for something to be applied, then
>>> > why do we need the extra "OK to apply"?
>>>
>>> It was intended mostly as a reviewer/committer-level tool, at least
>>> originally, which is why it's not active with Editor permissions. Since
>>> anyone can in principle come and edit the wiki, I thought something like
>>> this would come useful.
>>>
>>> I haven't been following the edits lately, so I guess its your call as
>>> the present active guy to decide who gets which privileges :)
>>>
>>
>> Not necessarily (certainly not in that I don't have the permissions to
>> grant such permissions; I don't even have permissions to commit changes): it
>> depends on the purpose of the attribute - if it's closer to what you say,
>> then I agree, it should be a reviewer/committor (though I didn't think those
>> were one and the same) who controls this; if, on the other hand, the purpose
>> is closer to what I say, then, at minimum, we need to think more about how
>> we do this.
>>
>
> It's not only about content, but also for example knowing for which
> docstrings pydocweb can not generate correct patches at the moment.
>

Ah, in that case, please rescind my "OK to apply" permissions.  Thanks!

DG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20100619/ee93eedc/attachment.html 


More information about the SciPy-Dev mailing list