On Aug 28, 2014, at 12:14 PM, Doug Hellmann <d...@doughellmann.com> wrote:

> Before Juno we set a deprecation policy for graduating libraries that said 
> the incubated versions of the modules would stay in the incubator repository 
> for one full cycle after graduation. This gives projects time to adopt the 
> libraries and still receive bug fixes to the incubated version (see 
> https://wiki.openstack.org/wiki/Oslo#Graduation).
> 
> That policy worked well early on, but has recently introduced some challenges 
> with the low level modules. Other modules in the incubator are still 
> importing the incubated versions of, for example, timeutils, and so tests 
> that rely on mocking out or modifying the behavior of timeutils do not work 
> as expected when different parts of the application code end up calling 
> different versions of timeutils. We had similar issues with the notifiers and 
> RPC code, and I expect to find other cases as we continue with the 
> graduations.
> 
> To deal with this problem, I propose that for Kilo we delete graduating 
> modules as soon as the new library is released, rather than waiting to the 
> end of the cycle. We can update the other incubated modules at the same time, 
> so that the incubator will always use the new libraries and be consistent.
> 
> We have not had a lot of patches where backports were necessary, but there 
> have been a few important ones, so we need to retain the ability to handle 
> them and allow projects to adopt libraries at a reasonable pace. To handle 
> backports cleanly, we can “freeze” all changes to the master branch version 
> of modules slated for graduation during Kilo (we would need to make a good 
> list very early in the cycle), and use the stable/juno branch for backports.
> 
> The new process would be:
> 
> 1. Declare which modules we expect to graduate during Kilo.
> 2. Changes to those pre-graduation modules could be made in the master branch 
> before their library is released, as long as the change is also backported to 
> the stable/juno branch at the same time (we should enforce this by having 
> both patches submitted before accepting either).
> 3. When graduation for a library starts, freeze those modules in all branches 
> until the library is released.
> 4. Remove modules from the incubator’s master branch after the library is 
> released.
> 5. Land changes in the library first.
> 6. Backport changes, as needed, to stable/juno instead of master.
> 
> It would be better to begin the export/import process as early as possible in 
> Kilo to keep the window where point 2 applies very short.
> 
> If there are objections to using stable/juno, we could introduce a new branch 
> with a name like backports/kilo, but I am afraid having the extra branch to 
> manage would just cause confusion.
> 
> I would like to move ahead with this plan by creating the stable/juno branch 
> and starting to update the incubator as soon as the oslo.log repository is 
> imported (https://review.openstack.org/116934).

That change has merged and the oslo.log repository has been created.

Doug

> 
> Thoughts?
> 
> Doug
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to