Swampd PID-driven Fan Controller

[Patrick Venture]

On Thu, Jul 6, 2017 at 9:14 AM, Patrick Williams <patrick at stwcx.xyz> wrote:
> 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.

My plan is to work on integrating it in.  I've been preoccupied lately
with an upcoming deployment of OpenBMC: so basically all other things
are temporarily back-burner-ed.

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

I have to reach out to the legal team to see if that's feasible.
There are guidelines for publishing to the Google owned repos, and
guidelines for personal open source projects, but not quite this type
of hybrid where it's non-personal project but isn't aiming to live
outside of the Google namespace.  So, i'll reach out and figure it
out.

>
>    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?
>
It sounds workable.

> --
> Patrick Williams