[OE-core] [PATCH 1/3] go: Add recipes for golang compilers and tools

[Maciej Borzęcki]

On Sun, Feb 12, 2017 at 8:36 AM, Khem Raj <raj.khem at gmail.com> wrote:
> On Wed, Feb 8, 2017 at 6:00 AM, Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
>> On Tue, 2017-02-07 at 17:35 +0000, Burton, Ross wrote:
>>>
>>> On 7 February 2017 at 04:24, Khem Raj <raj.khem at gmail.com> wrote:
>>> > This is converging the recipes for go from
>>> > meta-virtualization and oe-meta-go
>>> >
>>> I'm still of the opinion that this should be in meta-go, not oe-
>>> core...
>>>
>>> (but totally agree that converging is essential)
>>
>> I've just been reading the various responses.
>>
>> The benefit of core would be that it would get included in some of the
>> core test builds/coverage and that we've have the maintainer structure
>> that core has to help ensure patches get merged, if that has been a
>> problem in the past.
>>
>> The downside is more pressure onto the OE-Core maintainers in various
>> ways.
>>
>> I would like to see the duplication removed and have one good solution
>> for it. If adding it to core is how we achieve that, great, I can work
>> with that (and we can always split it out again) but I'm open to other
>> ideas too, if they can work...
>
> There are more layers which are using go for application development
> e.g. meta-mender etc. I think ecosystem will benefit if it was in
> OE-Core and second best solution would be to start a layer e.g.
> meta-go on yp.org. I am fine with either approach in that order.

Alternatively, I think that OE maintainers would not mind carrying
meta-go in their meta-openembedded. There's already a couple of
important languages there (eg. Lua, albeit in meta-oe) and a number of
language specific layers (meta-python, meta-ruby, meta-perl). There's
additional benefit of being included in 'bitbake world' jobs.

-- 
Maciej Borzecki
RnDity