From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 9DE9CE00798; Fri, 22 Aug 2014 02:58:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high * trust * [134.134.136.24 listed in list.dnswl.org] Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 65C77E0044A for ; Fri, 22 Aug 2014 02:58:30 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 22 Aug 2014 02:52:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,379,1406617200"; d="scan'208";a="562062529" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga001.jf.intel.com with ESMTP; 22 Aug 2014 02:57:39 -0700 Received: from irsmsx152.ger.corp.intel.com (163.33.192.66) by IRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 22 Aug 2014 10:55:30 +0100 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.3]) by IRSMSX152.ger.corp.intel.com ([169.254.6.48]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 10:55:30 +0100 From: "Barros Pena, Belen" To: "Reyna, David L (Wind River)" , "toaster@yoctoproject.org" Thread-Topic: Design for the configuration variables page (6588) Thread-Index: AQHPvVKwdNWY+ihW/k6N2nKjeJmKdJvcDIBggABXQIA= Date: Fri, 22 Aug 2014 09:55:29 +0000 Message-ID: References: <5E53D14CE4667A45B9A06760DE5D13D05CD89F3C@ALA-MBB.corp.ad.wrs.com> In-Reply-To: <5E53D14CE4667A45B9A06760DE5D13D05CD89F3C@ALA-MBB.corp.ad.wrs.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.237.224.33] MIME-Version: 1.0 Cc: "Eggleton, Paul" Subject: Re: Design for the configuration variables page (6588) 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, 22 Aug 2014 09:58:42 -0000 Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Thanks for reviewing the document, David. Some comments inline. On 22/08/2014 06:45, "Reyna, David" wrote: >Hi Belen, > >I have taken a pass at your excellent document. I have a few questions, >more than for other documents given the nature of the content, some >presumably for Alex. > >1) I myself am fine with the initial limited list of configuration >variables. Let us start easy and build up later. > >I assume that the class for Projects will be updated to initialize this >list, hard coded for now. > >2) [Alex] How does the interface know if a configure variable can be >blank, in other words when it can show the "delete" button as per your >design? Is the easy plan to just hardcode the behavior for the default >variables, and not attempt to assert this rule for the hand-added >variables? >From the design standpoint, I applied a very simple principle: no variable can be blank in the interface. You either set a variable to a non-empty value (i.e. not blank) or you delete it. The default list of variables cannot be deleted, so they must be set to a non-empty value. The only exception to this rule is IMAGE_INSTALL_append, and the reason is to expose the variable so that it is easier to discover that you can use it to customise the content of the rootfs. This approach might be too simplistic, though, and you might want to the ability to set certain variables to blank values through Toaster. > >Here is the table object that I understand maps to the project's >"Configuration Variable". > >class ProjectVariable(models.Model): > project =3D models.ForeignKey(Project) > name =3D models.CharField(max_length=3D100) > value =3D models.TextField(blank =3D True) > >3) [Alex] How did we want changes propagated back to the database? I >observe that there is no "Submit" button, unless "Save" and "Add Value" >are the mini-submit buttons. There is no 'global' save in this page: you make changes per variable, so changes should go into the database when you click a variable's "save" button (the mini-submit buttons, as you call them). > >The sample implementation has Javascript automatically updating the view >when "Add Value" is clicked (which is cool). Does that JS action also do >a Jquery or something and instantly update the database? > >Along these lines, I observe that there is no "Cancel" button so people >cannot change their minds. I myself am ok with that for now - we can >embellish this later. There is a "cancel" action again per variable. So if I click "change" DISTRO which is set to 'poky', I change the value to 'poky-bleeding', then I click the "cancel" action, the variable goes back to 'poky'. If I click 'save', it will change to 'poky-bleeding' and there is no undo: you need to change the variable value back if you change your mind. Since nothing really happens when you change a variable until you start a build, having an 'undo' option for variables is probably overkill. > >4) You write in your example for IMAGE_FSTYPES: > >It appears that IMAGE_FSTYPES is a special variable with special >handling. Is that list hard coded in the view data, or can I get that >list from somewhere? As far as I know, the list comes from the IMAGE_TYPES variable. I could be wrong though. > >5) Were does the strings for PACKAGE_CLASSES come from? Are they simply >hard coded in this initial version of the view? > >6) Can I assume that the SDKMACHINE variable can only be the values >'i686' or 'x86_64', and this is hard coded into the view? I have no answers to those 2. They reflect what we currently to in Hob, so I've assumed the values we show there are the correct values, and that they come from somewhere (hopefully they are not hardcoded). > >7) [Alex] Where does the blacklist come from? I think we need to put it together ourselves. I will send around a first version, so people can add to it. > >Thanks, >David > >> -----Original Message----- >> From: Barros Pena, Belen [mailto:belen.barros.pena@intel.com] >> Sent: Thursday, August 21, 2014 8:15 AM >> To: toaster@yoctoproject.org >> Cc: Reyna, David; EGGLETON, PAUL; DAMIAN, ALEXANDRU >> Subject: Design for the configuration variables page (6588) >> >> Design document attached to the Bugzilla issue, as usual >> >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=3D6588 >> >> I would need people to go through the document (it's not too long): >>there >> might be changes needed. >> >> Also, we need to come up with a final list of blacklisted variables. >> >> Thanks! >> >> Bel=E9n >> >