Il giorno sab, 18/04/2009 alle 08.38 +0200, piratebab ha scritto:
> I agree with you, the development cycle of SHR is different of the
> debian system. SHR testing is not evoluting smoothly, but step by step.
> I regret it, but it is the best way of working for the devs team.
> The simplest solution could be as the "apt-get upgrade " solution: ask
> the user if he agree to do the proposed update.
> But this is an opkg improvement, not SHR.
I know this, and i'm not saying that you should get a stable branch
rigth now, working with e17 is impossible to reach a stable branch,
everything is changing, it's the same with fso frameworkd and so on, i
don't pretend that, what i'm asking is to correct some upgrade known
bugs. The "missing icons" it was a known bug, if you upgrade a lot of
modules and change the kernel version (r2 to r3) a depmod is needed.
What i'm asking is just to pay some attention in the unstable to testing
update, if some bugs where fixed by installing e-wm-utils (if i remember
well), just make shr-task-base depends on it, not just putting some
packages from unstable to testing because this is leading a lot of
users, who use testing and update it daily or so, to have the same bugs
and problem of the unstable branch since last change, so 2 branch are
not so useful, just to have a bleeding edge branch like unstable, which
is updated daily and presents some small problems, and a more stable
branch like testing, which is updated twice a month and every update is
usually a reflash because there will be a lot of problems...
It will have more sense to provide some update to testing when a package
is working in unstable:
new package -> unstable -> testing
if there are big upgrades then provide a critical upgrade one by one,
eg:
illume upgrade, frameworkd upgrade and kernel upgrade then illume
upgrade, wait 2 days, frameworkd upgrade, wait 2 other days, kernel
upgrade.
This way if something borke something else you we can easily spot and
solve the problem.
Sorry for the long mail.
Bye!
Pietro
_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel
