https://bugs.kde.org/show_bug.cgi?id=431768
--- Comment #5 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Alexander Lohnau from comment #4) > (In reply to Duncan from comment #3) > > This may well be the first of several bugs given the recent ecm git-hooks > > commit (which I understood why but wondered about the bugs it might generate > > when I saw it), so however this ultimately gets resolved will let me see > > where I file those bugs. =;^| > > I honestly do not understand what you mean. The error that the file does not > exist should definitely get fixed. After that you will just get a warning > that there is no clang-format executable found, but that is not a critical > error. Apologies in advance as this ends up being a bit of a wall of text... [Just to make the context explicit in case someone hasn't seen the logs or comes back to this in a few months, it's extra-cmake-modules 45edd1b17 and followups. And explicit thanks to you the author as well; it's surely going to improve things in general! That said...] Perhaps an existing example will make things clearer. Tests. I'm sure everyone agrees integration testing is critical. I believe devs normally run with them enabled (as they should) as does the testing machinery (the point, for it!). But users building from source, gentooers, linux-from-scratchers, perhaps archers, others, may turn off testing at configure time (it's an available package-manager-config togglable feature on gentoo), because for them tests are actually building and running the software, and testing at build-time can both take much more time and pull in all sorts of additional deps. The problem is that because devs and their testing machinery always have testing enabled, the non-testing option tends to bit-rot and tends to be broken on enough packages enough of the time that gentoo/kde at least has an entire set of machinery dedicated to allow testing to be forced off where upstream overlooked it and automate the easiest breakage fixes, so the only no-testing breakage they have to spend per-package time on is breakage that's not so easily automated away. It eventually gets fixed upstream, but by then there's other no-test breakage elsewhere, so it tends to be an unending battle. [After writing the above I wonder: Would an integration tests setup that included build-testing for failures with testing turned off help catch this sort of no-testing bugs? Would it be worth it? Come to think of it, it has been awhile since I needed to report such a bug. I know gentoo/kde upgraded their automation for it a few months ago. That probably helped, but maybe upstream kde setup a no-tests test too? Anyway...] This git-hooks feature looks, at least initially, like it could be similar. It's another feature like testing that devs might overlook where their configuration is likely to be different from that of some of the direct users, thus triggering another opportunity for new code designed to take advantage of the feature to break for users who don't have that feature enabled, due to inadvertently hard-coded assumptions that don't hold for those users and their build environment. So overall it's good, even GREAT!, but like many good/GREAT! things, I'm afraid there are likely to be some relatively smaller negatives that partially offset the goodness. And due to my personal position in the ecosystem running live-git so catching and bug-reporting these things before they can affect others, I'm likely to be particularly heavily affected by any such negatives. So pardon my grumpiness, even if I know it's part of what I deliberately undertook by choosing to run live-git! =:^) Maybe I'm wrong and this isn't going to trigger an entire new genre of bugs akin to those I've seen and reported for testing, or sometimes seen the aftermath of in the git logs at both the gentoo and upstream levels, and like testing it's surely worth it even if it does, but that possibility is what I was alluding to and am afraid of. But if this /is/ the first of such an entire new genre of bugs hatched by this thing, how this one gets resolved will help me know where to file and what details I need to include on the others, when they come. -- You are receiving this mail because: You are watching all bug changes.
