Child pages
  • CMS Decommissioning RFC - Frequently Asked Questions
Skip to end of metadata
Go to start of metadata

CMS Decommissioning RFC - Frequently Asked Questions

CMS Documentation Reference - http://www.apache.org/dev/cms

Infrastructure Proposal: Decommissioning of the CMS


  1. Is this a done deal?

    1. NO. This is an inquiry into a proposal, not a final decision. The Infrastructure team would like to make a tentative decision based around this proposal by Tuesday 31st March 2015, so that the team have the opportunity to discuss this in more detail whilst we are altogether in Austin, at ApacheCon.

  2. Why has Infra proposed the retirement of the CMS?

    1. baldr.apache.org (CMS jail host) is EOL and requires replacement. Migration of services off FreeBSD hosts also includes a move to Ubuntu and puppet-based configuration management. An initial survey of the CMS code and existing documentation suggest that a conversion of the CMS to a fully supported, puppet-managed configuration would take a significant amount of infra contractor time.

      1. This point has been disputed during discussions, and infra is reviewing the documentation provided.

    1. To better utilize Infra resources, heavily customized, self-developed, or duplicate applications are being evaluated for ongoing “supportability,” typically as the service host nears EOL. Supportability in this case means identifying sufficient and appropriate on-staff or volunteer resources to effectively manage, repair, update, and upgrade custom code in a meaningful and timely fashion. Infra feels that the CMS does not currently fit this criteria, and would like to move towards solutions utilizing less custom/self-developed code.

    2. To simplify our service portfolio as much as possible.  We currently have more than 50 services we manage, and this is simply too high a burden given some of the services in question.

    3. Lack of ongoing project/community/vendor support like we have with jira, confluence, bugzilla, etc.

    4. Infra’s concerns lower our confidence level to a point where none of the the group feel comfortable in supporting this to a professional level, within the SLAs we have defined.

    5. Our desire to introduce the gitwcsub service, which is not compatible with the CMS without extensive reworking.

  3. What is Infra proposing as a replacement for CMS functionality?

    1. continued use of svnpubsub

    2. introduction of gitpubsub

    3. Infra-assisted migration to svnpubsub/gitpubsub

      1. PMCs would have option to use markdown source as-is or take existing HTML as-is and continue to publish via pubsub:

      2. Keep using markdown to derive their HTML

      3. Manage the HTML directly using svnpubsub to publish

      4. Manage the HTML directly using gitpubsub to publish. If a project opts for option number 1, the PMC has the choice to use svn or git to store the markdown. Then options 2 and 3 mean that the PMC just manages the HTML directly. If they opt to do this using SVN the location is currently outside the project’s own repo, but is just as accessible. If the PMC opts to use gitpubsub the site will be stored within the PMCs git repo.

    4. Infra will provide an environment for markdown translation so PMCs do not need to run markdown tools locally, but local markdown translation would also be supported.

  4. What markdown options will be supported?

    1. Currently, MD and GFM (Markdown and Github flavoured markdown) via Cactus and Jekyll for server-side HTML generation.

    2. PMCs choosing to generate HTML locally could use any client-side tooling.

  5. What will it take to convert an existing CMS markdown site to the new system?

    1. Very little, if anything, as the cactus engine we have suggested is very similar to the one used in the CMS.

  6. How many projects/podlings are currently using the CMS?

    1. 95

  7. Will this require additional work by projects to convert to the proposed replacement system?

    1. Yes, although the scope of work is still being documented and assessed. Any additional workload on projects will be carefully considered, as it is a cost associated with retirement of a service that may ultimately exceed the proposed benefit.

  8. Who will be responsible for converting the existing ASF site? Will it still be possible for members to use the GUI to edit / commit changes to it? And will the general public be able to easily generate patches for it?

    1. We don’t expect there to be any major issues, we expect Cactus to work just fine. If we deprecate the CMS, there will be no GUI to use no. Patches will be possible, yes, this depends on how the projects choose to manage their site. i.e. MD or HTML.

  9. Is there any change to the mdtext syntax? The main ASF site uses mdtext extensively. It took several months to convert everything from the previous syntax, and we were still discovering conversion errors a year or more later.

    1. Cactus supports the main CMS flavour of MD. The CMS supports only one variant, based on the perl implementation of the specific version it uses.

      1. A rebuttal to this provided by Joe: “Not quite. Lucy in particular uses a different version of markdown than the rest.  But for people who use the perl build the vast majority are using the markdownd which is the Python implementation.

  1. Are there opportunities to expand the number of supported builds in the proposal to include things like maven and anakia?

    1. TBD


Project-Specific Q&A


  1. The Commons website uses CMS for the parent site and svnpubsub only for the component sites. Would that have to change? If so, how?

    1. If we deprecate the CMS, then yes, the projects will need to use an alternate method. If you want to continue using svnpubsub for the component sites this would not change. You could move them to git, if that was preferred.  The only change is the removal of the CMS service.  We *will be* offering a different automated build of MD->HTML for those that want to maintain MD content.

  2. Looking at www for a second, a large amount of attention was paid to ensuring each original url was preserved including hashtags.  That is the main reason for santiago's custom markdown module.  How do we do this going forward?

    1. TBD

  3. Maven’s website makes extensive use of the cms's extpaths support to provide a mixture of cms generated content and subproject-based svnpubsub content.

    1. [Hervé] : that's what will cause problems without the CMS: I don't see how to update the main site without doing a checkout of the 5GB

    2. [still under discussion] => Solution found: /components svnwcsub added and symbolic links created (via Ant script and links list) in main site to link to

  4. How will CMS extpaths support be carried forward, as this appears to be critical to the builds of some sites (maven, for example.)

    1. [Joe] :  Anyway Tony, what Herve and I are discussing will resolve the maven situation acceptably.  What this means is that similarly structured sites: those with normal sized source trees but large websites due to extpaths usage, can cope with this proposal without major hardship.  Apache commons is similar, but there aren't too many of them in total.

      1. (Discussion on infrastructure Subject: Re: the maven site or any site using extpaths (was Re: cms migration steps))

  5. [Joe] : The incubator's build system is anakia/ant based, and the vast amount of content is stored in highly irregular xml.

    1. [Joe] :  What do I mean by irregular?  Well the xml is hand-written with no semblance of schema enforcement by the build system, so a lot of it is just tag soup, which complicates any wholesale migration scripting towards a different format.  We had to deal with the same situation with www, but there was a lot less content and it took months of eyeballing Sam's anakia2markdown conversion scripting for anomalies. Each page needed to be regenerated and cleaned up to a greater or lesser extent by hand, but his scripting took most of the tedium out of the process. Kudos to Sam once again. 
      Traditionally when the incubator managed its site by having users build and commit the results themselves, there was an epic amount of conflicts caused by the fact that users were making edits to the build output tree instead of the source tree.  Going back to that approach will invariably lead to the same types of errant commits, because relatively few incubating projects are versed in the cultural norms around managing an anakia site. The cms has fortunately buried these nagging details by managing the build itself.
      Migration to something else might be doable if the incubator can collectively decide on what to migrate to and find the tuits to do the necessary conversion work, but it is no small task that one or two volunteers can accomplish in a few weekends. Unless there is a serious effort to phase out tons of stale content and make the site a lot more minimalist. How should we address this situation?
      1. TBD.
  • No labels