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.