[Mailman-Users] Upgrading/migrating Mailman v2.1.9 -> v2.1.18-1

[Chris Nulk]

On 1/14/2015 7:57 AM, Mark Sapiro wrote:

Thanks for your help Mark.

> On 01/13/2015 09:04 PM, Chris Nulk wrote:
>> Are there any issues I should watch for using the following process?
> ...
>> Does the process seem reasonable and workable?
>
> It looks OK to me.
Great.
>> The question about customizations is how different is the code between
>> v2.1.9 and 2.1.18-1?
>
> Many modules are unchanged. Some have significant changes. Some have
> minor changes.

Below is a list of the files I have modified (base directory is 
/usr/lib/mailman).  Should I pay special attention due to changes to any 
particular files?

bin/add_members
bin/non_members
Mailman/LDAPMemberships.py
Mailman/ListAdmin.py
Mailman/MailList.py
Mailman/Version.py
Mailman/versions.py
Mailman/Cgi/listinfo.py
Mailman/Cgi/options.py
Mailman/Gui/GUIBase.py
Mailman/Gui/Privacy.py
Mailman/Handlers/Decorate.py
Mailman/Handlers/Moderate.py
Mailman/Queue/IncomingRunner.py


>
>
>> If I create patches with the difference between the original v2.1.9 code
>> and my customizations using diff -Nu, will I be able to apply those patches
>> to the v2.1.18-1 code?
>
> That's the way to go. See the recent post at
> <https://mail.python.org/pipermail/mailman-users/2015-January/078261.html>
> for more on this.
Yep.  Read the message.  Thanks for the reminder.
>
>> Naturally, I will make copies of any files that will be changed before
>> applying the patches.  Also, since I do add additional attributes to the
>> list configs, I will be very careful with changes to versions.py and
>> Version.py.
>
> Your main concern is with DATA_FILE_VERSION in Versions.py. As long as
> you apply the changes before moving the lists You just need to be sure
> that DATA_FILE_VERSION is > than that of the old installation. Then
> versions.py will be run to update the lists when they are moved.
>
> As far as additional attributes are concerned, you could ignore the
> whole issue. I wouldn't if for no other reasons than documentation and
> consistency, but your lists will presumably have all the additional
> attributes already so the code in versions.py to add them (if missing)
> won't do any harm, but won't actually be needed. As I said though, I
> would ensure the code was there just for documentation and consistency
> and in case at some point you migrate a list that doesn't have the
> attributes.
>
I will definitely make the mods prior to moving the lists since I will 
want to make sure Mailman is still functional.

I will also most likely do the same thing I did when I did the original 
mods to Version.py and versions.py.  I will bump the DATA_FILE_VERSION 
by one and make only the minimal change needed. Actually, here are the 
two patch files I plan on using for those two files.  So I will make 
copies of the original files (for all files to be modified) and for 
Version.py I will check for the current DATA_FILE_VERSION number and 
adjust appropriately.

Patch for Version.py
---------------------------
--- Version.py.original    2008-05-24 13:44:12.000000000 -0700
+++ Version.py.Modified    2009-09-25 10:47:02.000000000 -0700
@@ -37,7 +37,9 @@
                 (REL_LEVEL << 4)  | (REL_SERIAL << 0))

  # config.pck schema version number
-DATA_FILE_VERSION = 96
+# Updated the DATA_FILE_VERSION due to adding a new
+#    variable/attribute (previous value = 96) --Modified 24-Sep-2009
+DATA_FILE_VERSION = 97

  # qfile/*.db schema version number
  QFILE_SCHEMA_VERSION = 3

Patch file for versions.py
---------------------------------
--- versions.py.original    2008-05-24 13:44:12.000000000 -0700
+++ versions.py.Modified    2009-09-24 14:15:11.000000000 -0700
@@ -113,6 +113,11 @@
          l.forward_auto_discards = mm_cfg.DEFAULT_FORWARD_AUTO_DISCARDS
      if not hasattr(l, 'generic_nonmember_action'):
          l.generic_nonmember_action = 
mm_cfg.DEFAULT_GENERIC_NONMEMBER_ACTION
+
+    # Add an additional list attribute if not present --Modified 
24-Sep-2009
+    if not hasattr(l, 'accept_special_posters'):
+        l.accept_special_posters = []
+
      # Now convert what we can...  Note that the interaction between the
      # MM2.0.x attributes `moderated', `member_posting_only', and 
`posters' is
      # so confusing, it makes my brain really ache.  Which is why they 
go away


Thanks again for the assistance Mark,
Chris