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, 02 Sep 2020 14:53:41 GMT
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 <rmannibucau@gmail.com> wrote:
> 
> Le mar. 1 sept. 2020 à 19:28, David Jencks <david.a.jencks@gmail.com> 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 <rmannibucau@gmail.com>
>> wrote:
>>> 
>>> Le jeu. 27 août 2020 à 23:30, David Jencks <david.a.jencks@gmail.com
>> <mailto:david.a.jencks@gmail.com>> a
>>> écrit :
>>> 
>>>> 
>>>> 
>>>>> On Aug 26, 2020, at 11:01 PM, Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>>>> wrote:
>>>>> 
>>>>> Le jeu. 27 août 2020 à 00:22, David Jencks <david.a.jencks@gmail.com>
>> 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 <
>>>> rmannibucau@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.jencks@gmail.com
>>> 
>>>> a
>>>>>>> écrit :
>>>>>>> 
>>>>>>>> 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