Open Stack

On 2019-02-27 11:07:44 -0600 (-0600), Ben Nemec wrote:
> On 2/27/19 10:36 AM, Jeremy Stanley wrote:
> > On 2019-02-27 11:23:19 -0500 (-0500), Zane Bitter wrote:
> > [...]
> > > the resolution says we should unit test "[e]ach Python 3 version
> > > that was still used in any integration tests at the beginning of the
> > > development cycle"
> > [...]
> > 
> > Now I'm getting worried that the phrasing we settled on is leading
> > to misinterpretation. The entire point, I thought, was that we
> > decide at the beginning of the development cycle on which platforms
> > we're testing, and so choose the most recent releases of those LTS
> > distros. If some projects were still running jobs on an earlier
> > platform at the start of the cycle, I don't think we need to be
> > stuck maintaining that testing. The beginning of the cycle is the
> > point at which it's safe for them to switch to the agreed-upon
> > current platform for our upcoming release under development.
> > 
> 
> Part of the problem is that this didn't actually happen at the
> beginning of the cycle. The current plan is not to finish the
> legacy job migration until Apr. 1[0], which means until then
> projects may have a dependency on py35.
[...]

In the past, the way it worked was at the beginning of a new cycle
the Infra team said "there's a new Ubuntu LTS release and we have
working images for it, you all need to move your jobs to it before
the end of the cycle." (Or we just set a date when we were going to
switch everyone's jobs over and it was up to them to fix them if
they didn't do so before the deadline.) This time the Infra team
left it up to the TC to decide on the plan and messaging, so as
committee design tradition dictates we spent half the cycle just
coming to the conclusion we'd do pretty much what we've done in past
cycles. This of course has left teams with far less time to actually
implement a transition, and as a result it's overlapping with their
attempts to prepare the release.

The key is determination of the platform occurs as early in the
cycle as possible so teams have an opportunity to get it all working
before doing so impacts finalizing their release. Hopefully now that
the plan is baked, we can avoid similar delays for instating future
testing platform transitions. I don't think that the delay this time
should necessarily inform our policy for future iterations.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190227/73496cf9/attachment.sig>