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 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. 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". Have I missed some important consideration? Bryan Jacobs
signature.asc
Description: PGP signature
_______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
