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

Reply via email to