Thank you so much for walking me through the history (and db theory in that matter here)
> I believe the original UI was (using this list as the parent, and "xyz" is a random token) > mail to [email protected] forks off a new list [email protected] So the workflow is basically an email-native issue tracker where specific tasks fork off into tokenized (-xyz) child lists so the users can join and leave (intuitively too)...although it makes me wonder whether if there are too many of the -xyz sublists created, then if the people are using these for every little troubleshooting task won't the database be overflowing with soo many of them? when postorius asks for the directory of mailinglists, should core be hiding these lists by default so the ui doesn't get cluttered? or is it better if the core just sends everything and lets the frontend do the filtering? > "Subscription" is a Python class in Mailman core. It has attributes for the Address and the MailingList that are subscribed, as well as the subscription's configuration of the user > parameters like no-mail. By default these are all set to "inherit"... So as the subscription class already handles inheritance by default, attaching an address to a newly generated child list should pull the required parameters( without the heavy replication) > In Mailman 3, addresses are rows in one table, mailing lists are rows in another, and subscriptions are a many-to-many relation (table) joining addresses and lists... suddenly the idea that a sublist is just a mailing list doesn't seem so odd. So since mm3 relies on relational many-to-many join tables rather than hierarchical nested objects, a child list is just another row in the mailinglists table with a handful of subscription rows mapped to the addresses...thinking about it simply as an efficient database join rather than an isolated process makes this approach feel intuitive. Thanks again Regards Archie On Wed, Mar 18, 2026 at 1:51 AM Stephen J. Turnbull <[email protected]> wrote: > Archie Singh via Mailman-Developers writes: > > > I get it and you are right, a better use case would be some kind of > > user support lists where users maybe wish to follow some particular > > troubleshooting thread than core developer lists (as every thing is > > lowkey interconnected here) > > Exactly. I don't think it was you, I wrote to someone that the > original use case was basically as an issue tracker. There's be a > project list, the main line was discussions of architecture, UX, > look-and-feel, etc, and specific tasks (fixes or features) would fork > off a sublist. > > > This is my fault, I was working from the gsoc hour targets > > That's kind of an "attractive nuisance" (like a backyard swimming pool > with no fence that toddlers fall into) in the way the program is set > up. > > > So, if I am understanding correctly, you mean i should disregard > > building a new db schema to track the message_id and instead think > > of dynamic sublists as a mailinglist object in itself with a > > (parent) id that points to the main list (and the subscription > > relationship (address id linked to mailinglist) is standard mailman > > convention). > > Yes. I think that is sufficient to get a good match to the original > feature implemented by the Systers. > > > > Although, if a sublist is supposed to be dynamic then should this new > child > > mailing list object be produced as soon as someone adds a -follow > (assuming > > addition to email cli) command on a thread...as opposed to an admin > having > > to create it manually? > > The original concept was entirely email-based. Systers is a global > organization with a lot of members in places that did not have > reliable Internet, a web-based workflow was not viable for some of > their projects. They did add web UIs over time, but the core concept > was all email. > > I believe the original UI was (using this list as the parent, and > "xyz" is a random token) > > - mail to [email protected] forks off a new list > [email protected] > - The -new mail contains the description of the sublist, and it is > sent to both mailman-developers and to > - Users join the new list by sending mail to mailman-developers-xyz-join > and the rest of the administrative addresses work in the same way > > > Okay, so to preserve the existing ux patterns, the subscription should > be > > directly linked to the address object within the context of the child > list > > object > > "Subscription" is a Python class in Mailman core. It has attributes > for the Address and the MailingList that are subscribed, as well as > the subscription's configuration of the user parameters like no-mail. > By default these are all set to "inherit" (from the MailingList > settings, the Address settings, or the User settings). > > > Naturally. I was applying the social media model to mailing lists (i > just > > got carried away)...do you think (as stated on the website for proposal > > ideas) that lookign at the original anitaborg/systers implementation of > > dynamic sublists built on mm2 (and i do understand that mm2 and mm3 have > > very different architectural patterns) would help me understand the user > > experience and email commands to trigger sublists...or should I just > think > > about the command flow (and ux) from scratch for mm3? > > I think you should definitely look at their implementation to > understand the email command interface and how a sublist gets set up, > and populated with subscriptions. I don't think having a web UI will > constrain that much at all. If you have original ideas, let's discuss > them. But (at least in past years) architecture isn't your job in > GSoC -- if you want to model the Systers implementation as closely as > possible, that's entirely consistent with the intent of the GSoC rules. > > Mailman 3 adopted a lot of architectural features from Mailman 2. In > particular, the MailingList, Address, and Subscription classes are > largely unchanged. Addition of the User class to manage > authentication and Addresses, and splitting the pipeline of handlers > into Chains of Rules (moderation, basically) and Pipelines of Handlers > (message modification, generation of recipients, and actually sending > mail) are big changes but they didn't affect the core user-visible > objects except for the introduction of Users, and Users don't affect > the semantics of relations among MailingLists, Addresses, and > Subscriptions at all. > > > > I think the answer to that is "it's just handled like a list". > > > > understood, considering the sublist is itself a mailing list, it has its > > own pipeline...so no need to build a custom handler to inject in the > main > > pipeline to do set intersections at all. The standard handler that deals > > with returning the address ids will pull the addresses subscribed to > that > > child list (if my earlier assumption about child list objects was right) > > The database implementation is *really* different. In Mailman 2, it > was hierarchical: The mailing list object had a roster attribute, and > the roster contained subscriptions, which had addresses (just strings) > and various user options for the subscriptions. In Mailman 3, > addresses are rows in one table, mailing lists are rows in another, > and subscriptions are a many-to-many relation (table) joining > addresses and lists. And a database manager like PostgreSQL is built > to handle billions of such rows in each table (Apple has billions of > users so they may actually have a database that big!!) > > But then you realize that subscriptions are just rows (and pretty > short ones, at that) in a long table and a mailinglist only uses a few > of them. A sublist is just a mailing list with a parent that gets its > roster from > > SELECT * FROM mailinglists WHERE posting=' > [email protected]'; > > suddenly the idea that a sublist is just a mailing list doesn't seem > so odd. > > Steve > > > -- > GNU Mailman consultant (installation, migration, customization) > Sirius Open Source https://www.siriusopensource.com/ > Software systems consulting in Europe, North America, and Japan > _______________________________________________ Mailman-Developers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
