attic-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
Subject Re: idea for site maintenance simplification
Date Sat, 05 May 2018 09:52:16 GMT
Le samedi 5 mai 2018, 07:39:02 CEST Jan Iversen a écrit :
> 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
by "changing the site", you mean changing normal pages (like process.html) or 
changing more the structure?
To me, dividing in 2 is useful to distinguish normal business as usual 
changes, that have to be straightforward, from structural changes that are 
expected to be heavier.

> 
> > 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)
oh yes, you're right: in the previous paragraph, there was a third one that 
was browser JavaScript based: I forgot that this was done first as an intend to 
have simultaneously fewer files to edit and no local build tool

> > - 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.
for business as usual changes, no real discussion is expected before merging: 
you were doing the job and didn't ask for help (which is more the type of 
interaction that is expected), then everything was running as expected.

for structural changes, discussions are expected: this is where the Git/
GitBox/GitHub solution can help.
Personally, I just didn't track Attic mailing list sufficiently to see that we 
went from BaU to structural change. Sorry to not having answered before: with 
this thread, I'm trying to fix my own failure on being an active Attic PMC 
member (one of 21 PMC member) or even simply an active Attic committer (one of 
25 committers: looks like we have a few committers who are not PMC members, I 
don't know why/how this happened...)

> Apart from that how would you
> test a PR that changes site layout?
there can be multiple answers:
1. the most basic: just locally, since site layout changes are not BaU...
2. with a multi-branch buildbot job and if we can use build server as staging 
webserver, this could be automatic: I don't know how the webserver part can be 
done with buildbot, but I know for example that this is something I do with 
Jenkins. Sebb being our buildbot expert, we could try together

> > 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.
This is where it seems that on the 4 current active Attic committers, there 
are 2 styles of management on learning/testing. And probably misunderstanding 
about what is feasible or not.
IIUC, you were going to ask for a real migration to Git: AFAIK, this would not 
have been quick, since there there are many steps (svn2git mirror, with git 
read-only, then svnpubsub change for live site, then switch to Git read-write 
only). And this would have been a committment from the start that we would go 
to the end of the process.
Knowing that, quickly creating a test Git repo on GitBox to discover in 
parallel how it works, how we can use PRs, how we can build on buildbot, and 
so on, was a great idea and didn't engage much.
The only and critical management misunderstanding was: ask before (on doing 
something that doesn't really engage anything sensitive)
Given that it does not engage anything, I don't see anything wrong with 
starting first then explaining.

> 
> Thanks for a good summary, which is the reason I have taken time to answer
> you,
I'm glad you found it sufficiently useful to answer: I took time to try to find a 
constructive way to continue to work together as Attic committers on 
enhancements

> 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.
hehe, here I have to disagree :)
this discussion to me is some progress. My question for you is: do you want 
just to step down as PMC Chair, or also as PMC member, and even committer?
Or can you still get pleasure on working as committer and/or PMC member?

I'll explain a little bit more: you went into Attic simultaneously as 
committer (work on code and retiring projects), PMC member (manage the 
community when necessary) and PMC Chair (do board reports).

There are some tasks that you seem to have done with pleasure and that are a 
pain to me (and that are a cause that I not proposed to be PMC Chair, hoping 
someone else would do it). And there are some tasks that seem to have become a 
pain to you but that are not about being PMC Chair, and that I can help on 
(with pleasure on my side)

Then I will even tell you a secret hope (that won't be a secret any more...): 
if we manage with this discussion to get a better working Attic project 
between committers, PMC members and PMC Chair, I secretly hope that you'll 
have pleasure back to stay PMC Chair, do some PMC member work with the help of 
other PMC members, and do some committer work with the help of other 
committers.

That's my plan to solving the question of our future chair :)
You don't need to answer yet on the PMC Chair part: we still have time.
You need to figure out now if you want to continue to work with us as PMC 
member and committer...

Regards,

Hervé

> 
> rgds
> jan i
> 
> > Regards,
> > 
> > Hervé



Mime
View raw message