Bug 2162

The image types are not related to the specific machine.

We can set "ext3" to "qemux86".
We also can set "ext3" to "qemuarm".

Can you explain more?

Sure. 

Although there are image types that are relevant for more than one machine (like in your example of ext3 applying to both qemux86 and qemuarm), there are other image types that do not apply to certain machines (e.g. a live image cannot be created for any of the qemu machines). This is what the Settings design spec says on page 5:

"It appears to be some relationship between machines and image types, i.e. some image types do not make sense when applied to certain machines. For example, no live image will be generated for a qemu machine.
What this means for the interface is that image types must be set for each different machine listed within the 'Select a machine' combo box in the 'Image configuration' screen. Setting of image types takes place in the 'Image types' tab of the 'Settings' dialogue. Each machine is represented by a vertical tab. Each image type is represented by a checkbox. For each machine, only "sensible" image types will be listed (e.g. the 'live' checkbox will not display for the qemu machines)."

What I am trying to avoid with this design is a situation people can create nonsensical combinations of machines and input types, e.g. create a live image for a virtual machine.

Hope this makes sense.

Cheers

Belen

(In reply to comment #2)
> Sure. 
> 
> Although there are image types that are relevant for more than one machine
> (like in your example of ext3 applying to both qemux86 and qemuarm), there are
> other image types that do not apply to certain machines (e.g. a live image
> cannot be created for any of the qemu machines). This is what the Settings
> design spec says on page 5:
> 
> "It appears to be some relationship between machines and image types, i.e. some
> image types do not make sense when applied to certain machines. For example, no
> live image will be generated for a qemu machine.

Well, I think generating live format image is also useful for customers. Let me take a real example, we ever generated a qemux86 hddimg/iso minimal image for one of my colleague in Xen Virtualization team, since Xen could only accept the hddimg format to boot the guest. Therefore I think we could not strict too much for user's selection in image types.

I was working on the assumption it didn't make sense to create hddimg/iso for qemu machines. If this is not the case, we are back to the drawing board. 

Is your example an edge case or advanced use case, like that one we discussed about using qemu with FRI2 images?

Shane, can we get this bug going?

Created attachment 556 [details]
Settings dialog - Image types tab

The Settings dialog needs some review and discussion. Maybe we can start with the first tab: the 'Image types' one. I've attached a suggestion for it, following some conversations with Dexuan. 

Let me know what you think.

Belen

Give to Valentin for him to start with Hob.

Created attachment 619 [details]
Settings dialog - work in progress

The design is not finished yet, but I thought I'd share what I've done so far. Please let me know if you have any questions or you see any problems with the design so far. 

Belen

moving to M3, blocked by design.

Created attachment 626 [details]
Settings dialog design

Hi all,

I think I am done with this. If you find any gaps, anything I have not covered or have any questions during implementation, just let me know.

Cheers

Belen

I've sent Valentin's changes to bitbake-devel. Apparently though, his changes implement an older design (not the one in "Settings dialog design" attached to this bug). Please let me know if this is OK; if not, I'll modify his patch.

Thanks! Could you post a comment when the patch is merged to master, so that I can have a look at it?

Also, do you know by any chance which design did Valentin follow?

Belen



(In reply to comment #11)
> I've sent Valentin's changes to bitbake-devel. Apparently though, his
> changes implement an older design (not the one in "Settings dialog design"
> attached to this bug). Please let me know if this is OK; if not, I'll modify
> his patch.

Created attachment 757 [details]
HOB after Valentin's patches

(In reply to comment #12)
> Thanks! Could you post a comment when the patch is merged to master, so that
> I can have a look at it?
> 
> Also, do you know by any chance which design did Valentin follow?
> 
> Belen
> 
> 
> 
> (In reply to comment #11)
> > I've sent Valentin's changes to bitbake-devel. Apparently though, his
> > changes implement an older design (not the one in "Settings dialog design"
> > attached to this bug). Please let me know if this is OK; if not, I'll modify
> > his patch.

HI Belen,

I added an attachment ("HOB after Valentin's patches") which should give you an idea about the new look. I don't know what design he followed, but it's different from your "Settings dialog design" (although it _could_ be different only at the GUI level, not functionality-wise).

Changing this to NEEDINFO until we get an answer from Belen.

Created attachment 780 [details]
Settings dialog design

Some last minute changes made to the SSTATE_MIRROR field. Check pages 15 and 16, and bug 2893 for more details.

Thanks, Belen. I'll work on the changes.

Belen, please also see the comments that I added to bug #2893, I believe they are relevant for this bug too.

They very much are. Before making any changes to the Settings, let's clarify the SSTATE_MIRRORS thing in #2893.

Belen

(In reply to comment #18)
> Belen, please also see the comments that I added to bug #2893, I believe
> they are relevant for this bug too.

Created attachment 810 [details]
Settings dialog design

Hi Bogdan: as we agreed this morning, I've updated the design document to include all the changes to the Settings brought by bugs 3026 and 2893. When the design work refers to another bug, I've indicated that within the document. 

I am sure I am still missing things, so if you find any gaps or have any questions, please let me know.

Belen

I am including Belen's observations here so other people will know what I'm working on in order to close this bug:

=======================================================

I've had a quick peek to the fixes for 2162. I think we are 75% there, but there are a few things to do in order to match the design. There they go:

  *   Some of the image descriptions are cut (see screenshot attached). They are: core-image-lsb, core-image-lsb-sdk, core-image-minimal-mtdutils and core-image-sato. Is there any chance we can increase the width of the description paragraph a bit? Or play with the window size somehow?
  *   We should try to organise the content of the tabs using headings as shown in the design spec. For example, in the Settings dialog, in the Build Environment tab, the controls are supposed to be organised into 2 headings: "Parallel threads" and "Cache directories and mirrors".
  *   We should try to match the labels to the design spec. For example, "BB number threads" should be "BitBake parallel threads". The labels in the design spec are more like natural language, and less like the variable names.
  *   I have tried my best to get rid of the "Others" tab, but I see it is still there and lots of people are telling me to leave it. So, let's leave it ;) But could we move it to the Settings dialog, though? Right now is in the "Advanced configuration" dialog, but probably makes less sense there.
  *   The most work left to do is probably in the "Image types" tab of the "Advanced configuration" dialog. The design document explains that tab in pages 5 and 6. Just a quick overview: the 'live' image option should be split into hddimg and iso, the 'Image types' listed should be the ones compatible with my selected machine and distro (right now I still can see image types like 'vmdk' when I have selected Beagleboard as my machine), 'Image types' should be sorted alphabetically (A to Z, from top to bottom, then left to right as shown in page 5 of the design document), and I should never be able to deselect all image types and click 'Save' (you currently can do that). Less importantly, the 'info' icon is a bit too far from the "Select image types" heading: we should probably move it to the left a bit.

The design document I mention is available here: https://bugzilla.yoctoproject.org/attachment.cgi?id=626

=======================================================

Hi Bogdan and Belen,

At this stage of 1.3 and based on Belen's notes can we draw a line between this 2 items for 1.3:

 *   We should try to match the labels to the design spec. For example, "BB number threads" should be "BitBake parallel threads". The labels in the design spec are more like natural language, and less like the variable names.

==============================================================
  *   I have tried my best to get rid of the "Others" tab, but I see it is still there and lots of people are telling me to leave it. So, let's leave it ;) But could we move it to the Settings dialog, though? Right now is in the "Advanced configuration" dialog, but probably makes less sense there

For the rest we can move them for 1.4/1.3.1, this way, also gives Belen more time to work through her design process.

I am happy with that. 

Do you need me to file bugs for the changes in the 'Others' tab and the image types?



(In reply to comment #22)
> Hi Bogdan and Belen,
> 
> At this stage of 1.3 and based on Belen's notes can we draw a line between
> this 2 items for 1.3:
> 
>  *   We should try to match the labels to the design spec. For example, "BB
> number threads" should be "BitBake parallel threads". The labels in the
> design spec are more like natural language, and less like the variable names.
> 
> ==============================================================
>   *   I have tried my best to get rid of the "Others" tab, but I see it is
> still there and lots of people are telling me to leave it. So, let's leave
> it ;) But could we move it to the Settings dialog, though? Right now is in
> the "Advanced configuration" dialog, but probably makes less sense there
> 
> For the rest we can move them for 1.4/1.3.1, this way, also gives Belen more
> time to work through her design process.

Hi Belen,

Yes please file separate bugs for the remaining 2 issues to track for 1.4/1.3.1, and Bogdan can close this bug.

THanks,
Jessica

Actually I already implement most of the requirements from Belen, with two exceptions:

"Just a quick overview: the 'live' image option should be split into hddimg and iso, the 'Image types' listed should be the ones compatible with my selected machine and distro (right now I still can see image types like 'vmdk' when I have selected Beagleboard as my machine)"

I believe these too are actually bitbake issues, not Hob issues, thus I propose to make them into other bugs.

I'll file a new bug about the image types, then.

(In reply to comment #25)
> Actually I already implement most of the requirements from Belen, with two
> exceptions:
> 
> "Just a quick overview: the 'live' image option should be split into hddimg
> and iso, the 'Image types' listed should be the ones compatible with my
> selected machine and distro (right now I still can see image types like
> 'vmdk' when I have selected Beagleboard as my machine)"
> 
> I believe these too are actually bitbake issues, not Hob issues, thus I
> propose to make them into other bugs.

I've filed bug 3197 for the image types work and 3198 for bringing back and redesigning the 'Others' tab.

In reply to comment #26)
> I'll file a new bug about the image types, then.
> 
> (In reply to comment #25)
> > Actually I already implement most of the requirements from Belen, with two
> > exceptions:
> > 
> > "Just a quick overview: the 'live' image option should be split into hddimg
> > and iso, the 'Image types' listed should be the ones compatible with my
> > selected machine and distro (right now I still can see image types like
> > 'vmdk' when I have selected Beagleboard as my machine)"
> > 
> > I believe these too are actually bitbake issues, not Hob issues, thus I
> > propose to make them into other bugs.

Hi Bogdan,

I had a quick look at the 2162 fixes: it's looking absolutely brilliant. I can no longer save my image types with nothing selected! :)

Only 2 tiny things I've spotted:

1. Settings dialog > Build environment tab: because we have created a separate tab for shared state, the second heading should now say "Downloaded source code" instead of "Cache directory and mirror". The label should say "Downloads directory" instead of "Download directory"

2. Advanced configuration dialog > Image types tab: in the 'Distro' combo box, could we change the value 'defaultsetup' to just 'Default'. It sounds a bit more human

3. Advanced configuration dialog > Image types tab: something fun is going on with the Package format controls. The Root file system format is set to rpm by default. If you change it to something else (e.g. ipk), the info bubble changes position. 

And that's everything as far as I can see. Then we can close the bug. 

Brilliant work!

Great job, Bogdan and Belen, for making the changes and ensuring the changes are following the design!

Hi Belen,

(In reply to comment #28)
> Hi Bogdan,
> 
> I had a quick look at the 2162 fixes: it's looking absolutely brilliant. I
> can no longer save my image types with nothing selected! :)
> 
> Only 2 tiny things I've spotted:
> 
> 1. Settings dialog > Build environment tab: because we have created a
> separate tab for shared state, the second heading should now say "Downloaded
> source code" instead of "Cache directory and mirror". The label should say
> "Downloads directory" instead of "Download directory"
> 
> 2. Advanced configuration dialog > Image types tab: in the 'Distro' combo
> box, could we change the value 'defaultsetup' to just 'Default'. It sounds a
> bit more human
> 
> 3. Advanced configuration dialog > Image types tab: something fun is going
> on with the Package format controls. The Root file system format is set to
> rpm by default. If you change it to something else (e.g. ipk), the info
> bubble changes position. 
> 
> And that's everything as far as I can see. Then we can close the bug. 

I have nothing against implementing these changes (in fact I'll start working right on them), but may I suggest that in the future we should resort to opening new bugs instead? It seems to be that this bug (as origininally filed) is fixed at this point, so we should be able to close it. If we keep on adding new requirements to the same bug, I'm afraid we won't close it anytime soon :) As an unfortunate side effect, this also makes the git history pretty hard to follow (seeing so many references to bug 2162 in the git logs is certainly confusing).

Thanks,
Bogdan

> 
> Brilliant work!

Hi Bogdan,

I am going to have to respectfully disagree ;) Everything I've listed is part of the design document but didn't make it into the fix (they are not new requirements). I am happy to open new bugs (just let me know), but I think the problem is in the way we are handling the bug cycle.

This back and forth is completely normal when building GUIs. Design documents are often missing or overlooking stuff, designs have dependencies in other bugs and are thus subject to change, and it is natural for the implementation not to fully match the design on the first go. It's just a question on how we deal with it. Since the requirements are stated in the design document and the bug is filed to implement that design document, I think the back and forth should be handled within the same bug, since we are not dealing with new requirements. I do agree though that creating multiple patches messes up the git history.

In my opinion, I should probably review the patches before they are merged to master, not afterwards. That way, we could work in a single patch iteratively and we'd avoid merging patches where the implementation does not match the design. 

Having written all that, if you want me to file new bugs, just let me know.

Belen


(In reply to comment #30)
> Hi Belen,
> 
> (In reply to comment #28)
> > Hi Bogdan,
> > 
> > I had a quick look at the 2162 fixes: it's looking absolutely brilliant. I
> > can no longer save my image types with nothing selected! :)
> > 
> > Only 2 tiny things I've spotted:
> > 
> > 1. Settings dialog > Build environment tab: because we have created a
> > separate tab for shared state, the second heading should now say "Downloaded
> > source code" instead of "Cache directory and mirror". The label should say
> > "Downloads directory" instead of "Download directory"
> > 
> > 2. Advanced configuration dialog > Image types tab: in the 'Distro' combo
> > box, could we change the value 'defaultsetup' to just 'Default'. It sounds a
> > bit more human
> > 
> > 3. Advanced configuration dialog > Image types tab: something fun is going
> > on with the Package format controls. The Root file system format is set to
> > rpm by default. If you change it to something else (e.g. ipk), the info
> > bubble changes position. 
> > 
> > And that's everything as far as I can see. Then we can close the bug. 
> 
> I have nothing against implementing these changes (in fact I'll start
> working right on them), but may I suggest that in the future we should
> resort to opening new bugs instead? It seems to be that this bug (as
> origininally filed) is fixed at this point, so we should be able to close
> it. If we keep on adding new requirements to the same bug, I'm afraid we
> won't close it anytime soon :) As an unfortunate side effect, this also
> makes the git history pretty hard to follow (seeing so many references to
> bug 2162 in the git logs is certainly confusing).
> 
> Thanks,
> Bogdan
> 
> > 
> > Brilliant work!

Thanks. I've sent another patch for these issues.

And so, having re-re-refixed this bug, I can finally close it and open that bottle of scotch that I saved for this special ocassion. I don't really drink scotch, but I'll open the bottle anyway.

Scotch is good ...