+1 for all components Le jeu. 28 mars 2019 à 09:47, Gautier DI FOLCO <[email protected]> a écrit :
> +1 for all components (if I'm allowed to vote) > > Le 28/03/2019 à 09:30, Benoit Tellier a écrit : > > +1 for all components > > > > Unless we find contributors for them, of course. > > > > 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: [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] > >
