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

[Andrew Jeffery]

On Mon, 4 Mar 2019, at 15:01, krtaylor wrote:
> 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.

Great! Looks like I misread it (possibly not helped by lacking context). Thanks
for clarifying, and thanks for your work on improving communication around
feature development.

Andrew

> 
> Thanks for your feedback,
> Kurt (krtaylor)
>