Hi, On Tue, Dec 17, 2013 at 11:22:17PM -0600, rob_hirschf...@dell.com wrote: > All, > > So far, we've accomplished more with Crowbar 1 than I imagined possible. We > have led an new generation of bare metal automated installation and set a > standard that has been noticed. More importantly, we've learned critical > lessons about the right way to solve these hard problems. Crowbar 2 (both > iterations) are the embodiment of those hard won experiences. Our experience > with Crowbar 1 is driving a disruptive set of changes. > > We've reached a critical point with the Open Crowbar Project where we have a I might have missed something, but why does everybody now start to talk about Opencrowbar and "The Open Crowbar Project"? This just increases the already existing confusion around the whole project. As if Crowbar wasn't open before. What's wrong with just continuing to call it Crowbar?
> stable refactored base (aka Crowbar 2) for the open source project. This > base was created incrementally inside the current project but reflects a > fundamentally different code base. It's truly a new generation and that > means much of our legacy infrastructure is out of date. Up to this point, > we've worked very hard to keep both old and new code bases together and it > has added complexity and confusion for both code lines. We want to preserve > the stability of the Crowbar 1 code base, yet the changes we are making to > Crowbar 2 pose significant risk of breakage. > > With Crowbar 2, we have an opportunity to reach a broader audience of both > users and developers. Above all other objectives, expanding our community is > our top priority because it ensures the relevance and longevity of the > project. > > In November, we held a review of the status of the Crowbar 2 project and it > became clear that the code is ready for this challenge; however, the code is > only a part of what we need to make Crowbar successful. > > To be successful, the Open Crowbar project needs to improve/address the > following challenges: > * Documentation and materials that are clear and relevant > * Build process and tools that are transparent and easy to use > * Installation methodologies that align with industry practices > * Test (especially automated) coverage that ensures consistent > quality and stability > * Community governance that encourages collaboration, exposes value > that's being created and enables contribution > * Consistent and clear version/release management that works for both > community and commercial interests > * Overall simplification of the project layout and infrastructure to > accomplish the above. > > Many of these changes are disruptive and/or would require substantial > investment in Crowbar 1 infrastructure, to update and test. In the absence > of engineering resources that are committed to retrospectively retooling the > Crowbar 1 code base the only safe solution is to separate the Crowbar 2 code > from the current stable code tree. > > There has already been a discussion about this on the list that did not > result in a consensus. At some point, we must make a decision and move > forward to accomplish these goals because they are essential to the > community's growth. Any you really think that expanding the community works best by first separating the project into two? This sounds a little strange to me :) I believe Adam and others have made suggestions in the past for improving the git and wiki structure in a way that would allow Crowbar 2 to move forward without requiring a complete split. Have those been considered? If not, why? > Unlike code changes that can be managed in a branch by a small team; these > changes are highly visible and structural. Mostly significantly, we need to > eliminate layers of obfuscation that were built up over time. For this > reason, I believe that we need a clean base for this restructuring with the > following likely impacts: > > 1) Separate the Crowbar 1 and 2 documentation and wikis. They are > diverged enough to be confusing when intermingled. Further CB2 docs are > managed differently and already substantially ahead of CB1. > 2) Introduce a gated CI build process that can be managed by Gerrit (or > similar) - there is a similar but unrelated effort going on for Crowbar 1. > 3) Break the "DevTool" functions into parts (or eliminate in places) to > improve transparency > 4) Consolidate the core Crowbar barclamps into a single new repo (these > are the ones active in Crowbar 2 dev) > 5) Converge other "workload" barclamps into bundles (such as all of > OpenStack together to match the Stack Forge community) > 6) Reset our branching/versioning into something predictable and > consistent > 7) Change the installation paradigm to be more consistent with best > practices. This likely means NOT including all the dependencies into the > Crowbar ISO build and relying on the user to supply Internet access or a > local repo/mirror. > > These changes are opportunities for use to make it easier for everyone to > participate in Crowbar and the current state inhibits our forward progress. > We've got a gem in the Crowbar updated code base, now it's time update the > infrastructure around it. I think that everybody agrees that the infrastructure is in desparate need of an overhaul but throwing everything existing out of the window and start from scratch feels like the wrong approach to me. -- Ralf _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
