ubuntu-phone team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

On Fri, 2014-05-02 at 09:20 -0400, Chris Wayne wrote:
> On Thu, May 1, 2014 at 9:16 PM, Ted Gould <ted@xxxxxxxxxx> wrote:
> 
>         On Thu, 2014-05-01 at 18:28 -0400, Chris Wayne wrote: 
>         
>         > On Thu, May 1, 2014 at 5:16 PM, Ted Gould <ted@xxxxxxxxxx>
>         > wrote:
>         > 
>         >         All in all, I'm not against Upstart having the
>         >         feature, but it's a big scary stick and basically an
>         >         unsupportable interface. If we change the signals or
>         >         the job names in an image update, suddenly that
>         >         update breaks that customization tarball and device,
>         >         potentially in a hard to fix manner. 
>         > 
>         > That's why we have the -customized images tested by CI
>         > daily :)  Any update to the image that breaks customization
>         > would be found (and fixed) before an image would be
>         > promoted.  I don't see how having custom upstart jobs makes
>         > it any more likely to fail than having upstart jobs in the
>         > rootfs? 
>         
>         Heh, we're not going to have every customization for every
>         device on every carrier. It'd be nice, but we probably won't
>         even have an environment that could test things like
>         customized location providers (likely to require specific cell
>         towers for instance). What's important is that we keep the
>         things that can be customized as a stable API, if we can't
>         guarantee that, we shouldn't allow it be customized.
>         

> No, but in our base customization image (savilerow) we have every
> supported customization, exactly so that we can test the customization
> API, and can ensure that all types of customizations work.  Again, the
> location-service was a quick example that I made up (and is clearly
> not the greatest example to have used!).  I still don't quite
> understand the claim that having custom upstart jobs makes it any less
> stable than upstart jobs that live in the rootfs.


Because we test the rootfs differently than we test each customization
tarball. We also have processes in place to ensure that the people who
are editing those Upstart jobs know a fair amount about how the system
works, certainly more than someone at a carrier who's doing their first
Ubuntu integration. As a simple example you could override the network
job to have a pre-start condition to stop it and replace it with a job
"network-mycarrier" then any job that depended on that would fail to
run. If we needed to support that customization then we'd have to add
"start on network or network-mycarrier", it forces support for bugs in
each customization tarball into the core os.

>         > All in all, we think this is something that a carrier/oem
>         > would want/need to customize, and it'd be much easier to add
>         > now, than to scramble later 
>         
>         So the more we talk about this, the more I think it's a bad
>         idea. I'm now of the opinion that we shouldn't provide this to
>         customization tarballs. If nothing else, because we don't
>         expect to support Upstart as long as we expect the
>         customization tarballs to work.
> We expect the first phones that we ship to have Upstart, therefore
> it's going to be around at least long enough that we will need this. 

I haven't seen a definitive decision on that, but even so, we expect the
customization tarballs to work for a while beyond the first release. We
expect to upgrade the rootfs continually using the same customization.
It seems likely that we'll expect a customization tarball to work on
both an Upstart and a Systemd based rootfs.

I'd say "we will need this" is incorrect. Furthermore, I'd stipulate
that supporting it is hazardous to future upgradability. We need to
think of the customization tarballs more like a system level click
package where it provides configuration information using stable
interfaces that we're willing to support for an extended period of time.

Ted

Attachment: signature.asc
Description: This is a digitally signed message part