Request for a development repo

[Xo Wang]

On Fri, Dec 22, 2017 at 2:45 PM, Brad Bishop
<bradleyb at fuzziesquirrel.com> wrote:
> 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.
>

I wouldn't mind seeing seeing repos where the conventions of (a)
centralized code reviews and (b) one-project-per-repo are broken, so
long as they don't directly affect the main OpenBMC builds (i.e. are
not being nightly updated into the build) and they're intended to
eventually have a stable home.

I don't see much value in naming it according to a contributing
organization, even if most development efforts are de facto "owned" by
some company or group or other. The point is that you want unilateral
(ish) control over some code hosted on the OpenBMC GitHub organization
that other people can observe, review, and patch, right? It might help
to achieve your goal of openness to organize these looser repos by
their feature area than according who their controlling contributors
are.

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

xo