This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.
CMS Decommissioning RFC - Frequently Asked Questions
CMS Documentation Reference - http://www.apache.org/dev/cms
Infrastructure Proposal: Decommissioning of the CMS
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.
This point has been disputed during discussions, and infra is reviewing the documentation provided.
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.
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.
Lack of ongoing project/community/vendor support like we have with jira, confluence, bugzilla, etc.
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.
Our desire to introduce the gitwcsub service, which is not compatible with the CMS without extensive reworking.
continued use of svnpubsub
introduction of gitpubsub
Infra-assisted migration to svnpubsub/gitpubsub
PMCs would have option to use markdown source as-is or take existing HTML as-is and continue to publish via pubsub:
Keep using markdown to derive their HTML
Manage the HTML directly using svnpubsub to publish
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.
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.
Currently, MD and GFM (Markdown and Github flavoured markdown) via Cactus and Jekyll for server-side HTML generation.
PMCs choosing to generate HTML locally could use any client-side tooling.
Very little, if anything, as the cactus engine we have suggested is very similar to the one used in the CMS.
Will this require additional work by projects to convert to the proposed replacement system?
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.
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?
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.
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.
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.
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.
Are there opportunities to expand the number of supported builds in the proposal to include things like maven and anakia?
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.
[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
[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.
(Discussion on infrastructure Subject: Re: the maven site or any site using extpaths (was Re: cms migration steps))