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.


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.


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.


Reply via email to