Not sure if I understand the problem correctly, but we could we push the
items as they are into a GitHub repository and serve the legacy pages
from there? Basically the same thing as hosting them at Red Hat, but
without a risk of a rug pull.
Or if the docs were packaged and published to a maven repository, link
to those.
Toni
On 22/10/2025 19.38, Jason Porter wrote:
Yes, that would be acceptable. Maybe put everything under a “Non-Apache
Software Foundation Previous Releases and Documentation” or “Previous Releases
and Documentation Prior to ASF Migration” section. Both of those are a lot of
words. Maybe there’s a better way to say that.
* https://groovy.apache.org/download.html - Though I don’t like how they
have small wording saying it is not ASF
* Netbeans doesn’t have anything
* https://www.openoffice.org/download/archive.html - OpenOffice calls them
“Archived Versions” – maybe we could do the same?
* CouchDB doesn’t have any of their pre-ASF releases
* Doesn’t look like Derby does either
* Neither does subversion
It doesn’t look like there is a consensus among different projects as to how
they handle this situation.
Given what Alex stated about the JBoss Infra, I don’t know if we have a good
answer to this ☹
--
Jason Porter
Software Engineer
He/Him/His
IBM
From: Toshiya Kobayashi <[email protected]>
Date: Tuesday, October 21, 2025 at 19:48
To: [email protected] <[email protected]>
Subject: [EXTERNAL] Re: [DISCUSSION] Web site maintenance
Hi all,
I checked that on the incubator ML.
https://lists.apache.org/thread/gbwc1yypc03wb0hw1mf5fxwhh8ypzyrj
Only releases made under the Apache Incubator can be hosted on ASF
infrastructure like kie.apache.org.
Older (pre-Apache) releases such as 7.x or 8.x cannot be mirrored or served
there, but you may link to them from your download page if it’s made very clear
they’re non-ASF releases (e.g., add a note like “These are pre-Apache releases
and not ASF-approved.”).
So, we cannot move old docs/binaries to kie.apache.org.
Currently the kie.apache.org website has pages with links to the older versions.
https://kie.apache.org/docs/components/drools/drools_old_documentation
https://kie.apache.org/docs/components/drools/drools_old_downloads
I think that's the right direction. The wording should be improved by
clarifying they are non-ASF releases.
Would that be acceptable?
Regards,
Toshiya
On Tue, Oct 14, 2025 at 3:24 PM Toshiya Kobayashi
<[email protected]> wrote:
Hi, our mentors
Is it okay to move the old downloads (released before our ASF move) to
kie.apache.org so that users can download them?
Regards,
Toshiya
On Fri, Oct 10, 2025 at 2:15 AM Jason Porter <[email protected]> wrote:
For 10 and forward yes. For older downloads, which are not part of the ASF, we
need to figure out what to do with them.
--
Jason Porter
Software Engineer
He/Him/His
IBM
From: Alex Porcelli <[email protected]>
Date: Wednesday, October 8, 2025 at 19:18
To: [email protected] <[email protected]>
Subject: [EXTERNAL] Re: [DISCUSSION] Web site maintenance
Thank you, Toshiya!
In regards the downloads, I'd argue that it would be better to move to
Apache. As it's the new `owner` of the brands.
On Wed, Oct 8, 2025 at 9:05 PM Toshiya Kobayashi
<[email protected]> wrote:
Hi,
I have filed a GH issue for the old docs migration. I'll work on this.
https://github.com/apache/incubator-kie-issues/issues/2138
Btw, regarding old version downloads, they are still available in
https://download.jboss.org/drools/release/
https://download.jboss.org/optaplanner/release/
https://download.jboss.org/jbpm/release/
(Note: they are not drools.org etc.)
Do we also want to move them to kie.apache.org ?
Regards,
Toshiya
On Tue, Oct 7, 2025 at 11:36 PM Kennedy Bowers <[email protected]> wrote:
Sounds like a good idea, +1
On 2025/10/07 05:07:45 Toshiya Kobayashi wrote:
Maybe we could move that content under ASF and have docs supporting
older versions?
Yes, we can.
If there are no objections or concerns raised within the next few
days, I’ll create a GitHub issue for this task.
Cheers,
Toshiya
On Mon, Oct 6, 2025 at 9:13 PM Alex Porcelli <[email protected]> wrote:
Hi Toshyia,
Thank you for the redirection, although I hear you about older version
docs... and I agree. My concern is that those domains should belong to
ASF, and pointing it to an external infrastructure is quite worrisome.
Maybe we could move that content under ASF and have docs supporting
older versions?
On Mon, Oct 6, 2025 at 12:54 AM Toshiya Kobayashi
<[email protected]> wrote:
Hello,
I'm happy to inform that now drools.org, optaplanner.org and jbpm.org
are redirected to https://kie.apache.org/
Note that docs subdomain (docs.drools.org, docs.optaplanner.org and
docs.jbpm.org) stay the same to provide old version documents.
Regards,
Toshiya
On Fri, Jul 4, 2025 at 4:16 PM Toni Rikkola <[email protected]> wrote:
We need to do the same for optaplanner.org and jbpm.org. Apache requires us to
have everything under kie.apache.org.
Both of the websites have already been moved.
Toni
On 2025/07/04 01:40:16 Toshiya Kobayashi wrote:
Hi all,
We have migrated the contents to kie.apache.org.
I'm going to ask the administrator of drools.org web server (Red Hat) to
redirect from https://www.drools.org to https://kie.apache.org/ .
I think this is not something like "proposal" or "vote", so I'm notifying
it here.
If there are no objections for a few days, I'll proceed.
Thanks,
Toshiya
On Mon, May 5, 2025 at 6:09 PM Toni Rikkola <[email protected]> wrote:
Current status.
Everything moved or there is an existing PR pending for a move.
https://github.com/apache/incubator-kie-issues/issues/1713
The blog will stay where it is. The kie.apache.org can just have the
product release and other project announcements. Everyone can blog where
they want and we can even link to those blogs from our Apache site.
kie.org is pretty much just links to blogs, so nothing to move there that
is not already in kie.apache.org.
There is a separate ticket for documentation. This only moves what is
worth the move from websites to the new location.
Toni
On 2025/04/28 07:44:50 Toni Rikkola wrote:
Thank you Toshiya. I will move Optaplanner.
https://github.com/apache/incubator-kie-issues/issues/1936
Toni
On Mon, Apr 28, 2025 at 6:50 AM Toshiya Kobayashi <
[email protected]> wrote:
Thank you for the initiative, Toni.
We have a parent GH issue: "Migrate KIE Websites to Apache
Infrastructure"
https://github.com/apache/incubator-kie-issues/issues/1713
I added a sub-issue : "Migrate drools.org to kie-website" :
https://github.com/apache/incubator-kie-issues/issues/1934
Toshiya
On Fri, Apr 25, 2025 at 3:23 PM Toni Rikkola
<[email protected]>
wrote:
I can start the work for drools and Toshiya offered help. I can also
take
on Optaplanner.
That leaves jbpm. I know dmn had a site setup, but not sure if we
need/want
a separate section for it in the future?
Toni
On Fri, Apr 25, 2025 at 2:56 AM Craig Russell <[email protected]>
wrote:
Peanut here.
What Toni sez.
Right now, an internet search for "drools" returns links to the
obsolete
drools.org <http://drools.org/ > web site, which makes it seem like
drools
is dead. The downloads on the site are years old. Wrong message.
I'd suggest to copy any current data still on drools.org <
http://drools.org/ > to a section on kie.apache.org <
http://kie.apache.org/ >
In "no time at all" search engines will notice that drools is now
homed
at
kie.
Until the domain expires, now redirect drools.org <
http://drools.org/ >
to
kie.apache.org <http://kie.apache.org/ > .
Unless this is done, the project is missing out on a lot of
possible
users.
Same for other domains that are now kie projects.
HTH,
Craig
On Apr 24, 2025, at 03:57, Toni Rikkola
<[email protected]
wrote:
Hello,
Right now we have drools.org and kie.apache.org and I guess the
same
goes
for every other subproject.
Old sites
* They break the copyrights that Apache now has for KIE.
* They get a lot of hits and the site contents are 1.5 years old.
Basically
they say the project is dead, use something else.
* No updates. No mentions of the Apache releases
* Can go down at any moment since this community does not fund
them
New site
* No content
Both
* No, or minimal, resources to maintain them
Looking at the fact that it has been years. It is clear we have
no
motivation or man power to maintain these. So the question is
what is
the
shortest path to victory?
My suggestion is we use the domains and forward to
kie.apache.org as
soon
as possible. Right now the old domains are sending the wrong
signal.
I am sure we have a lot of ideas, but also consider where we get
the
resources to implement. For few years there has been none.
Toni Rikkola
Craig L Russell
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
