review request for configure details page

review request for configure details page

[Reyna, David]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

Hi Belen and Alex,

I have the configuration page ready for review at:  "dreyna/configure-detail-view"

Implementation Notes:

* In the file list pop-up dialog, I truncate the variable's value to 200 characters max.

The reason is that I discovered for variables (like "BBINCLUDE") with very long values, the pop-up is in fact unable by design to scroll to the end, to show the file list. I think that 200 characters give the right idea, and the result looks consistent with the more normal pop-ups.

* I have the file filters working for each of the indicated categories.

I will note that in my examinations that there were a few file types that were not covered by the existing categories, and I wondered if you were ok that.

    poky/meta/classes/*
    poky/bitbake/lib/bb/*

* I have the filter for the descriptions.

I ended on filtering on the presence of a space character, because I could not find an appropriate alternate field lookup. I suppose I could try a regex test.

* I implemented the file list such the last file is the one shown.

I was however curious if it is absolutely the case that the foreign key select on the VariableHistory table is guaranteed to be in time order. I did manually examine the first 100 rows and found that indeed that the rows were in primary key sequential order, but that is not proof.

Thanks,
David



[-- Attachment #2: Type: text/html, Size: 2253 bytes --]

Re: review request for configure details page

[Reyna, David]

[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]

Hi again,

> "I have the filter for the descriptions, but is depends on the presence of a space character"

Ok, I was able to redo and push the filter using a regex, so that will allow the possibility of a description that has characters but no spaces.

    ('Show only variables with description', 'description__regex:.+'),

- David

From: toaster-bounces@yoctoproject.org [mailto:toaster-bounces@yoctoproject.org] On Behalf Of Reyna, David
Sent: Friday, February 14, 2014 1:20 AM
To: belen.barros.pena@intel.com; Damian, Alexandru (alexandru.damian@intel.com)
Cc: toaster@yoctoproject.org
Subject: [Toaster] review request for configure details page

Hi Belen and Alex,

I have the configuration page ready for review at:  "dreyna/configure-detail-view"

Implementation Notes:

* In the file list pop-up dialog, I truncate the variable's value to 200 characters max.

The reason is that I discovered for variables (like "BBINCLUDE") with very long values, the pop-up is in fact unable by design to scroll to the end, to show the file list. I think that 200 characters give the right idea, and the result looks consistent with the more normal pop-ups.

* I have the file filters working for each of the indicated categories.

I will note that in my examinations that there were a few file types that were not covered by the existing categories, and I wondered if you were ok that.

    poky/meta/classes/*
    poky/bitbake/lib/bb/*

* I have the filter for the descriptions.

I ended on filtering on the presence of a space character, because I could not find an appropriate alternate field lookup. I suppose I could try a regex test.

* I implemented the file list such the last file is the one shown.

I was however curious if it is absolutely the case that the foreign key select on the VariableHistory table is guaranteed to be in time order. I did manually examine the first 100 rows and found that indeed that the rows were in primary key sequential order, but that is not proof.

Thanks,
David



[-- Attachment #2: Type: text/html, Size: 10444 bytes --]

Re: review request for configure details page

[Barros Pena, Belen]

Thanks, David. Those file filters are really neat :)

I have reviewed this page. There are a few little things
implementation-related, and there are other (bigger) issues that are
design problems. 

The implementation first:

SUMMARY TAB

* The Summary values in the Build configuration section don't seem to be
coming in (for my Beagleboard build, I see machine 'atom-pc', which
doesn't seem right). That section should list:

** BitBake version (BB_VERSION)

** Build system (BUILD_SYS)

** Host distribution (NATIVELSBSTRING)

** Target system (TARGET_SYS)

** Machine (MACHINE)

** Distro (DISTRO)

** Distro version (DISTRO_VERSION)

** Tune features (TUNE_FEATURES)

** Target FPU (TARGET_FPU)

** Target(s), i.e. the name(s) of the image recipe(s) or recipe(s) you are
building (e.g. core-image-minimal). If more than one, please mark them up
within an unnumbered list (<ul>)

If any of the above variables has no value, we don't list the variable

* We should take out the blue icon next to the layer name

BITBAKE VARIABLES TAB

* The Description filter should be applied when you load this page

* The Value heading is not sortable

* But the Set in file heading should be sortable

* The path for the bitbake.conf file is not the full path (it only says
conf/bitbake.conf)

* In the filter modal dialogs, the headings and the "All" radio button
labels say "configvars" instead of "variables". This also happens in the
applied filter tooltip (in the "Show all" button) and in the placeholder
text in the search input field (which should say "Search BitBake
variables")

There are also some design problems with this page that I need to think
about:


* As it was designed, the modal dialog for the history should only exist
if the number of config files touching the variable is higher than one.
This causes a few issues:

** how do we show the operation and line number for the variables touched
by only one file?


** Search and filtering work across all entries, which means it might not
be obvious why you get certain results since they are hidden inside the
history modal dialog


* How do we deal with very long values (both in the table and in the
history modal dialogs)?

* The design specification says that the page h1 should not be manipulated
by search results: for pages with tabs, like this one, it says to display
a h2 right above the search field with the number of results returned by
the search query. Having said that, I am not particularly happy with that
design either. On the other hand, manipulating the h1 causes some weird
interactions in the page that could be confusing. This is the kind of
thing you need to test with users to actually find out. I am inclined to
leave it as is for the moment, and see how it goes. We can always refine
it in the next release cycle.


* What do we do with the B_* variables (in a core-image-minimal build you
get about 600 of those). We knew we were going to hit this problem at some
point, but I am not sure how we can exclude those entries within our
existing filtering patterns. The only easy solution seems to be removing
the B variable from documentation.conf, which means that neither B nor any
of the 600 B_* variables will show by default, since we apply the
Variables with description filter.

* I have been thinking about how we can keep the links to the full
variable descriptions in the Yocto Project manual. Right now, we do know
that an entry in the manual exists for each variable that has a
description, so it is safe to show the link. We also know their structure
should be:

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var- +
<variableName>

For example: 

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-ALL
OW_EMPTY

The question is: what's the best way to generate the URLs?


Sorry for the brain dump: I thought I'd share my pains with you all ;) I
will try and look into the design issues above as soon as possible. If you
have any suggestions for any of them, please let me know.

Belén


On 14/02/2014 10:26, "Reyna, David" <david.reyna@windriver.com> wrote:

>Hi again,
> 
>> ³I have the filter for the descriptions, but is depends on the presence
>>of a space character²
> 
>Ok, I was able to redo and push the filter using a regex, so that will
>allow the possibility of a description that has characters but no spaces.
> 
>    ('Show only variables with description', 'description__regex:.+'),
> 
>- David
> 
>From: toaster-bounces@yoctoproject.org
>[mailto:toaster-bounces@yoctoproject.org]
>On Behalf Of Reyna, David
>Sent: Friday, February 14, 2014 1:20 AM
>To: belen.barros.pena@intel.com; Damian, Alexandru
>(alexandru.damian@intel.com)
>Cc: toaster@yoctoproject.org
>Subject: [Toaster] review request for configure details page
>
>
> 
>Hi Belen and Alex,
>
> 
>
>I have the configuration page ready for review at:
>³dreyna/configure-detail-view²
>
> 
>
>Implementation Notes:
>
> 
>
>* In the file list pop-up dialog, I truncate the variable¹s value to 200
>characters max.
>
>
> 
>
>The reason is that I discovered for variables (like ³BBINCLUDE²) with
>very long values, the pop-up is in fact unable by design to scroll to the
>end, to show the file list.
> I think that 200 characters give the right idea, and the result looks
>consistent with the more normal pop-ups.
>
> 
>
>* I have the file filters working for each of the indicated categories.
>
>
> 
>
>I will note that in my examinations that there were a few file types that
>were not covered by the existing categories, and I wondered if you were
>ok that.
>
> 
>
>    poky/meta/classes/*
>
>    poky/bitbake/lib/bb/*
>
> 
>
>* I have the filter for the descriptions.
>
> 
>
>I ended on filtering on the presence of a space character, because I
>could not find an appropriate alternate field lookup. I suppose I could
>try a regex test.
>
> 
>
>* I implemented the file list such the last file is the one shown.
>
> 
>
>I was however curious if it is absolutely the case that the foreign key
>select on the VariableHistory table is guaranteed to be in time order. I
>did manually examine the
> first 100 rows and found that indeed that the rows were in primary key
>sequential order, but that is not proof.
>
> 
>
>Thanks,
>
>David
>
> 
>
> 
>
>
>

Re: review request for configure details page

[Reyna, David]

Hi Belen,

Thank you for the review. Here are some comments for you while I make my fixes.

> SUMMARY TAB

Oh of course. I focused on the second (harder) page since this paged look fine out of the gate. I will fix this.

> BITBAKE VARIABLES TAB
> 
> * The path for the bitbake.conf file is not the full path (it only says
> conf/bitbake.conf)
> 

These are however the actual values from the database. I assumed that for some reason they were local paths. This is not something I can fix.

> * But the Set in file heading should be sortable

But can we sort on a synthetic field where the values only exist through a filter? I will try to find a way.

> * In the filter modal dialogs, the headings and the "All" radio button
> labels say "configvars" instead of "variables". This also happens in the
> applied filter tooltip (in the "Show all" button) and in the placeholder
> text in the search input field (which should say "Search BitBake
> variables")

That needs my patch set for the "Disk IO". "CPU Usage", and "Build Time" pages, which allows me to explicitly set those values different from the page's "cookie" value.

> * The Description filter should be applied when you load this page
> * The Value heading is not sortable

Will fix.

> ** how do we show the operation and line number for the variables touched
> by only one file?

That is why I show the dialog when there are any values available.

- David

> -----Original Message-----
> From: Barros Pena, Belen [mailto:belen.barros.pena@intel.com]
> Sent: Friday, February 14, 2014 8:27 AM
> To: Reyna, David; Damian, Alexandru
> Cc: toaster@yoctoproject.org
> Subject: Re: review request for configure details page
> 
> Thanks, David. Those file filters are really neat :)
> 
> I have reviewed this page. There are a few little things
> implementation-related, and there are other (bigger) issues that are
> design problems.
> 
> The implementation first:
> 
> SUMMARY TAB
> 
> * The Summary values in the Build configuration section don't seem to be
> coming in (for my Beagleboard build, I see machine 'atom-pc', which
> doesn't seem right). That section should list:
> 
> ** BitBake version (BB_VERSION)
> 
> ** Build system (BUILD_SYS)
> 
> ** Host distribution (NATIVELSBSTRING)
> 
> ** Target system (TARGET_SYS)
> 
> ** Machine (MACHINE)
> 
> ** Distro (DISTRO)
> 
> ** Distro version (DISTRO_VERSION)
> 
> ** Tune features (TUNE_FEATURES)
> 
> ** Target FPU (TARGET_FPU)
> 
> ** Target(s), i.e. the name(s) of the image recipe(s) or recipe(s) you are
> building (e.g. core-image-minimal). If more than one, please mark them up
> within an unnumbered list (<ul>)
> 
> If any of the above variables has no value, we don't list the variable
> 
> * We should take out the blue icon next to the layer name
> 
> BITBAKE VARIABLES TAB
> 
> * The Description filter should be applied when you load this page
> 
> * The Value heading is not sortable
> 
> * But the Set in file heading should be sortable
> 
> * The path for the bitbake.conf file is not the full path (it only says
> conf/bitbake.conf)
> 
> * In the filter modal dialogs, the headings and the "All" radio button
> labels say "configvars" instead of "variables". This also happens in the
> applied filter tooltip (in the "Show all" button) and in the placeholder
> text in the search input field (which should say "Search BitBake
> variables")
> 
> There are also some design problems with this page that I need to think
> about:
> 
> 
> * As it was designed, the modal dialog for the history should only exist
> if the number of config files touching the variable is higher than one.
> This causes a few issues:
> 
> ** how do we show the operation and line number for the variables touched
> by only one file?
> 
> 
> ** Search and filtering work across all entries, which means it might not
> be obvious why you get certain results since they are hidden inside the
> history modal dialog
> 
> 
> * How do we deal with very long values (both in the table and in the
> history modal dialogs)?
> 
> * The design specification says that the page h1 should not be manipulated
> by search results: for pages with tabs, like this one, it says to display
> a h2 right above the search field with the number of results returned by
> the search query. Having said that, I am not particularly happy with that
> design either. On the other hand, manipulating the h1 causes some weird
> interactions in the page that could be confusing. This is the kind of
> thing you need to test with users to actually find out. I am inclined to
> leave it as is for the moment, and see how it goes. We can always refine
> it in the next release cycle.
> 
> 
> * What do we do with the B_* variables (in a core-image-minimal build you
> get about 600 of those). We knew we were going to hit this problem at some
> point, but I am not sure how we can exclude those entries within our
> existing filtering patterns. The only easy solution seems to be removing
> the B variable from documentation.conf, which means that neither B nor any
> of the 600 B_* variables will show by default, since we apply the
> Variables with description filter.
> 
> * I have been thinking about how we can keep the links to the full
> variable descriptions in the Yocto Project manual. Right now, we do know
> that an entry in the manual exists for each variable that has a
> description, so it is safe to show the link. We also know their structure
> should be:
> 
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var- +
> <variableName>
> 
> For example:
> 
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-ALL
> OW_EMPTY
> 
> The question is: what's the best way to generate the URLs?
> 
> 
> Sorry for the brain dump: I thought I'd share my pains with you all ;) I
> will try and look into the design issues above as soon as possible. If you
> have any suggestions for any of them, please let me know.
> 
> Belén
> 
> 
> On 14/02/2014 10:26, "Reyna, David" <david.reyna@windriver.com> wrote:
> 
> >Hi again,
> >
> >> ³I have the filter for the descriptions, but is depends on the presence
> >>of a space character²
> >
> >Ok, I was able to redo and push the filter using a regex, so that will
> >allow the possibility of a description that has characters but no spaces.
> >
> >    ('Show only variables with description', 'description__regex:.+'),
> >
> >- David
> >
> >From: toaster-bounces@yoctoproject.org
> >[mailto:toaster-bounces@yoctoproject.org]
> >On Behalf Of Reyna, David
> >Sent: Friday, February 14, 2014 1:20 AM
> >To: belen.barros.pena@intel.com; Damian, Alexandru
> >(alexandru.damian@intel.com)
> >Cc: toaster@yoctoproject.org
> >Subject: [Toaster] review request for configure details page
> >
> >
> >
> >Hi Belen and Alex,
> >
> >
> >
> >I have the configuration page ready for review at:
> >³dreyna/configure-detail-view²
> >
> >
> >
> >Implementation Notes:
> >
> >
> >
> >* In the file list pop-up dialog, I truncate the variable¹s value to 200
> >characters max.
> >
> >
> >
> >
> >The reason is that I discovered for variables (like ³BBINCLUDE²) with
> >very long values, the pop-up is in fact unable by design to scroll to the
> >end, to show the file list.
> > I think that 200 characters give the right idea, and the result looks
> >consistent with the more normal pop-ups.
> >
> >
> >
> >* I have the file filters working for each of the indicated categories.
> >
> >
> >
> >
> >I will note that in my examinations that there were a few file types that
> >were not covered by the existing categories, and I wondered if you were
> >ok that.
> >
> >
> >
> >    poky/meta/classes/*
> >
> >    poky/bitbake/lib/bb/*
> >
> >
> >
> >* I have the filter for the descriptions.
> >
> >
> >
> >I ended on filtering on the presence of a space character, because I
> >could not find an appropriate alternate field lookup. I suppose I could
> >try a regex test.
> >
> >
> >
> >* I implemented the file list such the last file is the one shown.
> >
> >
> >
> >I was however curious if it is absolutely the case that the foreign key
> >select on the VariableHistory table is guaranteed to be in time order. I
> >did manually examine the
> > first 100 rows and found that indeed that the rows were in primary key
> >sequential order, but that is not proof.
> >
> >
> >
> >Thanks,
> >
> >David
> >
> >
> >
> >
> >
> >
> >
> 

Re: review request for configure details page

[Barros Pena, Belen]

On 14/02/2014 09:19, "Reyna, David" <david.reyna@windriver.com> wrote:

>Hi Belen and Alex,
> 
>I have the configuration page ready for review at:
>³dreyna/configure-detail-view²
> 
>Implementation Notes:
> 
>* In the file list pop-up dialog, I truncate the variable¹s value to 200
>characters max.
>
> 
>The reason is that I discovered for variables (like ³BBINCLUDE²) with
>very long values, the pop-up is in fact unable by design to scroll to the
>end, to show the file list. I think that 200 characters give the right
>idea, and the result looks consistent
> with the more normal pop-ups.
> 
>* I have the file filters working for each of the indicated categories.
> 
>I will note that in my examinations that there were a few file types that
>were not covered by the existing categories, and I wondered if you were
>ok that.
> 
>    poky/meta/classes/*
>    poky/bitbake/lib/bb/*

Yes, you are right: the configuration file filters don't cover every
single configuration file that exists. They are an attempt to categorise
configuration into useful groups, but the categorisation is not
exhaustive. 

Hopefully search will help address the classification gaps. For example,
you can search for poky/bitbake/lib/bb/ and that will return all the
variables that are set in files inside that directory (for example, in
cooker.py, or data_smart.py).


> 
>* I have the filter for the descriptions.
> 
>I ended on filtering on the presence of a space character, because I
>could not find an appropriate alternate field lookup. I suppose I could
>try a regex test.
> 
>* I implemented the file list such the last file is the one shown.
> 
>I was however curious if it is absolutely the case that the foreign key
>select on the VariableHistory table is guaranteed to be in time order. I
>did manually examine the first 100 rows and found that indeed that the
>rows were in primary key sequential
> order, but that is not proof.

This is a very good point. Should we be looking into confirming this or
creating some mechanism to collect the right sequence?

> 
>Thanks,
>David
> 
>