attic-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Iversen <j...@apache.org>
Subject Re: idea for site maintenance simplification
Date Sat, 05 May 2018 05:39:02 GMT


Sent from my iPad

> On 5 May 2018, at 06:25, Hervé BOUTEMY <herve.boutemy@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.
Correct
> 
> 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
Correct
> 
> - have fewer files to edit:
> how many files precisely to edit now?
You have to divide that in 2:
- Files to edit when retiring a project (2, but the whole site is added in the commit)
- When changing the site 
> 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
not only, but it is the main difference.
> 
> - 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
correct or use JS as in my solution ( I believe buildbot is better, but added it for completeness)
> 
> - 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.
correct
> 
> 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
in theory correct, but during my time as chair I would have been discussing with myself, so
it is overkill as a demand. Apart from that how would you test a PR that changes site layout?
> 
> 
> 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?
We had a community agreement, that I should ask for it, when somebody went ahead without consensus
and created attic-test (I suppose as an alternative to using branches). I would not not like
to end up with 2 git repo’s which means we need to reach consensus (again) on how a git
implementation should be.

Thanks for a good summary, which is the reason I have taken time to answer you, as you surely
also have read, this havoc have caused another (more important) problem for the Attic, a new
chair need to be found and discussions are not really progressing.

rgds
jan i
> 
> Regards,
> 
> Hervé

Mime
View raw message