Re: [atomic-devel] Fedora 23 Cloud Atomic Developer Mode Preview

[Nick Coghlan <ncoghlan gmail com>]

On 6 January 2016 at 02:30, Jonathan Lebon <jlebon redhat com> wrote:
>> Is there a specific reason it has to be a boot option in the standard
>> image rather than offering a separate developer mode image?
>
> I think the primary reason is simplicity, and not having to change
> the release pipeline much. Also knowing that you're playing with
> exactly the same bits as you would in the "real" case (i.e. when
> not in devmode).
>
> I guess it's to be discussed whether this is something worth
> trading for. My feeling right now is that 2s should be enough,
> coupled with a proper presentation of the image wherever devmode
> is advertised (e.g. an accompanying gif or even YouTube video
> of the process, which would also serve to showcase devmode in
> general).

I tend to think of this kind of problem in terms of:

1) Who bears the cognitive load and when?
2) Who bears the development load and when?

The "times" that are relevant in terms of the "when" question:

* image design time
* image build time
* image download time
* image boot time

With a boot menu option, the answers are:

* developers have a development and cognitive load at image design
time (designing the Developer Mode and adding the boot menu option)
* QA have a development load at image design time (since they need to
boot a non-default option for testing purposes)
* QA potentially have a cognitive load at image build time (depending
on how they go in automating testing with the non-default boot option)
* end users have a cognitive load at image boot time (choosing which
mode to boot, with no way to change the default boot option without
making a new image)

With a separate image:

* developers have a development and cognitive load at image design
time (designing the Developer Mode)
* release engineering have a development load at image design time
(updating the toolchain to produce a separate image for interactive
use, specifying the additional images)
* end users have a cognitive load at image download time (choosing
which image to download)
* cognitive load can be minimised at image boot time, since dev
environments can be configured to use a developer mode image, while
CI, QA, staging, and production environments don't

The pay-off of the additional upfront design time on figuring out how
to publish a second image without confusing end users at download time
is that folks only need to make the "Developer Mode or Production?"
decision once (when choosing the image to use for a given use case),
rather than having to make an interactive decision. This should also
simplify automated testing, since a lot of tests should be re-usable
between the two images.

Most importantly, with a separate image, we can change our assumptions
about usage scenarios: "Developer Mode" can assume there might be a
human watching the instance boot that wants to fiddle with the
process, and set things like the grub menu timeout accordingly, while
the production image can optimise for speed of starting ephemeral
instances.

If folks want to be confident that they understand the differences
between the "Developer Mode" image and the "Production" image, then
that sounds like a job for both an easy-to-use image-diffing utility,
as well as for a "Compare Products" capability in the Product
Definition Centre.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan gmail com   |   Brisbane, Australia