>>>>> "BR" == Brock Rozen <firstname.lastname@example.org> writes:
BR> Let's figure out what issues have to be dealt with in deleting lists.
But note also the importance of not over-thinking things.
BR> Actually deleting it (removing list files and aliases)
Which is basically the only functionality that the "delete list" command
needs to handle.
BR> Notifying subscribers (and allowing a quiet option)
That's an orthogonal issue. The owner can just post a message if they so
desire. Eventually I'll write that mail-merge command so that you can send
out a "personalized" message.
BR> Changing aliases to have messages sent to the list-owner for a period
BR> of time (even after deletion), for lists that have moved to a different
I don't agree. The list owner can set this up ahead of time by other
perfectly valid means. When the actual "delete list" command is run, the
list should be deleted, messages to it should bounce, etc. If you can
still mail to it (i.e. it still has aliases and an owner) then it has a
configuration and hasn't been deleted.
Note also that we provide the 'forward' mechanism to automatically handle
lists that have moved to another system (by actually forwarding the
BR> Archives (allow deletion or keeping them around)
Again, if the archives are still retrievable through Majordomo then the
list must still exist. Sure, it may not have any subscribers and you can't
post to it but it is still a perfectly valid list.
BR> Anything else?
Well, much, much less than that.
The naive implementation deletes the list directory.. The complex
implementation checks to see that the list has no members first. All other
functionality that you mention belongs somewhere else.
BR> And, IMHO, only the mj system owner can remove a list. list-owner's
BR> should NOT have this functionality.
I think I agree, especially since I'll probably just implement this as part
of the createlist command: