-----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 <dr.trigon(a)surfeu.ch
<mailto:dr.trigon@surfeu.ch>> 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-----