Am 23.04.2010 um 09:06 schrieb Sebastian Spaeth: >>> 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..
One thing you need to realize is that the unstableness merely comes from the fact that we are doing groundwork here. If all we would have to do is work on applications, we would have a great user-friendly software stack by now. However, we are also working on * build infrastructure (servers, release processes, OpenEmbedded), * a Linux distribution (SHR), * a middleware framework (FSO), and last but not least * a set of phone applications. These four dimensions are the problem (combined with a lack of manpower, but that only adds up, it's not a problem on its own). Due to the overall level of maturity, changes in one or two of these dimensions require changes in at least one other dimension as well – which in turn may have impact on the last dimension. No wonder the likeliness of things blowing up is huge. I'm afraid we will not reach any convincing level of stableness until we manage to fix three of these four dimensions and only work on one. It does not necessarily mean anything but one thing will come to a halt, however for a certain phase it's really critical. Otherwise we're just following a moving target never coming to a release. > 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. While OE has certain deficiencies, the roots of the problem is the four dimensions moving. The moment you stop developing software, you can branch off and start polishing packaging. We can't though, since we need to develop software as well. > > 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. If there was something better, we would have switched since long. Things like OpenWRT are not more stable, they're just orders of a magnitude less flexible. Plus, you will lose about ~100 experts helping you to not think about packages that just work because someone else is taking care of them. :M: _______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
