Site is back up now.
On Wed, 10 Jul 2024 at 10:23, Robbie Gemmell wrote:
>
> There is an issue with various projects websites just now, it is being
> investigated.
>
> On Wed, 10 Jul 2024 at 09:55, Lionel Cons wrote:
> >
> > I've tried from several hosts and I get a 404 each time...
> >
> > $ wg
There is an issue with various projects websites just now, it is being
investigated.
On Wed, 10 Jul 2024 at 09:55, Lionel Cons wrote:
>
> I've tried from several hosts and I get a 404 each time...
>
> $ wget https://activemq.apache.org/
> --2024-07-10 10:52:31-- https://activemq.apache.org/
> Re
I've tried from several hosts and I get a 404 each time...
$ wget https://activemq.apache.org/
--2024-07-10 10:52:31-- https://activemq.apache.org/
Resolving activemq.apache.org (activemq.apache.org)... 2a04:4e42::644,
151.101.2.132
Connecting to activemq.apache.org (activemq.apache.org)|2a04:4e
on this more general, i.e also applying to the
> 5.x 'latest' (typically stale) javadocs on the website as well, rather
> than just the per-release Artemis javadocs this thread started about?
>
> If so it would seem to me that all the people who regularly update the
> websit
JB, are your thoughts on this more general, i.e also applying to the
5.x 'latest' (typically stale) javadocs on the website as well, rather
than just the per-release Artemis javadocs this thread started about?
If so it would seem to me that all the people who regularly update the
websit
+1
I've never used the javadocs on the website and as Robbie said it makes
building the site incredibly slow so testing changes locally is really painful.
At the very least, it would be great to host them separately outside of the
Jekyll website.
- Lucas
On 2022-09-29, 12:11 PM,
Hi Clebert,
I'm +1 about this for the two reasons:
1. I don't think lot of people read the Javadoc on website (personally
I'm reading directly in the IDE)
2. We can still have the javadoc jar published on Maven (not need to
update website)
Regards
JB
On Wed, Sep 28, 2022 at
r added).
>
>
> Justin
>
> On Wed, Sep 28, 2022 at 11:18 AM Clebert Suconic
> wrote:
>
>> Can we stop publishing javadocs on the ActiveMQ Website for artemis?
>>
>> I see no point on publishing it as they are available in Maven.
>>
>> My
ng
smarter like only publish it when something changes (e.g. methods are
deprecated or added).
Justin
On Wed, Sep 28, 2022 at 11:18 AM Clebert Suconic
wrote:
> Can we stop publishing javadocs on the ActiveMQ Website for artemis?
>
> I see no point on publishing it as they are availabl
maintain the publishing, I would reconsider for
> > sure my stance, but as it stands, think it's pretty useful, and when my org
> > isn't rate-limited on the apache website, I use them :'-)
> >
> > --
> > Étienne
> >
> > On Wed, 28 Sep 2022,
ure my stance, but as it stands, think it's pretty useful, and when my org
> isn't rate-limited on the apache website, I use them :'-)
>
It slows down building the site no end, publishing the site somewhat,
uses a chunk of space, and adds a step to doing the release updates.
Th
t's a lot of effort to maintain the publishing, I would reconsider for
> sure my stance, but as it stands, think it's pretty useful, and when my org
> isn't rate-limited on the apache website, I use them :'-)
>
> --
> Étienne
>
> On Wed, 28 Sep 2022, at 9:1
l in all I dont see a great need for the javadoc to be on the
website these days, so I'd be fine with it not being there, +1
On Wed, 28 Sept 2022 at 17:13, Clebert Suconic
wrote:
>
> Can we stop publishing javadocs on the ActiveMQ Website for artemis?
>
> I see no point on publishi
ource code even more.
If it's a lot of effort to maintain the publishing, I would reconsider for sure
my stance, but as it stands, think it's pretty useful, and when my org isn't
rate-limited on the apache website, I use them :'-)
--
Étienne
On Wed, 28 Sep 2022, at 9:12
Can we stop publishing javadocs on the ActiveMQ Website for artemis?
I see no point on publishing it as they are available in Maven.
My vote is to completely remove it.
So, if you agree with me, please respond with
+1 Yes, stop publishing javadocs for ActiveMQ Artemis on the website
and keep
gt;> I'll go ask about it now, though there's possibly noone around just yet.
> >>
> >> On Thu, 1 Sept 2022 at 07:50, Emmanuel Hugonnet
> >> wrote:
> >>
> >>> There is nothing at
> >>>
> >>> https://github.com/apac
perhaps, so infra
>> would be the folks to ask on JIRA or slack:
>> https://infra.apache.org/contact.html
>>
>> I'll go ask about it now, though there's possibly noone around just yet.
>>
>> On Thu, 1 Sept 2022 at 07:50, Emmanuel Hugonnet
>> wrot
mmanuel Hugonnet
> wrote:
>
>> There is nothing at
>>
>> https://github.com/apache/activemq-website/tree/asf-site/output/components/artemis/download/commit-report-2.25.0.html
>> Looks like the CI which is supposed to build the site didn't run properly.
>>
27;ll go ask about it now, though there's possibly noone around just yet.
On Thu, 1 Sept 2022 at 07:50, Emmanuel Hugonnet wrote:
> There is nothing at
>
> https://github.com/apache/activemq-website/tree/asf-site/output/components/artemis/download/commit-report-2.25.0.html
> Look
There is nothing at
https://github.com/apache/activemq-website/tree/asf-site/output/components/artemis/download/commit-report-2.25.0.html
Looks like the CI which is supposed to build the site didn't run properly.
Emmanuel
Le 01/09/2022 à 01:34, Clebert Suconic a écrit :
Does anyone know w
Does anyone know what's going on?
the commit report 2.25.0 is committed at:
https://github.com/apache/activemq-website/blob/main/src/components/artemis/download/commit-report-2.25.0.html
However, it's not showing as:
https://activemq.apache.org/components/artemis/download/commit-rep
Thanks for your input on #asfinfra, it's now clearer to me.
I reverted my change and fix in the Karaf website.
Regards
JB
On Wed, Mar 30, 2022 at 11:29 AM Robbie Gemmell
wrote:
>
> The other download pages you linked actually are using the redirect
> script, in the template m
;
> > > Agree, infra guys are pretty clear (at least Daniel and Chris were
> > > very clear), but I guess other guys are not "up to date" ;)
> > >
> > > Quick extract from the chat I had with them on Slack:
> > >
> > > fluxo
FYI, I just asked the question straight (between dlcdn or closer.cgi
preferred use) on #asfinfra. I will update the projects website
accordingly.
Thanks,
Regards
JB
On Wed, Mar 30, 2022 at 11:19 AM Jean-Baptiste Onofré wrote:
>
> Why other Apache projects are using dlcdn directl
ight even say it is, in fact, [preferred]
> > Humbedooh 20 h 39
> > download.apache.org is backup OR for sigs/checksums
> >
> > So, it's what I said: dlcdn is the preferred download system for
> > artifacts, and keep download for sign/hash.
> >
> > I wi
d with them on Slack:
>
> fluxo 20 h 38
> you might even say it is, in fact, [preferred]
> Humbedooh 20 h 39
> download.apache.org is backup OR for sigs/checksums
>
> So, it's what I said: dlcdn is the preferred download system for
> artifacts, and keep download for s
backup OR for sigs/checksums
So, it's what I said: dlcdn is the preferred download system for
artifacts, and keep download for sign/hash.
I will update the website accordingly.
Regards
JB
On Wed, Mar 30, 2022 at 10:41 AM Robbie Gemmell
wrote:
>
> They must have changed their stance
o use for artifact download
> 2. They confirm the webpage Robbie linked is not up to date. I talked with
> Andrew Wetmore (author of this page). He didn’t know dlcdn : he will update
> the page with my help.
>
> So, according to this update, I will do a new pass on ActiveMQ website to
.
So, according to this update, I will do a new pass on ActiveMQ website to
use dlcdn where it makes sense and fix signature / hash links.
Regards
JB
Le mar. 29 mars 2022 à 18:17, Robbie Gemmell a
écrit :
> This seems wrong, I think this should be reverted.
>
> We are still asked t
No, it's correct.
Almost all Apache projects use dlcdn for the binary artifacts (I think
the page you are referencing is not up to date for artifacts). For
instance:
https://maven.apache.org/download.cgi
https://tomcat.apache.org/download-10.cgi
etc
However, checksum and signature should go via
This seems wrong, I think this should be reverted.
We are still asked to use the redirect scripts so that infra can
manage resources as needed, and are meant to link to
downloads.apache.org for checksums as the page did.
https://infra.apache.org/release-download-pages.html
The old links also redi
d mailing list
> discussions. However, it's not clear to everyone (especially outside
> contributors) that this is what should happen, and it's not consistent with
> the rest of the project components.
>
> History indicates that regardless of whether or not someone *should* cre
he rest of the project components.
History indicates that regardless of whether or not someone *should* create
a Jira for the website, they will. This isn't surprising because it's
natural to track such issues in Jira as that's exactly what it is for. This
is especially true for fol
Agree w/ Robbie. A JIRA Project for website changes is overkill. At this rate,
the "How do I contribute to ActiveMQ?" README is going to need page breaks ;-)
Having spent considerable time working on the AMQ backlog, I think less things
is better. Of the 9 current JIRA projects, ov
27;ve dealt with both cases even in the same
project, for me having the independent JIRA projects is definitely
nicer)
I think in that regard if people believe we need JIRAs for the website
then having its own project would be the way to go. That said, I dont
personally think the site really needs
fe.
>
>
>
> I think it would be simpler and more consistent for project contributors if
> we had a new Jira project specifically for the website. Currently issues
> for the website are opened in the AMQ [1] Jira project that's dedicated to
> the "Classic" broker. E
Jira project specifically for the website. Currently issues
for the website are opened in the AMQ [1] Jira project that's dedicated to
the "Classic" broker. Each project component has its own Jira project [2]
so it seems reasonable that the website would as well.
To be clear, ActiveMQ
I think it would be simpler and more consistent for project contributors if
we had a new Jira project specifically for the website. Currently issues
for the website are opened in the AMQ [1] Jira project that's dedicated to
the "Classic" broker. Each project component has its own
Jean-Baptiste Onofré
> > wrote:
> >
> > > Justin already merged the PR, so I guess we are good ;)
> > >
> > > Thanks !
> > >
> > > Regards
> > > JB
> > >
> > > On 13/08/2021 16:48, Jean-Baptiste Onofré wrote:
> &
n already merged the PR, so I guess we are good ;)
> >
> > Thanks !
> >
> > Regards
> > JB
> >
> > On 13/08/2021 16:48, Jean-Baptiste Onofré wrote:
> > > Hi guys,
> > >
> > > I created pull request
> > > https://github.com
, 2021 at 8:51 AM Jean-Baptiste Onofré
wrote:
> Justin already merged the PR, so I guess we are good ;)
>
> Thanks !
>
> Regards
> JB
>
> On 13/08/2021 16:48, Jean-Baptiste Onofré wrote:
> > Hi guys,
> >
> > I created pull request
> > https://github.c
Justin already merged the PR, so I guess we are good ;)
Thanks !
Regards
JB
On 13/08/2021 16:48, Jean-Baptiste Onofré wrote:
Hi guys,
I created pull request
https://github.com/apache/activemq-website/pull/56 on website to remove
the nabble link from the contact page.
Since nabble
Hi guys,
I created pull request
https://github.com/apache/activemq-website/pull/56 on website to remove
the nabble link from the contact page.
Since nabble downgraded their servers capacity, a bunch of forums linked
to mailing list are not available anymore. It's the case for se
here are points of difference, the examples are the place to
> demonstrate and document such that users community can easily evaluate
> for them selves.
>
> On Tue, 23 Mar 2021 at 04:59, Jean-Baptiste Onofre
> wrote:
> >
> > Hi Art,
> >
> > Your point about a
rdinates
> as they are today, and focus "naming" for website mainly.
> But you are right, the artifacts can be confusing for users.
> So, if we decide to rename, artifacts worth a rename as well.
>
> About website, I like your idea, especially for new users, providing
> &
Hi Art,
Your point about artifacts makes lot of sense.
To limit the impacts, my first thought was to keep the artifacts coordinates as
they are today, and focus "naming" for website mainly.
But you are right, the artifacts can be confusing for users.
So, if we decide to rename, artif
x27;s not a unique problem to AMQ; for example, I still have to
pause and think, "is it group-id commons-io, or org.apache.commons"?
One idea of a small change to the website landing page that could help (as
an additional consideration, not a replacement for renaming) - have a link
with
are in two different repos, and we have some gaps,
>> I think it could be "confusing" for our users.
>>
>> That was exactly my point when I started the thread: I see users lot in
>> naming, versioning.
>> I think that maybe the mistake was to keep Acti
users.
>>
>> That was exactly my point when I started the thread: I see users lot in
>> naming, versioning.
>> I think that maybe the mistake was to keep ActiveMQ "branding" for 5.x,
>> and have Artemis at same time.
>>
>> Anyway, it’s mostly a comm
version is not super clean
for users (for us, it’s a not a problem because we are involved in the project,
but think about "external" users).
If we go with naming change for "Classic" (or whatever name), I’m really to
tackle the effort (it can be done in two steps, website/docu
ould be "confusing" for our users.
>
> That was exactly my point when I started the thread: I see users lot in
> naming, versioning.
> I think that maybe the mistake was to keep ActiveMQ "branding" for 5.x,
> and have Artemis at same time.
>
> Anyway, it’s m
s behind it), so renaming could lead to a lot of changes -
for example, renaming the artifacts could be desirable.
Changing the designation on the website landing page seems like a good idea
to me - it's a "shallow" operation (shallow meaning only 1 layer of thing
to change). Hence
in naming,
versioning.
I think that maybe the mistake was to keep ActiveMQ "branding" for 5.x, and
have Artemis at same time.
Anyway, it’s mostly a communication and website point.
I think (even if I don’t like "Classic" name ;)) we can keep Artemis and
Classic, but clearly separa
t; Hi guys,
>
> It seems we lost the initial intend of this thread.
>
> The two initial questions on this thread were:
>
> 1. Can we give a more clear "tag name" than "classic", and also being able
> to use different versioning than just 5.
> 2. Refactori
Hi guys,
It seems we lost the initial intend of this thread.
The two initial questions on this thread were:
1. Can we give a more clear "tag name" than "classic", and also being able to
use different versioning than just 5.
2. Refactoring just the activemq "cla
ctiveMQ Community.
> For instance, 2 ActiveMQ committers who have been more committers on
> Artemis codebase more than anything dedicated a lot of their time into
> the website update.
>
> That was Martyn Talylor (who is actually the author of the new Logo),
> and Mike Pearce...
gt;> guess
> > >>>> maybe if you want to keep the branding)
> > >>>>
> > >>>> On Fri, Mar 19, 2021 at 10:57 AM Jean-Baptiste Onofre <
> j...@nanthrax.net
> > >>> <mailto:j...@nanthrax.net>>
> > >>>
> > broker is because we have not been selling/messaging it this way to the
> > user community. In the six years since HornetQ was donated, we have not
> > published any plans for the community (i.e., on the website) describing
> the
> > intended plan. I think this is due t
ty.
For instance, 2 ActiveMQ committers who have been more committers on
Artemis codebase more than anything dedicated a lot of their time into
the website update.
That was Martyn Talylor (who is actually the author of the new Logo),
and Mike Pearce...
I know both of them used a lot of non billable hours
; PMC members would prefer on the ActiveMQ "umbrella".
>>
>> Anyway, I give up on this thread, agree with Gary: let’s keep colocation
>> on the ActiveMQ "umbrella". We will see what our users will do.
>>
>> I will still maintain and work on
ctiveMQ "umbrella". We will see what our users will do.
>
> I will still maintain and work on ActiveMQ, heading to new features and
> releases. I will request some helps for website refactoring/cleanup.
>
> Regards
> JB
>
> > Le 19 mars 2021 à 21:21, Gary Tully
ead, agree with Gary: let’s keep colocation on the
ActiveMQ "umbrella". We will see what our users will do.
I will still maintain and work on ActiveMQ, heading to new features and
releases. I will request some helps for website refactoring/cleanup.
Regards
JB
> Le 19 mars 2021 à 21:
e six years since HornetQ was donated, we have not
> published any plans for the community (i.e., on the website) describing the
> intended plan. I think this is due to the fact that most folks were focused
> on Artemis development and working on moving toward feature parity with
> ActiveMQ
t; >>> don’t
> >>>>> want to "block" ActiveMQ to do a 6, 7, 8 or whatever release).
> >>>>>
> >>>>> Sorry, but classic is something I don’t fully understand (maybe my
> >>> French
> >>>>> culture
mis as the next gen
broker is because we have not been selling/messaging it this way to the
user community. In the six years since HornetQ was donated, we have not
published any plans for the community (i.e., on the website) describing the
intended plan. I think this is due to the fact that most
not believe this will ever happen without significant push
> back
> >>>>> from
> >>>>>>> the members of the community that do not want this to happen.
> >>>>>>>
> >>>>>>> Over the past couple of years my
>>>>>>> between developers and users so why not just make Artemis its own TLP?
>>>>> I
>>>>>>> really see no benefit of operating under the same umbrella anymore (I
>>>>>> guess
>>>>>>> maybe if
umbrella anymore (I
>>>>> guess
>>>>>> maybe if you want to keep the branding)
>>>>>>
>>>>>> On Fri, Mar 19, 2021 at 10:57 AM Jean-Baptiste Onofre <
>> j...@nanthrax.net
>>>>> <mailto:j...@nanthrax.net>>
&g
gt;>> don’t
> >>>>> want to "block" ActiveMQ to do a 6, 7, 8 or whatever release).
> >>>>>
> >>>>> Sorry, but classic is something I don’t fully understand (maybe my
> >>> French
> >>>>> culture ;)
;>>>> Sorry, but classic is something I don’t fully understand (maybe my
>>> French
>>>>> culture ;)). I don’t see what’s "classic" (or maybe in term of
>>> "previous"
>>>>> or "older") is. Maybe "vintage"
erm of
> > "previous"
> > >> or "older") is. Maybe "vintage" (like classical music compare to house
> > >> music) ;) ?
> > >>
> > >> And, anyway, nobody is using "classic": for the users I know, they use
>
;>>> culture ;)). I don’t see what’s "classic" (or maybe in term of
>>> "previous"
>>>>> or "older") is. Maybe "vintage" (like classical music compare to house
>>>>> music) ;) ?
>>>>>
>>>>
ssic" (or maybe in term of
>> "previous"
>>>> or "older") is. Maybe "vintage" (like classical music compare to house
>>>> music) ;) ?
>>>>
>>>> And, anyway, nobody is using "classic": for the users I know, the
; or "older") is. Maybe "vintage" (like classical music compare to house
> > >> music) ;) ?
> > >>
> > >> And, anyway, nobody is using "classic": for the users I know, they use
> > >> ActiveMQ and Artemis (not ActiveMQ Clas
gt; >>
> >> So, if you agree to have:
> >>
> >> http://activemq.apache.org/artemis <http://activemq.apache.org/artemis>
> <http://activemq.apache.org/artemis <http://activemq.apache.org/artemis>>
> >> http://activemq.apache.org/activemq &l
g/artemis <http://activemq.apache.org/artemis>>
>> http://activemq.apache.org/activemq <http://activemq.apache.org/activemq>
>> <http://activemq.apache.org/activemq <http://activemq.apache.org/activemq>>
>>
>> I think it’s even better than i
activemq <http://activemq.apache.org/activemq>
>
> I think it’s even better than introducing a new name, I agree.
>
> Then, I’m changing the proposal/question: agree to use activemq and
> Artemis on website ?
>
> Regards
> JB
>
> > Le 19 mars 2021 à 15:48, Bruc
you agree to have:
http://activemq.apache.org/artemis <http://activemq.apache.org/artemis>
http://activemq.apache.org/activemq <http://activemq.apache.org/activemq>
I think it’s even better than introducing a new name, I agree.
Then, I’m changing the proposal/question: agree to use activemq and Ar
xplain the intent
behind this name via the website.
Agreed, the Classic stream needs a major version bump before those
incompatible changes are introduced. Do this and move forward with those
incompatible changes.
Bruce
On Fri, Mar 19, 2021 at 8:29 AM Gary Tully wrote:
> Hi JB,
> I think &qu
Hi JB,
I think "classic" is a good name precisely because of its meaning, it
reflects its value and is a good way to differentiate on the website.
But I don't think the classic stream should be limited in versioning.
If for good reason (a new incompatible openwire version/stora
for much better performance than the existing ActiveMQ
>architecture [1]. After ActiveMQ Apollo 1.0 was released the stated goal of
>this project was for it to eventually be integrated with the mainline
>ActiveMQ code-base and serve as its replacement [2]. This fact was
>advert
ActiveMQ code-base and serve as its replacement [2]. This fact was
advertised on the ActiveMQ website although there are no longer any
references to that since the website was redesigned & updated a year or so
ago. For whatever reason Apollo never acquired the critical mass nec
th the mainline
ActiveMQ code-base and serve as its replacement [2]. This fact was
advertised on the ActiveMQ website although there are no longer any
references to that since the website was redesigned & updated a year or so
ago. For whatever reason Apollo never acquired the critical mass n
fied name. It means we would have:
>>
>> - Apache ActiveMQ Artemis
>> - Apache ActiveMQ Leto
>>
>> IMHO, it’s two subprojects under the same "umbrella" (like we have Camel
>> K, Camel Spring Boot, Camel Karaf, or Karaf runtime, Ka
good "naming/tagging".
>>
>> That’s why I’m proposing a new identified name. It means we would have:
>>
>> - Apache ActiveMQ Artemis
>> - Apache ActiveMQ Leto
>>
>> IMHO, it’s two subprojects under the same "umbrella" (like we have Camel
like we have Camel
> K, Camel Spring Boot, Camel Karaf, or Karaf runtime, Karaf Decanter, Karaf
> Cave, etc).
> Each subproject deserves a clear naming.
>
> About the website, you got my point: I would like to get all wiki based
> resources, update and clean it to push on
have Camel K,
Camel Spring Boot, Camel Karaf, or Karaf runtime, Karaf Decanter, Karaf Cave,
etc).
Each subproject deserves a clear naming.
About the website, you got my point: I would like to get all wiki based
resources, update and clean it to push on a dedicated sub context of the
website:
al standpoint ;), Artemis is the Greek goddess of the hunt, the
> wilderness, wild animals, the Moon, and chastity. Artemis is the daughter of
> Zeus and Leto, and the twin sister of Apollo.
> As "ActiveMQ Classic" is "older" than Artemis, I propose to rename as Apa
che
ActiveMQ Leto.
This name change won’t impact the code repository, it’s more for the website.
Related to that proposal, I would like to propose also to create a dedicated
space for Leto: http://activemq.apache.org/leto
<http://activemq.apache.org/leto> with a complete cleanup of th
Yep, thanks again Lucas for that contribution
(https://github.com/apache/activemq-website/pull/39). I was going to
bring more attention to it here myself once I had related changes for
adding a new Artemis release, which I now have.
As a summary, to add a new broker release you will now create a
Hey folks,
I'm late to the party but thought I would add my thanks for the work JB has
done with the recent releases even if there have been some slip ups.
For what it's worth, I noticed the process to update the website required
updates in a handful of places and looked pretty e
If you dont arrange things with others and/or send mails indicating
> you are going to do it, people are generally not going to expect they
> are needed to assist with the relatively simple final tasks of the
> release, or wont do it to avoid stepping on the original persons toes.
> If you i
lly not going to expect they
are needed to assist with the relatively simple final tasks of the
release, or wont do it to avoid stepping on the original persons toes.
If you instead need help, ask for that rather than reassuing you are
doing it, which likely only delays things further.
I did update the web
; schedule I am going to chime in here and bring up the fact that I think
> > that going forward as a project we need to do a much better job at
> > completing the release process. Recently it seems that most releases are
> > vastly delayed in having emails sent and the w
t going forward as a project we need to do a much better job at
> completing the release process. Recently it seems that most releases are
> vastly delayed in having emails sent and the website updated, etc. I've
> done a ton of releases for 5.x and I know it's a bit of extra wor
having emails sent and the website updated, etc. I've
done a ton of releases for 5.x and I know it's a bit of extra work to do
things like update the site, CVE announcements, release announcements, etc
but it's all part of doing a release. The process doesn't end when t
Hi,
Let me check (I did it but maybe forgot to send ;)).
I will fix that if it didn’t go.
Regards
JB
> Le 5 févr. 2021 à 16:46, Timothy Bish a écrit :
>
> Did I miss the announcement going out? Seems like it should have been done
> by now but I don't see it, although websi
Did I miss the announcement going out? Seems like it should have been done
by now but I don't see it, although website appears to but updated now.
On Fri, Jan 29, 2021 at 8:44 AM Jean-Baptiste Onofre
wrote:
> Thanks Robbie,
>
> I was about to update website. Thanks for catchin
will try to sustain this schedule.
> >
> > As soon as we have a consensus, I will update the website with the
> schedule/details.
> >
> > Regards
> > JB
> >
> >> Le 29 janv. 2021 à 13:38, Christopher Shannon <
> christopher.l.shan...@gmail.com>
gt; So basically, a release per quarter is probably do-able.
>
> I will try to sustain this schedule.
>
> As soon as we have a consensus, I will update the website with the
> schedule/details.
>
> Regards
> JB
>
>> Le 29 janv. 2021 à 13:38, Christopher Shann
1 - 100 of 548 matches
Mail list logo
