|
|
Subscribe / Log in / New account

The costs of forks

The costs of forks

Posted Jun 21, 2015 1:20 UTC (Sun) by angdraug (subscriber, #7487)
In reply to: The costs of forks by fandingo
Parent article: The costs of forks

Please start doing your own research. Answers to all your questions are right there in the thread on openstack-dev, the article that has summarized it, the comments here, or at most a quick google search away. If you're not interested in answers, please explicitly state that your questions are rhetorical. It would also be a good form to confirm whether or not you have a personal stake in this discussion, like I did in my first comment here. All that would help reassure me that you're genuinely interested in a two-way conversation and I shouldn't follow dlang's example and stop reading.

Why isn't Fuel a strict consumer of modules in PO? Why was the code ever forked?

The answer is right there in the comment you were replying to: deadlines.

Presumably the answer to #1 includes something about lacking functionality or bugs. Why weren't they just fixed in PO?

The answer is in one of my emails to the thread that were linked from the article above: additional effort that it would require from Fuel developers. Additional 5x to 10x times worth of effort, as I have illustrated in another email on that thread.

Why are OpenStack developers so siloed in their own projects? Why don't they contribute across projects instead of forking?

That is not true, and you would know that if you tried to confirm that accusation using Stackalytics, the online tool I linked in my previous comment. If you look at the top individual bug fixers in Kilo and check their commit statistics you'll find that the most active contributors have commits in dozens of projects outside of their main area of interest. OpenStack is complex, it takes time to learn even one component, so you can't blame less experienced contributors for sticking to the areas they know well.

Heck, if you bothered to RTFA you'd find the evidence of Fuel developers contributing to Puppet OpenStack in another linked email.

Fuel seems to fundamentally be an expansion of what PO set out to do. Why was a separate project started, and why is it trying to "drink PO's milkshake?"

No, it isn't. I already tried to explain that in another comment here. Just as Fuel is not just a GUI front-end to Puppet OpenStack, it's also not a replacement for Puppet OpenStack. The latter is a swiss army knife style collection of individual modules that allow you to set up individual OpenStack components in any way you like, and leave all the decisions and all the integration work up to you. The former is an integrated system that combines a local fork of the latter, a GUI, a great deal of orchestration logic, and a whole reference architectures guide's worth of configuration decisions that, all together, offers a completely different balance between flexibility and the effort and expertise required to get OpenStack up and running.

Was there any consideration to expanding the goals of PO, rebranding it, and essentially making Fuel without the need to duplicate so much work?

Wrong question. Turning Puppet OpenStack into what Fuel is now would have been a perversion of Puppet OpenStack purpose as it would severely narrow down the range of configurations it could support. Making Fuel out of just Puppet OpenStack without all the configuration choices, orchestration, UI, and operational tooling would have been impossible, see the code stats I've already posted here. A better question would have been, could the effort duplication specifically in the Puppet code of Fuel (fuel-library) be reduced? Maybe. Should the effort to reconcile fuel-library with upstream have been started earlier than 2014? I think so. Should "upstream first" have been the requirement from the very beginning? No, I don't believe that would have worked out at the time, due to the same expediency considerations that you chose to dismiss.

What's the corporate alignment behind Fuel and PO? Who's sponsoring major portions of development? Which corporation(s) started Fuel?

Are all those rhetorical questions? If you have time to write lengthy comments like this surely you have 5 minutes to find the answers on Stackalytics?

Did they have a beef with the corporation(s) behind PO, or more generally, what's their "angle?"

For someone who claims to use direct language, you sure chose a roundabout way to build up to this accusation. Is that why you're ignoring all technical reasons for the current situation? You think there's some sinister corporate conspiracy that hundreds of OpenStack contributors have been covering up all these years? Sorry, but the answer is no, I can't think of any real or imagined "beef" or "angle" that could have influenced that decision, it's always been a matter of expediency.

This gets back to the political tensions and infighting: Is the goal to entirely displace PO? It sure seems like it, and you bugfix numbers suggest so.

So far, the infighting has only been in your imagination, and I seriously don't appreciate your efforts to make the "political tensions" a reality by trying to invent reasons for Fuel and Puppet OpenStack to compete, when I have abundantly demonstrated (using bug numbers among other data) that collaboration is in both project's best interests, and key developers from both projects have publicly acknowledged the same and came up with process changes to improve that collaboration and eventually un-fork the projects.


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds