-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10.08.2013 15:30, Merlijn van Deen wrote:
> Hi Dr. Trigon,
> 
> On 31 July 2013 11:53, Dr. Trigon <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> I find it useful as it is already!
> 
> 
> I'm confused to how, exactly :-) Yes, you can now run pep8
> locally, which is useful, but the bot just reports 'oh, hey, the
> code doesn't pass validation', which does not actually tell use
> something new.

I assumed (my misstake ;) that the bot just checks the code contained
in the changeset/patch not the whole repo. First would be useful
indeed since it saves me some work, second would be indeed useless
since... yes you are right, that would be nothing new nor useful to
know... ;)

> As mentioned it would be good to have pep8 but I would be careful
> with FORCING it by blocking non-pep8-compilant patches/changes 
> because first of all that would just increase the workload to us.
> 
> This is true, although I think this is not too bad. I pep8-ified
> several files a week ago, and it was not a huge effort, so just
> fixing a single (or a few) problem in a patchset shouldn't be too
> much hassle.

There are 2 situations; if you have time and are anyway doing several
code changes, then you are right that should not be too much hassle.
But if you do not have spare time but need to fix an urgent bug - than
pep8 might by just very annoying...

>> 1) all code passes pep8 validation 2) someone uploads a patchset 
>> that adds a mistake: the merged repository does not pass 
>> validation 3) the bot reports the patchset failed validation 4)
>> the change is merged -> the repository no longer passes
>> validation!
> 
> Yes that's of course what can (and according to Murphy also will) 
> happen, but I would just mark susch a commit as bug or at least "to
> be improved" and fix it.
> 
> 
> What is the advantage of 'merge first, then (maybe, if you don't
> forget) fix' over 'fix first, then merge'? It has to be fixed at
> some point anyway.

Sorry that might be a missunderstanding; of course if you SEE a code
or styling but/issue you should (have ;) to fix it directly. I was
taking of a bug or issue you introduced with a change accidentially.

>> And because the repository no longer passes validation, the bot 
>> will also report 'failure' on any following patchset!
> 
> There it would be nice if the bot could be patched in order to
> become such smart that it can mark this as follow-up to the buggy
> patchset that was not pep8.
> 
> I don't understand this point. You mean the bot could mark the
> fixing patchset as related to the buggy patchset?

If you have change 'A' that is not pep8 compillant, the bot should
mark it. You are free to improve it (if you DO you are a hero - if
not, don't bother...). If it was NOT improved but merged and later
another change 'B' (changing the same code as 'A' did) is made which
IS pep8 but the whole code IS NOT - then it would be nice if the bot
could mention, that the pep8 issue was triggered by change 'A' and not
'B'... something like that, but I think this will be very complex to
implement and I am not sure of how much help this will be - was just
an idea... :)

Greetings
DrTrigon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlIQ1MIACgkQAXWvBxzBrDDLqgCfXdLgwNXSCdxqwYzRf3NVuvk6
xrIAn08rxlUcUhp9Q3F+K9nk2hGJ3gvN
=VQjf
-----END PGP SIGNATURE-----

_______________________________________________
Pywikipedia-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l

Reply via email to