On 6 January 2016 at 02:30, Jonathan Lebon <jle...@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 | ncogh...@gmail.com | Brisbane, Australia
