You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Tellier Benoit <bt...@apache.org> on 2021/02/28 07:45:40 UTC
Time for a 3.6.0 release
Hey there!
It's been almost a year (!) since we shipped some master code out in a
release (the last release taking me over 3 months!).
As such, I think it would be important, as a project, to make such a
release happen before the next Apache board meeting (mid. April). I
devote myself to perform such a release (let's hope I will be more
efficient this time!).
I would like to propose the following suggestion for this 3.6.0 release:
- Claim experimental support for JMAP RFC-8621 and RFC-8887 (websocket
transport)
- As such deprecate JMAP Draft as of 3.6.0, to be removed in 3.7.0. (or
later based on community usage) in order to encourage the migration.
- Deprecate `server/container/guice/cassandra-guice` product.
Rationals: it do not achieve distribution, this James server cannot be
scaled and maintaining a high project cardinality is hard - at least to
me. The more servers, the harder releasing is.
I would also love to see the following work integrated in it:
- https://issues.apache.org/jira/browse/JAMES-3506 SMTP stach is slow
and generate high GC when under high traffic (because it is such a nice
enhancement counter-weighting drawbacks of JAMES-3477)
- https://github.com/apache/james-project/pull/303 JAMES-3499 Use a
module chooser for LDAP users repository
<https://github.com/apache/james-project/pull/303> (as it ease
maintainance efforts)
I think (sadly) ElasticSearch V7 migration (and ES V6 backport) will not
be ready on time for this release, unless additional efforts are
committed to this issue.
Thoughts?
Best regards,
Benoit
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Time for a 3.6.0 release
Posted by Matthieu Baechler <ma...@apache.org>.
Hi Benoit, Hi James devs,
Thank you for your email.
On Sun, 2021-02-28 at 14:45 +0700, Tellier Benoit wrote:
> Hey there!
>
> It's been almost a year (!) since we shipped some master code out in
> a
> release (the last release taking me over 3 months!).
We definitely need to release more frequently.
> As such, I think it would be important, as a project, to make such a
> release happen before the next Apache board meeting (mid. April). I
> devote myself to perform such a release (let's hope I will be more
> efficient this time!).
:+1:
> I would like to propose the following suggestion for this 3.6.0 release:
>
> - Claim experimental support for JMAP RFC-8621 and RFC-8887 (websocket
> transport)
> - As such deprecate JMAP Draft as of 3.6.0, to be removed in 3.7.0. (or
> later based on community usage) in order to encourage the migration.
> - Deprecate `server/container/guice/cassandra-guice` product.
> Rationals: it do not achieve distribution, this James server cannot be
> scaled and maintaining a high project cardinality is hard - at least to
> me. The more servers, the harder releasing is.
:+1:
>
> I would also love to see the following work integrated in it:
>
> - https://issues.apache.org/jira/browse/JAMES-3506 SMTP stach is slow
> and generate high GC when under high traffic (because it is such a nice
> enhancement counter-weighting drawbacks of JAMES-3477)
> - https://github.com/apache/james-project/pull/303 JAMES-3499 Use a
> module chooser for LDAP users repository
> <https://github.com/apache/james-project/pull/303> (as it ease
> maintainance efforts)
I don't care about how many additionals things we integrate as long as
we define a deadline for cutting the release.
Could you say we cut the release on 2021-03-15 ?
> I think (sadly) ElasticSearch V7 migration (and ES V6 backport) will not
> be ready on time for this release, unless additional efforts are
> committed to this issue.
It's sad but also it will be a good incentive to release a 3.8 release
in a not so distant future.
Cheers,
-- Matthieu Baechler
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Time for a 3.6.0 release
Posted by Tellier Benoit <bt...@apache.org>.
Hi Matthieu,
I think that the cut should be done on the later the 15/03, yes.
Regards,
Benoit
Le 02/03/2021 à 20:36, Matthieu Baechler a écrit :
> Hi Juhan,
>
> On Tue, 2021-03-02 at 11:10 +0200, Juhan Aasaru wrote:
>
> [...]
>
> > I think (sadly) ElasticSearch V7 migration (and ES V6 backport) will
> not
> > be ready on time for this release, unless additional efforts are
> > committed to this issue.
>
> Since James guice version currently uses Elasticsearch 6.x that has
> reached end of life
> and our system cannot go live with old Elasticsearch then we would be
> very interested in getting
> this upgrade into a release (preferably into 3.6.0) and put in work in
> this.
>
> I know my colleague Andreas has made an effort to add Elasticsearch 7
> support
> in James and as I understand it currently the problem is to get all the
> tests to
> pass in Elasticsearch 7 related modules. But it is unclear to me what
> is
> the plan
> to continue supporting Elasticsearch 6 in parallel.
>
> We probably won't be able to support both versions in the same product
> for a reasonable cost so I propose to drop ElasticSearch 6 support
> entirely.
>
>
>
> Would it be possible to have a quick recap of the remaining efforts
> needed.
> One place for this could be the Jira task:
> https://issues.apache.org/jira/browse/JAMES-3492
>
> If the work required to finish is not too large I could get Andreas
> to come back and work on this starting this Friday. Hopefully this way
> we have
> a chance to reach the release deadline (or at least have a second
> release
> shortly after the current on)
>
> Let's define a deadline. That way, rather it's ready on time and
> included or not.
>
> If you need some help to make it happen, you may find some people
> offering consulting, we are several to be able to do that on the
> mailing-list.
>
>
> > the last release taking me over 3 months!
>
> Benoit, could you please list the main problems why creating a release
> is time consuming so we could think solutions how some of this could be
> automated.
> For example if PGP signing and publishing artifacts to Maven Central is
> time consuming then this could be automated in great deal.
> I created a JIRA issue for this automation initiative:
> https://issues.apache.org/jira/browse/JAMES-3510
>
> Thanks, good idea.
>
> Regarding a release I have planned to raise a new topic that we as a
> community
> could think about a "long-term-support" release of James. Currently any
> James release is more like
> just a point in time marker but probably many of us have a vision that
> for a release we could create
> a separate branch and later only merge important security fixes there
> and then we could release patched versions like 3.6.1, 3.6.2 etc
> coming out in parallel with new main releases 3.7.0, 3.8.0 etc
>
> I'm interested in getting this set up and working on getting the
> patches
> identified and released
> but for this we would need to dramatically shorten the time and effort
> it takes to create a (minor/major) release.
> So this is why I would come back to "long-term-support-version" a bit
> later.
>
> If you want to handle that burden, that's awesome. I think nobody would
> be against having and LTS release for James.
>
> Cheers,
>
> -- Matthieu Baechler
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Time for a 3.6.0 release
Posted by Jean Helou <je...@gmail.com>.
>
> - First, previous release had been rejected once. And one time where we
> struggle to get the approval on time.
> - Second, the numerous maven project counts makes the upload (mvn
> deploy / mvn release prepare / perform) long. I generally plan a day,
> and do it on my laptop not to copy my GPG keys around. Which negatively
> impact my other tasks.
>
I have been working with infrastructure provisioning quite a bit recently,
maybe using a terraform project to create a vm or even baremetal computers
(i know at least scaleway offers baremetal instances which are not VM but
actual computers not shared with other tenants) and release from there is
acceptable ?
connect over ssh using gpg socket forwarding (this way the secret key never
leaves your computer) either clone from github or upload the repo from your
machine and trigger the release process.
This at least would let you use your laptop to do stuff while the release
occurs, it also provides access to extremely powerful computers [1] which
could make the release process much faster.
[1] https://www.scaleway.com/fr/tarifs/#serveurs-cloud-bare-metal GP-BM1-L
or HC-BM1-XS for €.33/hour/instance
Re: Time for a 3.6.0 release
Posted by Tellier Benoit <bt...@apache.org>.
Hi Matthieu, Hi Juhan,
Le 02/03/2021 à 20:36, Matthieu Baechler a écrit :
> Hi Juhan,
>
> On Tue, 2021-03-02 at 11:10 +0200, Juhan Aasaru wrote:
>
> [...]
>
> We probably won't be able to support both versions in the same product
> for a reasonable cost so I propose to drop ElasticSearch 6 support
> entirely.
+1
>
> Would it be possible to have a quick recap of the remaining efforts
> needed.
> One place for this could be the Jira task:
> https://issues.apache.org/jira/browse/JAMES-3492
>
> If the work required to finish is not too large I could get Andreas
> to come back and work on this starting this Friday. Hopefully this way
> we have
> a chance to reach the release deadline (or at least have a second
> release
> shortly after the current on)
>
> Let's define a deadline. That way, rather it's ready on time and
> included or not.
+1
> If you need some help to make it happen, you may find some people
> offering consulting, we are several to be able to do that on the
> mailing-list.
>
>
> > the last release taking me over 3 months!
>
> Benoit, could you please list the main problems why creating a release
> is time consuming so we could think solutions how some of this could be
> automated.
- First, previous release had been rejected once. And one time where we
struggle to get the approval on time.
- Second, the numerous maven project counts makes the upload (mvn
deploy / mvn release prepare / perform) long. I generally plan a day,
and do it on my laptop not to copy my GPG keys around. Which negatively
impact my other tasks.
To be fair, this one should be less of a problem to me this time.
- Third: changing priorities...
> For example if PGP signing and publishing artifacts to Maven Central is
> time consuming then this could be automated in great deal.
> I created a JIRA issue for this automation initiative:
> https://issues.apache.org/jira/browse/JAMES-3510
>
> Thanks, good idea.
>
> Regarding a release I have planned to raise a new topic that we as a
> community
> could think about a "long-term-support" release of James. Currently any
> James release is more like
> just a point in time marker but probably many of us have a vision that
> for a release we could create
> a separate branch and later only merge important security fixes there
> and then we could release patched versions like 3.6.1, 3.6.2 etc
> coming out in parallel with new main releases 3.7.0, 3.8.0 etc
>
> I'm interested in getting this set up and working on getting the
> patches
> identified and released
> but for this we would need to dramatically shorten the time and effort
> it takes to create a (minor/major) release.
> So this is why I would come back to "long-term-support-version" a bit
> later.
>
> If you want to handle that burden, that's awesome. I think nobody would
> be against having and LTS release for James.
>
> Cheers,
>
> -- Matthieu Baechler
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Time for a 3.6.0 release
Posted by Matthieu Baechler <ma...@apache.org>.
Hi Juhan,
On Tue, 2021-03-02 at 11:10 +0200, Juhan Aasaru wrote:
[...]
> I think (sadly) ElasticSearch V7 migration (and ES V6 backport) will
not
> be ready on time for this release, unless additional efforts are
> committed to this issue.
Since James guice version currently uses Elasticsearch 6.x that has
reached end of life
and our system cannot go live with old Elasticsearch then we would be
very interested in getting
this upgrade into a release (preferably into 3.6.0) and put in work in
this.
I know my colleague Andreas has made an effort to add Elasticsearch 7
support
in James and as I understand it currently the problem is to get all the
tests to
pass in Elasticsearch 7 related modules. But it is unclear to me what
is
the plan
to continue supporting Elasticsearch 6 in parallel.
We probably won't be able to support both versions in the same product
for a reasonable cost so I propose to drop ElasticSearch 6 support
entirely.
Would it be possible to have a quick recap of the remaining efforts
needed.
One place for this could be the Jira task:
https://issues.apache.org/jira/browse/JAMES-3492
If the work required to finish is not too large I could get Andreas
to come back and work on this starting this Friday. Hopefully this way
we have
a chance to reach the release deadline (or at least have a second
release
shortly after the current on)
Let's define a deadline. That way, rather it's ready on time and
included or not.
If you need some help to make it happen, you may find some people
offering consulting, we are several to be able to do that on the
mailing-list.
> the last release taking me over 3 months!
Benoit, could you please list the main problems why creating a release
is time consuming so we could think solutions how some of this could be
automated.
For example if PGP signing and publishing artifacts to Maven Central is
time consuming then this could be automated in great deal.
I created a JIRA issue for this automation initiative:
https://issues.apache.org/jira/browse/JAMES-3510
Thanks, good idea.
Regarding a release I have planned to raise a new topic that we as a
community
could think about a "long-term-support" release of James. Currently any
James release is more like
just a point in time marker but probably many of us have a vision that
for a release we could create
a separate branch and later only merge important security fixes there
and then we could release patched versions like 3.6.1, 3.6.2 etc
coming out in parallel with new main releases 3.7.0, 3.8.0 etc
I'm interested in getting this set up and working on getting the
patches
identified and released
but for this we would need to dramatically shorten the time and effort
it takes to create a (minor/major) release.
So this is why I would come back to "long-term-support-version" a bit
later.
If you want to handle that burden, that's awesome. I think nobody would
be against having and LTS release for James.
Cheers,
-- Matthieu Baechler
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Time for a 3.6.0 release
Posted by Juhan Aasaru <aa...@gmail.com>.
Hi!
> Let's define a deadline. That way, rather it's ready on time and
> included or not.
I propose the following
- Andreas has PR ready with all the tests passing by 12 March 16:00 UTC
- Let's leave time for code review and fixes that have to
be resolved by 16 March 16:00 UTC the latest (so two more working days)
This would postpone the cut one day. I hope that's ok.
If these deadlines are not met then Elasticsearch 7 support
will be left out from 3.6.0 release
> Speeding up release process.
Thanks Benoit for explaining the bottlenecks.
I think spending a day twice a year for a release is not a huge problem.
But it quickly becomes a bottleneck if we want to start releasing
bugfix/security update versions 3.6.1, 3.6.2 etc
Let's try to come up with some ideas and agreement here:
https://issues.apache.org/jira/browse/JAMES-3510
Kind regards
Juhan Aasaru
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Time for a 3.6.0 release
Posted by Juhan Aasaru <aa...@gmail.com>.
Hi Benoit and all the other James devs,
Thanks for good initiative for stepping up to creating the next release.
It is definitely an important aspect to have regular releases.
And there has been huge work done in terms of improvements and new features.
What would be best way to celebrate this achievement than creating a
release.
> I think (sadly) ElasticSearch V7 migration (and ES V6 backport) will not
> be ready on time for this release, unless additional efforts are
> committed to this issue.
Since James guice version currently uses Elasticsearch 6.x that has
reached end of life
and our system cannot go live with old Elasticsearch then we would be
very interested in getting
this upgrade into a release (preferably into 3.6.0) and put in work in this.
I know my colleague Andreas has made an effort to add Elasticsearch 7
support
in James and as I understand it currently the problem is to get all the
tests to
pass in Elasticsearch 7 related modules. But it is unclear to me what is
the plan
to continue supporting Elasticsearch 6 in parallel.
Would it be possible to have a quick recap of the remaining efforts needed.
One place for this could be the Jira task:
https://issues.apache.org/jira/browse/JAMES-3492
If the work required to finish is not too large I could get Andreas
to come back and work on this starting this Friday. Hopefully this way
we have
a chance to reach the release deadline (or at least have a second release
shortly after the current on)
> the last release taking me over 3 months!
Benoit, could you please list the main problems why creating a release
is time consuming so we could think solutions how some of this could be
automated.
For example if PGP signing and publishing artifacts to Maven Central is
time consuming then this could be automated in great deal.
I created a JIRA issue for this automation initiative:
https://issues.apache.org/jira/browse/JAMES-3510
Regarding a release I have planned to raise a new topic that we as a
community
could think about a "long-term-support" release of James. Currently any
James release is more like
just a point in time marker but probably many of us have a vision that
for a release we could create
a separate branch and later only merge important security fixes there
and then we could release patched versions like 3.6.1, 3.6.2 etc
coming out in parallel with new main releases 3.7.0, 3.8.0 etc
I'm interested in getting this set up and working on getting the patches
identified and released
but for this we would need to dramatically shorten the time and effort
it takes to create a (minor/major) release.
So this is why I would come back to "long-term-support-version" a bit later.
Kind regards
Juhan Aasaru
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org