On Thu, Aug 16, 2012 at 12:42 AM, 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. > Quite possible, however how many times does this actually occur in practice? And when commits do occur by a not so savvy developer in that unfamiliar region, is the outcome negative? If there is a problem will the problem be detected and is it possible to easily revert back? Erecting fences to guard against these potential problems incurs an additional administrative overhead. Not only must you manage the permissions you have to evaluate the abilities of the developers based on a per subproject basis. Before discussing what's common at Apache, let's talk more about the OS way. Erecting fences for the sake of greater control is dangerous. It divides the community to a degree, and it prevents natural migrations from one region of the source to another through the "scratch an itch" mechanism. CloudStack is not like an Apache Commons where everything is absolutely separable today. It maybe one day, but you want people working in one area to eventually move into other areas of the source. These fences will detract from these natural flows. Furthermore now you have different kinds of committers and a need to evaluate who can work on what. What's important here is the initial committer evaluation. You want a good open source citizen who knows their limits and is not going to start picking at everything without knowing anything about the code base. You need this trust. There are not many committers here at Apache that think they know everything and have the gaul to muck around in areas they have no clue about. Sure there can be a small degree of this, but it's small, isolated and you really need good unit and integration tests to protect against this. Finally you do want people to gradually start looking into areas they may not be very knowledgable in so they eventually become savvy. As for Apache, the majority of projects here at the ASF, regardless of the size and complexity of the code base usually grant all or nothing access to their TLP scope of sources in whatever version control system they use. We trust in our committers and don't take on committers that seem to lack the balance to know their limits. We may occasionally find ourselves having to go into areas of code we are not so familiar with but transparency, collaboration and communication on the mailing lists help ameliorate the possible negative impacts. Again unit and integration tests a key to give us the confidence to try things in areas that might be our core proficiency. This bolsters trust. Finally version control is helps correct any problems that might arise in seconds. Diligence is everyone's responsibility. > - 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. > > Yeah but you're talking about having to determine this apriori. You're going to have to give out expert badges eventually and do this evaluation: at least the PMC does. > 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. > > The Hadoop ecosystem, is no longer a single TLP project. It naturally grew out this way and so too might CS. Incubation, IMHO, is the wrong time to be trying to build these fences. > 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. This obviously helps, not only from a code configuration perspective, but from the ability to detect alterations on the code with commits to do the diligence. > 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. > > I agree with Jim Jag, highly recommending against this. It's not going to pay off and is a dangerous direction. I can understand previous corporate control mechanisms around release management being tempting, but in open source these control mechanisms are unnecessary and lethal. -- Best Regards, -- Alex
