2.9 planning/progress docs?

[Garrett, Mike (HPE Server Firmware)]

Thanks for the clarification Patrick and all.

-----Original Message-----
From: Patrick Williams <patrick at stwcx.xyz> 
Sent: Monday, November 2, 2020 4:38 PM
To: Andrew Jeffery <andrew at aj.id.au>
Cc: Ed Tanous <ed at tanous.net>; Garrett, Mike (HPE Server Firmware) <mike.garrett at hpe.com>; openbmc at lists.ozlabs.org; kurt.r.taylor at gmail.com
Subject: Re: 2.9 planning/progress docs?

On Fri, Oct 30, 2020 at 03:45:07PM +1030, Andrew Jeffery wrote:
> 
> 
> On Tue, 28 Jul 2020, at 01:22, Ed Tanous wrote:
> > On Mon, Jul 27, 2020 at 8:22 AM Garrett, Mike (HPE Server Firmware) 
> > <mike.garrett at hpe.com> wrote:
> > > We have some patches for dbus-sensors specific to our platforms that are frequently being invalidated by updates upstream, and instead of constantly regenerating our patches, it would be nice to know when the upstream has accomplished its goals for 2.9 and we can regenerate our patches once.  We are still getting acquainted with the processes here.
> > >
> > 
> > The best answer here is to get your patches into review and onto 
> > master, then you shouldn't ever need to regenerate your downstream 
> > patches again.  Pushing a gerrit review is significantly less effort 
> > than even a single rebase, and you might gain some valuable insight 
> > from the maintainer doing so.  I understand the realities of that in 
> > the corporate world are not ideal, and sometimes you have technical 
> > conflicts that are hard to resolve, but at the very least if patches 
> > are "unmergeable" but in review, the maintainer can take this into 
> > consideration when other patches are merged, and possibly point out 
> > breaks.
> 
> Very late to the party here, but 100% on the above. As a maintainer 
> I'm not really prepared to cater to code I can't see - taking the time 
> to push your work to gerrit will get my attention, and:
> 
> 1. Help me appreciate your use-cases
> 2. Help you reduce your maintenance burden, and 3. Help others who 
> might share your use-cases.
> 
> It's always possible that others will pick your patches up and get 
> them merged for you.
> 
> Andrew

Good points Andrew.

It seems like in general we have a common misunderstanding about our release process.  Maybe Kurt can weigh in.

For the most part we have a time-based release cycle and not a feature-based release cycle.  This project isn't ran like some products where they say "we're not shipping this until feature X is done".  For the most part, people are not even able to effectively communicate what features they *are* working on and *when* they plan to have them done.

The Linux kernel also releases on a time-based release cycle.  There is no where to look up and answer "when will I be able to boot a kernel compressed with zstd compression?"  Someone decides they want to work on it, they put the code up, and eventually it finds its way into Linus'
tree during an open merge window.

Our releases have been pretty similar.  People work on code; code gets merged.  Eventually the upstream Yocto release happens and someone
(Kurt) volunteers to manage a corresponding OpenBMC release.  Whatever is in at that time, is what is in.

Maintainers of the individual code repositories have never managed a "closed" merge window in order to stabilze our code.  Code changes because someone contributes it and the code is approved for merge.
There will never be a particular point in time that a maintainer can tell you "I'm not going to merge code for the next month."

--
Patrick Williams