Swampd PID-driven Fan Controller

[Patrick Williams]

On Wed, Jun 28, 2017 at 06:13:27PM -0700, Patrick Venture wrote:
> I would have liked to develop this in the open, but as you touched on
> it, schedules.  My platform is under a compressed schedule.  Under any
> situation, I'll be responsible for maintaining this code base.  And
> expanding it to support other platforms.  As implementing it wasn't
> done in a vacuum, I feel fairly confident that outside contributions
> at least in furthering the design to make it simpler or more modular
> would be warranted.
> 
> Obviously, it was designed around very specific execution
> requirements, which drove my adding an interval to phosphor-hwmon and
> quite a few downstream hacks.  That said, those specific execution
> requirements do have an impact on the ability to change the design
> from input.  If the design suggestions or ideas violate the terms of
> service that we're providing the data centers -- it can be forked,
> effectively.

Patrick,

It was hard to tell from your initial email if your intentions were to
just give away some code you wrote (hence Brad's fears of a "code dump"
approach) or if you were trying to get this integrated as a repo we
would maintain long-term.  After discussions off-list it sounds like you
are wanting to do the work to integrate this into OpenBMC proper, which
is great.

One way of reading your original email was that you were wanting to host
this and maintain it in your own space and then add a recipe for the
package to openbmc/openbmc.  Since this hasn't come up before, I should
probably say formally I am really opposed to this.  I see it as a
difficulty long-term for us to have a repository that links against
phopshor-dbus-interfaces and recipe in openbmc, but the code itself is
not able to be updated by us.  It is not uncommon that we need to change
the dbus schema and the developer doing that is also generally responsible
for the changes across the repositories using the schema.  Having this
other code outside the project but that the project also relies on to
build an officially supported machine would make a dbus schema change
pretty painful.

My suggestion would be that we tackle this code in a few phases:

1. Place code on Github in your personal account for a high-level review
   by interested parties.

   1a.  We can take a look and get a feel for what lines up with
        existing architecture and where one of us needs to make changes.

2. We create a Gerrit repo for this code to live in long-term and you
   submit any changes from phase 1 there.

   2a.  We will then do a review and revisions per our normal process.

3. After merge, the code is now an officially supported repo that we
   will expect others to help maintain as, for example, APIs change.

At any point here, if you decide it is not going to be worth the effort,
we can stop or someone else can pick up where you leave off.  Does this
sound workable?

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170706/9e65e70a/attachment.sig>