Re: [oe] Plans for OE classic future
On 2011-11-25 23:04, Tom Rini wrote: On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks fransmeulenbro...@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 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Plans for OE classic future
On Sat, Nov 26, 2011 at 3:57 AM, Ulf Samuelsson ulf_samuels...@telia.com wrote: On 2011-11-25 23:04, Tom Rini wrote: On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks fransmeulenbro...@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 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Plans for OE classic future
2011/11/25 Tom Rini tom.r...@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 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Plans for OE classic future
2011/11/26 Tom Rini tom.r...@gmail.com On Sat, Nov 26, 2011 at 3:57 AM, Ulf Samuelsson ulf_samuels...@telia.com wrote: On 2011-11-25 23:04, Tom Rini wrote: On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks fransmeulenbro...@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 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Plans for OE classic future
2011/11/25 Tom Rini tom.r...@gmail.com On Thu, Nov 24, 2011 at 1:33 PM, Paul Menzel paulepan...@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 k...@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. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Plans for OE classic future
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 signature.asc Description: This is a digitally signed message part ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Mac OS X redhat-lsb
I tried both 2.6 and 2.7. Same result. Brett On Nov 25, 2011, at 7:29 PM, Tom Rini tom.r...@gmail.com wrote: On Fri, Nov 25, 2011 at 12:19 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: On Fri, Nov 25, 2011 at 12:52 PM, Brett McMillian brett.mcmill...@crossfieldtech.com wrote: Here are the steps I have run successfully so far. 1) ./scripts/rhel5-oe.sh 2) Edited the first line of ./scripts/create-config.py to read: #!/usr/bin/python2.7 3) ./scripts/create-config.py --config-file=fsl-p1022ds/sample-create-config.ini --features=native-development -j 4 -t 2 4) source build_p1022ds_release/bitbake.rc 4) bitbake devel-image Just for everyone's information, some of this stuff is specfic to the Freescale SDK. But, I think the rest should be valid. OS X isn't a supported (nor functional) build environment today nor in the snapshot that SDK is built from. The first bit of problems sound like a well, try python 2.6 instead but once you overcome that, other things will fail. -- Tom ___ 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: [oe] Plans for OE classic future
On 2011-11-26 16:20, Tom Rini wrote: On Sat, Nov 26, 2011 at 3:57 AM, Ulf Samuelsson ulf_samuels...@telia.com wrote: On 2011-11-25 23:04, Tom Rini wrote: On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks fransmeulenbro...@gmail.comwrote: 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 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Plans for OE classic future
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 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Plans for OE classic future
On Sat, Nov 26, 2011 at 8:45 AM, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2011/11/25 Tom Rini tom.r...@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 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Plans for OE classic future
On Sat, Nov 26, 2011 at 8:49 AM, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2011/11/26 Tom Rini tom.r...@gmail.com On Sat, Nov 26, 2011 at 3:57 AM, Ulf Samuelsson ulf_samuels...@telia.com wrote: On 2011-11-25 23:04, Tom Rini wrote: On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks fransmeulenbro...@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 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Plans for OE classic future
On Sat, Nov 26, 2011 at 9:11 AM, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2011/11/25 Tom Rini tom.r...@gmail.com On Thu, Nov 24, 2011 at 1:33 PM, Paul Menzel paulepan...@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 k...@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 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Plans for OE classic future
On Sat, Nov 26, 2011 at 11:53 AM, Ulf Samuelsson ulf_samuels...@telia.com wrote: On 2011-11-26 16:20, Tom Rini wrote: On Sat, Nov 26, 2011 at 3:57 AM, Ulf Samuelsson ulf_samuels...@telia.com wrote: On 2011-11-25 23:04, Tom Rini wrote: On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks fransmeulenbro...@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 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Plans for OE classic future
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 signature.asc Description: This is a digitally signed message part ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Plans for OE classic future
On Sat, Nov 26, 2011 at 3:01 PM, Paul Menzel paulepan...@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
Re: [oe] Plans for OE classic future
On Nov 26, 2011 11:02 PM, Paul Menzel paulepan...@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 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Plans for OE classic future
On Sat, Nov 26, 2011 at 20:37, Raffaele Recalcati lamiapost...@gmail.comwrote: ... 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: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Plans for OE classic future
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
Re: [oe] Plans for OE classic future
On Sat, Nov 26, 2011 at 3:44 PM, Otavio Salvador ota...@ossystems.com.br wrote: On Sat, Nov 26, 2011 at 20:37, Raffaele Recalcati lamiapost...@gmail.comwrote: ... 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 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Plans for OE classic future
On Sat, Nov 26, 2011 at 3:49 PM, Paul Menzel paulepan...@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
[oe] Documentation problems
Hey all, As things stand today, the wiki is out of date and a number of folks refuse to work on it. Using things like It's all text! for firefox only go so far and don't solve problems like people just avoiding documentation anyhow. Paul Menzel has mentioned that ikiwiki has been mentioned before and that lets us have the website in a repository. Do folks have other ideas? -- Tom ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
