On 2010-04-22, Roberto Previdi wrote: > On 04/22/10 16:15, Sebastian Spaeth wrote: > > Because shr-testing had other severe bugs that required bumping some > > versions and due to the interconnectedness of all those apps this > > required bumping more things than I wanted. I am sorry that the contact > Ok, i wanted to know if the frequent bump is a standard or an exception.
It is supposed to be an exception. I usually only cherry-pick single fixes. However as the systems are quite intertangled and some fixes depend on other fixes having been applied too, cherrypicking gets more difficult over time as the branches diverge. Openembedded is quite active (the last month alone had 922 commits) and it became impossible to just pick the isolated version bumps. So after making a whole uncompilable mess while trying, I decided to start from a clean slate and just merge in the current shr-u (which is just upstream Openembedded development branch nowadays). This does not excuse glitches, but it hopefully explains them. > > app requires some workaround now, but at least the GSM will reliably > > connect now, hopefully. (plus other bug fixes). > I'm sorry, but i don't see improvements on that part, sometimes it won't > connect at all (like now, for example), 2 or 3 reboots and it connect. > like before That is sad and I hope that shr-unstable will soon fix these things so I can cherry pick them. > Well, i could do it, or we just could use the testing in this way and > make a stable release. stable don't mean perfect, it means that it's the > most stable release until now.. i think it's better to have a stable > release updated once in a year than nothing at all.. Preaching to the converted here. I tried to do that be calling it stable and got told off for it. :-) Having that said, everyone was OK with providing a know-to-be-ok directory in which the latest best testing snapshot is provided for a year. If someone would pick up that torch, many would be happy (I'm not going to). > > Sorry if I sound grumpy, I am not grumpy or annoyed :-) > Sorry if i sound polemic, it just come from the frustration of having > been a follower of shr since it's born (many months and many flashes, > and many destructive opkg upgrade), and i would like to see it coming to > the stable goal. When i tried, in my little, to send a couple of patches > i have been discouraged and finally abandoned for the infinite burocracy > to change something in openembedded.. and i think 90% of shr problems > come from there.. I understand the frustration, I have the same. My wife is always making fun when I am not reachable by phone (and sometimes she is rightly annoyed). I tend to agree that OE brings as many problems as it solves, but that is just my personal opinion. There are just too many fast-moving targets, plus I am not happy with neither the package manager, nor the fact that bitbake can't easily do versionable dependencies (package x requires >=version y of package v) nor customizable builds (e.g. upstream EFL disabled gif, and I don't see a simple way for us to override that choice for SHR). Much of my gripes may come from not knowing the features that bitbake/OE offers, but many of the solutions I have seen, are more of a hackish workaround than proper solutions from a package manager/builder. But as I don't have the time nor energy to start up SHR on a different distro basis, I try to not complain too much about the choices others made and who do invest the efforts. spaetz _______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
