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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Reply via email to