Hi Shawn,

Op vr 7 aug. 2020 om 14:29 schreef Shawn McKinney <smckin...@apache.org>:

>
>
> > On Aug 6, 2020, at 3:11 PM, Roy Lenferink <lenferink...@gmail.com>
> wrote:
> >
> > Maybe you missed my message in this thread :)
> >
> > My response was more or less that february this year I tried converting
> the Directory website to use a static site generator. At that moment
> Emmanuel's response was to see how it went with MINA (already migrated off
> the CMS) before continuing with Directory. This because the two projects
> have more or less a similar design.
> >
>
> Hi Roy,
>
> No I didn’t miss the message, I have viewed the artifacts, they look good
> FWICT.
>
> Where my confusion lies is what are the next steps?  It appears you are
> offering to do the conversion for us which is a very kind offer.
>

The next steps I am willing to help out with.The history is preferably
included. That is something I am willing to do.
Also, the changes between february and now also need to be included (and
now overwritten).
While working on including the history I am willing to help out with that
as well.


> But, what happens after that conversion?  How do we make changes, what is
> the workflow, …?
>

The non-CMS workflow is that the generated site is available in version
control on the 'asf-site' branch.
The sources for generating the site are in the repository its default
branch.

For Apache Celix we created a Jenkins job which generates the site when
changes are committed to the master branch:
https://ci-builds.apache.org/job/Celix/job/site/job/master/

The Jenkins job pushes the generated site to the 'asf-site' branch, which
infra tooling then will pickup for serving the actual site.

So in case of a new release, the simplest task is updating the version
number here:
https://github.com/rlenferink/directory-site/blob/master/config.toml#L36

I made it configurable so that there is only a single definition of a
subproject its version throughout the whole site.

Other website content is available as it is right now as well, in Markdown:
https://github.com/rlenferink/directory-site/tree/master/source


>
> Perhaps it’s not confusion as much as concerns:
>
> 1.  That we won’t be able to maintain, or have significant difficulty
> maintaining, thus making it difficult to do a release.
>
> 2. The process to make changes to one subproject impacts another
> subproject in unforeseen ways.
>

The layouts/designs for the different subprojects are still available:
https://github.com/rlenferink/directory-site/tree/master/layouts

This means it is still possible to change the style of a subcomponent
without breaking the whole website.

The website sources for the different subprojects are in the same
repository but that is the same as it is right now with the CMS.


>
> Perhaps my concerns are unwarranted, but at this point there seems to be
> more of a risk than reward.
>

No problem asking! Better to have things clarified upfront.


>
> OTOH I clearly understand the imperative to get off of an obsolete CMS.
> So it’s not a question of if but when.
>
> > The following repo contains the Directory site converted to Hugo:
> https://github.com/rlenferink/directory-site
> >
> > Steps that I will take before it may be useful:
> > - Include SVN history (history is always useful, especially if someone
> wants to see why a specific change was made)
> > - Update to include latest SVN changes.
> >
> > Some threads about moving from the CMS to Git/static site generator:
> >
> https://lists.apache.org/thread.html/r4bb58d7f93dc547abc6c2829c1dad751a72a14089000550b37bbad6b%40%3Cdev.directory.apache.org%3E
> >
> https://lists.apache.org/thread.html/r338baf731f509c6ae833600469c2b247cafe02022c1687a705a66012%40%3Cdev.community.apache.org%3E
> >
> https://lists.apache.org/thread.html/rf0d4fef9b65e1ef346bc71b66253f9e54f15e048be6d011751a24ae0%40%3Cdev.community.apache.org%3E
> >
> https://lists.apache.org/thread.html/r2f2874ca9dc2dcf04970f59c5efdece9d14afc4b2193b4a0a108dcd9%40%3Cdev.jena.apache.org%3E
> >
> > Let me know if you need some additional info from my side.
>
>

Reply via email to