Ok ... pinging this thread again ...
So has anyone else had a look at the newly generated documentation in the flex-site.git "maven-site" branch? As I mentioned, if you checkout the "asf-site" branch you can see the generated output. Chris ________________________________ Von: Christofer Dutz <christofer.d...@c-ware.de> Gesendet: Donnerstag, 13. Oktober 2016 07:49:01 An: dev@flex.apache.org Betreff: AW: AW: AW: AW: [Website] Progress on the Website-Generation topic Hi Alex, Well you do need buildbot ... nothing else is allowed to commit. But nothing else than buildbot. I was talking about the user workflow. These three steps are the steps you need, if you want to change something and I guess you can't get any simpler than that. Especially with the ability to test your changes locally before committing. Buildbot kicks in as soon as you commit and does the rest. But needing buildbot isn't a change as we currently need buildbot for the current version too (https://ci.apache.org/builders/flex-site-staging). So in this case we would simply replace on buildbot job with another. So if we are comparing the new three-step user workflow: 1. Do changes 2. Test them locally with a "mvn clean site" 3. Commit changes to the current user workflow, which is: 1. Do changes 2. Commit changes 3. Wait for buildbot to stage the changes 4. Check if the output is what we want in the staging area 5. Go to the Web-Ui and release all changes at once (Could be a problem that you release stuff someone else is currently working on, but I guess that's a more theoretical problem) I think the new workflow is a great improvement. And especially if it's just the fixing of typos, it boils down to a two step Workflow: 1. Do changes 2. Commit changes And another thing I noticed is that the new page performs a lot better on small resolutions like on tablets or mobile phones (If you decrease the width of the browser window the site adjusts like in the old version, but the mobile-menu-version of the new version looks a lot nicer than that of the current version) And I just wanted to put straight that this workflow is not more complicated than anything we have right now. I know 99% of people on this list just read and don't let their voice be heard and I just think if they read your email containing a completely incorrect "How I understood it" summary from you, it would manipulate them in thinking the whole thing is too complicated - which it is not. Chris ________________________________ Von: Alex Harui <aha...@adobe.com> Gesendet: Donnerstag, 13. Oktober 2016 06:40:35 An: dev@flex.apache.org Betreff: Re: AW: AW: AW: [Website] Progress on the Website-Generation topic Well, maybe I'm just being dense, but in the most recent two threads you started on this topic, you mention buildbot, and I saw a lot of buildbot traffic come into my mailbox. So apologies if I haven't followed your emails in detail, but I did not see any prior mention of not needing buildbot and could not find your 3-step workflow in previous emails. On 10/12/16, 12:54 PM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >Well I think I wrote down the entire workflow as well as the when's and >why's so many times that I'm not going to repeat them again. > >You don't need the build at builds.a.o at all. I just set that up in the >beginning because in the beginning I thought I would have to trigger >buildbot from there and didn't delete it after finishing, because I >simply forgot it's there. > >What you get is: >- A website in git and not svn. >- The code is generally a lot cleaner. >- You don't have to commit changes to test them in the staging area. >- You don't have to use that stupid web interface to release staged stuff >to production. > >I currently don't have asciidoctor in there at all, so please stop >describing this approach as complicated and simply read my emails. I've been trying to figure out the advantage of using builds.a.o vs buildbot. It sounds like the key point is that we can publish without having to go through the web interface. That sounds like a good deal to me. Let's see what others think. > >Workflow is: > >1. Do changes in the "maven-site" branch >2. Test them locally by running "mvn clean site" >3. Commit and push them > >That's it. Nothing more to it. So assuming others are in favor, what are the remaining steps? Do we want to exactly reproduce the existing site? Do we need to be concerned about the "insecure content" errors/warnings? Nick K was working on a revamp of our website. I wonder how that work will be impacted. Thanks, -Alex
