On Fri, 17 Jan 2020 at 04:33, Nicolas Mailhot via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Le jeudi 16 janvier 2020 à 22:24 -0500, Neal Gompa a écrit : > > Hi Neal, > > > I've also said that I don't think we can handle it as our > > infrastructure currently stands. Our build system tooling has > > suffered from a decade of neglect, and attempts to reinvent or > > improve that have been rebuffed or failed in other ways. > > … > > > > there's an underlying general problem that it is okay to > > hobble along because we've hobbled along for so long. > > I agree 100%, thanks for posting this, it’s not easy be the messenger > for bad news. > > > Incrementalism has its place, but this is something where once we > > implement the "just enough increment", we'll stop again and > > everything will just be uncomfortable and somewhat unhelpful, > > And here I disagree. Beware of the “let’s rewrite everything better” > trap. If anything our incremental fixes failed more often than not > because key players waited on big bang magical solutions (for example, > modularity). > > We need to implement more incremental fixes. Incremental does not mean > risk free, it means *managed* risk. Project members need to accept > incremental changes need to go in, and they need to accept incremental > changes may break things or require some amount of project-wide work. > > And, the Fedora leadership needs to do its leadership job. Leadership > does not mean promoting fuzzy long term objectives that no one can > disagree on because of the fuzziness, and that will explode on someone > else’s turn. Leadership means decisions for today, not just tomorrow. > > Big bang initiatives have their places, but only when incrementalism > has hit a technical impasse. The Boeing 737 is an example where > incrementalism hit its limits. But, the 70 years of some 737 components > show how long incrementalism can be successful, as long as it it > managed intelligently. > My 'take' on the 737MAX problems is that they decided that incrementalism wasn't going 'fast' enough but they also didn't want to add a lot of training costs or 'change aversion' items. So they put in a lot of new things which would have made the plane a different model but then tried to sell it that they hadn't changed much so you didn't need to send your pilots to retrain over the fact that various switches do the opposite of what they did before.. Boeing then further 'cut' costs by removing a lot of places where a pilot team could over-ride the computers or have a backup piece in case the first failed. All of these things could have still been done with incrementalism, but it would have probably taken 10 more years that they felt they didn't need but that they also didn't want to lose their current customer base by making a 7337 or a 797 plane which told everyone this plane is different. One problem with rewrite everything is where you try to keep your existing base because it is safe but also try to do something completely new. If you are going to do it.. be clear about it and realize that the people you had will have little interest in it because they are happy with what they have. -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
