Hi, I am glad to announce you that the following proposition had been accepted.
- Votes for: +5 with a quorum of 3 PMC - Votes against: 0 See the following pull request: https://github.com/linagora/james-project/pull/2293 Cheers, Benoit Tellier On 28/03/2019 15:26, Benoit Tellier wrote: > Hi, > > In order to improve overall James development experience, I propose to > do a bit of post 3.3.0 cleanup. > > The proposal is to mark the given components as deprecated now, then, if > no contributor shows up and give some love to these components, remove > it after 3.4.0 release. > > I do propose a vote to ensure consensus on it: > - Answer this mail with "+1 for all components" to support all these > deprecations > - Answer this mail with "-1 for all components" if you reject the idea > of removing components > - Answer this mail with "+1 [components] -1 [components]" to express > per component not favorable opinion. > > Negative votes should be motivated (and ideally have contributors for > these components). Voting ends on 4th April 9am UTC > > Here are the rationals: > - Some components are not exposed to end users and affect our hability > to refactor code. > - These components do not receive contributions > - These components are not well enough tested > - We introduced some components that are better at performing that very > task > > See associated ticket: https://issues.apache.org/jira/browse/JAMES-2703 > > The components are: > > ## mailbox > > - mailbox/cache > Unused, not tested, low code quality > End user will not be affected by this removal > > ## server/data > > - SieveDefaultRepository > Read the filesystem to retrieve sieve scripts, read only, one file > per user > This does not support sieve script management and rtequires dropping > manually the filesystem > Migration strategy: use SieveFileRepository & CLI to upload scripts > > - MBoxFileRepository > Already deprecated, will target removal after 3.4.0 > Use FileMailRepository instead. Data migration can be done with > reprocessing + specific configuration > > - JDBCRecipientRewriteTable > Already deprecated, will target removal after 3.4.0 > Use another RRT implementation > > - AbstractJdbcUsersRepository DefaultUsersJdbcRepository & > JamesUsersJdbcRepository > Already deprecated, will target removal after 3.4.0 > Use another UsersRepository implementation > > ## mailets > > Note: these mailets are leveraging some storage capabilities of mailbox > or server/data. > > - AbstractRecipientRewriteTable > Already deprecated, will target removal after 3.4.0 > The mailet is responsible of the rule storage. No tests. > Note that this would allow removing JDBCRecipientRewriteTable and > XMLRecipientRewriteTable. > Migration plan: add the rules in the standard RRT and use the classic > RRT mailet. > > - JDBCAlias > Already deprecated, will target removal after 3.4.0 > This mailet does the RRT. No tests. > Migration plan: add the rules in the standard RRT and use the classic > RRT mailet. > > - UsersRepositoryAliasingForwarding > Already deprecated, will target removal after 3.4.0 > This buggy mailet expects the UsersRepository to be also a > RecipientRewriteTable. Hopefully we have no such freaks. > Otherwize behaves as the classic RRT mailet. > Migration: Replace in the configuration by the classic RRT mailet > > - MailboxQuotaFixed, AbstractStorageQuota, AbstractQuotaMatcher > Not using the quota API, these matchers do full inbox scans on each > processed email. > It adds confiusion with the non-experimental well tests IsOverQuota > matcher, relying on the mailbox quota system. > No test, big hierarchy > Migration plan: Use IsOverQuota + quota APIs > > --------------------------------------------------------------------- > 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
