Furthermore, since every administrator I talk to asks me "Isn't Crowbar a Dell-only project," I think it's a good idea to embrace the OpenCrowbar project name.. much as SUSE is recognized by OpenSUSE, even in the press http://linux.slashdot.org/story/13/11/19/2353236/opensuse-131-released-and-reviewed .
Finally, there is so much documentation debt in the wiki, I'd be very happy to just cut it loose. On Wed, Nov 20, 2013 at 11:01 AM, Judd Maltin <j...@newgoliath.com> wrote: > 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> 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 >> 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? > > > -- 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/
