This all sounds like an improvement and is therefore a step in the right direction :-) A while back I had the idea of "porting" the kernel's "checkpatch.pl" to The Yocto Project (it was around the

One thing that bothers me at the moment is how long we spend in do_configure. I have some new build hardware but sadly whilst having quite a large parallel capacity, it spends a lot of time at idle

Hi Trevor, I don't think there's that much of a division. I don't recall if it was you that raised it at the time but the issue of having two style guides did get rectified - I changed the one on

I agree it's not ideal. I said above, I do want to see it resolved. Leaving indentation aside for a moment do you have any comments on my proposal? Thanks, Paul -- Paul Eggleton Intel Open

I'm not familiar with FDO fork, so I don't know how it looks and behaves, but any improvement on patchwork side is definitely welcome and I appreciate it. Does it support e.g. moving the patches to

I think the areas where there are disagreements are comparatively small, really just on shell whitespace. Where they do exist, they are problematic, not least as some layers effectively ignored an

On 02/12/2015 08:17, "openembedded-core-bounces@... on behalf of Martin Jansa" <openembedded-core-bounces@... on behalf of martin.jansa@...> wrote: This is

On 02/12/2015 10:54, "openembedded-core-bounces@... on behalf of Barros Pena, Belen" <openembedded-core-bounces@... on behalf of belen.barros.pena@...>

.... 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

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

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

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

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

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

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

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

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

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

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

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