I'm giving my own viewpoint - from outside the group working on the
architecture - but I do have some experience with software projects.
> 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.