Previous history has shown that such "umbrella" projects (those with several sub-projects) are usually much more difficult to keep successful than a large project *or* a group of same-level top level projects.
So here's my -1 On Aug 15, 2012, at 5:42 PM, Alex Huang <alex.hu...@citrix.com> wrote: > After doing the merge over process one time, I realize something is wrong > with CS structure. We should think about fixing this. > > The problems I found are > > - I know nothing about the UI but I'm responsible for it. > - Someone who is a committer can actually check into areas they know > absolutely nothing about. > - As a release manager, I have no way of knowing whether someone doing a > checkin is actually an expert in that part of the code because of the above. > > So this reminded me of a conversation I had with Amr Awadallah, Cloudera's > CTO, when CS joined Apache incubation. I was picking his brains about how CS > should work in Apache given his experience with Hadoop. His suggested that > we break CS into multiple subprojects. We admit committers to the > subprojects based on their experience with that subproject. > > I like to see what's the community's response to a structure like that. > Through Murali's work, CloudStack has already been broken down into finer set > of plugins. We can start with every jar is a sub project with committers > assigned to them. It will take a little time to sort out but it will make > going forward a lot easier. > > Please comment. > > --Alex >
