yellow team mailing list archive

[Benjamin Saller <benjamin.saller@xxxxxxxxxxxxx>]

This is heading the right direction, I'd be tempted to change more of it
to use external programs and so on as noted below. If you're not
comfortable with the suggestions happy to talk about it.


https://codereview.appspot.com/6909046/diff/1/Makefile
File Makefile (right):

https://codereview.appspot.com/6909046/diff/1/Makefile#newcode31
Makefile:31: PENULTIMATE_VERSION=$(shell grep '^-' CHANGES.yaml | head
-n 2 | tail -n 1 \
Would it be better to use a small python (or external shell if you can
find a cli yaml tool) program to read the YAML and take the last two
entries in a list of release entries? This seems fragile. Such a program
could also be
used to generate the JS file below.

I understand this is just a few lines of shell, but its also the case
that keeping as much procedural logic out of the makefile as possible is
a good idea.

Still, if you feel strongly that it should be like this I'm ok with
that.

Its also not entirely clear why we'd keep the changes as list with desc
but without things like revno, I also don't know if its work checking
(maybe with bzrlib) that the release is tagged (and then we could use
the tag in the changes file). If however there isn't a real
use for the changes (and w/o tags or revno I'm not sure there is) we
could simply write revno to a file and use that value when building the
release.

https://codereview.appspot.com/6909046/diff/1/README
File README (right):

https://codereview.appspot.com/6909046/diff/1/README#newcode139
README:139:
Complicated set of flags, maybe these are different make targets? I see
what your solving, but many of these are specialized for our team but
will always be used in certain ways I expect.

https://codereview.appspot.com/6909046/

-- 
https://code.launchpad.net/~benji/juju-gui/bug-1083618/+merge/138740
Your team Juju GUI Hackers is requested to review the proposed merge of lp:~benji/juju-gui/bug-1083618 into lp:juju-gui.