2.7 Release Planning Guidelines - Features, Designs and Milestones

[krtaylor]

On 3/3/19 5:16 PM, Andrew Jeffery wrote:
> 
> 
> 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"?

We are a new open source project that has all the typical communication 
problems of teams that are not used to sharing what they are working on 
now having to. It can't wait until they are ready to drop a huge chunk 
of code. We are working toward breaking that cycle by starting early 
sharing what we are working on (features). Then we will get more detail 
(designs) and get needed feedback in the design reviews. When code 
starts dropping (incrementally), everyone knows about what is being 
delivered, and how the group intends on it functioning. This is about 
communication and cooperation, not 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

Exactly what we are doing. The label is for release intention.

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

Our release cycle is based on fixed dates, as are many other open source 
projects. Unlike product release cycles, we will not slip a date to 
finish a feature. If you miss the release train, you simply catch the 
next one.

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

If someone if working on a new feature that has not been added to 
github, then they need to talk to their release planning rep and get it 
entered, or just add it themselves. The last thing we need is to 
duplicate work. Again, this is about communication and cooperation, not 
control.

Thanks for your feedback,
Kurt (krtaylor)