Patchwork [RFC] fsl-commity-bsp: Add meta-qt5

login
register
mail settings
Submitter Eric Nelson
Date March 19, 2014, 8:35 p.m.
Message ID <1395261322-14905-1-git-send-email-eric.nelson@boundarydevices.com>
Download mbox | patch
Permalink /patch/68895/
State Deferred
Delegated to: Otavio Salvador
Headers show

Comments

Eric Nelson - March 19, 2014, 8:35 p.m.
Most of the energy in Qt for Freescale processors is in the area
of Qt5, not Qt4.

Since the meta-qt5 layer is tiny (currently < 2M), there's little
downside to including it to make it easier to include.

Change-Id: Ifa2850f54728626bbd51ae7924a8bc082ca6f359
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
---
 default.xml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
Otavio Salvador - March 21, 2014, 8:37 p.m.
Hello Eric,

On Wed, Mar 19, 2014 at 5:35 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> Most of the energy in Qt for Freescale processors is in the area
> of Qt5, not Qt4.
>
> Since the meta-qt5 layer is tiny (currently < 2M), there's little
> downside to including it to make it easier to include.
>
> Change-Id: Ifa2850f54728626bbd51ae7924a8bc082ca6f359
> Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>

I am not sure we ought to include it or not. I see valid points for
both and I will focus my answer in the cons:

 * Documentation: our Release Notes, User Guide and FAQ are still
uncomplete. Add new stuff will only make it worse as those will also
need to be documented.

 * Tests: We see limited tests using the images we have and people
does not provide much feedback when we open the test form. More things
will only complicate it more.

 * Size: more metadata means more updates and maintenance. We need
more people helping the metadata maintenance before extend it.

I cannot a lot more time in FSL Community BSP that I do. I do it in my
free time and before extending it we need more people committed to the
maintenance work.

Those are my remarks about this, and meta-browser, addition.

Regards,
Daiane Angolini - March 24, 2014, 1:08 p.m.
> -----Original Message-----
> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> bounces@yoctoproject.org] On Behalf Of Otavio Salvador
> Sent: Friday, March 21, 2014 5:37 PM
> To: Eric Nelson
> Cc: meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] [RFC PATCH] fsl-commity-bsp: Add meta-qt5
> 
> Hello Eric,
> 
> On Wed, Mar 19, 2014 at 5:35 PM, Eric Nelson
> <eric.nelson@boundarydevices.com> wrote:
> > Most of the energy in Qt for Freescale processors is in the area of
> > Qt5, not Qt4.
> >
> > Since the meta-qt5 layer is tiny (currently < 2M), there's little
> > downside to including it to make it easier to include.
> >
> > Change-Id: Ifa2850f54728626bbd51ae7924a8bc082ca6f359
> > Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
> 
> I am not sure we ought to include it or not. I see valid points for both
> and I will focus my answer in the cons:
> 
>  * Documentation: our Release Notes, User Guide and FAQ are still
> uncomplete. Add new stuff will only make it worse as those will also need
> to be documented.
> 
>  * Tests: We see limited tests using the images we have and people does not
> provide much feedback when we open the test form. More things will only
> complicate it more.

Until here I understand. And I agree.

> 
>  * Size: more metadata means more updates and maintenance. We need more
> people helping the metadata maintenance before extend it.

We already have almost 100% of the boards with maintainers. What do you mean, when you
say we need more maintenance before extend the metadata?

I still don´t have a clear idea if I like or dislike the idea of downloading more meta layers by default.

I´m still deciding ;)

Daiane

> 
> I cannot a lot more time in FSL Community BSP that I do. I do it in my free
> time and before extending it we need more people committed to the
> maintenance work.
> 
> Those are my remarks about this, and meta-browser, addition.
> 
> Regards,
> 
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>
Otavio Salvador - March 24, 2014, 2:26 p.m.
On Mon, Mar 24, 2014 at 10:08 AM, Daiane.Angolini@freescale.com
<Daiane.Angolini@freescale.com> wrote:
>> I am not sure we ought to include it or not. I see valid points for both
>> and I will focus my answer in the cons:
>>
>>  * Documentation: our Release Notes, User Guide and FAQ are still
>> uncomplete. Add new stuff will only make it worse as those will also need
>> to be documented.
>>
>>  * Tests: We see limited tests using the images we have and people does not
>> provide much feedback when we open the test form. More things will only
>> complicate it more.
>
> Until here I understand. And I agree.
>
>>  * Size: more metadata means more updates and maintenance. We need more
>> people helping the metadata maintenance before extend it.
>
> We already have almost 100% of the boards with maintainers. What do you mean, when you
> say we need more maintenance before extend the metadata?
>
> I still don´t have a clear idea if I like or dislike the idea of downloading more meta layers by default.
>
> I´m still deciding ;)

We need to split the maintainership areas:

* boards: Yes, most of board has someone committed nowadays and this
is awesome. This help us to get tests and feedback from those boards
and more people to help to address board specific things. However this
does not address the rest of meta-fsl-arm ...

* core BSP support: here we have some people working. You and me has
been doing most of work until now and Lauren has been started to
contribute more to this since Freescale started to work in the
3.10.17-1.0.0 BSP. Here we need a lot of help and it does affect
/every/ board we use/add/maintain ...

* technology specific support: here is where we are beginning. This
involves a lot of commitment and time. Here is where Qt5 and Chromium
are going to be covered. Currently we have no one really committed to
either and we cannot supply something in FSL Community BSP which is
not /maintained/ and for maintained I mean someone watching it and
doing the rework/improvements/commitments need for it to keep working
when Qt5 5.3 or Chromium 40 is released.

So it is a extensive topic; I hope it is clear now why I see we need
more people involved to grow.
Eric Nelson - March 24, 2014, 3:42 p.m.
Hi Daiane (and Otavio),

Otavio, I'm not sure why, but I didn't receive the e-mail
that Daiane's responding to, so I'll reply here.

>> -----Original Message-----
>> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
>> bounces@yoctoproject.org] On Behalf Of Otavio Salvador
>> Sent: Friday, March 21, 2014 5:37 PM
>> To: Eric Nelson
>> Cc: meta-freescale@yoctoproject.org
>> Subject: Re: [meta-freescale] [RFC PATCH] fsl-commity-bsp: Add meta-qt5
>>
>> Hello Eric,
>>
>> On Wed, Mar 19, 2014 at 5:35 PM, Eric Nelson
>> <eric.nelson@boundarydevices.com> wrote:
>>> Most of the energy in Qt for Freescale processors is in the area of
>>> Qt5, not Qt4.
>>>
>>> Since the meta-qt5 layer is tiny (currently < 2M), there's little
>>> downside to including it to make it easier to include.
>>>
>>> Change-Id: Ifa2850f54728626bbd51ae7924a8bc082ca6f359
>>> Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
>>
>> I am not sure we ought to include it or not. I see valid points for both
>> and I will focus my answer in the cons:
>>
>>   * Documentation: our Release Notes, User Guide and FAQ are still
>> uncomplete. Add new stuff will only make it worse as those will also need
>> to be documented.
>>

This is always a question of degree, right?

>>   * Tests: We see limited tests using the images we have and people does not
>> provide much feedback when we open the test form. More things will only
>> complicate it more.

Do you think this is because
	a.) people are just having success and not reporting it, or
	b.) folks aren't using the images

I tend to think a.), but I'm not sure.

If it's b.), then are the images matching what users are looking for?

>
> Until here I understand. And I agree.
>
>>
>>   * Size: more metadata means more updates and maintenance. We need more
>> people helping the metadata maintenance before extend it.
>>

I think this is somewhat un-related to Qt5.

>
> We already have almost 100% of the boards with maintainers. What do you mean,
> when you say we need more maintenance before extend the metadata?
>
> I still don´t have a clear idea if I like or dislike the idea of downloading
> more meta layers by default.
>
> I´m still deciding ;)
>

My initial thinking was that by having meta-qt5 included, we'll make
it easier to test the qt5-layer that's already included in meta-fsl-arm.

>>
>> I cannot a lot more time in FSL Community BSP that I do. I do it in my free
>> time and before extending it we need more people committed to the
>> maintenance work.
>>
>> Those are my remarks about this, and meta-browser, addition.
>>

I hear you loud and clear.

I see that you've posted another response to the thread that has
some constructive thoughts about how to remedy this.

And by the way: Thank you very much for all of your efforts!

Regards,


Eric
Eric Nelson - March 24, 2014, 3:58 p.m.
Hi Otavio,

Since we have diverged off the topic again, I changed the
subject line to invite more folks to chime in.

On 03/24/2014 07:26 AM, Otavio Salvador wrote:
> On Mon, Mar 24, 2014 at 10:08 AM, Daiane.Angolini@freescale.com
> <Daiane.Angolini@freescale.com> wrote:
>>> I am not sure we ought to include it or not. I see valid points for both
>>> and I will focus my answer in the cons:
>>>
>>>   * Documentation: our Release Notes, User Guide and FAQ are still
>>> uncomplete. Add new stuff will only make it worse as those will also need
>>> to be documented.
>>>
>>>   * Tests: We see limited tests using the images we have and people does not
>>> provide much feedback when we open the test form. More things will only
>>> complicate it more.
>>
>> Until here I understand. And I agree.
>>
>>>   * Size: more metadata means more updates and maintenance. We need more
>>> people helping the metadata maintenance before extend it.
>>
>> We already have almost 100% of the boards with maintainers. What do you mean, when you
>> say we need more maintenance before extend the metadata?
>>
>> I still don´t have a clear idea if I like or dislike the idea of downloading more meta layers by default.
>>
>> I´m still deciding ;)
>
> We need to split the maintainership areas:
>
> * boards: Yes, most of board has someone committed nowadays and this
> is awesome. This help us to get tests and feedback from those boards
> and more people to help to address board specific things. However this
> does not address the rest of meta-fsl-arm ...
>
> * core BSP support: here we have some people working. You and me has
> been doing most of work until now and Lauren has been started to
> contribute more to this since Freescale started to work in the
> 3.10.17-1.0.0 BSP. Here we need a lot of help and it does affect
> /every/ board we use/add/maintain ...
>

These are areas where both carrots and sticks might help. It seems
very reasonable to ask each board maintainer to update and test
against some set of target images within a certain time period.

> * technology specific support: here is where we are beginning. This
> involves a lot of commitment and time. Here is where Qt5 and Chromium
> are going to be covered. Currently we have no one really committed to
> either and we cannot supply something in FSL Community BSP which is
> not /maintained/ and for maintained I mean someone watching it and
> doing the rework/improvements/commitments need for it to keep working
> when Qt5 5.3 or Chromium 40 is released.
>

I think you're under-stating the issue here, since there are many
more bits than just Qt5 and Chromium.

Just off the top of my head:

- Is anybody testing DirectFB on a regular basis? (seems a question
on the ML today),
- Up until the recent addition of , there weren't any easy-buttons for
testing the gstreamer plugins in a non-X environment, and
- There's Wayland activity, but AFAIK, no image available to take
advantage of it.

> So it is a extensive topic; I hope it is clear now why I see we need
> more people involved to grow.
>

I feel like I've thrown a couple of bricks in the last week (Chromium
and Qt5), but I hope they can be constructive.

I do think that the questions you raise are worthy of a separate set of
discussions (or at least a separate e-mail chain).

Since there are a lot of different, interested parties with different
agendas, I wonder whether a different (more interactive) forum might
be a better match.

Conference call? Google Hangout meeting?

I'm sure it's too late to schedule anything at FTF, but perhaps not.
I'm also sure that there will be those interested in the topic who
won't be attending.

Regards,


Eric
Otavio Salvador - March 24, 2014, 4:55 p.m.
Hello,

On Mon, Mar 24, 2014 at 12:58 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> Hi Otavio,
>
> Since we have diverged off the topic again, I changed the
> subject line to invite more folks to chime in.
>
> On 03/24/2014 07:26 AM, Otavio Salvador wrote:
>>
>> On Mon, Mar 24, 2014 at 10:08 AM, Daiane.Angolini@freescale.com
>> <Daiane.Angolini@freescale.com> wrote:
>>>>
>>>> I am not sure we ought to include it or not. I see valid points for both
>>>> and I will focus my answer in the cons:
>>>>
>>>>   * Documentation: our Release Notes, User Guide and FAQ are still
>>>> uncomplete. Add new stuff will only make it worse as those will also
>>>> need
>>>> to be documented.
>>>>
>>>>   * Tests: We see limited tests using the images we have and people does
>>>> not
>>>> provide much feedback when we open the test form. More things will only
>>>> complicate it more.
>>>
>>>
>>> Until here I understand. And I agree.
>>>
>>>>   * Size: more metadata means more updates and maintenance. We need more
>>>> people helping the metadata maintenance before extend it.
>>>
>>>
>>> We already have almost 100% of the boards with maintainers. What do you
>>> mean, when you
>>> say we need more maintenance before extend the metadata?
>>>
>>> I still don´t have a clear idea if I like or dislike the idea of
>>> downloading more meta layers by default.
>>>
>>> I´m still deciding ;)
>>
>>
>> We need to split the maintainership areas:
>>
>> * boards: Yes, most of board has someone committed nowadays and this
>> is awesome. This help us to get tests and feedback from those boards
>> and more people to help to address board specific things. However this
>> does not address the rest of meta-fsl-arm ...
>>
>> * core BSP support: here we have some people working. You and me has
>> been doing most of work until now and Lauren has been started to
>> contribute more to this since Freescale started to work in the
>> 3.10.17-1.0.0 BSP. Here we need a lot of help and it does affect
>> /every/ board we use/add/maintain ...
>
> These are areas where both carrots and sticks might help. It seems
> very reasonable to ask each board maintainer to update and test
> against some set of target images within a certain time period.


Part of this has been addressed by the Test Form, which has been done
and maintained mainly by Daiane which try to make clear what we intend
to support during the release. However I agree we may need a more
frequent test to fully address this and here I am out of ideas. So do
you have any idea how we can improve on this regard?

>> * technology specific support: here is where we are beginning. This
>> involves a lot of commitment and time. Here is where Qt5 and Chromium
>> are going to be covered. Currently we have no one really committed to
>> either and we cannot supply something in FSL Community BSP which is
>> not /maintained/ and for maintained I mean someone watching it and
>> doing the rework/improvements/commitments need for it to keep working
>> when Qt5 5.3 or Chromium 40 is released.
>
> I think you're under-stating the issue here, since there are many
> more bits than just Qt5 and Chromium.

Of course; the idea here was to elucidate two more known and often
asked examples...

> Just off the top of my head:
>
> - Is anybody testing DirectFB on a regular basis? (seems a question
> on the ML today),

This is supported by Freescale so I assume they are doing those tests.

> - Up until the recent addition of , there weren't any easy-buttons for
> testing the gstreamer plugins in a non-X environment, and

Here again we need to split this:

Freescale 0.10 plugins: this is official material from Freescale and I
expect those to be tested by them. For example gplay makes it more or
less easy to use this.

gstreamer-imx (1.0): Carlos has been doing an awesome job here but he
cannot do all himself and as a community we ought to help here. We
need to think how to improve this and I am open for ideas here...

packagegroup-fsl-*, fsl-image-machine-test: Rogerio Nunes has started
an images rework which provides a much better base  for test, reuse
and long term maintenance...

... however I know that you have this background information so this
point is not clear to me. What you mean here exactly?

> - There's Wayland activity, but AFAIK, no image available to take
> advantage of it.

It is still not integrated in meta-fsl-arm. The patches are being
worked out and we ought to have it integrated soon, however, as
DirectFB this is something Freescale officially supports so we can
rely on them for tests.

>> So it is a extensive topic; I hope it is clear now why I see we need
>> more people involved to grow.
>
> I feel like I've thrown a couple of bricks in the last week (Chromium
> and Qt5), but I hope they can be constructive.
>
> I do think that the questions you raise are worthy of a separate set of
> discussions (or at least a separate e-mail chain).
>
> Since there are a lot of different, interested parties with different
> agendas, I wonder whether a different (more interactive) forum might
> be a better match.
>
> Conference call? Google Hangout meeting?

Yes; I think a Google Hangout would fit perfectly fine here. Some
people has suggested it privately in past but our community was still
too small for it to make sense. I think we are big enough for it to be
worth it and I am supportive to the idea.

What others think?

> I'm sure it's too late to schedule anything at FTF, but perhaps not.
> I'm also sure that there will be those interested in the topic who
> won't be attending.

Sure. I will send an e-mail about FTF later today and I think it is a
great place for us to meet and discuss some of those points
face-to-face as the FTF and the Google Hangout allow more interactive
discussion but this all needs to be summarised here, in the mailing
list, for a final decision.

Regards,
Daiane Angolini - March 24, 2014, 4:57 p.m.
> -----Original Message-----
> From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On
> Behalf Of Otavio Salvador
> Sent: Monday, March 24, 2014 1:55 PM
> To: Eric Nelson
> Cc: Angolini Daiane-B19406; meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] Call for maintainers (was [RFC PATCH] fsl-
> commity-bsp: Add meta-qt5)
> 
> Hello,
> 
> On Mon, Mar 24, 2014 at 12:58 PM, Eric Nelson
> <eric.nelson@boundarydevices.com> wrote:
> > Hi Otavio,
> >
> > Since we have diverged off the topic again, I changed the subject line
> > to invite more folks to chime in.
> >
> > On 03/24/2014 07:26 AM, Otavio Salvador wrote:
> >>
> >> On Mon, Mar 24, 2014 at 10:08 AM, Daiane.Angolini@freescale.com
> >> <Daiane.Angolini@freescale.com> wrote:
> >>>>
> >>>> I am not sure we ought to include it or not. I see valid points for
> >>>> both and I will focus my answer in the cons:
> >>>>
> >>>>   * Documentation: our Release Notes, User Guide and FAQ are still
> >>>> uncomplete. Add new stuff will only make it worse as those will
> >>>> also need to be documented.
> >>>>
> >>>>   * Tests: We see limited tests using the images we have and people
> >>>> does not provide much feedback when we open the test form. More
> >>>> things will only complicate it more.
> >>>
> >>>
> >>> Until here I understand. And I agree.
> >>>
> >>>>   * Size: more metadata means more updates and maintenance. We need
> >>>> more people helping the metadata maintenance before extend it.
> >>>
> >>>
> >>> We already have almost 100% of the boards with maintainers. What do
> >>> you mean, when you say we need more maintenance before extend the
> >>> metadata?
> >>>
> >>> I still don´t have a clear idea if I like or dislike the idea of
> >>> downloading more meta layers by default.
> >>>
> >>> I´m still deciding ;)
> >>
> >>
> >> We need to split the maintainership areas:
> >>
> >> * boards: Yes, most of board has someone committed nowadays and this
> >> is awesome. This help us to get tests and feedback from those boards
> >> and more people to help to address board specific things. However
> >> this does not address the rest of meta-fsl-arm ...
> >>
> >> * core BSP support: here we have some people working. You and me has
> >> been doing most of work until now and Lauren has been started to
> >> contribute more to this since Freescale started to work in the
> >> 3.10.17-1.0.0 BSP. Here we need a lot of help and it does affect
> >> /every/ board we use/add/maintain ...
> >
> > These are areas where both carrots and sticks might help. It seems
> > very reasonable to ask each board maintainer to update and test
> > against some set of target images within a certain time period.
> 
> 
> Part of this has been addressed by the Test Form, which has been done and
> maintained mainly by Daiane which try to make clear what we intend to
> support during the release. However I agree we may need a more frequent
> test to fully address this and here I am out of ideas. So do you have any
> idea how we can improve on this regard?
> 
> >> * technology specific support: here is where we are beginning. This
> >> involves a lot of commitment and time. Here is where Qt5 and Chromium
> >> are going to be covered. Currently we have no one really committed to
> >> either and we cannot supply something in FSL Community BSP which is
> >> not /maintained/ and for maintained I mean someone watching it and
> >> doing the rework/improvements/commitments need for it to keep working
> >> when Qt5 5.3 or Chromium 40 is released.
> >
> > I think you're under-stating the issue here, since there are many more
> > bits than just Qt5 and Chromium.
> 
> Of course; the idea here was to elucidate two more known and often asked
> examples...
> 
> > Just off the top of my head:
> >
> > - Is anybody testing DirectFB on a regular basis? (seems a question on
> > the ML today),
> 
> This is supported by Freescale so I assume they are doing those tests.
> 
> > - Up until the recent addition of , there weren't any easy-buttons for
> > testing the gstreamer plugins in a non-X environment, and
> 
> Here again we need to split this:
> 
> Freescale 0.10 plugins: this is official material from Freescale and I
> expect those to be tested by them. For example gplay makes it more or less
> easy to use this.
> 
> gstreamer-imx (1.0): Carlos has been doing an awesome job here but he
> cannot do all himself and as a community we ought to help here. We need to
> think how to improve this and I am open for ideas here...
> 
> packagegroup-fsl-*, fsl-image-machine-test: Rogerio Nunes has started an
> images rework which provides a much better base  for test, reuse and long
> term maintenance...
> 
> ... however I know that you have this background information so this point
> is not clear to me. What you mean here exactly?
> 
> > - There's Wayland activity, but AFAIK, no image available to take
> > advantage of it.
> 
> It is still not integrated in meta-fsl-arm. The patches are being worked
> out and we ought to have it integrated soon, however, as DirectFB this is
> something Freescale officially supports so we can rely on them for tests.
> 
> >> So it is a extensive topic; I hope it is clear now why I see we need
> >> more people involved to grow.
> >
> > I feel like I've thrown a couple of bricks in the last week (Chromium
> > and Qt5), but I hope they can be constructive.
> >
> > I do think that the questions you raise are worthy of a separate set
> > of discussions (or at least a separate e-mail chain).
> >
> > Since there are a lot of different, interested parties with different
> > agendas, I wonder whether a different (more interactive) forum might
> > be a better match.
> >
> > Conference call? Google Hangout meeting?
> 
> Yes; I think a Google Hangout would fit perfectly fine here. Some people
> has suggested it privately in past but our community was still too small
> for it to make sense. I think we are big enough for it to be worth it and I
> am supportive to the idea.
> 
> What others think?

+1

Daiane
> 
> > I'm sure it's too late to schedule anything at FTF, but perhaps not.
> > I'm also sure that there will be those interested in the topic who
> > won't be attending.
> 
> Sure. I will send an e-mail about FTF later today and I think it is a great
> place for us to meet and discuss some of those points face-to-face as the
> FTF and the Google Hangout allow more interactive discussion but this all
> needs to be summarised here, in the mailing list, for a final decision.
> 
> Regards,
> 
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
>
Eric Nelson - March 24, 2014, 8:45 p.m.
Hi Otavio,

On 03/24/2014 09:55 AM, Otavio Salvador wrote:
> Hello,
>
> On Mon, Mar 24, 2014 at 12:58 PM, Eric Nelson
> <eric.nelson@boundarydevices.com> wrote:
>> Hi Otavio,
>>
>> Since we have diverged off the topic again, I changed the
>> subject line to invite more folks to chime in.
>>
>> On 03/24/2014 07:26 AM, Otavio Salvador wrote:
>>>
>>> On Mon, Mar 24, 2014 at 10:08 AM, Daiane.Angolini@freescale.com
>>> <Daiane.Angolini@freescale.com> wrote:
>>>>>
>>>>> I am not sure we ought to include it or not. I see valid points for both
>>>>> and I will focus my answer in the cons:
>>>>>
>>>>>    * Documentation: our Release Notes, User Guide and FAQ are still
>>>>> uncomplete. Add new stuff will only make it worse as those will also
>>>>> need
>>>>> to be documented.
>>>>>
>>>>>    * Tests: We see limited tests using the images we have and people does
>>>>> not
>>>>> provide much feedback when we open the test form. More things will only
>>>>> complicate it more.
>>>>
>>>>
>>>> Until here I understand. And I agree.
>>>>
>>>>>    * Size: more metadata means more updates and maintenance. We need more
>>>>> people helping the metadata maintenance before extend it.
>>>>
>>>>
>>>> We already have almost 100% of the boards with maintainers. What do you
>>>> mean, when you
>>>> say we need more maintenance before extend the metadata?
>>>>
>>>> I still don´t have a clear idea if I like or dislike the idea of
>>>> downloading more meta layers by default.
>>>>
>>>> I´m still deciding ;)
>>>
>>>
>>> We need to split the maintainership areas:
>>>
>>> * boards: Yes, most of board has someone committed nowadays and this
>>> is awesome. This help us to get tests and feedback from those boards
>>> and more people to help to address board specific things. However this
>>> does not address the rest of meta-fsl-arm ...
>>>
>>> * core BSP support: here we have some people working. You and me has
>>> been doing most of work until now and Lauren has been started to
>>> contribute more to this since Freescale started to work in the
>>> 3.10.17-1.0.0 BSP. Here we need a lot of help and it does affect
>>> /every/ board we use/add/maintain ...
>>
>> These are areas where both carrots and sticks might help. It seems
>> very reasonable to ask each board maintainer to update and test
>> against some set of target images within a certain time period.
>
>
> Part of this has been addressed by the Test Form, which has been done
> and maintained mainly by Daiane which try to make clear what we intend
> to support during the release.
 >
 > However I agree we may need a more frequent test to fully address
 > this and here I am out of ideas. So do you have any idea how we can
 > improve on this regard?
>

I don't have any fully-baked ideas, but I think there's some value
is laying out expectations.


>>> * technology specific support: here is where we are beginning. This
>>> involves a lot of commitment and time. Here is where Qt5 and Chromium
>>> are going to be covered. Currently we have no one really committed to
>>> either and we cannot supply something in FSL Community BSP which is
>>> not /maintained/ and for maintained I mean someone watching it and
>>> doing the rework/improvements/commitments need for it to keep working
>>> when Qt5 5.3 or Chromium 40 is released.
>>
>> I think you're under-stating the issue here, since there are many
>> more bits than just Qt5 and Chromium.
>
> Of course; the idea here was to elucidate two more known and often
> asked examples...
>

Sorry if that came across badly. I was just making the point that
a lot more specificity would help here.

>> Just off the top of my head:
>>
>> - Is anybody testing DirectFB on a regular basis? (seems a question
>> on the ML today),
>
> This is supported by Freescale so I assume they are doing those tests.
>
Okay. I didn't know (and perhaps haven't read all of the documentation).

>> - Up until the recent addition of , there weren't any easy-buttons for
>> testing the gstreamer plugins in a non-X environment, and
>
> Here again we need to split this:
>
> Freescale 0.10 plugins: this is official material from Freescale and I
> expect those to be tested by them. For example gplay makes it more or
> less easy to use this.
>

Right.

> gstreamer-imx (1.0): Carlos has been doing an awesome job here but he
> cannot do all himself and as a community we ought to help here. We
> need to think how to improve this and I am open for ideas here...
>

Agreed.

> packagegroup-fsl-*, fsl-image-machine-test: Rogerio Nunes has started
> an images rework which provides a much better base  for test, reuse
> and long term maintenance...
>
> ... however I know that you have this background information so this
> point is not clear to me. What you mean here exactly?
>

I was just making the point that a broader conversation (with more
specifics) was appropriate.

>> - There's Wayland activity, but AFAIK, no image available to take
>> advantage of it.
>
> It is still not integrated in meta-fsl-arm. The patches are being
> worked out and we ought to have it integrated soon, however, as
> DirectFB this is something Freescale officially supports so we can
> rely on them for tests.
>

Cool. Again, I'm just throwing some bombs here to prod the conversation
(and brainstorm a bit) about what/where/how we can get others to take
some responsibility for the parts here.

And when I say others, I include myself in the mix.

>>> So it is a extensive topic; I hope it is clear now why I see we need
>>> more people involved to grow.
>>
>> I feel like I've thrown a couple of bricks in the last week (Chromium
>> and Qt5), but I hope they can be constructive.
>>
>> I do think that the questions you raise are worthy of a separate set of
>> discussions (or at least a separate e-mail chain).
>>
>> Since there are a lot of different, interested parties with different
>> agendas, I wonder whether a different (more interactive) forum might
>> be a better match.
>>
>> Conference call? Google Hangout meeting?
>
> Yes; I think a Google Hangout would fit perfectly fine here. Some
> people has suggested it privately in past but our community was still
> too small for it to make sense. I think we are big enough for it to be
> worth it and I am supportive to the idea.
>
> What others think?
>
>> I'm sure it's too late to schedule anything at FTF, but perhaps not.
>> I'm also sure that there will be those interested in the topic who
>> won't be attending.
>
> Sure. I will send an e-mail about FTF later today and I think it is a
> great place for us to meet and discuss some of those points
> face-to-face as the FTF and the Google Hangout allow more interactive
> discussion but this all needs to be summarised here, in the mailing
> list, for a final decision.
>

That makes sense to me.

Communities only work if there's commitment to some effort from
all involved.

Regards,


Eric
Trevor Woerner - March 25, 2014, 2:56 a.m.
On 03/24/14 12:55, Otavio Salvador wrote:
> Yes; I think a Google Hangout would fit perfectly fine here. Some
> people has suggested it privately in past but our community was still
> too small for it to make sense. I think we are big enough for it to be
> worth it and I am supportive to the idea. What others think?

I would be in favour of having a google hang-out, or a meeting on IRC.
Perhaps even on a quasi-regular basis?
Otavio Salvador - March 25, 2014, 11:55 a.m.
Hello,

On Mon, Mar 24, 2014 at 11:56 PM, Trevor Woerner
<trevor.woerner@linaro.org> wrote:
> On 03/24/14 12:55, Otavio Salvador wrote:
>> Yes; I think a Google Hangout would fit perfectly fine here. Some
>> people has suggested it privately in past but our community was still
>> too small for it to make sense. I think we are big enough for it to be
>> worth it and I am supportive to the idea. What others think?
>
> I would be in favour of having a google hang-out, or a meeting on IRC.
> Perhaps even on a quasi-regular basis?

Yes. This would be quite interesting indeed.

For a Google Hangout. Any ideal date for people? We need to first
check the pattern that works for most of us, as:

* Work days or weekend?
* Timezone of preference?
Daiane Angolini - March 25, 2014, 12:35 p.m.
> -----Original Message-----
> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> bounces@yoctoproject.org] On Behalf Of Trevor Woerner
> Sent: Monday, March 24, 2014 11:56 PM
> To: meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] Call for maintainers (was [RFC PATCH] fsl-
> commity-bsp: Add meta-qt5)
> 
> On 03/24/14 12:55, Otavio Salvador wrote:
> > Yes; I think a Google Hangout would fit perfectly fine here. Some
> > people has suggested it privately in past but our community was still
> > too small for it to make sense. I think we are big enough for it to be
> > worth it and I am supportive to the idea. What others think?
> 
> I would be in favour of having a google hang-out, or a meeting on IRC.
> Perhaps even on a quasi-regular basis?

Before defining any period. I prefer we define the "agenda for next meeting"

We can build the agenda and when it´s big enough, we set the "next meeting".


Daiane
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>
Otavio Salvador - March 25, 2014, 1:24 p.m.
Hello Daiane,

On Tue, Mar 25, 2014 at 9:35 AM, Daiane.Angolini@freescale.com
<Daiane.Angolini@freescale.com> wrote:
>> On 03/24/14 12:55, Otavio Salvador wrote:
>> > Yes; I think a Google Hangout would fit perfectly fine here. Some
>> > people has suggested it privately in past but our community was still
>> > too small for it to make sense. I think we are big enough for it to be
>> > worth it and I am supportive to the idea. What others think?
>>
>> I would be in favour of having a google hang-out, or a meeting on IRC.
>> Perhaps even on a quasi-regular basis?
>
> Before defining any period. I prefer we define the "agenda for next meeting"
>
> We can build the agenda and when it´s big enough, we set the "next meeting".

Ok.

I have started a Google Driver document[1] which can be commented by
anyone. I have added you (Daiane) as editor as well.

1. http://bit.ly/OVtbmd

So let's start work in a draft and then we can keep adding and
reworking it until we get it 'good enough'.
Eric Nelson - March 25, 2014, 1:59 p.m.
On 03/25/2014 04:55 AM, Otavio Salvador wrote:
> Hello,
>
> On Mon, Mar 24, 2014 at 11:56 PM, Trevor Woerner
> <trevor.woerner@linaro.org> wrote:
>> On 03/24/14 12:55, Otavio Salvador wrote:
>>> Yes; I think a Google Hangout would fit perfectly fine here. Some
>>> people has suggested it privately in past but our community was still
>>> too small for it to make sense. I think we are big enough for it to be
>>> worth it and I am supportive to the idea. What others think?
>>
>> I would be in favour of having a google hang-out, or a meeting on IRC.
>> Perhaps even on a quasi-regular basis?
>
> Yes. This would be quite interesting indeed.
>
> For a Google Hangout. Any ideal date for people? We need to first
> check the pattern that works for most of us, as:
>
> * Work days or weekend?
> * Timezone of preference?
>
+1

I'm in MST (UTC-7), and weekends are easiest to schedule.
Eric Nelson - March 25, 2014, 2:12 p.m.
On 03/25/2014 06:24 AM, Otavio Salvador wrote:
> Hello Daiane,
>
> On Tue, Mar 25, 2014 at 9:35 AM, Daiane.Angolini@freescale.com
> <Daiane.Angolini@freescale.com> wrote:
>>> On 03/24/14 12:55, Otavio Salvador wrote:
>>>> Yes; I think a Google Hangout would fit perfectly fine here. Some
>>>> people has suggested it privately in past but our community was still
>>>> too small for it to make sense. I think we are big enough for it to be
>>>> worth it and I am supportive to the idea. What others think?
>>>
>>> I would be in favour of having a google hang-out, or a meeting on IRC.
>>> Perhaps even on a quasi-regular basis?
>>
>> Before defining any period. I prefer we define the "agenda for next meeting"
>>
>> We can build the agenda and when it´s big enough, we set the "next meeting".
>
> Ok.
>
> I have started a Google Driver document[1] which can be commented by
> anyone. I have added you (Daiane) as editor as well.
>
> 1. http://bit.ly/OVtbmd
>
> So let's start work in a draft and then we can keep adding and
> reworking it until we get it 'good enough'.
>

Thanks Otavio.
Trevor Woerner - March 25, 2014, 4:17 p.m.
On 03/25/14 07:55, Otavio Salvador wrote:
>> I would be in favour of having a google hang-out, or a meeting on IRC.
>> Perhaps even on a quasi-regular basis?
> Yes. This would be quite interesting indeed.
>
> For a Google Hangout. Any ideal date for people? We need to first
> check the pattern that works for most of us, as:
>
> * Work days or weekend?

Either works, although I'm more likely to be available during the week
rather than on weekends.

> * Timezone of preference?

I'm in the EST timezone (nominally UTC-5, but currently UTC-4 due to
daylight savings).
Trevor Woerner - March 25, 2014, 4:26 p.m.
On 03/25/14 08:35, Daiane.Angolini@freescale.com wrote:
> Before defining any period. I prefer we define the "agenda for next meeting"
>
> We can build the agenda and when it´s big enough, we set the "next meeting".

I think these meetings would be a good opportunity for maintainers to
get together and discuss any issues they're facing leading into the next
release. Maybe these meetings could provide an opportunity to update
status information with respect to testing efforts in order to keep all
the board testing moving forward as we come into the next release?

I'm not implying these meetings should only be for maintainers, I'm just
pointing them out as one example of a group who might benefit from such
a meeting.

As such an agenda item could be:
- short testing status from maintainers/testers
Otavio Salvador - March 25, 2014, 4:32 p.m.
Hello Trevor,

On Tue, Mar 25, 2014 at 1:26 PM, Trevor Woerner
<trevor.woerner@linaro.org> wrote:
> On 03/25/14 08:35, Daiane.Angolini@freescale.com wrote:
>> Before defining any period. I prefer we define the "agenda for next meeting"
>>
>> We can build the agenda and when it´s big enough, we set the "next meeting".
>
> I think these meetings would be a good opportunity for maintainers to
> get together and discuss any issues they're facing leading into the next
> release. Maybe these meetings could provide an opportunity to update
> status information with respect to testing efforts in order to keep all
> the board testing moving forward as we come into the next release?

Good idea.

> I'm not implying these meetings should only be for maintainers, I'm just
> pointing them out as one example of a group who might benefit from such
> a meeting.

Sure but this is a perfect opportunity for this status update to
happen; besides it improves the social integration of the maintainers
and easy share of work and knowledge in long term.

> As such an agenda item could be:
> - short testing status from maintainers/testers

Added it in a 'section' called Status.
Tony Felice - March 26, 2014, 2:50 p.m.
Hi Otavio,

I'd prefer weekdays over weekends for meetings. We are at timezone UTC-5 (currently UTC-4 for daylight savings).

Thanks,

--
Tony Felice
Vybrid Technical Lead
Timesys Corporation

Patch

diff --git a/default.xml b/default.xml
index 0f9ba4f..b908c75 100644
--- a/default.xml
+++ b/default.xml
@@ -6,6 +6,7 @@ 
   <remote fetch="git://git.yoctoproject.org" name="yocto"/>
   <remote fetch="git://github.com/Freescale" name="freescale"/>
   <remote fetch="git://git.openembedded.org" name="oe"/>
+  <remote fetch="git://github.com" name="github"/>
 
   <project remote="yocto" revision="master" name="poky" path="sources/poky"/>
   <project remote="yocto" revision="master" name="meta-fsl-arm" path="sources/meta-fsl-arm"/>
@@ -19,5 +20,5 @@ 
 
   <project remote="freescale" revision="master" name="meta-fsl-arm-extra" path="sources/meta-fsl-arm-extra"/>
   <project remote="freescale" revision="master" name="meta-fsl-demos" path="sources/meta-fsl-demos"/>
-
+  <project remote="github" revision="master" name="meta-qt5" path="sources/meta-qt5"/>
 </manifest>