Hi
I have a couple of hours free while another project I work on is building, so I
did “svn up” in attic, and started looking at site-jekyll.
The very first ground rule, is that we (like other projects) have the right to
update our layout, but I agree we should (when possible) not loose project
data, if still relevant. It seems a lot of effort have gone into making a 100%
match with the production site.
Secondly, I kind of like the idea that the site is generated, but with
something simple like a small script (that could also do the flagged etc. kind
of stuff). I need to talk with infra, if we can have the site in git and still
have a the trigger for builds. Having the site on GitHub, would make
editing/commit very easy.
First impression was: "do we really need all those files, just to generate the
attic site". Of course we need
- projects.json (which I am not sure will be copied to the actual site,
something which is needed),
- the 3 static html pages
- the css files
- the script files (hopefully we can get rid of them)
- a template for the <project>.html
- a template for the sidebar to be included in all files
- a generator script
The rest is just complicating matters, and the many directories makes it
interesting to find the files that actually matters, e.g. project.html is in
_layout, while index.html is in root but both are templates.
Looking at the single files:
_config.yml,
I thought we wanted to avoid yaml ?
_includes/project.list
Contains:
<h6>Projects in the Attic</h6>
<ul>{% for project in site.data.projects %}
<li><a href="/projects/{{ project.id | default: project.name |
downcase | replace: " ","-" | replace: "/","-" }}.html">{{ project.name
}}</a></li> {% endfor %}
</ul>
This is supposed to be easy to maintain ?
It is like a whole new programming language, why do we need that. I for one are
not going to touch stuff like that.
_layouts/project.html
This should be real simple, something like a simple “sed …..” Doing the job,
but it contains lines like:
<td>{% for m in page.json.mailnames %}
{% unless forloop.first %}| {% endunless %}<a
href="http://mail-archives.apache.org/mod_mbox/{{ page.json.full_dash }}-{{ m
}}/">{{ m }}</a>{% endfor %}
</td>
Even a simple insert can be complicated:
<td><a href="{{ page.json.website }}">{{ page.json.website | replace:
"http://",""; }}</a></td>
I have no idea, why we need complicated replacing etc.
_data/projects.json
The fields in this version are bound to give problems (because e.g. some
projects use their own bugzilla version and thereby have a different link)
Fields like “jira” and “bugzilla” are better in their generic form as “issues”
and with an url. I wonder why “wiki” still is only 1 field, and not split in
the different wikis we have, but please keep it simple.
We have “name”, “project”, “jira”, “bugzilla”, “board”, that basically describe
the projects name, I hardly believe that is needed ?
“Retired” now contains e.g. “January 2011”, something which is harder for 3rd
party to interpret, what is wrong by using “mm/yyyy” ?
——
To sum up, the goal was to make a new site simple to maintain and in my opinion
site-jekyll is actually more complicated than the production site.
I still believe we can make a simple script, that are called in the build job,
which then generates what we need. It is basically attic.js, but written e.g.
in bash.
I believe it is important to stop making splitting fields in son, and finalise
what is there, so we can make a decision on how to proceed.
I am aware that Sebb has put a lot of time into making this, something I highly
respect, but truth is we have all agreed we need something simple, no new
languages. The js solution was that, but I agree with Sebb that a generated
solution is better.
How do we proceed from here ? I am -1 on putting site-jekyll in its present
form in production.
rgds
Jan I.
