[aerogear-dev] Suggestion/Discussion - Removal of AeroGear.org Production Branch

[Matthias Wessendorf]

On Wed, Dec 6, 2017 at 12:07 PM, Laura Fitzgerald <lfitzger at redhat.com>
wrote:

> Hi all,
>
> I have recently gone through the process of publishing documentation for
> AeroGear Digger to aerogear.org.
>
> The process for adding docs for digger was as follows:
>
> - Make changes on Feature Branch over a period of time.
> - At some point merge lots of commits (difficult to review) from Feature
> Branch to master.
> - This publishes to staging.aerogear.org (build needs to be manually
> triggered in Jenkins)
> - At some point merge master (again with lots of commits) to production
> branch
> - This publishes to aerogear.org (build needs to be manually triggered)
>
> Out of this we attempted to improve the process by adding development
> steps to the README [1] outlining that
> -> each change should be verified on it's own -> merged to master -> and
> then merged to production
> removing the wait time and merges which involved lots of commits and
> changes.
>
> *I think there are a few things we can do to make this better. (simpler)*
>
> *1) How?*
>
> Remove the production branch (and related steps) altogether.
>
> *Why?*
>
> - All this documentation is done in the open.
> - All branches are visible to all users/developers.
> - staging.aerogear.org is not private so I don't see that we gain
> something by having this step.
>

it was usful when preparing new looks or new contents (e.g. redesign / new
releases with new contents)


but I am fine having all that live, or on branches - there is no problem
viewing ascii doc via GH



> - Changes can be verified locally by building the website using the steps
> in the README [2] before being merged to master.
>
> *2) How?*
> Automate the publishing of the site
>
> *Why?*
> Right now the building of the site has to be triggered manually via a
> Jenkins instance on cloudbees. If we remove production and enforce that all
> changes are fully verified before being merged to master then we can
> automate that any new changes are published immediately once merged to
> master.
>
> *3) How?*
> Add some sort of versioning to the documentation. This could be in the
> form of tagging the repo once we have a release of a product.
>
> *Why?*
> If we are always publishing docs once a change is made to the product then
> we should version the documentation so we know which version of the docs
> matches older versions of the product.
>
> ~~~~~~~~~~~
>
> I'm really interested in some feedback on this. Let me know what you
> think. Is there a better/simpler way to do it than I suggested?
>


generally +1 on this move


>
> [1] https://github.com/aerogear/aerogear.org/blob/
> master/README.md#development-steps
> [2] https://github.com/aerogear/aerogear.org/blob/
> master/README.md#building
> --
>
> LAURA FITZGERALD
>
> Red Hat Mobile <https://www.redhat.com/>
>
> Communications House, Cork Road
>
> Waterford City, Ireland X91NY33
>
> lfitzger at redhat.com    IM: lfitzgerald
> <https://red.ht/sig>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20171206/51af814f/attachment-0001.html