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:22:14 GMT
I think this is a really really bad idea and will try to explain why later…. I did’t want it to seem like I was ignoring this since I replied to my previous message.

I would like to know why you don’t like redirect rules; AFAICT they are universally used for site updates.  Maybe you can convince me I’m wrong :-)

Thanks!
David Jencks

> On Aug 25, 2020, at 11:33 PM, Romain Manni-Bucau <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