I think this is a really really bad idea and will try to explain why later…. I did’t want it to seem like I was ignoring this since I replied to my previous message.
I would like to know why you don’t like redirect rules; AFAICT they are universally used for site updates. Maybe you can convince me I’m wrong :-) Thanks! David Jencks > On Aug 25, 2020, at 11:33 PM, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > Hmm, I think it is ok to have a fully new structure and just keep all old > pages (by just pasting them in the pubsub dir but no more synchronizing > them). > An option which is not bad and probably saner than redirects is to inject > in all old pages a div.alert block saying "page moved to <a>". > This enables to avoid a silent redirect which can not be what is expected > and still gives enough data for the user to know where he is exactly. > It is a bit like the banners we can see on doc with versioning "this is not > the latest version, here is new the <a>" but more in a backward > compatibility goal. > More will have redirect rules, more it will hurt IMHO so let's try to not > get any ;). > > 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. 26 août 2020 à 01:13, David Jencks <david.a.jen...@gmail.com> a > écrit : > >> I requested an aries-sitepub mailing list and then realized how redundant >> the name is. Now I’ve requested site-...@aries.apache.org, 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 <rmannibu...@gmail.com> >> wrote: >>> >>> Le dim. 23 août 2020 à 20:26, David Jencks <david.a.jen...@gmail.com> 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 <rmannibu...@gmail.com >>> >>>> wrote: >>>>> >>>>> With Ray on that. >>>>> >>>>> Le dim. 23 août 2020 à 15:11, Raymond Auge <raymond.a...@liferay.com >>>> .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, < >>>> david.a.jen...@gmail.com> >>>>>>> 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 >>>>>>> comm...@aries.apache.org are fine or agree to set up another list. >>>>>>> >>>>>>> David Jencks >>>>>>> >>>>>>>> On Aug 21, 2020, at 11:18 PM, Romain Manni-Bucau < >>>>>> rmannibu...@gmail.com> >>>>>>> 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 < >> david.a.jen...@gmail.com> >>>>>> 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 < >> david.a.jen...@gmail.com >>>>> >>>>>>>>> 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 < >>>> raymond.a...@liferay.com >>>>>>> .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 < >>>>>>>>> rmannibu...@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Le ven. 21 août 2020 à 08:36, David Jencks < >>>>>> david.a.jen...@gmail.com >>>>>>>> >>>>>>>>> a >>>>>>>>>>>> écrit : >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Aug 20, 2020, at 11:17 PM, Romain Manni-Bucau < >>>>>>>>>>>> rmannibu...@gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Le ven. 21 août 2020 à 08:15, David Jencks < >>>>>>> david.a.jen...@gmail.com >>>>>>>>>>>>> <mailto:david.a.jen...@gmail.com>> a >>>>>>>>>>>>>> écrit : >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Aug 17, 2020, at 10:43 PM, Romain Manni-Bucau < >>>>>>>>>>>>> rmannibu...@gmail.com> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Le mar. 18 août 2020 à 02:24, David Jencks < >>>>>>>>> david.a.jen...@gmail.com >>>>>>>>>>>>> >>>>>>>>>>>>> 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 < >>>>>>>>>>>> david.a.jen...@gmail.com> >>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>> rmannibu...@gmail.com >>>>>>>>>>>>>>>>> <mailto:rmannibu...@gmail.com>> 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 < >>>>>>>>> andr...@apache.org >>>>>>>>>>>>>>>>> <mailto:andr...@apache.org>> 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 < >>>>>>>>>>>>>>> david.a.jen...@gmail.com >>>>>>>>>>>>>>>>> <mailto:david.a.jen...@gmail.com>> >>>>>>>>>>>>>>>>>>> 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< >>>>>>> andr...@apache.org >>>>>>>>>>>>>>>>> <mailto:andr...@apache.org>> 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* >>>>>>>>>>>>>>>>>>>>> andr...@apache.org <mailto:andr...@apache.org> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >> 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* >>>>>>>>>>>>>>>>>>> andr...@apache.org <mailto:andr...@apache.org> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>>>>>>>>> (@rotty3000) >>>>>>>>>>> Senior Software Architect *Liferay, Inc.* < >> http://www.liferay.com> >>>>>>>>>>> (@Liferay) >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >> >>
