Simon Jakesch (simon_jake...@dell.com) wrote: > I've gone through the entire thread and I am going to make an > attempt at summarizing this conversation to flush out the most > burning and critical issues around this discussion. I've summarized > what I believe the high-level argument to be. Please everyone review > the list below (you will find many of your concerns), and confirm > that this captures everyone's concerns for now. Try framing any > uncovered concerns into the categories below. If there's nothing > more to add I believe we should move towards both: > > - Seriously exploring solutions to the problems that don't involve not > creating two organizations
Double negative! You mean "the problems that involve creating two organizations"? In which case how is this item different from this one? - > - Seriously trying to address the problems that would come with moving to a > new organization. Comments on the rest inline below ... > Developing (as newbie or veteran) is difficult/cumbersome for the following > reasons: > - Developing involves a huge number of github repositories with inconsistent > branching structure. > - The repositories contain a ton of cruft, as partially documented here: > http://crowbar.sync.in/crowbar-repos > - Developing requires learning a complex new tool [dev-tool] > - Documentation is scattered across multiple locations, and is frequently > duplicated and/or out of date. > > We want to make it easier and attract more people to help with the project so > we want to: > - collect Barclamps into larger "workload" repos (so the dev tool won't be > needed anymore) > - engage in a re-branding exercise on the organization name (OpenCrowbar vs. > Crowbar) Agree 100% with everything up to this point. > We can't do this without creating another Organization because: > - We need to avoid the clutter of Crowbar's current organization Disagree - "clutter" is an over-generalization. The only significant clutter is in the main repo and the wiki. > - It will be very hard to disambiguate CB1 information that's > accumulated and will be highly confusing for people trying to > learn either version Disagree - proper branching in the main repo would address this. > - We shouldn't/cannot touch the CB1 repos There is no such thing as "CB1 repos". There are CB1 branches. EXCEPT in the main repo, which is a big problem. Did I mention that already? ;-) > without a major investment > in validation that I think it wasted effort > > - There's risk of the cleanup messing with 1.x releases Disagree - proper branching in the main repo would avoid the need for ANY validation of CB1 when changes to CB2 are made. > - Adding more repos in the Crowbar org will only add to the "mess" > because we'll have that many more places for people to get lost The same is true with a new org. > - We need to counter the "isn't Crowbar a Dell-only project"-argument. > Therefore it's a good idea to embrace the OpenCrowbar project name.. much as > SUSE is recognized by OpenSUSE Growing the community would be far more effective than a rebranding exercise. > We believe potential benefits outweigh the risks: > - Doubling the number of places issues can be tracked > - Causing confusion over which wiki should be used > - Which repo should host the website > - Doubling the number of (push) access lists and subscriptions to be managed > - Not actually resolving any of the "newbie" confusion or even aggregating > the confusion on documentation > - search engine indexes not directing people properly Sorry, but you can exclude me from that "we". Complexity is already scaring away many newcomers, and introducing more will make the situation even worse. _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
