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<ph...@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
t...@lists.linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/tsc
_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
