On 12/02/2013 11:41 AM, Thierry Carrez wrote: > I don't really care that much about deprecation in that case, but I care > about which release the new project is made part of. Would you make it > part of the Icehouse common release ? That means fast-tracking through > incubation *and* integration in less than one cycle... I'm not sure we > want that. > > I agree it's the same code (at least at the beginning), but the idea > behind forcing all projects to undergo a full cycle before being made > part of the release is not really about code stability, it's about > integration with the other projects and all the various programs. We > want them to go through a whole cycle to avoid putting unnecessary > stress on packagers, QA, docs, infrastructure and release management. > > So while I agree that we could play tricks around deprecation, I'm not > sure we should go from forklifted to part of the common release in less > than 3 months. > > I'm not sure it would buy us anything, either. Having the scheduler > usable by the end of the Icehouse cycle and integrated in the J cycle > lets you have one release where both options are available, remove it > first thing in J and then anyone running J (be it tracking trunk or > using the final release) is using the external scheduler. That makes > more sense to me and technically, you still have the option to use it > with Icehouse. >
Not having to maintain code in 2 places is what it buys us. However, this particular point is a bit moot until we actually had it done and working. Perhaps we should just revisit the deprecation plan once we actually have the thing split out and running. -- Russell Bryant _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
