Oh ok. Ill not fight on this one. Just think it is better to not use redirect and got some successes not using them compared to using them in ($) work but not a blocker, just a proposal/feedack.
Le mer. 2 sept. 2020 à 16:53, David Jencks <[email protected]> a écrit : > I think I wasn’t clear about which issue I was talking about. I was > talking about whether we have an .htaccess file with redirects for all the > old page locations (what I want) or keep the old pages in their old > locations, with no visible means of having generated them (which is my > understanding of what you want, and which I haven’t seen anyone else > support). > > I haven’t figured out how to do it yet, and don’t think it’s time yet, but > I have no problem in principle with moving most or all of the content into > the main git repository from what is now aries-antora-site. > > Thanks, > David Jencks > > > On Sep 1, 2020, at 11:06 PM, Romain Manni-Bucau <[email protected]> > wrote: > > > > Le mar. 1 sept. 2020 à 19:28, David Jencks <[email protected]> a > > écrit : > > > >> Romain, > >> > >> This issue is keeping me from wanting to work more on the site. I > >> attempted a survey on antora/users gitter channel and only got one > >> response, which agreed with my position. Can you find any outside > opinion > >> that supports your position? > >> > > > > We are at least two on three participating in aries and already agreed > with > > outside people on such arch in other companies (past colleagues) so yes. > > > > Once again, only reason to split - all other concerns have simple > solutions > > - is reusability and we will not do it by design. > > > > > >> I’m not interested in working on a site with your proposed solution. > >> Since you are more likely than I to participate in the future to > evolving > >> the site, I suggest that we proceed by me setting up redirects (already > >> done in the preview), getting the site deployed, organizing things a > bit, > >> and when I’ve run out of things to do you can, if the community agrees, > put > >> in place your proposal. Otherwise, I can stop now. > >> > > > > Have to admit i fail to see what you dislike. It is technically exactly > the > > same proposal except in terms of storage and i dont think you abandon > for a > > "mv". Maybe Im missing sthg key :s. > > > > > >> Thoughts? > >> > >> David Jencks > >> > >>> On Aug 27, 2020, at 10:43 PM, Romain Manni-Bucau < > [email protected]> > >> wrote: > >>> > >>> Le jeu. 27 août 2020 à 23:30, David Jencks <[email protected] > >> <mailto:[email protected]>> a > >>> écrit : > >>> > >>>> > >>>> > >>>>> On Aug 26, 2020, at 11:01 PM, Romain Manni-Bucau < > >> [email protected]> > >>>> wrote: > >>>>> > >>>>> Le jeu. 27 août 2020 à 00:22, David Jencks <[email protected] > > > >> a > >>>>> écrit : > >>>>> > >>>>>> 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 > >>>> :-) > >>>>>> > >>>>> > >>>>> Because > >>>>> > >>>>> 1. You must maintain them if you change anything (and we will forget > >>>> about > >>>>> them for sure very very quickly and link validation is not enough to > >>>> fully > >>>>> validate it - and to add a more "personal" note: it hurts lol) > >>>> > >>>> Possibly we don’t need to maintain it. I have it set up to work now, > >>>> AFAICT, with all content from the old site and the current new > >> locations. > >>>> Since Antora supports multiple versions of each component very well, > one > >>>> possibility is to copy the current content to a branch/version called > >>>> ‘legacy’ and have .htaccess point there. All subsequent changes can > be > >> on > >>>> ‘master’ version (or whatever we decide). Then links to the old > website > >>>> will go to the new location of the old version of the page, and > updates > >> are > >>>> accessible through the version selector. > >>>> > >>>> IMO with a simple tool maintaining .htaccess is not that unpleasant. > I > >>>> wrote it for camel and after a little updating it worked here too. > >>>> Admittedly I don’t know of a way to test it thoroughly, but it > certainly > >>>> redirects all the existing website addresses. > >>>> > >>> > >>> -1, content is there to not break existing links but not as something > >> which > >>> must be accessible. > >>> Integrating in antora will make it slower and accessible whereas it is > >> not > >>> intented at all. > >>> > >>> > >>> > >>>>> 2. Cause we dont need it at all > >>>> > >>>> I totally disagree… see below > >>>> > >>> > >>> Hmm, i can say the same I guess ;) > >>> > >>> > >>>> > >>>>> Keep in mind we speak of a static website so can keep static > resources > >>>>> around without any issue and we dont conflict with antora namind - > >> except > >>>>> main index, so no need to stack layers and increase maintenance cost > >> for > >>>> no > >>>>> gain IMHO. > >>>> > >>>> I have two main objections to this point of view. > >>>> > >>>> 1. I think you used this strategy on the current TomEE website, > leaving > >>>> the old CMS content in place but not very accessible and adding new > >> JBake > >>>> generated content that was mostly a copy (or 3 copies, I don’t know if > >> you > >>>> did that part). When I discovered the old content my reaction was > >> something > >>>> like ‘AAAAAARGH! Are these guys amateurs or what? Can’t they maintain > >> their > >>>> website? Why are there 2 totally unrelated styles???? I don’t trust > >>>> anything about this project! I’m running away!’ In other words, I > think > >>>> that it’s essential for users to see everything on the site accessible > >>>> through one unified mechanism and displayed consistently. > >>>> > >>> > >>> TomEE was a different story. > >>> Old website was intended to be dead cause it was already outdated, > wrong > >> - > >>> from multiple migrations, and inconsistent. > >>> As discussed on the list we agreed to not maintain it and just move to > >> the > >>> new website. We kept it around for a kind of testing peruod. > >>> After some time and some good feedbacks, a missing page made a lot of > >> noise > >>> to reactivate the whole old website, current status is most links are > >>> broken and content is fully broken (mainly css last time i checked). > >>> But once again, the old website was intended to drop, otherwise you > dont > >>> need to change anything or use antora IMHO. > >>> > >>> > >>> > >>>> 2. For anyone to be comfortable maintaining the website I think that a > >>>> dead-simple single process that generates all the content is > essential. > >>>> Keeping some files in aries-site-pub between generations violates this > >>>> principle and is apt to lead to situations such as the pages at TomEE > >> that > >>>> appear to have been accidentally deployed by someone at the wrong > >> address > >>>> and just left there. Otherwise it’s like building a jar with maven > and > >>>> keeping all the old classes that got renamed and are no longer in > >> source. > >>>> > >>> > >>> As mentionned, TomEE situation was intended, only missing step was the > >>> mentionned injection of "this page is legacy" banner. Bringing these > not > >>> maintained pages - this is what it is, dont make it fakely maintained, > to > >>> the new theme is more confusing cause it looks up to date. > >>> > >>> Good example, this is what we discussed, just add to your metaphore > that > >>> you put @Deprecated on all the old packages/classes. > >>> > >>> > >>>> Thanks, > >>>> David Jencks > >>>>> > >>>>> > >>>>> > >>>>>> Thanks! > >>>>>> David Jencks > >>>>>> > >>>>>>> On Aug 25, 2020, at 11:33 PM, Romain Manni-Bucau < > >>>> [email protected]> > >>>>>> 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 < > [email protected] > >>> > >>>> a > >>>>>>> écrit : > >>>>>>> > >>>>>>>> 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) > >> > >> > > >
