Hello Hans, [Seems went to me only, re-adding cc:]
Sunday, January 6, 2008, 6:23:57 PM, you wrote: > On Jan 6, 2008 5:05 AM, Paul Sokolovsky <[EMAIL PROTECTED]> wrote: >> Hello Hans, >> >> Sunday, January 6, 2008, 9:31:08 AM, you wrote: >> >> > Richard was able to finaly close out some of the last nagging 2.6.23 >> > bugs for poodle (LED driver and LCD corruption on resume). >> >> > I would like to propose updating linux-rp-2.6.23 to the latest version >> > in the stable branch and making it the default for poodle. >> >> Just a quick conservative check - are you sure 10 days after the >> release, you're already want to burden users with a kernel upgrade >> thing (unless poodle got it right, then sorry)? Bug fixes you name >> probably fully worth it, but are you sure that next week or two won't >> bring more fixes which could be pooled up? > The biggest advantage of this change would be to bring all or the > Zaurus machines up the the same kerenel level. As for putting it in > here, I woluld like the users to try autobuild images ASAP. Ok, good plan. >> > linux-rp >> > 2.6.17 can then be dropped, unless someone else is still using it >> > (Tosa?) >> >> I'd vote to make as little branch-only changes as possible. People >> should not treat current stable branch as their new home where they >> love to brush grass for purely aesthetics reasons, but merely as a >> highly temporary, dead-end stable branch which will go away in a short >> amount of time (the branch won't serve even 3 years, so that's it - >> short period of time). Even with that outlook, it's clear that >> dropping something makes no sense - drops will be undone soon. But >> more generally, the more changes we do to the branch, the harder for >> us will be switching from maintenance of old release to development >> and elaborating the new one in the non-transient branch. > That sounds like a good plan. The only reason I brought this up was > that RP has warned me that 2.6.17 was going to be removed from .dev > soon. But it might actually be good to archive this in .angstrom for > now. Ah, sorry for confusion then. I thought reasons for removal would be "make bitbake parse run faster" or something. If that's kernel maintainer's motion in the main branch, I'd rather vote it to be propagated, unless there're specific reason it maybe still useful in branch. Again, what I argued, is that we'd rather keep trees close, at least for content changes (specific recipes), if not infrastructure. Sooner or later we may need to diff to diff 2 trees against each other, so the cleaner we make changes, the easier it will be (and chances of such need will be lower in the first place of course ;-)). > Thanks , -- Best regards, Paul mailto:[EMAIL PROTECTED] _______________________________________________ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
