[oe] TSC Meetings for the meeting of June

Frans Meulenbroeks fransmeulenbroeks at gmail.com
Thu Jul 1 11:52:26 UTC 2010


2010/7/1 Koen Kooi <k.kooi at student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 30-06-10 15:19, Holger Freyther wrote:
>
>> In regard to the TSC, what mode of operation do you propose? We freeze
>> the tree until all items are implemented in the order they are proposed?
>> We find people driving a topic?
>
> In this specific case you (or the TSC) choose to work on a extremely
> intrusive and controversial *cosmetic* change first instead of tackling
> the some of the (IMO more important) items agreed on earlier:
>
> * making QA checks be enabled by default
> * promoting new style staging and converting existing recipes
> * promoting bbclassextend and converting existing recipes
> * fixing nativesdk

As stated before the TSC is responsible for deciding on the road
forward, notably on controversial issues, NOT for implementing them.
The TSC handles issues that are brought up by the community.
I'd say if the TSC decided e.g. on new style staging as the way
forward it is up to the people who requested a ruling on this to take
it forward.

>
> By skipping over those, without saying why and going for the cosmetic
> change the TSC is sending out a signal that they do NOT care about
> quality, only appearance. In the past I was proud about how OE handled
> things by the things you yourself created, like insane.bbclass, the
> first edition of tinderbox, etc. But recently only 2 groups of OE
> developers seem to care about quality, the SHR and angstrom folk. Those
> are the only 2 distros that have the QA checks enabled. Due to the
> nature of OE other benefit from the awesome work Martin and Khem have
> been doing, but it feels a bit one sided to me.

I do care about quailty (although not being part of the SHR or
angstrom folks), but unfortunately your perception on quality and mine
differ substantially.
For me a goal would be to have a set of high quality recipes. Others
seem to mix up quality and quantity and think quality has to do with
having many versions of a recipe around.
Of course that does not really help to make high quality recipes.
Updating many versions is a lot more work (and not too rewarding if
you just use a single version). Also testing all those versions is a
PITA.
Net effect: either older versions are not updated, or the versions are
updated but not tested. In both cases IMHO quality-wise a less
desirable situation.

Then again, I tried to fight the version diarrhea, and I lost.So be it.
But don't come and ask me to improve the quality of recipes that IMHO
should have been discarded long time ago.

Frans.
>
> Since nearly all OE developers can't work fulltime on OE, I would
> propose that the TSC sends out a few "call to action" mails, describing
> the tasks that need doing and some guidance on how they want to see it
> done. I will *gladly* help out, but I need to know what needs doing and
> avoid duplicate work.
>
> It would help to have a "completed action items", "in progress action
> items" and "action items that noone is working on" list in the TSC
> minutes (or wiki) to keep track of stuff.
>
> And of course a big thank you to all the people working on QA that I
> didn't mention.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFMLFgrMkyGM64RGpERAtCVAJ4xp7Lxx91AwSUN7DgEwxasSjr4gACgi2/n
> qbbTDqsfC2RlFjxhRglNtZ4=
> =zIjM
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>




More information about the Openembedded-devel mailing list