Dear Graeme, Personally I feel it is not done to forward private mail without permission of the author to a public mailing list, especially not if the email contains opinions on other people. If I did want to send this to the list I would have done so myself. I would have expected a more prudent behaviour of a board member.
Best regards, Frans. Dear list, As you can read above this was forwarded to the list without my permission or consent. Frans. 2011/1/11 Graeme Gregory <[email protected]>: > This is really a technical disagreement between two developers so forwarded > it back to the technical list. > > I do not have my panda yet to test new bootloaders, I can rely on the one > official supported by TI working well until tests on a newer version can be > performed. Until new version is tested on real panda I am against upgrading > it. If some distro does not have the sources in its fetchable list can the > source archive not be copied to a more general source mirror? > > Graeme > > On 10/01/2011 22:10, Frans Meulenbroeks wrote: >> >> Dear TSC, >> >> Thank you for your reply. >> I agree that replacing the SRC_URI with one that is fetchable >> independent on distro specifics is the safest way to handle this. >> (but then again the solution I took was suggested by the upstream >> maintainer of the code). >> >> Unfortunately I feel that this decision does not touch the core of the >> problem. >> The issue at hand is that we have a maintainer that is already aware >> of the issue for almost three months (I've reported this problem >> already back in october). >> However this maintainer fails to take action, and has an attitude of >> "it works for me and my distro it is ok, and if it does not work for >> someone else, I don't care". >> I would have appreciated it if the TSC would take a position against >> this attitude,and the neglection to properly act as a maintainer. >> >> I feel this attitude is damaging OE. >> The blunt actions of this person have already driven away several >> people, and frankly speaking I'm also rapidly loosing interest to work >> on issues that are not strictly needed for my own projects. >> I feel we have a serious problem at hand that should have been dealt >> with a long time ago, difficult as it is. >> >> If we want to have a future beside yocto, it is important to be a >> friendly, respectful and cooperative community. Otherwise I fear OE >> will be history in a short while (which is something that I would >> pity, having been a member of the project for 5 years or so). As a >> crew I feel we are already close to being subcritical in number. >> Anyway, I for me, I am getting tired of being bitched at, where a >> polite message probably would have had much more effect. >> This is especially the case if it is by someone who has repeatedly >> shown disrespect for the work of others when it comes to making >> changes. >> >> A bit sad, >> Frans Meulenbroeks. >> >> >> 2011/1/10 Phil Blundell<[email protected]>: >>> >>> Frans, >>> >>> Thanks for your email. We discussed this issue at the TSC meeting held >>> on 2011-01-05. >>> >>> The TSC feels that we should be guided by two key principles, namely: >>> >>> a) all recipes should have a SRC_URI which is fetchable without relying >>> on any DISTRO-specific configuration (e.g. custom source mirrors); and >>> >>> b) the version number (or SRCREV) of a given recipe should only be >>> bumped after testing and consultation with its users. This applies >>> particularly to packages such as bootloaders and kernels which contain >>> many machine-specific parts and which would have particularly bad >>> consequences if inadvertently upgraded to nonworking versions. >>> >>> In this particular case the TSC believes that the right course of action >>> is to: >>> >>> 1. Find a way to repair the SRC_URI for the existing u-boot recipe so >>> that it is fetchable for everyone, but without changing the version of >>> the source code in use or the resulting binaries. (For example, the >>> SRC_URI could be pointed directly at a snapshot tarball hosted in some >>> suitable place.) >>> >>> 2. Create an additional recipe for the current mainline version of >>> u-boot which can be fetched from SVN. Individual machine maintainers >>> can test this version and, if it works for them, switch to using it at >>> their discretion. >>> >>> Regards >>> >>> Phil >>> (for the TSC) >>> >>> On Sat, 2011-01-01 at 19:37 +0100, Frans Meulenbroeks wrote: >>>> >>>> [Added TSC to the email, as I would like to request a decision on how >>>> to handle this] >>>> >>>>> Frans, given these two choices: >>>>> >>>>> 1) Recipe that builds and has tested output (but depends on distro >>>>> source >>>>> mirrors). >>>>> >>>>> 2) Recipe that builds (even without source mirrors), BUT the output is >>>>> not >>>>> tested. >>>>> >>>>> We should use choice #1, since the OUTPUT is tested. If someone who can >>>>> test >>>>> the output wants to bump the SRCREV, that is fine. Bumping SRCREVs just >>>>> to >>>>> get recipes to build and not testing the output only leads to >>>>> frustrated >>>>> users who think the output works. >>>>> >>>>> I'd point out that no one on the panda list (or this list) has >>>>> mentioned >>>>> they noticed the recipe doesn't build, so I am not sure you are >>>>> addressing >>>>> an actual problem. >>>>> >>>>> Philip >>>>> >>>> Philip, thanks for your reply. >>>> >>>> I'd like to point out that the fact that the recipe does not build has >>>> been reported to this very list late oct 2010. >>>> At that point Steve Sakoman (the owner of the git from which the >>>> recipe pulls) suggested to use u-boot 2010.09. >>>> I did not get to fixing the recipe until yesterday. As u-boot 2010.12 >>>> is already out I figured that this would be a better choice. >>>> I am also on the u-boot list and I know the changes from Steve are >>>> pulled into u-boot master. >>>> (and wrt to availability: I am quite confident that in a few years >>>> time this version can still be retrieved). >>>> >>>> The problem that this recipe does not build is already known for more >>>> than 2 months but the machine maintainer apparently is not interested >>>> in fixing his recipe. >>>> As such I feel the maintainer is doing a bad job. >>>> >>>> There are several ways to fix the problem. >>>> To coin a few: >>>> - move to a SRCREV that seems to me more stable (e.g. because it is a >>>> merge with upstream). I agree that there is still a chance of getting >>>> a breakage in the future >>>> - putting the tarball for the version that we have now at e.g. >>>> downloads.openembedded.org or so and adapt the recipe (we have done >>>> this for other recipes as well) >>>> - move to upstream. The panda changes from Steve have been merged by >>>> Wolfgang. I am not aware of any reason not to do so. >>>> >>>> While each alternative has its pro's and con's none of them is >>>> complicated, and any of them could have been done easily. >>>> As the problem is already reported last october, I feel the maintainer >>>> is not doing a good job, and actually makes things worse by abusing >>>> his powers to block others who want to fix it. >>>> Apparently spending a few minutes to resolve the issue is too much >>>> work, but there is of course always time to bitch and moan toward >>>> others who do want to keep OE a system that supports multiple machines >>>> and multiple distros. >>>> >>>> I'd like to ask the TSC to come up with a decision on how we should >>>> fix this recipe. I have already indicated a few solutions above. Yet >>>> another alternative (which is not too desirable) is to create another >>>> machine that chooses a proper recipe for u-boot. >>>> >>>> Frans >>>> >>>> PS: the fact that there are no other reports of this is probably >>>> because not many people rebuild u-boot. Most of my boards still use >>>> the u-boot that was on the board when I got it. I guess this also >>>> holds for other people. >>>> >>>> _______________________________________________ >>>> tsc mailing list >>>> [email protected] >>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/tsc >>> >>> > > _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
