from:"Rene Cordier"

Re: Call for vote: Apache James 0.8.11

2024-03-05 Thread Rene Cordier


+1,

Rene.

On 3/5/24 23:20, Karsten Otto wrote:

+1

I looked at how this change affects the parser, and played a bit with 
the test. LGTM.


Cheers,
Karsten OTTO

On 05.03.24 4:42 PM, Benoit TELLIER wrote:

Hi,

I would like to propose a new vote for 0.8.11 release of the Apache 
James MIME4J library.


You can find:

  - The maven release staged in repository.apache.org as the artifact 
#1082: 
https://repository.apache.org/content/repositories/orgapachejames-1082/

  - The changelog: https://github.com/apache/james-mime4j/pull/98
  - The site changes: https://github.com/apache/james-project/pull/2091

This is a minor release that addresses a regression of the 0.8.10 
release regarding invalid encoding usage in email headers.


Voting rules:
  - This is a majority approval: this release may not be vetoed.
  - A quorum of 3 binding votes is required
  - The vote starts at Tuesday 5th of March 2024, x4pmxx UTC+1
  - The vote ends at Tuesday 12th of March 2024, x4pmxx UTC+1

You can answer to it just with +1 and -1. Down-votes may be motivated.

3 binding votes are expected move forward on this release.

Cheers,

Benoit TELLIER


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Build metrics

2024-02-25 Thread Rene Cordier


Hello Jean,

Mistake on my part indeed, was not the intention of making this private, 
so i'm pushing it as public again on the ML. Thanks :)


Thanks for taking a look.

Interesting the diagnoses we can seem to get with develocity !

Regards,

Rene.

On 2/23/24 15:37, Jean Helou wrote:

hello rene,

I'm not sure if you answered privately on purpose or not so I'm 
answering in the same manner but I do thinks this conversation could 
benefit from being public :D


I looked in the testcontainer issue you mention and damn what a shitty 
design. There were mentions of changing it when introducing the 
ImagePullPolicy but I reviewed the MR and it wasn't changed and it 
still isn't. The effort to work around it is quite significant (but 
doable) I might poc it after my vacation.


However, going through the details of the errors using develocity, 
there are a lot more times when the cassandra tests fail because of
Caused by: com.datastax.oss.driver.api.core.DriverTimeoutException: 
Query timed out after PT2S 	


than there are times where it failed with a docker init error

looking around I also found that :
cassandra, opensearch, s3 and ldap are the subsystems that show errors
rabbit or pulsar for instance seem unaffected ( no failures over 3 
weeks of builds) there may be less integration tests for these 2 but 
this questions the volume of integration test done for the others :p



for now the volume of tests is a bit low and I need to include all PR 
builds to get some trends. over time we will be able to target master 
only to get a better view of what's going on


jean

Le jeu. 22 févr. 2024 à 04:12, Rene Cordier  a 
écrit :


Hi Jean,

Thanks for the heads up on your work on this, very interesting.

Regarding the test failures, to add a bit more insight, I never
really
took the time to fully look into it, but yes the issues with a test
containers not starting because could not initialize some class error
log has been going on for a while, and is plaguing our builds.

As I think Quan noticed a while ago, this issue opened on the
testcontainers java backlog seems related:
https://github.com/testcontainers/testcontainers-java/issues/1872

It seems this error is misleading and hides the real one. It could
ber
elated to infra, or something maybe real tricky on our build.
Might need
to take the time to dig deeper at some point, but looks like a tricky
one to me :)

Hope this bit of info helps somehow!

Regards,

Rene.

On 2/21/24 18:01, Jean Helou wrote:
> Hi fellows,
>
> The Develocity <https://ge.apache.org> integration of
james-project build
> has now been running for long enough that we can start seeing
interesting
> things beyond the raw build scans.
> First we can give a short look at build trends
>

<https://ge.apache.org/scans/trends?search.relativeStartTime=P28D=*james*=master=clean%2Cinstall=Europe%2FParis#

<https://ge.apache.org/scans/trends?search.relativeStartTime=P28D=*james*=master=clean%2Cinstall=Europe%2FParis#>>
> for the `clean install` command on master (the build stage), its
hard to
> derive actual trends since
> - we only have 15 days of history
> - we run on runners with varying cpu power ( build scans show
T1C go from
> 16 to 24)
> but it can be used to establish a baseline so we can compare
later on
> In average this stage took 9min10s
> the week from feb 5 to feb 11th has had a lot more spread 5th-95th
> percentile was 4m54s to 11m26s
> last week was a bit more homogenous with the same percentiles
being 7m54 -
> 10m18
> this week so far looks more similar to last week than the
previous, 7m12 -
> 9m4
>
> Adding the local build cache added about 14s of overhead and
provided no
> benefits on CI (completely expected, maybe I should disable
local caching
> on CI since it spawns in a fresh env everytime) but this will be
> interesting to compare with the remote build cache.
>
> The tests
>

<https://ge.apache.org/scans/tests?search.relativeStartTime=P28D=*james*=Europe%2FParis=FLAKY

<https://ge.apache.org/scans/tests?search.relativeStartTime=P28D=*james*=Europe%2FParis=FLAKY>>
> monitoring is also interesting. This screen monitors 2 things:
> - which tests fail the most often
> - which tests are flaky
> To measure this I enabled retries for surefire in this commit
> <https://github.com/apache/james-project/commit/39a50194> so
that a failing
> test is retried once.
> Failed is both tries failed
> Flakyness is derived by looking at retries (1 fail followed by 1
success).
>
> The results probably won't surprise you too much :
>
> The t

Re: vote : Remote build cache experiment

2024-02-20 Thread Rene Cordier


+1,

If there is a chance to make our builds faster, I say we take it! Thanks 
for this work :)


Rene.

On 2/20/24 15:18, Jean Helou wrote:

Hello devs !

I have not yet moved forward with enabling remote caching for the build and
tests in general. It is unclear to me if you are ok with trying it from the
previous discussion. So I'll call a more formal vote:

Are you ok with experimenting enabling remote build cache for james (ci
write+local read) ?

Deployment of the remote build cache would follow the documented plan
https://docs.gradle.com/enterprise/maven-build-cache/#rolling_out_the_cache_in_your_organization
TLDR;
1. move forward with the INFRA request to get our build cache node
2. test (read+write) with a few (2-3) volunteers locally (not enabled on CI)
3. enable write on CI
4, enable read for everyone

- voting starts 2024-02-20
- voting ends 2024-02-27

This is lazy consensus, this vote can be vetoed (please motivate your
veto), there will be a second formal vote to definitely enable the cache
once the experiment has been conducted and there are some results to share.

jean



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Call for vote: Apache James MIME4J 0.8.10

2024-02-14 Thread Rene Cordier


+1,

Rene.

On 2/12/24 17:38, Benoit TELLIER wrote:

Typo

The maven release staged in repository.apache.org as the artifact #1081:
https://repository.apache.org/content/repositories/orgapachejames-1081/

On 12/02/2024 11:35, Benoit TELLIER wrote:

Hi,

I would like to propose a new vote for 0.8.10 release of the Apache 
MIME4J library.


You can find:

 - The maven release staged in repository.apache.org as the artifact 
#1076:

https://repository.apache.org/content/repositories/orgapachejames-1076/
 - The changelog:
https://github.com/chibenwa/james-mime4j/blob/master/CHANGELOG.md

This release ships mostly small enhancements.

Voting rules:
 - This is a majority approval: this release may not be vetoed.
 - A quorum of 3 binding votes is required
 - The vote starts at Monday 12th of February 2024, 11am UTC+2
 - The vote ends at Monday 19th of February 2024, 11am UTC+2

You can answer to it just with +1 and -1. Down-votes may be motivated.

3 binding votes are expected move forward on this release.

Cheers,

Benoit TELLIER


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org




-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org




-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Call for vote: Apache James 3.7.5

2024-02-14 Thread Rene Cordier


+1,

Rene.

On 2/12/24 17:37, Benoit TELLIER wrote:

Hi,

Taking into account the feedback of this very list,

I would like to propose a new vote for 3.7.5 release of the Apache 
James server.


You can find:

 - The maven release staged in repository.apache.org as the artifact 
#1079:

https://repository.apache.org/content/repositories/orgapachejames-1079/
 - The changelog for 3.7.5:
https://github.com/apache/james-project/blob/master/CHANGELOG.md

This release mostly ships bug fixes.

Voting rules:
 - This is a majority approval: this release may not be vetoed.
 - A quorum of 3 binding votes is required
 - The vote starts at Tuesday 12th of February 2024, 11am UTC+2
 - The vote ends at Tuesday 19th of February 2024, 11am UTC+2

You can answer to it just with +1 and -1. Down-votes may be motivated.

3 binding votes are expected move forward on this release.

Cheers,

Benoit TELLIER


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org




-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Call for vote: Apache James 3.8.1

2024-02-14 Thread Rene Cordier


+1,

Rene.

On 2/12/24 18:43, Karsten Otto wrote:

+1

Looks good to me.

Cheers,
Karsten OTTO


On 12.02.24 11:46 AM, Benoit TELLIER wrote:

Hi,

Following the feedback of this very list,

I would like to propose a new vote for 3.8.1 release of the Apache 
James server.


You can find:

  - The maven release staged in repository.apache.org as the artifact 
#1080:

https://repository.apache.org/content/repositories/orgapachejames-1080/
  - The changelog for 3.8.1:
https://github.com/apache/james-project/blob/master/CHANGELOG.md

This release mostly ships bug fixes.

Voting rules:
  - This is a majority approval: this release may not be vetoed.
  - A quorum of 3 binding votes is required
  - The vote starts at Monday 12th of February 2024, 11am UTC+2
  - The vote ends at Monday 19th of February 2024, 11am UTC+2

You can answer to it just with +1 and -1. Down-votes may be motivated.

3 binding votes are expected move forward on this release.

Cheers,

Benoit TELLIER


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Develocity

2024-02-06 Thread Rene Cordier

I agree caching the test suite is very tempting, it would help gain 
so much time on the build.


But yes the test suite is flaky unfortunately. Maybe we need extra work 
making it more stable first, but that's not easy task ^^'


Or maybe for remote caching on test execution, maybe we can try to 
execute that in an other branch in parallel to master, giving us time to 
monitor the behavior of the build, before using it for good? Requires 
extra work, efforts and attention yes, but I hardly see how else we can 
go safely forward on this. But somebody else has a better idea maybe? :)


Regards,

Rene.

On 2/7/24 02:58, Jean Helou wrote:

Thanks for trying

As you can see in the output only about 10% of the tasks you ran were
cached.

Which explains why the gains are not so great.

There are 2 good news
- it is possible to configure more goals to be cached. I have an attempt at
caching scala compile (which doesn't work for now as that goal has rather
complex input and outputs).
I intend to look at build scans to cache more high CPU consuming goals and
to avoid running some goals entirely when possible (as per my comments on
the PR)

Where it becomes really interesting (the second good news) is that surefire
is supported out of the box, so if one pays the cost of running the tests,
every subsequent build would only run the tests for the changed projects
and their dependencies

And testing is by far the most time consuming goal in James build.

Remote caching of test execution would have the most impact, accelerating
both local and CI builds because it would allow sharing the cache between
different machines/nodes. (Only the ci would write but everyone could read
if I understand correctly)

The risk is caching a negative result coming from a flaky test. And I feel
like James test suite is quite unstable.

So I'm wondering if I should go ahead with the remote build cache node
request to apache INFRA or revisit that request in a few months.

Jean



Le mar. 6 févr. 2024 à 11:18, Quan tran hong 
a écrit :


Hi Jean,

I tried your work locally and the build time is truly better.
`mvn clean install -DskipTests -Dmaven.skip.doc=true
-Dgradle.cache.local.enabled=true`

1st build:
[INFO] Total time:  22:18 min
[INFO] 8053 goals, 7996 executed, 57 from cache, saving at least 13s

2nd build:
[INFO] Total time:  15:07 min
[INFO] 8053 goals, 7296 executed, 757 from cache, saving at least 3m 11s

Thank you for the initiative :-)

Quan

Vào Th 3, 6 thg 2, 2024 vào lúc 14:48 Jean Helou  đã
viết:


Hi devs,

I realized this morning that I initiated the conversation on the wrong

list

(server-user instead of server-dev) ...
see the archives
https://lists.apache.org/list.html?server-u...@james.apache.org for

Rene's

positive answer

sorry about that

jean

-- Forwarded message -
From: Jean Helou 
Date: Mon, Feb 5, 2024 at 3:52 PM
Subject: Develocity
To: James Users List 


Hello fellow james devs,

I'm not sure how much context to provide in the email you can read more

in



https://issues.apache.org/jira/projects/JAMES/issues/JAMES-3978?filter=allopenissues

TLDR; A few months ago the apache foundation announced a sponsorship of

the

"gradle" company for a tool to diagnose, monitor and optimize builds  (
called gradle enterprise at the time and renamed develocity since)

I posted a first PR to plug james build in that tool
https://github.com/apache/james-project/pull/1972

This first integration brings only build scans and local caching
- build scans can help us understand what slows our build
- local caching allows local build perf improvements (I posted a small
benchmark which shows a divide by 3 the time spent building
james-server-core in a repeat build with no changes)

The build scans also show that many tasks in the build are not actually
cached so there is room for more improvement.

The local cache does apply to surefire tasks,unfortunately the benefits

for

CI are very small :

In the first stage we cache the compilation result itself but that
represents a very small part of the test stages (even if we had to

compile

everything from scratch that's barely 20 minutes out of the 3h30 of the
build so caching only marginally improves the build time at the moment

the next stage would be to :
- make more tasks cacheable
- enable the remote build cache

The remote build cache allows to share caching accross builds which means
that if a change affects only a small portion of the build, only that
change would effectively be recompiled and retested, so the closer to the
"leafs" of the reactor a change would be the shorter its CI pipelines

would

be.
I pinged INFRA in https://issues.apache.org/jira/browse/INFRA-25461 to
know
what the process is for enabling the remote build cache and it seems it
starts with a mailing list thread :D

note that
- only the CI would be allowed to write to the remote build cache
- build caches both local and remote can be disabled with properties

(IIRC

there are

Re: Vote to merge the Java 21 adoption for Apache James PR

2024-02-05 Thread Rene Cordier


+1,

Thanks for the efforts on this work :)

Rene.

On 2/6/24 10:36, Quan tran hong wrote:

Hi everyone,

Following the Jira ticket

and the previous mailing list discussion

regarding Java 21 adoption for James, I and Benoit put together an effort
to successfully get a green build on the Java 21 adoption PR
.

The idea is to have James migrated to Java 21 with minimal changes first,
and after that, we can leverage new Java features gradually.

Because this is a big change for James, James's community review, remarks,
and opinions on merging the Java 21 PR should be needed.

It would be good if the community could spend some time reviewing the PR,
or just upvote/downvote directly on this mail thread.

Thanks for reading.

Best regards,

Quan



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Call for vote: Apache James 3.8.1

2024-01-11 Thread Rene Cordier


Hi jean,

FYI Karsten already proposed fixes for that issue that have been 
approved and will be part of the releases. It's just a matter now of 
getting a green build from a rather a bit capricious CI^^'


Regards,

Rene.

On 1/11/24 15:09, Jean Helou wrote:

Much clearer thank you !
What do you think about karsten's request ? i have no idea how painful it
is to add that to the release ( i have a vague notion that the release
process is quite complex). Though i don´t use rabbitmq I think a bug that
results in hard mail loss is  severe enough to warrant a hotfix

jean

Le mer. 10 janv. 2024 à 16:44, btell...@linagora.com 
a écrit :


I just merged the changelog updates, this should be better now.

On 10/01/2024 11:26, Jean Helou wrote:

hmm the linked changelog doesn't list any unreleased changes is that

normal

?

Le mar. 9 janv. 2024 à 09:17, Benoit TELLIER  a

écrit :

Hi,

I would like to propose a new vote for 3.8.1 release of the Apache James
server.

You can find:

- The maven release staged in repository.apache.org as the artifact
#1077:
https://repository.apache.org/content/repositories/orgapachejames-1077/
- The changelog for 3.8.1:
https://github.com/apache/james-project/blob/master/CHANGELOG.md

This release mostly ships bug fixes.

Voting rules:
- This is a majority approval: this release may not be vetoed.
- A quorum of 3 binding votes is required
- The vote starts at Tuesday 9th of January 2024, 9am UTC+2
- The vote ends at Tuesday 16th of January 2024, 9am UTC+2

You can answer to it just with +1 and -1. Down-votes may be motivated.

3 binding votes are expected move forward on this release.

Cheers,

Benoit TELLIER


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org




-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Call for vote: Apache James 3.8.1

2024-01-09 Thread Rene Cordier


+1,

Rene.

On 1/9/24 15:17, Benoit TELLIER wrote:

Hi,

I would like to propose a new vote for 3.8.1 release of the Apache 
James server.


You can find:

 - The maven release staged in repository.apache.org as the artifact 
#1077:

https://repository.apache.org/content/repositories/orgapachejames-1077/
 - The changelog for 3.8.1:
https://github.com/apache/james-project/blob/master/CHANGELOG.md

This release mostly ships bug fixes.

Voting rules:
 - This is a majority approval: this release may not be vetoed.
 - A quorum of 3 binding votes is required
 - The vote starts at Tuesday 9th of January 2024, 9am UTC+2
 - The vote ends at Tuesday 16th of January 2024, 9am UTC+2

You can answer to it just with +1 and -1. Down-votes may be motivated.

3 binding votes are expected move forward on this release.

Cheers,

Benoit TELLIER


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org




-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Call for vote: Apache James 3.7.5

2024-01-09 Thread Rene Cordier


+1,

Rene.

On 1/9/24 15:15, Benoit TELLIER wrote:

Hi,

I would like to propose a new vote for 3.7.5 release of the Apache 
James server.


You can find:

 - The maven release staged in repository.apache.org as the artifact 
#1079:

https://repository.apache.org/content/repositories/orgapachejames-1079/
 - The changelog for 3.7.5:
https://github.com/apache/james-project/blob/master/CHANGELOG.md

This release mostly ships bug fixes.

Voting rules:
 - This is a majority approval: this release may not be vetoed.
 - A quorum of 3 binding votes is required
 - The vote starts at Tuesday 9th of January 2024, 9am UTC+2
 - The vote ends at Tuesday 16th of January 2024, 9am UTC+2

You can answer to it just with +1 and -1. Down-votes may be motivated.

3 binding votes are expected move forward on this release.

Cheers,

Benoit TELLIER


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org




-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Call for vote: Apache James MIME4J 0.8.10

2024-01-08 Thread Rene Cordier


+1,

Cheers,

Rene.

On 1/8/24 21:36, Benoit TELLIER wrote:

Hi,

I would like to propose a new vote for 0.8.10 release of the Apache 
MIME4J library.


You can find:

 - The maven release staged in repository.apache.org as the artifact 
#1076:

https://repository.apache.org/content/repositories/orgapachejames-1076/
 - The changelog:
https://github.com/chibenwa/james-mime4j/blob/master/CHANGELOG.md

This release ships mostly small enhancements.

Voting rules:
 - This is a majority approval: this release may not be vetoed.
 - A quorum of 3 binding votes is required
 - The vote starts at Monday 8th of January 2024, 3pm UTC+2
 - The vote ends at Monday 15th of January 2024, 3pm UTC+2

You can answer to it just with +1 and -1. Down-votes may be motivated.

3 binding votes are expected move forward on this release.

Cheers,

Benoit TELLIER


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org




-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Event dead letter group deserialization too strict?

2023-12-14 Thread Rene Cordier


Hello guys,

Today I noticed on one of our servers that the redelivery of all event 
dead letters task was failing.


The problem being... too strict on event dead letter group 
deserialization. The problem I had was that after a migration, I had 
some groups still registered in group_table that were from before the 
migration. After the migration, those group didn't exist anymore or have 
been refactored and changed name. But the api is so strict on it that 
when we try to redeliver all events, we fetch all groups in the group 
table and try to deserialize them into their own class. If one of the 
group changed, it just crashes!


I've been trying to use webadmin for trying to delete the groups that 
were not in the code anymore: 
https://james.apache.org/server/manage-webadmin.html#Deleting_all_events_of_a_group


Looking at the code, it deletes events of a group, then the group. 
Checking in cassandra, there was no events left going around related to 
those groups. But still the task failed... because we try to strictly 
deserialize the group in to a class again .


I understand that being strict in some cases is good, but it reached the 
point where I had to go delete the faulty group lines in cassandra 
myself to do the clean up and allow the redeliver all events task to do 
its job again properly (which I find even more riskier).


Can we be a bit more relax on that? Or at least giving the possibility 
to delete via the webadmin api those outdated group without a strict 
deserialization first? Like maybe refactoring the webadmin route I 
posted above to accept a header, like "I-KNOW-WHAT-I-AM-DOING" (as we 
have for some other sensitive routes) and if we get that, we accept to 
not be strict and just do a blind remove against cassandra for that group?


It's not the first time I encounter this, and it's frustrating each time.

Would be interested to know what the community thinks.

Best regards,

Rene.


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Proposal about deprecation and removal

2023-11-26 Thread Rene Cordier


Hi Matthieu,

I think some people in the community are probably using the Spring 
version because the official documentation was never really clear about 
our intentions of potentially deprecating and removing this part.


I'm totally for deprecating and removing that part, and I'm very happy 
that this is getting addressed, but I think it should start by modifying 
the documentation where we put clearly that the Spring version is 
deprecated, planned for removal, and we strongly advice people to not 
use it as such.


What other features do you have in mind for removal though? I guess 
jmap-draft is on the table (was addressed in an other mail by Benoit 
already) but what else?


Cheers,

Rene.

On 11/24/23 23:30, Matthieu Baechler wrote:

Hi,

I had a hack session with Benoit today and the sentence "this would break 
Spring" came many times along the day.

As I'm less active on James than I used to be, I must admin I have no idea how 
popular the Spring version of James is nowadays.

However, what strikes me when I hack on James is how the size of the project 
and its legacy makes it so slow to make progress.

We did some deprecation and removal in the past but we have been conservative 
about that.

I would like to argue that being conservative to preserve existing users may 
actually prevents from attracting new ones. Moreover, it probably also prevents 
new developers to involve as they are quickly overwhelmed.

So, what would you think about removing more aggressively features and modules, 
starting with the Spring support?

Cheers,

-- Matthieu Baechler



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Deprecate and remove JMAP draft implementation

2023-11-16 Thread Rene Cordier


About time :) +1

Rene.

On 11/16/23 19:51, Benoit TELLIER wrote:

Hello there,

I wanted to quickly discussed the deprecation and removal of the JMAP 
draft implementation.


Please raise a voice if this impacts you...

## Why

 -> This protocol do no longer match standard specification
 -> Similar features are offered through the RFC-8621 regular JMAP 
mail protocol
 -> This code is complex (over 50.000 lines of code and roughtly 10% 
of James code volume)
 -> Build time is significant for JMAP draft integration tests - 16 
minutes.
 -> The only known usage is OpenPaaS, whose web-mail component is 
deprecated.


## What

Deprecate and eventually remove the following maven modules.

/server/protocols/jmap-draft
/server/protocols/jmap-draft-integration-testing/*

We might need to relocate the following classes:

 - org.apache.james.jmap.mailet
 - org.apache.james.jmap.event

Here are tests that would need to be ported to the new JMAP 
specification:


 - VacationRelayIntegrationTest
 - QuotaMailingTest
 - ImapSetMessagesMailboxesUpdatesCompatibility.feature
 - ImapKeywordsConsistency.feature

Regarding this one, wewould need a per test analysis to know if this 
is already tested with new spec or not.


- 
server/protocols/jmap-draft-integration-testing/jmap-draft-integration-testing-common/src/test/resources/cucumber/sharing


Best regards,

Benoit TELLIER


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org




-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Call for vote: Apache James 3.8.0

2023-05-18 Thread Rene Cordier


+1,

Rene.

On 19/05/2023 09:23, Benoit TELLIER wrote:

Hi,

I would like to propose a new vote for 3.8.0 release of the Apache James 
server.


You can find:

  - The maven release staged in repository.apache.org as the artifact 
#1074: 
https://repository.apache.org/content/repositories/orgapachejames-1074/
  - The changelog for 3.8.0: 
https://github.com/apache/james-project/pull/1568
  - The compatibility instructions/upgrade recommendation: 
https://github.com/apache/james-project/pull/1568


This release brings the following significant changes:

  - Upgrade TCP protocols to Netty 4
  - Migrate IMAP protocol as reactive
  - Multiple additional IMAP extensions are implemented
  - Upgrade to Cassandra driver 4
  - Migrate to OpenSearch for license purposes
  - Review our threading model to cap threads performing blocking tasks
  - Implement official JMAP quotas specification

Voting rules:

  - This is a majority approval: this release may not be vetoed.
  - A quorum of 3 binding votes is required
  - The vote starts at Friday 19th of June 2023, 9am30 UTC+7
  - The vote ends at Friday 26th of June 2023, 9am30 UTC+7

You can answer to it just with +1 and -1. Down-votes may be motivated.

3 binding votes are expected move forward on this release.

Cheers,

Benoit TELLIER in the name of the Apache James PMC.


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org




-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Call for vote: Apache James 3.7.4

2023-03-23 Thread Rene Cordier


+1

Rene.

On 24/03/2023 00:21, Benoit TELLIER wrote:

Hi,

I would like to propose a new vote for 3.7.4 release of the Apache James 
server.


You can find:

  - The maven release staged in repository.apache.org as the artifact 
#1073:

https://repository.apache.org/content/repositories/orgapachejames-1073/
  - The changelog for 3.7.4:
https://github.com/apache/james-project/blob/master/CHANGELOG.md
  - The compatibility instructions/upgrade recommendation:
https://github.com/apache/james-project/blob/master/upgrade-instructions.md#374-version

There is only minor fixes part of this release.

Voting rules:
  - This is a majority approval: this release may not be vetoed.
  - A quorum of 3 binding votes is required
  - The vote starts at Thursday 24th of March 2023, 6pm UTC+1
  - The vote ends at Thursday 31st of March 2023, 6pm UTC+1

You can answer to it just with +1 and -1. Down-votes may be motivated.

3 binding votes are expected move forward on this release.

Cheers,

PMC member name


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org




-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Antora build mis-fonctionning

2023-03-22 Thread Rene Cordier


Hi James community,

Recently some people took notice that the Antora documentation hosted on 
https://james.staged.apache.org/james-site/latest/homepage.html is not 
always showing.


We suspect it's because if the build on the CI fails for some reason, 
then deployment maybe doesn't go to the end and we end up with something 
broken (missing doc website).


Some work has been done regarding this, fixing some links and typos, 
adding this ML as a recipient in the mail build status so we can monitor 
it better if there is a problem during the build, ...


You can find a resume of it in the JIRA here if you are interested : 
https://issues.apache.org/jira/browse/JAMES-3894


If someone has more ideas how we can make that release process more 
reliable, any help is welcome and appreciated. Don't hesitate then to 
reply to this email or comment on the JIRA ticket.


Thanks for your attention and have a good day!

Best regards,
Rene.

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Fwd: [ANNOUNCE] Changes to Jira Account Creation (issues.a.o/jira)

2022-11-09 Thread Rene Cordier


+1,

Rene.

On 10/11/2022 12:01, Benoit TELLIER wrote:

Hello all

See the email bellow.

This email:
  - Warns us that SIGNIFICANT paper work would be needed to create 
accounts on our JIRA
  - Recommends us to activate GitHub issues for user facing interactions 
(bug reports, feature requests, etc...) and let the committer transpose 
this into JIRA.


Being likely the one the paper work would fall on, I am strongly in 
favor of following the recommendation. JIRA would then be reserved for 
regular contributors. Would you agree?


If so I would...
  - [ ] Activate github issues on our repos
  - [ ] Update our contributing sections, instructions and links on the 
website.


Regards,

Benoit



 Forwarded Message 
Subject: [ANNOUNCE] Changes to Jira Account Creation (issues.a.o/jira)
Date: Fri, 21 Oct 2022 17:55:40 -0700
From: fluxo 
Reply-To: us...@infra.apache.org
To: annou...@infra.apache.org



Hello PMC members,

As I'm sure most of you are aware, the spam issues on Jira are getting 
worse. We are seeing spam user creation of over 10,000 accounts per 
year, and receive many requests per month from project members for help 
addressing spam complaints. Infra is taking steps to disable public Jira 
signups.
Infra has developed a self-service tool by which folks on a PMC can 
request a Jira account for non-ASF contributors:



https://selfserve.apache.org/

Click "Create a Jira user account" to go to:


https://selfserve.apache.org/jira-acct.html


You need to enter a username for the new Jira account. We will reject 
the request if there is an existing account with that username. If this 
person may ultimately become a committer, Infra recommends that they 
choose a username that they can also use for their LDAP username.


Next, the tool asks you to enter their Display Name. This is the "public 
name" which will appear on all their Jira posts and comments.


Last, the tool asks you to enter the user's email address. We expect the 
PMC to exercise due diligence in making sure the contributor's email 
works. If it does not, they will not get the password reset mail.



Infra knows this process change places an increasing burden on PMC 
members for managing contributors, and makes it harder for people to 
contribute bug reports. We suggest projects consider using GitHub Issues 
for customer-facing questions/bug reports/etc., while maintaining 
development issues on Jira. You can enable GitHub Issues for your 
repository via 
https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-Repositoryfeatures



Infra has targeted 6 November for the date we switch off public signups 
for issues.apache.org/jira . Please let us know if this will place any 
significant burden on your teams. We are following an aggressive 
timeline because of the serious impact spam users have on the safety and 
stability of our infrastructure.


As always, if you have any questions or comments about this, please let 
us know!


-Chris (fluxo)



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Call for vote: Apache James 3.7.2

2022-10-07 Thread Rene Cordier


+1,
Rene.

On 07/10/2022 14:26, Benoit TELLIER wrote:

Hi,

I would like to propose a new vote for 3.7.2 release of the Apache James 
server.


You can find:

  - The maven release staged in repository.apache.org as the artifact 
#1066: 
https://repository.apache.org/content/repositories/orgapachejames-1066/
  - The communication material for release 3.7.2: 
https://github.com/apache/james-project/pull/1234


This release brings various fixes and enhancements. Some security 
related dependency upgrades where done.


Voting rules:
  - This is a majority approval: this release may not be vetoed.
  - A quorum of 3 binding votes is required
  - The vote starts at Friday 7th of October 2022, 2pm30 UTC+7
  - The vote ends at Friday 14th of October 2022, 2pm30 UTC+7

You can answer to it just with +1 and -1. Down-votes may be motivated.

3 binding votes are expected move forward on this release.

Cheers,

Benoit TELLIER


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org




-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Call for vote: Apache James JDKIM 0.3

2022-10-02 Thread Rene Cordier


+1,
Rene.

On 02/10/2022 16:06, Benoit TELLIER wrote:

Hi,

I would like to propose a new vote for 0.3 release of the Apache James 
JDKIM library.


You can find the maven release staged in repository.apache.org as the
artifact #1065:
https://repository.apache.org/content/repositories/orgapachejames-1065/

Voting rules:
  - This is a majority approval: this release may not be vetoed.
  - A quorum of 3 binding votes is required
  - The vote starts at Sunday 2nd of October 2022, 4pm UTC+7
  - The vote ends at Sunday 9th of October 2022, 4pm UTC+7

You can answer to it just with +1 and -1. Down-votes may be motivated.

3 binding votes are expected move forward on this release.

Cheers,

Benoit TELLIER


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org




-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Call for vote: Apache James 3.7.1

2022-08-28 Thread Rene Cordier


+1,
Rene.

On 26/08/2022 18:12, Benoit TELLIER wrote:
|Hi, I would like to propose a new vote for 3.7.1 release of the Apache 
James server. You can find: - The maven release staged in 
repository.apache.org as the artifact #1064: 
https://repository.apache.org/content/repositories/orgapachejames-1064/ 
- The changelog for 3.7.1: 
https://github.com/apache/james-project/pull/1160 - The compatibility 
instructions/upgrade recommendation: 
https://github.com/apache/james-project/blob/master/upgrade-instructions.md#371-version 
This release includes a few bug fixes Voting rules: - This is a majority 
approval: this release may not be vetoed. - A quorum of 3 binding votes 
is required - The vote starts at Friday 26th of August 2022, 6pm UTC+7 - 
The vote ends at Friday 2nd of September 2022, 6pm UTC+7 You can answer 
to it just with +1 and -1. Down-votes may be motivated. 3 binding votes 
are expected move forward on this release. Cheers, PMC member name |




-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: new committer: Jean Helou

2022-06-24 Thread Rene Cordier


Congrats Jean :)

Rene.

On 24/06/2022 08:51, Benoit TELLIER wrote:
|The Project Management Committee (PMC) for Apache James has invited 
Jean Helou to become a committer and we are pleased to announce that 
they have accepted. Jean started to contribute many years ago, starting 
with the first object storage implementation using JCloud. Later 
contributed, amongst other bug fixes the implementation for the 
promising Apache Pulsar mail queue. Being a committer enables easier 
contribution to the project since there is no need to go via the patch 
submission process. This should enable better productivity. A PMC member 
helps manage and guide the direction of the project. Best regards, 
Benoit in the name of Apache James PMC. |




-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Upgrade regarding ElasticSearch

2022-06-17 Thread Rene Cordier


Hi,

Overall no problem, maybe I wasn't clear enough on my initial mail, or 
it was too long to ingest.


But it seems we are all on the same page now so all good :)

Regards,
Rene.

On 17/06/2022 14:07, Matthieu Baechler wrote:

Hi,

On Fri, 2022-06-17 at 10:19 +0700, Rene Cordier wrote:


[...]





Instead of deleting the support for ES 7, we could just keep it and run
tests against OpenSearch.

Investment is very low and people don't have to switch to non-
opensource ES 8 if they don't want to.


I'm sorry you are mixing up things... It's not question anymore to move
up to ES 8 at all,



Sorry, I must have missed that part from your email.



none of the 3 solutions I proposed above are implying
this.



Well, I was thinking that, given you already have a ES 8 impl almost
done, you would like to keep it. It looks like I was wrong.


We agree it's better to just switch to OpenSearch and not continue
with ES versions after 7.10.



Definitely something I missed in the discussion.



If ever somebody has interest in migrating to OpenSearch 2, it can be
migrated at this point.


Well as said as well... I did spend a lot of time on it personally to
migrate to their new java client, that looks very similar to the one on
es8 (that's why the POC is starting from the ES work:
https://github.com/apache/james-project/pull/1051... but I can clean it
up to make all the es 8 stuff disappear?)

However I remain an issue with the sort to which we had a workaround
with Benoit (but I personally don't like it) and I proposed a fix on
their client:
https://github.com/opensearch-project/opensearch-java/pull/169 .

But maybe a bit early to fully migrate to that yet...



I would personally postpone the migration and go for solution 1.


I understand why not solution 3... but what about solution 2? It's just
change the one dependency es client to opensearch high level one and
change all the imports and... nothing else. Effort needed is not much
more time consuming IMO? And you can use OpenSearch 2. Would like to
know what makes you afraid on this?




To be honest, if you tackle this issue (I mean, if you have time to
spend on the task), I don't really care how, we have a good test suite,
we can always change later if needed.

Sorry for my previous email, I got the main assumption wrong.

Regards,

-- Matthieu

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org




-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: Upgrade regarding ElasticSearch

2022-06-16 Thread Rene Cordier

Hi Matthieu, thanks for joining the discussion.

Answers inline...

On 17/06/2022 03:28, Matthieu Baechler wrote:

Hi René,

Thank you for starting this thread.

On Wed, 2022-06-15 at 16:37 +0700, Rene Cordier wrote:

Hello James community!

I would like to start a discussion regarding the upgrade of
ElasticSearch, hoping we can reach a consensus, as I spent quite a lot
of time on this already.

As you know, the version 7.10 has reached EOL already, so we need to
migrate from it.

Thus a while ago I started a very painful migration to ES 8.2 here:
https://github.com/apache/james-project/pull/1018

Before being rightfully reminded by Matthieu Baechler that ES 7.10 is
the last OSI-compliant version of ElasticSearch, before you know they
switched to a new license that's not really open source anymore...

OpenSearch is indeed a fork of ES 7.10 using the Apache License, which
is definitely more in favor for adoption for the migration than ES 8. On
that, I totally agree.

From then, with Benoit Tellier, we did our little extra research then.

If we want to migrate from ES to OpenSearch, there is a few options on
the table actually:

- solution 1: not modifying the ES7 code. Well it's possible, but you
can only use versions 1.x of OpenSearch (1.3.3 atm). However, from 2.x
version of OpenSearch, the support for es7 client has been dropped in
favor of their own clients.

The best part for this solution is: it should not require anything else
than changing the docker image reference.

- solution 2: using the java high level rest client from OpenSearch
(https://opensearch.org/docs/latest/clients/java-rest-high-level/): That
client is a basic fork of the java high level rest client from ES. As
this client has been dropped in upper version of ES for a new client
(that you can see in the PR I did before:
https://github.com/apache/james-project/pull/1018), the fork is thus
identical.
Benoit did a little POC on it and it seems you only need to change the
imports and it works with OpenSearch 2.0 without issues (also said here
in their doc:
https://opensearch.org/docs/latest/clients/java-rest-high-level/#migrating-to-the-opensearch-java-high-level-rest-client)

- solution 3: using the new java client
(https://opensearch.org/docs/latest/clients/java/). That client has been
forked from the new java client from ES probably at its beginnings,
before the change of license. In the POC I did here:
https://github.com/apache/james-project/pull/1051, you can see the
structure is very similar to the java client from ES, but with obviously
some changes or bugs as the fork went its way since when from the
original one. That migration is complicated honestly, but because I did
the one to ES then the remaining work is minimal as proven in the POC.
Just a few issues though encountered... (in the POC you can see them)

I think solution 1 is IMO, not an option, as we probably want to migrate
to the latest version of OpenSearch as we are at it now.

Solution 2 is very easy (replace dependencies and imports... nothing
more) and allows to use OpenSearch 2.0.

I would say let's go with it if I didn't invest so much time migrating
to the new java client. Because this is the issue actually. Amazon
states that the java client is supposed to replace the high level one at
some point (like on forums, or the page of the github project
(https://github.com/opensearch-project/opensearch-java). It's a bit
blurry on really when the high level client would be dropped but I
wouldn't be surprised to see it on next major upgrade for example.

So at some point we will have to migrate the client eventually... do we
try to do it now (solution 3) or do we do things simple for now
(solution 2) and keep the work done under the hood for the day the
migration is necessary? (cause a big chunk of it has been done I think).

I'm honestly fine either way, but would love to hear what the community
has to say on the topic.

Sorry it was long! But I hope I gave all the keys necessary to
understand our options here regarding this migration.

My point is: upgrading to ES 8 was triggered by "ES 7 is EOL

OpenSearch 1.x is basically a supported ES 7 and the code for ES 7 is
supposed to work perfectly with OpenSearch 1.x.

Yes it does.

Instead of deleting the support for ES 7, we could just keep it and run
tests against OpenSearch.

Investment is very low and people don't have to switch to non-
opensource ES 8 if they don't want to.

I'm sorry you are mixing up things... It's not question anymore to move
up to ES 8 at all, none of the 3 solutions I proposed above are implying
this. We agree it's better to just switch to OpenSearch and not continue
with ES versions after 7.10.

If ever somebody has interest in migrating to OpenSearch 2, it can be
migrated at this point.

Well as said as well... I did spend a lot of time on it personally to
migrate to their new java client, that looks very similar to the one on
es8 (that's why the POC is starting from t

Upgrade regarding ElasticSearch

2022-06-15 Thread Rene Cordier