I've been following this list since last December, when I bought my Beagle.
Something that I just noticed is that when someone has a problem
compiling 'x' or 'y', outside the OpenEmbedded world, it is a little
bit hard to follow since commits or tags are not mentioned. I remember
some threads where this happened though (the mentioning of the commits
and / or tags), so maybe it's just a recent event.
Could it be somehow required to post the commit / tag in use of the
Linux Kernel (or module or package) so that tracking problems and
successes is easier?
Maybe this could be further explained in one of the wikis (some git
esentials along with the tagging policy in use, etc.).
Of course, that's my 2 cents. Any input on this will be greatly appreciated.
By the way, out of curiosity, the Linux Kernels tagged with an OMAP#
at the end, what does the OMAP# mean?
In my opinion the only way to synchronize the development in a such
complex project is to use OE and to really learn perfectly how to use
it.
I'm learning it.
A bug tracking should be interesting, see for example "trac" or https://launchpad.net.
The first can be installed somewhere, the second one can be hosted
only inside https://launchpad.net (used by ubuntu).
In the actual situation, really unstable, you can search in this
group, or, maybe, in irclogs of beagleboard, maybe using an automatic
wget script.
When we use a bug tracking system, normally we need a mantainer, and
we have to know the goals, that is doing a perfect support to
beagleboard or integrating omap3 in kernel mainline ?
I think the situation is really unstable and the magic commands:
cd oe/openembedded
git pull
bitbake beagleboard-demo-image
permits to everybody to create a very complex Angstrom filesystem for
beagleboard.
Them you can add a good OE knowledge and you can add your contribute
testing or adding something.
I hope we'll arrive soon to an omap3 kernel fully integrated in the
mainline.
I do agree with you that OE is a way of synchronizing development. I
haven't tried it out fully yet. I know a little bit of it and I'm
trying to learn about it to catch up.
I guess the different "recipes" can help in recreating particular
versions of the distribution. Still, I'd find it more useful to work
with commit hashes and tags and somehow create the list of what works
and what doesn't. I know that the latest kernel has audio broken (or
at least in what I have as the latest) and that I have a clone of the
x-loader git repository (up to commit
037a8ed45e9ecfffacfaab0b7a713fdde56d155a), but don't know for sure if
the latest is the best to flash or if there's another version that's
more recommended (it doesn't have any tags, by the way, that could
provide a hint on this).
So, what I'm looking for with this thread is to know if a record of
working versions based on hash keys and tags would be useful or not
for the community and if it is useful, I'd like to help out with this
(of course, with the community's help: I'd need everyone to provide
more information when reporting problems, bugs and successes).
Yes, there are threads and IRC logs one can search in, but I think
freezing certain versions and communicating them would be more useful,
so that a baseline exists while development moves forward (from what
I've read, of course, I think there have been good versions already
from which one can assemble a baseline; if none of the versions can be
considered as part of the baseline because of their level of maturity,
well, I guess there's always a first time). The baseline would be even
more useful if a record of what works and what not is included, in my
opinion.
Please do let me know about your comments. Feedback is always welcome.