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 Fri, 21 Aug 2020 22:18:34 GMT
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