aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david.a.jen...@gmail.com>
Subject Re: The project website
Date Wed, 26 Aug 2020 22:19:23 GMT
I’ve succeeded in setting up an .asf.yaml file so that the new site is previewed at https://aries-beta.staged.apache.org.  At the moment I'm building locally using a script, so perhaps the next step is to figure out how to use buildbot or jenkins.

To build the site and stage it, in the aries-antora project run ./build-publish.sh.

Sorry for the commit email to commits@aries.apache.org when I moved from the CMS site to the Antora site: I didn’t understand that I had set up .asf.yaml incorrectly.

David Jencks

> On Aug 25, 2020, at 4:13 PM, David Jencks <david.a.jencks@gmail.com> wrote:
> 
> I requested an aries-sitepub mailing list and then realized how redundant the name is. Now I’ve requested site-pub@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 <rmannibucau@gmail.com> wrote:
>> 
>> Le dim. 23 août 2020 à 20:26, David Jencks <david.a.jencks@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 <rmannibucau@gmail.com>
>>> wrote:
>>>> 
>>>> With Ray on that.
>>>> 
>>>> Le dim. 23 août 2020 à 15:11, Raymond Auge <raymond.auge@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.jencks@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
>>>>>> commits@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 <
>>>>> rmannibucau@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.jencks@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.jencks@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.auge@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 <
>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Le ven. 21 août 2020 à 08:36, David Jencks <
>>>>> david.a.jencks@gmail.com
>>>>>>> 
>>>>>>>> a
>>>>>>>>>>> écrit :
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Aug 20, 2020, at 11:17 PM, Romain Manni-Bucau <
>>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Le ven. 21 août 2020 à 08:15, David Jencks <
>>>>>> david.a.jencks@gmail.com
>>>>>>>>>>>> <mailto:david.a.jencks@gmail.com>> a
>>>>>>>>>>>>> écrit :
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Aug 17, 2020, at 10:43 PM, Romain Manni-Bucau <
>>>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Le mar. 18 août 2020 à 02:24, David Jencks <
>>>>>>>> david.a.jencks@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.jencks@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 <
>>>>>>>>>>>>>> rmannibucau@gmail.com
>>>>>>>>>>>>>>>> <mailto:rmannibucau@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 <
>>>>>>>> andreww@apache.org
>>>>>>>>>>>>>>>> <mailto:andreww@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.jencks@gmail.com
>>>>>>>>>>>>>>>> <mailto:david.a.jencks@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<
>>>>>> andreww@apache.org
>>>>>>>>>>>>>>>> <mailto:andreww@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*
>>>>>>>>>>>>>>>>>>>> andreww@apache.org <mailto:andreww@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*
>>>>>>>>>>>>>>>>>> andreww@apache.org <mailto:andreww@apache.org>
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>> (@rotty3000)
>>>>>>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>>>>>>>>> (@Liferay)
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>> 
> 


Mime
View raw message