FWIW I like the proposal as above adding a tag to the patches. If nobody objects to that we need to update the patch submission guidelines so that everyone is aware of this and then we can ask

I just started the thread onto the architecture list, lets move move the discussion there. Here is the

There is an initiative to track vulnerable software being built (see bugs 8119 and 7515). The idea is to have a testing tool that would check the recipe versions against CVEs. In order to accomplish

Agreed, right now I just want people to get thinking about the right place for some of these discussions to happen too though. I suspect the right place is architecture since we're likely going

I thought the exact same thing seconds after hitting send. I'll let the security and architecture people decide which list is best for discussion. What I do want to see is fewer discussions cross

and the architecture list, this is something that should apply to more than OE-Core ideally. Cheers, Richard

I don't think I'm alone in being a bit frustrated with the effort needed to get FILES_${PN}-dbg correct. I've just posted a patch to oe -core which automates this and means we can drop 99% of the

Good question. We need to get these things scheduled soon. Philip

Heh, I meant that's how Patchwork works at the moment, independently of what we do for OE

The list of bundles is in: http://www.openembedded.org/wiki/Patchwork#Multiple_layers_sharing_the_same_oe_project_on_patchwork Once the patches are added to correct bundles I mark them as archived

Well it depends on what the extra values are. Martin, what values do you use? A "merged in staging" value would be useful for everyone. Ross

That's already in place https://github.com/dlespiau/patchwork/issues/15 You can add status values (to the db directly or via the Django admin interface), but they will apply to all projects in the

Hi, Now that registration is open for ELC, it would be a good time to find out if there are any plans for any post-ELC activities? Best regards, Trevor

Hi Richard, <snip> I didn't mean to bring up old discussions :-) All I was trying to say is that one day I had the idea that it would be nice if we had something similar to the kernel's

Guys, it is 2015 and we are having a discussion about white space. Take a deep breath. The underlying issue here is this was brought up with the TSC, since we need clear guideance for people working

I agree with Ross that if we can get the functionality we truly need into Patchwork--and JaMa can live with the result or help guide the functionality--that we have a better path into the

Sounds like instead of bundles the new patchworks needs the ability for a single list to represent multiple projects (so there'd be a meta-oe, meta-python, etc), and more status values. Ross

OK, then can we please postpone this upgrade (or run both patchworks in parallel) until these 2 features are implemented and working? I'm depending on bundles heavily, to "mark" the patches for

At the time we fixed python functions to use four space indentation and no tabs. This matches python recommendations and avoided issues with some version of python which became stricter about

.... Can you remind us what the whitespace argument is again? I forget, and I think it is important that everyone understand the details. Philip PS: I trimmed the distribution to only the