Dear Vincent, I for one do not believe that CB1 is end of life. I think there is still good value in the product, strong commit-stream or not. Just the way it is it is still far ahead of our nearest competition. It was two years ahead of the pack two years ago, and it still remains still far ahead. It is not dead.
Again, speaking only for myself, it seems to me that with the design of Crowbar 2, we aim to take another leap two years ahead. Most folks on the team do not speak the way I do because they are far less dreamy and far more practical. It is urgent for us to put as many resources as possible towards the solid release of Crowbar 2. We do not have the resources to accomplish a tear-down and rebuild of the Crowbar 1 infrastructure without getting in the way of the amazing stream of PRs and products that can be created from Crowbar 1. -judd On Wed, Dec 18, 2013 at 5:31 AM, Vincent Untz <vu...@suse.com> wrote: > Hi Rob, > > Your mail seems to indicate that Crowbar 1.x has reached the end of its > life. This makes me really sad: I think we're proving this view is wrong > on a daily basis, as you can see with the amount of changes going in > Crowbar 1.x. I dare to say that its development has never been so fast, > and we're improving it in an iterative way. > > Also, I can only repeat one more time that I totally fail to understand > the reasons to move to another github org. You're mentioning that > without this, it would "require substantial investment in Crowbar 1 > infrastructure, to update and test". I beg to disagree here. It's only a > matter of creating branches in the toplevel crowbar repo. Can you > clarify what is substantial in doing that? It doesn't even have to > require huge changes in the ./dev workflow. > > What's really worrying to me, though, is that your suggestion might lead > to a split in the community. Our community is not that big, and I don't > think we can afford it. > > Cheers, > > Vincent > > PS: also +1 on Ralf's comment about "Open Crowbar". We've been working > on the Crowbar project all together -- it's already open! > > Le mardi 17 décembre 2013, à 23:22 -0600, rob_hirschf...@dell.com a écrit > : > > 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 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. > > > > 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. > > > > Rob > > ______________________________ > > Rob Hirschfeld > > Sr. Distinguished Cloud Solution Architect > > Dell | Cloud Edge, Data Center Solutions > > cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle > > Please note, I am based in the CENTRAL (-6) time zone > > > > > _______________________________________________ > > Crowbar mailing list > > Crowbar@dell.com > > https://lists.us.dell.com/mailman/listinfo/crowbar > > For more information: http://crowbar.github.com/ > > > -- > Les gens heureux ne sont pas pressés. > > _______________________________________________ > Crowbar mailing list > Crowbar@dell.com > https://lists.us.dell.com/mailman/listinfo/crowbar > For more information: http://crowbar.github.com/ > -- Judd Maltin T: 917-882-1270 F: 501-694-7809 what could possibly go wrong?
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
