[oe] layerindex upvoting Was: [OE-core] OE Changelog since 2016-05-15 until 2016-05-22

[Trevor Woerner]

On Fri 2016-05-27 @ 08:25:23 AM, Paul Eggleton wrote:
> On Thu, 26 May 2016 22:18:34 Andreas Müller wrote:
> > On Thu, May 26, 2016 at 10:14 PM, Paul Eggleton
> > 
> > <paul.eggleton at linux.intel.com> wrote:
> > > On Thu, 26 May 2016 13:46:21 Cliff Brake wrote:
> > >> On Tue, May 24, 2016 at 5:23 AM, Maxin B. John <maxin.john at intel.com> 
> wrote:
> > >> > meta-java repo was moved to:
> > >> > git://git.yoctoproject.org/meta-java
> > >> > 
> > >> > Is it possible to update the list with that info?
> > >> 
> > >> Done, thanks!
> > >> 
> > >> https://github.com/cbrake/openembedded-admin/commit/51604da79ed5a02341562
> > >> a9b f254b3dd9dc71704
> > > 
> > > At some point it would be great if this script could be driven from the OE
> > > layer index rather than being a separate entity - then updates would
> > > largely be self-service for the maintainers, or at least they would only
> > > need to be done in one place.
> > 
> > Maybe a bit off-topic but layer index should have some mechanism of
> > removing rotten layers.
> 
> We've discussed this on-and-off at OE developer meetings for a while now. FWIW 
> I can remove them manually - actually I just got around to deleting meta-
> picosam9 which has been unmaintained for years.
> 
> Part of the problem though is determining what "rotten" actually means. 
> Additionally, there's an element of leaving things around in case someone 
> comes to fork/revive them again. We do show a "last updated" date but it would 
> be good to figure out some other way of determining and indicating "layer 
> health" - to date I don't think we've managed to figure out anything practical 
> for that.

It's nice to see this topic come up. For the last couple OEDEMs and OEDAMs I'm
usually the person to brings this up and it usually gets bandied about for a
while. There's certainly lots of interest in general and from the toaster
people in particular since old layers are likely to cause a build to fail
which leaves a bad impression on newbies.

Currently the best idea we've come up with is to have an opt-in class that
people can enable in their builds which will "phone home" to the layer index
indicating what was build (target, distro) which which layers. Hopefully we'll
think of a way of giving some sort of relevant status in the layer index;
maybe with different coloured balls (a la Jenkins) or something to click on
for the data. I.e. someone built a poky image for a raspi2 using master 2 days
ago and it succeeded, but the 3 people who tried since have all seen failures.
Maybe toaster could use this info somehow too.

Ideally, as a start, we would only record nodistro, core-image-minimal builds.
If people fed in their results with various branches and various (BSP) layers
doing this build in a month we'd have something meaningful.

We're open to any suggestions :-)