Any convention on putting source codes into openbmc/openbmc repository

[Patrick Williams]

On Thu, Feb 18, 2021 at 05:23:56AM +0000, Joel Stanley wrote:
> On Thu, 18 Feb 2021 at 01:31, Thang Nguyen <thang at os.amperecomputing.com> wrote:
> >
> >
> > On 18/02/2021 06:46, Nancy Yuen wrote:
> >
> > Code should be put into an appropriate repo, and repos created where necessary.  Then referenced in recipes from openbmc/openbmc metalayers.
> >
> 
> It's a requirement.

My opinion is that there are two reasons that come to my mind on why we
follow this convention right now beyond just that Yocto is happier with it:

    1. We like to have a discussion before making a new repository to
       make sure we're not fragmenting the codebase more than necessary.
       Often problems/solutions overlap more than might seem obvious
       when you're looking at it just from your machine or architecture's
       perspective.  There may be some existing implementation that
       could be modified slightly to make it fit your needs, or it could
       be that someone else has the same problem and would like to work
       with you on implementation.

    2. All of our CI infrastructure is set up where machine recipes go
       in openbmc/openbmc and code goes in various code repositories.
       If you try to put code directly into openbmc/openbmc you do not
       gain any of those CI efforts we already have:
            * Build of your code and unit tests when someone
              makes a code change.
            * Unit test execution.
            * Code formatting.
            * Static code analysis.
       We have a lot of support at a repository level that doesn't exist
       in openbmc/openbmc directly, because it isn't approriate for what
       is there.

Hopefully this gives you some additional context on why.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20210220/f649da2e/attachment.sig>