Request for a development repo

[Brad Bishop]

On Thu, 2017-12-21 at 13:41 -0800, Patrick Venture wrote:
> On Thu, Dec 21, 2017 at 11:16 AM, Tanous, Ed <ed.tanous at intel.com>
> wrote:
> > In the hope of being more open with our development process, we’d
> > like to
> > create a repo for hosting work-in-progress applications, and
> > applications
> > that don’t really fit into the other repositories.  Internally, we
> > have such
> > a repository, informally named proving ground, where we try to
> > build out
> > concepts to test new applications, modes, and put the things that
> > are
> > specific to our platform that don’t really fit anywhere else.  An
> > example of
> > a component that would be contained in here would be this:
> > https://gerrit.openbmc-project.xyz/#/c/8197/
> > 
> > 
> > 
> > With the goal of being more open, we’d like to find a way to make
> > these
> > prototypes available to the community sooner, and have our machine
> > targets
> > build some of the components while still in development.  The
> > options we’ve
> > considered thusfar are:
> > 
> > 
> > 
> > 1.       Acquire a repository under github/openbmc, possibly called
> > intel,
> > possibly called something more company agnostic.  Here we would put
> > our
> > prototypes, and things that we would like to enable on our
> > platforms.
> 
> I vote for this option with a more generic name.  It would be handy
> since a lot of new daemons or work has nowhere to really be staged.

How would this work exactly?  Would there be one repository for the
whole project where any submissions are accepted unconditionally?  Or
are we driving at providing a repo to organizations and/or individuals
that they maintain?

I'm probably sounding critical of the idea...that isn't the intent -
just wanting to understand where we are headed.

> 
> > 
> > 2.       Start our own repository on 01.org (Intels open source
> > repository)
> > and simply make our platform recipes in openbmc point to it.
> > 
> > 3.       Create repositories for each component under openbmc, and
> > define a
> > faster SLA and process for requesting new repos.

In the longer term this would get my vote.  But I still think we need
to do something to enable you in the short term, until someone proposes
a process.

You mention a faster SLA and I want to touch on that because I think it
is important.

I'm reading between the lines a bit, but I'd guess if I'd created a
repository for the project you reference above within a couple days of
the submission (along with a couple other RFCs) we wouldn't be having
this conversation.

For better or worse, I am the maintainer of this project (at the moment
anyway :-)).  Let me share what I think this role means because I think
its informative here.

My role is to ensure that:
 - contributors to the project have a voice.
 - participation and collaboration occurs transparently (open).
 - contributions make the project better for the most number of people.

If someone submits an RFC, and I just create a repository, I've done
none of those things.  I honestly have very little motivation to hold
up any contributions based on technical merit alone.  What I want to
see is evidence of the bullet points above.

I'm perfectly happy to personally work myself to ensure these things
are being done for contributions from others, but that _will_ be a high
latency process.  To make it faster, contributors themselves can
solicit support for their ideas from others by asking them to review
code, vocalize their support on the mailing list, etc.  People that
helped shape the proposed code/design/idea behind closed doors don't
count imho - that would just be a rubber stamp.

Does this insight help any with the problem we are trying to solve with
the proposed proving-ground?

Sorry for the book - thoughts welcome.

> > 
> > 4.       Continue with our internal fork, and publish prototypes to
> > repositories once they fit some definition of “done”.
> > 
> > 
> > 
> > My personal preference would be #1, but I’m curious if anyone has
> > any
> > thoughts on other opinions on how this should be done, or have
> > better
> > options that we haven’t thought of yet.
> > 
> > 
> > 
> > Thanks,
> > 
> > 
> > 
> > -Ed