Re: 2.9 planning/progress docs?

[Ed Tanous <ed@tanous.net>]

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.