Hi Dr. Trigon, On 31 July 2013 11:53, Dr. Trigon <[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. > 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. > 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. > I mean nothing will break if the code is not > pep8. It will still work. It is just not that clean and pure anymore. > True. > > 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? Merlijn
_______________________________________________ Pywikipedia-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
