2.9 planning/progress docs?

2.9 planning/progress docs?

[Garrett, Mike (HPE Server Firmware)]

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

Hello,

Is there a good place to find the 2.9 change list, both in progress and planned?  For instance, I noticed a lot of change occurring in the dbus-sensors repo, but I'd like to see what master plan is guiding these commits and when they are "done" for 2.9.  I know things might be more fluid than that, but if there is a doc, I'd like to keep an eye on it.

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.

Thanks,

Mike

[-- Attachment #2: Type: text/html, Size: 2751 bytes --]

Re: 2.9 planning/progress docs?

[Ed Tanous]

On Mon, Jul 27, 2020 at 8:22 AM Garrett, Mike (HPE Server Firmware)
<mike.garrett@hpe.com> wrote:
>
> Is there a good place to find the 2.9 change list, both in progress and planned?
>

Frankly, no.  There is an official changelist that has been attempted
in the past (and might still be going), but we as a project have had
trouble in this area as people seem more motivated to build out
featuresets than document and schedule said building of them.  Also, a
number of the organizations (including the one the dbus-sensors
maintainer works for) have a "live at head" philosophy when it comes
to master.

>  For instance, I noticed a lot of change occurring in the dbus-sensors repo, but I’d like to see what master plan is guiding these commits and when they are “done” for 2.9.  I know things might be more fluid than that, but if there is a doc, I’d like to keep an eye on it.
>
>
>
> 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.
It should be noted, the dbus-sensors repo is set up to intentionally
separate the platform specific configuration things (how many
drives/slots/sockets/cores ect) that can't be made public yet from the
generic implementation in code for a given exposes record.  The hope
is that the C++ daemon code can be put into review as it's built, and
the config files can be followed on later (once the product is
released), thus avoiding most of the merge conflicts.

Re: 2.9 planning/progress docs?

[Andrew Jeffery]

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

Re: 2.9 planning/progress docs?

[Patrick Williams]

[-- 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 --]

RE: 2.9 planning/progress docs?

[Garrett, Mike (HPE Server Firmware)]

Thanks for the clarification Patrick and all.

-----Original Message-----
From: Patrick Williams <patrick@stwcx.xyz> 
Sent: Monday, November 2, 2020 4:38 PM
To: Andrew Jeffery <andrew@aj.id.au>
Cc: Ed Tanous <ed@tanous.net>; Garrett, Mike (HPE Server Firmware) <mike.garrett@hpe.com>; openbmc@lists.ozlabs.org; kurt.r.taylor@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@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