Merge lp:~pfalcon/linaro-android-build-tools/descr-update into lp:linaro-android-build-tools

[Paul Sokolovsky]

This updates Android Build job descriptions to include notice of Andy's user build scripts which were deployed recently.

See https://android-build.linaro.org/builds/~pfalcon/new-instr-sample/ for an example how it looks like.

[James Tunnicliffe (dooferlad)]

While I am not a fan of the pink background (#FFC is my preference for a nice yellow one, but I look at a lot of python docs - I guess I can live with it!

My preference would be to use a heading and define CSS for it to set the "New!" bit up as a different colour. That said, it is in a big colourful box - it is going to get peoples attention - so I think the new is not required and I would just delete it.

[Andy Doan (doanac)]

review: Approve

[Paul Sokolovsky (pfalcon)]

> While I am not a fan of the pink

Well, the idea is to get attention. At least it's not red ;-).

> My preference would be to use a heading and define CSS for it to set the "New!" bit up as a different colour. That said, it is in a big colourful box - it is going to get peoples attention - so I think the new is not required and I would just delete it.

Well, it does use CSS to define colors. Do you mean to use styles? If so, the need to define styles all the time (essentially, an extra level of indirection) is overstated. There're cases where self-containment and clarity is more important, and arguably this is the case.

And for "New!", well, it is! I probably wouldn't add it though if we didn't have what we have on the frontpage. But well, let's be user-friendly ;-). The idea is to remove "new!" in a couple of months and let just the box hang. (I don't even dream of actually having better formatted/consisted build descriptions).

[James Tunnicliffe (dooferlad)]

On 2 April 2012 17:48, Paul Sokolovsky <email address hidden> wrote:
>> While I am not a fan of the pink
> Well, the idea is to get attention. At least it's not red ;-).

It kind of looks like a warning (anything in the red spectrum does),
but it isn't. It is an information box. I am not sure if there is a
common colour that is used for this sort of thing, but I think it is
safe to say that pink/red isn't it.

>> My preference would be to use a heading and define CSS for it to set
>> the "New!" bit up as a different colour. That said, it is in a big colourful
>> box - it is going to get peoples attention - so I think the new is not
>> required and I would just delete it.
>
> Well, it does use CSS to define colors. Do you mean to use styles? If so,
> the need to define styles all the time (essentially, an extra level of
> indirection) is overstated. There're cases where self-containment and
> clarity is more important, and arguably this is the case.

<div class="info_hilight"> is preferred (if my memory serves) because
that way you are defining what the element contains and you then use
CSS to tell the browser how to render it. This is hardly a case of
having to define styles all the time and it makes it much easier if
someone comes along and wants you to change the colour of the element.

> And for "New!", well, it is! I probably wouldn't add it though if we
> didn't have what we have on the frontpage. But well, let's be
> user-friendly ;-). The idea is to remove "new!" in a couple of months
> and let just the box hang. (I don't even dream of actually having
> better formatted/consisted build descriptions).

Isn't this a patch that is generating some static HTML though, so all
those HTML files will have to be modified in the future? Wouldn't it
be much easier and far more maintainable to create the page using the
Django template engine?

--
James Tunnicliffe

[Paul Sokolovsky (pfalcon)]

On Mon, 02 Apr 2012 17:31:45 -0000
James Tunnicliffe <email address hidden> wrote:

> On 2 April 2012 17:48, Paul Sokolovsky <email address hidden>
> wrote:
> >> While I am not a fan of the pink
> > Well, the idea is to get attention. At least it's not red ;-).
>
> It kind of looks like a warning (anything in the red spectrum does),
> but it isn't. It is an information box. I am not sure if there is a
> common colour that is used for this sort of thing, but I think it is
> safe to say that pink/red isn't it.

Yes, that's the intention. What it tries to say is "Don't try to miss
me - if you do, and will read the below, your eyes will bleed because
styling there is much worse, and also you might get a headache
following all the (not always cleanly written) instructions below, and
there's still no warranty that it will work, because there's nor
warranty that those instructions are up to date".

>
> >> My preference would be to use a heading and define CSS for it to
> >> set the "New!" bit up as a different colour. That said, it is in a
> >> big colourful box - it is going to get peoples attention - so I
> >> think the new is not required and I would just delete it.
> >
> > Well, it does use CSS to define colors. Do you mean to use styles?
> > If so, the need to define styles all the time (essentially, an
> > extra level of indirection) is overstated. There're cases where
> > self-containment and clarity is more important, and arguably this
> > is the case.
>
> <div class="info_hilight"> is preferred (if my memory serves) because

There's no "preferred" on the global scale, there's only flexibility to
do it this or that way on that scale. It's just as saying that
"preferred" way to do an addition is to assign operands to variables
first:

a = 2; b = 2; c = a + b; c == 4

Nope, it's still fine to just do 2 + 2 = 4 when you need just that ;-).

> that way you are defining what the element contains and you then use
> CSS to tell the browser how to render it. This is hardly a case of
> having to define styles all the time and it makes it much easier if
> someone comes along and wants you to change the colour of the element.

Yes, that works really well (and gets extra boons) when thing is well
maintained. When it is not, making a simple self-contained changes is a
better approach.

> > And for "New!", well, it is! I probably wouldn't add it though if we
> > didn't have what we have on the frontpage. But well, let's be
> > user-friendly ;-). The idea is to remove "new!" in a couple of
> > months and let just the box hang. (I don't even dream of actually
> > having better formatted/consisted build descriptions).
>
> Isn't this a patch that is generating some static HTML though, so all
> those HTML files will have to be modified in the future? Wouldn't it
> be much easier and far more maintainable to create the page using the
> Django template engine?

Actually, pragmatically, what this patch does is finishing deployment
of Andy's work is the least disturbing and the most straightforward
way. Now, semantically, it exactly implements poor man's template
engine, so it would be easy to replace styling/text of that header.
Finally, syntacticall...

[Paul Sokolovsky (pfalcon)]

Ok, as Andy ok with it, going to deploy it.

=== added file 'utils/mangle-jobs/header.html'
--- utils/mangle-jobs/header.html	1970-01-01 00:00:00 +0000
+++ utils/mangle-jobs/header.html	2012-04-02 11:46:22 +0000
@@ -0,0 +1,12 @@
+<table width="65%" align="center">
+<tr><td>
+<p style="background: #FFCCFF; padding: 15px">
+<span style="color: gray">New!</span><br />
+We now provide <tt>linaro_android_build_cmds.sh</tt> script (see downloads)
+with exact commands to reproduce this build. Use it as a reference of
+commands you need to execute, or just run to perform a build automatically.
+There is also <tt>linaro_kernel_build_cmds.sh</tt> to rebuild just a kernel.
+Alternatively, you can try instructions below.
+</td></tr>
+</p>
+</table>

=== added file 'utils/mangle-jobs/prepend-to-description.mangle'
--- utils/mangle-jobs/prepend-to-description.mangle	1970-01-01 00:00:00 +0000
+++ utils/mangle-jobs/prepend-to-description.mangle	2012-04-02 11:46:22 +0000
@@ -0,0 +1,28 @@
+# This script prepends a notice to each job's description
+# (or replaces such notice if already there).
+
+from mangle_helper import *
+
+
+PREPEND_TEXT = open("header.html").read()
+
+HEADER = "\n<!-- Automatically managed header - do not change, do not add anything before this! -->\n"
+FOOTER = "<!-- End of automatically managed header -->"
+
+def mangle(tree):
+    cfg = get_build_config(tree)
+    build_type = cfg.get("BUILD_TYPE")
+    if not build_type:
+        build_type = cfg.get("SCRIPT_NAME", "build-android")
+    if build_type != "build-android":
+        return
+
+    nodes = tree.xpath('/project/description')
+    if not nodes: return
+    descr = nodes[0].text
+    if descr is None:
+        descr = ""
+    if FOOTER in descr:
+        descr = descr[descr.find(FOOTER) + len(FOOTER):]
+    descr = HEADER + PREPEND_TEXT + "\n" + FOOTER + "\n\n" + descr
+    nodes[0].text = descr