-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
| I agree that it would be best to have a single kernel tree for all | Freerunner derived distributions, and Marcelo and I will help work | towards that with Openmoko with respect to Android. Great. | What we would like to see though, is a greater effort in the following | areas: | -Determine a tagging structure so that testing can take place at | well-defined points in development. There has been much change in | certain branches (particularly andy-tracking), causing some regressions | in particular areas (ie: charging). Right now we're living out of a tracking branch, and that's doing its job "tracking" upstream changes. When we fork this into the new stable, we won't be rebasing all the time as we are now (and introducing some incomplete code like recent pm tree changes). So we shouldn't be surprised it is up and down in *-tracking mode. We can tag things, but what do you actually have in mind when you say "testing can take place at well-defined points in development"? Just tagging stuff isn't really going to deliver what it sounds like you are thinking about there. What exactly is wrong with charging on current andy-tracking? AFAIK it's really good since Balaji's changes to pcf50633 and more recently charger restart on full stuff. Please test current HEAD and send Trac reports or patches. | -Determine a method of testing of new kernels allowing to find any | regressions in functionality Wendy in Openmoko does run and report regression tests independently already, so far nobody has packaged 2.6.28 stuff for her to try AFAIK due to "recent upheavals". When that is done, I expect this will be a good way to find trouble. Of course, you are welcome to feed this list and Trac with stuff you find, or patches. | -Documentation of the status of the kernel, and the stability of the | various subsystems Really this is Trac. I'll have a think if it makes sense to maintain a wiki page or something with overview. | In addition, I would like to explore how we might start to push some of | the Openmoko code back to the kernel mainline via the kernel staging | branch. The issue lies in being able to cross-pollinate the changes from | Android into the kernel as well as those for the Openmoko kernel. It it really down to us to push the Android changes? I would have thought Google would have been doing that. For getting the rest of our stuff upstream we have started it, but it is going to be a slow process. | What's driving this is the demand from our customers to have staged | kernels with well defined and tested subsystems. It will be great if Koolu are going to help with testing "subsystems" and increasing our quality. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAklbpdgACgkQOjLpvpq7dMpKwACbBS8hTFdhEQZIzjNQNOmnYPEL Sy8An101xioP1j5vLzU3qUTbC9hnC7hR =QSS6 -----END PGP SIGNATURE-----
