Re: [yocto] Ideas for yoctoproject.org improvements
Hi, On 21.12.2010 20:01, Stewart, David C wrote: Hello Yocto Project – I was asked yesterday what kinds of things we might do to improve the project website, http://www.yoctoproject.org – I have a few opinions on the subject, but I thought I would put the question to you. Where can we do better? What kinds of frustrations did you have with the site when you first got involved with the project? How could it improve the experience of people becoming familiar with the project? I've just started looking at Yocto, but I have been following OpenEmbedded progress for two years now. So I don't have any comment yet on the yoctoproject website content but I noticed that : https://www.yoctoproject.org/ Leads to a broken, default, mailman page. Maybe this can be fixed ? If you want to use this email thread, that would be great. Or if you prefer to file issues in bugzilla.yoctoproject.org, that would be great too. Thanks! Dave Best Regards, -- Christophe Aeschlimann Embedded Software Engineer ACN Advanced Communications Networks S.A. Rue du Puits-Godet 8a 2000 Neuchâtel, Switzerland Tél. +41 32 724 74 31 c.aeschlim...@acn-group.ch ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Multiple Repository support
Hello, I've started collecting ideas from various emails on multiple repository support. http://wiki.openembedded.org/index.php/MultipleRepositoryMethods Please feel free to update the above page. In my mind, this is a key problem we need to solve, not just for Yocto/OE, but also for anyone doing product development. I've personally been using git submodules for most projects, and repo for Android based projects. Appreciate any ideas, experiences, or insights into how we solve this problem. Thanks, Cliff -- = http://bec-systems.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Multiple Repository support
On 10-12-22 11:09 AM, Cliff Brake wrote: Hello, I've started collecting ideas from various emails on multiple repository support. http://wiki.openembedded.org/index.php/MultipleRepositoryMethods Please feel free to update the above page. In my mind, this is a key problem we need to solve, not just for Yocto/OE, but also for anyone doing product development. I've personally been using git submodules for most projects, and repo for Android based projects. Appreciate any ideas, experiences, or insights into how we solve this problem. We've used (and walked away) from git submodules in the past for some really large projects. Our experiences closely match the bad on the wiki link you sent. I've met very few people who can effectively manage active development in a git submodule based environment. My blunt opinion is that if I never see another one in my life, I'd probably be happy. I haven't looked at a submodule in about a year, so maybe they have been fixed for the better .. but I'm skeptical. The solution to the submodule chaos that was used sucessfully was to create something we called 'subgits'. They use git, a wrapper script and standard git configs. A subgit points to a remote repo, specifies where it should be cloned, and has a place for special properties. You can recursively pull from a top level and have all subgits updated in a uniform fashion. The model can be extended for multi repository development as well. The big win here is that you can independently update repos, use normal git workflows, or wrap it as you want. Nothing is forced. Note: all the functionality of submodules isn't present here (global tracking, bisect, etc), but that was functionality that wasn't really crucial. Just some comments and opinions to throw into the discussion. Cheers, Bruce Thanks, Cliff ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] website
Hi all - Dave posted a request for website feedback on the blog. One idea that has worked well in other communities (including meld.org) is video walkthroughs of basic things, like setting up the environment, doing a first build, etc. Android does this - they don't have to be exciting or long, in fact the shorter the better, but it really helps for them to exist. There are several software packages that make it a breeze. keep up the good work, Jeff ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Master stability and the autobuilder.
All, In preparation for the M3 milestone, I've been taking notes on what our build and release process is and where the pain points are over the course of the M2 milestone. A few things I've noted that are concerning: 1. We have a really long build cycle. It takes a good 40 hours before contamination of master is recognized and a further 40 hours *at the very minimum* before it can be verified as corrected. 2. We are very resource constrained. Because the build loop is so long, our two build slaves are essentially in use 24/7. This will be alleviated soon with a new build slave, but not until after the new year. 3. There was an issue in M2 (which I'm not totally filled in on yet, I'm going to be pinging people for details) which caused some kernel issues around the M2 branch for ppc and arm. I haven't seen (and I've been swamped with email recently, so I may have missed it) any resolution on this in master. 4. People are relying on the autobuilder to do their builds or to verify their code. My main goal in M3 and on, is the stability of master. If we were less resource constrained, I could allow the autobuilder to be a global community resource where people could just queue up their various builds. That, unfortunately, is not the case for now. What this means is that I have to ask people for a few things. 1. I'll be cleaning up the poky autobuilder config within the git repo and making it very developer specific so that you should be able to run a script and have the autobuilder set up to run incremental and fulls (and an optional swabber target) on your own machine and have it work right out of the box. Once my pull for the new autobuilder comes through, please, set up your own local autobuilder instance. This should be by the EOD today. I'll be somewhat available through the holidays to assist people with local machine setups, but it should be fairly straightforward. 2. Please, make certain that your code builds on your local buildbot before submitting a pull request. As the project grows, maintaining the stability of master will become more and more important and the limited resources of our maintainers and our infrastructure will become more and more stretched. 3. I've dropped this recently, due to limited time, but I'm going to start sending out more and more broken build emails. Please, do not ignore these. Act on them. If you're think you may be responsible for something that is broken, let people know that you recognize the breakage and what you're planning on doing to fix it. 4. Until we know that master is stable (right now I know of 3 or 4 issues, email forthcoming), the autobuilder will be tasked with a very limited number of buildsets. I'll be generating a milestone type build off of master to get some quicker response (20 hours verses 38), and incremental versions of milestone and sanity testing. We will still be running nightly (although you can't see it on the autobuilder right now) and distro-testing but until master is stable, those have got to be the priorities on the autobuilder. -b ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1] linux-yocto: add dropped qemuppc configuration
The _ to - mass change mangled a config file name, which was dropped from the update. This adds the fixed file back to the meta branch of the kernel. Pull URL: git://git.pokylinux.org/poky-contrib.git Branch: zedd/qemuppc-fix Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/qemuppc-fix Thanks, Bruce Ashfield bruce.ashfi...@windriver.com --- Bruce Ashfield (1): linux-yocto: add dropped qemuppc configuration .../conf/distro/include/poky-default-revisions.inc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
