[Toaster] DRY RUN [Review Request] 4299 "recipes: View detailed information about a recipe"

[Lerner, Dave]

Hi David,

I notice that you pluralized the recipe.html to recipes.html.  Doesn't that break the existing convention of singular for all templates?

What is your suggested naming convention for templates, singular vs plural?  If those conventions are settled on by the team, then we should apply that naming convention to the project before we create a number of other templates. 

What do others think of the template naming conventions?  
Dave


> -----Original Message-----
> From: Reyna, David
> Sent: Sunday, January 12, 2014 12:35 AM
> To: Damian, Alexandru (alexandru.damian at intel.com); belen.barros.pena at intel.com; Ravi
> Chintakunta (ravi.chintakunta at timesys.com); Lerner, Dave; Eggleton, Paul
> (paul.eggleton at intel.com)
> Cc: Reyna, David; toaster at yoctoproject.org
> Subject: DRY RUN [Review Request] 4299 "recipes: View detailed information about a
> recipe"
> 
> Hi all,
> 
> I believe that I have completed the Recipe Details page, as per Belen's requirements.
> 
> I unfortunately do not have my commit credentials setup as I am moving to a more SSH-
> friendly host. I hope to have that in place Monday. In the meantime I would like to do
> an informal review request, with the following content.
> 
> 1) The diffs for the model and view are attached, plus "recipes.html" and "recipe.html"
> as normal files since they are new files. (FYI, "recipes.html" _plural_ is a fixed
> version of the previous template "recipe.html" _singular_).
> 
> 2) Below is a proposed formal example "review request" with "Development notes" and
> "Test Instructions". As per our discussion, this is based on Wind River's review request
> process. The test instructions in particular are intended to (a) demonstrate what I as a
> developer did to confirm that it is working, (b) provide an easy way to compare the
> scope of testing verses the original design document, and (c) provide simple and
> complete instructions for a Tester who most likely will not be as familiar with the
> feature as the developers. Hopefully, such instructions can be then later be
> incorporated into a regression test.
> 
> 3) This is my first review for Toaster. I will certainly be very interested in any Yocto
> standards that I may not have addressed.
> 
> 4) My next steps are to get my host SSH set up, start looking at Ravi's code, plus try
> to understand why the URL links in the tables do not have normal URL coloring.
> 
> Thanks,
> David
> 
> +++++++++++++++++++++++++++++++++++++++++
> [Review Request] 4299 "recipes: View detailed information about a recipe"
> 
> Development Notes
> =================
> 
> The implementation of the recipe "outcome" highlighting is done using a helper method in
> the "Task" class, which returns the CSS color style for the respective "outcome" value.
> 
> While it is not ideal to mix HTML fragments in class definitions, this choice was made
> because Django templates do not really support using conditionals to set local
> variables, and we want to avoid duplication of the table code for each case. The
> possible alternate implementations include custom filters, custom tags, or Javascript,
> each with their own tradeoffs.
> 
> 
> Test Instructions
> =================
> 
> 1) Create a default Yocto project (qemux86), and start the Toaster.
> 
>   $ source poky/oe-init-build-env
>   $ source toaster start
>   $ bitbake core-image-minimal
>   $ xdg-open http://localhost:8000/
> 
> 2) Select the "core-image-minimal" build link
> 
> 3) Select the "Recipes" link in the left sidebar
> 
> Observe that the recipes are listed in a table, and that each recipe name is a live URL
> link.
> 
> 4) Click on the "busybox" recipe name link
> 
> Observe:
>   a) The "breadcrumbs" at the top include is in this form form, and that all but the
> last entry are live links.
> 
> 	     All builds > core-image-sato atom-pc (<time>) > Recipes > busybox_1.21.1-r0
> 
>   b) The informational sidebar on the right contains information pertinent to the
> "busybox" recipe,
> 
>   c) Some 14 task entries, starting with "do_patch" and ending with "do_build" If you
> hover over a recipe name, you will see a question-mark icon appear, and if you hover
> over that a tooltip will appear for that task.
> 
>   d) Any task outcome of "Succeeded" should be in normal black. Any outcome of "Failed"
> (not likely) would be red, and all other tasks should be in grey.
> 
>   e) The layer description will indicate the layer "meta", and the recipe will point to
> "busybox_1.21.1.bb".
> 
>   f) The right-hand sidebar about busybox is still present.
> 
> 5) Observe that "Packages" link. It should have an appended value like "(4)". Now click
> on this link.
> 
> Observe:
>   a) The number of packages matches the previous number in parenthesis.
> 
>   b) Each package has a version and a size. The size may be zero.
> 
>   c) Note that if you hover on a package name, it will reveal a URL of the following
> form. This link should take you to the corresponding package detail page once you have
> the fix for 4328 pulled.
> 
> 	localhost:8000/gui/build/<number>/package/<number>
> 
> 6) Observe that "Build Dependencies" link. It should have an appended value like "(0)".
> Now click on this link.
> 
> Observe:
>   a) No dependencies appear, and you get a message of the form:
> 
>   "$RECIPE_NAME_VERSION has no build dependencies."
> 
> 7) Observe that "Reverse build dependencies" link. It should have an appended value like
> "(1)". Now click on this link.
> 
> Observe:
>   a) The number of packages matches the previous number in parenthesis.
> 
>   b) The recipe dependency should be "packagegroup-core-boot",
> 
>   c) There should be a respective version displayed, for example "1.0-r11"
> 
>   d) If you hover on the recipe name, it will reveal a URL of the following form. This
> link should take you to the corresponding recipe detail page.
> 
> 	localhost:8000/gui/build/<number>/recipe/<number>
> 
> 8) Click the breadcrumb "Recipes" at the top, locate the "gdbm" recipe, and select it.
> 
> 9) Observe that "Packages" link. It should have an appended value like "(0)". Now click
> on this link.
> 
> Observe:
>   a) No packages appear, and you get a message of the form:
> 
>   "$PACKAGE_NAME_VERSION does not build any packages."
> 
> 10) Observe that "Build dependencies" link. It should have an appended value like "(2)".
> Now click on this link.
> 
> Observe:
>   a) The number of build dependencies matches the previous number in parenthesis.
> 
>   b) The recipe dependency should have values like "gettext-native" and "libtool-cross".
> 
>   c) There should be a respective versions displayed for each dependency.
> 
>   d) If you hover on a recipe name, it will reveal a URL of the following form. This
> link should take you to the corresponding recipe detail page.
> 
> 	localhost:8000/gui/build/<number>/recipe/<number>
> 
> 11) Observe that "Reverse build dependencies" link. It should have an appended value
> like "(0)". Now click on this link.
> 
> Observe:
>   a) No reverse dependencies appear, and you get a message of the form:
> 
>   "$RECIPE_NAME_VERSION does not build any packages."
> 
> - David