2.7 Release Planning Guidelines - Features, Designs and Milestones

[krtaylor]

All,

At the last release planning meeting we agreed to start enforcing the 
design requirement for 2.7 release features. This gives the repo 
maintainer the authority to not merge major contributions without 
designs in place. Of course, the maintainer also has the discretion to 
"grandfather" in work that was previously underway that had designs 
socialized in IRC or email. I think having these designs in place will 
fix a lot of the release notes concerns, as well as level-setting what 
we're all working on.

TLDR: if work has a feature issue created in github (tagged Release2.7), 
it MUST to have a design template filled out in order to be merged.

Second, we agreed to set a VERY aggressive schedule for having all 
feature issue designs in place: *March 25th*  Obviously, that means that 
release feature issues need to be completed before then.

Third, we also agreed to establish checkpoints for delivery of features 
so we can check the feature progress, seek community assistance, etc. We 
will establish Design, Code1, Code2, Freeze and Release milestones. They 
are mostly self-explanatory, with Code1 and Code2 being used for staging 
dependent work for instance. They will be approximately 6 week intervals.

Finally, I am asking for EVERYONE'S help in making sure what you are 
working on falls into a openbmc/openbmc issue tagged Release2.7 (or 
Release2.8 for long-running projects). If not, and it is not a quick fix 
or small enhancement, please let your release planning rep know and help 
them get the feature issue created ASAP. Check here: 
https://github.com/openbmc/openbmc/issues?q=is%3Aopen+is%3Aissue+label%3ARelease2.7

As always, I am available for any questions. Find me on IRC or come to a 
release planning meeting and let's discuss.

Kurt Taylor (krtaylor)