Request for a development repo

[Tanous, Ed]

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

This would be a repository for our WIP.  One repository, yes, unless in the future it makes more sense to split along certain architectural lines, but at this point I think one will do.  I'm happy to work with others if they would like to share the repository, or work together on components, but at the end of the day, my engineers need a sandbox where they can develop in the open.

No, submissions will not be accepted unconditionally;  This is not an attempt to skirt coding style, language choice, or any large architectural rules.  This is an attempt to get a repository that my engineers can check into and get code review approval from a maintainer in quick order, for components that meet our needs without a hard fork of the codebase.  Once proven to be viable and useful to the community, they could transition to a full repository, with all the discussions that entails.

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

The vibe I'm getting (from the lack of responses) is that a 01.org fork isn't desired.  I completely agree, I just wanted to throw it out there as an option.

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

Long term, absolutely, but I don't think we're at a critical mass to the point where we can really define 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.

We'd likely still be having this discussion, although from a different viewpoint.  I don't think every RFC needs a repo, nor am I arguing that you should've created repos for the WIP that we've been pushing.  The act of actually creating the repo is less important than the fact that we seem to be struggling to foster discussions around architectural decisions.  In the lack of consensus, we need to continue moving toward the goal of building something product worthy.

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

Just to be clear, your point #2 is exactly what we're trying to do with this request.  I'd really like to discourage the private forks that most organizations have at the moment, and define a process that lets us get more code in the open so we can have technical discussions about the merits and demerits of everyone's solutions.
Just to be clear, I'm in no way arguing you haven't done your job here, and I think that the guidelines above are a great starting point for defining your role in this project.

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