Le 29/09/2020 à 17:47, Matthieu Baechler a écrit :
> On Tue, 2020-09-29 at 08:59 +0700, Tellier Benoit wrote:
>
> [...]
>
>> Spring deprecation could be seen as this big event for most users ?
>
> You are not very good at public relation, do you? (:
> I don't see feature deprecation as a good opportunity to increment
> major version number.
With Spring deprecation comes Guice applications.
Today they are not even available as a download option, so nobody uses them.
(this should be fixed by the way for the next minor release)
I believe, with all the changes and features that comes with Guice
application, a major release could be justified.
Of course we should not communicate in a "stop spring" way as I did it.
Also I found this link helpfull (and I should try applying it more to my
writings here): https://infra.apache.org/contrib-email-tips.html
" Try not to use the word "you". People get defensive when they think
that comments are directed at them personally. Consider using "one" or
"we" or even "me". "
>
>>> 4. About defining a vision
>>>
>>> [...]
>>>
>>> What I would really like is to break things! Let's remove all
>>> these anachronic modules, or even better: let's build James 4 by
>>> adopting only well selected modules, ones that are here for a purpose.
>> I do think that such an effort will end up with similar effects for the
>> community than the 3.0 release effort.
>
> I agree to some extent.
>
>> What I am looking for is a scalable, modern mail server, we mostly have
>> that already (after 5 years of development which is already a huge
>> commitment).
>
> I know that it's Linagora intent. However, you are still slow to reach
> that goal partly because of James codebase size. Also, you will keep
> having a clutered product that most people won't see as a "scalable,
> modern mail server".
We agree on the symptoms.
The problem here is that "Linagora" problem about code base size becomes
a community problem.
>> [...]
>
> How it is different from what we did for years? Did it solve velocity
> issues? Is the project fun now?
>
> I may start this 3.99 thing on my fork to see how it goes and will keep
> you posted about that.
We deprecated unmaintained outdated components with no active contributors.
Maybe what we should do is discuss what we want to reach as a project.
As a project (as I understood it) we want to answer our end user needs
(self hosting, the distributed server, easy to extend behavior). We
spoke a lot about it lately.
That being said maybe our goal as a project is not to offer a fully
featured email server that we can plug directly into in a collaborative
platform. (our goal at Linagora is to do just that, but our goal as an
Apache project is to *enable* people doing that).
But our goal is more to enable people to do that.
I believe that, going down that road, and removing things, even
maintained, well-written, that ended up in the Apache James code base by
accident (with the classic deprecation / removal procedure)
Third parties, including Linagora, will of course be free to backport them.
I believe it will:
- enhance the governance of the project
- simplify the code base
- force us to have well working extension systems
However (relative) API stability will be needed.
But this could be done "reasonably quickly" with the 3.x code base.
This is what I meant, and as far as I know we never done that.
Sorry for explaining myself elusively.
>
> Cheers,
>
> -- Matthieu Baechler
As a conclusion, I'm sure there is a way to arrange the way Linagora
contributes to the Apache James project so that I feel for confident
endorsing both hats at the same time.
It's a long lasting problem, but trying to solve it will in my opinion
solve some of the problems we encounter as a community.
Cheers,
Benoit
>
>
> ---------------------------------------------------------------------
> 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
