Russell Bryant wrote: > 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.
Agreed. My position on this would probably be different if the forklift had been completed one month ago and we had 5 months of 'integration'. With the current timing however, I think we'll have to have the code in two places by the icehouse release. That said, if we mark the nova-scheduler Icehouse code "deprecated" and remove it early in J, the dual-maintenance burden is limited. The only obligation we'd have would be security backports, and the scheduler has been relatively vulnerability-free so far. -- Thierry Carrez (ttx) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev