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: - 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? 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. 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. > > But what's the alternative? Telling the user to do it instead? That requires > human input, too: *somebody* has to write the elog message, and such that > any Gentoo user can understand it. Or is your point that one can look for > *fully* automatic solutions, as opposed to solutions where humans have to > provide input? I would expect the portage developers to have thought about it > for a while before settling with the subslot idea. > > Now an example of my experience with subslots: > > I use pandoc (used by IPython Notebook to convert notebooks to html or > whatever), and it -- along with all it's Haskell dependencies -- uses > subslots. > That means that, whenever one of the Haskell dependencies updates, it > automatically rebuilds its reverse dependencies. And most of the time, it > works > just fine! That's when I like subslots. Especially since the Haskell packages > are moving targets that update fairly often. > > When it doesn't work, I'm stuck looking for what I have to rebuild. As a > matter of fact, I ran into such an issue just now: dev-haskell/texmath is > missing a dependency somewhere, so that pandoc would not compile (or run) > anymore after an upgrade to dev-haskell/aeson. Solution: recompile texmath > manually (a bug report will follow). That was simple, however, since the error > message of the Haskell compiler tells you which libraries are the problem. I > don't think I dislike subslots because of this. It's certainly nothing > preserved-rebuild or revdep-rebuild would find. > > So, unless there's an at least equally good alternative, *no* subslots would > mean I would have to re-merge *all* dev-haskell packages after every update, > just to be on the safe side (or iteratively recompile according to what the > error message tells me until I finally catch all packages). I think that would > be slightly more terrible than forgotten subslots ;) . > > -------------------- > > That said, one can certainly improve the "user interface" to subslots, and I > like the ideas put forth by Martin Väth in > https://bugs.gentoo.org/show_bug.cgi?id=490350. I especially like the idea of > having a dynamic set analogous to @preserved-rebuild (under the condition that > it also includes the updates that cause the rebuilds and not just the rebuilds > themselves, in order to avoid breakage). You could call it @subslot-rebuild ;) > or @subslot-upgrade. > -- Alan McKinnon alan.mckin...@gmail.com
