Rob, I think you misunderstood my recommendation below. What I'm proposing is that we branch everything, including the main Crowbar repo. See my responses to your points below.
At this point in time, I'm not seeing the benefit of creating a new org since everything that we want done can be done with branching, which would involve creating no new repos at all, while creating a new org would create duplicate repos of every one that we have today. Thanks, Chris Dell From: Hirschfeld, Rob Sent: Tuesday, November 19, 2013 7:57 PM To: Dearborn, Chris; aspi...@suse.com<mailto:aspi...@suse.com>; crowbar Subject: RE: [Crowbar] Crowbar 2 Hack Report On your -1. I'm certain that we can create new CB2 repos that address issues in Crowbar 1; however... · We shouldn't/cannot touch the CB1 repos without a major investment in validation that I think it wasted effort Ø I completely agree. I'm not proposing that we touch any Crowbar 1 repos other than main Crowbar repo. · 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 only repos that would need to be added would be repos that result from restructuring the root Crowbar repo, which could very well be no new repos at all. · It will be very hard to disambiguate CB1 information that's accumulated and will be highly confusing for people trying to learn either version Ø If we branched every repo, there would be no possibility of confusing CB1 information from CB2 information, since by definition, what's in the branch is what should be there for each version. I started from a similar distaste for the new org idea. Then I stepped back and thought about the challenges a n00b faces in starting w/ Crowbar. It's a serious effort to cleanup while both branches are being actively developed and I don't think we have the velocity to invest in cleanup. IMHO, our discussion needs to focus 1) what makes it easiest for new users to understand Crowbar and 2) what we have the velocity to do effectively. Note: I am not interested in any approach that risks the stability of the CB1 branches or requires extra investment to verify the stability of CB1 codebase for past releases. Ø Neither am I. From: crowbar-bounces On Behalf Of Dearborn, Chris Sent: Monday, November 18, 2013 6:58 AM To: aspi...@suse.com<mailto:aspi...@suse.com>; crowbar Subject: Re: [Crowbar] Crowbar 2 Hack Report I agree that we need to get rid of the releases dir in the root crowbar repo and begin branching all repos (including the root crowbar repo) per release. The way it is currently structured leads to collisions between releases. For example, Mesa and Roxy now require two different versions of Ubuntu 12.04, but because the root crowbar repo is not branched, it must be configured to build either one or the other. In my dev environment, I have to change symbolic links to point to the correct Ubuntu ISO whenever switching between Mesa and Roxy. Needless to say, this is very error prone, and if you do forget to change the links, you only find it when installing, which means at least an hour or two wasted. -1 on creating a new org. I would rather we clean up our current mess or at most create new repos. Thanks, Chris Dell -----Original Message----- From: crowbar-bounces On Behalf Of Adam Spiers Sent: Sunday, November 17, 2013 10:06 AM To: crowbar Subject: Re: [Crowbar] Crowbar 2 Hack Report Rob Hirschfeld (rob_hirschf...@dell.com<mailto:rob_hirschf...@dell.com>) wrote: > That's a clear +1 towards new Github Org to me. Hmm, that's not clear to me - possibly the way to go, but I think that would require a lot more thought first. For example it raises the question of how the two organizations should be named, doubles the number of places issues can be tracked, potentially causes confusion over which wiki should be used, and which repo should host the website. It also doubles the number of (push) access lists and subscriptions to be managed. The plus side of that is that commit rights and notifications could be per-release ... for *now*, but only until Crowbar 3, at which point it's not at all clear what would be the right path. A github org per release is WAY overkill. Another reasonable route is to create new repositories within the existing org. There are pros and cons to this too. A third route is simply to break out the top-level repo (and the dev tool with it) into more sensible chunks. That's the least invasive approach, and the one which I (and I think *probably* Victor too) had in mind when we discussed it. Whichever approach we take, we should be clear that creating a new github org or repos is not the silver bullet. The real hard work is doing the cleanup. That *must* include getting rid of the releases/ tree. I am absolutely convinced that the *only* way to go is to have strictly a git branch per release, with the branch names unified across all repos which contain any release-specific data, as detailed at <http://crowbar.sync.in/crowbar-repos>. It also must include removing unused cruft which currently achieves nothing except confusing people :) > That aligns with other discussions that generally say "thank goodness, yes!" > Anyone have objections or issues? I wouldn't be keen on seeing a new org until I'm clear about the answers to the above questions.
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
