On 5 May 2018 at 05:25, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > Hi, > > I took time to read the whole discussions from april and understand what was > the common objective, and what were solutions envisioned and discussed and > partly done and partly with consensus yet to be found. > > AFAIK, we have a common objective: simplifying attic site maintenance.
+1 > The simplification ideas and solutions are: > - retired site update: > banners solution in place with initial site http://oltu.apache.org/ > IIUC, there are still some improvements that could eventually be done (for .eu > and .us urls), but it works quite well. > This idea is the most critical, since it was really a pain for each new > project move to Attic +1 > - have fewer files to edit: > how many files precisely to edit now? > evaluation has been that this require changing templating solution (too hard > or no knowledge to add such feature to current Ant/Anakia build), and format > of data > this is where we have 2 competing solutions.. we'll discuss this later > > - avoiding build tools use on editor's computer: > buildbot job added that builds and publish when source is updated. > Manual local build and commit can still be done > AFAIK, this solution works well Yes, it works well with SVN. I have tried to get a GitHub/GitBox-based version working using the temporary attic-test repo. The build aspect works fine and can use separate branches for source and target. Unfortunately there is a problem when buildbot tries push the updated target workspace back. See https://issues.apache.org/jira/browse/INFRA-16471 > - web browser only edit: > Idea on this would be to use GitHub online editing: given ASF has GitBox > service in place, and with previous automated build and publish on source > update, this seems feasible. I have tried this with attic-test. AFAICT when using a browser GitHub can only be used to update existing files. If there is a way to create a new file, it's not at all obvious, and would presumably mean more work. So a single file solution seems essential to support easy online updates. > This Git/GitBox/GitHub solution could bring us other advantages: branches > management and PR review would ease tests and discussion before deciding to > merge to trunk/master > > > IMHO, working on GitBox/GitHub solution would ease future work and discussion > on the "have fewer files to edit" ideas. > And I know that it is feasible without changing many things on the current > situation. > > WDYT about prioritizing this Git/GitBox/GitHub solution? AFAICT that will not allow browser-only addition of new Attic projects unless the code is also changed to support using a single file as the data source. It would allow maintenance of existing templates etc, i.e. could be used to update existing project info or change templates. But if we do wish to move the existing site to Git first, most of the preparatory work for automatic builds has been done using the attic-test repo. However until INFRA-16471 is solved, Buildbot cannot be used to automate site publication with GitBox/GitHub. Note: pushes to git-wip repos work fine under Buildbot, however I think it would be a non-starter to move to git-wip as it is being phased out and we would have to move to Gitbox later anyway. > Regards, > > Hervé
