Thread titleRepliesLast modified
Supporting short timeframe before feature freeze020:12, 13 January 2017

Supporting short timeframe before feature freeze

There was thought given on the mailing list to the possibility of having an overly long review process push a new feature (requiring a dependency bump) past the feature freeze.

I don't think it makes sense for our engineering review timeframes to change based on proximity to feature freeze -- if we can support a quicker review, the mandatory review timeframe should be that short all the time, not just when feature freeze is near (after all it's not like we get extra personnel contributing only in those 1-2 week windows).

However the crux of the requirement is to support CI, not feature freeze, so I think it would be suitable to say something like: "if the new dependency can be conditionally-detected and compiled, that the new feature and dependency bump could be submitted into the code repository (in time to make the feature freeze) even while the sysadmins add their comments and/or plan how to deliver the dependency in the meantime." In other words, as long as other code review requirements are met, the full sysadmin approval timeframe would only be needed when the dependency is mandatory in the source code.

We should still include the requirement for sysadmins to be noticed for dependency changes (even optional ones) since we will want to ensure that the CI provides its testing against the software configurations we intend for the user to use. But I think allowing flexibility in how long the dependency can be blocked based on whether it's mandatory or not can work well for all involved.

Mpyne (talk) 20:12, 13 January 2017 (UTC)

20:12, 13 January 2017

This page was last edited on 13 January 2017, at 20:12. Content is available under Creative Commons License SA 4.0 unless otherwise noted.