Sent from my iPad
> On 5 May 2018, at 11:52, Hervé BOUTEMY <herve.bout...@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.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. >> >> 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é > >
