[Mailman-Developers] Newlist/rmlist update

[Marc MERLIN]

On Wed, Jan 02, 2002 at 10:45:59AM +0100, Marc MERLIN wrote:
> On Tue, Jan 01, 2002 at 03:26:11PM -0500, Barry A. Warsaw wrote:
> > 
> > >>>>> "MM" == Marc MERLIN <marc_news@vasoftware.com> writes:
> > 
> >     MM> As promised, here's a patch that:
> >     MM> 1) Adds the SPLIT_DIRS option which does this:
> > 
> > Some questions: what if you already have an `m' list or a `t' list?  I
> 
> I thought  about list  names of  less than 3  characters to  see if  the dir
> hashing would work, but I forgot about this case.
> So basically,  it means that  it'll get  a bit ugly  if you have  one letter
> listnames.
> For that  matter, it should work,  but your 't' list  would have directories
> with other lists inside of it, not very pretty.
> 
> In other words we need at least a disclaimer in Default.py that if you turn
> the option on, you'd better have at least 2 letters for all your lists.

Actually, I just realized that if you have a list named 'a', and you try to
delete it, my  current rmlist code will  blow away all the  lists that start
with 'a'.
I think  the best  fix to this,  instead of making  mailman too  complex, or
removing the  flexibility of  running a  dual setup (with  both old  and new
lists), is
1) Document that all lists need to have at least two letters above the
   setting in Defaults.py
2) Patch newlist and rmlist further to refuse to deal with one letter lists.

For #2, we can do it in the following ways:
a) all the time (even if you don't have split_dirs enabled)
b) only if split_dirs is enabled (that would mean that if you enabled it and
   disabled it later, and then you try to delete list 'a', it will blow away
   all the lists that start with 'a' and that were created when split_dirs
   was enabled
c) As soon as split dirs is enabled and a list is created, newlist drops a
   ~mailman/lists/.splitdirs_do_not_delete file, and after that refuses to
   create  or delete  one  letter  lists whether  the  setting is  currently
   enabled or not

I do realize that  none are ideal or foolproof, but I  expect that few users
are ever going to use this, and  even fewer will toggle the setting back and
forth. I believe choosing (b) or (c) and documenting appropriately should be
enough.

What do you think?

Marc
-- 
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
  
Home page: http://marc.merlins.org/   |   Finger marc_f@merlins.org for PGP key