Plans for OE classic future

Plans for OE classic future

[Mats Kärrman]

Hi,

Are there any plans for new releases and/or maintenance branches of OE classic?

BR / Mats

Re: Plans for OE classic future

[Henning Heinold]

On Thu, Oct 27, 2011 at 10:53:13AM +0000, Mats Kärrman wrote:
> Hi,
> 
> Are there any plans for new releases and/or maintenance branches of OE classic?
> 
> BR / Mats

Hi,

http://cgit.openembedded.org/openembedded/log/?h=org.openembedded.dev

and

http://cgit.openembedded.org/openembedded/log/?h=2011.03-maintenance

Bye Henning

PS: Feel free to update the wiki

Re: Plans for OE classic future

[Martin Jansa]

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

On Thu, Oct 27, 2011 at 01:56:43PM +0200, Henning Heinold wrote:
> On Thu, Oct 27, 2011 at 10:53:13AM +0000, Mats Kärrman wrote:
> > Hi,
> > 
> > Are there any plans for new releases and/or maintenance branches of OE classic?
> > 
> > BR / Mats
> 
> Hi,
> 
> http://cgit.openembedded.org/openembedded/log/?h=org.openembedded.dev
> 
> and
> 
> http://cgit.openembedded.org/openembedded/log/?h=2011.03-maintenance
> 
> Bye Henning

Are you showing that maintenance ibranch is not so old and that only few
things changed in old OE-classic since then? :)

Afaik: nobody plans to do another release from OE-classic and
oe-core/meta-oe/BSP's/... are veryclose to first release

Regards

> 
> PS: Feel free to update the wiki
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Plans for OE classic future

[Ulf Samuelsson]

2011-10-27 14:27, Martin Jansa skrev:
> On Thu, Oct 27, 2011 at 01:56:43PM +0200, Henning Heinold wrote:
>> On Thu, Oct 27, 2011 at 10:53:13AM +0000, Mats Kärrman wrote:
>>> Hi,
>>>
>>> Are there any plans for new releases and/or maintenance branches of OE classic?
>>>
>>> BR / Mats
>> Hi,
>>
>> http://cgit.openembedded.org/openembedded/log/?h=org.openembedded.dev
>>
>> and
>>
>> http://cgit.openembedded.org/openembedded/log/?h=2011.03-maintenance
>>
>> Bye Henning
> Are you showing that maintenance ibranch is not so old and that only few
> things changed in old OE-classic since then? :)
>
> Afaik: nobody plans to do another release from OE-classic and
> oe-core/meta-oe/BSP's/... are veryclose to first release

What repository is used for the BSP's ?

BR
Ulf Samuelsson

> Regards
>
>> PS: Feel free to update the wiki
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel


-- 
Best Regards
Ulf Samuelsson

Re: Plans for OE classic future

[Denys Dmytriyenko]

On Tue, Nov 01, 2011 at 01:38:33AM +0100, Ulf Samuelsson wrote:
> 2011-10-27 14:27, Martin Jansa skrev:
>> On Thu, Oct 27, 2011 at 01:56:43PM +0200, Henning Heinold wrote:
>>> On Thu, Oct 27, 2011 at 10:53:13AM +0000, Mats K?rrman wrote:
>>>> Hi,
>>>>
>>>> Are there any plans for new releases and/or maintenance branches of OE 
>>>> classic?
>>>>
>>>> BR / Mats
>>> Hi,
>>>
>>> http://cgit.openembedded.org/openembedded/log/?h=org.openembedded.dev
>>>
>>> and
>>>
>>> http://cgit.openembedded.org/openembedded/log/?h=2011.03-maintenance
>>>
>>> Bye Henning
>> Are you showing that maintenance ibranch is not so old and that only few
>> things changed in old OE-classic since then? :)
>>
>> Afaik: nobody plans to do another release from OE-classic and
>> oe-core/meta-oe/BSP's/... are veryclose to first release
>
> What repository is used for the BSP's ?

Each BSP in own repository - http://www.openembedded.org/wiki/LayerIndex

-- 
Denys

Re: Plans for OE classic future

[Jaap de Jong]

On 11/01/2011 02:00 AM, Denys Dmytriyenko wrote:
> On Tue, Nov 01, 2011 at 01:38:33AM +0100, Ulf Samuelsson wrote:
>> 2011-10-27 14:27, Martin Jansa skrev:
>>> On Thu, Oct 27, 2011 at 01:56:43PM +0200, Henning Heinold wrote:
>>>> On Thu, Oct 27, 2011 at 10:53:13AM +0000, Mats K?rrman wrote:
>>>>> Hi,
>>>>>
>>>>> Are there any plans for new releases and/or maintenance branches of OE
>>>>> classic?
>>>>>
>>>>> BR / Mats
>>>> Hi,
>>>>
>>>> http://cgit.openembedded.org/openembedded/log/?h=org.openembedded.dev
>>>>
>>>> and
>>>>
>>>> http://cgit.openembedded.org/openembedded/log/?h=2011.03-maintenance
>>>>
>>>> Bye Henning
>>> Are you showing that maintenance ibranch is not so old and that only few
>>> things changed in old OE-classic since then? :)
>>>
>>> Afaik: nobody plans to do another release from OE-classic and
>>> oe-core/meta-oe/BSP's/... are veryclose to first release
>> What repository is used for the BSP's ?
> Each BSP in own repository - http://www.openembedded.org/wiki/LayerIndex
>
Does anybody know where the atmel boards are? (at91sam9263ek)

Re: Plans for OE classic future

[Henning Heinold]

On Tue, Nov 01, 2011 at 08:13:18AM +0100, Jaap de Jong wrote:
> On 11/01/2011 02:00 AM, Denys Dmytriyenko wrote:
> >On Tue, Nov 01, 2011 at 01:38:33AM +0100, Ulf Samuelsson wrote:
> >>2011-10-27 14:27, Martin Jansa skrev:
> >>>On Thu, Oct 27, 2011 at 01:56:43PM +0200, Henning Heinold wrote:
> >>>>On Thu, Oct 27, 2011 at 10:53:13AM +0000, Mats K?rrman wrote:
> >>>>>Hi,
> >>>>>
> >>>>>Are there any plans for new releases and/or maintenance branches of OE
> >>>>>classic?
> >>>>>
> >>>>>BR / Mats
> >>>>Hi,
> >>>>
> >>>>http://cgit.openembedded.org/openembedded/log/?h=org.openembedded.dev
> >>>>
> >>>>and
> >>>>
> >>>>http://cgit.openembedded.org/openembedded/log/?h=2011.03-maintenance
> >>>>
> >>>>Bye Henning
> >>>Are you showing that maintenance ibranch is not so old and that only few
> >>>things changed in old OE-classic since then? :)
> >>>
> >>>Afaik: nobody plans to do another release from OE-classic and
> >>>oe-core/meta-oe/BSP's/... are veryclose to first release
> >>What repository is used for the BSP's ?
> >Each BSP in own repository - http://www.openembedded.org/wiki/LayerIndex
> >
> Does anybody know where the atmel boards are? (at91sam9263ek)

I guess Ulf has to do create it first.

Bye Henning

Re: Plans for OE classic future

[Denys Dmytriyenko]

On Thu, Oct 27, 2011 at 01:56:43PM +0200, Henning Heinold wrote:
> On Thu, Oct 27, 2011 at 10:53:13AM +0000, Mats K?rrman wrote:
> > Hi,
> > 
> > Are there any plans for new releases and/or maintenance branches of OE classic?

> http://cgit.openembedded.org/openembedded/log/?h=org.openembedded.dev
> 
> and
> 
> http://cgit.openembedded.org/openembedded/log/?h=2011.03-maintenance

Huh? Are those links to the plans?

> PS: Feel free to update the wiki

-- 
Denys

Re: Plans for OE classic future

[Tom Rini]

On Thu, Oct 27, 2011 at 10:44 AM, Denys Dmytriyenko <denis@denix.org> wrote:
> On Thu, Oct 27, 2011 at 01:56:43PM +0200, Henning Heinold wrote:
>> On Thu, Oct 27, 2011 at 10:53:13AM +0000, Mats K?rrman wrote:
>> > Hi,
>> >
>> > Are there any plans for new releases and/or maintenance branches of OE classic?
>
>> http://cgit.openembedded.org/openembedded/log/?h=org.openembedded.dev
>>
>> and)
>>
>> http://cgit.openembedded.org/openembedded/log/?h=2011.03-maintenance
>
> Huh? Are those links to the plans?

No, but putting my TSC hat on, we had talked (and this is reflected in
the minutes somewhere or another) and we aren't actively having
another maintenance release happen (if people step up to do one of
course, that's another matter).

Taking my TSC hat off, 2011.03-maintenance will continue so long as
people have a use for it and my policy was clarified at some point a
little while back that backporting from oe-core/etc directly is fine
(which is another plus of asking people to put what they want into a
branch for me to pull from rather than "cherry-pick $hash from $tree"
as the request).

-- 
Tom

Re: Plans for OE classic future

[Khem Raj]

On Thu, Oct 27, 2011 at 3:53 AM, Mats Kärrman <Mats.Karrman@tritech.se> wrote:
> Hi,
>
> Are there any plans for new releases and/or maintenance branches of OE classic?
>

2011.03-maintenance is the last release of OE classic. As long as the
branch is maintained

Re: Plans for OE classic future

[Frans Meulenbroeks]

2011/11/23 Khem Raj <raj.khem@gmail.com>

> On Thu, Oct 27, 2011 at 3:53 AM, Mats Kärrman <Mats.Karrman@tritech.se>
> wrote:
> > Hi,
> >
> > Are there any plans for new releases and/or maintenance branches of OE
> classic?
> >
>
> 2011.03-maintenance is the last release of OE classic. As long as the
> branch is maintained
>
> _
>
> Related: I noticed TSC plans to discuss on whether or not to make oe
classic read only.

I'd like to suggest leaving it open for those of us that are still using
it.
For instance I have still products that are based on OE classic. If there
is a problem that is of a generic nature, I'm more than happy to submit
patches so others in the same situation can benefit from it.
(actually I have one pending with a new version of netsnmp; the current
recipe does not build with uclibc, whereas the latest version of netsnmp
does; found/fixed this today, but haven't had time to make a commit)

And if there is no interest any more it'll eventually die. But as of now I
do see people working on/with it (see the commit log).

Frans.

Re: Plans for OE classic future

[Philip Balister]

On 11/23/2011 04:18 PM, Frans Meulenbroeks wrote:
> 2011/11/23 Khem Raj <raj.khem@gmail.com>
> 
>> On Thu, Oct 27, 2011 at 3:53 AM, Mats Kärrman <Mats.Karrman@tritech.se>
>> wrote:
>>> Hi,
>>>
>>> Are there any plans for new releases and/or maintenance branches of OE
>> classic?
>>>
>>
>> 2011.03-maintenance is the last release of OE classic. As long as the
>> branch is maintained
>>
>> _
>>
>> Related: I noticed TSC plans to discuss on whether or not to make oe
> classic read only.
> 
> I'd like to suggest leaving it open for those of us that are still using
> it.
> For instance I have still products that are based on OE classic. If there
> is a problem that is of a generic nature, I'm more than happy to submit
> patches so others in the same situation can benefit from it.
> (actually I have one pending with a new version of netsnmp; the current
> recipe does not build with uclibc, whereas the latest version of netsnmp
> does; found/fixed this today, but haven't had time to make a commit)
> 
> And if there is no interest any more it'll eventually die. But as of now I
> do see people working on/with it (see the commit log).

At some point it needs to die/go read only.

But, until oe-core + openembedded can replace it, we need to be able to
do minor updates to support already deployed systems.

Philip

Re: Plans for OE classic future

[Bernhard Guillon]

On Wed, 23 Nov 2011, Philip Balister wrote:

> At some point it needs to die/go read only.
>
> But, until oe-core + openembedded can replace it, we need to be able to
> do minor updates to support already deployed systems.

We need to rewrite the getting started wiki page [1] to point to oe-core. 
It still mentions oe-classic which confuses new users. Also the main page 
should make it clear that oe-classic is going to die and new projects 
should use oe-core. In my opinion this will help new users more than to make 
oe-core read only. Some warning message when bitbakeing something 
with oe classic would also be nice.

1 http://www.openembedded.org/wiki/Getting_started

Best regards,
Bernhard

Re: Plans for OE classic future

[Frans Meulenbroeks]

2011/11/26 Bernhard Guillon <Bernhard.Guillon@opensimpad.org>

>
>
> On Wed, 23 Nov 2011, Philip Balister wrote:
>
>  At some point it needs to die/go read only.
>>
>> But, until oe-core + openembedded can replace it, we need to be able to
>> do minor updates to support already deployed systems.
>>
>
> We need to rewrite the getting started wiki page [1] to point to oe-core.
> It still mentions oe-classic which confuses new users. Also the main page
> should make it clear that oe-classic is going to die and new projects
> should use oe-core. In my opinion this will help new users more than to
> make oe-core read only. Some warning message when bitbakeing something with
> oe classic would also be nice.
>
> 1 http://www.openembedded.org/wiki/Getting_started
>

Very good plan!
I wholehearty agree!

Frans

Re: Plans for OE classic future

[Khem Raj]

On Wed, Nov 23, 2011 at 1:18 PM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2011/11/23 Khem Raj <raj.khem@gmail.com>
>
>> On Thu, Oct 27, 2011 at 3:53 AM, Mats Kärrman <Mats.Karrman@tritech.se>
>> wrote:
>> > Hi,
>> >
>> > Are there any plans for new releases and/or maintenance branches of OE
>> classic?
>> >
>>
>> 2011.03-maintenance is the last release of OE classic. As long as the
>> branch is maintained
>>
>> _
>>
>> Related: I noticed TSC plans to discuss on whether or not to make oe
> classic read only.
>
> I'd like to suggest leaving it open for those of us that are still using
> it.

2011.03-maintenance branch is maintained and that would be place to go.


> For instance I have still products that are based on OE classic. If there
> is a problem that is of a generic nature, I'm more than happy to submit
> patches so others in the same situation can benefit from it.
> (actually I have one pending with a new version of netsnmp; the current
> recipe does not build with uclibc, whereas the latest version of netsnmp
> does; found/fixed this today, but haven't had time to make a commit)
>
> And if there is no interest any more it'll eventually die. But as of now I
> do see people working on/with it (see the commit log).

those fixes are intended for 2011.03-maintenance which go into master and then
get cherry-picked

>
> Frans.
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Plans for OE classic future

[Andreas Oberritter]

On 23.11.2011 23:25, Khem Raj wrote:
> On Wed, Nov 23, 2011 at 1:18 PM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
>> 2011/11/23 Khem Raj <raj.khem@gmail.com>
>>
>>> On Thu, Oct 27, 2011 at 3:53 AM, Mats Kärrman <Mats.Karrman@tritech.se>
>>> wrote:
>>>> Hi,
>>>>
>>>> Are there any plans for new releases and/or maintenance branches of OE
>>> classic?
>>>>
>>>
>>> 2011.03-maintenance is the last release of OE classic. As long as the
>>> branch is maintained
>>>
>>> _
>>>
>>> Related: I noticed TSC plans to discuss on whether or not to make oe
>> classic read only.
>>
>> I'd like to suggest leaving it open for those of us that are still using
>> it.
> 
> 2011.03-maintenance branch is maintained and that would be place to go.
> 
> 
>> For instance I have still products that are based on OE classic. If there
>> is a problem that is of a generic nature, I'm more than happy to submit
>> patches so others in the same situation can benefit from it.
>> (actually I have one pending with a new version of netsnmp; the current
>> recipe does not build with uclibc, whereas the latest version of netsnmp
>> does; found/fixed this today, but haven't had time to make a commit)
>>
>> And if there is no interest any more it'll eventually die. But as of now I
>> do see people working on/with it (see the commit log).
> 
> those fixes are intended for 2011.03-maintenance which go into master and then
> get cherry-picked

So master needs to stay open in order to get patches there first before
being cherry-picked into 2011.03-maintenance, right?

I also don't like the idea to make it read-only. Those who already
switched to oe-core are free to just ignore the classic master branch.
Others should still be able to push bugfixes etc, if they care enough
about it.

Regards,
Andreas

Re: Plans for OE classic future

[Mats Kärrman]

>From: openembedded-devel-bounces@lists.openembedded.org [openembedded-devel-bounces@lists.openembedded.org] on behalf of Andreas Oberritter [obi@opendreambox.org]
>Sent: Wednesday, November 23, 2011 11:42 PM
>To: openembedded-devel@lists.openembedded.org
>Subject: Re: [oe] Plans for OE classic future
>
>On 23.11.2011 23:25, Khem Raj wrote:
>> On Wed, Nov 23, 2011 at 1:18 PM, Frans Meulenbroeks
>> <fransmeulenbroeks@gmail.com> wrote:
>>> 2011/11/23 Khem Raj <raj.khem@gmail.com>
>>>
>>>> On Thu, Oct 27, 2011 at 3:53 AM, Mats Kärrman <Mats.Karrman@tritech.se>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> Are there any plans for new releases and/or maintenance branches of OE
>>>> classic?
>>>>>
>>>>
>>>> 2011.03-maintenance is the last release of OE classic. As long as the
>>>> branch is maintained
>>>>
>>>> _
>>>>
>>>> Related: I noticed TSC plans to discuss on whether or not to make oe
>>> classic read only.
>>>
>>> I'd like to suggest leaving it open for those of us that are still using
>>> it.
>>
>> 2011.03-maintenance branch is maintained and that would be place to go.
>>
>>
>>> For instance I have still products that are based on OE classic. If there
>>> is a problem that is of a generic nature, I'm more than happy to submit
>>> patches so others in the same situation can benefit from it.
>>> (actually I have one pending with a new version of netsnmp; the current
>>> recipe does not build with uclibc, whereas the latest version of netsnmp
>>> does; found/fixed this today, but haven't had time to make a commit)
>>>
>>> And if there is no interest any more it'll eventually die. But as of now I
>>> do see people working on/with it (see the commit log).
>>
>> those fixes are intended for 2011.03-maintenance which go into master and then
>> get cherry-picked
>
> So master needs to stay open in order to get patches there first before
> being cherry-picked into 2011.03-maintenance, right?
>
> I also don't like the idea to make it read-only. Those who already
> switched to oe-core are free to just ignore the classic master branch.
> Others should still be able to push bugfixes etc, if they care enough
> about it.
>
> Regards,
> Andreas

I have a project based on 2011.03-maintenance that is about to reach final
testing and I don't have the confidence (or the budget) to make a switch to
oe-core now. However only yesterday I had failing builds due to
missing/obsolete package versions.
--> One more vote to keep classic open!

BR // Mats

_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Plans for OE classic future

[Hauser, Wolfgang (external)]

I would vote for an open classic master for bugfixing too, our project based on 2011.03-maintenance goes into the final phase and to switch to oe-core, the budged is not available jet.

Regards 
Wolfgang Hauser
  
-----Ursprüngliche Nachricht-----
Von: openembedded-devel-bounces@lists.openembedded.org [mailto:openembedded-devel-bounces@lists.openembedded.org] Im Auftrag von Mats Kärrman
Gesendet: Donnerstag, 24. November 2011 09:04
An: openembedded-devel@lists.openembedded.org
Betreff: Re: [oe] Plans for OE classic future

>From: openembedded-devel-bounces@lists.openembedded.org [openembedded-devel-bounces@lists.openembedded.org] on behalf of Andreas Oberritter [obi@opendreambox.org]
>Sent: Wednesday, November 23, 2011 11:42 PM
>To: openembedded-devel@lists.openembedded.org
>Subject: Re: [oe] Plans for OE classic future
>
>On 23.11.2011 23:25, Khem Raj wrote:
>> On Wed, Nov 23, 2011 at 1:18 PM, Frans Meulenbroeks
>> <fransmeulenbroeks@gmail.com> wrote:
>>> 2011/11/23 Khem Raj <raj.khem@gmail.com>
>>>
>>>> On Thu, Oct 27, 2011 at 3:53 AM, Mats Kärrman <Mats.Karrman@tritech.se>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> Are there any plans for new releases and/or maintenance branches of OE
>>>> classic?
>>>>>
>>>>
>>>> 2011.03-maintenance is the last release of OE classic. As long as the
>>>> branch is maintained
>>>>
>>>> _
>>>>
>>>> Related: I noticed TSC plans to discuss on whether or not to make oe
>>> classic read only.
>>>
>>> I'd like to suggest leaving it open for those of us that are still using
>>> it.
>>
>> 2011.03-maintenance branch is maintained and that would be place to go.
>>
>>
>>> For instance I have still products that are based on OE classic. If there
>>> is a problem that is of a generic nature, I'm more than happy to submit
>>> patches so others in the same situation can benefit from it.
>>> (actually I have one pending with a new version of netsnmp; the current
>>> recipe does not build with uclibc, whereas the latest version of netsnmp
>>> does; found/fixed this today, but haven't had time to make a commit)
>>>
>>> And if there is no interest any more it'll eventually die. But as of now I
>>> do see people working on/with it (see the commit log).
>>
>> those fixes are intended for 2011.03-maintenance which go into master and then
>> get cherry-picked
>
> So master needs to stay open in order to get patches there first before
> being cherry-picked into 2011.03-maintenance, right?
>
> I also don't like the idea to make it read-only. Those who already
> switched to oe-core are free to just ignore the classic master branch.
> Others should still be able to push bugfixes etc, if they care enough
> about it.
>
> Regards,
> Andreas

I have a project based on 2011.03-maintenance that is about to reach final
testing and I don't have the confidence (or the budget) to make a switch to
oe-core now. However only yesterday I had failing builds due to
missing/obsolete package versions.
--> One more vote to keep classic open!

BR // Mats

_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Plans for OE classic future

[Otavio Salvador]

On Thu, Nov 24, 2011 at 08:23, Hauser, Wolfgang (external) <
Wolfgang.Hauser.external@cassidian.com> wrote:

> I would vote for an open classic master for bugfixing too, our project
> based on 2011.03-maintenance goes into the final phase and to switch to
> oe-core, the budged is not available jet.
>

I also believe oe-classic master ought to be read-only as soon as possible;
I understand that people are using it but the soonner we make it read-only,
sooner people will move to oe-core otherwise people will keep starting new
project on it and it will never die.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Plans for OE classic future

[Frans Meulenbroeks]

2011/11/24 Otavio Salvador <otavio@ossystems.com.br>

> On Thu, Nov 24, 2011 at 08:23, Hauser, Wolfgang (external) <
> Wolfgang.Hauser.external@cassidian.com> wrote:
>
> > I would vote for an open classic master for bugfixing too, our project
> > based on 2011.03-maintenance goes into the final phase and to switch to
> > oe-core, the budged is not available jet.
> >
>
> I also believe oe-classic master ought to be read-only as soon as possible;
> I understand that people are using it but the soonner we make it read-only,
> sooner people will move to oe-core otherwise people will keep starting new
> project on it and it will never die.
>
> People like Wolfgang, Mats and me are working on products that are at the
moment not in a position to move to oe-core.
Why would you want to deprive people in that situation from having a spot
(under the openembedded umbrella) under which they can share things.
Isn't sharing and cooperating what openembedded is all about ???

I understand you want people to move to oe-core, but really this should be
at the discretion of the users, and we should not give those who can not do
so right now a hard time.

Over time people will move to oe-core, as it will definitely be better
supported, have newer recipes etc. Actually for my next product I will
probably move over, but for now, with a release being imminent, moving is
not an option for me, and I consider having a place to share and exchange
bug fixes as useful.

My two cents.
Frans.

Re: Plans for OE classic future

[Otavio Salvador]

On Thu, Nov 24, 2011 at 09:24, Frans Meulenbroeks <
fransmeulenbroeks@gmail.com> wrote:

> 2011/11/24 Otavio Salvador <otavio@ossystems.com.br>
>
> > On Thu, Nov 24, 2011 at 08:23, Hauser, Wolfgang (external) <
> > Wolfgang.Hauser.external@cassidian.com> wrote:
> >
> > > I would vote for an open classic master for bugfixing too, our project
> > > based on 2011.03-maintenance goes into the final phase and to switch to
> > > oe-core, the budged is not available jet.
> > >
> >
> > I also believe oe-classic master ought to be read-only as soon as
> possible;
> > I understand that people are using it but the soonner we make it
> read-only,
> > sooner people will move to oe-core otherwise people will keep starting
> new
> > project on it and it will never die.
> >
> People like Wolfgang, Mats and me are working on products that are at the
> moment not in a position to move to oe-core.
> Why would you want to deprive people in that situation from having a spot
> (under the openembedded umbrella) under which they can share things.
> Isn't sharing and cooperating what openembedded is all about ???
>

This is not the point. Those that are bugfixes will and can be put into the
maintainence branch but new features I think ought to be sent to oe-core
and not to classic. People can always use and make their trees public
(github comes to my mind) but master keeping receiving patches commited and
new things will make it a unkillable project and even worse people will
keep starting new projects above it.


> I understand you want people to move to oe-core, but really this should be
> at the discretion of the users, and we should not give those who can not do
> so right now a hard time.
>
> Over time people will move to oe-core, as it will definitely be better
> supported, have newer recipes etc. Actually for my next product I will
> probably move over, but for now, with a release being imminent, moving is
> not an option for me, and I consider having a place to share and exchange
> bug fixes as useful.
>

Sure I fully agree and I also have projects running on oe-classic but the
point here is that it will be kept running on the maintainence branch and
thus we keep our branch above it and put fixes or improvements above it;
however all new projects are now being done above oe-core to avoid all this
hassle later.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Plans for OE classic future

[Paul Menzel]

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

Am Donnerstag, den 24.11.2011, 09:12 -0200 schrieb Otavio Salvador:
> On Thu, Nov 24, 2011 at 08:23, Hauser, Wolfgang (external) wrote:
> 
> > I would vote for an open classic master for bugfixing too, our project
> > based on 2011.03-maintenance goes into the final phase and to switch to
> > oe-core, the budged is not available jet.
> 
> I also believe oe-classic master ought to be read-only as soon as possible;
> I understand that people are using it but the soonner we make it read-only,
> sooner people will move to oe-core otherwise people will keep starting new
> project on it and it will never die.

You seem to use OE-core and meta-oe already so I understand your point
of view. Martin, Koen, Andreas and you are doing the major work for
meta-oe and not a lot of other people contribute.

In my opinion it is a bad sign to force people to switch. OE-core and
meta-oe should be so appealing that they switch by themselves. My
impression from reading the list and from IRC is that a lot of people
still have objections and are not totally comfortable. Good community
management would be to listen to these people then try to find solutions
and implement them. People then should come by themselves.


Thanks,

Paul

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Plans for OE classic future

[Otavio Salvador]

On Thu, Nov 24, 2011 at 09:33, Paul Menzel <
paulepanter@users.sourceforge.net> wrote:

> Am Donnerstag, den 24.11.2011, 09:12 -0200 schrieb Otavio Salvador:
> > On Thu, Nov 24, 2011 at 08:23, Hauser, Wolfgang (external) wrote:
> >
> > > I would vote for an open classic master for bugfixing too, our project
> > > based on 2011.03-maintenance goes into the final phase and to switch to
> > > oe-core, the budged is not available jet.
> >
> > I also believe oe-classic master ought to be read-only as soon as
> possible;
> > I understand that people are using it but the soonner we make it
> read-only,
> > sooner people will move to oe-core otherwise people will keep starting
> new
> > project on it and it will never die.
>
> You seem to use OE-core and meta-oe already so I understand your point
> of view. Martin, Koen, Andreas and you are doing the major work for
> meta-oe and not a lot of other people contribute.
>
> In my opinion it is a bad sign to force people to switch. OE-core and
> meta-oe should be so appealing that they switch by themselves. My
> impression from reading the list and from IRC is that a lot of people
> still have objections and are not totally comfortable. Good community
> management would be to listen to these people then try to find solutions
> and implement them. People then should come by themselves.
>

In fact I use both. The projects running at oe-classic are working well and
will be kept running that way but all new ones are based on oe-core +
meta-oe.

I am not against oe-classic maintainence branch and people contributting
new fixes but I am against the work on new features and recipes being put
on master branch.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Plans for OE classic future

[Koen Kooi]

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

Op 24-11-11 12:43, Otavio Salvador schreef:
> On Thu, Nov 24, 2011 at 09:33, Paul Menzel < 
> paulepanter@users.sourceforge.net> wrote:
> 
>> Am Donnerstag, den 24.11.2011, 09:12 -0200 schrieb Otavio Salvador:
>>> On Thu, Nov 24, 2011 at 08:23, Hauser, Wolfgang (external) wrote:
>>> 
>>>> I would vote for an open classic master for bugfixing too, our
>>>> project based on 2011.03-maintenance goes into the final phase and
>>>> to switch to oe-core, the budged is not available jet.
>>> 
>>> I also believe oe-classic master ought to be read-only as soon as
>> possible;
>>> I understand that people are using it but the soonner we make it
>> read-only,
>>> sooner people will move to oe-core otherwise people will keep
>>> starting
>> new
>>> project on it and it will never die.
>> 
>> You seem to use OE-core and meta-oe already so I understand your point 
>> of view. Martin, Koen, Andreas and you are doing the major work for 
>> meta-oe and not a lot of other people contribute.
>> 
>> In my opinion it is a bad sign to force people to switch. OE-core and 
>> meta-oe should be so appealing that they switch by themselves. My 
>> impression from reading the list and from IRC is that a lot of people 
>> still have objections and are not totally comfortable. Good community 
>> management would be to listen to these people then try to find
>> solutions and implement them. People then should come by themselves.
>> 
> 
> In fact I use both. The projects running at oe-classic are working well
> and will be kept running that way but all new ones are based on oe-core
> + meta-oe.

With both my angstrom and TI hat on: I use both 2011.03-maintenance and OE-core.

> I am not against oe-classic maintainence branch and people contributting 
> new fixes but I am against the work on new features and recipes being
> put on master branch.

Exactly!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAk7OgqAACgkQMkyGM64RGpF3TgCfWAfwcn7rIZD4cdfHVf1GQW1h
PiIAnRrWDAeKvSeSoitXe8JC3ZJsnRY0
=9/Cy
-----END PGP SIGNATURE-----

Re: Plans for OE classic future

[Raffaele Recalcati]

Hi,

> With both my angstrom and TI hat on: I use both 2011.03-maintenance and OE-core.

I'm starting now a project. I have a preliminary build on oe-core and
I'm trying to convince my boss to join this direction.
I'll try to put resources on it, hoping it is the right choice (I need
a stable angstrom in four months).

Thx for your work,
Raffaele

Re: Plans for OE classic future

[Frans Meulenbroeks]

Some global comments.

First of all I think it is good that we have this discussion, and that this
is discussed with the community, not solely within the TSC.

Wrt keeping master alive:

I feel it is better to have a central spot to put patches to be cherry
picked, than everyone making e.g. his own github project (at least having a
central spot is less work and less cumbersome).
Cherry picking from oe-core/meta-oe is of course also possible, but also
has a higher chance to encounter problems. E.g. the patch may not apply or
the recipe may not be parseable by the bitbake used in maintenance (because
oe-core uses a newer bitbake or different class files).

Also switching from master to the maintenance branch may not be possible
for all projects. This may depend on phase of the project, internal
policies, time etc.
(actually I did a test to move one of my projects to the maintenance
branch, several of the recipes did not fetch any more (mostly due to the
kernel.org situation))

For me, and from reading the discussion master still serves a need for some
of us, so why close it down. Actually I have not really heard any
compelling (compelling to me that is) reason to close it down.
Yes, for new projects most likely oe-core is the best choice, but I feel
people are capable enough to make that choice themselves; and, over time,
both the classic master branch and maintenance branch will die. For now it
is still useful for some of us, so my preference would be to keep it
available and writable (if only as a sort of 'alpha/draft' version of
maintenance).

After all, isn't one of the purposes of OE to promote information sharing,
cooperation and the use of openembedded technology (and not make things
harder).

Best regards, Frans

'PS: Thinking of it, we might consider a README file; and/or some text in
the git description to suggest not to use classic for new developments.

Re: Plans for OE classic future

[Otavio Salvador]

On Fri, Nov 25, 2011 at 05:31, Frans Meulenbroeks <
fransmeulenbroeks@gmail.com> wrote:

> ..

'PS: Thinking of it, we might consider a README file; and/or some text in
> the git description to suggest not to use classic for new developments.


I fully support it.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Plans for OE classic future

[Tom Rini]

On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:

> After all, isn't one of the purposes of OE to promote information sharing,
> cooperation and the use of openembedded technology (and not make things
> harder).

One of the points of making master read-only would be to ensure that
changes aren't lost.

Perhaps the transition needs to be:
- master is as it is today
- master becomes oe-core backport || master-only bugfixes only
- master becomes read only.

And we go from the first step to the second step sometime sooner
rather than later.  The top of my head date would be before the
paid-developers go on end of year breaks to try and make sure all the
hobbyist folks start their hacking with oe-core+etc rather than master
and risk getting caught later.  I'm open to arguments on why that's
exactly backwards...

-- 
Tom

Re: Plans for OE classic future

[Ulf Samuelsson]

On 2011-11-25 23:04, Tom Rini wrote:
> On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com>  wrote:
>
>> After all, isn't one of the purposes of OE to promote information sharing,
>> cooperation and the use of openembedded technology (and not make things
>> harder).
> One of the points of making master read-only would be to ensure that
> changes aren't lost.
>
> Perhaps the transition needs to be:
> - master is as it is today
> - master becomes oe-core backport || master-only bugfixes only
> - master becomes read only.
>
> And we go from the first step to the second step sometime sooner
> rather than later.  The top of my head date would be before the
> paid-developers go on end of year breaks to try and make sure all the
> hobbyist folks start their hacking with oe-core+etc rather than master
> and risk getting caught later.  I'm open to arguments on why that's
> exactly backwards...
>

Won't it be a problem for existing projects, if you cannot add fixes to 
cope with new host OS versions.

At the moment, openembedded-classic does not build properly with Ubuntu 
11.10 .

-- 
Best Regards
Ulf Samuelsson

Re: Plans for OE classic future

[Tom Rini]

On Sat, Nov 26, 2011 at 3:57 AM, Ulf Samuelsson
<ulf_samuelsson@telia.com> wrote:
> On 2011-11-25 23:04, Tom Rini wrote:
>>
>> On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks
>> <fransmeulenbroeks@gmail.com>  wrote:
>>
>>> After all, isn't one of the purposes of OE to promote information
>>> sharing,
>>> cooperation and the use of openembedded technology (and not make things
>>> harder).
>>
>> One of the points of making master read-only would be to ensure that
>> changes aren't lost.
>>
>> Perhaps the transition needs to be:
>> - master is as it is today
>> - master becomes oe-core backport || master-only bugfixes only
>> - master becomes read only.
>>
>> And we go from the first step to the second step sometime sooner
>> rather than later.  The top of my head date would be before the
>> paid-developers go on end of year breaks to try and make sure all the
>> hobbyist folks start their hacking with oe-core+etc rather than master
>> and risk getting caught later.  I'm open to arguments on why that's
>> exactly backwards...
>>
>
> Won't it be a problem for existing projects, if you cannot add fixes to cope
> with new host OS versions.
>
> At the moment, openembedded-classic does not build properly with Ubuntu
> 11.10 .

Won't what be a problem?  Either oe-core+meta-oe+etc fails on 11.10
(so, fix it there first then backport changes) or it's fine and you
can either find the relevant changes there and move them or it's a
oe.dev-only bug and just needs to be fixed, under my proposal (until
we reach the point where everyone is OK calling it r/o).

And part of this is to say that yes, existing projects external to
oe.dev need to move to oe-core(+meta-oe+whatever else) (where layers
should be making their life easier or again, there's problems we're
unaware of and need to be made aware of) or explain why they can't
ever move (and are forking the project?).

-- 
Tom

Re: Plans for OE classic future

[Frans Meulenbroeks]

2011/11/26 Tom Rini <tom.rini@gmail.com>

> On Sat, Nov 26, 2011 at 3:57 AM, Ulf Samuelsson
> <ulf_samuelsson@telia.com> wrote:
> > On 2011-11-25 23:04, Tom Rini wrote:
> >>
> >> On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks
> >> <fransmeulenbroeks@gmail.com>  wrote:
> >>
> >>> After all, isn't one of the purposes of OE to promote information
> >>> sharing,
> >>> cooperation and the use of openembedded technology (and not make things
> >>> harder).
> >>
> >> One of the points of making master read-only would be to ensure that
> >> changes aren't lost.
> >>
> >> Perhaps the transition needs to be:
> >> - master is as it is today
> >> - master becomes oe-core backport || master-only bugfixes only
> >> - master becomes read only.
> >>
> >> And we go from the first step to the second step sometime sooner
> >> rather than later.  The top of my head date would be before the
> >> paid-developers go on end of year breaks to try and make sure all the
> >> hobbyist folks start their hacking with oe-core+etc rather than master
> >> and risk getting caught later.  I'm open to arguments on why that's
> >> exactly backwards...
> >>
> >
> > Won't it be a problem for existing projects, if you cannot add fixes to
> cope
> > with new host OS versions.
> >
> > At the moment, openembedded-classic does not build properly with Ubuntu
> > 11.10 .
>
> Won't what be a problem?  Either oe-core+meta-oe+etc fails on 11.10
> (so, fix it there first then backport changes) or it's fine and you
> can either find the relevant changes there and move them or it's a
> oe.dev-only bug and just needs to be fixed, under my proposal (until
> we reach the point where everyone is OK calling it r/o).
>
> And part of this is to say that yes, existing projects external to
> oe.dev need to move to oe-core(+meta-oe+whatever else) (where layers
> should be making their life easier or again, there's problems we're
> unaware of and need to be made aware of) or explain why they can't
> ever move (and are forking the project?).
>

See the message on NIOS that I just posted.
Also I am not opposed to making oe classic master the place where patches
may land before they end up in the maintenance thread, but I am strongly
opposed to making OE classic read only on short notice (which as suggested
by Koen earlier).

Frans

Re: Plans for OE classic future

[Tom Rini]

On Sat, Nov 26, 2011 at 8:49 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2011/11/26 Tom Rini <tom.rini@gmail.com>
>
>> On Sat, Nov 26, 2011 at 3:57 AM, Ulf Samuelsson
>> <ulf_samuelsson@telia.com> wrote:
>> > On 2011-11-25 23:04, Tom Rini wrote:
>> >>
>> >> On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks
>> >> <fransmeulenbroeks@gmail.com>  wrote:
>> >>
>> >>> After all, isn't one of the purposes of OE to promote information
>> >>> sharing,
>> >>> cooperation and the use of openembedded technology (and not make things
>> >>> harder).
>> >>
>> >> One of the points of making master read-only would be to ensure that
>> >> changes aren't lost.
>> >>
>> >> Perhaps the transition needs to be:
>> >> - master is as it is today
>> >> - master becomes oe-core backport || master-only bugfixes only
>> >> - master becomes read only.
>> >>
>> >> And we go from the first step to the second step sometime sooner
>> >> rather than later.  The top of my head date would be before the
>> >> paid-developers go on end of year breaks to try and make sure all the
>> >> hobbyist folks start their hacking with oe-core+etc rather than master
>> >> and risk getting caught later.  I'm open to arguments on why that's
>> >> exactly backwards...
>> >>
>> >
>> > Won't it be a problem for existing projects, if you cannot add fixes to
>> cope
>> > with new host OS versions.
>> >
>> > At the moment, openembedded-classic does not build properly with Ubuntu
>> > 11.10 .
>>
>> Won't what be a problem?  Either oe-core+meta-oe+etc fails on 11.10
>> (so, fix it there first then backport changes) or it's fine and you
>> can either find the relevant changes there and move them or it's a
>> oe.dev-only bug and just needs to be fixed, under my proposal (until
>> we reach the point where everyone is OK calling it r/o).
>>
>> And part of this is to say that yes, existing projects external to
>> oe.dev need to move to oe-core(+meta-oe+whatever else) (where layers
>> should be making their life easier or again, there's problems we're
>> unaware of and need to be made aware of) or explain why they can't
>> ever move (and are forking the project?).
>
> See the message on NIOS that I just posted.

Addressed there :)

> Also I am not opposed to making oe classic master the place where patches
> may land before they end up in the maintenance thread, but I am strongly
> opposed to making OE classic read only on short notice (which as suggested
> by Koen earlier).

I believe master needs to go read-only, or at least
backport||master-only-problems bugfix only, sooner rather than later.

The arguments seem to be:
- Some people or projects use master and can't move
* So don't move, but do expect to need to either migrate to
2011.03-maintenance or carry more fixes locally.  With my
2011.03-maintenance hat on, if someone says for my project to move I
need N patches moved from master to maintenance, I'm fine reviewing
that pull request.

- There's concern that $something won't be able to work with oe-core+meta-oe+etc
* These are problems that either need to be fixed or assumptions that
aren't correct.

- Lack of recipes in meta-oe
* The recipes people need have been moved, stuff that isn't can be
when someone needs it.  id3lib was mentioned as an example of why
there might be problems getting things moved to meta-oe.  I can't help
but notice it's also been moved into meta-oe.

-- 
Tom

Re: Plans for OE classic future

[Paul Menzel]

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

Am Samstag, den 26.11.2011, 14:36 -0700 schrieb Tom Rini:
> On Sat, Nov 26, 2011 at 8:49 AM, Frans Meulenbroeks wrote:
> > 2011/11/26 Tom Rini
> >
> >> On Sat, Nov 26, 2011 at 3:57 AM, Ulf Samuelsson wrote:
> >> > On 2011-11-25 23:04, Tom Rini wrote:
> >> >>
> >> >> On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks wrote:
> >> >>
> >> >>> After all, isn't one of the purposes of OE to promote information
> >> >>> sharing,
> >> >>> cooperation and the use of openembedded technology (and not make things
> >> >>> harder).
> >> >>
> >> >> One of the points of making master read-only would be to ensure that
> >> >> changes aren't lost.
> >> >>
> >> >> Perhaps the transition needs to be:
> >> >> - master is as it is today
> >> >> - master becomes oe-core backport || master-only bugfixes only
> >> >> - master becomes read only.
> >> >>
> >> >> And we go from the first step to the second step sometime sooner
> >> >> rather than later.  The top of my head date would be before the
> >> >> paid-developers go on end of year breaks to try and make sure all the
> >> >> hobbyist folks start their hacking with oe-core+etc rather than master
> >> >> and risk getting caught later.  I'm open to arguments on why that's
> >> >> exactly backwards...
> >> >>
> >> >
> >> > Won't it be a problem for existing projects, if you cannot add fixes to
> >> cope
> >> > with new host OS versions.
> >> >
> >> > At the moment, openembedded-classic does not build properly with Ubuntu
> >> > 11.10 .
> >>
> >> Won't what be a problem?  Either oe-core+meta-oe+etc fails on 11.10
> >> (so, fix it there first then backport changes) or it's fine and you
> >> can either find the relevant changes there and move them or it's a
> >> oe.dev-only bug and just needs to be fixed, under my proposal (until
> >> we reach the point where everyone is OK calling it r/o).
> >>
> >> And part of this is to say that yes, existing projects external to
> >> oe.dev need to move to oe-core(+meta-oe+whatever else) (where layers
> >> should be making their life easier or again, there's problems we're
> >> unaware of and need to be made aware of) or explain why they can't
> >> ever move (and are forking the project?).
> >
> > See the message on NIOS that I just posted.
> 
> Addressed there :)
> 
> > Also I am not opposed to making oe classic master the place where patches
> > may land before they end up in the maintenance thread, but I am strongly
> > opposed to making OE classic read only on short notice (which as suggested
> > by Koen earlier).
> 
> I believe master needs to go read-only, or at least
> backport||master-only-problems bugfix only, sooner rather than later.
> 
> The arguments seem to be:
> - Some people or projects use master and can't move
> * So don't move, but do expect to need to either migrate to
> 2011.03-maintenance or carry more fixes locally.

This is still not understandable. I understand that you want developers
to move to OE-core and meta-oe. But trying to force people by making
master read-only is the wrong way. It just arbitrarily puts a burden on
current users. You can advertise prominently that OE-core and meta-oe
should be used. Over the time people will move and a lot of people have
expressed their willingness to move in the future.

> With my
> 2011.03-maintenance hat on, if someone says for my project to move I
> need N patches moved from master to maintenance, I'm fine reviewing
> that pull request.

I thought that was always possible in the past.

> - There's concern that $something won't be able to work with oe-core+meta-oe+etc
> * These are problems that either need to be fixed or assumptions that
> aren't correct.
> 
> - Lack of recipes in meta-oe
> * The recipes people need have been moved, stuff that isn't can be
> when someone needs it.  id3lib was mentioned as an example of why
> there might be problems getting things moved to meta-oe.  I can't help
> but notice it's also been moved into meta-oe.

As Bernhard noted in this reply. OE-Core and meta-oe seriously lack
documentation. And if it is just that our Wiki currently is still based
on OE-classic. And in my experience not a lot of people put effort
behind it and just neglect it.

(New users will search for tutorials and help on the WWW and there
currently a lot is dealing with OE-classic.)


Thanks,

Paul

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Plans for OE classic future

[Tom Rini]

On Sat, Nov 26, 2011 at 3:01 PM, Paul Menzel
<paulepanter@users.sourceforge.net> wrote:
> Am Samstag, den 26.11.2011, 14:36 -0700 schrieb Tom Rini:
>> On Sat, Nov 26, 2011 at 8:49 AM, Frans Meulenbroeks wrote:
>> > 2011/11/26 Tom Rini
>> >
>> >> On Sat, Nov 26, 2011 at 3:57 AM, Ulf Samuelsson wrote:
>> >> > On 2011-11-25 23:04, Tom Rini wrote:
>> >> >>
>> >> >> On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks wrote:
>> >> >>
>> >> >>> After all, isn't one of the purposes of OE to promote information
>> >> >>> sharing,
>> >> >>> cooperation and the use of openembedded technology (and not make things
>> >> >>> harder).
>> >> >>
>> >> >> One of the points of making master read-only would be to ensure that
>> >> >> changes aren't lost.
>> >> >>
>> >> >> Perhaps the transition needs to be:
>> >> >> - master is as it is today
>> >> >> - master becomes oe-core backport || master-only bugfixes only
>> >> >> - master becomes read only.
>> >> >>
>> >> >> And we go from the first step to the second step sometime sooner
>> >> >> rather than later.  The top of my head date would be before the
>> >> >> paid-developers go on end of year breaks to try and make sure all the
>> >> >> hobbyist folks start their hacking with oe-core+etc rather than master
>> >> >> and risk getting caught later.  I'm open to arguments on why that's
>> >> >> exactly backwards...
>> >> >>
>> >> >
>> >> > Won't it be a problem for existing projects, if you cannot add fixes to
>> >> cope
>> >> > with new host OS versions.
>> >> >
>> >> > At the moment, openembedded-classic does not build properly with Ubuntu
>> >> > 11.10 .
>> >>
>> >> Won't what be a problem?  Either oe-core+meta-oe+etc fails on 11.10
>> >> (so, fix it there first then backport changes) or it's fine and you
>> >> can either find the relevant changes there and move them or it's a
>> >> oe.dev-only bug and just needs to be fixed, under my proposal (until
>> >> we reach the point where everyone is OK calling it r/o).
>> >>
>> >> And part of this is to say that yes, existing projects external to
>> >> oe.dev need to move to oe-core(+meta-oe+whatever else) (where layers
>> >> should be making their life easier or again, there's problems we're
>> >> unaware of and need to be made aware of) or explain why they can't
>> >> ever move (and are forking the project?).
>> >
>> > See the message on NIOS that I just posted.
>>
>> Addressed there :)
>>
>> > Also I am not opposed to making oe classic master the place where patches
>> > may land before they end up in the maintenance thread, but I am strongly
>> > opposed to making OE classic read only on short notice (which as suggested
>> > by Koen earlier).
>>
>> I believe master needs to go read-only, or at least
>> backport||master-only-problems bugfix only, sooner rather than later.
>>
>> The arguments seem to be:
>> - Some people or projects use master and can't move
>> * So don't move, but do expect to need to either migrate to
>> 2011.03-maintenance or carry more fixes locally.
>
> This is still not understandable. I understand that you want developers
> to move to OE-core and meta-oe. But trying to force people by making
> master read-only is the wrong way. It just arbitrarily puts a burden on
> current users. You can advertise prominently that OE-core and meta-oe
> should be used. Over the time people will move and a lot of people have
> expressed their willingness to move in the future.

Well, on this side of the fence I think we're unclear what more needs
to be said.  In my mind, we couldn't do a technical branching of the
repository, we made a new one.  But people are still working off of a
branch made against an 8 month old snapshot.  We really want to
encourage this to stop.  If we were all in one repository still, it
woud be people saying "don't make legacy/main read-only!  I still want
to add things to it!".

>> With my
>> 2011.03-maintenance hat on, if someone says for my project to move I
>> need N patches moved from master to maintenance, I'm fine reviewing
>> that pull request.
>
> I thought that was always possible in the past.

It always has been, but since there's been confusion apparently about
what can and cannot happen with the branch today, I want to spell it
out.  I would be very happy to review whatever changes need to come in
from master that would make $project be able to say "OK, I can use the
maintenance branch until we have the time to move to oe-core/etc".

>> - There's concern that $something won't be able to work with oe-core+meta-oe+etc
>> * These are problems that either need to be fixed or assumptions that
>> aren't correct.
>>
>> - Lack of recipes in meta-oe
>> * The recipes people need have been moved, stuff that isn't can be
>> when someone needs it.  id3lib was mentioned as an example of why
>> there might be problems getting things moved to meta-oe.  I can't help
>> but notice it's also been moved into meta-oe.
>
> As Bernhard noted in this reply. OE-Core and meta-oe seriously lack
> documentation. And if it is just that our Wiki currently is still based
> on OE-classic. And in my experience not a lot of people put effort
> behind it and just neglect it.
>
> (New users will search for tutorials and help on the WWW and there
> currently a lot is dealing with OE-classic.)

Yes, and this is why I can understand wikihate.  So, consider this a
beg for help, from anyone that likes wiki editing.  There's content to
be updated, people that will answer questions when it's not clear, but
just can't get into the groove on editing the wiki.

-- 
Tom

Re: Plans for OE classic future

[Paul Menzel]

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

Am Samstag, den 26.11.2011, 15:33 -0700 schrieb Tom Rini:
> On Sat, Nov 26, 2011 at 3:01 PM, Paul Menzel wrote:
> > Am Samstag, den 26.11.2011, 14:36 -0700 schrieb Tom Rini:
> >> On Sat, Nov 26, 2011 at 8:49 AM, Frans Meulenbroeks wrote:
> >> > 2011/11/26 Tom Rini
> >> >
> >> >> On Sat, Nov 26, 2011 at 3:57 AM, Ulf Samuelsson wrote:
> >> >> > On 2011-11-25 23:04, Tom Rini wrote:
> >> >> >>
> >> >> >> On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks wrote:
> >> >> >>
> >> >> >>> After all, isn't one of the purposes of OE to promote information
> >> >> >>> sharing,
> >> >> >>> cooperation and the use of openembedded technology (and not make things
> >> >> >>> harder).
> >> >> >>
> >> >> >> One of the points of making master read-only would be to ensure that
> >> >> >> changes aren't lost.
> >> >> >>
> >> >> >> Perhaps the transition needs to be:
> >> >> >> - master is as it is today
> >> >> >> - master becomes oe-core backport || master-only bugfixes only
> >> >> >> - master becomes read only.
> >> >> >>
> >> >> >> And we go from the first step to the second step sometime sooner
> >> >> >> rather than later.  The top of my head date would be before the
> >> >> >> paid-developers go on end of year breaks to try and make sure all the
> >> >> >> hobbyist folks start their hacking with oe-core+etc rather than master
> >> >> >> and risk getting caught later.  I'm open to arguments on why that's
> >> >> >> exactly backwards...
> >> >> >>
> >> >> >
> >> >> > Won't it be a problem for existing projects, if you cannot add fixes to
> >> >> cope
> >> >> > with new host OS versions.
> >> >> >
> >> >> > At the moment, openembedded-classic does not build properly with Ubuntu
> >> >> > 11.10 .
> >> >>
> >> >> Won't what be a problem?  Either oe-core+meta-oe+etc fails on 11.10
> >> >> (so, fix it there first then backport changes) or it's fine and you
> >> >> can either find the relevant changes there and move them or it's a
> >> >> oe.dev-only bug and just needs to be fixed, under my proposal (until
> >> >> we reach the point where everyone is OK calling it r/o).
> >> >>
> >> >> And part of this is to say that yes, existing projects external to
> >> >> oe.dev need to move to oe-core(+meta-oe+whatever else) (where layers
> >> >> should be making their life easier or again, there's problems we're
> >> >> unaware of and need to be made aware of) or explain why they can't
> >> >> ever move (and are forking the project?).
> >> >
> >> > See the message on NIOS that I just posted.
> >>
> >> Addressed there :)
> >>
> >> > Also I am not opposed to making oe classic master the place where patches
> >> > may land before they end up in the maintenance thread, but I am strongly
> >> > opposed to making OE classic read only on short notice (which as suggested
> >> > by Koen earlier).
> >>
> >> I believe master needs to go read-only, or at least
> >> backport||master-only-problems bugfix only, sooner rather than later.
> >>
> >> The arguments seem to be:
> >> - Some people or projects use master and can't move
> >> * So don't move, but do expect to need to either migrate to
> >> 2011.03-maintenance or carry more fixes locally.
> >
> > This is still not understandable. I understand that you want developers
> > to move to OE-core and meta-oe. But trying to force people by making
> > master read-only is the wrong way. It just arbitrarily puts a burden on
> > current users. You can advertise prominently that OE-core and meta-oe
> > should be used. Over the time people will move and a lot of people have
> > expressed their willingness to move in the future.
> 
> Well, on this side of the fence I think we're unclear what more needs
> to be said.

Like Frans and Bernhard wrote, for new users a README on OE-classic
would be nice and the Wiki needs to be updated. Maybe also a deprecation
notice when pulling from the master branch.

For old users as also written no further comments are needed. They are
experienced enough and have heard your arguments. Now you should let
them make their own decisions even if you do not like it.

> In my mind, we couldn't do a technical branching of the repository, we
> made a new one. But people are still working off of a branch made
> against an 8 month old snapshot.  We really want to encourage this to
> stop.  If we were all in one repository still, it would be people
> saying "don't make legacy/main read-only!  I still want to add things
> to it!".

I did not understand that paragraph. Sorry.

> >> With my
> >> 2011.03-maintenance hat on, if someone says for my project to move I
> >> need N patches moved from master to maintenance, I'm fine reviewing
> >> that pull request.
> >
> > I thought that was always possible in the past.
> 
> It always has been, but since there's been confusion apparently about
> what can and cannot happen with the branch today, I want to spell it
> out.  I would be very happy to review whatever changes need to come in
> from master that would make $project be able to say "OK, I can use the
> maintenance branch until we have the time to move to oe-core/etc".
> 
> >> - There's concern that $something won't be able to work with oe-core+meta-oe+etc
> >> * These are problems that either need to be fixed or assumptions that
> >> aren't correct.
> >>
> >> - Lack of recipes in meta-oe
> >> * The recipes people need have been moved, stuff that isn't can be
> >> when someone needs it.  id3lib was mentioned as an example of why
> >> there might be problems getting things moved to meta-oe.  I can't help
> >> but notice it's also been moved into meta-oe.
> >
> > As Bernhard noted in this reply. OE-Core and meta-oe seriously lack
> > documentation. And if it is just that our Wiki currently is still based
> > on OE-classic. And in my experience not a lot of people put effort
> > behind it and just neglect it.
> >
> > (New users will search for tutorials and help on the WWW and there
> > currently a lot is dealing with OE-classic.)
> 
> Yes, and this is why I can understand wikihate.  So, consider this a
> beg for help, from anyone that likes wiki editing.  There's content to
> be updated, people that will answer questions when it's not clear, but
> just can't get into the groove on editing the wiki.

A lot of developers do not like to document things or to use a Web-Wiki.
I can understand the Wiki part because in my opinion a Web editor is
just unusable.

In my opinion the the community should seriously think about if a
MediaWiki setup has proven successful and if they think not first think
about if a Wiki is needed at all, secondly what should be documented and
lastly what tools developers might use.

There are a lot of Wiki setups maintained in a repository like ikiwiki
[1]. Adding a requirement to the guidelines that documentation also has
be updated would be a feasible solution in my opinion developers could
also live with since it is all managed in one repository.

There has been a thread about this in the past I think. So please open a
new thread if you put that up on the agenda.


Thanks,

Paul


[1] http://ikiwiki.info/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Plans for OE classic future

[Tom Rini]

On Sat, Nov 26, 2011 at 3:49 PM, Paul Menzel
<paulepanter@users.sourceforge.net> wrote:
> Am Samstag, den 26.11.2011, 15:33 -0700 schrieb Tom Rini:
>> On Sat, Nov 26, 2011 at 3:01 PM, Paul Menzel wrote:
>> > Am Samstag, den 26.11.2011, 14:36 -0700 schrieb Tom Rini:
>> >> On Sat, Nov 26, 2011 at 8:49 AM, Frans Meulenbroeks wrote:
>> >> > 2011/11/26 Tom Rini
>> >> >
>> >> >> On Sat, Nov 26, 2011 at 3:57 AM, Ulf Samuelsson wrote:
>> >> >> > On 2011-11-25 23:04, Tom Rini wrote:
>> >> >> >>
>> >> >> >> On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks wrote:
>> >> >> >>
>> >> >> >>> After all, isn't one of the purposes of OE to promote information
>> >> >> >>> sharing,
>> >> >> >>> cooperation and the use of openembedded technology (and not make things
>> >> >> >>> harder).
>> >> >> >>
>> >> >> >> One of the points of making master read-only would be to ensure that
>> >> >> >> changes aren't lost.
>> >> >> >>
>> >> >> >> Perhaps the transition needs to be:
>> >> >> >> - master is as it is today
>> >> >> >> - master becomes oe-core backport || master-only bugfixes only
>> >> >> >> - master becomes read only.
>> >> >> >>
>> >> >> >> And we go from the first step to the second step sometime sooner
>> >> >> >> rather than later.  The top of my head date would be before the
>> >> >> >> paid-developers go on end of year breaks to try and make sure all the
>> >> >> >> hobbyist folks start their hacking with oe-core+etc rather than master
>> >> >> >> and risk getting caught later.  I'm open to arguments on why that's
>> >> >> >> exactly backwards...
>> >> >> >>
>> >> >> >
>> >> >> > Won't it be a problem for existing projects, if you cannot add fixes to
>> >> >> cope
>> >> >> > with new host OS versions.
>> >> >> >
>> >> >> > At the moment, openembedded-classic does not build properly with Ubuntu
>> >> >> > 11.10 .
>> >> >>
>> >> >> Won't what be a problem?  Either oe-core+meta-oe+etc fails on 11.10
>> >> >> (so, fix it there first then backport changes) or it's fine and you
>> >> >> can either find the relevant changes there and move them or it's a
>> >> >> oe.dev-only bug and just needs to be fixed, under my proposal (until
>> >> >> we reach the point where everyone is OK calling it r/o).
>> >> >>
>> >> >> And part of this is to say that yes, existing projects external to
>> >> >> oe.dev need to move to oe-core(+meta-oe+whatever else) (where layers
>> >> >> should be making their life easier or again, there's problems we're
>> >> >> unaware of and need to be made aware of) or explain why they can't
>> >> >> ever move (and are forking the project?).
>> >> >
>> >> > See the message on NIOS that I just posted.
>> >>
>> >> Addressed there :)
>> >>
>> >> > Also I am not opposed to making oe classic master the place where patches
>> >> > may land before they end up in the maintenance thread, but I am strongly
>> >> > opposed to making OE classic read only on short notice (which as suggested
>> >> > by Koen earlier).
>> >>
>> >> I believe master needs to go read-only, or at least
>> >> backport||master-only-problems bugfix only, sooner rather than later.
>> >>
>> >> The arguments seem to be:
>> >> - Some people or projects use master and can't move
>> >> * So don't move, but do expect to need to either migrate to
>> >> 2011.03-maintenance or carry more fixes locally.
>> >
>> > This is still not understandable. I understand that you want developers
>> > to move to OE-core and meta-oe. But trying to force people by making
>> > master read-only is the wrong way. It just arbitrarily puts a burden on
>> > current users. You can advertise prominently that OE-core and meta-oe
>> > should be used. Over the time people will move and a lot of people have
>> > expressed their willingness to move in the future.
>>
>> Well, on this side of the fence I think we're unclear what more needs
>> to be said.
>
> Like Frans and Bernhard wrote, for new users a README on OE-classic
> would be nice and the Wiki needs to be updated. Maybe also a deprecation
> notice when pulling from the master branch.

All sounds fine to me.

> For old users as also written no further comments are needed. They are
> experienced enough and have heard your arguments. Now you should let
> them make their own decisions even if you do not like it.

So the question is, what is the long term plan for classic OE based
stuff?  The TSC has been saying, perhaps not with enough voice or
emphasis:
- 2011.03 is the last "release" of oe.dev (unless someone(s) step up
and wish to do another!)
- 2011.03-maintenance will be maintained as long as people are saying
they have a need for it.
- The master branch needs to go away somehow as the last step of
migration.  This is what I was trying to say below...

>> In my mind, we couldn't do a technical branching of the repository, we
>> made a new one. But people are still working off of a branch made
>> against an 8 month old snapshot.  We really want to encourage this to
>> stop.  If we were all in one repository still, it would be people
>> saying "don't make legacy/main read-only!  I still want to add things
>> to it!".
>
> I did not understand that paragraph. Sorry.

The analogy I'm trying to make between classic OE master branch and
behavior is that it wasn't "lets start from scratch with this new
repository and hope someday most people stop using the old tree" it
was "if we could cleanly do a 'git branch -m master legacy' and start
master as the new meta-oe repository, we would".

Now I'm going to make a Linux Kernel analogy.  The 2.4 series didn't
(nearly) go away for a long while after 2.6 came out, but after a
while the rules for what could go in got rather restrictive.

The direction the TSC has recommended for how to deal with classic OE
is to have the folks that can't yet move off of it be using the
maintenance branch.  It's not going to be pulled out from under
anyone.  It's just got rules about what kind of changes are allowed
in.  Today that's "must exist in relevant oe-core based layer or be
N/A in that world".  I can't imagine that changing until the user base
is small enough and themselves in a maintenance mode to be happy with
that too.

If anything it seems like there's an objection to switching classic OE
from "free for all" to the pull request (or patches posted) model
oe-core/meta-oe/etc are using.

[snip]
>> > As Bernhard noted in this reply. OE-Core and meta-oe seriously lack
>> > documentation. And if it is just that our Wiki currently is still based
>> > on OE-classic. And in my experience not a lot of people put effort
>> > behind it and just neglect it.
>> >
>> > (New users will search for tutorials and help on the WWW and there
>> > currently a lot is dealing with OE-classic.)
>>
>> Yes, and this is why I can understand wikihate.  So, consider this a
>> beg for help, from anyone that likes wiki editing.  There's content to
>> be updated, people that will answer questions when it's not clear, but
>> just can't get into the groove on editing the wiki.
>
> A lot of developers do not like to document things or to use a Web-Wiki.
> I can understand the Wiki part because in my opinion a Web editor is
> just unusable.
>
> In my opinion the the community should seriously think about if a
> MediaWiki setup has proven successful and if they think not first think
> about if a Wiki is needed at all, secondly what should be documented and
> lastly what tools developers might use.
>
> There are a lot of Wiki setups maintained in a repository like ikiwiki
> [1]. Adding a requirement to the guidelines that documentation also has
> be updated would be a feasible solution in my opinion developers could
> also live with since it is all managed in one repository.
>
> There has been a thread about this in the past I think. So please open a
> new thread if you put that up on the agenda.

I think this needs to happen, yes.  Thanks.

-- 
Tom

Re: Plans for OE classic future

[Koen Kooi]

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

Op 27-11-11 03:37, Tom Rini schreef:

> If anything it seems like there's an objection to switching classic OE 
> from "free for all" to the pull request (or patches posted) model 
> oe-core/meta-oe/etc are using.

I think you're describing the actual issue at hand now :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAk7SBtgACgkQMkyGM64RGpEtJQCgq6pjhNEx//YpXFphZPBN+7fn
yLUAoLgLp3++TcLaeI+nq0pPDbXfiUNK
=o/ef
-----END PGP SIGNATURE-----

Re: Plans for OE classic future

[Frans Meulenbroeks]

2011/11/27 Tom Rini <tom.rini@gmail.com>

>
>
> So the question is, what is the long term plan for classic OE based
> stuff?  The TSC has been saying, perhaps not with enough voice or
> emphasis:
> - 2011.03 is the last "release" of oe.dev (unless someone(s) step up
> and wish to do another!)
> - 2011.03-maintenance will be maintained as long as people are saying
> they have a need for it.
> - The master branch needs to go away somehow as the last step of
> migration.  This is what I was trying to say below...
>
> >> In my mind, we couldn't do a technical branching of the repository, we
> >> made a new one. But people are still working off of a branch made
> >> against an 8 month old snapshot.  We really want to encourage this to
> >> stop.  If we were all in one repository still, it would be people
> >> saying "don't make legacy/main read-only!  I still want to add things
> >> to it!".
> >
> > I did not understand that paragraph. Sorry.
>
> The analogy I'm trying to make between classic OE master branch and
> behavior is that it wasn't "lets start from scratch with this new
> repository and hope someday most people stop using the old tree" it
> was "if we could cleanly do a 'git branch -m master legacy' and start
> master as the new meta-oe repository, we would".
>
> Now I'm going to make a Linux Kernel analogy.  The 2.4 series didn't
> (nearly) go away for a long while after 2.6 came out, but after a
> while the rules for what could go in got rather restrictive.
>
> The direction the TSC has recommended for how to deal with classic OE
> is to have the folks that can't yet move off of it be using the
> maintenance branch.  It's not going to be pulled out from under
> anyone.  It's just got rules about what kind of changes are allowed
> in.  Today that's "must exist in relevant oe-core based layer or be
> N/A in that world".  I can't imagine that changing until the user base
> is small enough and themselves in a maintenance mode to be happy with
> that too.
>
> If anything it seems like there's an objection to switching classic OE
> from "free for all" to the pull request (or patches posted) model
> oe-core/meta-oe/etc are using.
>
> Personally I think we are not yet at at point where we should move OE
classic to a pull/patches model. Give it some time.

I understand the concerns with people using master for new projects, but I
also understand the concerns of people that for one reason or another are
still bound to oe-classic.

I feel that it also would be helpful to have some sort of staging area
where people can update things before they are pulled. Doing that
distributed not really creates visibility to those changes, so I'd say it
is better to keep that centralized. Might even be more convenient too.

That still leaves the issue of new projects.
What if we decide to rename master to e.g. maintenance-staging, or legacy,
or classic or whatever you want to; keeping it as it is now (so not R/O),
and have a new master that is R/O and only contains a document with some
explanation and referring to oe-core for new projects. This doc could
mention the legacy branch together with a statement that it is not desired
for new projects, but mainly there for maintenance/testing purposes.

Frans.

Re: Plans for OE classic future

[Tom Rini]

On Sun, Nov 27, 2011 at 3:12 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2011/11/27 Tom Rini <tom.rini@gmail.com>
>
>>
>>
>> So the question is, what is the long term plan for classic OE based
>> stuff?  The TSC has been saying, perhaps not with enough voice or
>> emphasis:
>> - 2011.03 is the last "release" of oe.dev (unless someone(s) step up
>> and wish to do another!)
>> - 2011.03-maintenance will be maintained as long as people are saying
>> they have a need for it.
>> - The master branch needs to go away somehow as the last step of
>> migration.  This is what I was trying to say below...
>>
>> >> In my mind, we couldn't do a technical branching of the repository, we
>> >> made a new one. But people are still working off of a branch made
>> >> against an 8 month old snapshot.  We really want to encourage this to
>> >> stop.  If we were all in one repository still, it would be people
>> >> saying "don't make legacy/main read-only!  I still want to add things
>> >> to it!".
>> >
>> > I did not understand that paragraph. Sorry.
>>
>> The analogy I'm trying to make between classic OE master branch and
>> behavior is that it wasn't "lets start from scratch with this new
>> repository and hope someday most people stop using the old tree" it
>> was "if we could cleanly do a 'git branch -m master legacy' and start
>> master as the new meta-oe repository, we would".
>>
>> Now I'm going to make a Linux Kernel analogy.  The 2.4 series didn't
>> (nearly) go away for a long while after 2.6 came out, but after a
>> while the rules for what could go in got rather restrictive.
>>
>> The direction the TSC has recommended for how to deal with classic OE
>> is to have the folks that can't yet move off of it be using the
>> maintenance branch.  It's not going to be pulled out from under
>> anyone.  It's just got rules about what kind of changes are allowed
>> in.  Today that's "must exist in relevant oe-core based layer or be
>> N/A in that world".  I can't imagine that changing until the user base
>> is small enough and themselves in a maintenance mode to be happy with
>> that too.
>>
>> If anything it seems like there's an objection to switching classic OE
>> from "free for all" to the pull request (or patches posted) model
>> oe-core/meta-oe/etc are using.
>>
> Personally I think we are not yet at at point where we should move OE
> classic to a pull/patches model. Give it some time.

So, why are we not at that point yet for OE classic?  I'd like to
think I've been timely in my pulls.

> I understand the concerns with people using master for new projects, but I
> also understand the concerns of people that for one reason or another are
> still bound to oe-classic.
>
> I feel that it also would be helpful to have some sort of staging area
> where people can update things before they are pulled. Doing that
> distributed not really creates visibility to those changes, so I'd say it
> is better to keep that centralized. Might even be more convenient too.

We already have this for oe-core/meta-oe so it shouldn't be hard to
make up a contrib repo for classic OE, for folks that don't want to
just fork the mirror on github.

> That still leaves the issue of new projects.
> What if we decide to rename master to e.g. maintenance-staging, or legacy,
> or classic or whatever you want to; keeping it as it is now (so not R/O),
> and have a new master that is R/O and only contains a document with some
> explanation and referring to oe-core for new projects. This doc could
> mention the legacy branch together with a statement that it is not desired
> for new projects, but mainly there for maintenance/testing purposes.

The only part here I object to is saying we need an anyone-can-write branch.

-- 
Tom

Re: Plans for OE classic future

[Frans Meulenbroeks]

2011/11/27 Tom Rini <tom.rini@gmail.com>

> On Sun, Nov 27, 2011 at 3:12 AM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
> > Personally I think we are not yet at at point where we should move OE
> > classic to a pull/patches model. Give it some time.
>
> So, why are we not at that point yet for OE classic?  I'd like to
> think I've been timely in my pulls.
>

I'm not saying you are not timely. Au contraire, you are.

>
> > I understand the concerns with people using master for new projects, but
> I
> > also understand the concerns of people that for one reason or another are
> > still bound to oe-classic.
> >
> > I feel that it also would be helpful to have some sort of staging area
> > where people can update things before they are pulled. Doing that
> > distributed not really creates visibility to those changes, so I'd say it
> > is better to keep that centralized. Might even be more convenient too.
>
> We already have this for oe-core/meta-oe so it shouldn't be hard to
> make up a contrib repo for classic OE, for folks that don't want to
> just fork the mirror on github.
>

Whether it is a branch or a separate repo does not make too much of a
difference (at least not to me).
It was my impression that a branch would work a little bit simpler, but I
may well be mistaken here.

>
> > That still leaves the issue of new projects.
> > What if we decide to rename master to e.g. maintenance-staging, or
> legacy,
> > or classic or whatever you want to; keeping it as it is now (so not R/O),
> > and have a new master that is R/O and only contains a document with some
> > explanation and referring to oe-core for new projects. This doc could
> > mention the legacy branch together with a statement that it is not
> desired
> > for new projects, but mainly there for maintenance/testing purposes.
>
> The only part here I object to is saying we need an anyone-can-write
> branch.
>

If it is a contrib repo or overlay fine with me.
I do think it is probably convenient that it should be an
anyone-who-is-authorized-can-write repo/overlay/branch/whatever, in order
not to unneededly raise the barrier to submit patches.

Frans

Re: Plans for OE classic future

[Tom Rini]

On Sun, Nov 27, 2011 at 10:25 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2011/11/27 Tom Rini <tom.rini@gmail.com>
>
>> On Sun, Nov 27, 2011 at 3:12 AM, Frans Meulenbroeks
>> <fransmeulenbroeks@gmail.com> wrote:
>> > Personally I think we are not yet at at point where we should move OE
>> > classic to a pull/patches model. Give it some time.
>>
>> So, why are we not at that point yet for OE classic?  I'd like to
>> think I've been timely in my pulls.
>
> I'm not saying you are not timely. Au contraire, you are.

OK.  So provided we have an easy way to make pull requests of trees
hosted on oe.org (like oe-core/meta-oe today), are there any other
objections to moving towards pull request model for classic OE?

>> > I understand the concerns with people using master for new projects, but
>> I
>> > also understand the concerns of people that for one reason or another are
>> > still bound to oe-classic.
>> >
>> > I feel that it also would be helpful to have some sort of staging area
>> > where people can update things before they are pulled. Doing that
>> > distributed not really creates visibility to those changes, so I'd say it
>> > is better to keep that centralized. Might even be more convenient too.
>>
>> We already have this for oe-core/meta-oe so it shouldn't be hard to
>> make up a contrib repo for classic OE, for folks that don't want to
>> just fork the mirror on github.
>>
>
> Whether it is a branch or a separate repo does not make too much of a
> difference (at least not to me).
> It was my impression that a branch would work a little bit simpler, but I
> may well be mistaken here.

My understanding of the git server side of things is a contrib repo is
easier to setup and manage permission-wise.

>> > That still leaves the issue of new projects.
>> > What if we decide to rename master to e.g. maintenance-staging, or
>> legacy,
>> > or classic or whatever you want to; keeping it as it is now (so not R/O),
>> > and have a new master that is R/O and only contains a document with some
>> > explanation and referring to oe-core for new projects. This doc could
>> > mention the legacy branch together with a statement that it is not
>> desired
>> > for new projects, but mainly there for maintenance/testing purposes.
>>
>> The only part here I object to is saying we need an anyone-can-write
>> branch.
>>
>
> If it is a contrib repo or overlay fine with me.
> I do think it is probably convenient that it should be an
> anyone-who-is-authorized-can-write repo/overlay/branch/whatever, in order
> not to unneededly raise the barrier to submit patches.

So, like we do today for openembedded-core-contrib / meta-openembedded-contrib?

-- 
Tom

Re: Plans for OE classic future

[Frans Meulenbroeks]

2011/11/27 Tom Rini <tom.rini@gmail.com>

> On Sun, Nov 27, 2011 at 10:25 AM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
> > 2011/11/27 Tom Rini <tom.rini@gmail.com>
> >
> >> On Sun, Nov 27, 2011 at 3:12 AM, Frans Meulenbroeks
> >> <fransmeulenbroeks@gmail.com> wrote:
> >> > Personally I think we are not yet at at point where we should move OE
> >> > classic to a pull/patches model. Give it some time.
> >>
> >> So, why are we not at that point yet for OE classic?  I'd like to
> >> think I've been timely in my pulls.
> >
> > I'm not saying you are not timely. Au contraire, you are.
>
> OK.  So provided we have an easy way to make pull requests of trees
> hosted on oe.org (like oe-core/meta-oe today), are there any other
> objections to moving towards pull request model for classic OE?
>

My whole point is that things should be easy for those who want to
contribute.
And it should be clear what goes in and how it should be done (and not like
in some other place where it seems to be left to the discretion of the pull
god, note that I am quite happy with the way you do your job).

>
> >> > I understand the concerns with people using master for new projects,
> but
> >> I
> >> > also understand the concerns of people that for one reason or another
> are
> >> > still bound to oe-classic.
> >> >
> >> > I feel that it also would be helpful to have some sort of staging area
> >> > where people can update things before they are pulled. Doing that
> >> > distributed not really creates visibility to those changes, so I'd
> say it
> >> > is better to keep that centralized. Might even be more convenient too.
> >>
> >> We already have this for oe-core/meta-oe so it shouldn't be hard to
> >> make up a contrib repo for classic OE, for folks that don't want to
> >> just fork the mirror on github.
> >>
> >
> > Whether it is a branch or a separate repo does not make too much of a
> > difference (at least not to me).
> > It was my impression that a branch would work a little bit simpler, but I
> > may well be mistaken here.
>
> My understanding of the git server side of things is a contrib repo is
> easier to setup and manage permission-wise.
>
I can't comment on that as I have no knowledge on the server side. I'm
looking at it from a user/contributor perspective.

>
> >> > That still leaves the issue of new projects.
> >> > What if we decide to rename master to e.g. maintenance-staging, or
> >> legacy,
> >> > or classic or whatever you want to; keeping it as it is now (so not
> R/O),
> >> > and have a new master that is R/O and only contains a document with
> some
> >> > explanation and referring to oe-core for new projects. This doc could
> >> > mention the legacy branch together with a statement that it is not
> >> desired
> >> > for new projects, but mainly there for maintenance/testing purposes.
> >>
> >> The only part here I object to is saying we need an anyone-can-write
> >> branch.
> >>
> >
> > If it is a contrib repo or overlay fine with me.
> > I do think it is probably convenient that it should be an
> > anyone-who-is-authorized-can-write repo/overlay/branch/whatever, in order
> > not to unneededly raise the barrier to submit patches.
>
> So, like we do today for openembedded-core-contrib /
> meta-openembedded-contrib?
>
> Sorry but since all my projects are still based upon oe-classic, I never
bothered to peek at those.

Anyway these are my opinions. There were some others that had concerns. Not
sure how they feel about it.
And it is good that we come to a plan and define a workflow and a migration
path.

The original statement by someone saying "OE classic will be R/O soon", was
a little bit too quick and too incomplete for the community I think. At
least it was for me.

Frans

Re: Plans for OE classic future

[Tom Rini]

On Sun, Nov 27, 2011 at 2:58 PM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2011/11/27 Tom Rini <tom.rini@gmail.com>
>
>> On Sun, Nov 27, 2011 at 10:25 AM, Frans Meulenbroeks
>> <fransmeulenbroeks@gmail.com> wrote:
>> > 2011/11/27 Tom Rini <tom.rini@gmail.com>
>> >
>> >> On Sun, Nov 27, 2011 at 3:12 AM, Frans Meulenbroeks
>> >> <fransmeulenbroeks@gmail.com> wrote:
>> >> > Personally I think we are not yet at at point where we should move OE
>> >> > classic to a pull/patches model. Give it some time.
>> >>
>> >> So, why are we not at that point yet for OE classic?  I'd like to
>> >> think I've been timely in my pulls.
>> >
>> > I'm not saying you are not timely. Au contraire, you are.
>>
>> OK.  So provided we have an easy way to make pull requests of trees
>> hosted on oe.org (like oe-core/meta-oe today), are there any other
>> objections to moving towards pull request model for classic OE?
>>
>
> My whole point is that things should be easy for those who want to
> contribute.

Agreed.  And I think based on the volume going into
oe-core/meta-oe/etc today, folks have found the contrib tree model to
work.  And again, if it's not working, people need to be speaking up
:)

>> >> > I understand the concerns with people using master for new projects,
>> but
>> >> I
>> >> > also understand the concerns of people that for one reason or another
>> are
>> >> > still bound to oe-classic.
>> >> >
>> >> > I feel that it also would be helpful to have some sort of staging area
>> >> > where people can update things before they are pulled. Doing that
>> >> > distributed not really creates visibility to those changes, so I'd
>> say it
>> >> > is better to keep that centralized. Might even be more convenient too.
>> >>
>> >> We already have this for oe-core/meta-oe so it shouldn't be hard to
>> >> make up a contrib repo for classic OE, for folks that don't want to
>> >> just fork the mirror on github.
>> >>
>> >
>> > Whether it is a branch or a separate repo does not make too much of a
>> > difference (at least not to me).
>> > It was my impression that a branch would work a little bit simpler, but I
>> > may well be mistaken here.
>>
>> My understanding of the git server side of things is a contrib repo is
>> easier to setup and manage permission-wise.
>>
> I can't comment on that as I have no knowledge on the server side. I'm
> looking at it from a user/contributor perspective.

Yes, lets leave this part up to the admins, I'm just inferring from
how it's setup today.

>> >> > That still leaves the issue of new projects.
>> >> > What if we decide to rename master to e.g. maintenance-staging, or
>> >> legacy,
>> >> > or classic or whatever you want to; keeping it as it is now (so not
>> R/O),
>> >> > and have a new master that is R/O and only contains a document with
>> some
>> >> > explanation and referring to oe-core for new projects. This doc could
>> >> > mention the legacy branch together with a statement that it is not
>> >> desired
>> >> > for new projects, but mainly there for maintenance/testing purposes.
>> >>
>> >> The only part here I object to is saying we need an anyone-can-write
>> >> branch.
>> >>
>> >
>> > If it is a contrib repo or overlay fine with me.
>> > I do think it is probably convenient that it should be an
>> > anyone-who-is-authorized-can-write repo/overlay/branch/whatever, in order
>> > not to unneededly raise the barrier to submit patches.
>>
>> So, like we do today for openembedded-core-contrib /
>> meta-openembedded-contrib?
>>
> Sorry but since all my projects are still based upon oe-classic, I never
> bothered to peek at those.
>
> Anyway these are my opinions. There were some others that had concerns. Not
> sure how they feel about it.
> And it is good that we come to a plan and define a workflow and a migration
> path.

Yes, lets make sure everyone else has a chance to voice their opinion.
 And while the details are in various emails (and I should summarize
before we say this is it), at the high level:
- Be more like oe-core/meta-oe in that we have contrib repositories
(or self hosted or github or gitorious or ..) and pull requests for
changes going into 2011.03-maintenance (note that pull requests are
the rule today)
- Get everyone else who is doing projects based on OE classic 'master'
to either be fine with no more changes at some point OR migrate to
2011.03-maintenance and as always, I'm happy to review pull requests
of N commits worth of backports of changes from master, or wherever
else, to make that migration work for a given project.
- Get public documentation to reflect the reality of
oe-core+meta-oe+$stuff going forward, 2011.03-maintenance for OE
classic that's receiving some amount of updates and that master and
2011.03-maintenance are strongly cautioned against for new projects.
- Make sure meta-oe policy is documented in cases where it diverges
from oe-core, so everyone is clear.

> The original statement by someone saying "OE classic will be R/O soon", was
> a little bit too quick and too incomplete for the community I think. At
> least it was for me.

Yes, I agree this was a needed conversation.  With my TSC hat on, I
think we were just waiting to see if anyone needed more than notice of
a date in the future.

-- 
Tom

Re: Plans for OE classic future

[Raffaele Recalcati]

On Nov 26, 2011 11:02 PM, "Paul Menzel" <paulepanter@users.sourceforge.net>
wrote:
>
> Am Samstag, den 26.11.2011, 14:36 -0700 schrieb Tom Rini:
> > On Sat, Nov 26, 2011 at 8:49 AM, Frans Meulenbroeks wrote:
> > > 2011/11/26 Tom Rini
> > >
> > >> On Sat, Nov 26, 2011 at 3:57 AM, Ulf Samuelsson wrote:
> > >> > On 2011-11-25 23:04, Tom Rini wrote:
> > >> >>
> > >> >> On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks wrote:
> > >> >>
> > >> >>> After all, isn't one of the purposes of OE to promote information
> > >> >>> sharing,
> > >> >>> cooperation and the use of openembedded technology (and not make
things
> > >> >>> harder).
> > >> >>
> > >> >> One of the points of making master read-only would be to ensure
that
> > >> >> changes aren't lost.
> > >> >>
> > >> >> Perhaps the transition needs to be:
> > >> >> - master is as it is today
> > >> >> - master becomes oe-core backport || master-only bugfixes only
> > >> >> - master becomes read only.
> > >> >>
> > >> >> And we go from the first step to the second step sometime sooner
> > >> >> rather than later.  The top of my head date would be before the
> > >> >> paid-developers go on end of year breaks to try and make sure all
the
> > >> >> hobbyist folks start their hacking with oe-core+etc rather than
master
> > >> >> and risk getting caught later.  I'm open to arguments on why
that's
> > >> >> exactly backwards...
> > >> >>
> > >> >
> > >> > Won't it be a problem for existing projects, if you cannot add
fixes to
> > >> cope
> > >> > with new host OS versions.
> > >> >
> > >> > At the moment, openembedded-classic does not build properly with
Ubuntu
> > >> > 11.10 .
> > >>
> > >> Won't what be a problem?  Either oe-core+meta-oe+etc fails on 11.10
> > >> (so, fix it there first then backport changes) or it's fine and you
> > >> can either find the relevant changes there and move them or it's a
> > >> oe.dev-only bug and just needs to be fixed, under my proposal (until
> > >> we reach the point where everyone is OK calling it r/o).
> > >>
> > >> And part of this is to say that yes, existing projects external to
> > >> oe.dev need to move to oe-core(+meta-oe+whatever else) (where layers
> > >> should be making their life easier or again, there's problems we're
> > >> unaware of and need to be made aware of) or explain why they can't
> > >> ever move (and are forking the project?).
> > >
> > > See the message on NIOS that I just posted.
> >
> > Addressed there :)
> >
> > > Also I am not opposed to making oe classic master the place where
patches
> > > may land before they end up in the maintenance thread, but I am
strongly
> > > opposed to making OE classic read only on short notice (which as
suggested
> > > by Koen earlier).
> >
> > I believe master needs to go read-only, or at least
> > backport||master-only-problems bugfix only, sooner rather than later.
> >
> > The arguments seem to be:
> > - Some people or projects use master and can't move
> > * So don't move, but do expect to need to either migrate to
> > 2011.03-maintenance or carry more fixes locally.
>
> This is still not understandable. I understand that you want developers
> to move to OE-core and meta-oe. But trying to force people by making
> master read-only is the wrong way. It just arbitrarily puts a burden on
> current users. You can advertise prominently that OE-core and meta-oe
> should be used. Over the time people will move and a lot of people have
> expressed their willingness to move in the future.
>

Choosing now the baseline for dm3730 with my colleagues it seems that it
will be arago, that is still oe-classic, because Ti is releasing dvsdk
based on it. If Ti moves with arago to oe-core we move as well to it.
Very clean and simple decision, isn't it?

> > With my
> > 2011.03-maintenance hat on, if someone says for my project to move I
> > need N patches moved from master to maintenance, I'm fine reviewing
> > that pull request.
>
> I thought that was always possible in the past.
>
> > - There's concern that $something won't be able to work with
oe-core+meta-oe+etc
> > * These are problems that either need to be fixed or assumptions that
> > aren't correct.
> >
> > - Lack of recipes in meta-oe
> > * The recipes people need have been moved, stuff that isn't can be
> > when someone needs it.  id3lib was mentioned as an example of why
> > there might be problems getting things moved to meta-oe.  I can't help
> > but notice it's also been moved into meta-oe.
>
> As Bernhard noted in this reply. OE-Core and meta-oe seriously lack
> documentation. And if it is just that our Wiki currently is still based
> on OE-classic. And in my experience not a lot of people put effort
> behind it and just neglect it.
>
> (New users will search for tutorials and help on the WWW and there
> currently a lot is dealing with OE-classic.)
>
>
> Thanks,
>
> Paul
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Plans for OE classic future

[Otavio Salvador]

On Sat, Nov 26, 2011 at 20:37, Raffaele Recalcati <lamiaposta71@gmail.com>wrote:

> ...

Choosing now the baseline for dm3730 with my colleagues it seems that it
> will be arago, that is still oe-classic, because Ti is releasing dvsdk
> based on it. If Ti moves with arago to oe-core we move as well to it.
> Very clean and simple decision, isn't it?


Yes and you deal with the fork of it by your own. Simple consequence, isn't
it?

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Plans for OE classic future

[Tom Rini]

On Sat, Nov 26, 2011 at 3:44 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Sat, Nov 26, 2011 at 20:37, Raffaele Recalcati <lamiaposta71@gmail.com>wrote:
>
>> ...
>
> Choosing now the baseline for dm3730 with my colleagues it seems that it
>> will be arago, that is still oe-classic, because Ti is releasing dvsdk
>> based on it. If Ti moves with arago to oe-core we move as well to it.
>> Very clean and simple decision, isn't it?
>
>
> Yes and you deal with the fork of it by your own. Simple consequence, isn't
> it?

Putting on my TI hat, Arago isn't a fork.  And, TI is moving forward
to oe-core/etc, but like everyone else with a timing problem, yeah,
timing problem.

-- 
Tom

Re: Plans for OE classic future

[Ulf Samuelsson]

On 2011-11-26 16:20, Tom Rini wrote:
> On Sat, Nov 26, 2011 at 3:57 AM, Ulf Samuelsson
> <ulf_samuelsson@telia.com>  wrote:
>> On 2011-11-25 23:04, Tom Rini wrote:
>>> On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks
>>> <fransmeulenbroeks@gmail.com>    wrote:
>>>
>>>> After all, isn't one of the purposes of OE to promote information
>>>> sharing,
>>>> cooperation and the use of openembedded technology (and not make things
>>>> harder).
>>> One of the points of making master read-only would be to ensure that
>>> changes aren't lost.
>>>
>>> Perhaps the transition needs to be:
>>> - master is as it is today
>>> - master becomes oe-core backport || master-only bugfixes only
>>> - master becomes read only.
>>>
>>> And we go from the first step to the second step sometime sooner
>>> rather than later.  The top of my head date would be before the
>>> paid-developers go on end of year breaks to try and make sure all the
>>> hobbyist folks start their hacking with oe-core+etc rather than master
>>> and risk getting caught later.  I'm open to arguments on why that's
>>> exactly backwards...
>>>
>> Won't it be a problem for existing projects, if you cannot add fixes to cope
>> with new host OS versions.
>>
>> At the moment, openembedded-classic does not build properly with Ubuntu
>> 11.10 .
> Won't what be a problem?  Either oe-core+meta-oe+etc fails on 11.10
> (so, fix it there first then backport changes) or it's fine and you
> can either find the relevant changes there and move them or it's a
> oe.dev-only bug and just needs to be fixed, under my proposal (until
> we reach the point where everyone is OK calling it r/o).

Making it R/O.
/Ulf


> And part of this is to say that yes, existing projects external to
> oe.dev need to move to oe-core(+meta-oe+whatever else) (where layers
> should be making their life easier or again, there's problems we're
> unaware of and need to be made aware of) or explain why they can't
> ever move (and are forking the project?).
>


-- 
Best Regards
Ulf Samuelsson

Re: Plans for OE classic future

[Tom Rini]

On Sat, Nov 26, 2011 at 11:53 AM, Ulf Samuelsson
<ulf_samuelsson@telia.com> wrote:
> On 2011-11-26 16:20, Tom Rini wrote:
>>
>> On Sat, Nov 26, 2011 at 3:57 AM, Ulf Samuelsson
>> <ulf_samuelsson@telia.com>  wrote:
>>>
>>> On 2011-11-25 23:04, Tom Rini wrote:
>>>>
>>>> On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks
>>>> <fransmeulenbroeks@gmail.com>    wrote:
>>>>
>>>>> After all, isn't one of the purposes of OE to promote information
>>>>> sharing,
>>>>> cooperation and the use of openembedded technology (and not make things
>>>>> harder).
>>>>
>>>> One of the points of making master read-only would be to ensure that
>>>> changes aren't lost.
>>>>
>>>> Perhaps the transition needs to be:
>>>> - master is as it is today
>>>> - master becomes oe-core backport || master-only bugfixes only
>>>> - master becomes read only.
>>>>
>>>> And we go from the first step to the second step sometime sooner
>>>> rather than later.  The top of my head date would be before the
>>>> paid-developers go on end of year breaks to try and make sure all the
>>>> hobbyist folks start their hacking with oe-core+etc rather than master
>>>> and risk getting caught later.  I'm open to arguments on why that's
>>>> exactly backwards...
>>>>
>>> Won't it be a problem for existing projects, if you cannot add fixes to
>>> cope
>>> with new host OS versions.
>>>
>>> At the moment, openembedded-classic does not build properly with Ubuntu
>>> 11.10 .
>>
>> Won't what be a problem?  Either oe-core+meta-oe+etc fails on 11.10
>> (so, fix it there first then backport changes) or it's fine and you
>> can either find the relevant changes there and move them or it's a
>> oe.dev-only bug and just needs to be fixed, under my proposal (until
>> we reach the point where everyone is OK calling it r/o).
>
> Making it R/O.

I'm sorry, I'm not clear on why this is a problem.  Are you suggesting
that oe.dev be maintained and kept building until...?  And again, I'm
happy to keep the maintenance branch building so long as people are
willing to feed me pull requests to do so.

But also, please see what I said just now in another part of the
thread about the direction I see things going, today.

-- 
Tom

Re: Plans for OE classic future

[Paul Eggleton]

On Thursday 24 November 2011 12:33:29 Paul Menzel wrote:
> You seem to use OE-core and meta-oe already so I understand your point
> of view. Martin, Koen, Andreas and you are doing the major work for
> meta-oe and not a lot of other people contribute.
> 
> In my opinion it is a bad sign to force people to switch. OE-core and
> meta-oe should be so appealing that they switch by themselves. My
> impression from reading the list and from IRC is that a lot of people
> still have objections and are not totally comfortable. Good community
> management would be to listen to these people then try to find solutions
> and implement them. People then should come by themselves.

Let's not get carried away. In the current discussion it seems the main 
objection to switching from several people is that they are in the middle or 
close to the end of their development cycle on products that depend on OE-
classic; it's totally understandable that those people can't switch at this 
time. I'm not entirely convinced those people can't use the 2011.3 maintenance 
branch for those purposes however.

As regards to things missing or improvements needed in the new OE-core based 
structure, those things will only get better when people who are able to do so 
commit to moving across. You can't expect a restructuring of the thousands of 
recipes to come fully formed from a small number of developers - please, we 
need your help. If more people get involved it's only a small amount of work 
for lots of people as opposed to a large amount of work for very few.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Plans for OE classic future

[Koen Kooi]

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

Op 24-11-11 12:43, Paul Eggleton schreef:
> On Thursday 24 November 2011 12:33:29 Paul Menzel wrote:
>> You seem to use OE-core and meta-oe already so I understand your point 
>> of view. Martin, Koen, Andreas and you are doing the major work for 
>> meta-oe and not a lot of other people contribute.
>> 
>> In my opinion it is a bad sign to force people to switch. OE-core and 
>> meta-oe should be so appealing that they switch by themselves. My 
>> impression from reading the list and from IRC is that a lot of people 
>> still have objections and are not totally comfortable. Good community 
>> management would be to listen to these people then try to find
>> solutions and implement them. People then should come by themselves.
> 
> Let's not get carried away. In the current discussion it seems the main 
> objection to switching from several people is that they are in the middle
> or close to the end of their development cycle on products that depend on
> OE- classic; it's totally understandable that those people can't switch
> at this time. I'm not entirely convinced those people can't use the
> 2011.3 maintenance branch for those purposes however.

Most, if not all people objecting to OE-classic closing seem to be on
2011.03-maintenance already. The confusion seems to be rooted into not
paying attention when Tom said fixes for the maintenance branch can go
through oe-core/meta-oe/whatever as well. That is even mentioned in the damn
wiki for the maintenance branch!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAk7Og0gACgkQMkyGM64RGpETAgCfX1jflPTMJCZndnIKZpKWTAvR
2psAoLqc0id3iCacEOuVu9bZVBPVwzBq
=AUUz
-----END PGP SIGNATURE-----

Re: Plans for OE classic future

[Andreas Oberritter]

On 24.11.2011 18:47, Koen Kooi wrote:
> Op 24-11-11 12:43, Paul Eggleton schreef:
>> On Thursday 24 November 2011 12:33:29 Paul Menzel wrote:
>>> You seem to use OE-core and meta-oe already so I understand your point 
>>> of view. Martin, Koen, Andreas and you are doing the major work for 
>>> meta-oe and not a lot of other people contribute.
>>>
>>> In my opinion it is a bad sign to force people to switch. OE-core and 
>>> meta-oe should be so appealing that they switch by themselves. My 
>>> impression from reading the list and from IRC is that a lot of people 
>>> still have objections and are not totally comfortable. Good community 
>>> management would be to listen to these people then try to find
>>> solutions and implement them. People then should come by themselves.
> 
>> Let's not get carried away. In the current discussion it seems the main 
>> objection to switching from several people is that they are in the middle
>> or close to the end of their development cycle on products that depend on
>> OE- classic; it's totally understandable that those people can't switch
>> at this time. I'm not entirely convinced those people can't use the
>> 2011.3 maintenance branch for those purposes however.
> 
> Most, if not all people objecting to OE-classic closing seem to be on
> 2011.03-maintenance already. The confusion seems to be rooted into not
> paying attention when Tom said fixes for the maintenance branch can go
> through oe-core/meta-oe/whatever as well. That is even mentioned in the damn
> wiki for the maintenance branch!

Ah, of course. Just tell everybody to switch to oe-core, so they can
backport fixes from there to 2011.03. Sure. That's what everybody who
isn't able to switch to oe-core for some reason will do.

Mentioning your "damn" wiki again and again doesn't help anybody.

Regards,
Andreas

Re: Plans for OE classic future

[Koen Kooi]

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

Op 23-11-11 23:42, Andreas Oberritter schreef:
> On 23.11.2011 23:25, Khem Raj wrote:
>> On Wed, Nov 23, 2011 at 1:18 PM, Frans Meulenbroeks 
>> <fransmeulenbroeks@gmail.com> wrote:
>>> 2011/11/23 Khem Raj <raj.khem@gmail.com>
>>> 
>>>> On Thu, Oct 27, 2011 at 3:53 AM, Mats Kärrman
>>>> <Mats.Karrman@tritech.se> wrote:
>>>>> Hi,
>>>>> 
>>>>> Are there any plans for new releases and/or maintenance branches
>>>>> of OE
>>>> classic?
>>>>> 
>>>> 
>>>> 2011.03-maintenance is the last release of OE classic. As long as
>>>> the branch is maintained
>>>> 
>>>> _
>>>> 
>>>> Related: I noticed TSC plans to discuss on whether or not to make
>>>> oe
>>> classic read only.
>>> 
>>> I'd like to suggest leaving it open for those of us that are still
>>> using it.
>> 
>> 2011.03-maintenance branch is maintained and that would be place to
>> go.
>> 
>> 
>>> For instance I have still products that are based on OE classic. If
>>> there is a problem that is of a generic nature, I'm more than happy
>>> to submit patches so others in the same situation can benefit from
>>> it. (actually I have one pending with a new version of netsnmp; the
>>> current recipe does not build with uclibc, whereas the latest version
>>> of netsnmp does; found/fixed this today, but haven't had time to make
>>> a commit)
>>> 
>>> And if there is no interest any more it'll eventually die. But as of
>>> now I do see people working on/with it (see the commit log).
>> 
>> those fixes are intended for 2011.03-maintenance which go into master
>> and then get cherry-picked
> 
> So master needs to stay open in order to get patches there first before 
> being cherry-picked into 2011.03-maintenance, right?

That has been stated multiple times before: No, OE-classic is not the only
way patches can flow into 2011.03-maintenance. It's even listed in the damn
wiki: http://www.openembedded.org/wiki/2011.03-maintenance

OE .dev will go read-only soon, If you need an OE-classic setup,
2011.03-maintenance is there for you.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAk7OCmgACgkQMkyGM64RGpF6CACeNE8dbi9QIHSKXUtMbGo87Tj5
RewAn0M/iVo9uIqVMPjBCrBt9m9SqwAg
=xqiO
-----END PGP SIGNATURE-----

Re: Plans for OE classic future

[Frans Meulenbroeks]

2011/11/24 Koen Kooi <koen@dominion.thruhere.net>

>
>
> OE .dev will go read-only soon, If you need an OE-classic setup,
> 2011.03-maintenance is there for you.
>

As stated before there are still people using .dev and committing to it
[1], and there are people interested in keeping it that way for a while.
So as it stands I suggest to keep it open for a while for those that still
are interested to use it.

People not interested in oe classic can safely ignore it, but I feel there
is no need to complicate the life of the people that for whatever reason
still need access and are interesting to commit to it.

Frans.

[1] http://cgit.openembedded.org/openembedded/log/

Re: Plans for OE classic future

[Khem Raj]

On (24/11/11 10:31), Frans Meulenbroeks wrote:
> 2011/11/24 Koen Kooi <koen@dominion.thruhere.net>
> 
> >
> >
> > OE .dev will go read-only soon, If you need an OE-classic setup,
> > 2011.03-maintenance is there for you.
> >
> 
> As stated before there are still people using .dev and committing to it
> [1], and there are people interested in keeping it that way for a while.
> So as it stands I suggest to keep it open for a while for those that still
> are interested to use it.

I would suggest that people interested in oe classic should use 2011.03
branch since its maintained and tested regularly. Its in their best
interest too since there are people behind the branch and it gets
regular bug fixes thats not true for master.

I would like stronger arguments for why master and not 2011.03 release
branch ?

-Khem

Re: Plans for OE classic future

[Andreas Oberritter]

On 24.11.2011 18:06, Khem Raj wrote:
> On (24/11/11 10:31), Frans Meulenbroeks wrote:
>> 2011/11/24 Koen Kooi <koen@dominion.thruhere.net>
>>
>>>
>>>
>>> OE .dev will go read-only soon, If you need an OE-classic setup,
>>> 2011.03-maintenance is there for you.
>>>
>>
>> As stated before there are still people using .dev and committing to it
>> [1], and there are people interested in keeping it that way for a while.
>> So as it stands I suggest to keep it open for a while for those that still
>> are interested to use it.
> 
> I would suggest that people interested in oe classic should use 2011.03
> branch since its maintained and tested regularly. Its in their best
> interest too since there are people behind the branch and it gets
> regular bug fixes thats not true for master.

I guess most people using OE are old enough to know better about their
own interests.

> I would like stronger arguments for why master and not 2011.03 release
> branch ?

Obviously, you can push a changeset to master, wait for someone to
complain about a bug, fix the bug, wait for silence, merge it into 2011.03.

Would you prefer experimental changesets in 2011.03?

Regards,
Andreas

P.S.: I'd really like to switch to oe-core, but at this time it's
impossible. I'm not multithreaded. Closing master won't make me switch
faster, but just annoy me. You'll just force me to keep any bugfixes and
enhancements in my own layer, so that no other body can benefit from them.

Re: Plans for OE classic future

[Otavio Salvador]

On Thu, Nov 24, 2011 at 15:41, Andreas Oberritter <obi@opendreambox.org>wrote:

> ...
>
> I would like stronger arguments for why master and not 2011.03 release
> > branch ?
>
> Obviously, you can push a changeset to master, wait for someone to
> complain about a bug, fix the bug, wait for silence, merge it into 2011.03.
>

Sure not; 2011.03 is for bugfixes not huge changesets with new things.


> Would you prefer experimental changesets in 2011.03?
>

This is not going to happen  has 2011.03 is not a playground but a stable
 branch.

You're confusing development and maintainence branch meaning here.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Plans for OE classic future

[Andreas Oberritter]

On 24.11.2011 19:43, Otavio Salvador wrote:
> On Thu, Nov 24, 2011 at 15:41, Andreas Oberritter <obi@opendreambox.org>wrote:
> 
>> ...
>>
>> I would like stronger arguments for why master and not 2011.03 release
>>> branch ?
>>
>> Obviously, you can push a changeset to master, wait for someone to
>> complain about a bug, fix the bug, wait for silence, merge it into 2011.03.
>>
> 
> Sure not; 2011.03 is for bugfixes not huge changesets with new things.

Who said "huge" or "new"? Even bugfixes need testing. That's why
changesets should go
through master after all.

>> Would you prefer experimental changesets in 2011.03?
>>
> 
> This is not going to happen  has 2011.03 is not a playground but a stable
>  branch.

Exactly. That's what master is good for. Everything that hasn't been
tested in many environments is experimental by nature. You simply can't
commit anything to 2011.03 directly, for it would be experimental. It
has to be tested somewhere. That's master. (Yes, Koen, we know, OE-core
is an option, but not for some of us.)

> You're confusing development and maintainence branch meaning here.

Obviously not.

Regards,
Andreas

Re: Plans for OE classic future

[Tom Rini]

On Fri, Nov 25, 2011 at 6:17 AM, Andreas Oberritter
<obi@opendreambox.org> wrote:
> On 24.11.2011 19:43, Otavio Salvador wrote:
>> On Thu, Nov 24, 2011 at 15:41, Andreas Oberritter <obi@opendreambox.org>wrote:
>>
>>> ...
>>>
>>> I would like stronger arguments for why master and not 2011.03 release
>>>> branch ?
>>>
>>> Obviously, you can push a changeset to master, wait for someone to
>>> complain about a bug, fix the bug, wait for silence, merge it into 2011.03.
>>>
>>
>> Sure not; 2011.03 is for bugfixes not huge changesets with new things.
>
> Who said "huge" or "new"? Even bugfixes need testing. That's why
> changesets should go
> through master after all.

No, but this is why I ask for pull requests to the maintenance branch
not "please do git cherry-pick ...".  I want things that people have
confirmed do what they need done.

-- 
Tom

Re: Plans for OE classic future

[Paul Menzel]

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

Am Donnerstag, den 24.11.2011, 09:06 -0800 schrieb Khem Raj:
> On (24/11/11 10:31), Frans Meulenbroeks wrote:
> > 2011/11/24 Koen Kooi <koen@dominion.thruhere.net>
> >
> > > OE .dev will go read-only soon, If you need an OE-classic setup,
> > > 2011.03-maintenance is there for you.
> > 
> > As stated before there are still people using .dev and committing to it
> > [1], and there are people interested in keeping it that way for a while.
> > So as it stands I suggest to keep it open for a while for those that still
> > are interested to use it.
> 
> I would suggest that people interested in oe classic should use 2011.03
> branch since its maintained and tested regularly. Its in their best
> interest too since there are people behind the branch and it gets
> regular bug fixes thats not true for master.

That statement is not true as far as I can see from the commit log.
Almost all patches to 2011.03-maintenance went through master.

> I would like stronger arguments for why master and not 2011.03 release
> branch ?

Andreas answered that well.


Thanks,

Paul

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Plans for OE classic future

[Tom Rini]

On Thu, Nov 24, 2011 at 1:33 PM, Paul Menzel
<paulepanter@users.sourceforge.net> wrote:
> Am Donnerstag, den 24.11.2011, 09:06 -0800 schrieb Khem Raj:
>> On (24/11/11 10:31), Frans Meulenbroeks wrote:
>> > 2011/11/24 Koen Kooi <koen@dominion.thruhere.net>
>> >
>> > > OE .dev will go read-only soon, If you need an OE-classic setup,
>> > > 2011.03-maintenance is there for you.
>> >
>> > As stated before there are still people using .dev and committing to it
>> > [1], and there are people interested in keeping it that way for a while.
>> > So as it stands I suggest to keep it open for a while for those that still
>> > are interested to use it.
>>
>> I would suggest that people interested in oe classic should use 2011.03
>> branch since its maintained and tested regularly. Its in their best
>> interest too since there are people behind the branch and it gets
>> regular bug fixes thats not true for master.
>
> That statement is not true as far as I can see from the commit log.
> Almost all patches to 2011.03-maintenance went through master.

Yes, but that's also due, in general to the nature of the branch.
Angstrom/TI related stuff was going master->2011.03-maintenance before
I clarified that coming from oe-core is also fine.  As of yet, no one
else has stepped up and said "I need DISTRO=foo MACHINE=bar working
here, and I intend to keep an eye on things".  Having angstrom-2008.1
in there seems to be good enough for most cases.

-- 
Tom

Re: Plans for OE classic future

[Frans Meulenbroeks]

2011/11/25 Tom Rini <tom.rini@gmail.com>

> On Thu, Nov 24, 2011 at 1:33 PM, Paul Menzel
> <paulepanter@users.sourceforge.net> wrote:
> > Am Donnerstag, den 24.11.2011, 09:06 -0800 schrieb Khem Raj:
> >> On (24/11/11 10:31), Frans Meulenbroeks wrote:
> >> > 2011/11/24 Koen Kooi <koen@dominion.thruhere.net>
> >> >
> >> > > OE .dev will go read-only soon, If you need an OE-classic setup,
> >> > > 2011.03-maintenance is there for you.
> >> >
> >> > As stated before there are still people using .dev and committing to
> it
> >> > [1], and there are people interested in keeping it that way for a
> while.
> >> > So as it stands I suggest to keep it open for a while for those that
> still
> >> > are interested to use it.
> >>
> >> I would suggest that people interested in oe classic should use 2011.03
> >> branch since its maintained and tested regularly. Its in their best
> >> interest too since there are people behind the branch and it gets
> >> regular bug fixes thats not true for master.
> >
> > That statement is not true as far as I can see from the commit log.
> > Almost all patches to 2011.03-maintenance went through master.
>
> Yes, but that's also due, in general to the nature of the branch.
> Angstrom/TI related stuff was going master->2011.03-maintenance before
> I clarified that coming from oe-core is also fine.  As of yet, no one
> else has stepped up and said "I need DISTRO=foo MACHINE=bar working
> here, and I intend to keep an eye on things".  Having angstrom-2008.1
> in there seems to be good enough for most cases.
>

Forgot to mention this in my previous email, but I do have an interest in
minimal and minimal-uclibc for mpc8313. Then again virtually all of my work
is console only, so I'm not really into a position to test lots of things.
I'm keeping an eye on things though and have one or two patches pending
(e.g. our current netsnmp version and uclibc do not seem to be friends).
Personally I prefer to commit these patches to master and issue a pull
request for them and I prefer it if others do the same, so we have a
centralized location, instead of a gazillion git trees at several places.

Frans.

Re: Plans for OE classic future

[Tom Rini]

On Sat, Nov 26, 2011 at 9:11 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2011/11/25 Tom Rini <tom.rini@gmail.com>
>
>> On Thu, Nov 24, 2011 at 1:33 PM, Paul Menzel
>> <paulepanter@users.sourceforge.net> wrote:
>> > Am Donnerstag, den 24.11.2011, 09:06 -0800 schrieb Khem Raj:
>> >> On (24/11/11 10:31), Frans Meulenbroeks wrote:
>> >> > 2011/11/24 Koen Kooi <koen@dominion.thruhere.net>
>> >> >
>> >> > > OE .dev will go read-only soon, If you need an OE-classic setup,
>> >> > > 2011.03-maintenance is there for you.
>> >> >
>> >> > As stated before there are still people using .dev and committing to
>> it
>> >> > [1], and there are people interested in keeping it that way for a
>> while.
>> >> > So as it stands I suggest to keep it open for a while for those that
>> still
>> >> > are interested to use it.
>> >>
>> >> I would suggest that people interested in oe classic should use 2011.03
>> >> branch since its maintained and tested regularly. Its in their best
>> >> interest too since there are people behind the branch and it gets
>> >> regular bug fixes thats not true for master.
>> >
>> > That statement is not true as far as I can see from the commit log.
>> > Almost all patches to 2011.03-maintenance went through master.
>>
>> Yes, but that's also due, in general to the nature of the branch.
>> Angstrom/TI related stuff was going master->2011.03-maintenance before
>> I clarified that coming from oe-core is also fine.  As of yet, no one
>> else has stepped up and said "I need DISTRO=foo MACHINE=bar working
>> here, and I intend to keep an eye on things".  Having angstrom-2008.1
>> in there seems to be good enough for most cases.
>>
>
> Forgot to mention this in my previous email, but I do have an interest in
> minimal and minimal-uclibc for mpc8313. Then again virtually all of my work
> is console only, so I'm not really into a position to test lots of things.
> I'm keeping an eye on things though and have one or two patches pending
> (e.g. our current netsnmp version and uclibc do not seem to be friends).
> Personally I prefer to commit these patches to master and issue a pull
> request for them and I prefer it if others do the same, so we have a
> centralized location, instead of a gazillion git trees at several places.

Well, today oe.master isn't read-only.  But tomorrow do you want to go
and fix these problems again in oe-core?  Most of us do not and have
already gone through the pain of "oh, I need to bring this change, and
this change, and ...." into oe-core+meta-oe.

But, perhaps we're running into a naming problem.  What I see as the
direction the TSC wants things to go is that development is done
against oe-core+meta-oe+etc, people that need classic OE, for
historical interests (history, reproducing old builds) have somewhere
to pull from.  And that legacy projects have somewhere to work against
until they can migrate to oe-core.  We want to discourage development
in the OE classic tree.  A 'git cherry' showed 250-odd changes in
oe.dev master not in the maintenance branch, which is pretty good.
The issue right now is we have two choices for the legacy projects use
case, master and 2011.03-maintenance.  Some places have chosen the
maintenance branch and some have chosen master, and we'd like to unify
that.

-- 
Tom

Re: Plans for OE classic future

[Tom Rini]

On Wed, Nov 23, 2011 at 3:42 PM, Andreas Oberritter
<obi@opendreambox.org> wrote:
> On 23.11.2011 23:25, Khem Raj wrote:
>> On Wed, Nov 23, 2011 at 1:18 PM, Frans Meulenbroeks
>> <fransmeulenbroeks@gmail.com> wrote:
>>> 2011/11/23 Khem Raj <raj.khem@gmail.com>
>>>
>>>> On Thu, Oct 27, 2011 at 3:53 AM, Mats Kärrman <Mats.Karrman@tritech.se>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> Are there any plans for new releases and/or maintenance branches of OE
>>>> classic?
>>>>>
>>>>
>>>> 2011.03-maintenance is the last release of OE classic. As long as the
>>>> branch is maintained
>>>>
>>>> _
>>>>
>>>> Related: I noticed TSC plans to discuss on whether or not to make oe
>>> classic read only.
>>>
>>> I'd like to suggest leaving it open for those of us that are still using
>>> it.
>>
>> 2011.03-maintenance branch is maintained and that would be place to go.
>>
>>
>>> For instance I have still products that are based on OE classic. If there
>>> is a problem that is of a generic nature, I'm more than happy to submit
>>> patches so others in the same situation can benefit from it.
>>> (actually I have one pending with a new version of netsnmp; the current
>>> recipe does not build with uclibc, whereas the latest version of netsnmp
>>> does; found/fixed this today, but haven't had time to make a commit)
>>>
>>> And if there is no interest any more it'll eventually die. But as of now I
>>> do see people working on/with it (see the commit log).
>>
>> those fixes are intended for 2011.03-maintenance which go into master and then
>> get cherry-picked
>
> So master needs to stay open in order to get patches there first before
> being cherry-picked into 2011.03-maintenance, right?
>
> I also don't like the idea to make it read-only. Those who already
> switched to oe-core are free to just ignore the classic master branch.
> Others should still be able to push bugfixes etc, if they care enough
> about it.

<Putting on TSC hat>
The problem with this mindset is that we don't want to have
oe-core+meta-oe+etc and oe.dev diverge any more than they had at the
start.  This is why at some point master needs to become read-only.
Everyone and their master based project can still fetch and build and
work.  But if you're going right now and saying "I need to start a new
project and it should be oe.dev+master based", please speak up now
about why you're unable to use oe-core+etc.  We can't solve what we
don't know is a problem and frankly I think the TSC is of the mind
that oe-core+etc is as good as or better than oe.dev.  If we're wrong,
someone needs to tell us what's missing.

<Taking off TSC hat, putting on just my own>
In the beginning it felt like oe-core was missing a lot of handy
little things that oe.dev had gone off and made since the last time
there had been a sync up into poky (but there were its own good ideas
in there!).  We've now finally reached the point where it's really
just mechanical "migrate recipes A/B/C" (and not to trivialize these
efforts!).  I think it would be bad to go back to the point of "well,
now we need to move $concept from oe.dev into oe-core".

-- 
Tom

Re: Plans for OE classic future

[Denis 'GNUtoo' Carikli]

>If we're wrong,
>someone needs to tell us what's missing.
A lot of recipes are missing in the new core-based oe

>We've now finally reached the point where it's really
>just mechanical "migrate recipes A/B/C" (and not to trivialize these
>efforts!).
What about recipes that have patches without the correct header?
Migrating the patches to the new core-based oe may be trivial, but in order to 
be able to submit them you need to have the correct patch headers, right?

Some recipes are kept in the contrib/shr branches because of that issue.

I was thinking of a kernel-like staging area for recipes of bad quality. (for 
instance that lack the correct patch headers) so porting a big recipe like 
mplayer1 would not be a one-person effort anymore.

Or are the recipes with multiples patches lacking the correct headers not so 
common?

Denis.

Re: Plans for OE classic future

[Frans Meulenbroeks]

2011/11/25 Tom Rini <tom.rini@gmail.com>

>
>
> <Putting on TSC hat>
> The problem with this mindset is that we don't want to have
> oe-core+meta-oe+etc and oe.dev diverge any more than they had at the
> start.  This is why at some point master needs to become read-only.
> Everyone and their master based project can still fetch and build and
> work.  But if you're going right now and saying "I need to start a new
> project and it should be oe.dev+master based", please speak up now
> about why you're unable to use oe-core+etc.  We can't solve what we
> don't know is a problem and frankly I think the TSC is of the mind
> that oe-core+etc is as good as or better than oe.dev.  If we're wrong,
> someone needs to tell us what's missing.
>

Well, there is at least the issue of machines and architectures.
Now it is probably not too big a deal to bring over a new machine and turn
it into a BSP layers, but adding another architecture is yet another thing.

We do have products that are based upon NIOS II. This architecture is
present in OE classic and not in OE core.
One of the issues is that the NIOS II toolchain is still based upon (iirc)
gcc 4.1.1
I do not see an upgrade of gcc/niosii happen in the near future (In the
past I did spent some time to see if I could move to a newer version, but
there were some issues, and afaik no one is working on this atm), and I
doubt oe-core is interested in having a 4.1.1 toolchain around.

Therefore probably our next niosii project will still be oe-classic based.
On the other hand we also have ppc projects and the next one might quite
well use oe-core (it is too late to switch for the current one as we need
to release next month).

(and more general: oe classic still has quite some recipes that are not in
oe-core or meta-oe (apart from the fact that the latter is not really too
open to contributions; see the email thread on id3lib from a while ago).

Frans

Re: Plans for OE classic future

[Paul Menzel]

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

Am Samstag, den 26.11.2011, 16:45 +0100 schrieb Frans Meulenbroeks:

[…]

> (and more general: oe classic still has quite some recipes that are not in
> oe-core or meta-oe (apart from the fact that the latter is not really too
> open to contributions; see the email thread on id3lib from a while ago).

No, that is not true. The id3lib recipe had formal issues so it could
not be applied [2].

The only issue is that there is a disagreement if the guidelines for
OE-core [2] are mandatory for meta-oe too.


Thanks,

Paul


[1] http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-October/035854.html
[2] http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Plans for OE classic future

[Tom Rini]

On Sat, Nov 26, 2011 at 8:45 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2011/11/25 Tom Rini <tom.rini@gmail.com>
>
>>
>>
>> <Putting on TSC hat>
>> The problem with this mindset is that we don't want to have
>> oe-core+meta-oe+etc and oe.dev diverge any more than they had at the
>> start.  This is why at some point master needs to become read-only.
>> Everyone and their master based project can still fetch and build and
>> work.  But if you're going right now and saying "I need to start a new
>> project and it should be oe.dev+master based", please speak up now
>> about why you're unable to use oe-core+etc.  We can't solve what we
>> don't know is a problem and frankly I think the TSC is of the mind
>> that oe-core+etc is as good as or better than oe.dev.  If we're wrong,
>> someone needs to tell us what's missing.
>>
>
> Well, there is at least the issue of machines and architectures.
> Now it is probably not too big a deal to bring over a new machine and turn
> it into a BSP layers, but adding another architecture is yet another thing.
>
> We do have products that are based upon NIOS II. This architecture is
> present in OE classic and not in OE core.
> One of the issues is that the NIOS II toolchain is still based upon (iirc)
> gcc 4.1.1
> I do not see an upgrade of gcc/niosii happen in the near future (In the
> past I did spent some time to see if I could move to a newer version, but
> there were some issues, and afaik no one is working on this atm), and I
> doubt oe-core is interested in having a 4.1.1 toolchain around.

An external toolchain should be fine.  You should also be able to put
that gcc & company into meta-niosii.  If you can't, then IMHO, there's
a problem someone needs to look at.  But I suspect there isn't a
problem doing that.

> Therefore probably our next niosii project will still be oe-classic based.
> On the other hand we also have ppc projects and the next one might quite
> well use oe-core (it is too late to switch for the current one as we need
> to release next month).
>
> (and more general: oe classic still has quite some recipes that are not in
> oe-core or meta-oe (apart from the fact that the latter is not really too
> open to contributions; see the email thread on id3lib from a while ago).

Where someone asked Koen to document the differences between oe-core
requirements and meta-oe requirements?  Yes, that's reasonable but
lets not fool ourselves either, it's not vastly different, it's PR =
r0 or not (and PR is supposed to go away).

-- 
Tom

Re: Plans for OE classic future

[Frans Meulenbroeks]

2011/11/26 Tom Rini <tom.rini@gmail.com>

> On Sat, Nov 26, 2011 at 8:45 AM, Frans Meulenbroeks
>
> >
> > Well, there is at least the issue of machines and architectures.
> > Now it is probably not too big a deal to bring over a new machine and
> turn
> > it into a BSP layers, but adding another architecture is yet another
> thing.
> >
> > We do have products that are based upon NIOS II. This architecture is
> > present in OE classic and not in OE core.
> > One of the issues is that the NIOS II toolchain is still based upon
> (iirc)
> > gcc 4.1.1
> > I do not see an upgrade of gcc/niosii happen in the near future (In the
> > past I did spent some time to see if I could move to a newer version, but
> > there were some issues, and afaik no one is working on this atm), and I
> > doubt oe-core is interested in having a 4.1.1 toolchain around.
>
> An external toolchain should be fine.  You should also be able to put
> that gcc & company into meta-niosii.  If you can't, then IMHO, there's
> a problem someone needs to look at.  But I suspect there isn't a
> problem doing that.
>

In oe-classic it is not an external toolchain. It is also a CPU
architecture.
It mgiht be possible to make an external toolchain for it, but that does
not allow
saying things in recipes like: FILES_niosii += in other recipes (iirc there
are a few of these)

Moving the recipes to meta-niosii could also be done, and is probably
better as the toolchain is a set of OE recipes. I'm not sure if it is
possible to solve the ARCH problem that way, but one might get away with it
by e.g. bbappend-ing in all relevant recipes. This seems a fair amount of
work, so I guess this is not going to happen overnight.

BTW if this is felt to be a good plan then we might consider moving all
arch specific bits into an arch specific layer. (not too sure if that is a
good plan though).

>
> > Therefore probably our next niosii project will still be oe-classic
> based.
> > On the other hand we also have ppc projects and the next one might quite
> > well use oe-core (it is too late to switch for the current one as we need
> > to release next month).
> >
> > (and more general: oe classic still has quite some recipes that are not
> in
> > oe-core or meta-oe (apart from the fact that the latter is not really too
> > open to contributions; see the email thread on id3lib from a while ago).
>
> Where someone asked Koen to document the differences between oe-core
> requirements and meta-oe requirements?  Yes, that's reasonable but
> lets not fool ourselves either, it's not vastly different, it's PR =
> r0 or not (and PR is supposed to go away).
>

I feel that if meta-oe is considered an openembedded layer, its guidelines
should be made clear.
Also in that case it does seem desirable to use the same guidelines as OE
core uses where possible and only deviate if really needed (and in the PR
case there is probably no such compelling reason).
This last section may be off-topic for the discussion at hand, but it might
explain some of the reluctance to contribute to meta-oe and move to meta-oe.

Might be a topic for the TSC to discuss too.

Frans

Re: Plans for OE classic future

[Tom Rini]

On Sun, Nov 27, 2011 at 2:55 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2011/11/26 Tom Rini <tom.rini@gmail.com>
>
>> On Sat, Nov 26, 2011 at 8:45 AM, Frans Meulenbroeks
>>
>> >
>> > Well, there is at least the issue of machines and architectures.
>> > Now it is probably not too big a deal to bring over a new machine and
>> turn
>> > it into a BSP layers, but adding another architecture is yet another
>> thing.
>> >
>> > We do have products that are based upon NIOS II. This architecture is
>> > present in OE classic and not in OE core.
>> > One of the issues is that the NIOS II toolchain is still based upon
>> (iirc)
>> > gcc 4.1.1
>> > I do not see an upgrade of gcc/niosii happen in the near future (In the
>> > past I did spent some time to see if I could move to a newer version, but
>> > there were some issues, and afaik no one is working on this atm), and I
>> > doubt oe-core is interested in having a 4.1.1 toolchain around.
>>
>> An external toolchain should be fine.  You should also be able to put
>> that gcc & company into meta-niosii.  If you can't, then IMHO, there's
>> a problem someone needs to look at.  But I suspect there isn't a
>> problem doing that.
>>
>
> In oe-classic it is not an external toolchain. It is also a CPU
> architecture.

Right.  I'm saying that on the path to migration using OE classic to
export a NIOS II toolchain as an external toolchain and having
meta-niosii start by using that would save some headache.   Get the
basics building and working then bring in the toolchain.

> It mgiht be possible to make an external toolchain for it, but that does
> not allow
> saying things in recipes like: FILES_niosii += in other recipes (iirc there
> are a few of these)
>
> Moving the recipes to meta-niosii could also be done, and is probably
> better as the toolchain is a set of OE recipes. I'm not sure if it is
> possible to solve the ARCH problem that way, but one might get away with it
> by e.g. bbappend-ing in all relevant recipes. This seems a fair amount of
> work, so I guess this is not going to happen overnight.

Yes, meta-niosii would have some bbappend files and a copy of a few
bbclass files until those parts ARCH parts can be merged.

[snip]
> I feel that if meta-oe is considered an openembedded layer, its guidelines
> should be made clear.

Agreed.

-- 
Tom