=?UTF-8?Q?Re:_2.7_Release_Planning_Guidelines_-_Features, _Designs_and_Mi?= lestones

[Andrew Jeffery]

On Sat, 2 Mar 2019, at 03:47, krtaylor wrote:
> 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.

What is the scope of these features? My gut instinct is it's something like
"high-level capability that OpenBMC does not yet have" as opposed to
"useful feature in existing platform-specific tool". Is there a description
somewhere of where we're drawing the line? I guess my question can
be rephrased as "what are we (explicitly) _not_ trying to control"?

> 
> 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.

I haven't been attending the release planning meetings; maybe I'm a bit
under-informed/out of line so take this with a grain of salt. However:

This all seems like a top-down attempt to manage a large-ish open source
project. Given everyone's diverse interest as a means to scratch their own
itch, I feel like the kernel's approach is something that we should be
modelling: Releases occur on a fixed cadence, and whether a feature makes
it into a given release is largely dictated by whether the maintainer of a given
subsystem feels its ready to go in rather than whether a particular label is
applied to a github issue. Having timed releases dictating included features
rather than features happening to land in a given timed release leads to
problems like serious slippage of release dates or merging of immature
features simply to meet the promised deadline. Best for things just to go in
when they are ready. If people need to ship the feature before it is integrated
upstream then the responsibility and burden is on their own (probably
internal) fork of the project. It's not something upstream should be saddled
with.

I'm not arguing against having designs or code freezes, but I am concerned
about language like "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". It has a distasteful dictatorial ring to it for an open source project,
and to me it's a bit demotivating. Maybe that's not how it was intended?

Andrew