Le samedi 28 avril 2018, 19:44:45 CEST Jan Iversen a écrit : > Sent from my iPad > > > On 28 Apr 2018, at 18:10, Hervé BOUTEMY <[email protected]> wrote: > > > > Le samedi 28 avril 2018, 15:07:34 CEST Jan Iversen a écrit : > >> Sent from my iPad > >> > >>>> On 28 Apr 2018, at 14:56, sebb <[email protected]> wrote: > >>>> On 28 April 2018 at 13:45, Jan Iversen <[email protected]> wrote: > >>>> > >>>> > >>>> Sent from my iPad > >>>> > >>>>>> On 28 Apr 2018, at 14:28, sebb <[email protected]> wrote: > >>>>>> > >>>>>> On 28 April 2018 at 13:06, Jan Iversen <[email protected]> wrote: > >>>>>> > >>>>>> > >>>>>> Sent from my iPad > >>>>>> > >>>>>>> On 28 Apr 2018, at 13:07, Hervé BOUTEMY <[email protected]> > >>>>>>> wrote: > >>>>>>> > >>>>>>> oh, I was just trying to document, not change anything: > >>>>>>> - the svnwcsub part is what works for years but was not well known > >>>>>>> outside > >>>>>>> infra team > >>>>>>> - the buildbot job *for the current build.sh* > >>>>>>> (in/repos/asf/attic/site/) which is just a way to not require to do > >>>>>>> the build locally > >>>>>>> > >>>>>>> this does not include anything regarding future changes that are in > >>>>>>> discussion/tests: > >>>>>>> - Git migration > >>>>>>> - build switch from Ant/Anakia to 3 other solutions > >>>>>>> > >>>>>>> do you see something that is not simple documentation in my commit? > >>>>>>> (I don't want to add more diversity in ideas for future changes, > >>>>>>> just > >>>>>>> document) > >>>>>> > >>>>>> will the buildbot is new, and adding it to our current process is a > >>>>>> bit > >>>>>> premature, especially since we might end up not needing it. > >>>>>> > >>>>>> No need to reverse the commit, I simply wanted to point out facts, > >>>>>> because during the last period things seem to have their own life, > >>>>>> and > >>>>>> are then seen as facts. If I were to retire a project tomorrow, I > >>>>>> would use the old method, without a buildbot.>>> > >>>>> > >>>>> No, you cannot ignore the buildbot because it happens when you commit. > >>>>> > >>>>> However provided that you commit all the changes at once, you should > >>>>> not notice a difference. > >>>> > >>>> then let me just say, the process (online right now) says: > >>>> > >>>> in xdocs/projects/ copy one of the files to the new project name (eg. > >>>> devicemap.xml) Add the new file as a link in the > >>>> xdocs/stylesheets/project.xml navigation Run 'ant' from the root (ie: > >>>> the attic/site/ directory you checked out) Review the generated files > >>>> in > >>>> docs/** in your browser > >>>> SVN commit all changes. Remember to add both the new xdocs/ project > >>>> file > >>>> and the new generated docs/ project file N.B. the buildbot will detect > >>>> any changes to the source and build/commit the outout. So it's > >>>> important > >>>> to checkin all the changes at once. Or just checkin the source changes > >>>> and let buildbot do the rest. The new pages should go live quickly > >>>> so according to that I have to run ant (old process) and commit both > >>>> xdocs and docs, and then buildbot will do something.....this is not > >>>> really understandable as it in reality describes 2 competing > >>>> procedures.> > >>> > >>> There are two alternative procedures: > >>> - build everything locally and check it all in in one commit > >>> - check in the xdocs changes and let buildbot do the work > >>> > >>> I can disable the automatic buildbot if you insist. > >>> But I thought we had already agreed to use it. > >> > >> I just want the procedure to be very clear. > >> the “run ant” step is not optional as an example. > > > > I don't understand this sentence: is it a question or an assertion (which > > is wrong IMHO)? > > it is a statement, looking at process.html as it is right now is at very > least confusing, because it describes 2 methods, but does not clearly state > which steps are mandatory and which steps are optional (choose method) there are 2 options: light remote or full local - light remote process, without local build to check before commit: build is done by buildbot - full local process with local build to check before commit It's really usual with sites built from markup as seen in many other Apache projects, whatever the build tool and the CI server are (which differ from project to project to adapt local technical knowledge)
> > The "ant run" is optional once we have buildbot, it's only useful if you > > want to build locally to check locally something. But you can commit the > > source without having run locally the build: buildbot will do the job for > > you. > yes but we are not there today, and the document should describe things as > they are, and not as they possibly will be. > > And when you tell that in the future you'll edit the source at GitHub > > (which is IMHO a very good target), you'll be exactly on the case where > > you commit the source without having locally tested it > > > >> The build job is there, so I assume it can be used. > > > > yes, it can be used. It can also be ignored = what happens when you run > > the > > build.sh script locally and commit xdocs+docs simultaneously. > > > > But with your sentence "the “run ant” step is not optional as an example", > > I don't get where you want to go: build and commit xdocs+docs locally > > (then ignore buildbot)? or commit just source in xdocs and let buildbot > > do the build and commut docs? > > I want to have a clear process, as it works today. it works today like it is documented > In general I am not in > favor of just changing the process documentation, without having a > community consensus. you can continue to just use the full local process if you want to stick with it only: it does not prevent others to use the light remote one when it is sufficient > > The process doc is on the live site, and should therefore be correct, once again, it is correct, no problem > and > things that may come in the future belong in either of the 2 solutions. no: it will remain with both options: light remote for simple edits, full local for more complex edits. Honestly, once we'll switch to Git and that the output will be in a separate branch (like it happens in many other Apache projects using GitPubSub, or in GitHub sites), the situation will become clearer since even for complex changes, it will be the CI server that will commit the generated content. What makes the situation currently a little unusual is that both source and generated content are in the same svn tree: nowadays in every project I work on, they are always in separate tree just to avoid confusion between source and generated content. Regards, Hervé > > rgds > jan i > > > Regards, > > > > Hervé > > > >> rgds > >> jan i > >> > >>>> rgds > >>>> jan i > >>>> > >>>>>> rgds > >>>>>> jan i > >>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> Hervé > >>>>>>> > >>>>>>> [1] http://svn.apache.org/viewvc/attic/site/ > >>>>>>> > >>>>>>> Le samedi 28 avril 2018, 12:54:40 CEST Jan Iversen a écrit : > >>>>>>>> Isn’t it a bit premature to change the process ? Seen from pow we > >>>>>>>> are > >>>>>>>> experimenting with at least 3 proposals of which 1 does not need a > >>>>>>>> buildbot. > >>>>>>>> > >>>>>>>> This is of course just my opinion. > >>>>>>>> > >>>>>>>> rgds > >>>>>>>> jan I > >>>>>>>> > >>>>>>>> Sent from my iPad > >>>>>>>> > >>>>>>>>> On 28 Apr 2018, at 12:33, [email protected] wrote: > >>>>>>>>> > >>>>>>>>> Author: hboutemy > >>>>>>>>> Date: Sat Apr 28 10:33:07 2018 > >>>>>>>>> New Revision: 1830424 > >>>>>>>>> > >>>>>>>>> URL: http://svn.apache.org/viewvc?rev=1830424&view=rev > >>>>>>>>> Log: > >>>>>>>>> added links to Buildbot job and svnwcsub configuration > >>>>>>>>> > >>>>>>>>> Modified: > >>>>>>>>> attic/site/xdocs/process.xml > >>>>>>>>> > >>>>>>>>> Modified: attic/site/xdocs/process.xml > >>>>>>>>> URL: > >>>>>>>>> http://svn.apache.org/viewvc/attic/site/xdocs/process.xml?rev=1830 > >>>>>>>>> 42 > >>>>>>>>> 4&r1= > >>>>>>>>> 1830423&r2=1830424&view=diff > >>>>>>>>> ================================================================== > >>>>>>>>> == > >>>>>>>>> ===== > >>>>>>>>> ===== --- attic/site/xdocs/process.xml (original) > >>>>>>>>> +++ attic/site/xdocs/process.xml Sat Apr 28 10:33:07 2018 > >>>>>>>>> @@ -76,8 +76,9 @@ > >>>>>>>>> > >>>>>>>>> <p>The following are usefull svn/https locations: > >>>>>>>>> <ul> > >>>>>>>>> > >>>>>>>>> - <li>svn site <a > >>>>>>>>> href="http://svn.apache.org/repos/asf/attic";>http://svn.apache.org > >>>>>>>>> /r > >>>>>>>>> epos/ > >>>>>>>>> asf/attic</a></li> + <li>svn site <a > >>>>>>>>> href="http://svn.apache.org/viewvc/attic";>http://svn.apache.org/re > >>>>>>>>> po > >>>>>>>>> s/asf > >>>>>>>>> /attic</a>: sources in <code>xdocs</code>, generated html in > >>>>>>>>> <code>docs</code></li>> > >>>>>>>>> > >>>>>>>>> <li>site <a > >>>>>>>>> href="http://attic.apache.org";>http://attic.apache.org</a></li> > >>>>>>>>> > >>>>>>>>> + <li>internals: <a > >>>>>>>>> href="https://ci.apache.org/builders/attic-site";>Buildbot job</a> > >>>>>>>>> to > >>>>>>>>> build from source and commit generated html, <a > >>>>>>>>> href="https://github.com/apache/infrastructure-puppet/blob/deploym > >>>>>>>>> en > >>>>>>>>> t/mod > >>>>>>>>> ules/svnwcsub/files/svnwcsub.conf#L36">svnwcsub configuration</a> > >>>>>>>>> to > >>>>>>>>> update generated html from svn to webserver</li>> > >>>>>>>>> > >>>>>>>>> <li>jira <a > >>>>>>>>> href="https://issues.apache.org/jira/browse/ATTIC";>https://issues > >>>>>>>>> . > >>>>>>>>> ap > >>>>>>>>> ache.org/jira/browse/ATTIC</a></li> <li>committees.xml <a > >>>>>>>>> href="https://svn.apache.org/repos/asf/comdev/projects.apache.org > >>>>>>>>> / > >>>>>>>>> da > >>>>>>>>> ta/committees.xml">https://svn.apache.org/repos/asf/comdev/projec > >>>>>>>>> t > >>>>>>>>> s.a > >>>>>>>>> pache.org/data/committees.xml</a></li>> > >>>>>>>>> > >>>>>>>>> </ul>
