That all makes sense to me. Doug Hellmann 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). > > Thoughts? > > Doug > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
-- Thierry Carrez (ttx) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
