Hello Jean Topic 1:
I think an ADR structure rework discussion was started on the mailing list already. Regarding this very example: - The principal of operating off a smal number of fixed buckets is likely an architecture decision. Worth recording in an ADR. It could decide to define an architecture principle. Then in the *context* we could list offending features and plugins and *consequences* list needed refactorings. - Having an ADR presenting why we have a plugin to fix a generic problem in the email world seems like a reasonnable choice to me. I often end up, in architecture discussions (and no later than yesterday!) to get discussion on this topic. Hence it feels justified to get a track record. Also this seems dangerous to me to say "not relevant, that's a plugin" as everything (the mailbox, the event-bus, etc) is somehow a plugin with guice binding and concern specific implementations and not others. Topic 2: Answers inlined. -- Best regards, Benoit TELLIER General manager of Linagora VIETNAM. Product owner for Twake-Mail product. Chairman of the Apache James project. Mail: [email protected] Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) Le janv. 15, 2026 4:13 PM, de Jean Helou <[email protected]>Since you called a formal vote I must vote -1 I may change my vote after the discussion has taken place. 2 topics on which I would like to see some discussion before voting : Topic 1 Why an ADR for an implementation detail in a plugin ? Maybe I'm just too new to james and/or need a refresher in what james considers and architectural decision. It feels to me that this should be part of the README for the plugin. I see that introducing the feature (the deleted message store) was also done through an ADR which seems a bit suprising to me. I dont disagree on the content of the files themselves (thought the ADR formalism is a bit weird for a README), it just doesn't match with my understanding of what ADRs are. I personnally would prefer to merge the content of both files in a README file on the plugin itself (to document the why and the implementation details of the plugin) and list the plugin out somewhere in the documentation ( it probably already is) to let people know the feature exist and where to find details about it. On the plugin evolution itself The currenty behaviour is to create a full s3 bucket following the pattern `deleted-messages-[year]-[month]-01` (it is unclear to me what the 01 represents, is it the day ?) Means first day of the month and was adopted to get something that looks like a date if I recall well/ According to the change proposed in the "ADR", the plugin would now store the same contents under a virtual path within a single bucker ` [year]/[month]/[blob_id]` The proposed migration strategy is : - - write only on the single bucket, fall back if necessary on old buckets for read and delete - - add the single bucket usage case to the purge task, that would do cleaning on both new and old buckets. I think we should work out right now for how long we intend to maintain the fallback and old behaviour in the clean task +1 typical retention is 1 year so going for 2 years seems reasonable. Likely a bit more to further ease the upgrade path. Probably also clearly communicate (changelog comes to mind) on the deprecation of the old behaviour so we can eventually remove both the fallback and the cleaning task. +1 However this has consequences on users ugrade path. As proposed they will have to install a version which has both the new behaviour and the fallback for at least the retention period of all the deleted messages in their system. Would you consider providing a migration tool that allows them to move their deleted messages to the new scheme and fast forward on the versions ? (maybe even skip as each versions embarks all the migrations from the previous versions IIRC) To be fair given it's simplicity I'd rather support the fallback 5 years rather than moving blobs around. Personal taste. I was away from home and had a small car crash so I didn't have time to look into 2902 yet. I had a quick look while writing this message and I was suprised to see an API change that affects the cassandra implementation and introduces something similar to a blobid factory (and used as such) but with a different type. I left a comment to that effect and will continue the review (probably tomorrow or during the weekend) I saw it and I will craft something around it, it seems like a relevant remark. jean Le jeu. 15 janv. 2026 à 14:23, Benoit TELLIER <[email protected]> a écrit : > > Hi all, > > > > > I would like to call a vote on the following change: > > - github.com/apache/james-project/pull/2894 ADR: Deleted message > vault single bucket usage > > - github.com/apache/james-project/pull/2902 which is the > implementation of the aforementioned ADR > > > The use of monthly buckets is problematic with certain S3 suppliers that > limit their count, and require extensive rights onto the object store > endpoints. > The proposal would address solely this problematic feature and not attempt > to refactor in depth the way James' bucket are encoded onto the S3 endpoint. > > (More context is provided onto the relevant ADR) > > > > This vote is open for at least 72 hours and requires a simple majority. > > > Please vote: > > > - +1 approve > > > - 0 no opinion > > > - -1 disapprove (please explain) > > > > Thanks, > > -- > > Best regards, > > Benoit TELLIER > > General manager of Linagora VIETNAM. > Product owner for Twake-Mail product. > Chairman of the Apache James project. > > Mail: [email protected] > Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) > > >
