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 11:01:34 GMT


Sent from my iPad

> On 5 May 2018, at 11:52, Hervé BOUTEMY <herve.boutemy@free.fr> wrote:
> 
> 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?
yes
> 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.
+1
> 
>> 
>>> 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.
Well you have to consider the history, some committers are very quick to point out when changes
have not been discussed in advance.
> 
>> 
>> 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?
As you can see in my mail, my plan is to leave completely.
> 
> 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.
Until recently I had no problem doing it all, but now I have 2 problems:
- I see a pattern in the community discussion (the old redirect and this one), a moderator
is needed to achieve consensus. I have acted as moderator, trying not to be directly involved
(e.g. as you surely have read, I have not pushed for my original solution just fir something
useful). That is something I find a waste of time (in this case) because it seems that no-doers
decide.
- I fear if I continue I will be forced to work tools I do not understand, nor care about.
> 
> 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...
As above, I have no problem filing board reports, not even retiring a project now and then
(provided I have good tools, like github editing in a single understandable file). But the
pointless discussion are something I do not want to participate in, nor read (as Chair I am
supposed to follow our ML, to be able to make the board reports).

Sorry if I have disappointed you.
rgds
jan I
> 
> Regards,
> 
> Hervé
> 
>> 
>> rgds
>> jan i
>> 
>>> Regards,
>>> 
>>> Hervé
> 
> 

Mime
View raw message