[oe] [PATCH 2/2] omap4430-panda: fix u-boot

Tue Jan 11 11:26:48 UTC 2011

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 <dp at xora.org.uk>:
> 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<philb at gnu.org>:
>>>
>>> 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
>>>> tsc at lists.linuxtogo.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/tsc
>>>
>>>
>
>