Request for a development repo

[Tanous, Ed]

> -----Original Message-----
> From: Xo Wang [mailto:xow at google.com]
> Sent: Saturday, December 23, 2017 1:17 AM
> To: Brad Bishop <bradleyb at fuzziesquirrel.com>
> Cc: Patrick Venture <venture at google.com>; Tanous, Ed
> <ed.tanous at intel.com>; openbmc at lists.ozlabs.org
> Subject: Re: Request for a development repo
> 
> 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.

One of the goals with this repo is to enable these components in our platform (that's currently upstream).  Right now that platform (WFP) isn't in the build system, but at some point I would hope it is.

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

Unilateral control makes it sound like we want total control of the project.  Just to be clear, we want _some_ control over a sandbox so that we can build the components that we believe are needed for the WFP platform in upstream.  I'd be open to organizing by feature area rather than controlling contributors.  At the end of the day, the repo is just a name.  What matters is where the push/merge/commit permissions lie, and how quickly we can move on new features.