From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path:
Received: from mail.windriver.com (mail.windriver.com [147.11.1.11])
by yocto-www.yoctoproject.org (Postfix) with ESMTP id CF029E007E2
for ; Fri, 28 Feb 2014 03:33:31 -0800 (PST)
Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com
[147.11.189.40])
by mail.windriver.com (8.14.5/8.14.5) with ESMTP id s1SBXScM005683
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
Fri, 28 Feb 2014 03:33:28 -0800 (PST)
Received: from ALA-MBB.corp.ad.wrs.com ([169.254.1.230]) by
ALA-HCA.corp.ad.wrs.com ([147.11.189.40]) with mapi id 14.02.0347.000;
Fri, 28 Feb 2014 03:33:28 -0800
From: "Reyna, David"
To: "Barros Pena, Belen" , "Damian, Alexandru"
Thread-Topic: V4: review request for configure details page
Thread-Index: Ac80GuUwRLT7CeSXSmaQpVCSIWnr4AAM7XKgAAjtQYAAAIUdkAAAuS2AAAAK4/A=
Date: Fri, 28 Feb 2014 11:33:27 +0000
Message-ID: <5E53D14CE4667A45B9A06760DE5D13D055DD7972@ALA-MBB.corp.ad.wrs.com>
References: <5E53D14CE4667A45B9A06760DE5D13D055DD6F6D@ALA-MBB.corp.ad.wrs.com>
<5E53D14CE4667A45B9A06760DE5D13D055DD7591@ALA-MBB.corp.ad.wrs.com>
<5E53D14CE4667A45B9A06760DE5D13D055DD7906@ALA-MBB.corp.ad.wrs.com>
In-Reply-To:
Accept-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.11.118.179]
MIME-Version: 1.0
Cc: Paul Eggleton ,
"toaster@yoctoproject.org"
Subject: Re: V4: review request for configure details page
X-BeenThere: toaster@yoctoproject.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Web based interface for BitBake
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 28 Feb 2014 11:33:34 -0000
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
> So in the last action 3), when I search, the search should search all
> variables stored in the database for the selected build, and when the
> search results come in, there should be no filter applied.
Hmm. The ability to assert both a filter AND a search was actually a strong=
selling point when I did my presentation to our Wind River engineers.
The use case is this:=20
1) Select the "All Builds" page
2) Set the "Completed on" filter do a specific day or time range.
3) Set the "Search" to "atom-pc"
In this example, the build team can examine and correlate all builds for a =
given "Machine" for a given time range (for example for a specific commit w=
indow), in order to compare success rates and build times. The engineers in=
fact wanted more correlation and grouping views and tools of this nature, =
especially since Toaster already had all the data.
I have collected several other such user stories, which I am validated and =
will pass back to the Toaster team soon.
I propose that we keep this feature, and sell the heck out of it.
- David
> -----Original Message-----
> From: Barros Pena, Belen [mailto:belen.barros.pena@intel.com]
> Sent: Friday, February 28, 2014 3:22 AM
> To: Reyna, David; Damian, Alexandru
> Cc: Paul Eggleton; toaster@yoctoproject.org
> Subject: Re: V4: review request for configure details page
>=20
>=20
>=20
> On 28/02/2014 11:12, "Reyna, David" wrote:
>=20
> >> I cannot see this working. I am not sure the fix is in your dev branch=
.
> >
> >Hmm, I see the patch in "dreyna/configure-detail-view", in the file
> >"basetable_top.html".
> >
> >Let me describe my test procedure in detail, in case that will reveal
> >something.
> >
> >1) Start the "Configure" page fresh, and click "Bitbake variables".
> >
> >Observe that the column filter is by default set to the "Description"
> >column "Variables with description".
> >
> >2) Reset the filter to the "Set in file" column, and choose for example
> >"Machine configuration variables".
> >
> >Observe that the new column filter is asserted, and that the
> >"Description" filter is off.
> >
> >3) Put the string "conf/bitbake" in the "Search" text box, and click
> >"Search".
> >
> >Before this fix, the default "Description" filter would suddenly be
> >re-asserted, and the user selected "Set in file" filter would be turned
> >off.
>=20
> Ah, right, the problem is that the above does not match how search behave=
s
> everywhere else in Toaster (that is why for me "it wasn't working"). The
> scope of the search is the full content of the database, so searching
> clears your filters.
>=20
> So in the last action 3), when I search, the search should search all
> variables stored in the database for the selected build, and when the
> search results come in, there should be no filter applied.
>=20
> >
> >With this fix, the filter remains as the "Set in file" filter, preservin=
g
> >the user's selection.
> >
> >
> >What do you observe?
> >
> >- David
> >
> >
> >> -----Original Message-----
> >> From: Barros Pena, Belen [mailto:belen.barros.pena@intel.com]
> >> Sent: Friday, February 28, 2014 2:46 AM
> >> To: Reyna, David; Damian, Alexandru
> >> Cc: Paul Eggleton; toaster@yoctoproject.org
> >> Subject: Re: V4: review request for configure details page
> >>
> >> On 28/02/2014 06:40, "Reyna, David" wrote:
> >>
> >> >Hi again,
> >> >
> >> >> * When you cancel the search string, the column filters are also
> >>reset.
> >> >
> >> >Fixed and added to "dreyna/configure-detail-view"!
> >>
> >> I cannot see this working. I am not sure the fix is in your dev branch=
.
> >>
> >> Cheers
> >>
> >> Bel=E9n
> >>
> >> >
> >> >It turns out that the two search buttons were not passing the "filter=
"
> >> >and "count" values, and that has the unfortunate side effect of forci=
ng
> >> >every view to execute "_redirect_parameters", which in turn would
> >>always
> >> >immediately reset any user-selected filters (and "count").
> >> >
> >> >Here is the simple (and global) fix:
> >> >
> >> >vvvvvvvvvvvvvvv
> >> >
> >> >diff --git
> >>a/bitbake/lib/toaster/toastergui/templates/basetable_top.html
> >> >b/bitbake/lib/toaster/toastergui/templates/basetable_top.html
> >> >index 9a8bacb..b19c936 100644
> >> >--- a/bitbake/lib/toaster/toastergui/templates/basetable_top.html
> >> >+++ b/bitbake/lib/toaster/toastergui/templates/basetable_top.html
> >> >@@ -35,6 +35,8 @@
> >> >
> >> > >>value=3D"{{request.GET.orderby}}">
> >> >
> >> >+
> >> >+
> >> >
> >> >
> >> >
> >> >^^^^^^^^^^^^^^^^^
> >> >
> >> >The other remaining issue (sorting the file column) will need to wait
> >>for
> >> >a database fix when Alex gets back.
> >> >
> >> >- David
> >> >
> >> >> -----Original Message-----
> >> >> From: toaster-bounces@yoctoproject.org [mailto:toaster-
> >> >> bounces@yoctoproject.org] On Behalf Of Reyna, David
> >> >> Sent: Thursday, February 27, 2014 5:08 PM
> >> >> To: Barros Pena, Belen; Damian, Alexandru
> >> >> Cc: Paul Eggleton; toaster@yoctoproject.org
> >> >> Subject: [Toaster] V4: review request for configure details page
> >> >>
> >> >> Hi Belen,
> >> >>
> >> >> On to V4 for "dreyna/configure-detail-view"!
> >> >>
> >> >> FIXES:
> >> >>
> >> >> * The description filter tooltip says: "Showing only Show only
> >> >>variables..."
> >> >> * I see: FILTER:conf/
> >> >> * variable values over 150 characters are not truncated on the tabl=
e.
> >> >> * Extended variable name patterns should link to the root variable
> >>entry
> >> >>
> >> >> All done!
> >> >>
> >> >> * When using the search, each row will appear multiple times.
> >> >>
> >> >> Done! I realized that the "searches" were in fact working inside th=
e
> >> >>vhistory
> >> >> list (it is column sorts that are broken). The unexpected consequen=
ce
> >> >>is that
> >> >> each hit added the record to the queryset, with the observed anomal=
y
> >> >>that
> >> >> multiple file name hits added duplicate rows in the table. Here is =
my
> >> >> resolution.
> >> >>
> >> >> # remove duplicate records from multiple search hits in the
> >> >> VariableHistory table
> >> >> queryset =3D queryset.distinct()
> >> >>
> >> >> * Variables with no value and no file should be excluded
> >> >>
> >> >> Done! My tests show this working as expected, where I do see rows
> >>with
> >> >>a file
> >> >> but no value, but I do not see rows without both. Plus, since this =
is
> >> >>done in
> >> >> the view and not in the template, the pagination works as expected.
> >> >>Here is
> >> >> my resolution.
> >> >>
> >> >> # remove records where the value is empty AND there are no
> >>history
> >> >>files
> >> >> queryset =3D
> >> >> queryset.exclude(variable_value=3D'',vhistory__file_name__isnull=3D=
True)
> >> >>
> >> >> I had to play around with this to get the second clause to work, an=
d
> >>I
> >> >>would
> >> >> like Alex to review it, but as I said it seems to work.
> >> >>
> >> >>
> >> >> PENDING ISSUES:
> >> >>
> >> >> > Where should I map the help for variable name with patterns of th=
e
> >> >>form
> >> >> "do_*"
> >> >>
> >> >> I sent email on this question separately.
> >> >>
> >> >> > "My only doubts are about case 2, where
> >> >> > I am not sure it makes sense to show the last file when the searc=
h
> >> >>string
> >> >> > is found in any other file for a certain variable."
> >> >>
> >> >> I propose that most user searches are for variable names, so the fi=
le
> >> >>column
> >> >> will appear to reflect the default behavior. If I do not by default
> >> >>include
> >> >> the last file, then searching for variable names will _always_ resu=
lt
> >> >>in the
> >> >> file column becoming empty (expect by coincidence), which does not
> >>look
> >> >>like
> >> >> the normal behavior for the page.
> >> >>
> >> >> It may only look odd if you do a search for example for
> >>"conf/bitbake",
> >> >>where
> >> >> you would get all of the matches _plus_ the last file. Given the
> >> >>downside in
> >> >> the previous and more common use case, I think that this little bit
> >>of
> >> >>extra
> >> >> information is worth it.
> >> >>
> >> >> I think a match between both a variable and a file name is unlikely=
.
> >> >>
> >> >> > * The column sort for files will only test the first file in any
> >> >>vhistory
> >> >> list.
> >> >> > * When you cancel the search string, the column filters are also
> >> >>reset.
> >> >>
> >> >> Still pending.
> >> >>
> >> >> > Any scripting inside a template should go at the very end of the
> >> >> > markup, but before the closing
...
tag.
> >> >>
> >> >> All I am saying is that unless we define an additional block for
> >> >>template-
> >> >> specific scripts (and I think that at some point this would be a go=
od
> >> >>idea),
> >> >> both the "
..." and the "
" are locked
> >>inside
> >> >> "main.html" and are inaccessible to template files, and thus
> >> >>inaccessible for
> >> >> template-specific scripts.
> >> >>
> >> >> Thanks!
> >> >> David
> >> >>
> >> >> > -----Original Message-----
> >> >> > From: Barros Pena, Belen [mailto:belen.barros.pena@intel.com]
> >> >> > Sent: Thursday, February 27, 2014 4:05 AM
> >> >> > To: Reyna, David; Damian, Alexandru
> >> >> > Cc: toaster@yoctoproject.org; Paul Eggleton
> >> >> > Subject: Re: V3: review request for configure details page
> >> >> >
> >> >> > Hi David,
> >> >> >
> >> >> > Thanks for all the good work. I have commented inline on your ema=
il
> >> >>when
> >> >> > required.
> >> >> >
> >> >> > There are also a couple of small issues I am still seeing:
> >> >> >
> >> >> > * The description filter tooltip says: "Showing only Show only
> >> >>variables
> >> >> > with description". It should say "Showing only variables with
> >> >> > description". If needed, we can change the radio button label to
> >>say
> >> >>just
> >> >> > "Variables with description=B2
> >> >> >
> >> >> > * Variables with no value and no file are only there because ther=
e
> >>is
> >> >>a
> >> >> > description set for them in documentation.conf. They should be
> >> >>excluded
> >> >> > from the view (table, search, sorting and filtering).
> >> >> >
> >> >> >
> >> >> > Cheers
> >> >> >
> >> >> > Bel=E9n
> >> >> >
> >> >> > On 27/02/2014 03:53, "Reyna, David"
> >>wrote:
> >> >> >
> >> >> > >Hi Belen,
> >> >> > >
> >> >> > >I have implemented the proposed design changes to the "Configure=
"
> >> >>page.
> >> >> > >
> >> >> > > dreyna/configure-detail-view
> >> >> > >
> >> >> > >I did need to make some small changes to the proposed design, as
> >> >> > >documented below. There are also some outstanding issues, which =
I
> >> >>also
> >> >> > >list below.
> >> >> > >
> >> >> > >IMPLEMENTATION:
> >> >> > >
> >> >> > >> 1) "Showing history for all variables"
> >> >> > >
> >> >> > >Done.
> >> >> > >
> >> >> > >> 2) "Searching and filtering" (Hidden file problem)
> >> >> > >
> >> >> > >Done.
> >> >> > >
> >> >> > >I did however realize that "search" applies to all fields, not
> >>just
> >> >>the
> >> >> > >file list. This is an issue when you for example search the rpws=
a
> >>for
> >> >> > >"BBINCLUDED", because suddenly all of the files would disappear
> >> >>because
> >> >> > >none would match. I do not think that this is what the user woul=
d
> >> >>expect
> >> >> > >when they are searching for variables and not file names.
> >> >> > >
> >> >> > >Here is therefore how I implemented the file filtering:
> >> >> > >
> >> >> > > 'search' 'file filter' Action
> >> >> > > -------- ------------- ----------------------
> >> >> > > - - show last file
> >> >> > > value - show last file, plus any file names tha=
t
> >> >>match
> >> >> > >search
> >> >> > > - value show only file names that match filter
> >> >> > > value value show any file names that match either
> >>string
> >> >> > >
> >> >> > >I think that this meets out needs, and is a "least surprise" for
> >> >>users.
> >> >> >
> >> >> > In general, this makes sense to me. My only doubts are about case
> >>2,
> >> >>where
> >> >> > I am not sure it makes sense to show the last file when the searc=
h
> >> >>string
> >> >> > is found in any other file for a certain variable.
> >> >> >
> >> >> > Also, when I apply a 'set in file' filter, I see the following
> >>string
> >> >>on
> >> >> > each cell: FILTER:conf/
> >> >> >
> >> >> > >
> >> >> > >> 3) "Dealing with long values"
> >> >> > >
> >> >> > >Done. To see it work, turn off the "Description" filter and look
> >>at
> >> >>the
> >> >> > >variable "BBINCLUDED", which is guaranteed to be bigger than 570
> >> >> > >characters.
> >> >> >
> >> >> > This is working in the history modal dialogs, but variable values
> >> >>over 150
> >> >> > characters are not truncated on the table. It's important we do
> >>this
> >> >>in
> >> >> > order to keep the table readable.
> >> >> >
> >> >> > >
> >> >> > >> 4) "What if a variable value is an empty string?"
> >> >> > >
> >> >> > >Done.
> >> >> > >
> >> >> > >> 5) "What do we do with the 613 B_* variables?"
> >> >> > >
> >> >> > >They are now gone from the view.
> >> >> > >
> >> >> > >> 6) "Linking variables to the Yocto Project reference manual"
> >> >> > >
> >> >> > >Done.
> >> >> > >
> >> >> > >However, the statement "we do know that all variables with a
> >> >>description
> >> >> > >in documentation.conf have an entry in
> >> >> > >the Yocto Project reference manual" is not universally true. Her=
e
> >>are
> >> >> > >some counter examples:
> >> >> > >
> >> >> > > ALLOW_EMPTY_${PN}-dbg
> >> >> > > ASSUME_PROVIDED
> >> >> > > ASSUME_SHLIBS
> >> >> > > BBFILE_PATTERN_core
> >> >> > > BBFILE_PRIORITY_core
> >> >> > > ...
> >> >> > >
> >> >> > >Some of these are obviously extended patterns, but the code does
> >>not
> >> >>know
> >> >> > >that, and there is no obvious way to filter for that.
> >> >> >
> >> >> > Extended patterns should link to the root variable entry (so
> >> >> > ALLOW_EMPTY_${PN}-dbg links to the ALLOW_EMPTY entry). But you ar=
e
> >> >>right:
> >> >> > ASSUME_PROVIDED does not have an entry in the manual. I'll review
> >>the
> >> >> > content of documentation.conf to eliminate any mismatches.
> >> >> >
> >> >> > >
> >> >> > >
> >> >> > >LIMITATIONS:
> >> >> > >
> >> >> > >7) There are still the observed defects. I will investigate, but
> >> >>they are
> >> >> > >outside of the code under review.
> >> >> > >
> >> >> > > * When you cancel the search string, the column filters are al=
so
> >> >>reset.
> >> >> > > * The search will only test the first file in any vhistory lis=
t.
> >> >> > > * When using the search, each row will appear multiple times.
> >> >> > >
> >> >> > >8) I have added the new Javascript code to support the value
> >>extender
> >> >> > >dialog to the file "templates/base.html", and it works!
> >> >> >
> >> >> > It does work wonderfully :)
> >> >> >
> >> >> > >
> >> >> > >
> >> >> > >I do not know if this the best place. Nor do I know if it will
> >>affect
> >> >> > >other pages that would not otherwise use it.
> >> >> > >
> >> >> > >I do observe that there is currently no way for a page to add
> >>local
> >> >> > >script code to the "" section, which is currently locked
> >>inside
> >> >> > >"base.html". Maybe you can add script code to other sections, bu=
t
> >>I
> >> >>know
> >> >> > >that in testing that this new script section would not work when
> >> >>placed
> >> >> > >anywhere within "templates/configvars.html".
> >> >> >
> >> >> > Any scripting that will be reused by several templates should go =
on
> >> >> > main.js. Any scripting inside a template should go at the very en=
d
> >>of
> >> >>the
> >> >> > markup, but before the closing tag. That way the page loa=
ds
> >> >>first
> >> >> > all markup and we show something to users, while the scripts take
> >> >>their
> >> >> > time to load. But I think in general we should aim to have all js
> >> >>neatly
> >> >> > put away in main.js
> >> >> >
> >> >> > >
> >> >> > >Thanks,
> >> >> > >David
> >> >> > >
> >> >> >
> >> >>
> >> >> _______________________________________________
> >> >> toaster mailing list
> >> >> toaster@yoctoproject.org
> >> >> https://lists.yoctoproject.org/listinfo/toaster
> >>
> >
>=20