I'm giving my own viewpoint - from outside the group working on the architecture - but I do have some experience with software projects.
Brian writes: > This cloud proposal is new and different, and it will redesign and > likely recode the existing VCL core. Although it seems different, Well, the first sentence says it is different. :-) > this experimental architecture is designed to accommodate the current > roadmap through a different architecture implementation. The > fundamental assumption is that the most reasonable way to implement > the roadmap outlined here > (http://cwiki.apache.org/confluence/display/VCL/Future+Development+topics ) > is have the VCL core become resource agnostic. I believe that a resource > agnostic VCL core can schedule fluid resources more flexibly by revising > the daemon portion of the VCL architecture to be event driven. This > modification allows the core to be resource agnostic and schedule a > variety of fundamentally different resources through the use of resource > specific resource managers. This is IMHO a very desireable goal, and I think that we have widespread agreement on that. We've already been moving towards this goal in the 2.X code base - but via incremental changes rather than through a radical redesign/restructure/recode effort. So, to me, the question is of the route(s) we take rather than disagreement over the long term goal(s). > Moreover, with the 2.X code base, [... discussion of limitations of 2.X and > desired aspects of the new architecture] Given that we're trying to release a 2.X version with increased functionality and with increased ease of bringing into production (which is *very* important as the number of adopters increases) it seems sensible to me to focus on 2.X. Aaron has discussed the importance of this, especially considering the limited development resources. Does this mean we should abandon work on this new version (I'll call it 2.D with D for different)? No, IMHO. But neither do we need to take it on as an urgent project. We (the entire VCL community) have the time to scope it out carefully and to have a good discussion of the requirements, tradeoffs, implementation approaches, etc., as Josh has suggested. We'll also have discussed the roadmap for progress - e.g. whether there should be a fork in the code. Then, when development resources (people) become available we'll be ready to proceed in a very productive manner. > I'd like to suggest the reuse of the existing API enabled VCL 2.X code > base as a bare-metal resource manager, which can be driven by this > experimental branch of VCL code. ... This sound to me like the type of discussion that should be going on. --henry
