Re: Keeping Glib up to date (was RE: Diablo, do we need a separate repository?)
ext Graham Cobb wrote: Nokia should be keeping all system libraries up to date and should be scheduling testing, to verify that the updated libraries do not break anything, as part of the release cycle. It is part of Nokia's responsibilities to its development community. Sure, and using fresh libraries is the general intend. For the development community and the own Nokia developer teams. Then real life comes with just one predictable thing: every day has 24h. And one clear goal: we need to ship the next release on week nn. Architect decisions are made, some go through, some go back, some go through again after some work... But not even glib will put in risk a deadline if it's not worth from a consumer point of view. Other software projects might have different priorities and that's fine. During the life of an installed release, I agree. Between Nokia-issued firmware releases, I disagree. My view (I realise you disagree) is that at each new release Nokia should update all shared libraries. We don't work release after release. There is ongoing plans and development at different stages on different releases. Even if football fans and media present each game as 90 minutes where a team has to put all the flesh, in the coach's mind there is a couple of national competitions, the European competition, the players that will go to the national team on specific dates... You need to make some sense of all that without burning your team. Same for us developing software, more or less. Chinook was a major release (4.0), Diablo is going to be a minor release from a platform point of view (4.1) and Diablo+1... we will start talking about it soon. -- Quim Gil marketing manager, open source maemo software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Keeping Glib up to date (was RE: Diablo, do we need a separate repository?)
On Tuesday 06 May 2008 13:32:34 [EMAIL PROTECTED] wrote: A properly versioned operating system should be able to handle side by side libraries. Why on earth bother? I am also not a DD but my understanding was that in Debian this was only done when some ABI change occurs and means an application can only work with either the old or the new version. IIUC the Debian approach to this issue would just be to replace libglib-2.0.so.0 (etc.). It should ONLY be a testing issue to make sure glib is kept up to date in every release and it should be Nokia policy to keep it up to date unless it is discovered to break an application. Please don't make assertions about such things. Especially if they involve resources you don't control. I certainly will make assertions about such things. I am fairly confident in my assertion that this is only a testing issue -- no code changes required -- but feel free to correct me if I am wrong. Note that I didn't say it was a *small* issue, just that it was a testing issue. I will also continue to assert, as a customer and a member of the development community which helps Nokia be more successful by providing additional applications, that Nokia should be keeping all system libraries up to date and should be scheduling testing, to verify that the updated libraries do not break anything, as part of the release cycle. It is part of Nokia's responsibilities to its development community. That said, to some extent people obviously do want to use later versions of libraries when/where possible. No one loves the idea of using code that's many years out of date with its ever growing set of known bugs. However sometimes bug-wise compatibility triumphs. During the life of an installed release, I agree. Between Nokia-issued firmware releases, I disagree. My view (I realise you disagree) is that at each new release Nokia should update all shared libraries. If it felt like it. While this would mean you'd have multiple glibs on the system, it isn't impossible to do, and if you absolutely need it, you could do it. Sure, I could do that. I could also build my own tablet or move to another product. But my goal is to make a particular piece of software (e.g. Opensync) run on the tablet. The barrier of creating my own glib package, (and trying to co-ordinate a community effort to use it so we don't all have to do the same thing), just to workround a Nokia restriction, may just raise the bar beyond the level I am willing to take to proceed with the project. To take a real example, I previously supported Opensync on mistral, gregale, bora and chinook. I have already abandonned support for all except chinook because it was too much effort to deal with the old glib versions. For the moment I persevere with chinook, patching Opensync to make it work with 2.12.12. One day even that will become too hard, at which time Opensync on Maemo will die unless Maemo includes an up to date glib. I am hopeful that Nokia believes it is in Nokia's interest to provide some level of support for the community. That should include not frustrating community efforts to port software. If Nokia really want to stay on an old version of glib (or any other library) they should take the hit of creating their own libraries, not the community (which is why I suggested nokiaglib). And no. I'm not a DD, my advice does not constitute Debian advice. I'm a pragmatist and a hacker. If I need something, I make it work. If the community is to solve the problem I think it would be easier just to develop a patch to disable the Application Manager preventing updates to system libraries (and get rid of that annoying click-through warning while we are at it!). I'd be curious to see a list of applications that require newer glibs. That seems kinda strange to me. Nothing strange at all. Glib continuously adds new functions. The whole purpose of Glib is to be a library of useful functions. People use them. Nokia taking the benefit of using opensource code while deliberately making it hard for other projects to make use of the same benefit seems unreasonable. I believe Nokia has three feasible course of actions: 1) make sure system libraries are kept reasonably up to date; 2) use private libraries and let the community use bleeding edge libraries if we want; 3) turn off the locks preventing the community from updating system libraries. Personally I prefer 1 (because we all benefit from core system libraries not changing underneath us and can concentrate re-testing on OS updates), then 2 (the locks on system libraries do help with stability). Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Keeping Glib up to date (was RE: Diablo, do we need a separate repository?)
On Tuesday 06 May 2008, Graham Cobb wrote: To take a real example, I previously supported Opensync on mistral, gregale, bora and chinook. I have already abandonned support for all except chinook because it was too much effort to deal with the old glib versions. For the moment I persevere with chinook, patching Opensync to make it work with 2.12.12. One day even that will become too hard, at which time Opensync on Maemo will die unless Maemo includes an up to date glib. And given that GPE apps and opensync are *SO OBVIOUSLY MISSING* (I can't stress that enough ;-) on the tablet, everything that can help that is important. I am hopeful that Nokia believes it is in Nokia's interest to provide some level of support for the community. That should include not frustrating community efforts to port software. If Nokia really want to stay on an old version of glib (or any other library) they should take the hit of creating their own libraries, not the community (which is why I suggested nokiaglib). I love the tablet because of its openness, because it allows me to develop the very specific applications I need for my work on a small device. However, and I'm not the only one thinking that given what is written on the various forum on the subject, there are many missing applications in the default OS (without talking about the general look-and-feel), and without the community (I'm not including myself in that), the tablet might not have the success it has. Fred P.S. Sorry for not contributing anything else than a rant ;-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Keeping Glib up to date (was RE: Diablo, do we need a separate repository?)
That said, to some extent people obviously do want to use later versions of libraries when/where possible. No one loves the idea of using code that's many years out of date with its ever growing set of known bugs. However sometimes bug-wise compatibility triumphs. Graham Cobb wrote: During the life of an installed release, I agree. Between Nokia-issued firmware releases, I disagree. I suspect the original hope was that diablo would have been delivered by SSU. If you keep that in mind, does it help change your view? Also note that the merge cost for hundreds of packages exceeds the small window for a project like diablo (which really really was a dot release). My view (I realise you disagree) Actually, in this case, I have no particular opinion. I understand why Nokia did it, and I can understand why you're upset. From a technical perspective, the browser team did not have enough time/resources to merge to trunk (nor was there a stable trunk of any value until long after we were frozen) and get any work done for diablo. We therefore had to choose not to merge to trunk and plan to do it for a future release. Most other projects (excluding wimax) probably had much fewer resources than the browser (in some cases they probably had no resources at all). is that at each new release Nokia should update all shared libraries. I think the key is that you're ascribing this to be an OS release. It isn't. it's a dot release. We never claimed it was a new OS release, the marketing information on this is quite clear, and I can't imagine anyone from Nokia would have claimed otherwise. http://www.backports.org/dokuwiki/doku.php You are running Debian stable, because you prefer the stable Debian tree. It runs great, there is just one problem: the software is a little bit outdated compared to other distributions. That is where backports come in. Think of chinook as a debian stable. Diablo is basically a collection of libraries provided by Nokia for chinook. You still have old libraries, and because it isn't actually newer software, the more you use it the more little bit outdated your software will become until an actual new distribution is released. As for how you manage to get a backports.org up and running, obviously that the package manager makes it harder is well... Unfortunate. But such is life. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
