+1 I'd like to bring in a different (workload) repo structure. CB2 has little structural overlap with CB1. The code in the cookbooks can be ported/preserved but not much else.
From: Judd Maltin [mailto:j...@newgoliath.com] Sent: Wednesday, November 20, 2013 10:01 AM Central Standard Time To: Adam Spiers <aspi...@suse.com> Cc: Dearborn, Chris; crowbar; Hirschfeld, Rob Subject: Re: [Crowbar] Crowbar 2 Hack Report All the branching doesn't address the confusing situation for newbies who we are trying to attract to the project. Since we'll be leaving a huge portion of the 1.x codebase behind for good and forever, I think the gains of making it easy for newbies to join FAR outweighs branching and cleaning up. On Wed, Nov 20, 2013 at 9:52 AM, Adam Spiers <aspi...@suse.com<mailto:aspi...@suse.com>> wrote: christopher_dearb...@dell.com (christopher_dearb...@dell.com) wrote: > Rob, > > I think you misunderstood my recommendation below. What I'm > proposing is that we branch everything, including the main Crowbar > repo. I think I'm on the same page as you here Chris, although the above statement makes it sound like a much bigger deal than it actually is! All the barclamp repos are already branched, so all that needs to be done is to branch the main repo, and split out non-release-specific stuff. (I have been advocating for both of these actions for a long time.) There would be NO risk of destabilising CB1, because that's exactly the use case (git) branches were invented to handle in the first place. > 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. Correct. Furthermore I have not yet heard any proposals how to address the numerous concerns I raised about creating a second organisation (quoted again below for reference). On the flip side, the only disadvantage I can think of caused by keeping a single org is that people can't trivially choose how to be notified at per-release granularity. However this seems to be achievable via RSS: http://stackoverflow.com/questions/7353538/setting-up-an-github-commit-rss-feed Hopefully we can iron this all out in 70 minutes from now. To anyone who intends to participate in the discussion, it would be very helpful if you could glance over this first: http://crowbar.sync.in/crowbar-repos > Rob Hirschfeld <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<mailto: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/
