TSC Meetings for the meeting of June

TSC Meetings for the meeting of June

[Holger Freyther]

Hi all,

we didn't really have much to talk....



== Renaming the org.openmebdded.dev branch ==

We were carrying the org.openembedd.dev branch name from the monotone
era into the git era and the TSC was asked to consider renaming it to
'master' which is the git default for the main development tree. Now the
actual change on the server will be minor what is of a bigger concern
are the existing users and documentation.

The TSC would like to make the following proposal:

  a.) Contributor's will be asked to push to master, a git-hook
      will prevent pushes to the old branch name.
  b.) The default branch will be changed to 'master' and the
      documentation will be updated.
  c.) To ease this for existing users and to reduce the amount of
      support org.openembedded.dev will track master and remains
      available for a limited but long amount of time.


The TSC is not sure on how to implement c.) and this will determine when
we will be able to switch over and the schedule of doing so.

Re: TSC Meetings for the meeting of June

[Michael Smith]

Holger Freyther wrote:
>   c.) To ease this for existing users and to reduce the amount of
>       support org.openembedded.dev will track master and remains
>       available for a limited but long amount of time.

> The TSC is not sure on how to implement c.) and this will determine when
> we will be able to switch over and the schedule of doing so.

This should work (on the bare repo):

git branch -m org.openembedded.dev master
git symbolic-ref refs/heads/org.openembedded.dev refs/heads/master

(thanks 
http://stackoverflow.com/questions/549920/is-it-possible-to-alias-a-branch-in-git)

Mike

Re: TSC Meetings for the meeting of June

[Frans Meulenbroeks]

2010/6/9 Holger Freyther <holger+oe@freyther.de>:
> Hi all,
>
> we didn't really have much to talk....
>
>
>
> == Renaming the org.openmebdded.dev branch ==
>
> We were carrying the org.openembedd.dev branch name from the monotone
> era into the git era and the TSC was asked to consider renaming it to
> 'master' which is the git default for the main development tree. Now the
> actual change on the server will be minor what is of a bigger concern
> are the existing users and documentation.

Technically speaking I think we should have run an RFC for this before
it was brought to the table of the TSC.

Personally the org.openembedded.dev branch name does not bother me
although I know master is the 'standard' git name.
Afaik renaming does not really solve a problem.

I am not too sure how much this affects the current users. Actually I
doubt if the change is bigger than the packages -> recipes renaming
Isse is that if we do that we should make sure all relevant
documentation is updated, otherwise we only create confusion (which
might still creep up as people use old mailing list articles).

Considering this, I am in favour of keeping things as they are.

Frans
>
> The TSC would like to make the following proposal:
>
>  a.) Contributor's will be asked to push to master, a git-hook
>      will prevent pushes to the old branch name.
>  b.) The default branch will be changed to 'master' and the
>      documentation will be updated.
>  c.) To ease this for existing users and to reduce the amount of
>      support org.openembedded.dev will track master and remains
>      available for a limited but long amount of time.
>
>
> The TSC is not sure on how to implement c.) and this will determine when
> we will be able to switch over and the schedule of doing so.
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: TSC Meetings for the meeting of June

[Chris Larson]

On Wed, Jun 9, 2010 at 6:53 AM, Frans Meulenbroeks <
fransmeulenbroeks@gmail.com> wrote:

> 2010/6/9 Holger Freyther <holger+oe@freyther.de <holger%2Boe@freyther.de>
> >:
> > We were carrying the org.openembedd.dev branch name from the monotone
> > era into the git era and the TSC was asked to consider renaming it to
> > 'master' which is the git default for the main development tree. Now the
> > actual change on the server will be minor what is of a bigger concern
> > are the existing users and documentation.
>
> Technically speaking I think we should have run an RFC for this before
> it was brought to the table of the TSC.
>
> Personally the org.openembedded.dev branch name does not bother me
> although I know master is the 'standard' git name.
> Afaik renaming does not really solve a problem.
>

Personally, I have to type it at least a few times a day, it gets old, and I
think its time we ditched monotone remnants where we're able to do so.

I am not too sure how much this affects the current users. Actually I
> doubt if the change is bigger than the packages -> recipes renaming
> Isse is that if we do that we should make sure all relevant
> documentation is updated, otherwise we only create confusion (which
> might still creep up as people use old mailing list articles).
>
> Considering this, I am in favour of keeping things as they are.


If we implement this, I don't really see a problem doing it for the users:


>  >  c.) To ease this for existing users and to reduce the amount of
> >      support org.openembedded.dev will track master and remains
> >      available for a limited but long amount of time.
>
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: TSC Meetings for the meeting of June

[Philip Balister]

On 06/09/2010 10:57 AM, Chris Larson wrote:
> On Wed, Jun 9, 2010 at 6:53 AM, Frans Meulenbroeks<
> fransmeulenbroeks@gmail.com>  wrote:
>
>> 2010/6/9 Holger Freyther<holger+oe@freyther.de<holger%2Boe@freyther.de>
>>> :
>>> We were carrying the org.openembedd.dev branch name from the monotone
>>> era into the git era and the TSC was asked to consider renaming it to
>>> 'master' which is the git default for the main development tree. Now the
>>> actual change on the server will be minor what is of a bigger concern
>>> are the existing users and documentation.
>>
>> Technically speaking I think we should have run an RFC for this before
>> it was brought to the table of the TSC.
>>
>> Personally the org.openembedded.dev branch name does not bother me
>> although I know master is the 'standard' git name.
>> Afaik renaming does not really solve a problem.
>>
>
> Personally, I have to type it at least a few times a day, it gets old, and I
> think its time we ditched monotone remnants where we're able to do so.

I'm with Chris. The name is long and annoying. It is time to drop the 
monotone/bitkeeper remnants.

Philip

>
> I am not too sure how much this affects the current users. Actually I
>> doubt if the change is bigger than the packages ->  recipes renaming
>> Isse is that if we do that we should make sure all relevant
>> documentation is updated, otherwise we only create confusion (which
>> might still creep up as people use old mailing list articles).
>>
>> Considering this, I am in favour of keeping things as they are.
>
>
> If we implement this, I don't really see a problem doing it for the users:
>
>
>>   >   c.) To ease this for existing users and to reduce the amount of
>>>       support org.openembedded.dev will track master and remains
>>>       available for a limited but long amount of time.
>>

Re: TSC Meetings for the meeting of June

[Khem Raj]

On Wed, Jun 9, 2010 at 9:53 AM, Philip Balister <philip@balister.org> wrote:
> On 06/09/2010 10:57 AM, Chris Larson wrote:
>>
>> On Wed, Jun 9, 2010 at 6:53 AM, Frans Meulenbroeks<
>> fransmeulenbroeks@gmail.com>  wrote:
>>
>>> 2010/6/9 Holger Freyther<holger+oe@freyther.de<holger%2Boe@freyther.de>
>>>>
>>>> :
>>>> We were carrying the org.openembedd.dev branch name from the monotone
>>>> era into the git era and the TSC was asked to consider renaming it to
>>>> 'master' which is the git default for the main development tree. Now the
>>>> actual change on the server will be minor what is of a bigger concern
>>>> are the existing users and documentation.
>>>
>>> Technically speaking I think we should have run an RFC for this before
>>> it was brought to the table of the TSC.
>>>
>>> Personally the org.openembedded.dev branch name does not bother me
>>> although I know master is the 'standard' git name.
>>> Afaik renaming does not really solve a problem.
>>>
>>
>> Personally, I have to type it at least a few times a day, it gets old, and
>> I
>> think its time we ditched monotone remnants where we're able to do so.
>
> I'm with Chris. The name is long and annoying. It is time to drop the
> monotone/bitkeeper remnants.


yes I am also in favor of getting it simpler. Although I do have
bash_completion for git
still its annoying because there are more than one branch names that
start with org.openembedded.


>
> Philip
>
>>
>> I am not too sure how much this affects the current users. Actually I
>>>
>>> doubt if the change is bigger than the packages ->  recipes renaming
>>> Isse is that if we do that we should make sure all relevant
>>> documentation is updated, otherwise we only create confusion (which
>>> might still creep up as people use old mailing list articles).
>>>
>>> Considering this, I am in favour of keeping things as they are.
>>
>>
>> If we implement this, I don't really see a problem doing it for the users:
>>
>>
>>>  >   c.) To ease this for existing users and to reduce the amount of
>>>>
>>>>      support org.openembedded.dev will track master and remains
>>>>      available for a limited but long amount of time.
>>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: TSC Meetings for the meeting of June

[Frans Meulenbroeks]

Ok, as I see no-one else has objections, I'll withdraw mine, under the
assumption that when the change is made, both the user manual and
www.openembedded.org are updated at the same time the change is made.

Have fun, Frans

Re: TSC Meetings for the meeting of June

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09-06-10 15:53, Frans Meulenbroeks wrote:
> 2010/6/9 Holger Freyther <holger+oe@freyther.de>:
>> Hi all,
>>
>> we didn't really have much to talk....
>>
>>
>>
>> == Renaming the org.openmebdded.dev branch ==
>>
>> We were carrying the org.openembedd.dev branch name from the monotone
>> era into the git era and the TSC was asked to consider renaming it to
>> 'master' which is the git default for the main development tree. Now the
>> actual change on the server will be minor what is of a bigger concern
>> are the existing users and documentation.
> 
> Technically speaking I think we should have run an RFC for this before
> it was brought to the table of the TSC.
> 
> Personally the org.openembedded.dev branch name does not bother me
> although I know master is the 'standard' git name.
> Afaik renaming does not really solve a problem.

Ah well, seeing that the TSC completely failed to implement anything of
the things they decided on last month I think we can stop worrying about
this for the next few months. Does the TSC use FIFO or LIFO for their
targets?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMEoB7MkyGM64RGpERAhaEAJ4ix66HITFX983gh3axyaXRJkUEYQCgihFu
aeJb69Aqv3epd/0KxTMWgrQ=
=BqdY
-----END PGP SIGNATURE-----

Re: TSC Meetings for the meeting of June

[Richard Purdie]

On Fri, 2010-06-11 at 20:29 +0200, Koen Kooi wrote:
> > Personally the org.openembedded.dev branch name does not bother me
> > although I know master is the 'standard' git name.
> > Afaik renaming does not really solve a problem.
> 
> Ah well, seeing that the TSC completely failed to implement anything of
> the things they decided on last month I think we can stop worrying about
> this for the next few months. Does the TSC use FIFO or LIFO for their
> targets?

You've always got to be destructive and negative ;-).

How about suggesting the TSC improves its process by assigning actions
to people? That would be a bit more constructive and might address the
problem.

We're all volunteers doing this, we all have lots of things we're all
involved in and we do the best we can.

There is also nothing stopping anyone from helping the TSC, it was asked
to make a decision, not necessarily implement it although I'd agree it
would be desirable if someone on the TSC could help.

FWIW, I'm about to take a weeks vacation which is my first proper
holiday in a long time. I'll pay for it when I get back but until then
I'm aiming to enjoy it.

See you when I get back ;-).

Cheers,

Richard

Re: TSC Meetings for the meeting of June

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11-06-10 23:37, Richard Purdie wrote:
> On Fri, 2010-06-11 at 20:29 +0200, Koen Kooi wrote:
>>> Personally the org.openembedded.dev branch name does not bother me
>>> although I know master is the 'standard' git name.
>>> Afaik renaming does not really solve a problem.
>>
>> Ah well, seeing that the TSC completely failed to implement anything of
>> the things they decided on last month I think we can stop worrying about
>> this for the next few months. Does the TSC use FIFO or LIFO for their
>> targets?
> 
> You've always got to be destructive and negative ;-).
> 
> How about suggesting the TSC improves its process by assigning actions
> to people? That would be a bit more constructive and might address the
> problem.
> 
> We're all volunteers doing this, we all have lots of things we're all
> involved in and we do the best we can.
> 
> There is also nothing stopping anyone from helping the TSC, it was asked
> to make a decision, not necessarily implement it although I'd agree it
> would be desirable if someone on the TSC could help.
> 
> FWIW, I'm about to take a weeks vacation which is my first proper
> holiday in a long time. I'll pay for it when I get back but until then
> I'm aiming to enjoy it.
> 
> See you when I get back ;-).

My 2 weeks holiday starts on monday, although mine will be filled with
studying for exams :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMEzkmMkyGM64RGpERAoytAJ0cInkxyh8EdFw5AIJGyrIbLfH+1ACgqvta
SOBkogx6f+o6q2aJx1C54n0=
=sbsa
-----END PGP SIGNATURE-----

Re: TSC Meetings for the meeting of June

[Frans Meulenbroeks]

2010/6/11 Richard Purdie <rpurdie@rpsys.net>:
> On Fri, 2010-06-11 at 20:29 +0200, Koen Kooi wrote:
>> > Personally the org.openembedded.dev branch name does not bother me
>> > although I know master is the 'standard' git name.
>> > Afaik renaming does not really solve a problem.
>>
>> Ah well, seeing that the TSC completely failed to implement anything of
>> the things they decided on last month I think we can stop worrying about
>> this for the next few months. Does the TSC use FIFO or LIFO for their
>> targets?
>
> You've always got to be destructive and negative ;-).

If people pick up actions (like removing old minor versions of
recipes, someone will complain that they are touching other peoples'
recipes without consent, RFC or whatever.
It would be nice if  owners/maintainers of recipes would start to
implement the policies as outlined  by the TSC, instead of bashing
others. But no, instead of having 8 abiword recies (when I tables this
issue) we now have 10.
>
> How about suggesting the TSC improves its process by assigning actions
> to people? That would be a bit more constructive and might address the
> problem.
>
> We're all volunteers doing this, we all have lots of things we're all
> involved in and we do the best we can.
>
> There is also nothing stopping anyone from helping the TSC, it was asked
> to make a decision, not necessarily implement it although I'd agree it
> would be desirable if someone on the TSC could help.
>
> FWIW, I'm about to take a weeks vacation which is my first proper
> holiday in a long time. I'll pay for it when I get back but until then
> I'm aiming to enjoy it.

Richard, enjoy your vacation! I hope you have lots of fin.

Frans (who scurries back to the corner he decided to hide into after
the last round of negative feedback when he tried to update a recipe
for the benefit of all, without needing it  himself)

Re: TSC Meetings for the meeting of June

[Graeme Gregory]

On Sat, 12 Jun 2010 13:12:18 +0200
Frans Meulenbroeks <fransmeulenbroeks@gmail.com> wrote:
> If people pick up actions (like removing old minor versions of
> recipes, someone will complain that they are touching other peoples'
> recipes without consent, RFC or whatever.
> It would be nice if  owners/maintainers of recipes would start to
> implement the policies as outlined  by the TSC, instead of bashing
> others. But no, instead of having 8 abiword recies (when I tables this
> issue) we now have 10.

This is one of the issues we still have in our way of thinking, you see
having 10 recipes as a huge issue that has to be fixed. Some of us
don't see any need to delete recipes that are not broken. I would
expect (as one of the abiword maintainers) if I went in and do some
major change to packaging and couldnt be bothered to backport it I
would delete some of those recipes.

G

Re: TSC Meetings for the meeting of June

[Frans Meulenbroeks]

2010/6/12 Graeme Gregory <dp@xora.org.uk>:
> On Sat, 12 Jun 2010 13:12:18 +0200
> Frans Meulenbroeks <fransmeulenbroeks@gmail.com> wrote:
>> If people pick up actions (like removing old minor versions of
>> recipes, someone will complain that they are touching other peoples'
>> recipes without consent, RFC or whatever.
>> It would be nice if  owners/maintainers of recipes would start to
>> implement the policies as outlined  by the TSC, instead of bashing
>> others. But no, instead of having 8 abiword recies (when I tables this
>> issue) we now have 10.
>
> This is one of the issues we still have in our way of thinking, you see
> having 10 recipes as a huge issue that has to be fixed. Some of us
> don't see any need to delete recipes that are not broken. I would
> expect (as one of the abiword maintainers) if I went in and do some
> major change to packaging and couldnt be bothered to backport it I
> would delete some of those recipes.

Actually I just picked  abiword as an example (because it is one of
the first things that shows up, alphabetically speaking).
Actually the opie recipes that have versions 1.2.2, 1.2.3 and 1.2.4
for which the .4 fis already quite old and the others seen obsolete
bother me just as much

Rationale of getting rid of the old recipes is that it decreases parsing time.
And note that it is a git, so the old data remains available in the
git for those who want to access it. (actually that *is* one of the
purposes of a version control system)

Frans.

Re: TSC Meetings for the meeting of June

[Holger Freyther]

On 06/09/2010 09:03 PM, Holger Freyther wrote:


> The TSC would like to make the following proposal:
> 
>   a.) Contributor's will be asked to push to master, a git-hook
>       will prevent pushes to the old branch name.
>   b.) The default branch will be changed to 'master' and the
>       documentation will be updated.
>   c.) To ease this for existing users and to reduce the amount of
>       support org.openembedded.dev will track master and remains
>       available for a limited but long amount of time.


Okay, any idea about the time line? What resources to update? The Wiki
[1]? The Manual? External resources?


[1]
http://wiki.openembedded.net/index.php/Special:Search?search=%22org.openembedded.dev%22&go=Go

Re: TSC Meetings for the meeting of June

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30-06-10 12:26, Holger Freyther wrote:
> On 06/09/2010 09:03 PM, Holger Freyther wrote:
> 
> 
>> The TSC would like to make the following proposal:
>>
>>   a.) Contributor's will be asked to push to master, a git-hook
>>       will prevent pushes to the old branch name.
>>   b.) The default branch will be changed to 'master' and the
>>       documentation will be updated.
>>   c.) To ease this for existing users and to reduce the amount of
>>       support org.openembedded.dev will track master and remains
>>       available for a limited but long amount of time.
> 
> 
> Okay, any idea about the time line? What resources to update? The Wiki
> [1]? The Manual? External resources?

What about tackling the items from the previous month first before going
off on this cosmetic change that wasn't even discussed in the community
first before the TSC jumped the gun on it?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMKyTdMkyGM64RGpERAkjnAKCZRUmqOmTT7ZQZYt0BWBw5RtCukACgj/PW
d2Idn1MPoyVyDnmBgvYsoKI=
=urmp
-----END PGP SIGNATURE-----

Re: TSC Meetings for the meeting of June

[Frans Meulenbroeks]

2010/6/30 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 30-06-10 12:26, Holger Freyther wrote:
>> On 06/09/2010 09:03 PM, Holger Freyther wrote:
>>
>>
>>> The TSC would like to make the following proposal:
>>>
>>>   a.) Contributor's will be asked to push to master, a git-hook
>>>       will prevent pushes to the old branch name.
>>>   b.) The default branch will be changed to 'master' and the
>>>       documentation will be updated.
>>>   c.) To ease this for existing users and to reduce the amount of
>>>       support org.openembedded.dev will track master and remains
>>>       available for a limited but long amount of time.
>>
>>
>> Okay, any idea about the time line? What resources to update? The Wiki
>> [1]? The Manual? External resources?
>
> What about tackling the items from the previous month first before going
> off on this cosmetic change that wasn't even discussed in the community
> first before the TSC jumped the gun on it?

And the pre-previous ones?

Probably somewhere keep a list of decisions/actions.

Frans

Re: TSC Meetings for the meeting of June

[Holger Freyther]

On 06/30/2010 07:05 PM, Koen Kooi wrote:

> 
> What about tackling the items from the previous month first before going
> off on this cosmetic change that wasn't even discussed in the community
> first before the TSC jumped the gun on it?

Well,

what do you want to say with was not discussed? We would not have picked
up the topic when it was not discussed in the community as we are not
making up topics.

And rest assured personally for a non native english speaker master,
foobar, blabla has about the same semantic for a branch name (I get used
to any of those), for the native ones this was a pretty big issue...

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?

Re: TSC Meetings for the meeting of June

[Koen Kooi]

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

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.

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

Re: TSC Meetings for the meeting of June

[Frans Meulenbroeks]

2010/7/1 Koen Kooi <k.kooi@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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: TSC Meetings for the meeting of June

[Graeme Gregory]

On Thu, 1 Jul 2010 13:52:26 +0200
Frans Meulenbroeks <fransmeulenbroeks@gmail.com> wrote:
> 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.
> 
Aaaaargh how many times do I have to say this, removing a recipe just
because it is old is not acceptable to me. Removing a recipe because
its discovered old versions are broken and no DISTRO is interested in
that old version is perfectly acceptable (as long as a strong
maintainer is kept in the loop if exists).

Graeme

Re: TSC Meetings for the meeting of June

[Frans Meulenbroeks]

2010/7/1 Graeme Gregory <dp@xora.org.uk>:
> On Thu, 1 Jul 2010 13:52:26 +0200
> Frans Meulenbroeks <fransmeulenbroeks@gmail.com> wrote:
>> 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.
>>
> Aaaaargh how many times do I have to say this, removing a recipe just
> because it is old is not acceptable to me. Removing a recipe because
> its discovered old versions are broken and no DISTRO is interested in
> that old version is perfectly acceptable (as long as a strong
> maintainer is kept in the loop if exists).
>
> Graeme

Graeme, I am aware of your position on this, and I am pretty sure you
are aware of mine.

However, for the rest of the world, I'd like to clarify things.

Koen calls for action to move to new staging, BBCLASSEXTEND, nativesdk
etc, which IMHO is a good action.
However, if you want to keep older recipes this means that:
- they need to be converted too
- if they are converted one also need to test them if you are serious on quality
if you want to, be my guest. I'm just saying that I'm not going to
waste my time on this.

Personally I feel that if we want to focus on quality we better remove
the versions no one is interested in and focus our efforts, limited as
they are, on the remaining recipes.
And note that the old versions are still available in git. That is
what revision control systems are for.

Have fun! Frans

Re: TSC Meetings for the meeting of June

[Mark Brown]

On Thu, Jul 01, 2010 at 03:43:02PM +0200, Frans Meulenbroeks wrote:
> 2010/7/1 Graeme Gregory <dp@xora.org.uk>:

> > because it is old is not acceptable to me. Removing a recipe because
> > its discovered old versions are broken and no DISTRO is interested in
> > that old version is perfectly acceptable (as long as a strong
> > maintainer is kept in the loop if exists).

> Personally I feel that if we want to focus on quality we better remove
> the versions no one is interested in and focus our efforts, limited as
> they are, on the remaining recipes.

You guys appear to be agreeing furiously here - both of you are saying
that old recipies that are causing hassle and nobody is interested in
should be removed.  The fact that there's all these global changes
supposed to be going on at the minute means the situation with things
getting broken is rather different to what it would be in the normal
course of affairs.