Good day, On Wed, 2008-05-07 at 10:40 +0100, ext Graham Cobb wrote: > On Wednesday 07 May 2008 09:07:16 Kimmo Hämäläinen wrote: > > Please make a bug for me to update libxml2 at some point. Usually I'm > > adhering to the well-known principle "do not fix it if it's not broken", > > because of years of experience has taught me there's some truth in it > > (when people come spank me for breaking their software). Btw. We've had > > some big problems with Glib upgrades in the past -- some builds broke > > and caused delays in SW deliveries -- you cannot really know in advance > > what will happen, thus the "do not fix it..." is quite wise. > > I will create a bug for libxml2.
Thanks. > But, unfortunately, Nokia has got itself into a very difficult position. Of > course, as a software developer, I embrace the principle of "don't fix it if > it ain't broke". But Nokia wants Maemo to be a development platform, with a Nokia's top priority are the products and the SW that goes into the sales release. Libraries such as Glib clearly move too fast for Nokia, because the APIs and code should be stabilised well before (several months) the sales release, and also because some people want to keep the ABI-compatibility (that is broken by adding new functions) between certain Maemo releases. Nokia cannot plan its product releases according to Glib release plans (that would also be a bit too easy for competitors ;)). > community of developers. It cannot do that if it LOCKS the system into > obsolete versions of important libraries. I would not call it locked, because you can certainly install new SW there and modify most of the system (I do it almost every day at work!). > If Nokia wants to continue with the Internet Tablets being a platform for a > community of developers, it only has two reasonable choices: > > 1) Abandon the principle of "if it ain't broke..." and make a commitment to > keep all system libraries up to date. Clearly this will increase testing It would provide some testing, but not the kind of testing that counts the most: testing the library as part of the product software itself (the whole software stack), when it's not even available outside Nokia yet. Libraries such as Glib are certainly tested by the open-source community and desktop Linux distributions, but they lack testing in our specific hardware and software stack. > costs and also increase project risk (I used to be a development manager -- I > feel your pain). But, it can be done, if Nokia is willing to accept the > increased cost. Unfortunately, currently the products make the money, not the development platform, and we are part of this capitalist system. However, I agree, we could do better with regard to up-to-date software. It is also very important that we get some pressure to upgrade the package version, e.g. from this mailing list. > 2) Create a separate set of libraries (either nokiaglib, nokiaxml2, etc or > a /usr/nokia/lib directory) for Nokia-provided applications to use and > release the lock on the community upgrading normal system libraries. One of our principle has been to be as close to desktop Debian (not the newest one, for the reasons I explained above) as possible. This would break it. > I actually prefer option 2 because the problem is not only keeping libraries > up to date. For example (if I remember correctly), libopenobex in chinook > has been built without bluetooth support (or something like that). If Nokia > are going to prevent us updating their libraries, I would prefer if their > libraries did not have the same name as the real libraries. If Glib would be truly ABI-compatible, you would not need to write e- mails like this. You would simply put a dependency to it and upload it to extras or take it directly from a Debian armel repository (yeah, in a dream world). > I know Josh has suggested that the community do the opposite of option 2 > (e.g. > create /usr/maemo/lib) but I do not think that is realistic or feasible. > Nokia has both the incentive and the staff to do and maintain option 2. The > community does not. And any solution has to apply to ALL libraries (for > example, what if Nokia suddenly decided to use, and ship, libsoup in the next > release, suddenly turning it from an updateable to a locked library) and be > fully integrated with the SDKs. Only Nokia are realistically in a position > to do that. If you need the new Glib for your personal use only, you could do all kind of hacks. If you need more people to use it, you need to do more hacks. I don't see how Nokia could prevent this from happening, because we will always have out-dated SW when the product comes out. This will happen until someone shows the top managers some figures how selling products with the newest Glib will be bring more money even with the risk of breaking the existing SW. > Otherwise, one (or, more likely, both) of two things will happen: community > support will decline (if I cant get Opensync to work I will start keeping a > look out for an alternative toy for my next upgrade), or people will start to > bypass Nokia's locks, replacing core system libraries anyway, and causing > system instability. You are certainly free to do that. Just out of curiosity, which Linux- based handheld would you take as a replacement? BR, Kimmo > > Graham > _______________________________________________ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
