On 26 October 2015 at 19:34, Nigel Magnay <[email protected]> wrote: >> That's why automation check should save time and enhance quality. > > It only “enhances quality” if you agree with the idea that a set of > arbitrary syntactic checkstyle rules spat out by tooling represents > “quality” rather than merely “conformity". The truth is ‘quality’ is rather > hard to measure - particularly in an automated way - and we’re left with the > old management adage that those who can’t measure what they want, end up > wanting what they can measure. This is why poor managers often clock-watch > and obsess as to whether their staff turn up in a suit & tie or not. > > e.g: JDK7 has, according to SonarQube, over 100,000 “Major, Critical or > Blocking” issues. IMO, that says much more about the value of SonarQube > than the quality of the JDK (which, incidentally, has an almost entirely > uniform code style). > > If a PR ‘fails’ from a bunch of checkstyle rules, you’re effectively asking > the original author to expend additional effort on ‘conformity’. The time > cost delivers zero end-user value, and meanwhile you’re piling up inventory > — risking yet more rework in the event of a merge conflict, or the author > simply giving up (after all, he’s given this code to you for free). Software > development these days claims to be all about being agile - and yet the > above is practically the ‘lean’ textbook example of waste. > > Having a clean history - not having to dig through commits that did nothing > to change the semantics (merely dicked about with the whitespace) - turns > out to be far more important now that tooling has moved to the state when > histories become actually useful. Which is why ideas from old-school coding > standards (like making variable names line up horizontally - which actually > really does improve readability) are basically dropped (because this makes a > single character change potentially ripple to several unrelated lines, > polluting the history and potentially making merges harder).
And `git blame --first-parent -w` becomes much more important when tracking and tracing changes... Once you start down the `--first-parent` route you then realize that all this fussing over squashing commits is a waste of time, there is no need to squash commits... the only need is to fix the GitHub UI so that people who are not CLI ninjas can gain the benefit... Please everyone start pestering GitHub to add the support for --first-parent and -w on the git blame and git log web pages... if it's just my request sitting in their in box it may take a while... if everyone asks for it... well they should fix it faster. > > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83SVJT7d6TN07Xh_obV94Y09n84Mtb8T6u6gyZAZ%2BEHS%3Dw%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMzHC%3D5XoSwFwy5YfLhxsZX%3Djo%2BWPK-zdGb9zk5uvq91Gw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
