Re: 2.9 planning/progress docs?

[Patrick Williams <patrick@stwcx.xyz>]

[-- Attachment #1: Type: text/plain, Size: 3173 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]