I requested an aries-sitepub mailing list and then realized how redundant the name is. Now I’ve requested [email protected], I suspect it will be ready tomorrow and I’ll be able to start experimenting with publishing a preview of the new site.
I think we’re likely to want to move pages around for a while when basic publishing works. I have an .htaccess file for the current “new locations” of the content, and it has 301 permanent redirects in it. While we are deciding on a new structure, would it work to have 302 temporary redirects and never supply redirects from the “current new location” to the “final new location”? David Jencks > On Aug 23, 2020, at 10:35 PM, Romain Manni-Bucau <[email protected]> > wrote: > > Le dim. 23 août 2020 à 20:26, David Jencks <[email protected]> a > écrit : > >> Let’s not try to do everything at once. For me the next step is getting >> the site build/publishing working. My question about a separate mailing >> list is the next sub-step. >> > > +1 > > I’m having some medical problems so may not be able to do much on this for >> a few days, but resolving any answer to the mailing list quest would be >> helpful. >> > > Take care, site does not urge ;) > > >> David Jencks >> >> Sent from my iPhone >> >>> On Aug 23, 2020, at 9:41 AM, Romain Manni-Bucau <[email protected]> >> wrote: >>> >>> With Ray on that. >>> >>> Le dim. 23 août 2020 à 15:11, Raymond Auge <[email protected] >> .invalid> >>> a écrit : >>> >>>> Sigh, I had hoped the Aries site sources would be in the main aries >> repo. I >>>> hate to be combative, but I feel we had consensus to do just that in the >>>> beginning of this process. Now we're just in the same boat as before, no >>>> one will update the site when source code is modified... >>>> >>>> - Ray >>>> >>>>> On Sat., Aug. 22, 2020, 7:05 p.m. David Jencks, < >> [email protected]> >>>>> wrote: >>>>> >>>>> Progress: >>>>> >>>>> - CMS content history and initial antora migration is in the >>>>> aries-antora-site repo >>>>> - Published site history is in aries-site-pub repo >>>>> - html pages from CMS and those in the published site (except for >>>>> duplicates) are now visible in Antora site. They don’t all look great, >>>> but >>>>> they are there. >>>>> - javadoc pages are also in the site and accessible >>>>> - I think the nav has all the pages except javadoc >>>>> - I constructed an .htaccess file which redirects from all locations >> from >>>>> the old site to the new site, including the xsd urls. This does not >>>>> include the apparent mistakes of duplicate files. >>>>> - The not-found pages for .htaccess are listed in the aries-antora >>>> project >>>>> in dot-htaccess-not-found >>>>> - I added a package.json and playbook for building the content that >>>>> happens to be in the aries-antora-site repo locally. This will be one >> of >>>>> many, don’t think it can be used for building the site. >>>>> - I started on a script to publish to aries-site-pub repo. >>>>> >>>>> Next steps: >>>>> >>>>> - I don’t think we want commits to aries-site-pub to go to the commits >>>>> list, having source updates from aries-antora-site will be more than >>>>> enough. Infra requires commit emails go somewhere, and they suggested >>>>> setting up a list just for this. I think this is a fine idea, how >> about >>>>> aries-site-pub for the list name? >>>>> >>>>> - when this issue of where the emails go is resolved I’ll work more on >>>> the >>>>> publish script; I’m hoping it will be straightforward to get the script >>>>> working locally, figure out an asf.yml to publish to a preview site. >> At >>>>> this point I’ll point out the preview. >>>>> >>>>> - next, figure out how to run the script on ASF hardware. I think >>>> there’s >>>>> a requirement that only PMC members can cause the site to be published, >>>> so >>>>> I don’t think it can work off a commit trigger. >>>>> >>>>> - at some point I’ll write some instructions in README.adoc files. >>>>> >>>>> Comments: >>>>> >>>>> - I think we can take advantage of Antora’s multi-version capabilities >> by >>>>> tagging something like the current state (in aries-antora-site) as >>>> “legacy” >>>>> and keeping that as a version. On master we can delete obsolete >> content, >>>>> but it will still be visible in the legacy version. We could mark >>>> content >>>>> to be deleted with a header attribute ‘obsolete’ and generate a list of >>>>> these pages while we consider. (cf. auto-index.adoc). >>>>> >>>>> - I think the utility of the per-source-repo ‘author-mode’ builds is a >>>>> stronger argument for keeping the ui in a separate repo than my strong >>>>> personal preference to do so. We’re shortly going to have >>>>> (subproject-count) + 2 repos with playbooks in them, and any argument >> for >>>>> putting the UI in one is just about as strong as for another…… very >> weak >>>>> IMO. I suggest you try out the current arrangement before rejecting >> it. >>>>> It will get easier when I write some docs. >>>>> >>>>> The next steps are, I think, going to involve pushing the new build >> site >>>>> to aries-site-pub, so we need to either agree that commit emails going >> to >>>>> [email protected] are fine or agree to set up another list. >>>>> >>>>> David Jencks >>>>> >>>>>> On Aug 21, 2020, at 11:18 PM, Romain Manni-Bucau < >>>> [email protected]> >>>>> wrote: >>>>>> >>>>>> Still think playbook and ui module must be merged. >>>>>> Both will never be released anyway and it makes things easier. >>>>>> >>>>>> Site history should just be a folder imo, not a repo... >>>>>> >>>>>> >>>>>> Le sam. 22 août 2020 à 02:11, David Jencks <[email protected]> >>>> a >>>>>> écrit : >>>>>> >>>>>>> A couple more comments on playbooks… >>>>>>> >>>>>>> Since IIUC we’re planning to add docs for all the more recent >>>>> subprojects >>>>>>> that each live in their own repo, to those repos, the “production” >>>>> playbook >>>>>>> can’t prefer one over the others and be in a content repo. >>>>>>> >>>>>>> However, we can easily provide a “preview” playbook in each repo for >>>>>>> building just the content in that repo, to check local changes in >>>> more >>>>>>> detail than in the IntelliJIDEA asciidoctor plugin. >>>>>>> >>>>>>> David Jencks >>>>>>> >>>>>>>> On Aug 21, 2020, at 3:18 PM, David Jencks <[email protected] >>> >>>>>>> wrote: >>>>>>>> >>>>>>>> Here are the repos and why they should be separate: >>>>>>>> >>>>>>>> aries-antora-site. This contains the content migrated from CMS. It >>>>>>> might be possible to migrate all of these into the repos that have >> the >>>>>>> related source code, but I don’t think that’s really appropriate for >>>>> stuff >>>>>>> about the community, board reports, etc. In any case that’s a step >>>> for >>>>>>> after the new web site is working. Generally this is what you’d >>>> modify >>>>>>> when working on documentation improvements. >>>>>>>> >>>>>>>> aries-antora. This contains the playbook. Antora works without a >>>>>>> checked out copy of the source .adocs, but the playbook does need to >>>> be >>>>>>> checked out. Therefore this needs to be a separate project. It’s >>>>> possible >>>>>>> to put this in with the sources, but it’s a bad idea IMO. Generally >>>>> this >>>>>>> is going to be modified only when a new subproject is added to the >>>>>>> documentation, or, if we decide on versioned documentation for some >>>>>>> components, possibly when a new version is published (although most >>>>> likely >>>>>>> this can be handled by wildcards). >>>>>>>> >>>>>>>> aries-antora-ui. The content here is almost all MPL2.0 licensed. I >>>>>>> checked on legal discuss, and the consensus was that it was fine to >>>> have >>>>>>> such content in an Apache repo as long as it never becomes part of a >>>>>>> release. In order to make the licensing more obvious, I think it’s >>>>>>> imperative to keep this in a separate repo that we can prominently >>>> label >>>>>>> “don’t release anything from this repo”. I think few people are >> going >>>>> to >>>>>>> work on this, and as it will change infrequently we’d save some build >>>>> time >>>>>>> and automation complexity by keeping it separate. >>>>>>>> >>>>>>>> aries-site-pub. This currently contains the CMS site history, and >> is >>>>>>> going to be where the new build process commits the site to publish >>>>> it. No >>>>>>> one should be modifying it by hand. >>>>>>>> >>>>>>>> David Jencks >>>>>>>> >>>>>>>>> On Aug 21, 2020, at 6:07 AM, Raymond Auge < >> [email protected] >>>>> .INVALID> >>>>>>> wrote: >>>>>>>>> >>>>>>>>> Personally, I would really appreciate only having to work with the >>>>> main >>>>>>>>> source repo and at most with the sub project repos. Having the site >>>>>>> tech in >>>>>>>>> multiple repos serves only to annoy me (and I feel anyone) that >>>> wants >>>>> to >>>>>>>>> provide quick fixes or just ramp up on updating docs due to a >> higher >>>>>>>>> barrier for testing. >>>>>>>>> >>>>>>>>> That's my opinion at least. I had assumed the multiple repos you >>>> used >>>>>>> David >>>>>>>>> were merely for testing (I also do understand the publish repo that >>>>>>> holds >>>>>>>>> the built site...) >>>>>>>>> >>>>>>>>> - Ray >>>>>>>>> >>>>>>>>> On Fri, Aug 21, 2020 at 3:05 AM Romain Manni-Bucau < >>>>>>> [email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Le ven. 21 août 2020 à 08:36, David Jencks < >>>> [email protected] >>>>>> >>>>>>> a >>>>>>>>>> écrit : >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Aug 20, 2020, at 11:17 PM, Romain Manni-Bucau < >>>>>>>>>> [email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Le ven. 21 août 2020 à 08:15, David Jencks < >>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]>> a >>>>>>>>>>>> écrit : >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Aug 17, 2020, at 10:43 PM, Romain Manni-Bucau < >>>>>>>>>>> [email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Le mar. 18 août 2020 à 02:24, David Jencks < >>>>>>> [email protected] >>>>>>>>>>> >>>>>>>>>>> a >>>>>>>>>>>>>> écrit : >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I’ve created 4 repos at Apache for this and started to move >>>> the >>>>>>>>>>> content >>>>>>>>>>>>> to >>>>>>>>>>>>>>> them. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Why 4? Dont we only need the build and publish ones if we put >>>>> docs >>>>>>> in >>>>>>>>>>>>> each >>>>>>>>>>>>>> code repo? Theme should probably stay with build one to avoid >>>> to >>>>>>> make >>>>>>>>>>> it >>>>>>>>>>>>>> complex since we couple them anyway. >>>>>>>>>>>>> >>>>>>>>>>>>> Well, I’ve had 3 all along, and the 4th is to publish to. I >>>> much >>>>>>>>>> prefer >>>>>>>>>>>>> keeping all the separate aspects in separate repos. >>>>>>>>>>>>> At the moment I’m waiting on infra for >>>>>>>>>>>>> https://issues.apache.org/jira/browse/INFRA-20724 < >>>>>>>>>>>>> https://issues.apache.org/jira/browse/INFRA-20724 < >>>>>>>>>>> https://issues.apache.org/jira/browse/INFRA-20724>>. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Any reason? It just adds complexity and slows down the build >>>>>>> (multiple >>>>>>>>>>> hits) >>>>>>>>>>> >>>>>>>>>>> If you’re building locally, the UI is downloaded when you run npm >>>> i >>>>>>> (or >>>>>>>>>>> preferably nom run clean-install). If they are in one repo, you >>>>> have >>>>>>> to >>>>>>>>>>> build the UI every time to be sure it’s up to date. If it’s >>>>>>> referenced >>>>>>>>>> in >>>>>>>>>>> an already built state, that’s much faster. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Not really, generally all frontend projects push the build state >> so >>>>> you >>>>>>>>>> just reference the built state and when you change it, rebuild it >>>>>>> locally >>>>>>>>>> and update the pushed state so this is not an issue IMHO. >>>>>>>>>> Issue is keep synchronizing repos for nothing or having to clone N >>>>>>> repo to >>>>>>>>>> work on the website locally. Any indirection increases the entry >>>> cost >>>>>>> ;). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> However, I find that keeping the UI, playbook, and sources in >>>>>>> different >>>>>>>>>>> repo helps keep my thinking more organized, which is far more >>>>>>> important >>>>>>>>>> to >>>>>>>>>>> me than slight time savings. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Source and build repo yes, but UI and playbook don't need to be >>>> split >>>>>>> at >>>>>>>>>> all and from experience, when it is not reusable - our case - it >> is >>>>>>> saner >>>>>>>>>> to keep them in the same repo so I think we should merge it. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> David Jencks >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> One repo, aries-site-pub, is for publishing the built site >>>> from. >>>>>>>>>>>>> Locally >>>>>>>>>>>>>>> I used svn2git to get the whole history of the published site >>>>> out >>>>>>> of >>>>>>>>>>>>> svn. >>>>>>>>>>>>>>> Infra doesn’t seem to recommend doing this, but I think it >>>> will >>>>> be >>>>>>>>>>>>>>> extremely handy to be able to see the history in one place >>>>> without >>>>>>>>>>>>> having >>>>>>>>>>>>>>> to deal with svn. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I’ve already realized that >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - there are a bunch of schemas to serve. These can go in an >>>>>>>>>>> attachments >>>>>>>>>>>>>>> directory. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> We have some per project so likely a folder per module or just >>>>>>>>>> specific >>>>>>>>>>>>>> links outside antora since we should never delete one, no? >>>>>>>>>>>>> >>>>>>>>>>>>> I realized I already put them in attachments, I just didn’t >> know >>>>>>> about >>>>>>>>>>> the >>>>>>>>>>>>> redirects. If we end up docs for blueprint, jpa, etc. in the >>>> repo >>>>>>> the >>>>>>>>>>> code >>>>>>>>>>>>> is in we can move the schemas too and have yet more redirects. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> - there’s an existing .htaccess file with a few redirects, and >>>> we >>>>>>>>>> need >>>>>>>>>>>>> one >>>>>>>>>>>>>>> that also shows the new location of every previously existing >>>>>>> page. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I’ll work on this… >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I’m most of the way to having a reasonable .htaccess. >>>>>>>>>>>>> >>>>>>>>>>>>>> Sounds great, we keep httpd right? >>>>>>>>>>>>> >>>>>>>>>>>>> I don’t think we have a choice about that :-) anyway I have no >>>>>>>>>> problems >>>>>>>>>>>>> with it… >>>>>>>>>>>>> >>>>>>>>>>>>>> Thans a lot David. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> David Jencks >>>>>>>>>>>>>> >>>>>>>>>>>>>>> David Jencks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Aug 14, 2020, at 9:54 AM, David Jencks < >>>>>>>>>> [email protected]> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I updated the feather to the current svg version, adjusted >>>> the >>>>>>>>>>> spacing >>>>>>>>>>>>> a >>>>>>>>>>>>>>> bit, and added some basic instructions to the UI project. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> David Jencks >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Aug 13, 2020, at 12:29 AM, Romain Manni-Bucau < >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Starts to look very good, some sizing and the feather to >>>>> change >>>>>>> to >>>>>>>>>>>>> have >>>>>>>>>>>>>>> a better quality and I think it is at least as good as the >>>>> website >>>>>>>>>> we >>>>>>>>>>>>> have >>>>>>>>>>>>>>> today. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog < >>>>>>>>>>>>>>> https://rmannibucau.metawerx.net/> | Old Blog < >>>>>>>>>>>>>>> http://rmannibucau.wordpress.com/> | Github < >>>>>>>>>>>>>>> https://github.com/rmannibucau> | LinkedIn < >>>>>>>>>>>>>>> https://www.linkedin.com/in/rmannibucau> | Book < >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>> >>>> >> https://www.packtpub.com/application-development/java-ee-8-high-performance >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Le mer. 12 août 2020 à 14:38, Andrew Wetmore < >>>>>>> [email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>> a écrit : >>>>>>>>>>>>>>>>> Hi, David! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Glad to know you are moving forward. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We need, for each project: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - a formal decision by the PMC approving the move and the >>>> tech >>>>>>>>>> you >>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>> moving to. >>>>>>>>>>>>>>>>> - a Jira ticket for INFRA so we have an audit trail on what >>>> we >>>>>>>>>> are >>>>>>>>>>>>>>> doing >>>>>>>>>>>>>>>>> and when. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thank you for pointing out Antora. I will add it to our >>>> list! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I will forward your other questions to our team, who are >>>> much >>>>>>> more >>>>>>>>>>>>>>>>> knowledgeable than I on the migration. Basically, whoever >>>>> picks >>>>>>> up >>>>>>>>>>>>> your >>>>>>>>>>>>>>>>> Jira ticket will facilitate the move. As far as I know, >>>>> keeping >>>>>>>>>>>>>>> repository >>>>>>>>>>>>>>>>> history is not a problem. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> A good way to contact me/us in near-real-time is to join >>>>>>> #asfinfra >>>>>>>>>>> on >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> ASF Slack channel (https://the-asf.slack.com/ < >>>>>>>>>>>>>>> https://the-asf.slack.com/>). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I am confident this will go pretty smoothly! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Andrew >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>> >>>> >> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail >>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>> >>>> >> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Virus-free. >>>>>>>>>>>>>>>>> www.avast.com <http://www.avast.com/> >>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>> >>>> >> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail >>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>> >>>> >> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Aug 12, 2020 at 2:44 AM David Jencks < >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Andrew, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I think I’m going to be setting up the new Aries website. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> We’re going to use Antora to build the site. I’m a bit >>>>>>> surprised >>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>> this tool isn’t on your list of common site builders, at >>>>> least >>>>>>>>>>> Camel >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> Isis use it. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I’m also going to be working to move TomEE off of CMS, >> that >>>>>>> site >>>>>>>>>> is >>>>>>>>>>>>>>> likely >>>>>>>>>>>>>>>>>> to be partly Antora and partly something else. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Something both projects are interested in is preserving >> the >>>>>>>>>> history >>>>>>>>>>>>>>> of the >>>>>>>>>>>>>>>>>> website. I think this could be done by running svn2git on >>>>> the >>>>>>>>>>>>>>> appropriate >>>>>>>>>>>>>>>>>> svn url, could you help figure out what that url would be? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> When are you generally available and what is a good way to >>>>>>>>>> contact >>>>>>>>>>>>>>> you for >>>>>>>>>>>>>>>>>> faster than email questions? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>> David Jencks >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Aug 4, 2020, at 6:33 AM, Andrew Wetmore< >>>>> [email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I am part of the Infrastructure team, and am writing to >>>> ask >>>>>>>>>>> whether >>>>>>>>>>>>>>> your >>>>>>>>>>>>>>>>>>> project is still using the Apache CMS for your project >>>>>>> website. >>>>>>>>>> As >>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>>>> know, the CMS is reaching end-of-life, and we need >>>> projects >>>>> to >>>>>>>>>>> move >>>>>>>>>>>>>>> their >>>>>>>>>>>>>>>>>>> websites onto a different option within the next few >>>> weeks. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> There are several alternatives available, including those >>>>>>> listed >>>>>>>>>>> on >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>> page [1] on managing project websites. Infra is >>>> assembling a >>>>>>>>>> Wiki >>>>>>>>>>>>>>> page >>>>>>>>>>>>>>>>>> [2] >>>>>>>>>>>>>>>>>>> on migrating a website from the CMS, and is looking >>>> forward >>>>> to >>>>>>>>>>>>>>> helping >>>>>>>>>>>>>>>>>>> projects with this transition. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Please let me know whether your site is still on the >>>> Apache >>>>>>> CMS >>>>>>>>>>>>>>> and, if >>>>>>>>>>>>>>>>>> so, >>>>>>>>>>>>>>>>>>> who will be the project point-of-contact with Infra for >>>> the >>>>>>>>>>>>>>> migration. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thank you! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> [1] https://infra.apache.org/project-site.html < >>>>>>>>>>>>>>> https://infra.apache.org/project-site.html> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> [2] >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>> >>>> >> https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS >>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>> >>>> >> https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Andrew Wetmore >>>>>>>>>>>>>>>>>>> Technical Writer-Editor >>>>>>>>>>>>>>>>>>> Infra >>>>>>>>>>>>>>>>>>> *Apache Software Foundation* >>>>>>>>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>> >>>> >> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail >>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>> >>>> >> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Virus-free. >>>>>>>>>>>>>>>>>>> www.avast.com <http://www.avast.com/> >>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>> >>>> >> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail >>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>> >>>> >> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Andrew Wetmore >>>>>>>>>>>>>>>>> Technical Writer-Editor >>>>>>>>>>>>>>>>> Infra >>>>>>>>>>>>>>>>> *Apache Software Foundation* >>>>>>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>>>>>>> (@rotty3000) >>>>>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >>>>>>>>> (@Liferay) >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>
