PR1.2 SDK for Extras-devel: how to solve?
Hi, The number of issues being caused by the deployment of PR1.2 SDK to the fremantle autobuilder is becoming critical. It doesn't even matter when PR1.2 is released, as we should have a way of dealing with this in-place for the next upgrade. BACKGROUND ~~ After the PR1.2 SDK was released, Niels deployed it to the autobuilder; enacting a plan which was discussed on this list. This has caused problems with libhildon dependencies, but the problems aren't just limited to that library: http://lists.maemo.org/pipermail/maemo-developers/2010-March/025668.html Both Niels and the Council believe we should do something to assist. WHAT WE SHOULD DO ~ We *need* to do something, both to improve the situation in -devel and -testing today, and test an approach for the next upgrade. The main requirements here are, I think: * It's not an excessive amount of work * It's a viable long term strategy * The QA process doesn't get broken Thoughts and comments from developers, or anyone else with a idea, will be much appreciated. OPTIONS ~~~ 1) Deploy SDKs as they are released; treat -devel and -testing as trunk. This is what we have now, I think we can say it doesn't work if there's going to be more than a few days between SDK release and device upgrade. Since Nokia doesn't pre-announce release dates, and last minute bugs could cause problems; I think we can rule this one out. 2) Revert the builder. This is basically a step backwards. Changing the builder config is easy. Cleaning up -devel and rebuilding the affected packages is quite some work as we don't have any scripts for that made yet. 3) Hack the SDK, create some kind of hybrid. This'd be bad enough if limited to just libhildon, but isn't viable and WILL cause unforeseen problems. Veto :-) 4) Create separate repos, build queues for pre- and post-1.2. Similar to what's been done for Extras proper. Creating the repos will be about a day work, but the part that sits on top of that (management scripts, Packages interface, QA queue) will probably take a week of work. There are hard issues around QA here. 5) Try building in each SDK in turn. My suggestion; when someone uploads to fremantle auto-builder it attempts to build the package against the PR1.1 SDK. If it succeeds, it goes into Extras-devel. If it fails to build, it gets built with the PR1.2 SDK, and so on. For an app with compile time symbol resolution (e.g. C/C++), this'd handle both cases quite nicely. Python apps would have to depend on the specific versions of bindings which gave them the features they wanted - again, not too much of a problem. At extras(-stable) promotion time you could even decide, based on actual binary package dependencies, whether to put in fremantle-1.2 or both fremantle-1.2 fremantle extras repos. This would fix another common complain, what if I don't upgrade for a few weeks. Larger packages could be prevent from being tried to built twice by stating a forced build dependency on a PR1.2 version of any system package. Some software won't install from -devel and -testing as it does now, but that will be reduced to the set of software which is actually using features that are unavailable. A HAM patch could grey out applications which were uninstallable, or show some other indication. This is, effectively, reinventing the more intelligent dpkg-shlibdeps: http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps However, it deals with the following three circumstances: 1) Application uses API which has changed in later SDK. This will be built with PR1.1 SDK, succeeds and goes into Extras-devel. Can be promoted to Extras-testing but there's no clear way for a tester to know it won't work if their device is running the latest OS. 2) Application uses API which is unchanged in later SDK. This will be built with PR1.1 SDK, succeeds and goes into Extras-devel. Can be promoted to Extras-testing and tested on any device with PR1.1 or PR1.2. Once promoted it COULD go into fremantle and fremantle-1.2. 3) Application uses API which is introduced in later SDK. This will be built with PR1.1 SDK and fail. It will be rebuilt with PR1.2 SDK, succeed and go into Extras-devel. Can be promoted to Extras-testing and tested by testers using the most recent release. Once promoted it will go into fremantle-1.2. 6) Case-by-case basis. Developer complains: add a temporary exception to autobuilder to build $APPNAME with PR1.0/1.1 SDK, but goes into the shared extras-devel as now. Thanks in advance, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
On Wed, 7 Apr 2010 14:55:51 +0100 Andrew Flegg and...@bleb.org wrote: Hi, The number of issues being caused by the deployment of PR1.2 SDK to the fremantle autobuilder is becoming critical. It doesn't even matter when PR1.2 is released, as we should have a way of dealing with this in-place for the next upgrade. BACKGROUND ~~ After the PR1.2 SDK was released, Niels deployed it to the autobuilder; enacting a plan which was discussed on this list. This has caused problems with libhildon dependencies, but the problems aren't just limited to that library: http://lists.maemo.org/pipermail/maemo-developers/2010-March/025668.html Both Niels and the Council believe we should do something to assist. WHAT WE SHOULD DO ~ We *need* to do something, both to improve the situation in -devel and -testing today, and test an approach for the next upgrade. The main requirements here are, I think: * It's not an excessive amount of work * It's a viable long term strategy * The QA process doesn't get broken Thoughts and comments from developers, or anyone else with a idea, will be much appreciated. OPTIONS ~~~ 1) Deploy SDKs as they are released; treat -devel and -testing as trunk. This is what we have now, I think we can say it doesn't work if there's going to be more than a few days between SDK release and device upgrade. Since Nokia doesn't pre-announce release dates, and last minute bugs could cause problems; I think we can rule this one out. 2) Revert the builder. This is basically a step backwards. Changing the builder config is easy. Cleaning up -devel and rebuilding the affected packages is quite some work as we don't have any scripts for that made yet. 3) Hack the SDK, create some kind of hybrid. This'd be bad enough if limited to just libhildon, but isn't viable and WILL cause unforeseen problems. Veto :-) 4) Create separate repos, build queues for pre- and post-1.2. Similar to what's been done for Extras proper. Creating the repos will be about a day work, but the part that sits on top of that (management scripts, Packages interface, QA queue) will probably take a week of work. There are hard issues around QA here. 5) Try building in each SDK in turn. My suggestion; when someone uploads to fremantle auto-builder it attempts to build the package against the PR1.1 SDK. If it succeeds, it goes into Extras-devel. If it fails to build, it gets built with the PR1.2 SDK, and so on. For an app with compile time symbol resolution (e.g. C/C++), this'd handle both cases quite nicely. Python apps would have to depend on the specific versions of bindings which gave them the features they wanted - again, not too much of a problem. At extras(-stable) promotion time you could even decide, based on actual binary package dependencies, whether to put in fremantle-1.2 or both fremantle-1.2 fremantle extras repos. This would fix another common complain, what if I don't upgrade for a few weeks. Larger packages could be prevent from being tried to built twice by stating a forced build dependency on a PR1.2 version of any system package. Some software won't install from -devel and -testing as it does now, but that will be reduced to the set of software which is actually using features that are unavailable. A HAM patch could grey out applications which were uninstallable, or show some other indication. This is, effectively, reinventing the more intelligent dpkg-shlibdeps: http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps However, it deals with the following three circumstances: 1) Application uses API which has changed in later SDK. This will be built with PR1.1 SDK, succeeds and goes into Extras-devel. Can be promoted to Extras-testing but there's no clear way for a tester to know it won't work if their device is running the latest OS. 2) Application uses API which is unchanged in later SDK. This will be built with PR1.1 SDK, succeeds and goes into Extras-devel. Can be promoted to Extras-testing and tested on any device with PR1.1 or PR1.2. Once promoted it COULD go into fremantle and fremantle-1.2. 3) Application uses API which is introduced in later SDK. This will be built with PR1.1 SDK and fail. It will be rebuilt with PR1.2 SDK, succeed and go into Extras-devel. Can be promoted to Extras-testing and tested by testers using the most recent release. Once promoted it will go into fremantle-1.2. 6) Case-by-case basis. Developer complains: add a temporary exception to autobuilder to build $APPNAME with PR1.0/1.1 SDK, but goes into the shared extras-devel as now. Thanks in advance, Andrew Hello all, Pardon the intrusion from somebody who doesn't usually post on this list, but I think I might have some input. It seems to me that the real problem is actually the difficulty in
Re: PR1.2 SDK for Extras-devel: how to solve?
On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs n...@landwarsin.asia wrote: It seems to me that the real problem is actually the difficulty in implementing #4 above. If there were magically separate infrastructure for each incompatible release, there would be no issue - a developer uploads their package to each repository for which it builds (preferably through a list of checkboxes in the web interface), and a user selects one or more package sources that match the preinstalled software on their device. No problems, mate. True; however what about the QA process? The UI at http://maemo.org/packages/ is getting better, but it's also getting more familiar. How do we: a) not confuse ad-hoc testers b) ensure that versions in all repos get tested? One suggestion would be to promote all versions simultaneously, but there are obvious drawbacks with that! So the real issue is that creating a new branch requires a nontrivial amount of work. This is a computerized system; computers excel at automation. Why not spend the one-off time to allow for near-instant creation of a new branch? Once that's done, future releases will just consist of oh, I should create a new repository for this release. Let me run that script again with a new name and then upload the new SDK release to it. Indeed. Have I missed some important consideration? I think the issues aren't technical (although streamlining the repo creation is obviously part of it), but more procedural. I could be wrong. I wonder what the testing squad think (I'll poke VDVsx). Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
On Wed, 7 Apr 2010 15:41:48 +0100 Andrew Flegg and...@bleb.org wrote: On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs n...@landwarsin.asia wrote: It seems to me that the real problem is actually the difficulty in implementing #4 above. If there were magically separate infrastructure for each incompatible release, there would be no issue - a developer uploads their package to each repository for which it builds (preferably through a list of checkboxes in the web interface), and a user selects one or more package sources that match the preinstalled software on their device. No problems, mate. True; however what about the QA process? The UI at http://maemo.org/packages/ is getting better, but it's also getting more familiar. How do we: a) not confuse ad-hoc testers b) ensure that versions in all repos get tested? Each QA tester (probably) only uses one device for testing. If this is true, this means that applications get tested on the platform the QA testers are on. This doesn't guarantee coverage for any particular application/SDK combination, but it does mean that things that are important to (the QA) users will get more throughly used. I'm not convinced that's a bad thing. As long as the QA users make both positive and negative bug reports, I think this will probably work out while not totally satisfying (b) above. (a) is OK because each QA tester just uses the repos matching their device, and upgrades whenever the next level meets their own personal comfort level with the bleeding-edge-to-stability spectrum. One suggestion would be to promote all versions simultaneously, but there are obvious drawbacks with that! I wouldn't do that. I'd promote things when you have enough negative bug reports about the particular version. Some things will never get promoted if nobody loves them. Tough cookies - if nobody cares enough to test the package as it is, does it really need promotion? So the real issue is that creating a new branch requires a nontrivial amount of work. This is a computerized system; computers excel at automation. Why not spend the one-off time to allow for near-instant creation of a new branch? Once that's done, future releases will just consist of oh, I should create a new repository for this release. Let me run that script again with a new name and then upload the new SDK release to it. Indeed. Have I missed some important consideration? I think the issues aren't technical (although streamlining the repo creation is obviously part of it), but more procedural. I could be wrong. I wonder what the testing squad think (I'll poke VDVsx). I can't really say anything about whatever internal rules would restrict this from working. I obviously have an interest in the process working better than it has, so I felt like commenting. It would be a shame if it were more than a technical problem. It's easier to argue for longer about qualitative things. Cheers, Andrew Bryan Jacobs signature.asc Description: PGP signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
Andrew Flegg wrote: Hi, The number of issues being caused by the deployment of PR1.2 SDK to the fremantle autobuilder is becoming critical. It doesn't even matter when PR1.2 is released, as we should have a way of dealing with this in-place for the next upgrade. I've copied the contents of your message to the wiki: http://wiki.maemo.org/Task:PR1.2_autobuilder I have also added some stuff about dpkg-shlibdeps that we have been discussing on IRC a few minutes ago. Feel free to add any extra options or cons of existing ones. -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
On Wed, April 7, 2010 16:41, Andrew Flegg wrote: On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs n...@landwarsin.asia wrote: It seems to me that the real problem is actually the difficulty in implementing #4 above. If there were magically separate infrastructure for each incompatible release, there would be no issue - a developer uploads their package to each repository for which it builds (preferably through a list of checkboxes in the web interface), and a user selects one or more package sources that match the preinstalled software on their device. No problems, mate. True; however what about the QA process? The UI at http://maemo.org/packages/ is getting better, but it's also getting more familiar. How do we: a) not confuse ad-hoc testers b) ensure that versions in all repos get tested? This is a non-trivial issue. Testing against all repos is not going to work, imagine what happens when we have PR1.2+1 etc. One suggestion would be to promote all versions simultaneously, but there are obvious drawbacks with that! That would make the most recent repo the best supported and tested repo. Older repos might or might not work. But then again, that is what -devel is now too. So the real issue is that creating a new branch requires a nontrivial amount of work. This is a computerized system; computers excel at automation. Why not spend the one-off time to allow for near-instant creation of a new branch? Once that's done, future releases will just consist of oh, I should create a new repository for this release. Let me run that script again with a new name and then upload the new SDK release to it. Indeed. Have I missed some important consideration? I think the issues aren't technical (although streamlining the repo creation is obviously part of it), but more procedural. I could be wrong. There is also the technical issue that after SSU you would need to change your catalog settings in your device manually for -devel and -testing. Getting that changed in AM is probably not going to happen. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
I would like to throw in my 2 pence as well for what its worth. The idea is to give a choice to the developer to choose which SDK the autobuilder needs to use and to which repo the app needs to go to. Providing an option in the debian control file to build against the user specified SDK since the developer knows what SDK he/she uses. e.g: Xsbc-sdk : PR1.2 Also, we can maintain n and n-1 version of the repository at any time to limit the number of maemo OS trunks. does it look feasible ? - Original Message - From: Andrew Flegg Sent: 04/07/10 03:41 PM To: Bryan Jacobs Subject: Re: PR1.2 SDK for Extras-devel: how to solve? On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs n...@landwarsin.asia wrote: It seems to me that the real problem is actually the difficulty in implementing #4 above. If there were magically separate infrastructure for each incompatible release, there would be no issue - a developer uploads their package to each repository for which it builds (preferably through a list of checkboxes in the web interface), and a user selects one or more package sources that match the preinstalled software on their device. No problems, mate. True; however what about the QA process? The UI at http://maemo.org/packages/ is getting better, but it's also getting more familiar. How do we: a) not confuse ad-hoc testers b) ensure that versions in all repos get tested? One suggestion would be to promote all versions simultaneously, but there are obvious drawbacks with that! So the real issue is that creating a new branch requires a nontrivial amount of work. This is a computerized system; computers excel at automation. Why not spend the one-off time to allow for near-instant creation of a new branch? Once that's done, future releases will just consist of oh, I should create a new repository for this release. Let me run that script again with a new name and then upload the new SDK release to it. Indeed. Have I missed some important consideration? I think the issues aren't technical (although streamlining the repo creation is obviously part of it), but more procedural. I could be wrong. I wonder what the testing squad think (I'll poke VDVsx). Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ 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
Re: PR1.2 SDK for Extras-devel: how to solve?
2010/4/7 Ram Kurvakat rkma...@gmx.com: The idea is to give a choice to the developer to choose which SDK the autobuilder needs to use and to which repo the app needs to go to. Providing an option in the debian control file to build against the user specified SDK since the developer knows what SDK he/she uses. e.g: Xsbc-sdk : PR1.2 Another Maemo-specific control field? No thanks :) Just create two repositories. It worked fine for Chinook and Diablo, and developers uploaded the same source package to Chinook and Diablo without problems until the Chinook autobuilder was closed down. The situation with pre-PR1.2 and PR1.2 is similar to Chinook and Diablo. We can think of PR1.2 as Maemo 5.1 the same way Diablo has been Maemo 4.1. As for testing/QA: Testers will simply use the repository for which they have got firmware on their devices. Which is why I support the idea of community firmware testing (which would allow both testers and developers to test apps on the real devices with the real firmware). Do you really want people to test apps in the SDK and pretend that they will work the same way on a real device? Thomas ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
On Wednesday 07 April 2010 16:54:28 Niels Breet wrote: On Wed, April 7, 2010 16:41, Andrew Flegg wrote: On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs n...@landwarsin.asia wrote: It seems to me that the real problem is actually the difficulty in implementing #4 above. If there were magically separate infrastructure for each incompatible release, there would be no issue - a developer uploads their package to each repository for which it builds (preferably through a list of checkboxes in the web interface), and a user selects one or more package sources that match the preinstalled software on their device. No problems, mate. True; however what about the QA process? The UI at http://maemo.org/packages/ is getting better, but it's also getting more familiar. How do we: a) not confuse ad-hoc testers b) ensure that versions in all repos get tested? This is a non-trivial issue. Testing against all repos is not going to work, imagine what happens when we have PR1.2+1 etc. I agree. There is little point in having repositories for old versions if nothing can ever get promoted into them because there are very few testers left. Unless they are really intended just to be archives: they work while the new version is being introduced (like where we are at at the moment with PR1.2) but once the new version has been out a few weeks, they just drop into archive mode with no promotions, just an archive of software for the old version. One suggestion would be to promote all versions simultaneously, but there are obvious drawbacks with that! That would make the most recent repo the best supported and tested repo. Older repos might or might not work. But then again, that is what -devel is now too. Actually I would make the process make all versions eligible for promotion simultaneously -- once the latest version is tested the developer can promote the other versions without QA when they wish but they can choose to do some more testing themselves if they wish. In an earlier discussion I had proposed another alternative: have a single repository but multiple autobuilders feeding it. I could submit to either the PR1.1 or PR1.2 autobuilder but the output would go into a single place. This seems more efficient than the build with PR1.1 and if that fails try PR1.2 option but otherwise quite similar. The only problem I have noticed so far with that would come when you introduced a new version which made use of some PR1.2 feature, and hence was built with PR1.2. At that time, the PR1.1 version would no longer be installable (as it has a lower version number and is in the same repository). But for cases like this, where PR1.2 is expected to be fairly quickly adopted once it is eventually released, this would probably work well enough. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
On Wed, 7 Apr 2010 21:27:30 +0100 Graham Cobb g+...@cobb.uk.net wrote: On Wednesday 07 April 2010 16:54:28 Niels Breet wrote: On Wed, April 7, 2010 16:41, Andrew Flegg wrote: On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs n...@landwarsin.asia wrote: It seems to me that the real problem is actually the difficulty in implementing #4 above. If there were magically separate infrastructure for each incompatible release, there would be no issue - a developer uploads their package to each repository for which it builds (preferably through a list of checkboxes in the web interface), and a user selects one or more package sources that match the preinstalled software on their device. No problems, mate. True; however what about the QA process? The UI at http://maemo.org/packages/ is getting better, but it's also getting more familiar. How do we: a) not confuse ad-hoc testers b) ensure that versions in all repos get tested? This is a non-trivial issue. Testing against all repos is not going to work, imagine what happens when we have PR1.2+1 etc. I agree. There is little point in having repositories for old versions if nothing can ever get promoted into them because there are very few testers left. Unless they are really intended just to be archives: they work while the new version is being introduced (like where we are at at the moment with PR1.2) but once the new version has been out a few weeks, they just drop into archive mode with no promotions, just an archive of software for the old version. You want to keep the repositories for exactly that reason. People can keep using their devices with no disruption of service. I, at least, feel that having the latest version of an application is secondary to avoiding a backwards leap in functionality. One suggestion would be to promote all versions simultaneously, but there are obvious drawbacks with that! That would make the most recent repo the best supported and tested repo. Older repos might or might not work. But then again, that is what -devel is now too. Actually I would make the process make all versions eligible for promotion simultaneously -- once the latest version is tested the developer can promote the other versions without QA when they wish but they can choose to do some more testing themselves if they wish. That sounds decent to me. And it would help keep old/extras as up-to-date as new/extras. In an earlier discussion I had proposed another alternative: have a single repository but multiple autobuilders feeding it. I could submit to either the PR1.1 or PR1.2 autobuilder but the output would go into a single place. This seems more efficient than the build with PR1.1 and if that fails try PR1.2 option but otherwise quite similar. The only problem I have noticed so far with that would come when you introduced a new version which made use of some PR1.2 feature, and hence was built with PR1.2. At that time, the PR1.1 version would no longer be installable (as it has a lower version number and is in the same repository). But for cases like this, where PR1.2 is expected to be fairly quickly adopted once it is eventually released, this would probably work well enough. This is the only solution proposed so far which I would reject out of hand. It's what we've got right now, more or less. As a developer, this is fine - I can use PR1.2 packages. As a user, this is a nightmare. My applications disappear forever for reasons that are unclear to me. When I contact a developer, they say wait for the PR1.2 release to come out. When I ask Nokia, they say We do not discuss release dates for future firmware updates. It's better than the current situation in that packages not using 1.2 functionality aren't broken, but it's still not optimal and I feel it should be avoided at all costs. Remember, you also break packages DEPENDING on the ones using 1.2 functionality. The disruption could be very large if, say, Nokia were to update glibc. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers signature.asc Description: PGP signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
