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

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 
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 (



OpenStack-dev mailing list

Reply via email to