All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
* Patchwork and incoming patch testing
@ 2017-01-17 18:05 Paul Eggleton
  2017-01-17 19:56 ` [Openembedded-architecture] " Denys Dmytriyenko
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Paul Eggleton @ 2017-01-17 18:05 UTC (permalink / raw
  To: openembedded-architecture, openembedded-core, yocto

Hi all,

As some of you are aware some of my colleagues and I have been working on 
improving how incoming patches are handled - initially for OE-Core but we hope 
to arrive at something that will be useful for other layers as well. The aim 
was to do so without adversely affecting existing workflows, so that means 
building on top of the things we already have. It's taken a bit longer than 
we'd originally planned - we embarked on this a little over a year ago [1] - 
but now I am happy to be able to show some meaningful progress.

A few months ago we upgraded OE's patchwork instance [2], moving not just to a 
later version but to a fork of patchwork where a bunch of new functionality 
was being developed for freedesktop.org [3], notably support for capturing and 
presenting patch series instead of just individual patches. There were some 
teething problems but we've now resolved most of them. Unfortunately work on 
said freedesktop.org fork appears to have stalled so for now we have forked it 
ourselves [4]; long term we'll have to see if we can merge back with patchwork 
upstream - at least for small fixes we'll try to push those back up 
independent of any wholesale merge. In any event we are now finally in the 
position where our patchwork instance can be relied upon to collect emails, 
and the UI is much improved. This should give us a bit more visibility into 
where patches are at in the process, although we are still working on a few 
places where patch series status needs to be updated (e.g. when a patch goes 
into testing).

On top of patchwork we have built a simple smoke-testing framework called 
"patchtest" [5] along with a suite of corresponding tests for OE [6]. These 
tests are fairly simplistic at this point but check the basics such as whether 
a patch has been properly signed off, etc. We should soon start seeing replies 
sent to the mailing list and to submitters with results if there are any 
failures, saving us from noticing and pointing out some of the more obvious 
classes of mistakes. The tests are easy to run locally without the rest of the 
infrastructure and can be extended without difficulty, and I expect we'll 
continue to work on those as time progresses. Contributions would be very 
welcome.

My sincere thanks to José Lamego, Leonardo Sandoval, Daniela Plascencia, 
Belen Barros Pena, Michael Halstead, Damien Lespiau, Patrick Ohly and others 
that have been part of implementing this, and to everyone else who has put up 
with the delays.

Please let us know if you have issues with any part of this process or 
suggestions on how to improve it. We're tracking improvements in the Yocto 
Project bugzilla [7] so you can see what's being worked on there if you're 
interested.

Cheers,
Paul

[1] Earlier announcement:
    https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg72952.html

[2] OE's patchwork instance:
    http://patchwork.openembedded.org

[3] Freedesktop.org patchwork fork:
    https://github.com/dlespiau/patchwork

[4] Our patchwork fork:
    http://git.yoctoproject.org/cgit/cgit.cgi/patchwork/

[5] Patchtest main repository:
    http://git.yoctoproject.org/cgit/cgit.cgi/patchtest/

[6] OE test suite for patchtest:
    http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe/

[7] Yocto Project bugzilla area for patchwork/patchtest:
    https://bugzilla.yoctoproject.org/describecomponents.cgi?product=Patchwork%2FPatchtest

-- 

Paul Eggleton
Intel Open Source Technology Centre


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Openembedded-architecture] Patchwork and incoming patch testing
  2017-01-17 18:05 Patchwork and incoming patch testing Paul Eggleton
@ 2017-01-17 19:56 ` Denys Dmytriyenko
  2017-01-18  8:40 ` Jussi Kukkonen
  2017-01-19  3:54   ` Trevor Woerner
  2 siblings, 0 replies; 10+ messages in thread
From: Denys Dmytriyenko @ 2017-01-17 19:56 UTC (permalink / raw
  To: Paul Eggleton; +Cc: yocto, openembedded-architecture, openembedded-core

Paul,

That is some impressive work by the team! Thank you all for the hard work and 
bringing the plan to fruition - I'm sure this framework will benefit our 
entire Community and will improve and streamline the workflow!

-- 
Denys


On Wed, Jan 18, 2017 at 07:05:58AM +1300, Paul Eggleton wrote:
> Hi all,
> 
> As some of you are aware some of my colleagues and I have been working on 
> improving how incoming patches are handled - initially for OE-Core but we hope 
> to arrive at something that will be useful for other layers as well. The aim 
> was to do so without adversely affecting existing workflows, so that means 
> building on top of the things we already have. It's taken a bit longer than 
> we'd originally planned - we embarked on this a little over a year ago [1] - 
> but now I am happy to be able to show some meaningful progress.
> 
> A few months ago we upgraded OE's patchwork instance [2], moving not just to a 
> later version but to a fork of patchwork where a bunch of new functionality 
> was being developed for freedesktop.org [3], notably support for capturing and 
> presenting patch series instead of just individual patches. There were some 
> teething problems but we've now resolved most of them. Unfortunately work on 
> said freedesktop.org fork appears to have stalled so for now we have forked it 
> ourselves [4]; long term we'll have to see if we can merge back with patchwork 
> upstream - at least for small fixes we'll try to push those back up 
> independent of any wholesale merge. In any event we are now finally in the 
> position where our patchwork instance can be relied upon to collect emails, 
> and the UI is much improved. This should give us a bit more visibility into 
> where patches are at in the process, although we are still working on a few 
> places where patch series status needs to be updated (e.g. when a patch goes 
> into testing).
> 
> On top of patchwork we have built a simple smoke-testing framework called 
> "patchtest" [5] along with a suite of corresponding tests for OE [6]. These 
> tests are fairly simplistic at this point but check the basics such as whether 
> a patch has been properly signed off, etc. We should soon start seeing replies 
> sent to the mailing list and to submitters with results if there are any 
> failures, saving us from noticing and pointing out some of the more obvious 
> classes of mistakes. The tests are easy to run locally without the rest of the 
> infrastructure and can be extended without difficulty, and I expect we'll 
> continue to work on those as time progresses. Contributions would be very 
> welcome.
> 
> My sincere thanks to José Lamego, Leonardo Sandoval, Daniela Plascencia, 
> Belen Barros Pena, Michael Halstead, Damien Lespiau, Patrick Ohly and others 
> that have been part of implementing this, and to everyone else who has put up 
> with the delays.
> 
> Please let us know if you have issues with any part of this process or 
> suggestions on how to improve it. We're tracking improvements in the Yocto 
> Project bugzilla [7] so you can see what's being worked on there if you're 
> interested.
> 
> Cheers,
> Paul
> 
> [1] Earlier announcement:
>     https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg72952.html
> 
> [2] OE's patchwork instance:
>     http://patchwork.openembedded.org
> 
> [3] Freedesktop.org patchwork fork:
>     https://github.com/dlespiau/patchwork
> 
> [4] Our patchwork fork:
>     http://git.yoctoproject.org/cgit/cgit.cgi/patchwork/
> 
> [5] Patchtest main repository:
>     http://git.yoctoproject.org/cgit/cgit.cgi/patchtest/
> 
> [6] OE test suite for patchtest:
>     http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe/
> 
> [7] Yocto Project bugzilla area for patchwork/patchtest:
>     https://bugzilla.yoctoproject.org/describecomponents.cgi?product=Patchwork%2FPatchtest
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> 


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Openembedded-architecture] Patchwork and incoming patch testing
  2017-01-17 18:05 Patchwork and incoming patch testing Paul Eggleton
  2017-01-17 19:56 ` [Openembedded-architecture] " Denys Dmytriyenko
@ 2017-01-18  8:40 ` Jussi Kukkonen
  2017-01-18 14:52     ` [yocto] " Leonardo Sandoval
  2017-01-19  3:54   ` Trevor Woerner
  2 siblings, 1 reply; 10+ messages in thread
From: Jussi Kukkonen @ 2017-01-18  8:40 UTC (permalink / raw
  To: Paul Eggleton
  Cc: Yocto Project, openembedded-architecture,
	Patches and discussions about the oe-core layer

[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]

This looks great, thanks.

On 17 January 2017 at 20:05, Paul Eggleton <paul.eggleton@linux.intel.com>
wrote:

> In any event we are now finally in the
> position where our patchwork instance can be relied upon to collect emails,
> and the UI is much improved. This should give us a bit more visibility into
> where patches are at in the process, although we are still working on a few
> places where patch series status needs to be updated (e.g. when a patch
> goes
> into testing).


What's the plan for these status updates -- is the idea that you go to
patchwork UI to see the state of a specific patch set?
Or maybe a reply to either patch sender or even the ML?

On top of patchwork we have built a simple smoke-testing framework called
> "patchtest" [5] along with a suite of corresponding tests for OE [6]. These
> tests are fairly simplistic at this point but check the basics such as
> whether
> a patch has been properly signed off, etc. We should soon start seeing
> replies
> sent to the mailing list and to submitters with results if there are any
> failures, saving us from noticing and pointing out some of the more obvious
> classes of mistakes.


 Is there a reason for patchwork only showing "success" or "failure" in the
web ui, instead of linking to test results at least in in the failure case?



 - Jussi

[-- Attachment #2: Type: text/html, Size: 2500 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Openembedded-architecture] Patchwork and incoming patch testing
  2017-01-18  8:40 ` Jussi Kukkonen
@ 2017-01-18 14:52     ` Leonardo Sandoval
  0 siblings, 0 replies; 10+ messages in thread
From: Leonardo Sandoval @ 2017-01-18 14:52 UTC (permalink / raw
  To: Jussi Kukkonen, Paul Eggleton
  Cc: Yocto Project, openembedded-architecture, Jose Lamego,
	Patches and discussions about the oe-core layer

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

+ Jose Lamego


Jose is doing recent work on the patchwork UI, perhaps there are already 
bugs for the items you are asking.


On 01/18/2017 02:40 AM, Jussi Kukkonen wrote:
> This looks great, thanks.
>
> On 17 January 2017 at 20:05, Paul Eggleton 
> <paul.eggleton@linux.intel.com <mailto:paul.eggleton@linux.intel.com>> 
> wrote:
>
>     In any event we are now finally in the
>     position where our patchwork instance can be relied upon to
>     collect emails,
>     and the UI is much improved. This should give us a bit more
>     visibility into
>     where patches are at in the process, although we are still working
>     on a few
>     places where patch series status needs to be updated (e.g. when a
>     patch goes
>     into testing).
>
>
> What's the plan for these status updates -- is the idea that you go to 
> patchwork UI to see the state of a specific patch set?
> Or maybe a reply to either patch sender or even the ML?
>
>     On top of patchwork we have built a simple smoke-testing framework
>     called
>     "patchtest" [5] along with a suite of corresponding tests for OE
>     [6]. These
>     tests are fairly simplistic at this point but check the basics
>     such as whether
>     a patch has been properly signed off, etc. We should soon start
>     seeing replies
>     sent to the mailing list and to submitters with results if there
>     are any
>     failures, saving us from noticing and pointing out some of the
>     more obvious
>     classes of mistakes.
>
>
>  Is there a reason for patchwork only showing "success" or "failure" 
> in the web ui, instead of linking to test results at least in in the 
> failure case?

Jussi, that is a good idea. Right now we need to click into the series, 
then into the patches and then one can see the patch test results, 
obviously, not the best way.

>
>
>
>  - Jussi
>
>
>


[-- Attachment #2: Type: text/html, Size: 4138 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [yocto] [Openembedded-architecture] Patchwork and incoming patch testing
@ 2017-01-18 14:52     ` Leonardo Sandoval
  0 siblings, 0 replies; 10+ messages in thread
From: Leonardo Sandoval @ 2017-01-18 14:52 UTC (permalink / raw
  To: Jussi Kukkonen, Paul Eggleton
  Cc: Yocto Project, openembedded-architecture, Jose Lamego,
	Patches and discussions about the oe-core layer

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

+ Jose Lamego


Jose is doing recent work on the patchwork UI, perhaps there are already 
bugs for the items you are asking.


On 01/18/2017 02:40 AM, Jussi Kukkonen wrote:
> This looks great, thanks.
>
> On 17 January 2017 at 20:05, Paul Eggleton 
> <paul.eggleton@linux.intel.com <mailto:paul.eggleton@linux.intel.com>> 
> wrote:
>
>     In any event we are now finally in the
>     position where our patchwork instance can be relied upon to
>     collect emails,
>     and the UI is much improved. This should give us a bit more
>     visibility into
>     where patches are at in the process, although we are still working
>     on a few
>     places where patch series status needs to be updated (e.g. when a
>     patch goes
>     into testing).
>
>
> What's the plan for these status updates -- is the idea that you go to 
> patchwork UI to see the state of a specific patch set?
> Or maybe a reply to either patch sender or even the ML?
>
>     On top of patchwork we have built a simple smoke-testing framework
>     called
>     "patchtest" [5] along with a suite of corresponding tests for OE
>     [6]. These
>     tests are fairly simplistic at this point but check the basics
>     such as whether
>     a patch has been properly signed off, etc. We should soon start
>     seeing replies
>     sent to the mailing list and to submitters with results if there
>     are any
>     failures, saving us from noticing and pointing out some of the
>     more obvious
>     classes of mistakes.
>
>
>  Is there a reason for patchwork only showing "success" or "failure" 
> in the web ui, instead of linking to test results at least in in the 
> failure case?

Jussi, that is a good idea. Right now we need to click into the series, 
then into the patches and then one can see the patch test results, 
obviously, not the best way.

>
>
>
>  - Jussi
>
>
>


[-- Attachment #2: Type: text/html, Size: 4138 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [yocto] [Openembedded-architecture] Patchwork and incoming patch testing
  2017-01-18 14:52     ` [yocto] " Leonardo Sandoval
  (?)
@ 2017-01-18 15:06     ` Jose Lamego
  2017-01-18 22:40       ` Jose Lamego
  -1 siblings, 1 reply; 10+ messages in thread
From: Jose Lamego @ 2017-01-18 15:06 UTC (permalink / raw
  To: openembedded-core


[-- Attachment #1.1: Type: text/plain, Size: 2398 bytes --]



On 01/18/2017 08:52 AM, Leonardo Sandoval wrote:
> + Jose Lamego
> 
> 
> Jose is doing recent work on the patchwork UI, perhaps there are already
> bugs for the items you are asking.
> 
> 
> On 01/18/2017 02:40 AM, Jussi Kukkonen wrote:
>> This looks great, thanks.
>>
>> On 17 January 2017 at 20:05, Paul Eggleton
>> <paul.eggleton@linux.intel.com <mailto:paul.eggleton@linux.intel.com>>
>> wrote:
>>
>>     In any event we are now finally in the
>>     position where our patchwork instance can be relied upon to
>>     collect emails,
>>     and the UI is much improved. This should give us a bit more
>>     visibility into
>>     where patches are at in the process, although we are still working
>>     on a few
>>     places where patch series status needs to be updated (e.g. when a
>>     patch goes
>>     into testing).
>>
>>
>> What's the plan for these status updates -- is the idea that you go to
>> patchwork UI to see the state of a specific patch set?
>> Or maybe a reply to either patch sender or even the ML?
>>
There is a request to enable email notifications to submitter for patch
status changes in the future:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7684

The idea is that users should have the option to use what they prefer:
either the email notifications, or the patchwork web interface.

>>     On top of patchwork we have built a simple smoke-testing framework
>>     called
>>     "patchtest" [5] along with a suite of corresponding tests for OE
>>     [6]. These
>>     tests are fairly simplistic at this point but check the basics
>>     such as whether
>>     a patch has been properly signed off, etc. We should soon start
>>     seeing replies
>>     sent to the mailing list and to submitters with results if there
>>     are any
>>     failures, saving us from noticing and pointing out some of the
>>     more obvious
>>     classes of mistakes.
>>
>>
>>  Is there a reason for patchwork only showing "success" or "failure"
>> in the web ui, instead of linking to test results at least in in the
>> failure case?
> 
> Jussi, that is a good idea. Right now we need to click into the series,
> then into the patches and then one can see the patch test results,
> obviously, not the best way.
> 
>>
>>
>>
>>  - Jussi
>>
>>
-- 
Jose Lamego | OTC Embedded Platforms & Tools | GDC


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [yocto] [Openembedded-architecture] Patchwork and incoming patch testing
  2017-01-18 15:06     ` Jose Lamego
@ 2017-01-18 22:40       ` Jose Lamego
  2017-01-18 22:47         ` [OE-core] " Jose Lamego
  0 siblings, 1 reply; 10+ messages in thread
From: Jose Lamego @ 2017-01-18 22:40 UTC (permalink / raw
  To: openembedded-core


[-- Attachment #1.1: Type: text/plain, Size: 2400 bytes --]


On 01/18/2017 08:52 AM, Leonardo Sandoval wrote:
> + Jose Lamego
> 
> 
> Jose is doing recent work on the patchwork UI, perhaps there are already
> bugs for the items you are asking.
> 
> 
> On 01/18/2017 02:40 AM, Jussi Kukkonen wrote:
>> This looks great, thanks.
>>
>> On 17 January 2017 at 20:05, Paul Eggleton
>> <paul.eggleton@linux.intel.com <mailto:paul.eggleton@linux.intel.com>>
>> wrote:
>>
>>     In any event we are now finally in the
>>     position where our patchwork instance can be relied upon to
>>     collect emails,
>>     and the UI is much improved. This should give us a bit more
>>     visibility into
>>     where patches are at in the process, although we are still working
>>     on a few
>>     places where patch series status needs to be updated (e.g. when a
>>     patch goes
>>     into testing).
>>
>>
>> What's the plan for these status updates -- is the idea that you go to
>> patchwork UI to see the state of a specific patch set?
>> Or maybe a reply to either patch sender or even the ML?
>>
There is a request to enable email notifications to submitter for patch
status changes in the future:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7684

The idea is that users should have the option to use what they prefer:
either the email notifications, or the patchwork web interface.

>>     On top of patchwork we have built a simple smoke-testing framework
>>     called
>>     "patchtest" [5] along with a suite of corresponding tests for OE
>>     [6]. These
>>     tests are fairly simplistic at this point but check the basics
>>     such as whether
>>     a patch has been properly signed off, etc. We should soon start
>>     seeing replies
>>     sent to the mailing list and to submitters with results if there
>>     are any
>>     failures, saving us from noticing and pointing out some of the
>>     more obvious
>>     classes of mistakes.
>>
>>
>>  Is there a reason for patchwork only showing "success" or "failure"
>> in the web ui, instead of linking to test results at least in in the
>> failure case?
> 
> Jussi, that is a good idea. Right now we need to click into the series,
> then into the patches and then one can see the patch test results,
> obviously, not the best way.
> 
>>
>>
>>
>>  - Jussi
>>
>>
-- 
Jose Lamego | OTC Embedded Platforms & Tools | GDC




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [OE-core] [Openembedded-architecture] Patchwork and incoming patch testing
  2017-01-18 22:40       ` Jose Lamego
@ 2017-01-18 22:47         ` Jose Lamego
  0 siblings, 0 replies; 10+ messages in thread
From: Jose Lamego @ 2017-01-18 22:47 UTC (permalink / raw
  To: yocto@yoctoproject.org


[-- Attachment #1.1: Type: text/plain, Size: 2564 bytes --]

I was replying to the wrong mailing list. Sorry for the spam. :(

On 01/18/2017 04:40 PM, Jose Lamego wrote:
> 
> On 01/18/2017 08:52 AM, Leonardo Sandoval wrote:
>> + Jose Lamego
>>
>>
>> Jose is doing recent work on the patchwork UI, perhaps there are already
>> bugs for the items you are asking.
>>
>>
>> On 01/18/2017 02:40 AM, Jussi Kukkonen wrote:
>>> This looks great, thanks.
>>>
>>> On 17 January 2017 at 20:05, Paul Eggleton
>>> <paul.eggleton@linux.intel.com <mailto:paul.eggleton@linux.intel.com>>
>>> wrote:
>>>
>>>     In any event we are now finally in the
>>>     position where our patchwork instance can be relied upon to
>>>     collect emails,
>>>     and the UI is much improved. This should give us a bit more
>>>     visibility into
>>>     where patches are at in the process, although we are still working
>>>     on a few
>>>     places where patch series status needs to be updated (e.g. when a
>>>     patch goes
>>>     into testing).
>>>
>>>
>>> What's the plan for these status updates -- is the idea that you go to
>>> patchwork UI to see the state of a specific patch set?
>>> Or maybe a reply to either patch sender or even the ML?
>>>
There is a request to enable email notifications to submitter for patch
status changes in the future:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7684

The idea is that users should have the option to use what they prefer:
either the email notifications, or the patchwork web interface.
> 
>>>     On top of patchwork we have built a simple smoke-testing framework
>>>     called
>>>     "patchtest" [5] along with a suite of corresponding tests for OE
>>>     [6]. These
>>>     tests are fairly simplistic at this point but check the basics
>>>     such as whether
>>>     a patch has been properly signed off, etc. We should soon start
>>>     seeing replies
>>>     sent to the mailing list and to submitters with results if there
>>>     are any
>>>     failures, saving us from noticing and pointing out some of the
>>>     more obvious
>>>     classes of mistakes.
>>>
>>>
>>>  Is there a reason for patchwork only showing "success" or "failure"
>>> in the web ui, instead of linking to test results at least in in the
>>> failure case?
>>
>> Jussi, that is a good idea. Right now we need to click into the series,
>> then into the patches and then one can see the patch test results,
>> obviously, not the best way.
>>
>>>
>>>
>>>
>>>  - Jussi
>>>

-- 
Jose Lamego | OTC Embedded Platforms & Tools | GDC


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [OE-core] Patchwork and incoming patch testing
  2017-01-17 18:05 Patchwork and incoming patch testing Paul Eggleton
@ 2017-01-19  3:54   ` Trevor Woerner
  2017-01-18  8:40 ` Jussi Kukkonen
  2017-01-19  3:54   ` Trevor Woerner
  2 siblings, 0 replies; 10+ messages in thread
From: Trevor Woerner @ 2017-01-19  3:54 UTC (permalink / raw
  To: Paul Eggleton; +Cc: yocto, openembedded-architecture, openembedded-core

On Wed 2017-01-18 @ 07:05:58 AM, Paul Eggleton wrote:
> This should give us a bit more visibility into 
> where patches are at in the process, although we are still working on a few 
> places where patch series status needs to be updated (e.g. when a patch goes 
> into testing).

Is the testing process for OE patches formalized?

I'm not referring to the Yocto Project's release testing.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Patchwork and incoming patch testing
@ 2017-01-19  3:54   ` Trevor Woerner
  0 siblings, 0 replies; 10+ messages in thread
From: Trevor Woerner @ 2017-01-19  3:54 UTC (permalink / raw
  To: Paul Eggleton; +Cc: yocto, openembedded-architecture, openembedded-core

On Wed 2017-01-18 @ 07:05:58 AM, Paul Eggleton wrote:
> This should give us a bit more visibility into 
> where patches are at in the process, although we are still working on a few 
> places where patch series status needs to be updated (e.g. when a patch goes 
> into testing).

Is the testing process for OE patches formalized?

I'm not referring to the Yocto Project's release testing.


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2017-01-19  3:54 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-01-17 18:05 Patchwork and incoming patch testing Paul Eggleton
2017-01-17 19:56 ` [Openembedded-architecture] " Denys Dmytriyenko
2017-01-18  8:40 ` Jussi Kukkonen
2017-01-18 14:52   ` Leonardo Sandoval
2017-01-18 14:52     ` [yocto] " Leonardo Sandoval
2017-01-18 15:06     ` Jose Lamego
2017-01-18 22:40       ` Jose Lamego
2017-01-18 22:47         ` [OE-core] " Jose Lamego
2017-01-19  3:54 ` [OE-core] " Trevor Woerner
2017-01-19  3:54   ` Trevor Woerner

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.