On Wed, Aug 15, 2012 at 6:51 PM, Will Chan <will.c...@citrix.com> wrote: > > >> -----Original Message----- >> From: Sheng Liang [mailto:sheng.li...@citrix.com] >> Sent: Wednesday, August 15, 2012 3:41 PM >> To: cloudstack-dev@incubator.apache.org >> Subject: RE: [PROPOSAL] Breaking CloudStack into subprojects >> >> > Let's take the Netscaler AutoScale feature currently being >> > implemented. I'm sure they must be at least touching the API, UI, some >> Resources layer and DAO layer. If they were committers, do they have to >> have been invited to all 4 of those subprojects? >> >> This is precisely the type of problem exposed by the separation. We need to >> address these problems head-on and not try to prolong a large monolithic >> system. >> >> Once we have clean separation of projects developers will be naturally >> inclined to maintain the separation. Autoscaling should ideally be its own >> project and not require changes to core CloudStack functionalities. >> >> Sheng > > What you suggest makes sense but I don't think we are quite there yet. Alex > is proposing we assign committers to each of the jar files (defined by him as > a subproject) that are currently being created today. That seems a bit > burdensome to me especially when we already have a maintainer system setup to > review changes and commit patches. > > Will >
I think we're talking about two different things: First, the architectural approach to the software. Second, the organizational approach to managing the software. For the architectural side of things, I'm a fan of Kelvin's comments on a separate thread. We should probably shift that discussion over to respond to Kelvin. For the organizational issues, I am very much against making multiple projects. I'm using the term project *very* specifically here: ASF project / sub-project. We can certainly revisit this at a later time, but I don't think we have a large enough community of active participants to truly break up into different sub-projects. As it stands right now, I can see myself only agreeing to sub-projects if there was an explicit agreement that only the "top level project" (i.e.: CloudStack) was allowed to perform an official release for the child components. (reserving the right to evolve my opinion) I completely understand Alex's concern (all the more so, knowing how intimate he is with the product as a whole). This is complex system, and I've experienced a similar issue acting in that role for internal projects in the past. One person can't be the expert in all layers / modules. Adding to this: regardless of how clean we separate the layers, many features will still have to have code that slices vertically through the architecture. The way to deal with this is to think about the role Alex stepped up for a bit differently. It shouldn't be his responsibility to personally *approve* with all changes. Instead, being the release branch "gatekeeper" should be a semi-technical and semi-administrative function. Clearly using his own knowledge to verify patches is of significant value to the project, but the administrative function is to ensure that (1) the commits have been tested, (2) the appropriate developers have reviewed the commits, (3) communicate with the community if there is a reason to keep something out of the release branch so that we can ensure a consensus driven approach to decisions. For identifying the appropriate reviewers of any commit (point 2 above), we have already established a "maintainer" list [1] that I think we have already agreed to. Alex should be leaning heavily on the people mentioned in that list! -chip [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Maintainers+Guide
