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.