Am Tue, 05 Nov 2013 16:44:43 +0200 schrieb Alan McKinnon <alan.mckin...@gmail.com>:
> On 05/11/2013 14:11, Marc Joliet wrote: > > Am Tue, 05 Nov 2013 12:14:59 +0200 > > schrieb Alan McKinnon <alan.mckin...@gmail.com>: > > > >> On 05/11/2013 11:52, Martin Vaeth wrote: > >>> Alan McKinnon <alan.mckin...@gmail.com> wrote: > >>>> You know what? I'm not convinced. > >>>> > >>>> What I'm seeing is a rather large towering edifice of complexity to deal > >>>> with a problem that is not the general case. > >>> > >>> I find it funny that perhaps you did not realize that you repeated > >>> the main argument *in favour of subslots* on the dev mailing list: > >> > >> > >> It seems to me that you didn't read the whole post fully, and have > >> cherry-picked a part that you think bolsters your position. It does not. > >> So I will repeat myself in a different way. > >> > >> I've run emerge -e world with the result of correcting something perhaps > >> 2 or 3 times in 8 years. Let's assume that in the absence of portage > >> being able to detect those nasty errors, that this is reasonably > >> representative of the actual incidence of actual errors I encountered. > >> Let's then be generous and triple it. > >> > >> In effect subslots appear to fix something for me about once a year. Is > >> my logic^Wguess flawed in any way? > > > > For *you*! You are not everyone, although I'm sure you already know that ;) > > . > > See my Haskell example below for when subslots fix something more often. > > > >> So now we have a rather large complex system that deals with what is > >> essentially a minor problem that occurs say once a year. > >> > >> I completely understand the problem sub-slots is trying to solve. I'm > >> just wondering if the methodology you are using to do it is valid, and > >> if it does not become the cure that is worse than the disease. > >> > >> Consider for a moment the maintenance burden imposed on ebuild > >> maintainers, and how sub-slot notation is essentially added by humans > >> deploying human brains. And remember that humans are notoriously bad at > >> using mathematically correct solutions (they ... err ... forget to do > >> stuff). > >> > >> sub-slots, whilst quite likely mathematically correct, has all the > >> hallmarks to me of SOMETHING THAT IS GOING TO FAIL DUE TO HUMANS. And > >> humans seldom do those things that they should do . If this were not so, > >> php would never have been written (just an arb random example) > >> > >> I predict once a week fallout from sub-slots induced bugs that was > >> intended to fix once a year problem. > >> > >> Do you now see why I'm not convinced this is a real-world solution? > > > > I think I see your point, but what is the worst that can happen if somebody > > gets a subslot wrong? Since too *many* rebuilds aren't all too terrible (a > > waste of time for sure, and potentially annoying, but it won't outright > > break > > anything), I suppose the worst case is too *few* automatic rebuilds, right? > > So > > to me it sounds like you want to throw out the feature altogether because it > > won't *always* catch everything. Or what potential bugs are you thinking > > about > > that aren't useless rebuilds? I don't remember any from this thread, but of > > course I could have missed something. > > > > I too see your viewpoint, as you see mine. There's nothing wrong with > your logic within the narrow domain of making the code that implements > this specific feature (subslots) work correctly per spec. > > Background: I'm a Linux sysadmin by day at an ISP. I constantly have to > contend with Devs and Devops writing bespoke code to implement business > rules. Because I sit three feet back from the problem, I can almost > always see the flaws with the solution. I can't give much details > unfortunately, my employer owns the code. But I get to be very very good > at spotting code that runs per spec, but is very brittle in the real > world. I look for tells like this: For clarification: my background is very different and lies in science and engineering, which has its own (overlapping) set of programming problems, some of them probably (hopefully? (for you I mean)) of a more basic nature than what you have to deal with. One word: MATLAB. The only thing I'll say about it is that it's the only programming language I know whose usage can make me aggressive (and I like POSIX Shell, which at worst irritates me, so I think that's saying something). At least I was able to choose the language used for my master's thesis myself (Python, of course). > - is the dev trying to get code deployed that is not fully tested? > - is the dev trying to ignore or minimize the real world effect on other > systems? > - can the dev show that someone else (not him) can actually maintain it, > configure it and understand it? > - Can every single person in his team rattle off the primary salient > points of the code without thinking much? > - Did the team who write the code write a doc on how to configure it, > and how to deal with possible failures they anticipate? > - If someone else (like eg me) gets this wrong and I make mistakes while > deploying, how will I know I've made a mistake? Do I get a sane error > message that a) describes the error in simple language and b) does not > make the fatal mistake of exposing the underlying implementation in > error messages? > - Do I need to read the code itself to gain even a high level > understanding of what the code does? Those sound like some pretty sane metrics, especially for important infrastructure code. Also: anyone can code to spec, you just have to fix the spec ;) . One of those questions stands out to me right now: the one on understandable error messages. As some recent posts to this ML demonstrate, it seems to be one area where portage is visibly falling (staying?) behind right now. They remind me of the type of error message gcc/g++ spit out, actually. > By now you will have guessed that nearby Dev team hate my guts with a > passion. Unlucky for them, I'm root and they ain't. Lucky for them, I'm > quite reasonable and happy to work together to get the questions > answered. With an answer of some kind, we can assess risk and make a > rational choice. Oftentimes it comes down to we write one detailed > technical doc and allay all fears. Haha, yes, I bet they do hate your guts ;) . However, in all honesty, I actually think having somebody perform a job like that is a good thing. Mostly I think it boils down to the idea that writing code in a cave (or echo chamber, for that matter) with no outside input will pretty much never yield the best results (for a variety of reasons). Or put differently: you should always seek external feedback on your code, if only to get some outside perspective. In fact, at my previous job at a local research institution my supervisor (sort of) fulfilled such a role. However, he was pretty much alone in trying to establish good (or at least *consistent*) programming practices and had little power to enforce them. I would love to name some of the nastier examples of what people would do (you know, apart from not writing proper build systems or documentation, etc.), but I don't want to veer too much off topic. > I don't see these questions being answered wrt subslots. Maybe they were > answered and I haven't seen the link yet, maybe not. Maybe senior devs > with clue have thus far successfully modified ebuilds, maybe not. Maybe > more junior devshave yet to take their first steps, and maybe they will > royally screw things up by not understanding the syntax, or maybe not. > > These questions have not been answered and I certainly don't have > answers; I also think neither do you. I would like to see this feature > extensively tested in de and stage before it hits production. Only then > can I decide for myself if subslots are a good solution to the stated > problem. > [...] Yes, of course I don't have answers :) . I'm just a user thinking out loud and sharing my experience. Anyway, now that you've made your point clear as day, I see it better now :) . -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup
signature.asc
Description: PGP signature
