[Openembedded-architecture] patchwork (etc) support for BSP layers (OEDAM 2017)

[Denys Dmytriyenko]

On Tue, Mar 07, 2017 at 01:37:09PM +1300, Paul Eggleton wrote:
> Hi Trevor / all,
> 
> On Tuesday, 7 March 2017 12:59:53 PM NZDT Trevor Woerner wrote:
> > On Mon 2017-03-06 @ 09:03:32 AM, akuster808 wrote:
> > > On 03/05/2017 09:43 PM, Trevor Woerner wrote:
> > > > One of the items discussed over lunch at the recent OEDAM 2017, but that
> > > > I
> > > > can't find in the notes, was about including support for more layers in
> > > > patchwork.
> > > 
> > > I believe this was in the context of the sub layers in meta-openembedded.
> > > OE ( community)  could be driving that work, changes etc.
> > 
> > Funny... I remember it the other way around.
> > 
> > _I_ brought up this topic in the context of meta-rockchip and it was almost
> > immediately subverted by everyone wanting to talk about Tim Orling's
> > meta-openembedded split up work ...and here we are again :-(
> > 
> > So, ignoring Tim's work for the time-being, would it be possible for
> > "non-core" layers (maybe the layers found in the layer index?) to be added
> > to patchwork (and possibly benefit from other available Yocto tooling)?
> > 
> > When I brought this up RP immediately questioned whether BSP layers should
> > be hosted on git.yoctoproject.org. Then there was talk about financial
> > contributions. Then someone suggested the Raspberry Pi foundation might
> > want to fund some of this infrastructure for meta-raspberrypi. Then we
> > drifted into the meta-openembedded split-up (and everyone forgot the
> > previous 10 minutes).
> > :-)
> 
> I wasn't present for the meeting, so I can't speak to what was discussed other 
> than what I've read in the minutes.
> 
> Leaving that aside, I don't think there's any impediment that I know of per se  
> to additional layers getting added to patchwork, and beyond the initial setup 
> it shouldn't present much of a burden to be accounted for. meta-freescale is 
> already there as an example.
> 
> However, what might be tricky is if that layer currently accepts patches via a 
> mailing list that also takes patches for other layers; meta-rockchip would 
> fall into this category given that it shares the yocto at yoctoproject.org 
> mailing list with several other layers. I'm unsure as to whether patchwork 
> supports filtering on subject or similar - at the moment the patchwork project 
> entry to mailing list relationship is 1:1. Jose, can you check on that?

This part was actually discussed at OEDAM. Hence I keep referring back to 
Tim's proposal, which was supposed to call out separate mailing list 
requirement as well.


> Another useful piece of infrastructure would be the recipe reporting system at 
> http://recipes.yoctoproject.org , whose major function is to provide a view to 
> how well we're tracking upstream with regard to recipe upgrades. It's not 
> currently set up to scale to multiple layers unfortunately. FYI it's a fork of 
> the layer index code (something that I regret, but it was started as an intern 
> project without much time available). However, long term I'd like to see the 
> recipe reporting functionality reintegrated back into the layer index so that 
> layer maintainers that wish to take advantage of it could simply enable it. 
> That would need some design work, and there may have to be some external 
> process gathering and populating the data though as that can be resource-
> consuming, however if we make that relatively easy to set up that shouldn't 
> present too much of a problem. At the moment AFAIK nobody is working on this 
> though, so volunteers would be welcome.
> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>