From ckolar@admin.aurora.edu Fri Oct 1 15:10:51 1999 From: ckolar@admin.aurora.edu (Christopher Kolar) Date: Fri, 1 Oct 1999 09:10:51 -0500 Subject: [Mailman-Developers] feature requests Message-ID: <99100109180002.09732@kolar.facnet.aurora.edu> While beating on the documentation a few things came to mind. 1. Any chance that the monthly reminder can be used by a bounce handler script as a membership probe (good for low-volume lists). Right now I just get N bounce messages as mailman-owner but I do not see that the list manager ever gets the information. 2. How about adding an "invite" feature like on some of the commercial list providers. The invite would be non-binding, but a simple reply would add the person to the list (I suppose that it would use most of the same code that the sub-confirmation bits use). See listbot and egroups if you do not know what I am talking about. 3. How about a chunk of html code that can be dropped into a web page that would allow a person to just type in their e-mail and click to make a sub request (also something that listbot/egroups do). The request could be handled like a normal sub request with a confirmation request being sent out to the e-mail address that was entered. Is this already possible by hacking the listinfo page to remove everything but the field for e-mail address and the submit button? I deal with a lot of novice users and I would like to take out a lot of the verbiage and the initial password setting. Cheers, --chris -- /////\\\\\/////\\\\\ Christopher G. Kolar Director of Instructional Technology Aurora University, Aurora, Illinois ckolar@admin.aurora.edu -- www.aurora.edu [PGP Public Key ID: 0xC6492C72] From jye@helios.physics.utoronto.ca Tue Oct 5 16:39:26 1999 From: jye@helios.physics.utoronto.ca (Jun Ye) Date: Tue, 5 Oct 1999 11:39:26 -0400 (EDT) Subject: [Mailman-Developers] sublists & Implicit Destination Message-ID: <199910051539.LAA663053@helios.physics.utoronto.ca> Hi, there I just installed Mailman several days ago. However, when a list contains sub-lists, every post requires my approvals on all levels of sub-lists. So one post may require the owner(s) to approve many times. Pain ! Look at this: Your authorization is required for a mailing list posting request approval: List: (list name) Reason held: Implicit destination Can I disable this "feature" site-wise and/or list-wise ? Any one can offer quick advice how to fix it ? P.S. I posted this question on user list but no body reply. So I now count on your guys. Thanks !!! Jun From ddickey@wamnet.com Tue Oct 5 17:26:02 1999 From: ddickey@wamnet.com (Dan A. Dickey) Date: Tue, 05 Oct 1999 11:26:02 -0500 Subject: [Mailman-Developers] sublists & Implicit Destination References: <199910051539.LAA663053@helios.physics.utoronto.ca> Message-ID: <37FA269A.EAD9390@wamnet.com> Jun Ye wrote: > > Hi, there > > I just installed Mailman several days ago. > However, when a list contains sub-lists, > every post requires my approvals on all levels > of sub-lists. So one post may require the owner(s) to > approve many times. Pain ! > > Look at this: > > Your authorization is required for a mailing list posting request > approval: > > List: (list name) > Reason held: Implicit destination > > Can I disable this "feature" site-wise and/or list-wise ? > > Any one can offer quick advice how to fix it ? > > P.S. I posted this question on user list but no body reply. > So I now count on your guys. Thanks !!! Yes, this is possible to do. Let me try to recall what we did here... On the Privacy Options page, set the "Must posts have list named in destination field..." to No. And, in the box right below that, "Alias names (regexps) which qualify as explicit..." fill in the 'top-level' list that the emails come from. You'd do both of these on all of the sub-lists, and nothing on the top level list. For example, suppose you have top-listA, and sub-listB, and sub-listC. top-listA includes sub-listB and sub-listC as members. On the Privacy Options page for both sub-listB and sub-listC, you need to set the require_explicit_destination option to No as described above; and also set the acceptable_aliases option to top-listA. Give that a try! I hope it helps. -Dan -- Dan A. Dickey ddickey@wamnet.com From jafo@tummy.com Wed Oct 6 16:43:58 1999 From: jafo@tummy.com (Sean Reifschneider) Date: Wed, 6 Oct 1999 09:43:58 -0600 Subject: [Mailman-Developers] List archiving broken? Qmail? Message-ID: <19991006094358.A23871@tummy.com> In tracking down why my list archiving has not been functioning, I've found that the .mbox files do not have a 'From ' line at the beginning of each message. I'm forced to wonder if this is a problem with QMail, but normally my mbox format files written from qmail seem to be fine... To work around this, I've added the following lines to the ArchiveMail() function in Archiver/Archiver.py: # archive to builtin html archiver + if not msg.unixfrom: + import time + msg.unixfrom = 'From unknown %s\n' % time.ctime(time.time()) import traceback This seems to cause the archives to begin functioning quite nicely. I would submit that this should probably be there as a fail-safe. Any ideas why the From line might not be getting preserved though? Sean -- That weapon will replace your tongue. You will learn to speak through it. And your poetry will now be written with blood. -- _Dead_Man_ Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. From cherub@azrael.dyn.cheapnet.net Thu Oct 7 04:19:38 1999 From: cherub@azrael.dyn.cheapnet.net (Steven Hazel) Date: Wed, 6 Oct 1999 22:19:38 -0500 (CDT) Subject: [Mailman-Developers] Re: Mailman and your code for online posting In-Reply-To: (message from Susan Snell on Wed, 6 Oct 1999 21:55:43 -0500 (CDT)) References: Message-ID: I hope you don't mind if I cc my reply to the Mailman developers list. Is the code that you submitted to the developers list going to be incorporated into a subsequent release of Mailman? I hope so. It got no response, so I'm not quite sure what's up. When I have more time on my hands I plan to keep my changes current with both the latest release and CVS versions of Mailman and distribute them myself. I figure that should be enough to get an answer one way or the other from the Mailman developers, at least. I'm not familiar with Python and I'd like to get away without me having to make code changes on my system. I'd probably somehow manage to mess things up. If your changes aren't going to be incorporated then I guess I'll have to roll up my sleaves and jump right in. I'd be happy to help you with any problems you have. My other question is have you ever run across an existing list application which allows you to post online in addition to the normal mailing list functionality? Nope. -S From troy@graphon.com Thu Oct 7 21:45:00 1999 From: troy@graphon.com (Troy Morrison) Date: Thu, 07 Oct 1999 13:45:00 -0700 (PDT) Subject: [Mailman-Developers] List archiving broken? Qmail? In-Reply-To: <19991006094358.A23871@tummy.com> Message-ID: qmail does not add a "From " line when it delivers the message into the mailbox. I did something like this for my archives (which aren't using the archiving built into mailman): What I did was to subscribe archives-{listname} to each list I support, and then I have an 'archives' user whose home directory has a '.qmail-default' that does: |preline cat >> ./$DEFAULT && exit 0 man preline for more information. Preline adds the 'From ' line. Troy On 06-Oct-99 Sean Reifschneider wrote: | In tracking down why my list archiving has not been functioning, | I've found that the .mbox files do not have a 'From ' line at | the beginning of each message. I'm forced to wonder if this | is a problem with QMail, but normally my mbox format files | written from qmail seem to be fine... | | To work around this, I've added the following lines to the | ArchiveMail() function in Archiver/Archiver.py: | | # archive to builtin html archiver | + if not msg.unixfrom: | + import time | + msg.unixfrom = 'From unknown %s\n' % time.ctime(time.time()) | import traceback | | This seems to cause the archives to begin functioning quite nicely. | | I would submit that this should probably be there as a fail-safe. | Any ideas why the From line might not be getting preserved though? | | Sean | -- | That weapon will replace your tongue. You will learn to speak through | it. And your poetry will now be written with blood. -- _Dead_Man_ | Sean Reifschneider, Inimitably Superfluous | URL: HP-UX/Linux/FreeBSD/BSDOS scanning | software. | | _______________________________________________ | Mailman-Developers maillist - Mailman-Developers@python.org | http://www.python.org/mailman/listinfo/mailman-developers -- Troy Morrison From jafo@tummy.com Fri Oct 8 13:09:03 1999 From: jafo@tummy.com (Sean Reifschneider) Date: Fri, 8 Oct 1999 06:09:03 -0600 Subject: [Mailman-Developers] List archiving broken? Qmail? In-Reply-To: ; from Troy Morrison on Thu, Oct 07, 1999 at 01:45:00PM -0700 References: <19991006094358.A23871@tummy.com> Message-ID: <19991008060903.O997@tummy.com> On Thu, Oct 07, 1999 at 01:45:00PM -0700, Troy Morrison wrote: >|preline cat >> ./$DEFAULT && exit 0 Of course... What *WAS* I thinking. :-) I still think it's probably a good idea to fake one if we didn't get one (since the archiving needs it). The real fix is, of course, to insert "preline" at the beginning of the aliases for the mailing list wrapper. So, that patch I submitted for qmail aliases should be changed as the following: *** bin/newlist.old Fri Oct 8 06:01:58 1999 --- bin/newlist Fri Oct 8 05:59:08 1999 *************** *** 104,112 **** aliases = ''' To create system aliases: ! echo '|%(wrapper)s post %(listname)s' >~alias/.qmail-%(list)s ! echo '|%(wrapper)s mailowner %(listname)s' >~alias/.qmail-%(admin)s ! echo '|%(wrapper)s mailcmd %(listname)s' >~alias/.qmail-%(request)s echo '&%(listname)s-admin' >~alias/.qmail-%(owner1)s echo '&%(listname)s-admin' >~alias/.qmail-%(owner2)s chmod 644 ~alias/.qmail-%(list)s ~alias/.qmail-%(admin)s --- 104,112 ---- aliases = ''' To create system aliases: ! echo '|preline %(wrapper)s post %(listname)s' >~alias/.qmail-%(list)s ! echo '|preline %(wrapper)s mailowner %(listname)s' >~alias/.qmail-%(admin)s ! echo '|preline %(wrapper)s mailcmd %(listname)s' >~alias/.qmail-%(request)s echo '&%(listname)s-admin' >~alias/.qmail-%(owner1)s echo '&%(listname)s-admin' >~alias/.qmail-%(owner2)s chmod 644 ~alias/.qmail-%(list)s ~alias/.qmail-%(admin)s Sean -- Today's robots are very primitive, capable of understanding only a few simple instructions such as 'go left', 'go right', and 'build car'. -- John Sladek Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. From M. Bruce Cronlund" I am considering using your Mailman product for managing an announcement only type mailing list that will be going out to approximately 8,000 recipients. One question that I have, that I can't seem to find a quick answer for anywhere, is whether there are any limitations placed on the number of addresses that can be assigned to a list. In other words, could I use Mailman for 8 - 10,000 recipients? I thank you for your response. --------------------------------- M. Bruce Cronlund Digital Wave Technologies mailto:brucec@digitalwave.com 215-938-6611 Pager: 215-891-4676 "Things should be made as simple as possible -- no simpler." --Albert Einstein From claw@ Fri Oct 8 19:11:49 1999 From: claw@ (J C Lawrence) Date: Fri, 08 Oct 1999 11:11:49 -0700 Subject: [Mailman-Developers] request for information In-Reply-To: Message from "M. Bruce Cronlund" of "Fri, 08 Oct 1999 13:10:27 EDT." <000301bf11b0$04cca520$3301500a@frezza.stp.tvol.net> Message-ID: On Fri, 8 Oct 1999 13:10:27 -0400 M Bruce Cronlund wrote: > I am considering using your Mailman product for managing an > announcement only type mailing list that will be going out to > approximately 8,000 recipients. One question that I have, that I > can't seem to find a quick answer for anywhere, is whether there > are any limitations placed on the number of addresses that can be > assigned to a list. In other words, could I use Mailman for 8 - > 10,000 recipients? There are no real limits. I've successfully run MailMan lists with up to 150,000 members. -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From claw@varesearch.com Sat Oct 9 06:55:03 1999 From: claw@varesearch.com (J C Lawrence) Date: Fri, 08 Oct 1999 22:55:03 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] (help required) Timeout Problems with Large Mailing list In-Reply-To: Message from J C Lawrence of "Fri, 08 Oct 1999 11:15:45 PDT." Message-ID: > From: J C Lawrence wrote: Sorry about that. Fixed. -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From Robert@grapevine2.com Sat Oct 9 15:45:42 1999 From: Robert@grapevine2.com (Robert) Date: Sat, 09 Oct 1999 10:45:42 -0400 Subject: [Mailman-Developers] Timeout Problems with Large Mailing list Part II In-Reply-To: References: <4.2.0.58.19991008114953.00963980@pop.gv2.com> Message-ID: <4.2.0.58.19991009103325.00b90100@pop.gv2.com> Hi! At 11:15 AM 10/8/99 -0700, you wrote: >On Fri, 08 Oct 1999 11:59:44 -0400 >Robert wrote: > > > I'm serious....we want to add roughly 20-40,000 new Email > > addresses to existing 30,000 Email addresses mailing list. > >Not a problem. There are a few timeout and response time problems >when using the web interface for adding large numbers of >subscribers. These *may* have been fixed now (I haven't checked, >but there was discussion on the area). > >More simply however you can use the commandline bin/add_members >script. I've successfully run this on files containing as many as >5,000 addresses (that's how they were provided to me). > > > I'm seriously considering using this new mailing list manager: > > Subscribe Me Professional by Elite's CGI Script Center at > > http://www.cgiscriptcenter.com/ for $149.00 Any comments on this > > one compared to Mailman? The only nice thing about this Subscribe > > Me Professional is their support forum, which the real > > knowledgeable people will answer any good questions. > >MailMan is a free software product. Support is of course on a best >effort basis, and perhaps more significantly, on an "as willing" >basis. It still timeouts when adding the large Email addresses to the mailing list. Also, when the Mailman is running (processing 35,000 Email addresses 2 times), we could not access to the web site: http://deafdigest.net/mailman/cgi-bin/listinfo.cgi/deafdigest_web Bug in Mailman version 1.0rc3 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (innermost last): File "/home/mailman/scripts/driver", line 84, in run_main from Mailman.Logging.StampedLogger import StampedLogger File "/home/mailman/Mailman/Logging/StampedLogger.py", line 18, in ? from Logger import Logger File "/home/mailman/Mailman/Logging/Logger.py", line 22, in ? from Mailman.Utils import reraise File "/home/mailman/Mailman/Utils.py", line 33, in ? import random File "/usr/lib/python1.5/random.py", line 18, in ? from whrandom import random, uniform, randint, choice # Also for export! ImportError: No module named whrandom Environment variables: VariableValue DOCUMENT_ROOT /home/barry HTTP_ACCEPT_ENCODING gzip, deflate REMOTE_HOST madmax.deafdigest.net SERVER_PORT 80 PATH_TRANSLATED /home/berry/deafdigest_web REMOTE_ADDR 207.138.154.38 HTTP_ACCEPT_LANGUAGE en-us GATEWAY_INTERFACE CGI/1.1 SERVER_NAME www.deafdigest.net HTTP_CONNECTION Keep-Alive HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 4.01; Windows 95) HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/x-quickviewplus, */* REQUEST_URI /mailman/cgi-bin/listinfo.cgi/deafdigest_web PATH /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/robert/bin QUERY_STRING SCRIPT_FILENAME /home/berry/mailman/cgi-bin/listinfo.cgi PATH_INFO /deafdigest_web HTTP_HOST deafdigest.net REQUEST_METHOD GET SERVER_SIGNATURE Apache/1.3.6 Server at www.deafdigest.net Port 80 SCRIPT_NAME /mailman/cgi-bin/listinfo.cgi SERVER_ADMIN webmaster@deafdigest.net SERVER_SOFTWARE Apache/1.3.6 (Unix) PHP/4.0B2 PYTHONPATH /home/mailman SERVER_PROTOCOL HTTP/1.1 REMOTE_PORT 3130 Same for here when accessing to admin.cgi: http://deafdigest.net/mailman/cgi-bin/admin.cgi/deafdigest_web Bug in Mailman version 1.0rc3 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (innermost last): File "/home/mailman/scripts/driver", line 108, in run_main File "/home/mailman/Mailman/Cgi/admin.py", line 28, in ? File "/home/mailman/Mailman/MailList.py", line 40, in ? File "/home/mailman/Mailman/SecurityManager.py", line 28, in ? File "/home/mailman/Mailman/Cookie.py", line 165, in ? File "/usr/lib/python1.5/pickle.py", line 29, in ? ImportError: No module named copy_reg Environment variables: VariableValue DOCUMENT_ROOT /home/barry HTTP_ACCEPT_ENCODING gzip, deflate REMOTE_HOST madmax.deafdigest.net SERVER_PORT 80 PATH_TRANSLATED /home/berry/deafdigest_web REMOTE_ADDR 207.138.154.38 HTTP_ACCEPT_LANGUAGE en-us GATEWAY_INTERFACE CGI/1.1 SERVER_NAME www.deafdigest.net HTTP_CONNECTION Keep-Alive HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 4.01; Windows 95) HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/x-quickviewplus, */* REQUEST_URI /mailman/cgi-bin/admin.cgi/deafdigest_web PATH /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/python/bin QUERY_STRING SCRIPT_FILENAME /home/berry/mailman/cgi-bin/admin.cgi PATH_INFO /deafdigest_web HTTP_HOST deafdigest.net REQUEST_METHOD GET SERVER_SIGNATURE Apache/1.3.6 Server at www.deafdigest.net Port 80 SCRIPT_NAME /mailman/cgi-bin/admin.cgi SERVER_ADMIN webmaster@deafdigest.net SERVER_SOFTWARE Apache/1.3.6 (Unix) PHP/4.0B2 PYTHONPATH /home/mailman SERVER_PROTOCOL HTTP/1.1 REMOTE_PORT 3129 Server status at this time when running 35,000 Email addresses in 2 messages to be sent out at the same time: [root@madmax berry]# uptime 10:43am up 4 days, 3:18, 1 user, load average: 2.97, 2.24, 1.66 [root@madmax berry]# free total used free shared buffers cached Mem: 156484 152312 4172 116796 5048 14704 -/+ buffers/cache: 132560 23924 Swap: 240932 112368 128564 [root@madmax berry]# Server: 350MHz AMD, 160Mb, 1Mb cache What's wrong? Thanks, Robert From starback@ling.uu.se Mon Oct 11 19:59:17 1999 From: starback@ling.uu.se (Per Starback) Date: 11 Oct 1999 20:59:17 +0200 Subject: [Mailman-Developers] Re: [Mailman-Users] Can't change with admin pages In-Reply-To: Per Starback's message of "11 Oct 1999 16:13:45 +0200" References: Message-ID: On mailman-users I wrote about problems I had with one particular list that I couldn't admin with the web interface. Now I know why, and I send this followup to the developer list too, since it might be reason to change something. It turned out that Mailman never sent out any cookies for that particular list. Why? Because the list administrator (not me!) had changed the Base URL for the list by removing "http://" at the beginning of the url. (I don't know what he was trying to achieve with that, but I can understand that some people might be tempted to that with all the non-URL "URLs" that are printed everywhere like that.) Mailman uses the Base URL for cookie stuff. In MakeCookie there is a line path = urlparse(self.web_page_url)[2] # '/mailman' For one of my sensible lists path here became '/mailman/' (note: not exactly as in the comment) but for the bogus list it became instead something else, and I guess that's where things started to go wrong. I changed the Base URL back, and then it works fine again. So what should the lesson be? I'm not sure, but it is nice if Mailman can support clueless list administrators (as long as the main Mailman administrator has a clue) so I don't think the right answer is just "so don't do that!". Probably it shouldn't be allowed to set "Base URL" to any string. I suggest instead that the Mailman administrator should be able to set what basenames should be possible, and the list administrators only can chose from those values. (Most sites would only have one possible value, and then that section could preferrably be deleted from the list admin pages.) -- Per Starback "Life is but a gamble! Let flipism chart your ramble!" P.S. I loved the comments in MakeCookie! From cklempay@chimera.acm.jhu.edu Mon Oct 11 20:59:35 1999 From: cklempay@chimera.acm.jhu.edu (Corbett J. Klempay) Date: Mon, 11 Oct 1999 15:59:35 -0400 (EDT) Subject: [Mailman-Developers] broken mbox? Message-ID: I'm writing here instead of to a general Python list because I'm not sure; the problem may lie with Mailman (not sure). I'm working on a script that reads through a given mbox file from the archives/private subtree and does fun things with it (like index the words, for example :) I am using the UnixMailbox class from the mailbox module. The problem is that having the mailbox module give me the message body (like mailboxobj.fp.read()) gives me the message body, just like it's supposed to...*and* part of the first line of the header of the next message. For example, getting the body on the first message in one of my archives gives: --start--- Mailman 1.0b6 is up and running now...and archiving is in too! The archiving wasn't turned on for this list previously, but it was for some other lists (so it just accumulated the messages in a file, but there was no real archiving -- the real archiver uses a btree -- and no way to view them in a threaded format or whatever). If you want to see what it looks like, view the HOBY list archive (its archiving has been on for months)...link to it from www2.acm.jhu.edu/mailman/listinfo/hoby ------------------------------------------------------------------------------ Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Conscience is the inner voice that warns up that someone may be looking." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 ------------------------------------------------------------------------------ From acm-admin@chi ---end--- (note: the start and end are added in by the script of course...but so you can see the spacing and then the start of the next header). I don't know if this is due to Mailman writing the mbox files screwily (or maybe used to write them screwily; this particular message was dated 11/7/98), or if the mailbox module has a bug of sorts. Anyone seen this / know what's going on? --- Corbett J. Klempay Trilogy Software, Inc. 512.685.4193 (W) | 512.750.1372 (C) corbett.klempay@trilogy.com From cklempay@chimera.acm.jhu.edu Mon Oct 11 21:05:04 1999 From: cklempay@chimera.acm.jhu.edu (Corbett J. Klempay) Date: Mon, 11 Oct 1999 16:05:04 -0400 (EDT) Subject: [Mailman-Developers] broken mbox? In-Reply-To: Message-ID: Oops...not sure how it got in my message, but in my quoted output body, this: >From acm-admin@chi ---end--- should *not* have the > in there...I just looked at the output again..I must have typed that > by accident. --- Corbett J. Klempay Trilogy Software, Inc. 512.685.4193 (W) | 512.750.1372 (C) corbett.klempay@trilogy.com From bwarsaw@python.org Mon Oct 11 21:15:02 1999 From: bwarsaw@python.org (bwarsaw@python.org) Date: Mon, 11 Oct 1999 16:15:02 -0400 (EDT) Subject: [Mailman-Developers] Plea for Help Message-ID: <14338.17734.6158.914332@anthem.cnri.reston.va.us> Folks, As you know, earlier this year I became the primary maintainer for JPython, which means that the time I have available to continue hacking on Mailman has been pretty severely curtailed. My role as webmaster@python.org allowed me to work on it to the point where it now supports all mailing lists on python.org, as well as the Usenet gateways. The current CVS snapshot works well for those purposes, although as we're all aware, Mailman could use a lot of improvement. I greatly appreciate everything you folks do to help each other, and new users, out. Just answering the emails goes a very long way toward easing the burden. I've come to rely on the fact that many of you have a lot of experience with the code base, and are very generous with your time. I'm not the only one of the core maintainers who is extremely busy. I try to work on Mailman as often as I can, but I definitely realize how far back I am lagging. I just can't seem to catch up. And I know the other maintainers are in worse shape than me. I've gotten to the point where I only have time to track those issues that make it to the bugs list, and that sucks. I firmly believe that Mailman is good software that deserves better than I can give it at the moment. So I'm making a plea to you folks to see if anybody has both the experience with Python, and the Mailman source code, and is motivated to join the inner circle. Please be very honest about the time you have available to hack on the software; we all understand what being busy is like. If you think you are able, and would like to join the core maintainer team please send me email. Since Mailman is GNU software, you will have to abide by the GNU guidelines, and assign copyright to your future Mailman changes. I can send you all the necessary GNU information. You should also have a knowledge of CVS and SSH, since those are essential tools we use. Thanks, -Barry From jafo@tummy.com Tue Oct 12 02:12:55 1999 From: jafo@tummy.com (Sean Reifschneider) Date: Mon, 11 Oct 1999 19:12:55 -0600 Subject: [Mailman-Developers] Plea for Help In-Reply-To: <14338.17734.6158.914332@anthem.cnri.reston.va.us>; from bwarsaw@python.org on Mon, Oct 11, 1999 at 04:15:02PM -0400 References: <14338.17734.6158.914332@anthem.cnri.reston.va.us> Message-ID: <19991011191255.L1005@tummy.com> On Mon, Oct 11, 1999 at 04:15:02PM -0400, bwarsaw@python.org wrote: >I'm not the only one of the core maintainers who is extremely busy. I I understand. As I've been saying: It's a great time to be a geek, as long is you like being busy. :-) >to see if anybody has both the experience with Python, and the Mailman >source code, and is motivated to join the inner circle. Please be I'm interested in contributing, of course. While I've found the code to be quite easy for maintinance, I don't feel I have the exposure to the code that allows me to avoid introducing subtle bugs. And, of course, there's that I'm fairly swamped as well. :-) I usually only get time to dig through Mailman on the weekends. I don't expect it to get much better for a couple of weeks. However, I have been thinking that it might be interesting to have a secondary CVS repository where changes could be made and tested and reviewed by anyone. Then, once changes were in and we were confident about them we could submit patch bundles back to the mainstream line. Kind of like what was done with EGCS. Comments? Sean -- I used to think that the brain was the most wonderful organ in my body. Then I realized who was telling me this. -- Emo Phillips Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. From jafo@tummy.com Tue Oct 12 02:22:56 1999 From: jafo@tummy.com (Sean Reifschneider) Date: Mon, 11 Oct 1999 19:22:56 -0600 Subject: [Mailman-Developers] broken mbox? In-Reply-To: ; from Corbett J. Klempay on Mon, Oct 11, 1999 at 03:59:35PM -0400 References: Message-ID: <19991011192256.M1005@tummy.com> On Mon, Oct 11, 1999 at 03:59:35PM -0400, Corbett J. Klempay wrote: >>From acm-admin@chi To answer your second question first, a '>' is often inserted before a bare 'From ' in position 0 to prevent it from being mistaken for the beginning of a new message. See: From here on out. From my point of view. From what I've heard. As far as the mailbox class, it expects a from line to match the following regular expression: _fromlinepattern = r"From \s*[^\s]+\s+\w\w\w\s+\w\w\w\s+\d?\d\s+" \ r"\d?\d:\d\d(:\d\d)?(\s+[^\s]+)?\s+\d\d\d\d\s*$" Your line above doesn't (it's looking for "From something Mon Oct 11 19:21:12 MDT 1999" (where the "MDT" part is optional). That's your problem. According to the docs for mailbox, you can override the _fromlinepattern regex, or the entire _isrealfromline() method if you wish. That should take care of it. Sean -- Put out fires during the daytime. Do your real work at night. Sleep is just an addiction. -- Dieter Muller Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. From Wolf-Dietrich.Ihlenfeldt@CCC.Chemie.Uni-Erlangen.DE Tue Oct 12 16:54:43 1999 From: Wolf-Dietrich.Ihlenfeldt@CCC.Chemie.Uni-Erlangen.DE (Wolf-Dietrich Ihlenfeldt) Date: Tue, 12 Oct 1999 15:54:43 +0000 Subject: [Mailman-Developers] Possible to request/store additional user data? Message-ID: <9910121554.ZM18457@torvs.ccc.uni-erlangen.de> Hello Mailman developers, thank your for developing such an eminently useful program. I am running a Mailman-based mailing list which should only be open to members of a certain special interest group of a scientific society. Subscriptions are configured to require approval. So far this works very well. However, in addition to requesting the email address of new users, I would like to require them to also supply their society membership number, to be able to check their membership status, and archive/display this number together with their email addresses in the admin panels. a) Is this possible? b) If not, is this a planned feature? It might be useful also for other mailing list administrators. -- Dr. Wolf-D. Ihlenfeldt Computer Chemistry Center, University of Erlangen-Nuernberg Naegelsbachstrasse 25, D-91052 Erlangen (Germany) Tel (+49)-(0)9131-85-26579 Fax (+49)-(0)9131-85-26566 --- The three proven methods for ultimate success and fame: 1) Nakanu nara koroshite shimae hototogisu 2) Nakanu nara nakasete miseyou hototogisu 3) Nakanu nara naku made matou hototogisu From bwarsaw@python.org Tue Oct 12 16:24:13 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Tue, 12 Oct 1999 11:24:13 -0400 (EDT) Subject: [Mailman-Developers] Plea for Help References: <14338.17734.6158.914332@anthem.cnri.reston.va.us> <19991011191255.L1005@tummy.com> Message-ID: <14339.21149.443863.835164@anthem.cnri.reston.va.us> >>>>> "SR" == Sean Reifschneider writes: SR> However, I have been thinking that it might be interesting to SR> have a secondary CVS repository where changes could be made SR> and tested and reviewed by anyone. Then, once changes were in SR> and we were confident about them we could submit patch bundles SR> back to the mainstream line. SR> Kind of like what was done with EGCS. Another possibility is using BitKeeper as our revision control system. Please check out www.bitkeeper.com -- they have some very interesting software that would allow us to be more liberal about how developers interact with the source code. I think it would essentially let everyone on this list develop and share their changes. The idea would be that once there's consensus from the community, one of us cabalists would integrate it into the primary repository and "bless" the changes for the next official release. There are three downsides as I see it: 1) BitKeeper is not free software, and Mailman's a GNU project, so that matters. It may matter less than whether Mailman thrives or not at all. 2) We have no experience with BitKeeper so our infrastructure isn't set up for it. Does it integrate with Emacs? Can we easily suck in our CVS history, and perhaps as important, can we export back into CVS if we find it's necessary some time down the road? 3) Those who want to contribute will have to learn YASCCS. I'd like to know what you all think about this. I have no problems with the requirement that our change logs be public (they are anyway). -Barry From vic@vgg.sci.uma.es Tue Oct 12 17:35:24 1999 From: vic@vgg.sci.uma.es (Victoriano Giralt) Date: Tue, 12 Oct 1999 18:35:24 +0200 (MEST) Subject: [Mailman-Developers] Plea for Help In-Reply-To: <14339.21149.443863.835164@anthem.cnri.reston.va.us> Message-ID: On Tue, 12 Oct 1999, Barry A. Warsaw wrote: > > >>>>> "SR" == Sean Reifschneider writes: > > SR> However, I have been thinking that it might be interesting to > SR> have a secondary CVS repository where changes could be made [snip] > > Another possibility is using BitKeeper as our revision control > system. Please check out www.bitkeeper.com -- they have some very > [snip] > There are three downsides as I see it: > > 1) BitKeeper is not free software, and Mailman's a GNU project, so For me, absolute NO-NO [snip] > > 2) We have no experience with BitKeeper so our infrastructure isn't > set up for it. Does it integrate with Emacs? Can we easily suck [snip] > 3) Those who want to contribute will have to learn YASCCS. [snip] My answer to point 3 is absolutely not. I'm trying to standardize CVS for all our inhouse development, at the very least for my own team and the teams in my area, and outside I'm the strongest proponent-evangelist of free software, so I'm not going to propose or spend a bit of effort on a proprietary product, once we are in the road to learn CVS. I'm not a CVS guru (yet :) ;), but I think it would be to difficult to set up a mechanism as the one proposed by Sean, moreover once it has been already done for another project, as can be infered from his message. Flame-GNU-free-ly, -- Victoriano Giralt Systems Programmer Central Computing Facility University of Málaga SPAIN From cklempay@chimera.acm.jhu.edu Tue Oct 12 17:38:59 1999 From: cklempay@chimera.acm.jhu.edu (Corbett J. Klempay) Date: Tue, 12 Oct 1999 12:38:59 -0400 (EDT) Subject: [Mailman-Developers] broken mbox? In-Reply-To: <19991012103203.R1005@tummy.com> Message-ID: Hmm..but this is what I'm saying...none of these messages start with From. The From you saw is taken from the header of the next message (none of the sentences in the message body start with From). That's the problem I'm talking about...every message (if I run the script and watch it go throught the first 10 or 20 messages in the mbox file) is read wrong or something by the mailbox module, as requesting their message bodies always has this fragment of the header from the following message. --- Corbett J. Klempay Trilogy Software, Inc. 512.685.4193 (W) | 512.750.1372 (C) corbett.klempay@trilogy.com On Tue, 12 Oct 1999, Sean Reifschneider wrote: > On Mon, Oct 11, 1999 at 09:45:29PM -0400, Corbett J. Klempay wrote: > >Hmm..I guess you missed my immediate follow up message...that > was not > >supposed to be there...I seem to have typed it by accident (I reran my > >program several times to make sure...sure enough, the output of my program > >does not have a > before the From, and the actual mbox file doesn't have > >it either). ? > > Sending e-mail with a line that starts with "From" causes a '>' to be > inserted, as I demonstrated in the message I sent to you. The point > still remains that you had a "From" line which was not in a format > recognised by the Python mailbox code, and it had nothing to do with > the '>' that appeared in your mail message. > > Sean > -- > [...] Premature optimization is the root of all evil. > -- Donald Knuth > Sean Reifschneider, Inimitably Superfluous > URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. > From gonter@maestria.wu-wien.ac.at Tue Oct 12 18:11:41 1999 From: gonter@maestria.wu-wien.ac.at (Gerhard Gonter) Date: Tue, 12 Oct 1999 19:11:41 +0200 (MES) Subject: [Mailman-Developers] multilingual mailman In-Reply-To: <19990919005451.B2887@tummy.com> from Sean Reifschneider at "Sep 19, 99 00:54:51 am" Message-ID: <199910121711.TAA64068@maestria.wu-wien.ac.at> According to Sean Reifschneider: > On Sat, Sep 18, 1999 at 10:27:40AM +0200, Gerhard Gonter wrote: > >Are there any plans to for non-english user interfaces which can be > >selected individually by the user or at least for a whole list? > > What about an approach that would use an interface like this: > > setlang('German') > print translang['ERROR: You have selected an invalid option ("%s")'] > print translang[' Please try again...'] > > I imagine a shelve called "German" which has as the key the hash of the > string, and as the value the translated string. [...] > > Any comments? A sophisticated approach like your example with some sort of automatic translation is certainly an insteresting goal. Another much simpler and only partial solution to start with would be a translate a couple of templates. This may be sufficient to keep the bulk of non-english speaking users happy enough to accept mailman. A modification of Utils.maketext in a way to select a list-specific templates directory could do the trick, e.g. an additional parameter which defaults to En_US or C. The template directory would contain language specific subdirectories ~mailman/templates/ En_US/ Fr_FR/ De_DE/ The templates directory could also contain the shelves for the more sophisticated translation part. Well... Just a thought ... +gg -- Gerhard.Gonter@wu-wien.ac.at Fax: +43/1/31336/702 g.gonter@ieee.org Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From lindsey@ncsa.uiuc.edu Tue Oct 12 18:39:45 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Tue, 12 Oct 1999 12:39:45 -0500 (CDT) Subject: [Mailman-Developers] broken mbox? In-Reply-To: from "Corbett J. Klempay" at Oct 12, 99 12:38:59 pm Message-ID: <199910121739.MAA31188@ferret.ncsa.uiuc.edu> > Hmm..but this is what I'm saying...none of these messages start with From. > The From you saw is taken from the header of the next message (none of the > sentences in the message body start with From). That's the problem I'm > talking about...every message (if I run the script and watch it go > throught the first 10 or 20 messages in the mbox file) is read wrong or > something by the mailbox module, as requesting their message bodies always > has this fragment of the header from the following message. Try preprocessing your mailbox with formail (part of the procmail suite, available at procmail.org). It will automatically generate missing From_ headers for you or rebuild broken ones (like you have). Something like formail -I"Content-Length:" -I"From " < inbox | formail -m 6 -des > outbox might do the trick. You'll need to play with the numeric value -- it is the number of headers that must appear in a row for the matching lines to be considered part of a new email message. The higher you can set it, the better because lower values may match on headers within attachments (i.e. Content-Disposition, etc.) Chris From vic@vgg.sci.uma.es Tue Oct 12 18:58:22 1999 From: vic@vgg.sci.uma.es (Victoriano Giralt) Date: Tue, 12 Oct 1999 19:58:22 +0200 (MEST) Subject: [Mailman-Developers] multilingual mailman In-Reply-To: <199910121711.TAA64068@maestria.wu-wien.ac.at> Message-ID: On Tue, 12 Oct 1999, Gerhard Gonter wrote: > According to Sean Reifschneider: > > On Sat, Sep 18, 1999 at 10:27:40AM +0200, Gerhard Gonter wrote: > > >Are there any plans to for non-english user interfaces which can be > > >selected individually by the user or at least for a whole list? > > > > What about an approach that would use an interface like this: > > > > setlang('German') > > print translang['ERROR: You have selected an invalid option ("%s")'] > > print translang[' Please try again...'] > > > > I imagine a shelve called "German" which has as the key the hash of the > > string, and as the value the translated string. [...] > > > A sophisticated approach like your example with some sort of automatic > translation is certainly an insteresting goal. Another much simpler > > The template directory would contain language specific subdirectories > ~mailman/templates/ > En_US/ > Fr_FR/ > De_DE/ There is already an effort that has gone that way (using GNU gettext for aidding in the translation). We have a working copy of mailman with spanish, english and german interface, and, I think, somebody working on japanesse and swedish. We have submited the patches to Barry Warsaw and he said we would integrate them when he can ease the overload he is suffering at the moment. You can visit it at http://joker.sci.uma.es/mailman/listinfo/test For the admin password and more info, please, contact Juan Carlos Rey Anaya . Joker is his workstation and he has done the dirty coding work. I have been blessed with funding his time for the project and playing boss :) -- Victoriano Giralt Systems Programmer Central Computing Facility University of Málaga SPAIN From jafo@tummy.com Wed Oct 13 09:56:15 1999 From: jafo@tummy.com (Sean Reifschneider) Date: Wed, 13 Oct 1999 02:56:15 -0600 Subject: [Mailman-Developers] Problem with % formatting. Message-ID: <19991013025615.L1005@tummy.com> Boy, this percent formatting is really turning out to be a problem. For about the last week, a list I manage has been having severe problems, but I didn't realize fully HOW severe (the only report was that digests had duplicate messages in them). It turns out that the code which creates the headers and footers from the template was missing an 's' on this list, so it had "%(real_name):". This meant that the message was being written for archiving with every delivery, but every REAL attempt to deliver was failing. I've made a patch for the specific instance of this problem (switching to a SafeDict at the same time). However, I think the real answer may be something like the following in Util.py: def Formatter(fmt, data): if type(data) == types.DictType: data = SafeDict(data) try: s = fmt % data except ValueError: s = fmt return(s) and use this function in place of % formatting, *PARTICULARLY* where the LHS is user-provided. Sean ====================== *** MailList.py.old Wed Oct 13 02:28:31 1999 --- MailList.py Wed Oct 13 02:36:26 1999 *************** *** 1346,1356 **** pass self.LogMsg("post", "post to %s from %s size=%d", self._internal_name, msg.GetSender(), len(msg.body)) ! d = self.__dict__.copy() d['cgiext'] = mm_cfg.CGIEXT self.DeliverToList(msg, recipients, ! header = self.msg_header % d, ! footer = self.msg_footer % d) if ack_post: self.SendPostAck(msg, sender) self.last_post_time = time.time() --- 1346,1362 ---- pass self.LogMsg("post", "post to %s from %s size=%d", self._internal_name, msg.GetSender(), len(msg.body)) ! d = Utils.SafeDict(self.__dict__.copy()) d['cgiext'] = mm_cfg.CGIEXT + + # Make sure invalid formatting doesn't frob us up + try: header = self.msg_header % d + except ValueError: header = self.msg_header + try: footer = self.msg_footer % d + except ValueError: footer = self.msg_footer self.DeliverToList(msg, recipients, ! header = header, ! footer = footer) if ack_post: self.SendPostAck(msg, sender) self.last_post_time = time.time() -- [...] Premature optimization is the root of all evil. -- Donald Knuth Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. From jafo@tummy.com Wed Oct 13 10:09:26 1999 From: jafo@tummy.com (Sean Reifschneider) Date: Wed, 13 Oct 1999 03:09:26 -0600 Subject: [Mailman-Developers] Plea for Help In-Reply-To: ; from Victoriano Giralt on Tue, Oct 12, 1999 at 06:35:24PM +0200 Message-ID: <19991013030833.M1005@tummy.com> On Tue, Oct 12, 1999 at 06:35:24PM +0200, Victoriano Giralt wrote: >For me, absolute NO-NO Personally, I'm more concerned with the ongoing viability of Mailman. It's a sweet system, however it does need regular maintinance. Added features would be good too: lftp ftp.list.org:/pub/mailman> ls mailman-1.0rc3.tgz -rw-r--r-- 1 604 601 906745 Jul 12 09:20 mailman-1.0rc3.tgz lftp ftp.list.org:/pub/mailman> If you make it hard for folks to contribute, they won't. Their contributions getting lost in a black hole qualify as "hard". >> 3) Those who want to contribute will have to learn YASCCS. > >My answer to point 3 is absolutely not. I'm trying to standardize CVS for >all our inhouse development, at the very least for my own team and the With all due respect, do you have a better solution to the current problems? If the choice is between using a non-GNU tool and watching MailMan wither, I'll select the former. Perhaps I'm just tainted by trying to meet the mortgage while working on Open Source Software, but I don't have a problem with non-free software... >I'm not a CVS guru (yet :) ;), but I think it would be to difficult to set >up a mechanism as the one proposed by Sean, moreover once it has been >already done for another project, as can be infered from his message. Hmm. I'm afraid I'm not able to parse the above. Are you saying that it would be difficult to set up a second CVS repository? Sean -- "All I'm saying is that when I'm around you I find myself showing off, which is the idiots version of being interesting." -- _LA_Story_ Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. From jafo@tummy.com Wed Oct 13 10:13:10 1999 From: jafo@tummy.com (Sean Reifschneider) Date: Wed, 13 Oct 1999 03:13:10 -0600 Subject: [Mailman-Developers] Plea for Help In-Reply-To: <14339.21149.443863.835164@anthem.cnri.reston.va.us>; from Barry A. Warsaw on Tue, Oct 12, 1999 at 11:24:13AM -0400 References: <14338.17734.6158.914332@anthem.cnri.reston.va.us> <19991011191255.L1005@tummy.com> <14339.21149.443863.835164@anthem.cnri.reston.va.us> Message-ID: <19991013031310.N1005@tummy.com> On Tue, Oct 12, 1999 at 11:24:13AM -0400, Barry A. Warsaw wrote: >system. Please check out www.bitkeeper.com -- they have some very >interesting software that would allow us to be more liberal about how >developers interact with the source code. I think it would The feature that sounds most interesting is: Distributed means that every developer gets their own personal repository and the tool handles moving changes between repositories. This is exactly what I was thinking of doing with the more public CVS repository. Unfortunately, I don't believe that CVS has any sort of mechanism for doing this automaticly, So, that means that the core developers still have to do a lot of work to maintain it. Sean -- "Yes on one, no on two." "Is number one nuke Russia, or number two?" -- _Buckaroo_Banzai_ Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. From jafo@tummy.com Wed Oct 13 10:24:17 1999 From: jafo@tummy.com (Sean Reifschneider) Date: Wed, 13 Oct 1999 03:24:17 -0600 Subject: [Mailman-Developers] Re: [Mailman-Users] Can't change with admin pages In-Reply-To: ; from Per Starback on Mon, Oct 11, 1999 at 08:59:17PM +0200 References: Message-ID: <19991013032417.O1005@tummy.com> On Mon, Oct 11, 1999 at 08:59:17PM +0200, Per Starback wrote: > path = urlparse(self.web_page_url)[2] # '/mailman' Is that comment supposed to mean something? Should the above code be changed to something more like: path = urlparse(self.web_page_url)[2] # '/mailman' if not path: path = self.web_page_url I don't fully understand how path interacts with the rest of that cookie code though. I'm really supposed to be working now. :-) Ideally, the user-interface should check that the URL is acceptable, but IMHO the back-end code should be made more robust as well. Sean -- Problem with Closed Source Software #101: "We have found 46 ways to remotely crash NT by sending authentication packets." Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. From bwarsaw@python.org Wed Oct 13 16:01:42 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Wed, 13 Oct 1999 11:01:42 -0400 (EDT) Subject: [Mailman-Developers] Plea for Help References: <14338.17734.6158.914332@anthem.cnri.reston.va.us> <19991011191255.L1005@tummy.com> <14339.21149.443863.835164@anthem.cnri.reston.va.us> <19991013031310.N1005@tummy.com> Message-ID: <14340.40662.126399.12714@anthem.cnri.reston.va.us> >>>>> "SR" == Sean Reifschneider writes: SR> Distributed means that every developer gets their own personal SR> repository and the tool handles moving changes between SR> repositories. SR> This is exactly what I was thinking of doing with the more SR> public CVS repository. Unfortunately, I don't believe that SR> CVS has any sort of mechanism for doing this automaticly, So, SR> that means that the core developers still have to do a lot of SR> work to maintain it. My sentiments exactly. What would be ideal would be some kind of hiearchical arrangement of repositories. Let's say the I18N guys work on their patches for multi-languages. Another group works on archiving improvements. Another group is improving the web interface. Maybe I hack on the database schema. As each subproject reaches various milestones, those changes would percolate up the repository hierarchy so that wider groups of folks could bang on them. At some point, they would pass greater scrutiny and end up ready for the main tree. These changes would have to merge cleanly with all the other changes coming down from the top. Eventually, I'd know that enough people like the change, have tested it, and understand it so that I can pull it into the main branch without reading every single line of code. There's another approach, which is more work upfront, but is probably worth it anyway. The way Guido deals with the enormity of Python development is that his source is very modular. There are core bits that he cares very deeply about, and will not commit to unless he's read every line. He'll nitpick over minor details until the patch is just right. That's a good thing because you want to be sure the critical stuff is clean, consistent, robust, etc. But enough of the code is modular so that he doesn't have to look at every line of the Python library, or peripheral objects or modules. Sure, sometimes patches will break things, but that usually comes out during beta testing, and besides if they're really broken it doesn't hose Python completely. We aren't there with Mailman; there is much too much interdependence in the code base. It would be a lot of work to separate components out so that people can work on them independently. And Mailman the same kind of project as Python, so there's a limit to how much modularity can be had. Anyway, I'm rambling, but I'm glad you guys are talking about this stuff. I want to do anything I can to maintain the longterm viability of Mailman, and the usefulness of the program outside python.org. As long as I'm webmaster over here, I'm sure I'll be using Mailman, but my own personal requirements may not completely coincide with y'all's. So its good to hear what your ideas are. Thanks, -Barry From gonter@maestria.wu-wien.ac.at Wed Oct 13 21:09:48 1999 From: gonter@maestria.wu-wien.ac.at (Gerhard Gonter) Date: Wed, 13 Oct 1999 22:09:48 +0200 (MES) Subject: [Mailman-Developers] Plea for Help In-Reply-To: <19991013031310.N1005@tummy.com> from Sean Reifschneider at "Oct 13, 99 03:13:10 am" Message-ID: <199910132009.WAA56410@maestria.wu-wien.ac.at> According to Sean Reifschneider: > This is exactly what I was thinking of doing with the more public CVS > repository. Unfortunately, I don't believe that CVS has any sort of > mechanism for doing this automaticly, So, that means that the core > developers still have to do a lot of work to maintain it. There is nothing in software engineering that works truely automaticaly, behind the scenes there is always some good spirit who lends a helping hand or speaks a magic spell ;) With all due respect to the mailman development effort, CVS is used in open source projects much larger than Mailman or even Python. All three BSD's[1] are nice examples, all with anonymous CVS, CVS web, bug tracking and developer lists. (FreeBSD even offers the CVS repository itself to be ftp'ed.) Concentrating development to one central CVS repository and using the branches for those various improvements might work like the hierarchical arrangement of repositories BAW mentioned in his post a while ago. This seems to be quite successfull for the BSD's already mentioned. Summary: keep CVS, add CVS web and use branches References: [1] www.freebsd.org, www.openbsd.org, www.netbsd.org +gg -- Gerhard.Gonter@wu-wien.ac.at Fax: +43/1/31336/702 g.gonter@ieee.org Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Oct 13 21:17:10 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 13 Oct 1999 16:17:10 -0400 (EDT) Subject: [Mailman-Developers] Plea for Help References: <19991013031310.N1005@tummy.com> <199910132009.WAA56410@maestria.wu-wien.ac.at> Message-ID: <14340.59590.668220.421674@anthem.cnri.reston.va.us> >>>>> "GG" == Gerhard Gonter writes: GG> Summary: keep CVS, add CVS web and use branches Not sure about the branches bit. We had a horrible experience recently trying to use CVS branches on the Python tree. Okay, maybe it's just me, but I would be very hesitant about using branches again. -Barry From jarrell@vt.edu Wed Oct 13 20:38:05 1999 From: jarrell@vt.edu (Ron Jarrell) Date: Wed, 13 Oct 1999 15:38:05 -0400 Subject: [Mailman-Developers] Plea for Help In-Reply-To: References: <14339.21149.443863.835164@anthem.cnri.reston.va.us> Message-ID: <4.2.0.58.19991013153718.00cf11c0@vtserf.cc.vt.edu> --=====================_48520035==_.ALT Content-Type: text/plain; charset="us-ascii" At 06:35 PM 10/12/99 +0200, Victoriano Giralt wrote: >I'm not a CVS guru (yet :) ;), but I think it would be to difficult to set >up a mechanism as the one proposed by Sean, moreover once it has been >already done for another project, as can be infered from his message. I'm thinking from the rest of your note that you meant "would *not* be difficult"? --=====================_48520035==_.ALT Content-Type: text/html; charset="us-ascii" At 06:35 PM 10/12/99 +0200, Victoriano Giralt wrote:
I'm not a CVS guru (yet :) ;), but I think it would be to difficult to set
up a mechanism as the one proposed by Sean, moreover once it has been
already done for another project, as can be infered from his message.

I'm thinking from the rest of your note that you meant "would *not* be
difficult"?
 --=====================_48520035==_.ALT-- From cklempay@chimera.acm.jhu.edu Wed Oct 13 22:25:24 1999 From: cklempay@chimera.acm.jhu.edu (Corbett J. Klempay) Date: Wed, 13 Oct 1999 17:25:24 -0400 (EDT) Subject: [Mailman-Developers] Plea for Help In-Reply-To: <14340.59590.668220.421674@anthem.cnri.reston.va.us> Message-ID: The thing that worries me about kicking off all of these brances is the potential for a HUGE speed it. (depending on how many) --- Corbett J. Klempay Trilogy Software, Inc. 512.685.4193 (W) | 512.750.1372 (C) corbett.klempay@trilogy.com On Wed, 13 Oct 1999, Barry A. Warsaw wrote: > > >>>>> "GG" == Gerhard Gonter writes: > > GG> Summary: keep CVS, add CVS web and use branches > > Not sure about the branches bit. We had a horrible experience > recently trying to use CVS branches on the Python tree. Okay, maybe > it's just me, but I would be very hesitant about using branches > again. > > -Barry > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers > From vic@vgg.sci.uma.es Wed Oct 13 23:19:43 1999 From: vic@vgg.sci.uma.es (Victoriano Giralt) Date: Thu, 14 Oct 1999 00:19:43 +0200 (MEST) Subject: [Mailman-Developers] Plea for Help In-Reply-To: <4.2.0.58.19991013153718.00cf11c0@vtserf.cc.vt.edu> Message-ID: On Wed, 13 Oct 1999, Ron Jarrell wrote: > At 06:35 PM 10/12/99 +0200, Victoriano Giralt wrote: > > I'm thinking from the rest of your note that you meant "would *not* be > difficult"? > Right on target. I meant NOT difficult. -- Victoriano Giralt Systems Programmer Central Computing Facility University of Málaga SPAIN From jarrell@vt.edu Wed Oct 13 22:56:36 1999 From: jarrell@vt.edu (Ron Jarrell) Date: Wed, 13 Oct 1999 17:56:36 -0400 Subject: [Mailman-Developers] Plea for Help In-Reply-To: <14340.59590.668220.421674@anthem.cnri.reston.va.us> References: <19991013031310.N1005@tummy.com> <199910132009.WAA56410@maestria.wu-wien.ac.at> Message-ID: <4.2.0.58.19991013175544.04ba5800@vtserf.cc.vt.edu> --=====================_51322084==_.ALT Content-Type: text/plain; charset="us-ascii" At 04:17 PM 10/13/99 -0400, Barry A. Warsaw wrote: > >>>>> "GG" == Gerhard Gonter writes: > > GG> Summary: keep CVS, add CVS web and use branches > >Not sure about the branches bit. We had a horrible experience >recently trying to use CVS branches on the Python tree. Okay, maybe >it's just me, but I would be very hesitant about using branches >again. Works pretty well for BSD and INN... Just takes some practice. I'd ask one of the folks that set it up for them for advice... --=====================_51322084==_.ALT Content-Type: text/html; charset="us-ascii" At 04:17 PM 10/13/99 -0400, Barry A. Warsaw wrote:

>>>>> "GG" == Gerhard Gonter <gonter@maestria.wu-wien.ac.at> writes:

    GG> Summary: keep CVS, add CVS web and use branches

Not sure about the branches bit.  We had a horrible experience
recently trying to use CVS branches on the Python tree.  Okay, maybe
it's just me, but I would be very hesitant about using branches
again.

Works pretty well for BSD and INN... Just takes some practice.  I'd ask one of the
folks that set it up for them for advice... --=====================_51322084==_.ALT-- From Harald.Meland@usit.uio.no Wed Oct 13 23:08:47 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 14 Oct 1999 00:08:47 +0200 Subject: [Mailman-Developers] Re: [Mailman-Users] Usability patch: (D In-Reply-To: Ricardo Kustner's message of "Wed, 18 Aug 1999 20:29:51 +0200 (CEST)" References: Message-ID: [Ricardo Kustner] > On 18-Aug-99 Bernhard Reiter wrote: > > I can understand that the developers are busy. > same here... but i've never had any reactions to the suggestions i posted in > here so i kind of got the feeling that nobody took me seriously... It doesn't appear that anyone has answered this (posted nearly two months ago), although it indeed does deserve comment. For me, the last few months have been a bad case of Too Busy Doing Real Work -- I'm sorry if anyone have gotten the impression that we (the core developers/Mailman cabal[1]) aren't taking suggestions seriously. I am now just starting to get my head above water, and hope to be able to start hacking a little on Mailman in a week or two. Until I'm confident that it really is air I'm breathing again, I'll just keep a low profile, skimming over the messages that have come to the list(s) these last months, and of course trying to take note of patches/suggestions/bug reports etc. Glad to be back (well, nearly, anyway :), [1] However, of course There Is No Cabal[TM] ;) -- Harald From claw@varesearch.com Wed Oct 13 23:11:29 1999 From: claw@varesearch.com (J C Lawrence) Date: Wed, 13 Oct 1999 15:11:29 -0700 Subject: [Mailman-Developers] Plea for Help In-Reply-To: Message from "Barry A. Warsaw" of "Tue, 12 Oct 1999 11:24:13 EDT." <14339.21149.443863.835164@anthem.cnri.reston.va.us> Message-ID: On Tue, 12 Oct 1999 11:24:13 -0400 (EDT) Barry A Warsaw wrote: > Another possibility is using BitKeeper as our revision control > system. I've been using BitKeeper heavily for about 6 months now. Gorgeous stuff. > 2) We have no experience with BitKeeper so our infrastructure > isn't set up for it. Does it integrate with Emacs? Yes. > Can we easily suck in our CVS history, and perhaps as important, Yes, with caveats. Larry isn't willing to release the port tool yet as it is, umm, fragile and may lose data from your repository. Happily Larry is often willing to assist with such transfers. > can we export back into CVS if we find it's necessary some time > down the road? BK is a superset of CVS. As such some data (not code) will be lost in such a transition. There's nothing you can do about this. > 3) Those who want to contribute will have to learn YASCCS. If you know RCS or SCCS learning BK is a doddle. Just do exactly the same things you used to do and put "bk" in the front of every string. $ bk get file.c $ bk co -l file.c After that its just a matter of adding the commit and resync commands and you're pretty well away to running. -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From claw@varesearch.com Wed Oct 13 23:16:20 1999 From: claw@varesearch.com (J C Lawrence) Date: Wed, 13 Oct 1999 15:16:20 -0700 Subject: [Mailman-Developers] Plea for Help In-Reply-To: Message from Victoriano Giralt of "Tue, 12 Oct 1999 18:35:24 +0200." Message-ID: On Tue, 12 Oct 1999 18:35:24 +0200 (MEST) Victoriano Giralt wrote: > My answer to point 3 is absolutely not. I'm trying to standardize > CVS for all our inhouse development, at the very least for my own > team and the teams in my area, and outside I'm the strongest > proponent-evangelist of free software, so I'm not going to propose > or spend a bit of effort on a proprietary product, once we are in > the road to learn CVS. As a tired voice of experience: Please come back when you've learned the agony of CVS. If you still think CVS is just fine, then there's little reason to even look at BK. On a more minor note, please read BK's license. While it is not Open Source, you do get access to the source, you are able to fix bugs and redistribute patches, there are no license fees (as long as you're willing to publish your changelogs), and everything reverts to GPL if BitMover Inc or Larry fails to maintain BK etc. Essentially it treads the very narrow line between Open Source and maintaining a business model that is capable of supporting a software company via commercial licensing (companies don't want their changelogs published as that becomes a shopping list for headhunters). -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From jafo@tummy.com Wed Oct 13 23:17:09 1999 From: jafo@tummy.com (Sean Reifschneider) Date: Wed, 13 Oct 1999 16:17:09 -0600 Subject: [Mailman-Developers] Plea for Help In-Reply-To: <14340.59590.668220.421674@anthem.cnri.reston.va.us>; from Barry A. Warsaw on Wed, Oct 13, 1999 at 04:17:10PM -0400 References: <19991013031310.N1005@tummy.com> <199910132009.WAA56410@maestria.wu-wien.ac.at> <14340.59590.668220.421674@anthem.cnri.reston.va.us> Message-ID: <19991013161709.F1005@tummy.com> On Wed, Oct 13, 1999 at 04:17:10PM -0400, Barry A. Warsaw wrote: >Not sure about the branches bit. We had a horrible experience >recently trying to use CVS branches on the Python tree. Okay, maybe >it's just me, but I would be very hesitant about using branches >again. I do not fully understand how branches work. While the core development team doesn't have a lot of time, that precious spare time may be better used to grok branches than to grok BitKeeper. Sean -- Reading computer manuals without the hardware is as frustrating as reading sex manuals without the software. -- Arthur C. Clarke Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. From claw@varesearch.com Wed Oct 13 23:21:41 1999 From: claw@varesearch.com (J C Lawrence) Date: Wed, 13 Oct 1999 15:21:41 -0700 Subject: [Mailman-Developers] Plea for Help In-Reply-To: Message from "Barry A. Warsaw" of "Wed, 13 Oct 1999 16:17:10 EDT." <14340.59590.668220.421674@anthem.cnri.reston.va.us> Message-ID: On Wed, 13 Oct 1999 16:17:10 -0400 (EDT) Barry A Warsaw wrote: >>>>>> "GG" == Gerhard Gonter >>>>>> writes: GG> Summary: keep CVS, add CVS web and use branches > Not sure about the branches bit. We had a horrible experience > recently trying to use CVS branches on the Python tree. Okay, > maybe it's just me, but I would be very hesitant about using > branches again. Branches under CVS are the next thing to evil and early hair loss. CVS doesn't even attempt to handle renames or deletes in any way that pretends to be sensical. Reproducability under CVS is non-existent. Three-way merges are a nightmare. Change tracking is a royal pain (cf CVSBLAME). Even Aegis is a better choice than CVS, and that's not saying a whole lot for Aegis. -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From claw@varesearch.com Wed Oct 13 23:26:30 1999 From: claw@varesearch.com (J C Lawrence) Date: Wed, 13 Oct 1999 15:26:30 -0700 Subject: [Mailman-Developers] Plea for Help In-Reply-To: Message from Sean Reifschneider of "Wed, 13 Oct 1999 16:17:09 MDT." <19991013161709.F1005@tummy.com> Message-ID: On Wed, 13 Oct 1999 16:17:09 -0600 Sean Reifschneider wrote: > I do not fully understand how branches work. While the core > development team doesn't have a lot of time, that precious spare > time may be better used to grok branches than to grok BitKeeper. I have just over a dozen people using BK. The average learning time for them to get up to basic usability was under two hours, total. Admittedly many of these people are professional software engineers with history with Perforce, Clearcase, ptools, fcs/kcs, etc. More amusingly that history was more of a problem in their learning than an assist. BK is simple. Very simple. If you know RCS or SCCS, you can use BK right now. If you know CVS the learning curve is on the order of 20 minutes. -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From bwarsaw@python.org Wed Oct 13 23:36:44 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Wed, 13 Oct 1999 18:36:44 -0400 (EDT) Subject: [Mailman-Developers] Plea for Help References: <19991013031310.N1005@tummy.com> <199910132009.WAA56410@maestria.wu-wien.ac.at> <4.2.0.58.19991013175544.04ba5800@vtserf.cc.vt.edu> Message-ID: <14341.2428.386586.869623@anthem.cnri.reston.va.us> >>>>> "RJ" == Ron Jarrell writes: RJ> Works pretty well for BSD and INN... Just takes some practice. RJ> I'd ask one of the folks that set it up for them for RJ> advice... I had two really killer problems with CVS branches. First, I often had trouble getting new files checked into the branch. Second, when I went to merge the branch into the mainline, it pulled in gobs of old files that had long been Attic'd. -Barry From bwarsaw@python.org Wed Oct 13 23:40:53 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Wed, 13 Oct 1999 18:40:53 -0400 (EDT) Subject: [Mailman-Developers] Plea for Help References: <14339.21149.443863.835164@anthem.cnri.reston.va.us> Message-ID: <14341.2677.760419.782383@anthem.cnri.reston.va.us> Thanks for the info JC. The BK web pages seem pretty out of date though, and I didn't see anything about downloads. Interestingly enough I also didn't see any links to the supposedly public free software change logs :) Everything else sounds interesting. I'd like to come up with a solution that would eventually translate to all the projects we've got here (JPython and Python) so I want to investigate Aegis, and get Guido's feedback on things as well. I appreciate all the feedback, information and experience you guys share. -Barry From bwarsaw@python.org Wed Oct 13 23:45:50 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Wed, 13 Oct 1999 18:45:50 -0400 (EDT) Subject: [Mailman-Developers] Plea for Help References: <19991013031310.N1005@tummy.com> <199910132009.WAA56410@maestria.wu-wien.ac.at> <14340.59590.668220.421674@anthem.cnri.reston.va.us> <19991013161709.F1005@tummy.com> Message-ID: <14341.2974.845317.266445@anthem.cnri.reston.va.us> >>>>> "SR" == Sean Reifschneider writes: SR> I do not fully understand how branches work. While the core SR> development team doesn't have a lot of time, that precious SR> spare time may be better used to grok branches than to grok SR> BitKeeper. I'm fairly sure I understand how they're /supposed/ to work, I just think they're broken in some serious ways, at least with CVS 1.10.x BTW, anybody have real-world experience with Aegis? It's GPL'd but I've never heard of it before... http://www.canb.auug.org.au/~millerp/aegis/aegis.html Sure does have one mondo reference manual :) -Barry From ricardo@miss-janet.com Wed Oct 13 23:49:42 1999 From: ricardo@miss-janet.com (Ricardo - Miss Janet . Fanclub) Date: Thu, 14 Oct 1999 00:49:42 +0200 Subject: [Mailman-Developers] Re: [Mailman-Users] Usability patch: (D In-Reply-To: ; from Harald Meland on Thu, Oct 14, 1999 at 12:08:47AM +0200 References: Message-ID: <19991014004942.B1362@rix> Hi, On Thu, Oct 14, 1999 at 12:08:47AM +0200, Harald Meland wrote: > > On 18-Aug-99 Bernhard Reiter wrote: > > > I can understand that the developers are busy. > > same here... but i've never had any reactions to the suggestions i posted in > > here so i kind of got the feeling that nobody took me seriously... > It doesn't appear that anyone has answered this (posted nearly two > months ago), although it indeed does deserve comment. > For me, the last few months have been a bad case of Too Busy Doing > Real Work -- I'm sorry if anyone have gotten the impression that we > (the core developers/Mailman cabal[1]) aren't taking suggestions > seriously. thanks for reacting though... better late than never :) i've ended up hacking my wishes into the source myself -- most of which are in the posting moderate options (admindb.py) since we use that feature intensively... this will mean i'm probably going to have some sleepless nights when a new mailman version is being released and i will have to put back all the things i've added :) I do wish had some more free time on my hands so i could (a) learn myself some more python and (b) be an active developer for mailman... Ricardo. -- From claw@varesearch.com Thu Oct 14 01:37:15 1999 From: claw@varesearch.com (J C Lawrence) Date: Wed, 13 Oct 1999 17:37:15 -0700 Subject: [Mailman-Developers] (no subject) Message-ID: I forwarded some of the BK traffic to Larry. A reply: ------- Forwarded Message Date: Wed, 13 Oct 1999 15:46:14 -0700 From: Larry McVoy To: J C Lawrence Subject: Re: [Mailman-Developers] Plea for Help Check out the screen shots on bitkeeper.com - we've added GUI helptool and GUI csettool. The latter is cool beyond description. You give it one more cset revs as an arg and it walks you through them. You get to see . the list of files / revs in each cset . the cset comments and the file comments together . side by side diffs of the old/new versions of the file and you can move through the whole thing with the space bar - it will page the diffs, when you hit the end of the diffs, it goes to the next file which updates the comments window, and you repeat. Coolness? - -- - --- Larry McVoy lm@bitmover.com http://www.bitmover.com/lm ------- End of Forwarded Message -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From claw@varesearch.com Thu Oct 14 01:38:30 1999 From: claw@varesearch.com (J C Lawrence) Date: Wed, 13 Oct 1999 17:38:30 -0700 Subject: [Mailman-Developers] Plea for Help In-Reply-To: Message from "Barry A. Warsaw" of "Wed, 13 Oct 1999 18:45:50 EDT." <14341.2974.845317.266445@anthem.cnri.reston.va.us> Message-ID: On Wed, 13 Oct 1999 18:45:50 -0400 (EDT) Barry A Warsaw wrote: > BTW, anybody have real-world experience with Aegis? It's GPL'd > but I've never heard of it before... There's been some brief discussion on Linux-Kernel (searchable archives at http://www.mail-archive.com/), but not a whole lot. I've never seen a real installation or user report from other than the authors. -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From lm@bitmover.com Thu Oct 14 02:17:54 1999 From: lm@bitmover.com (Larry McVoy) Date: Wed, 13 Oct 1999 18:17:54 -0700 Subject: [Mailman-Developers] [lm@bitmover.com: Re: FW: Staging System - Requirements Meeting Recap] Message-ID: <19991013181754.15843@work.bitmover.com> hey there, two things: (a) is mailman better than majordomo? I assume it must be right, or you wouldn't be putting all this effort into it. I'm using majordomo now and I keep meaning to look for something that has better spam filters. Forgive the stupid questions, but should I switch? (b) JC has told me that you are considering maybe using BitKeeper for mailman development. I had a call from a large company today and they sent in their requirements and I spent a bunch of time answering them. It might be worth it for you to skim through the questions and answers, I suspect there is some overlap. I'd love it if it turned out that BK was useful to you (and I'd be equally bummed to find out it didn't work for you; if that's the case I want to know why: if there are technical reasons for you not using it, those will almost certainly be fixed, you guys have similar issues to everyone else so that means if it doesn't work for you, it doesn't work for very many other people). Finally, if you have questions, you can mail to me and/or dev@bitmover.com . The dev alias is all the people hacking on BK right now. Cheers, --lm -----Forwarded message----- Hi folks, here are BitMover's responses to your requirements. We think BitKeeper might be a good fit for you, let us know what you think. > Open Discussion - Requirements > a.. Direct FTP access We provide SSH (secure remote shell), RSH (BSD remote shell), and SMTP (email) as transports for moving stuff around. We could do a FTP transport but it seems questionable given that ssh is faster and more secure. If the issue is Windows, no problem, we support ssh on Windows. Use it all the time, in fact, between Windows and Unix. Oh, I forgot, we also work in local and networked file systems (NFS, SMB) and do resyncs between Unix and Windows using SMB. > b.. Graphical view of the file tree -or- dynamic tree structure We actually don't have this right now. But see the checkin response. We have it on Windows because we integrate with their GUI glop, but that's not much help. If we get far enough along and this is a go/no go thing for you, and you're buying 10,000 seats (:-) then we'll write one. Seriously, it's on the list. > c.. Check-in and check-out facilities Got 'em. Both command line and graphical. The command line stuff is like so bk new file - check a file into the system for the first time - aliases: bk delta -i, bk ci -i, bk admin -i bk edit file - check out a file locked for modification - aliases bk co -l, bk get -e bk ci file - check in modifications to a file - aliases: bk delta You can do all of the above on the entire tree, a sub tree, an explict list: bk -r new - checks in everything it finds bk -r edit - locks everything bk -r ci -yComment - checks in everything But the best tool is citool, which finds everything you've modified, lists in a graphical tool, and shows you the diffs as you're doing the check in. See http://www.bitkeeper.com/citool.html > d.. Open ended client support allowing developers to use any editing > tool - FTP to local machine with check-out - edit with whatever tool you > wish - FTP upload to server with check-in That's exactly the right answer. Use any editor you want. What you get with BK is the revision history files locally. If you've worked with RCS or SCCS, in many respects, BK is like that with all the added stuff you need to have multiple copies of the revision history. So every playpen is a repository, you can lock, edit, checkin, browse, etc., everything locally. No need for network connectivity except when you want to update your tree or the other tree. Oh, and you can update "sideways". One developer can slurp in the changes in a another developer's tree directly, without going through the "master" or "shared" tree. In CVS terms, I don't have to go back to the master repository, I can talk directly to you. The hierarchical nature of the system is strictly a convention thing, you can resync from anywhere to anywhere. > e.. Ability to cluster files into "Change Sets" for version control and > configuration management Chuckle. We have that in spades. We don't let you move data between playpens unless you've put it in a changeset (yeah, you could get the diffs and apply them with patch, we can't stop you, but if you want the system to do it, you have to "commit" whatever you have done to a changeset). The normal way you do this is when you pop into citool, there will be N+1 entries, where N are the files with mods, and the Nth+1 entry is the ChangeSet file. If you comment the ChangeSet file, you are creating a ChangeSet. The "diffs" shown for the ChangeSet file are the comments you have just typed in on all the other files like so src/foo.c Fix a bug in arg processing src/foo.h Include getopt.h with the idea being that the ChangeSet comments should be the idea or concept you just did, while the per file comments are implementation details. > f.. Allow user selectable update reports on one or more branches of the > development system I think this is what we call a LOD, but I need clarification. What exactly do you want? > g.. Ability for CGI to be accessible and scriptable from a remote shell - > should support Mac/PC/Linux/Unix/etc. Is this a source management system issue? I don't understand. And one huge bummer - we don't support the Mac; the system depends pretty heavily on various Unix tools (sed, sh, tr, diff, etc), which we provide for Windows but haven't worked up the ompf to do on the Mac. If the Mac is a requirement, we can support MacOS X no problem, that's Unix, but MacOS 8 is a real drag. Let me know, that might be a show stopper. There are ways we can work around this, using appletalk - you could do the source management crud on Linux and the editing on a Mac. Definitely a hack but I can relate to the requirement - the Mac has a bunch of useful tools for Web folks. Long term we will do a port. But that isn't likely to happen in the next few months. > h.. Change Logs You get these for free, it's the ChangeSet comment history. > i.. Concurrent Development of files - requires intelligent merging agent > for coordinating updates from multiple developers (CVS does this now) We do this better than anyone. Period. Everyone else screws up your history. Here's how: you have two developers A and B. They both do CVS update and have the same tree. They both modify file foo.c. A checks in first, so B "lost the race" and has to merge. What CVS will check in is not B's changes, it's B's changes plus whatever B had to do to merge. That is **two events** collapsed into one. Why is this a big deal? Undo. Suppose B's stuff was good and A's stuff wasn't. We can reconstruct B's stuff without the merge. CVS can't. It lost the information. Look at http://www.bitkeeper.com/sccstool.html - what you are seeing is the race and the merge. I'm "lm" and "awc" is my Windows guy. We were working parallel and the graph that you are seeing is the revision history after we merged. 1.89 is the merge delta, 1.86.1.1 and 1.86.1.2 are my deltas. If I want to reconstruct just my work, I do an undo and tell it which branch I want gone. And we do all this automagically. That tree of changes is a straight line, no branches tree as far as the user is concerned. The branches are created automatically when changes are merged in, you never have to do that. > j.. Access Control for each user of the development environment: Per user > basis and Per file basis We don't do this because this is an operating system issue. How you achieve the same effect is to restrict access using standard Unix file permissions on the master repository. > k.. Provide secure remote access to environment either through secure CRT, > SSL, domain restrictions, etc. SSH. > l.. Ability to differentiate gear, products and templates for exclusive > use (for one private label) and public use (all private labels) I don't understand this requirement. > Roles and Responsibilities > Engineering > a.. Priviledged access (on a user by user basis) to everything on the site > (cgi, kernels, html, graphics, etc.) This done through the OS. If you have an account and you can read and write the files, then you can read and write the files. > b.. Utilize a versioning source control system (SCS) for updates We provide something which is file format compatible with SCCS, AT&T's original revision control system from the 70's. A lot of people question this, there are claims that the SCCS file format is worse than RCS. That's not true, in fact, the opposite is true. RCS has one potential advantage that they don't even use: they store the most recent delta as a clear file and all the previous ones as diffs (backward diffs for going up the trunk and forward diffs for going down the branches). If RCS stored an offset and a size in the file, then they could seek to to the clear text and write the file out in one system call. They don't do that so they end up reading the whole file anyway (or most of it, it depends). Whatever. Someone could modify RCS to do what I said and it would still suck. Here's why: . No checksum. SCCS checksums the file and verifies the checksum every time you get the file. BK adds an additional per delta checksum. The point is that you put your IP into a system; that system should guard that IP very carefully. RCS makes a performance vs integrity tradeoff which will end up screwin you in the long run. . Annotation. SCCS can trivially give you a copy of the file with each line prefixed by any combination of the revision/user/date which added that line. In addition, BK can check out a copy of the file with every line in every revision in the file. Think about that. You know that somebody changed something and you know the string they changed but you don't know when. In BK you can find out by doing this bk sccscat -mu foo.c | grep string . ChangeSets. SCCS is a changeset engine, people just don't know it. What that means is that I can edit a file on one branch and say "I also want that delta over there which is on a different branch". SCCS will happily include it. You can creat new deltas and include/exclude any arbitrary list of deltas. It may not be obvious, but this is really cool and has far reaching ramifications. Not only can RCS not do this, if you tried to kludge it in, it would grow the file linearly for each include. In SCCS, including or excluding a delta costs you about 4 bytes per included delta. In other words, you can construct multiple different views of your data and it doesn't cost you. Ping me in the conference call about this if I did a poor job explaining it, it is profoundly important. It's what makes SCCS a ChangeSet engine and what makes RCS not a ChangeSet engine. > c.. Each engineer works in an independant workspace (currently known as > playpens) Yup. Each engineer can have as many playpens as s/he wants. Each are fully independent and get this: NO NO NO environment variables. You work in a playpen by saying cd ~/playpen/src bk vi foo.c If you want to work in a different playpen, you just say cd ~/different_playpen/src bk vi bar.c Environment variables suck. Just say no. Dare to break the environment variable habit :-) > d.. Depending on the engineer's privileges - able to push edits to staging > server at the branch or global levels If they have a login and write permissions on the staging area, they can. I really felt no need to reinvent Unix file permissions. Yeah, this screws the NT people but they can emulate the same thing by limiting access to the machine which has the staging area. > Web Development > a.. Priviledged access (on a user by user basis) to limited content on the > site (html, graphics, etc.) > b.. Utilize a versioning source control system (SCS) for updates > c.. Each developer works in an independant workspace (currently known as > playpens) > d.. Depending on the developers privileges - able to push edits to staging > server at the branch or global levels Same as above. > Quality Assurance > a.. Utilizes a selective build configuration management system (CMS) that > allows Q/A to selectivey test and build portions of the site We're weak here in some regards. We don't support partial repositories. In other words, when you do a resync, you get the whole tree. To deal with this, you will naturally split your project up into chunks. Each of these chunks is a repository. So far so good, but the one bummer is when you want to share data between two repositories. We currently don't have any way for data to be in two different "chunks" (we call 'em projects) at the same time. This needs more explanation so please ping me during the conference call. > b.. Ability to rollback change sets and individual files Chuckle. You bet. The easiest (but somewhat slow) way to roll back is like so: suppose you want to roll back to ChangeSet 1.123 (which was conviently tagged with alpha2). $ bk resync -r..alpha2 master alhpa2-test That will create a repository which is identical to the master repository when alpha2 went in (by the way, the tag is just for clarity, anywhere you use a tag you can use a revision). The other way is suppose you had a tree with ... alpha2 - 1.124 - 1.125 and you wanted alpha2. You can dothis $ bk undo 1.124,1.125 and that will DESTROY those two changesets. You'd better have a copy of them somewhere if you want 'em back). > c.. Tie in builds with bug tracking system to complete a closed loop > tracking process Busted. We want to do this but this is a 2.0 or perhaps 3.0 before we have it. We have a plan for doing it but right now we don't have diddly. > d.. Test and submit builds for Go Live! ??? > Release Management > a.. Schedules and approves builds for go live > b.. Coordinates builds with Q/A for testing Seems OK. > Private Label Partners > a.. Restricted access to their branch > b.. Access control based on a case by case basis I don't know what these are. --------------------------------------------- One thing you forgot to ask about is file renames. This is another place where people fall down. We don't (surprise!). We handle file pathname changes identically to file content changes. Pathnames are revisioned and propogate. Consider a couple of test cases: You Me Resync you to me mv foo bar nothing moves foo to bar in my tree change foo mv foo bar applies change in foo to bar in my tree mv foo bar mv foo blech prompts you with name conflict This is not a big deal until you need it to work but then it is a huge deal. It can bring your develpment to a halt for days while your engineers unscramble the mess. We just make that problem go away. You also forgot file permissions. We pick up the permissions as of the time that the file was originally checked in "bk new". After that, if you want to change them, you just say "bk chmod 755 foo.sh" and it saves the modes. On windows, only the top bits (owner permissions) are used, but it doesn't stomp on the lower bits. > Possible Vendors > a.. Continuus - Continuus http://www.continuus.com/ > b.. Interwoven - Teamsite http://www.interwoven.com/ > c.. Clear Case - Need Vendor Name Rational Software, http://www.rational.com > d.. Bit Keeper - Need Vendor Name BitMover, Inc. And it is "BitKeeper" if you want to be picky. http://www.bitkeeper.com Also consider the following: CVS (it's free and I can show you what you could do to sort of have some of these features, not all, but some). Perforce, http://www.perforce.com - I know Chris, great guy, nice little tool. It doesn't do what you want but it is quite popular and you should know it exists. TrueChange from TrueSoft, http://www.truesoft.com - this is the only commercially available ChangeSet engine other than BitKeeper. Cheers, Larry McVoy President, BitMover, Inc. -----End of forwarded message----- -- --- Larry McVoy lm@bitmover.com http://www.bitmover.com/lm From claw@varesearch.com Thu Oct 14 02:40:15 1999 From: claw@varesearch.com (J C Lawrence) Date: Wed, 13 Oct 1999 18:40:15 -0700 Subject: [Mailman-Developers] Plea for Help In-Reply-To: Message from "Barry A. Warsaw" of "Wed, 13 Oct 1999 18:40:53 EDT." <14341.2677.760419.782383@anthem.cnri.reston.va.us> Message-ID: On Wed, 13 Oct 1999 18:40:53 -0400 (EDT) Barry A Warsaw wrote: > Thanks for the info JC. The BK web pages seem pretty out of date > though, and I didn't see anything about downloads. Interestingly > enough I also didn't see any links to the supposedly public free > software change logs :) BK is not released *yet*. Access is currently restricted to people who sign the beta agreement etc. BK should be released fairly soon tho (Larry: What's the current predict?) > Everything else sounds interesting. I'd like to come up with a > solution that would eventually translate to all the projects we've > got here (JPython and Python) so I want to investigate Aegis, and > get Guido's feedback on things as well. Please note that I'm explicitly biased here. I've used and don't like CVS. I'm aware of Aegis only intellectually. Aegis follows a somewhat similar design model to BK, but with a much more overweaning and dictatorial (you will do things our way or you will not do anything so NYAH!) implementation. Compared to the various SCM tools I've used at HP, IBM, SGI, etc I'm damn near in love with BK, so no brownie points for guessing which I'd recommend. > I appreciate all the feedback, information and experience you guys > share. Absolutely. Some of the things I particularly like about BK: -- Cross platform. It is identical under Linux, Solaris, IRIX, Windows NT, etc. -- Resolves 95% of the three way merge problem. -- The GUI tools for merges (when they do happen) does almost exactly what you want a three-way merge tool to do. Some comments I wrote offlist comparing CVS and BK: -- BK removes 95% of the merge problem. That's enough alone to sell it to me. BK's merge tools are not perfect, but they're a sight better than anything else I've seen. -- BK gives you real audit trails for changes. CVS doesn't. No more CVSBLAME. -- BK handles file deletes and renames. CVS doesn't. -- BK allows you to stage work and to distribute only known-working source sets. CVS doesn't. -- Nothing in BK runs as root. CVS' pserver must run as root to allow UID changes, and pserver was not built with security in mind. -- BK can be run over SSH. CVS can run pserver connections over an SSH port forward, but its a pain (I've done it). CVS over SSH performance also sucks. BK over SSH is quite nippy. -- BK can use email, even PGP'ed email, as it transport. CVS can't. -- BK handles binary files transparently. CVS doesn't even pretend to. While BK's handling is not great (it checks in the UUencoded copy), it does work. -- Nothing happens to a BK repository that you don't explicitly Okay, and EVERYTHING can be rolled back to its prior state. Got a bum changeset in? No problem: Just back it out. There are few controls on what happens to a CVS repository other than user/passwd authentication, and absolutely no rollback capabilities. -- One of Larry's big items: BK is very very bandwidth light. You can easily (and often quickly) sync two massive repositories over a slow link. Basically under BK only the absolutely needed changes are sent, nothing else. CVS is not so generous. -- BK imposes no user heirachy. All BK work areas are first class repositories. Resync your work area from a repository and the result is bit identical to the other repository and anybody else can resync from you. CVS imposes a single central server/many-clients model. BK allows any sort of tree, or even mesh, to be used. -- BK handles branches fairly well, sorta. I'm still waiting for Larry's promised LinesOfDevelopment code so I can get a handle on what he's trying to do there. If it is what I understand it will be clean and fairly neat. CVS OTOH is just painful once you have anything more than a single branch. -- BK makes it very easy to seperate your work on a source tree into waht I call "projects" (eg a fix for bug X, new feature Y, etc), each distinct from the others and then lets you track and propagate them individually. While similar is possible under CVS, it is nowhere near as easy and the individual propagation just ain't there. -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From lm@bitmover.com Thu Oct 14 03:15:12 1999 From: lm@bitmover.com (Larry McVoy) Date: Wed, 13 Oct 1999 19:15:12 -0700 Subject: [Mailman-Developers] Plea for Help In-Reply-To: ; from J C Lawrence on Wed, Oct 13, 1999 at 06:40:15PM -0700 References: Message-ID: <19991013191512.43950@work.bitmover.com> On Wed, Oct 13, 1999 at 06:40:15PM -0700, J C Lawrence wrote: > On Wed, 13 Oct 1999 18:40:53 -0400 (EDT) > Barry A Warsaw wrote: > > > Thanks for the info JC. The BK web pages seem pretty out of date > > though, and I didn't see anything about downloads. Interestingly > > enough I also didn't see any links to the supposedly public free > > software change logs :) > > BK is not released *yet*. Access is currently restricted to people > who sign the beta agreement etc. BK should be released fairly soon > tho (Larry: What's the current predict?) We are trying to do one last beta starting around this Friday and ship 1.0 on or close to Nov 1. LODs will not be complete but it is way past the point that it is useful enough it is more a less a crime to keep it hidden. Just my opinion :-) More seriously, Zack Weinberg, one of people who work here on BK, has been pointing out that we should have shipped a month ago, around the time that VA started saying "No more betas, this works". The reason being that while we are busy polishing, there are some bugs that just aren't going to be exposed until we let it go out to the masses. I'm starting to agree. > > Everything else sounds interesting. I'd like to come up with a > > solution that would eventually translate to all the projects we've > > got here (JPython and Python) so I want to investigate Aegis, and > > get Guido's feedback on things as well. > > Please note that I'm explicitly biased here. I've used and don't > like CVS. I'm aware of Aegis only intellectually. Aegis follows a > somewhat similar design model to BK, but with a much more > overweaning and dictatorial (you will do things our way or you will > not do anything so NYAH!) implementation. Compared to the various > SCM tools I've used at HP, IBM, SGI, etc I'm damn near in love with > BK, so no brownie points for guessing which I'd recommend. Aegis has a bunch of problems, which you'll run into when you try it. No NT support and as much as I despise NT, it is as much of a player as Solaris, for example. A bunch of other issues, most of which stem from one problem: Aegis is a layer on top of the revision system, it can sit on SCCS or RCS or whatever. That means that it can only do as well as the greatest common denominator of all of those systems. Which isn't a good place. We rewrote all of SCCS from scratch and our implementation is substantially better than RCS or the other SCCS implementations out there. And we use all of the power of SCCS. SCCS has a bad name, Tichy did a great job badmouthing it when he did RCS, but the fact is that SCCS is a far better file format that RCS. It did have some problems, such as no tag support, no permissions support, no pathname support, etc., but we fixed all of those (in a way which is backwards compat - if you are a Sun machine, you can use Sun's SCCS to read/write our files). There are some non-obvious things that SCCS can do that we are planning to use extensively in BK for LOD support. This is probably the feature you will want the most over the long run. Imagine multiple branches, like the dev, stable, released branches. Imagine being able to be in a visual tool like http://www.bitkeeper.com/sccstool.html , and being able to see all the changesets (a changeset is a lot like what you might think of as a patch, just more formal). Now imagine saying "start up and show me the stable branch but hide the release branch, and hide everything that is in the dev branch that I haven't explicitly included or excluded into the stable branch". The world just became a less cluttered space. Now imagine being able to browse each changeset with http://www.bitkeeper.com/csettool.html and deciding which ones you want and which ones you don't. You can drag and drop the ones you want onto the stable branch and they show up there. And the next time you run this setup, those changes are now hidden in the dev branch. Does that make any sense? It's sort of graphical branch management which can be arbitrarily complex, with an arbitrary number of branches. (well almost arbitrary, we currently limit you to 65535 branches :-) The disk space required for all of those branches is proportional to the patch size. Another way to say this: suppose you had 10 branches and you had a 1GB change which lived in the outer most branch, then got included into each inner branch, one at a time. In RCS, you'd have a 10GB file. In BK, you have a 1GB file plus about 2K of meta data. it's cool stuff like that that we can do because we took the time to write a good revision engine. We looked hard at RCS and came to the conclusion that it was just profoundly broken for the things that we wanted to do and we couldn't fix it. > Absolutely. Some of the things I particularly like about BK: > > -- Cross platform. It is identical under Linux, Solaris, IRIX, > Windows NT, etc. Including ssh support - we got ssh server/client to work on NT. That was the last remaining issue. Other than stuff like group/world permissions and symlinks (which we support, you can have a file that was at different times in its life a symlink, a regular file, a revision controlled MDBM file), the NT world is identical to the Unix world. Whoops - not true, we also support integration with the Visual studio GUI so the NT version actually has that over the Unix stuff. > -- Resolves 95% of the three way merge problem. Man you ain't seen nothing yet. We figured out how to handle the two branch, merge only one way (old -> new, but not the other way), and not have the 3 way diff go to the ever more distance GCA. We can treat the last merge point as a legitimate GCA. And we save enough information that we can find this closer GCA. I went through and tried it both ways on all the merges in the BK source tree itself. On average 9/10 of merge conflicts went away. This is amazingly cool, you have to see it to believe it. > Some comments I wrote offlist comparing CVS and BK: > > -- BK removes 95% of the merge problem. That's enough alone to > sell it to me. BK's merge tools are not perfect, but they're a > sight better than anything else I've seen. You only have the two merge stuff. We have a somewhat broken threeway merge tool that you'll get in the next beta. > -- BK can be run over SSH. CVS can run pserver connections over > an SSH port forward, but its a pain (I've done it). CVS over SSH > performance also sucks. BK over SSH is quite nippy. Yeah it is. I'm supportng the Linux/PPC folks and I have to resync to a machine in bum-f*ck New Mexico that has the lossiest T1 line I've ever had the misfortune to encounter. BK rocks for that. It transfers close to the minimum that must be transfered. I'm realy tickled with this, it is completely reasonable to have remote modem access to huge projects. It works. It never plows through the remote tree to do a resync because we only resync changesets so all we have to look at is the ChangeSet log to see what needs to come across the wire. And we are currently lazy about that and transfer more data than we really need to. But since that over head is in the Kbyte area, we haven't gotten too excited about fixing it. We know how and will some day. > -- BK handles binary files transparently. CVS doesn't even > pretend to. While BK's handling is not great (it checks in the > UUencoded copy), it does work. Yeah, this sucks, in my opinion, in spite of your nice words. I could at the very least gzip and uuencode it (that is a supported mode, it just isn't the default). But the real answer is to have binary specific "plugins" which know how to break apart binaries so you can get meaningful diffs. Binaries are a pain and our support of them, while not horrible, is not anywhere near acceptable in my opinion. Anther long term thing to fix. > -- BK handles branches fairly well, sorta. I'm still waiting for > Larry's promised LinesOfDevelopment code so I can get a handle on > what he's trying to do there. If it is what I understand it will be > clean and fairly neat. CVS OTOH is just painful once you have > anything more than a single branch. The current branch support in BK sucks dog doo. It's non-existant, just basic branches with no way to manage them. That's not branch support. The LOD stuff will make your heart go flip-flop though. yeah, it's all vaporware as far as you are concerned (the first implementation just went into our dev tree), but I swear to you that this will rock your world. I have to get this to work right or Linus won't even consider using BK and I want it for my own tree. It's #! feature on the priority list. Anyway, that's a lot of salesman blather. Let me know if you have specific questions. I'll go check out mailman in the mean time. -- --- Larry McVoy lm@bitmover.com http://www.bitmover.com/lm From bwarsaw@python.org Thu Oct 14 04:26:53 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Wed, 13 Oct 1999 23:26:53 -0400 (EDT) Subject: [Mailman-Developers] Plea for Help References: <14341.2974.845317.266445@anthem.cnri.reston.va.us> Message-ID: <14341.19837.727117.80517@anthem.cnri.reston.va.us> >>>>> "JCL" == J C Lawrence writes: JCL> There's been some brief discussion on Linux-Kernel JCL> (searchable archives at http://www.mail-archive.com/), but JCL> not a whole lot. I've never seen a real installation or user JCL> report from other than the authors. And yet it appears to have been out since 1991. Interesting. From claw@varesearch.com Thu Oct 14 19:04:50 1999 From: claw@varesearch.com (J C Lawrence) Date: Thu, 14 Oct 1999 11:04:50 -0700 Subject: [Mailman-Developers] Plea for Help In-Reply-To: Message from "Barry A. Warsaw" of "Wed, 13 Oct 1999 23:26:53 EDT." <14341.19837.727117.80517@anthem.cnri.reston.va.us> Message-ID: On Wed, 13 Oct 1999 23:26:53 -0400 (EDT) Barry A Warsaw wrote: <> >>>>>> "JCL" == J C Lawrence writes: JCL> There's been some brief discussion on Linux-Kernel (searchable JCL> archives at http://www.mail-archive.com/), but not a whole lot. JCL> I've never seen a real installation or user report from other JCL> than the authors. > And yet it appears to have been out since 1991. Interesting. That's, umm, one way to put it. -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From lindsey@ncsa.uiuc.edu Thu Oct 14 20:42:54 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Thu, 14 Oct 1999 14:42:54 -0500 (CDT) Subject: [Mailman-Developers] mailman vs majordomo In-Reply-To: <19991013181754.15843@work.bitmover.com> from "Larry McVoy" at Oct 13, 99 06:17:54 pm Message-ID: <199910141942.OAA13634@ferret.ncsa.uiuc.edu> > two things: (a) is mailman better than majordomo? I assume it must > be right, or you wouldn't be putting all this effort into it. I'm using > majordomo now and I keep meaning to look for something that has better spam > filters. Forgive the stupid questions, but should I switch? This is probably better on mailman-users... Anyhow, I think mailman and majordomo each have their own place. Majordomo is much more flexible and, in my opinion, powerful. The basic structure is simplistic, but it's very easy to change things. However, it is also pretty admin-intensive and has a braindead digest scheme. mailman takes administrative tasks away from the admin and puts them in the hands of the listowner. It saves time and is a lot easier to configure. Users also find the Web interface easier than an email one. However, Adding features is a pain in the butt, especially if you're not familiar with Python (i.e. I doubt that I'll ever see support for quoted addresses containing spaces, since Mailman splits on whitespace). So if you want to pass administrative tasks to the listowner and have a pretty Web interface, use mailman. If you need to do heavy-duty funky stuff as an admin, use majordomo. Don't get me wrong though -- I like mailman and find it very useful when I want to offload list responsibility. In fact, we're trying to implement it here at NCSA for a majority of our less complicated lists. Chris From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Oct 14 21:07:18 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 14 Oct 1999 16:07:18 -0400 (EDT) Subject: [Mailman-Developers] [lm@bitmover.com: Re: FW: Staging System - Requirements Meeting Recap] References: <19991013181754.15843@work.bitmover.com> Message-ID: <14342.14326.927619.545115@anthem.cnri.reston.va.us> >>>>> "LM" == Larry McVoy writes: LM> hey there, two things: (a) is mailman better than majordomo? I still firmly believe so. We had never ending problems with Majordomo on python.org, which is why (more than the philosophical discomfort :) we made a strong push to get Mailman in operational shape. I've since been able to completely wax Majordomo from my hard drives :) Yes, Mailman needs work. But there are some really great hackers on mailman-developers and I think we just need to structure the project better so that those folks can contribute more directly, without the frustration when the core 5 of us are busy with Real Work. LM> Oh, and you can update "sideways". One developer can slurp in LM> the changes in a another developer's tree directly, without LM> going through the "master" or "shared" tree. In CVS terms, I LM> don't have to go back to the master repository, I can talk LM> directly to you. The hierarchical nature of the system is LM> strictly a convention thing, you can resync from anywhere to LM> anywhere. This really fires me up. I would love to have Mailman's doco team announce "hey, we've got a new revision, please sync with our repository to check it out". Meanwhile the archivists say "we've got the new search engine ready for those who'd like to take a look". So then at some point I get an email saying that there's been enough testing and people are feeling confident about the changes. Until then, maybe I don't even look at the stuff, and only suck it into the master when there's been enough of that sideways development to make things stable. If I got vision right, that's exactly what I'm looking for LM> with the idea being that the ChangeSet comments should be the LM> idea or concept you just did, while the per file comments are LM> implementation details. Another very cool idea, because this is exactly how I'd like to work. Currently I put both levels of detail into the individual file log msgs, but I'd rather do it this way. Is there an equivalent of citool for Emacs? >> h.. Change Logs LM> You get these for free, it's the ChangeSet comment history. One important thing for GNU projects (although I've been lax about it) is the ability to generate GNU ChangeLogs. Emacs has tools for extracting this info out of RCS/CVS log msgs. It would be nice to have the same capability with BK. If there are aliases for "cvs log" then it might be a no-brainer. LM> We do this better than anyone. Period. Everyone else screws LM> up your history. Here's how: you have two developers A and B. LM> They both do CVS update and have the same tree. They both LM> modify file foo.c. A checks in first, so B "lost the race" LM> and has to merge. What CVS will check in is not B's changes, LM> it's B's changes plus whatever B had to do to merge. That is LM> **two events** collapsed into one. Why is this a big deal? LM> Undo. Suppose B's stuff was good and A's stuff wasn't. We LM> can reconstruct B's stuff without the merge. CVS can't. It LM> lost the information. LM> Look at http://www.bitkeeper.com/sccstool.html - what you are LM> seeing is the race and the merge. I'm "lm" and "awc" is my LM> Windows guy. We were working parallel and the graph that you LM> are seeing is the revision history after we merged. 1.89 is LM> the merge delta, 1.86.1.1 and 1.86.1.2 are my deltas. If I LM> want to reconstruct just my work, I do an undo and tell it LM> which branch I want gone. Um, drool. LM> . ChangeSets. SCCS is a changeset engine, people just don't LM> know it. What that means is that I can edit a file on one LM> branch and say "I also want that delta over there which is on LM> a different branch". Indeed, very cool, IIUC. Another thing that sucks in CVS, but which we need surprisingly often, is the ability to include a file in multiple projects. Example, in the Python project we've got a file called Lib/smtplib.py which Guido will edit and change as bug reports come into via the Python channel. Mailman usually just wants to use the latest smtplib.py file, but it lives under the Mailman project in Mailman/pythonlib/smtplib.py. When I see changes happen to the Python tree, I usually checkout the latest version, and commit it to the Mailman tree. This sucks because I've now lost the revision history to the file under Mailman. I can kludge around this by evil tricks like symlinking or hardlinking the ,v file in the repository. That sucks for any number of reasons (rsync to the anonCVS, what if I want to do this for lots of files all over the place, etc.) Does BK provide any kind of support for this? LM> We're weak here in some regards. We don't support partial LM> repositories. In other words, when you do a resync, you get LM> the whole tree. To deal with this, you will naturally split LM> your project up into chunks. Each of these chunks is a LM> repository. So far so good, but the one bummer is when you LM> want to share data between two repositories. We currently LM> don't have any way for data to be in two different "chunks" LM> (we call 'em projects) at the same time. Ah, so I think my answer to above is "no". Well, I guess I'm no worse off :) LM> and that will DESTROY those two changesets. You'd better have LM> a copy of them somewhere if you want 'em back). Hmm, it might be nice if some day those were re-doable. LM> One thing you forgot to ask about is file renames. Equally important is directory renames. Can't be done in CVS, so what you end up doing is creating the new directory, moving all the ,v files in the repository, then doing an update -d -P. The old dir doesn't go away, it's just pruned out 'cause it's empty. There's gotta be a better way. Thanks for all the info Larry, -Barry From will@connectcorp.net Fri Oct 15 00:33:58 1999 From: will@connectcorp.net (Will Leaver) Date: Thu, 14 Oct 1999 16:33:58 -0700 Subject: [Mailman-Developers] Multiple Deliveries Message-ID: <01fe01bf169c$96887de0$0300a8c0@ceo.connectcorp.net> Howdy to all! We are running four lists with Mailman 1.0, Python ver.1.5.1, Linux Red Hat, 5.?, and Sendmail, 8.9.3 We installed Mailman late in August. We have upgraded the smtplib.py to the current version. We are still sending duplicates of every post, and sometimes up to three or four copies. We have searched the archives, and think we understand the problem, but we are lacking clear direction to resolve it. Can anyone help? Will Leaver Joe Whittaker MASLOM, Inc. From a.eyre@optichrome.com Mon Oct 18 15:22:16 1999 From: a.eyre@optichrome.com (Adrian Eyre) Date: Mon, 18 Oct 1999 15:22:16 +0100 Subject: [Mailman-Developers] CVS Access Message-ID: <002801bf1974$2e139800$3acbd9c2@peridot.optichrome.com> The webpage mentions CVS access to sources, but not a CVSROOT. Does anyone have this string? -------------------------------------------- Adrian Eyre Optichrome Computer Solutions Ltd Maybury Road, Woking, Surrey, GU21 5HX, UK Tel: +44 1483 740 233 Fax: +44 1483 760 644 http://www.optichrome.com -------------------------------------------- From adrian.joseph@guardian.co.uk Fri Oct 22 11:55:30 1999 From: adrian.joseph@guardian.co.uk (Adrian Joseph) Date: Fri, 22 Oct 1999 11:55:30 +0100 Subject: [Mailman-Developers] Re: bug report id 146 Message-ID: <00fc01bf1c7b$f5040620$09d5060a@3100.guardian.co.uk> The problem proved to be with a particular message which could not be approved,rejected or discarded. I looked at the message and the sender seemed to be a little odd. So, I made the change below to ListAdmin.py and it seemed to work okay, I don't know if this might cause other problems. Adrian 160c160 < 'sender' : msg.GetSender(), --- > 'sender' : strquote(msg.GetSender()), From jerrya@fastrans.net Fri Oct 22 12:58:40 1999 From: jerrya@fastrans.net (Jerry Adlersfluegel) Date: Fri, 22 Oct 1999 06:58:40 -0500 (CDT) Subject: [Mailman-Developers] unable to edit my archive page Message-ID: I am trying to edit my Archives Index Page with the web interface, and my changes aren't showing up. The archive is private, and works just fine. I just finished configuring ht://dig to index the private archive and now I want to put the search doodads on the archive page. Changes I make on the web form show up in ~/lists/listname/archives.html but never make it to ~/archives/private/listname/index.html, even after someone sends mail to the list. The index.html file is overwritten everytime a message is posted, which blows away anything I tried to add there. Just to see if the web-based editor worked, I was able to successfully edit the General list information page. I would appreciate any help in modifying this file. (Mailman 1.0 on a RedHat 6.0 system.) Thanks! -- Jerry Adlersfluegel From Thomas.Esamie@uts.EDU.AU Wed Oct 27 04:52:07 1999 From: Thomas.Esamie@uts.EDU.AU (Thomas Esamie) Date: Wed, 27 Oct 1999 13:52:07 +1000 Subject: [Mailman-Developers] Mailman installation problems Message-ID: Hi, I'm attempting to install mailman 1.0 on a Mac OS X server and managed to install Python (1.5.2) without too many problems and I ran the ./configure script. When I get to the the "make install" stage for mailman it starts chugging along merrily until we get to the following sequence >for f in answer_majordomo_mail mailcmd mailowner post driver; \ >do \ > /usr/bin/install -c -m 644 $f /Local/Applications/mailman/scripts; \ >done >cc -c -I. -DPREFIX="\"/Local/Applications/mailman\"" -DPYTHON="\"/usr/local/bin/python\"" -DHELPFUL -g -O2 -DHAVE_STRERROR=1 -DHAVE_SETREGID=1 -DHAVE_SYSLOG=1 -DSTDC_HEADERS=1 -DHAVE_SYSLOG_H=1 -DGETGROUPS_T=gid_t -DHAVE_VSNPRINTF=1 ./common.c >./common.c:26: `PREFIX' undeclared here (not in a function) >./common.c:26: `scripts' undeclared here (not in a function) >./common.c:26: parse error before `;' >make[1]: *** [common.o] Error 1 >make: *** [install] Error 2 Well I had a look at common.c and there are these lines which appear to cause the problem #define SCRIPTDIR PREFIX ## "/scripts/" /* trailing slash */ #define MODULEDIR PREFIX /* no trailing slash */ const char* scriptdir = SCRIPTDIR; [note this line is line 26] PREFIX does not appear to be an environment variable and it is not explicitly set in common.h I know this is kind of scratchy stuff but any clues on what to do from here? Greetings, Thomas PS. I'm no guru so assume complete stupidity on my part in any explanation :-) From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Oct 29 16:12:08 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 29 Oct 1999 11:12:08 -0400 (EDT) Subject: [Mailman-Developers] Speeding up Mailman Message-ID: <14361.47432.588695.159990@anthem.cnri.reston.va.us> Here's a bit of low-hanging fruit that might speed up Mailman. I don't know exactly by how much, but it works by starting Python with the -S option. On my Sparc boxes I've seen 4-8x improvement in the startup times of the Python executable. I've tested the patch in that I'm sure it works, but I haven't put it in the python.org operation system yet. I plan on doing that next. Note that this only works for the CGI and mail wrappers, not the bin scripts, but it should still help out a lot. Let me know if you give this a shot, and whether you see any improvement or not. Thanks to Jeremy Hylton for the inspiration. -Barry -------------------- snip snip -------------------- Index: common.c =================================================================== RCS file: /projects/cvsroot/mailman/src/common.c,v retrieving revision 1.18 retrieving revision 1.19 diff -c -r1.18 -r1.19 *** common.c 1999/07/12 20:32:59 1.18 --- common.c 1999/10/29 15:06:43 1.19 *************** *** 196,212 **** newenv[j] = NULL; /* Now put together argv. This will contain first the absolute path ! * to the python executable, then the absolute path to the script, ! * then any additional args passed in argv above. */ ! newargv = (char**)malloc(sizeof(char*) * (argc + 2)); ! newargv[0] = python; ! newargv[1] = (char*)malloc(sizeof(char) * ( strlen(scriptdir) + strlen(script) + 1)); ! strcpy(newargv[1], scriptdir); ! strcat(newargv[1], script); /* now tack on all the rest of the arguments. we can skip argv's * first two arguments because, for cgi-wrapper there is only argv[0]. --- 196,215 ---- newenv[j] = NULL; /* Now put together argv. This will contain first the absolute path ! * to the Python executable, then the -S option (to speed executable ! * start times), then the absolute path to the script, then any ! * additional args passed in argv above. */ ! newargv = (char**)malloc(sizeof(char*) * (argc + 3)); ! j = 0; ! newargv[j++] = python; ! newargv[j++] = "-S"; ! newargv[j] = (char*)malloc(sizeof(char) * ( strlen(scriptdir) + strlen(script) + 1)); ! strcpy(newargv[j], scriptdir); ! strcat(newargv[j], script); /* now tack on all the rest of the arguments. we can skip argv's * first two arguments because, for cgi-wrapper there is only argv[0]. *************** *** 218,227 **** * * TBD: have to make sure this works with alias-wrapper. */ ! for (i = 2; i < argc; i++) ! newargv[i] = argv[i]; ! newargv[i] = NULL; /* return always means failure */ (void)execve(python, &newargv[0], &newenv[0]); --- 221,230 ---- * * TBD: have to make sure this works with alias-wrapper. */ ! for (i=2, j++; i < argc; i++) ! newargv[j++] = argv[i]; ! newargv[j] = NULL; /* return always means failure */ (void)execve(python, &newargv[0], &newenv[0]); From ckolar@admin.aurora.edu Fri Oct 1 15:10:51 1999 From: ckolar@admin.aurora.edu (Christopher Kolar) Date: Fri, 1 Oct 1999 09:10:51 -0500 Subject: [Mailman-Developers] feature requests Message-ID: <99100109180002.09732@kolar.facnet.aurora.edu> While beating on the documentation a few things came to mind. 1. Any chance that the monthly reminder can be used by a bounce handler script as a membership probe (good for low-volume lists). Right now I just get N bounce messages as mailman-owner but I do not see that the list manager ever gets the information. 2. How about adding an "invite" feature like on some of the commercial list providers. The invite would be non-binding, but a simple reply would add the person to the list (I suppose that it would use most of the same code that the sub-confirmation bits use). See listbot and egroups if you do not know what I am talking about. 3. How about a chunk of html code that can be dropped into a web page that would allow a person to just type in their e-mail and click to make a sub request (also something that listbot/egroups do). The request could be handled like a normal sub request with a confirmation request being sent out to the e-mail address that was entered. Is this already possible by hacking the listinfo page to remove everything but the field for e-mail address and the submit button? I deal with a lot of novice users and I would like to take out a lot of the verbiage and the initial password setting. Cheers, --chris -- /////\\\\\/////\\\\\ Christopher G. Kolar Director of Instructional Technology Aurora University, Aurora, Illinois ckolar@admin.aurora.edu -- www.aurora.edu [PGP Public Key ID: 0xC6492C72] From jye@helios.physics.utoronto.ca Tue Oct 5 16:39:26 1999 From: jye@helios.physics.utoronto.ca (Jun Ye) Date: Tue, 5 Oct 1999 11:39:26 -0400 (EDT) Subject: [Mailman-Developers] sublists & Implicit Destination Message-ID: <199910051539.LAA663053@helios.physics.utoronto.ca> Hi, there I just installed Mailman several days ago. However, when a list contains sub-lists, every post requires my approvals on all levels of sub-lists. So one post may require the owner(s) to approve many times. Pain ! Look at this: Your authorization is required for a mailing list posting request approval: List: (list name) Reason held: Implicit destination Can I disable this "feature" site-wise and/or list-wise ? Any one can offer quick advice how to fix it ? P.S. I posted this question on user list but no body reply. So I now count on your guys. Thanks !!! Jun From ddickey@wamnet.com Tue Oct 5 17:26:02 1999 From: ddickey@wamnet.com (Dan A. Dickey) Date: Tue, 05 Oct 1999 11:26:02 -0500 Subject: [Mailman-Developers] sublists & Implicit Destination References: <199910051539.LAA663053@helios.physics.utoronto.ca> Message-ID: <37FA269A.EAD9390@wamnet.com> Jun Ye wrote: > > Hi, there > > I just installed Mailman several days ago. > However, when a list contains sub-lists, > every post requires my approvals on all levels > of sub-lists. So one post may require the owner(s) to > approve many times. Pain ! > > Look at this: > > Your authorization is required for a mailing list posting request > approval: > > List: (list name) > Reason held: Implicit destination > > Can I disable this "feature" site-wise and/or list-wise ? > > Any one can offer quick advice how to fix it ? > > P.S. I posted this question on user list but no body reply. > So I now count on your guys. Thanks !!! Yes, this is possible to do. Let me try to recall what we did here... On the Privacy Options page, set the "Must posts have list named in destination field..." to No. And, in the box right below that, "Alias names (regexps) which qualify as explicit..." fill in the 'top-level' list that the emails come from. You'd do both of these on all of the sub-lists, and nothing on the top level list. For example, suppose you have top-listA, and sub-listB, and sub-listC. top-listA includes sub-listB and sub-listC as members. On the Privacy Options page for both sub-listB and sub-listC, you need to set the require_explicit_destination option to No as described above; and also set the acceptable_aliases option to top-listA. Give that a try! I hope it helps. -Dan -- Dan A. Dickey ddickey@wamnet.com From jafo@tummy.com Wed Oct 6 16:43:58 1999 From: jafo@tummy.com (Sean Reifschneider) Date: Wed, 6 Oct 1999 09:43:58 -0600 Subject: [Mailman-Developers] List archiving broken? Qmail? Message-ID: <19991006094358.A23871@tummy.com> In tracking down why my list archiving has not been functioning, I've found that the .mbox files do not have a 'From ' line at the beginning of each message. I'm forced to wonder if this is a problem with QMail, but normally my mbox format files written from qmail seem to be fine... To work around this, I've added the following lines to the ArchiveMail() function in Archiver/Archiver.py: # archive to builtin html archiver + if not msg.unixfrom: + import time + msg.unixfrom = 'From unknown %s\n' % time.ctime(time.time()) import traceback This seems to cause the archives to begin functioning quite nicely. I would submit that this should probably be there as a fail-safe. Any ideas why the From line might not be getting preserved though? Sean -- That weapon will replace your tongue. You will learn to speak through it. And your poetry will now be written with blood. -- _Dead_Man_ Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. From cherub@azrael.dyn.cheapnet.net Thu Oct 7 04:19:38 1999 From: cherub@azrael.dyn.cheapnet.net (Steven Hazel) Date: Wed, 6 Oct 1999 22:19:38 -0500 (CDT) Subject: [Mailman-Developers] Re: Mailman and your code for online posting In-Reply-To: (message from Susan Snell on Wed, 6 Oct 1999 21:55:43 -0500 (CDT)) References: Message-ID: I hope you don't mind if I cc my reply to the Mailman developers list. Is the code that you submitted to the developers list going to be incorporated into a subsequent release of Mailman? I hope so. It got no response, so I'm not quite sure what's up. When I have more time on my hands I plan to keep my changes current with both the latest release and CVS versions of Mailman and distribute them myself. I figure that should be enough to get an answer one way or the other from the Mailman developers, at least. I'm not familiar with Python and I'd like to get away without me having to make code changes on my system. I'd probably somehow manage to mess things up. If your changes aren't going to be incorporated then I guess I'll have to roll up my sleaves and jump right in. I'd be happy to help you with any problems you have. My other question is have you ever run across an existing list application which allows you to post online in addition to the normal mailing list functionality? Nope. -S From troy@graphon.com Thu Oct 7 21:45:00 1999 From: troy@graphon.com (Troy Morrison) Date: Thu, 07 Oct 1999 13:45:00 -0700 (PDT) Subject: [Mailman-Developers] List archiving broken? Qmail? In-Reply-To: <19991006094358.A23871@tummy.com> Message-ID: qmail does not add a "From " line when it delivers the message into the mailbox. I did something like this for my archives (which aren't using the archiving built into mailman): What I did was to subscribe archives-{listname} to each list I support, and then I have an 'archives' user whose home directory has a '.qmail-default' that does: |preline cat >> ./$DEFAULT && exit 0 man preline for more information. Preline adds the 'From ' line. Troy On 06-Oct-99 Sean Reifschneider wrote: | In tracking down why my list archiving has not been functioning, | I've found that the .mbox files do not have a 'From ' line at | the beginning of each message. I'm forced to wonder if this | is a problem with QMail, but normally my mbox format files | written from qmail seem to be fine... | | To work around this, I've added the following lines to the | ArchiveMail() function in Archiver/Archiver.py: | | # archive to builtin html archiver | + if not msg.unixfrom: | + import time | + msg.unixfrom = 'From unknown %s\n' % time.ctime(time.time()) | import traceback | | This seems to cause the archives to begin functioning quite nicely. | | I would submit that this should probably be there as a fail-safe. | Any ideas why the From line might not be getting preserved though? | | Sean | -- | That weapon will replace your tongue. You will learn to speak through | it. And your poetry will now be written with blood. -- _Dead_Man_ | Sean Reifschneider, Inimitably Superfluous | URL: HP-UX/Linux/FreeBSD/BSDOS scanning | software. | | _______________________________________________ | Mailman-Developers maillist - Mailman-Developers@python.org | http://www.python.org/mailman/listinfo/mailman-developers -- Troy Morrison From jafo@tummy.com Fri Oct 8 13:09:03 1999 From: jafo@tummy.com (Sean Reifschneider) Date: Fri, 8 Oct 1999 06:09:03 -0600 Subject: [Mailman-Developers] List archiving broken? Qmail? In-Reply-To: ; from Troy Morrison on Thu, Oct 07, 1999 at 01:45:00PM -0700 References: <19991006094358.A23871@tummy.com> Message-ID: <19991008060903.O997@tummy.com> On Thu, Oct 07, 1999 at 01:45:00PM -0700, Troy Morrison wrote: >|preline cat >> ./$DEFAULT && exit 0 Of course... What *WAS* I thinking. :-) I still think it's probably a good idea to fake one if we didn't get one (since the archiving needs it). The real fix is, of course, to insert "preline" at the beginning of the aliases for the mailing list wrapper. So, that patch I submitted for qmail aliases should be changed as the following: *** bin/newlist.old Fri Oct 8 06:01:58 1999 --- bin/newlist Fri Oct 8 05:59:08 1999 *************** *** 104,112 **** aliases = ''' To create system aliases: ! echo '|%(wrapper)s post %(listname)s' >~alias/.qmail-%(list)s ! echo '|%(wrapper)s mailowner %(listname)s' >~alias/.qmail-%(admin)s ! echo '|%(wrapper)s mailcmd %(listname)s' >~alias/.qmail-%(request)s echo '&%(listname)s-admin' >~alias/.qmail-%(owner1)s echo '&%(listname)s-admin' >~alias/.qmail-%(owner2)s chmod 644 ~alias/.qmail-%(list)s ~alias/.qmail-%(admin)s --- 104,112 ---- aliases = ''' To create system aliases: ! echo '|preline %(wrapper)s post %(listname)s' >~alias/.qmail-%(list)s ! echo '|preline %(wrapper)s mailowner %(listname)s' >~alias/.qmail-%(admin)s ! echo '|preline %(wrapper)s mailcmd %(listname)s' >~alias/.qmail-%(request)s echo '&%(listname)s-admin' >~alias/.qmail-%(owner1)s echo '&%(listname)s-admin' >~alias/.qmail-%(owner2)s chmod 644 ~alias/.qmail-%(list)s ~alias/.qmail-%(admin)s Sean -- Today's robots are very primitive, capable of understanding only a few simple instructions such as 'go left', 'go right', and 'build car'. -- John Sladek Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. From M. Bruce Cronlund" I am considering using your Mailman product for managing an announcement only type mailing list that will be going out to approximately 8,000 recipients. One question that I have, that I can't seem to find a quick answer for anywhere, is whether there are any limitations placed on the number of addresses that can be assigned to a list. In other words, could I use Mailman for 8 - 10,000 recipients? I thank you for your response. --------------------------------- M. Bruce Cronlund Digital Wave Technologies mailto:brucec@digitalwave.com 215-938-6611 Pager: 215-891-4676 "Things should be made as simple as possible -- no simpler." --Albert Einstein From claw@ Fri Oct 8 19:11:49 1999 From: claw@ (J C Lawrence) Date: Fri, 08 Oct 1999 11:11:49 -0700 Subject: [Mailman-Developers] request for information In-Reply-To: Message from "M. Bruce Cronlund" of "Fri, 08 Oct 1999 13:10:27 EDT." <000301bf11b0$04cca520$3301500a@frezza.stp.tvol.net> Message-ID: On Fri, 8 Oct 1999 13:10:27 -0400 M Bruce Cronlund wrote: > I am considering using your Mailman product for managing an > announcement only type mailing list that will be going out to > approximately 8,000 recipients. One question that I have, that I > can't seem to find a quick answer for anywhere, is whether there > are any limitations placed on the number of addresses that can be > assigned to a list. In other words, could I use Mailman for 8 - > 10,000 recipients? There are no real limits. I've successfully run MailMan lists with up to 150,000 members. -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From claw@varesearch.com Sat Oct 9 06:55:03 1999 From: claw@varesearch.com (J C Lawrence) Date: Fri, 08 Oct 1999 22:55:03 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] (help required) Timeout Problems with Large Mailing list In-Reply-To: Message from J C Lawrence of "Fri, 08 Oct 1999 11:15:45 PDT." Message-ID: > From: J C Lawrence wrote: Sorry about that. Fixed. -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From Robert@grapevine2.com Sat Oct 9 15:45:42 1999 From: Robert@grapevine2.com (Robert) Date: Sat, 09 Oct 1999 10:45:42 -0400 Subject: [Mailman-Developers] Timeout Problems with Large Mailing list Part II In-Reply-To: References: <4.2.0.58.19991008114953.00963980@pop.gv2.com> Message-ID: <4.2.0.58.19991009103325.00b90100@pop.gv2.com> Hi! At 11:15 AM 10/8/99 -0700, you wrote: >On Fri, 08 Oct 1999 11:59:44 -0400 >Robert wrote: > > > I'm serious....we want to add roughly 20-40,000 new Email > > addresses to existing 30,000 Email addresses mailing list. > >Not a problem. There are a few timeout and response time problems >when using the web interface for adding large numbers of >subscribers. These *may* have been fixed now (I haven't checked, >but there was discussion on the area). > >More simply however you can use the commandline bin/add_members >script. I've successfully run this on files containing as many as >5,000 addresses (that's how they were provided to me). > > > I'm seriously considering using this new mailing list manager: > > Subscribe Me Professional by Elite's CGI Script Center at > > http://www.cgiscriptcenter.com/ for $149.00 Any comments on this > > one compared to Mailman? The only nice thing about this Subscribe > > Me Professional is their support forum, which the real > > knowledgeable people will answer any good questions. > >MailMan is a free software product. Support is of course on a best >effort basis, and perhaps more significantly, on an "as willing" >basis. It still timeouts when adding the large Email addresses to the mailing list. Also, when the Mailman is running (processing 35,000 Email addresses 2 times), we could not access to the web site: http://deafdigest.net/mailman/cgi-bin/listinfo.cgi/deafdigest_web Bug in Mailman version 1.0rc3 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (innermost last): File "/home/mailman/scripts/driver", line 84, in run_main from Mailman.Logging.StampedLogger import StampedLogger File "/home/mailman/Mailman/Logging/StampedLogger.py", line 18, in ? from Logger import Logger File "/home/mailman/Mailman/Logging/Logger.py", line 22, in ? from Mailman.Utils import reraise File "/home/mailman/Mailman/Utils.py", line 33, in ? import random File "/usr/lib/python1.5/random.py", line 18, in ? from whrandom import random, uniform, randint, choice # Also for export! ImportError: No module named whrandom Environment variables: VariableValue DOCUMENT_ROOT /home/barry HTTP_ACCEPT_ENCODING gzip, deflate REMOTE_HOST madmax.deafdigest.net SERVER_PORT 80 PATH_TRANSLATED /home/berry/deafdigest_web REMOTE_ADDR 207.138.154.38 HTTP_ACCEPT_LANGUAGE en-us GATEWAY_INTERFACE CGI/1.1 SERVER_NAME www.deafdigest.net HTTP_CONNECTION Keep-Alive HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 4.01; Windows 95) HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/x-quickviewplus, */* REQUEST_URI /mailman/cgi-bin/listinfo.cgi/deafdigest_web PATH /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/robert/bin QUERY_STRING SCRIPT_FILENAME /home/berry/mailman/cgi-bin/listinfo.cgi PATH_INFO /deafdigest_web HTTP_HOST deafdigest.net REQUEST_METHOD GET SERVER_SIGNATURE Apache/1.3.6 Server at www.deafdigest.net Port 80 SCRIPT_NAME /mailman/cgi-bin/listinfo.cgi SERVER_ADMIN webmaster@deafdigest.net SERVER_SOFTWARE Apache/1.3.6 (Unix) PHP/4.0B2 PYTHONPATH /home/mailman SERVER_PROTOCOL HTTP/1.1 REMOTE_PORT 3130 Same for here when accessing to admin.cgi: http://deafdigest.net/mailman/cgi-bin/admin.cgi/deafdigest_web Bug in Mailman version 1.0rc3 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (innermost last): File "/home/mailman/scripts/driver", line 108, in run_main File "/home/mailman/Mailman/Cgi/admin.py", line 28, in ? File "/home/mailman/Mailman/MailList.py", line 40, in ? File "/home/mailman/Mailman/SecurityManager.py", line 28, in ? File "/home/mailman/Mailman/Cookie.py", line 165, in ? File "/usr/lib/python1.5/pickle.py", line 29, in ? ImportError: No module named copy_reg Environment variables: VariableValue DOCUMENT_ROOT /home/barry HTTP_ACCEPT_ENCODING gzip, deflate REMOTE_HOST madmax.deafdigest.net SERVER_PORT 80 PATH_TRANSLATED /home/berry/deafdigest_web REMOTE_ADDR 207.138.154.38 HTTP_ACCEPT_LANGUAGE en-us GATEWAY_INTERFACE CGI/1.1 SERVER_NAME www.deafdigest.net HTTP_CONNECTION Keep-Alive HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 4.01; Windows 95) HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/x-quickviewplus, */* REQUEST_URI /mailman/cgi-bin/admin.cgi/deafdigest_web PATH /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/python/bin QUERY_STRING SCRIPT_FILENAME /home/berry/mailman/cgi-bin/admin.cgi PATH_INFO /deafdigest_web HTTP_HOST deafdigest.net REQUEST_METHOD GET SERVER_SIGNATURE Apache/1.3.6 Server at www.deafdigest.net Port 80 SCRIPT_NAME /mailman/cgi-bin/admin.cgi SERVER_ADMIN webmaster@deafdigest.net SERVER_SOFTWARE Apache/1.3.6 (Unix) PHP/4.0B2 PYTHONPATH /home/mailman SERVER_PROTOCOL HTTP/1.1 REMOTE_PORT 3129 Server status at this time when running 35,000 Email addresses in 2 messages to be sent out at the same time: [root@madmax berry]# uptime 10:43am up 4 days, 3:18, 1 user, load average: 2.97, 2.24, 1.66 [root@madmax berry]# free total used free shared buffers cached Mem: 156484 152312 4172 116796 5048 14704 -/+ buffers/cache: 132560 23924 Swap: 240932 112368 128564 [root@madmax berry]# Server: 350MHz AMD, 160Mb, 1Mb cache What's wrong? Thanks, Robert From starback@ling.uu.se Mon Oct 11 19:59:17 1999 From: starback@ling.uu.se (Per Starback) Date: 11 Oct 1999 20:59:17 +0200 Subject: [Mailman-Developers] Re: [Mailman-Users] Can't change with admin pages In-Reply-To: Per Starback's message of "11 Oct 1999 16:13:45 +0200" References: Message-ID: On mailman-users I wrote about problems I had with one particular list that I couldn't admin with the web interface. Now I know why, and I send this followup to the developer list too, since it might be reason to change something. It turned out that Mailman never sent out any cookies for that particular list. Why? Because the list administrator (not me!) had changed the Base URL for the list by removing "http://" at the beginning of the url. (I don't know what he was trying to achieve with that, but I can understand that some people might be tempted to that with all the non-URL "URLs" that are printed everywhere like that.) Mailman uses the Base URL for cookie stuff. In MakeCookie there is a line path = urlparse(self.web_page_url)[2] # '/mailman' For one of my sensible lists path here became '/mailman/' (note: not exactly as in the comment) but for the bogus list it became instead something else, and I guess that's where things started to go wrong. I changed the Base URL back, and then it works fine again. So what should the lesson be? I'm not sure, but it is nice if Mailman can support clueless list administrators (as long as the main Mailman administrator has a clue) so I don't think the right answer is just "so don't do that!". Probably it shouldn't be allowed to set "Base URL" to any string. I suggest instead that the Mailman administrator should be able to set what basenames should be possible, and the list administrators only can chose from those values. (Most sites would only have one possible value, and then that section could preferrably be deleted from the list admin pages.) -- Per Starback "Life is but a gamble! Let flipism chart your ramble!" P.S. I loved the comments in MakeCookie! From cklempay@chimera.acm.jhu.edu Mon Oct 11 20:59:35 1999 From: cklempay@chimera.acm.jhu.edu (Corbett J. Klempay) Date: Mon, 11 Oct 1999 15:59:35 -0400 (EDT) Subject: [Mailman-Developers] broken mbox? Message-ID: I'm writing here instead of to a general Python list because I'm not sure; the problem may lie with Mailman (not sure). I'm working on a script that reads through a given mbox file from the archives/private subtree and does fun things with it (like index the words, for example :) I am using the UnixMailbox class from the mailbox module. The problem is that having the mailbox module give me the message body (like mailboxobj.fp.read()) gives me the message body, just like it's supposed to...*and* part of the first line of the header of the next message. For example, getting the body on the first message in one of my archives gives: --start--- Mailman 1.0b6 is up and running now...and archiving is in too! The archiving wasn't turned on for this list previously, but it was for some other lists (so it just accumulated the messages in a file, but there was no real archiving -- the real archiver uses a btree -- and no way to view them in a threaded format or whatever). If you want to see what it looks like, view the HOBY list archive (its archiving has been on for months)...link to it from www2.acm.jhu.edu/mailman/listinfo/hoby ------------------------------------------------------------------------------ Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Conscience is the inner voice that warns up that someone may be looking." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 ------------------------------------------------------------------------------ From acm-admin@chi ---end--- (note: the start and end are added in by the script of course...but so you can see the spacing and then the start of the next header). I don't know if this is due to Mailman writing the mbox files screwily (or maybe used to write them screwily; this particular message was dated 11/7/98), or if the mailbox module has a bug of sorts. Anyone seen this / know what's going on? --- Corbett J. Klempay Trilogy Software, Inc. 512.685.4193 (W) | 512.750.1372 (C) corbett.klempay@trilogy.com From cklempay@chimera.acm.jhu.edu Mon Oct 11 21:05:04 1999 From: cklempay@chimera.acm.jhu.edu (Corbett J. Klempay) Date: Mon, 11 Oct 1999 16:05:04 -0400 (EDT) Subject: [Mailman-Developers] broken mbox? In-Reply-To: Message-ID: Oops...not sure how it got in my message, but in my quoted output body, this: >From acm-admin@chi ---end--- should *not* have the > in there...I just looked at the output again..I must have typed that > by accident. --- Corbett J. Klempay Trilogy Software, Inc. 512.685.4193 (W) | 512.750.1372 (C) corbett.klempay@trilogy.com From bwarsaw@python.org Mon Oct 11 21:15:02 1999 From: bwarsaw@python.org (bwarsaw@python.org) Date: Mon, 11 Oct 1999 16:15:02 -0400 (EDT) Subject: [Mailman-Developers] Plea for Help Message-ID: <14338.17734.6158.914332@anthem.cnri.reston.va.us> Folks, As you know, earlier this year I became the primary maintainer for JPython, which means that the time I have available to continue hacking on Mailman has been pretty severely curtailed. My role as webmaster@python.org allowed me to work on it to the point where it now supports all mailing lists on python.org, as well as the Usenet gateways. The current CVS snapshot works well for those purposes, although as we're all aware, Mailman could use a lot of improvement. I greatly appreciate everything you folks do to help each other, and new users, out. Just answering the emails goes a very long way toward easing the burden. I've come to rely on the fact that many of you have a lot of experience with the code base, and are very generous with your time. I'm not the only one of the core maintainers who is extremely busy. I try to work on Mailman as often as I can, but I definitely realize how far back I am lagging. I just can't seem to catch up. And I know the other maintainers are in worse shape than me. I've gotten to the point where I only have time to track those issues that make it to the bugs list, and that sucks. I firmly believe that Mailman is good software that deserves better than I can give it at the moment. So I'm making a plea to you folks to see if anybody has both the experience with Python, and the Mailman source code, and is motivated to join the inner circle. Please be very honest about the time you have available to hack on the software; we all understand what being busy is like. If you think you are able, and would like to join the core maintainer team please send me email. Since Mailman is GNU software, you will have to abide by the GNU guidelines, and assign copyright to your future Mailman changes. I can send you all the necessary GNU information. You should also have a knowledge of CVS and SSH, since those are essential tools we use. Thanks, -Barry From jafo@tummy.com Tue Oct 12 02:12:55 1999 From: jafo@tummy.com (Sean Reifschneider) Date: Mon, 11 Oct 1999 19:12:55 -0600 Subject: [Mailman-Developers] Plea for Help In-Reply-To: <14338.17734.6158.914332@anthem.cnri.reston.va.us>; from bwarsaw@python.org on Mon, Oct 11, 1999 at 04:15:02PM -0400 References: <14338.17734.6158.914332@anthem.cnri.reston.va.us> Message-ID: <19991011191255.L1005@tummy.com> On Mon, Oct 11, 1999 at 04:15:02PM -0400, bwarsaw@python.org wrote: >I'm not the only one of the core maintainers who is extremely busy. I I understand. As I've been saying: It's a great time to be a geek, as long is you like being busy. :-) >to see if anybody has both the experience with Python, and the Mailman >source code, and is motivated to join the inner circle. Please be I'm interested in contributing, of course. While I've found the code to be quite easy for maintinance, I don't feel I have the exposure to the code that allows me to avoid introducing subtle bugs. And, of course, there's that I'm fairly swamped as well. :-) I usually only get time to dig through Mailman on the weekends. I don't expect it to get much better for a couple of weeks. However, I have been thinking that it might be interesting to have a secondary CVS repository where changes could be made and tested and reviewed by anyone. Then, once changes were in and we were confident about them we could submit patch bundles back to the mainstream line. Kind of like what was done with EGCS. Comments? Sean -- I used to think that the brain was the most wonderful organ in my body. Then I realized who was telling me this. -- Emo Phillips Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. From jafo@tummy.com Tue Oct 12 02:22:56 1999 From: jafo@tummy.com (Sean Reifschneider) Date: Mon, 11 Oct 1999 19:22:56 -0600 Subject: [Mailman-Developers] broken mbox? In-Reply-To: ; from Corbett J. Klempay on Mon, Oct 11, 1999 at 03:59:35PM -0400 References: Message-ID: <19991011192256.M1005@tummy.com> On Mon, Oct 11, 1999 at 03:59:35PM -0400, Corbett J. Klempay wrote: >>From acm-admin@chi To answer your second question first, a '>' is often inserted before a bare 'From ' in position 0 to prevent it from being mistaken for the beginning of a new message. See: From here on out. From my point of view. From what I've heard. As far as the mailbox class, it expects a from line to match the following regular expression: _fromlinepattern = r"From \s*[^\s]+\s+\w\w\w\s+\w\w\w\s+\d?\d\s+" \ r"\d?\d:\d\d(:\d\d)?(\s+[^\s]+)?\s+\d\d\d\d\s*$" Your line above doesn't (it's looking for "From something Mon Oct 11 19:21:12 MDT 1999" (where the "MDT" part is optional). That's your problem. According to the docs for mailbox, you can override the _fromlinepattern regex, or the entire _isrealfromline() method if you wish. That should take care of it. Sean -- Put out fires during the daytime. Do your real work at night. Sleep is just an addiction. -- Dieter Muller Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. From Wolf-Dietrich.Ihlenfeldt@CCC.Chemie.Uni-Erlangen.DE Tue Oct 12 16:54:43 1999 From: Wolf-Dietrich.Ihlenfeldt@CCC.Chemie.Uni-Erlangen.DE (Wolf-Dietrich Ihlenfeldt) Date: Tue, 12 Oct 1999 15:54:43 +0000 Subject: [Mailman-Developers] Possible to request/store additional user data? Message-ID: <9910121554.ZM18457@torvs.ccc.uni-erlangen.de> Hello Mailman developers, thank your for developing such an eminently useful program. I am running a Mailman-based mailing list which should only be open to members of a certain special interest group of a scientific society. Subscriptions are configured to require approval. So far this works very well. However, in addition to requesting the email address of new users, I would like to require them to also supply their society membership number, to be able to check their membership status, and archive/display this number together with their email addresses in the admin panels. a) Is this possible? b) If not, is this a planned feature? It might be useful also for other mailing list administrators. -- Dr. Wolf-D. Ihlenfeldt Computer Chemistry Center, University of Erlangen-Nuernberg Naegelsbachstrasse 25, D-91052 Erlangen (Germany) Tel (+49)-(0)9131-85-26579 Fax (+49)-(0)9131-85-26566 --- The three proven methods for ultimate success and fame: 1) Nakanu nara koroshite shimae hototogisu 2) Nakanu nara nakasete miseyou hototogisu 3) Nakanu nara naku made matou hototogisu From bwarsaw@python.org Tue Oct 12 16:24:13 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Tue, 12 Oct 1999 11:24:13 -0400 (EDT) Subject: [Mailman-Developers] Plea for Help References: <14338.17734.6158.914332@anthem.cnri.reston.va.us> <19991011191255.L1005@tummy.com> Message-ID: <14339.21149.443863.835164@anthem.cnri.reston.va.us> >>>>> "SR" == Sean Reifschneider writes: SR> However, I have been thinking that it might be interesting to SR> have a secondary CVS repository where changes could be made SR> and tested and reviewed by anyone. Then, once changes were in SR> and we were confident about them we could submit patch bundles SR> back to the mainstream line. SR> Kind of like what was done with EGCS. Another possibility is using BitKeeper as our revision control system. Please check out www.bitkeeper.com -- they have some very interesting software that would allow us to be more liberal about how developers interact with the source code. I think it would essentially let everyone on this list develop and share their changes. The idea would be that once there's consensus from the community, one of us cabalists would integrate it into the primary repository and "bless" the changes for the next official release. There are three downsides as I see it: 1) BitKeeper is not free software, and Mailman's a GNU project, so that matters. It may matter less than whether Mailman thrives or not at all. 2) We have no experience with BitKeeper so our infrastructure isn't set up for it. Does it integrate with Emacs? Can we easily suck in our CVS history, and perhaps as important, can we export back into CVS if we find it's necessary some time down the road? 3) Those who want to contribute will have to learn YASCCS. I'd like to know what you all think about this. I have no problems with the requirement that our change logs be public (they are anyway). -Barry From vic@vgg.sci.uma.es Tue Oct 12 17:35:24 1999 From: vic@vgg.sci.uma.es (Victoriano Giralt) Date: Tue, 12 Oct 1999 18:35:24 +0200 (MEST) Subject: [Mailman-Developers] Plea for Help In-Reply-To: <14339.21149.443863.835164@anthem.cnri.reston.va.us> Message-ID: On Tue, 12 Oct 1999, Barry A. Warsaw wrote: > > >>>>> "SR" == Sean Reifschneider writes: > > SR> However, I have been thinking that it might be interesting to > SR> have a secondary CVS repository where changes could be made [snip] > > Another possibility is using BitKeeper as our revision control > system. Please check out www.bitkeeper.com -- they have some very > [snip] > There are three downsides as I see it: > > 1) BitKeeper is not free software, and Mailman's a GNU project, so For me, absolute NO-NO [snip] > > 2) We have no experience with BitKeeper so our infrastructure isn't > set up for it. Does it integrate with Emacs? Can we easily suck [snip] > 3) Those who want to contribute will have to learn YASCCS. [snip] My answer to point 3 is absolutely not. I'm trying to standardize CVS for all our inhouse development, at the very least for my own team and the teams in my area, and outside I'm the strongest proponent-evangelist of free software, so I'm not going to propose or spend a bit of effort on a proprietary product, once we are in the road to learn CVS. I'm not a CVS guru (yet :) ;), but I think it would be to difficult to set up a mechanism as the one proposed by Sean, moreover once it has been already done for another project, as can be infered from his message. Flame-GNU-free-ly, -- Victoriano Giralt Systems Programmer Central Computing Facility University of Málaga SPAIN From cklempay@chimera.acm.jhu.edu Tue Oct 12 17:38:59 1999 From: cklempay@chimera.acm.jhu.edu (Corbett J. Klempay) Date: Tue, 12 Oct 1999 12:38:59 -0400 (EDT) Subject: [Mailman-Developers] broken mbox? In-Reply-To: <19991012103203.R1005@tummy.com> Message-ID: Hmm..but this is what I'm saying...none of these messages start with From. The From you saw is taken from the header of the next message (none of the sentences in the message body start with From). That's the problem I'm talking about...every message (if I run the script and watch it go throught the first 10 or 20 messages in the mbox file) is read wrong or something by the mailbox module, as requesting their message bodies always has this fragment of the header from the following message. --- Corbett J. Klempay Trilogy Software, Inc. 512.685.4193 (W) | 512.750.1372 (C) corbett.klempay@trilogy.com On Tue, 12 Oct 1999, Sean Reifschneider wrote: > On Mon, Oct 11, 1999 at 09:45:29PM -0400, Corbett J. Klempay wrote: > >Hmm..I guess you missed my immediate follow up message...that > was not > >supposed to be there...I seem to have typed it by accident (I reran my > >program several times to make sure...sure enough, the output of my program > >does not have a > before the From, and the actual mbox file doesn't have > >it either). ? > > Sending e-mail with a line that starts with "From" causes a '>' to be > inserted, as I demonstrated in the message I sent to you. The point > still remains that you had a "From" line which was not in a format > recognised by the Python mailbox code, and it had nothing to do with > the '>' that appeared in your mail message. > > Sean > -- > [...] Premature optimization is the root of all evil. > -- Donald Knuth > Sean Reifschneider, Inimitably Superfluous > URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. > From gonter@maestria.wu-wien.ac.at Tue Oct 12 18:11:41 1999 From: gonter@maestria.wu-wien.ac.at (Gerhard Gonter) Date: Tue, 12 Oct 1999 19:11:41 +0200 (MES) Subject: [Mailman-Developers] multilingual mailman In-Reply-To: <19990919005451.B2887@tummy.com> from Sean Reifschneider at "Sep 19, 99 00:54:51 am" Message-ID: <199910121711.TAA64068@maestria.wu-wien.ac.at> According to Sean Reifschneider: > On Sat, Sep 18, 1999 at 10:27:40AM +0200, Gerhard Gonter wrote: > >Are there any plans to for non-english user interfaces which can be > >selected individually by the user or at least for a whole list? > > What about an approach that would use an interface like this: > > setlang('German') > print translang['ERROR: You have selected an invalid option ("%s")'] > print translang[' Please try again...'] > > I imagine a shelve called "German" which has as the key the hash of the > string, and as the value the translated string. [...] > > Any comments? A sophisticated approach like your example with some sort of automatic translation is certainly an insteresting goal. Another much simpler and only partial solution to start with would be a translate a couple of templates. This may be sufficient to keep the bulk of non-english speaking users happy enough to accept mailman. A modification of Utils.maketext in a way to select a list-specific templates directory could do the trick, e.g. an additional parameter which defaults to En_US or C. The template directory would contain language specific subdirectories ~mailman/templates/ En_US/ Fr_FR/ De_DE/ The templates directory could also contain the shelves for the more sophisticated translation part. Well... Just a thought ... +gg -- Gerhard.Gonter@wu-wien.ac.at Fax: +43/1/31336/702 g.gonter@ieee.org Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From lindsey@ncsa.uiuc.edu Tue Oct 12 18:39:45 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Tue, 12 Oct 1999 12:39:45 -0500 (CDT) Subject: [Mailman-Developers] broken mbox? In-Reply-To: from "Corbett J. Klempay" at Oct 12, 99 12:38:59 pm Message-ID: <199910121739.MAA31188@ferret.ncsa.uiuc.edu> > Hmm..but this is what I'm saying...none of these messages start with From. > The From you saw is taken from the header of the next message (none of the > sentences in the message body start with From). That's the problem I'm > talking about...every message (if I run the script and watch it go > throught the first 10 or 20 messages in the mbox file) is read wrong or > something by the mailbox module, as requesting their message bodies always > has this fragment of the header from the following message. Try preprocessing your mailbox with formail (part of the procmail suite, available at procmail.org). It will automatically generate missing From_ headers for you or rebuild broken ones (like you have). Something like formail -I"Content-Length:" -I"From " < inbox | formail -m 6 -des > outbox might do the trick. You'll need to play with the numeric value -- it is the number of headers that must appear in a row for the matching lines to be considered part of a new email message. The higher you can set it, the better because lower values may match on headers within attachments (i.e. Content-Disposition, etc.) Chris From vic@vgg.sci.uma.es Tue Oct 12 18:58:22 1999 From: vic@vgg.sci.uma.es (Victoriano Giralt) Date: Tue, 12 Oct 1999 19:58:22 +0200 (MEST) Subject: [Mailman-Developers] multilingual mailman In-Reply-To: <199910121711.TAA64068@maestria.wu-wien.ac.at> Message-ID: On Tue, 12 Oct 1999, Gerhard Gonter wrote: > According to Sean Reifschneider: > > On Sat, Sep 18, 1999 at 10:27:40AM +0200, Gerhard Gonter wrote: > > >Are there any plans to for non-english user interfaces which can be > > >selected individually by the user or at least for a whole list? > > > > What about an approach that would use an interface like this: > > > > setlang('German') > > print translang['ERROR: You have selected an invalid option ("%s")'] > > print translang[' Please try again...'] > > > > I imagine a shelve called "German" which has as the key the hash of the > > string, and as the value the translated string. [...] > > > A sophisticated approach like your example with some sort of automatic > translation is certainly an insteresting goal. Another much simpler > > The template directory would contain language specific subdirectories > ~mailman/templates/ > En_US/ > Fr_FR/ > De_DE/ There is already an effort that has gone that way (using GNU gettext for aidding in the translation). We have a working copy of mailman with spanish, english and german interface, and, I think, somebody working on japanesse and swedish. We have submited the patches to Barry Warsaw and he said we would integrate them when he can ease the overload he is suffering at the moment. You can visit it at http://joker.sci.uma.es/mailman/listinfo/test For the admin password and more info, please, contact Juan Carlos Rey Anaya . Joker is his workstation and he has done the dirty coding work. I have been blessed with funding his time for the project and playing boss :) -- Victoriano Giralt Systems Programmer Central Computing Facility University of Málaga SPAIN From jafo@tummy.com Wed Oct 13 09:56:15 1999 From: jafo@tummy.com (Sean Reifschneider) Date: Wed, 13 Oct 1999 02:56:15 -0600 Subject: [Mailman-Developers] Problem with % formatting. Message-ID: <19991013025615.L1005@tummy.com> Boy, this percent formatting is really turning out to be a problem. For about the last week, a list I manage has been having severe problems, but I didn't realize fully HOW severe (the only report was that digests had duplicate messages in them). It turns out that the code which creates the headers and footers from the template was missing an 's' on this list, so it had "%(real_name):". This meant that the message was being written for archiving with every delivery, but every REAL attempt to deliver was failing. I've made a patch for the specific instance of this problem (switching to a SafeDict at the same time). However, I think the real answer may be something like the following in Util.py: def Formatter(fmt, data): if type(data) == types.DictType: data = SafeDict(data) try: s = fmt % data except ValueError: s = fmt return(s) and use this function in place of % formatting, *PARTICULARLY* where the LHS is user-provided. Sean ====================== *** MailList.py.old Wed Oct 13 02:28:31 1999 --- MailList.py Wed Oct 13 02:36:26 1999 *************** *** 1346,1356 **** pass self.LogMsg("post", "post to %s from %s size=%d", self._internal_name, msg.GetSender(), len(msg.body)) ! d = self.__dict__.copy() d['cgiext'] = mm_cfg.CGIEXT self.DeliverToList(msg, recipients, ! header = self.msg_header % d, ! footer = self.msg_footer % d) if ack_post: self.SendPostAck(msg, sender) self.last_post_time = time.time() --- 1346,1362 ---- pass self.LogMsg("post", "post to %s from %s size=%d", self._internal_name, msg.GetSender(), len(msg.body)) ! d = Utils.SafeDict(self.__dict__.copy()) d['cgiext'] = mm_cfg.CGIEXT + + # Make sure invalid formatting doesn't frob us up + try: header = self.msg_header % d + except ValueError: header = self.msg_header + try: footer = self.msg_footer % d + except ValueError: footer = self.msg_footer self.DeliverToList(msg, recipients, ! header = header, ! footer = footer) if ack_post: self.SendPostAck(msg, sender) self.last_post_time = time.time() -- [...] Premature optimization is the root of all evil. -- Donald Knuth Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. From jafo@tummy.com Wed Oct 13 10:09:26 1999 From: jafo@tummy.com (Sean Reifschneider) Date: Wed, 13 Oct 1999 03:09:26 -0600 Subject: [Mailman-Developers] Plea for Help In-Reply-To: ; from Victoriano Giralt on Tue, Oct 12, 1999 at 06:35:24PM +0200 Message-ID: <19991013030833.M1005@tummy.com> On Tue, Oct 12, 1999 at 06:35:24PM +0200, Victoriano Giralt wrote: >For me, absolute NO-NO Personally, I'm more concerned with the ongoing viability of Mailman. It's a sweet system, however it does need regular maintinance. Added features would be good too: lftp ftp.list.org:/pub/mailman> ls mailman-1.0rc3.tgz -rw-r--r-- 1 604 601 906745 Jul 12 09:20 mailman-1.0rc3.tgz lftp ftp.list.org:/pub/mailman> If you make it hard for folks to contribute, they won't. Their contributions getting lost in a black hole qualify as "hard". >> 3) Those who want to contribute will have to learn YASCCS. > >My answer to point 3 is absolutely not. I'm trying to standardize CVS for >all our inhouse development, at the very least for my own team and the With all due respect, do you have a better solution to the current problems? If the choice is between using a non-GNU tool and watching MailMan wither, I'll select the former. Perhaps I'm just tainted by trying to meet the mortgage while working on Open Source Software, but I don't have a problem with non-free software... >I'm not a CVS guru (yet :) ;), but I think it would be to difficult to set >up a mechanism as the one proposed by Sean, moreover once it has been >already done for another project, as can be infered from his message. Hmm. I'm afraid I'm not able to parse the above. Are you saying that it would be difficult to set up a second CVS repository? Sean -- "All I'm saying is that when I'm around you I find myself showing off, which is the idiots version of being interesting." -- _LA_Story_ Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. From jafo@tummy.com Wed Oct 13 10:13:10 1999 From: jafo@tummy.com (Sean Reifschneider) Date: Wed, 13 Oct 1999 03:13:10 -0600 Subject: [Mailman-Developers] Plea for Help In-Reply-To: <14339.21149.443863.835164@anthem.cnri.reston.va.us>; from Barry A. Warsaw on Tue, Oct 12, 1999 at 11:24:13AM -0400 References: <14338.17734.6158.914332@anthem.cnri.reston.va.us> <19991011191255.L1005@tummy.com> <14339.21149.443863.835164@anthem.cnri.reston.va.us> Message-ID: <19991013031310.N1005@tummy.com> On Tue, Oct 12, 1999 at 11:24:13AM -0400, Barry A. Warsaw wrote: >system. Please check out www.bitkeeper.com -- they have some very >interesting software that would allow us to be more liberal about how >developers interact with the source code. I think it would The feature that sounds most interesting is: Distributed means that every developer gets their own personal repository and the tool handles moving changes between repositories. This is exactly what I was thinking of doing with the more public CVS repository. Unfortunately, I don't believe that CVS has any sort of mechanism for doing this automaticly, So, that means that the core developers still have to do a lot of work to maintain it. Sean -- "Yes on one, no on two." "Is number one nuke Russia, or number two?" -- _Buckaroo_Banzai_ Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. From jafo@tummy.com Wed Oct 13 10:24:17 1999 From: jafo@tummy.com (Sean Reifschneider) Date: Wed, 13 Oct 1999 03:24:17 -0600 Subject: [Mailman-Developers] Re: [Mailman-Users] Can't change with admin pages In-Reply-To: ; from Per Starback on Mon, Oct 11, 1999 at 08:59:17PM +0200 References: Message-ID: <19991013032417.O1005@tummy.com> On Mon, Oct 11, 1999 at 08:59:17PM +0200, Per Starback wrote: > path = urlparse(self.web_page_url)[2] # '/mailman' Is that comment supposed to mean something? Should the above code be changed to something more like: path = urlparse(self.web_page_url)[2] # '/mailman' if not path: path = self.web_page_url I don't fully understand how path interacts with the rest of that cookie code though. I'm really supposed to be working now. :-) Ideally, the user-interface should check that the URL is acceptable, but IMHO the back-end code should be made more robust as well. Sean -- Problem with Closed Source Software #101: "We have found 46 ways to remotely crash NT by sending authentication packets." Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. From bwarsaw@python.org Wed Oct 13 16:01:42 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Wed, 13 Oct 1999 11:01:42 -0400 (EDT) Subject: [Mailman-Developers] Plea for Help References: <14338.17734.6158.914332@anthem.cnri.reston.va.us> <19991011191255.L1005@tummy.com> <14339.21149.443863.835164@anthem.cnri.reston.va.us> <19991013031310.N1005@tummy.com> Message-ID: <14340.40662.126399.12714@anthem.cnri.reston.va.us> >>>>> "SR" == Sean Reifschneider writes: SR> Distributed means that every developer gets their own personal SR> repository and the tool handles moving changes between SR> repositories. SR> This is exactly what I was thinking of doing with the more SR> public CVS repository. Unfortunately, I don't believe that SR> CVS has any sort of mechanism for doing this automaticly, So, SR> that means that the core developers still have to do a lot of SR> work to maintain it. My sentiments exactly. What would be ideal would be some kind of hiearchical arrangement of repositories. Let's say the I18N guys work on their patches for multi-languages. Another group works on archiving improvements. Another group is improving the web interface. Maybe I hack on the database schema. As each subproject reaches various milestones, those changes would percolate up the repository hierarchy so that wider groups of folks could bang on them. At some point, they would pass greater scrutiny and end up ready for the main tree. These changes would have to merge cleanly with all the other changes coming down from the top. Eventually, I'd know that enough people like the change, have tested it, and understand it so that I can pull it into the main branch without reading every single line of code. There's another approach, which is more work upfront, but is probably worth it anyway. The way Guido deals with the enormity of Python development is that his source is very modular. There are core bits that he cares very deeply about, and will not commit to unless he's read every line. He'll nitpick over minor details until the patch is just right. That's a good thing because you want to be sure the critical stuff is clean, consistent, robust, etc. But enough of the code is modular so that he doesn't have to look at every line of the Python library, or peripheral objects or modules. Sure, sometimes patches will break things, but that usually comes out during beta testing, and besides if they're really broken it doesn't hose Python completely. We aren't there with Mailman; there is much too much interdependence in the code base. It would be a lot of work to separate components out so that people can work on them independently. And Mailman the same kind of project as Python, so there's a limit to how much modularity can be had. Anyway, I'm rambling, but I'm glad you guys are talking about this stuff. I want to do anything I can to maintain the longterm viability of Mailman, and the usefulness of the program outside python.org. As long as I'm webmaster over here, I'm sure I'll be using Mailman, but my own personal requirements may not completely coincide with y'all's. So its good to hear what your ideas are. Thanks, -Barry From gonter@maestria.wu-wien.ac.at Wed Oct 13 21:09:48 1999 From: gonter@maestria.wu-wien.ac.at (Gerhard Gonter) Date: Wed, 13 Oct 1999 22:09:48 +0200 (MES) Subject: [Mailman-Developers] Plea for Help In-Reply-To: <19991013031310.N1005@tummy.com> from Sean Reifschneider at "Oct 13, 99 03:13:10 am" Message-ID: <199910132009.WAA56410@maestria.wu-wien.ac.at> According to Sean Reifschneider: > This is exactly what I was thinking of doing with the more public CVS > repository. Unfortunately, I don't believe that CVS has any sort of > mechanism for doing this automaticly, So, that means that the core > developers still have to do a lot of work to maintain it. There is nothing in software engineering that works truely automaticaly, behind the scenes there is always some good spirit who lends a helping hand or speaks a magic spell ;) With all due respect to the mailman development effort, CVS is used in open source projects much larger than Mailman or even Python. All three BSD's[1] are nice examples, all with anonymous CVS, CVS web, bug tracking and developer lists. (FreeBSD even offers the CVS repository itself to be ftp'ed.) Concentrating development to one central CVS repository and using the branches for those various improvements might work like the hierarchical arrangement of repositories BAW mentioned in his post a while ago. This seems to be quite successfull for the BSD's already mentioned. Summary: keep CVS, add CVS web and use branches References: [1] www.freebsd.org, www.openbsd.org, www.netbsd.org +gg -- Gerhard.Gonter@wu-wien.ac.at Fax: +43/1/31336/702 g.gonter@ieee.org Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Oct 13 21:17:10 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 13 Oct 1999 16:17:10 -0400 (EDT) Subject: [Mailman-Developers] Plea for Help References: <19991013031310.N1005@tummy.com> <199910132009.WAA56410@maestria.wu-wien.ac.at> Message-ID: <14340.59590.668220.421674@anthem.cnri.reston.va.us> >>>>> "GG" == Gerhard Gonter writes: GG> Summary: keep CVS, add CVS web and use branches Not sure about the branches bit. We had a horrible experience recently trying to use CVS branches on the Python tree. Okay, maybe it's just me, but I would be very hesitant about using branches again. -Barry From jarrell@vt.edu Wed Oct 13 20:38:05 1999 From: jarrell@vt.edu (Ron Jarrell) Date: Wed, 13 Oct 1999 15:38:05 -0400 Subject: [Mailman-Developers] Plea for Help In-Reply-To: References: <14339.21149.443863.835164@anthem.cnri.reston.va.us> Message-ID: <4.2.0.58.19991013153718.00cf11c0@vtserf.cc.vt.edu> --=====================_48520035==_.ALT Content-Type: text/plain; charset="us-ascii" At 06:35 PM 10/12/99 +0200, Victoriano Giralt wrote: >I'm not a CVS guru (yet :) ;), but I think it would be to difficult to set >up a mechanism as the one proposed by Sean, moreover once it has been >already done for another project, as can be infered from his message. I'm thinking from the rest of your note that you meant "would *not* be difficult"? --=====================_48520035==_.ALT Content-Type: text/html; charset="us-ascii" At 06:35 PM 10/12/99 +0200, Victoriano Giralt wrote:
I'm not a CVS guru (yet :) ;), but I think it would be to difficult to set
up a mechanism as the one proposed by Sean, moreover once it has been
already done for another project, as can be infered from his message.

I'm thinking from the rest of your note that you meant "would *not* be
difficult"?
 --=====================_48520035==_.ALT-- From cklempay@chimera.acm.jhu.edu Wed Oct 13 22:25:24 1999 From: cklempay@chimera.acm.jhu.edu (Corbett J. Klempay) Date: Wed, 13 Oct 1999 17:25:24 -0400 (EDT) Subject: [Mailman-Developers] Plea for Help In-Reply-To: <14340.59590.668220.421674@anthem.cnri.reston.va.us> Message-ID: The thing that worries me about kicking off all of these brances is the potential for a HUGE speed it. (depending on how many) --- Corbett J. Klempay Trilogy Software, Inc. 512.685.4193 (W) | 512.750.1372 (C) corbett.klempay@trilogy.com On Wed, 13 Oct 1999, Barry A. Warsaw wrote: > > >>>>> "GG" == Gerhard Gonter writes: > > GG> Summary: keep CVS, add CVS web and use branches > > Not sure about the branches bit. We had a horrible experience > recently trying to use CVS branches on the Python tree. Okay, maybe > it's just me, but I would be very hesitant about using branches > again. > > -Barry > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers > From vic@vgg.sci.uma.es Wed Oct 13 23:19:43 1999 From: vic@vgg.sci.uma.es (Victoriano Giralt) Date: Thu, 14 Oct 1999 00:19:43 +0200 (MEST) Subject: [Mailman-Developers] Plea for Help In-Reply-To: <4.2.0.58.19991013153718.00cf11c0@vtserf.cc.vt.edu> Message-ID: On Wed, 13 Oct 1999, Ron Jarrell wrote: > At 06:35 PM 10/12/99 +0200, Victoriano Giralt wrote: > > I'm thinking from the rest of your note that you meant "would *not* be > difficult"? > Right on target. I meant NOT difficult. -- Victoriano Giralt Systems Programmer Central Computing Facility University of Málaga SPAIN From jarrell@vt.edu Wed Oct 13 22:56:36 1999 From: jarrell@vt.edu (Ron Jarrell) Date: Wed, 13 Oct 1999 17:56:36 -0400 Subject: [Mailman-Developers] Plea for Help In-Reply-To: <14340.59590.668220.421674@anthem.cnri.reston.va.us> References: <19991013031310.N1005@tummy.com> <199910132009.WAA56410@maestria.wu-wien.ac.at> Message-ID: <4.2.0.58.19991013175544.04ba5800@vtserf.cc.vt.edu> --=====================_51322084==_.ALT Content-Type: text/plain; charset="us-ascii" At 04:17 PM 10/13/99 -0400, Barry A. Warsaw wrote: > >>>>> "GG" == Gerhard Gonter writes: > > GG> Summary: keep CVS, add CVS web and use branches > >Not sure about the branches bit. We had a horrible experience >recently trying to use CVS branches on the Python tree. Okay, maybe >it's just me, but I would be very hesitant about using branches >again. Works pretty well for BSD and INN... Just takes some practice. I'd ask one of the folks that set it up for them for advice... --=====================_51322084==_.ALT Content-Type: text/html; charset="us-ascii" At 04:17 PM 10/13/99 -0400, Barry A. Warsaw wrote:

>>>>> "GG" == Gerhard Gonter <gonter@maestria.wu-wien.ac.at> writes:

    GG> Summary: keep CVS, add CVS web and use branches

Not sure about the branches bit.  We had a horrible experience
recently trying to use CVS branches on the Python tree.  Okay, maybe
it's just me, but I would be very hesitant about using branches
again.

Works pretty well for BSD and INN... Just takes some practice.  I'd ask one of the
folks that set it up for them for advice... --=====================_51322084==_.ALT-- From Harald.Meland@usit.uio.no Wed Oct 13 23:08:47 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 14 Oct 1999 00:08:47 +0200 Subject: [Mailman-Developers] Re: [Mailman-Users] Usability patch: (D In-Reply-To: Ricardo Kustner's message of "Wed, 18 Aug 1999 20:29:51 +0200 (CEST)" References: Message-ID: [Ricardo Kustner] > On 18-Aug-99 Bernhard Reiter wrote: > > I can understand that the developers are busy. > same here... but i've never had any reactions to the suggestions i posted in > here so i kind of got the feeling that nobody took me seriously... It doesn't appear that anyone has answered this (posted nearly two months ago), although it indeed does deserve comment. For me, the last few months have been a bad case of Too Busy Doing Real Work -- I'm sorry if anyone have gotten the impression that we (the core developers/Mailman cabal[1]) aren't taking suggestions seriously. I am now just starting to get my head above water, and hope to be able to start hacking a little on Mailman in a week or two. Until I'm confident that it really is air I'm breathing again, I'll just keep a low profile, skimming over the messages that have come to the list(s) these last months, and of course trying to take note of patches/suggestions/bug reports etc. Glad to be back (well, nearly, anyway :), [1] However, of course There Is No Cabal[TM] ;) -- Harald From claw@varesearch.com Wed Oct 13 23:11:29 1999 From: claw@varesearch.com (J C Lawrence) Date: Wed, 13 Oct 1999 15:11:29 -0700 Subject: [Mailman-Developers] Plea for Help In-Reply-To: Message from "Barry A. Warsaw" of "Tue, 12 Oct 1999 11:24:13 EDT." <14339.21149.443863.835164@anthem.cnri.reston.va.us> Message-ID: On Tue, 12 Oct 1999 11:24:13 -0400 (EDT) Barry A Warsaw wrote: > Another possibility is using BitKeeper as our revision control > system. I've been using BitKeeper heavily for about 6 months now. Gorgeous stuff. > 2) We have no experience with BitKeeper so our infrastructure > isn't set up for it. Does it integrate with Emacs? Yes. > Can we easily suck in our CVS history, and perhaps as important, Yes, with caveats. Larry isn't willing to release the port tool yet as it is, umm, fragile and may lose data from your repository. Happily Larry is often willing to assist with such transfers. > can we export back into CVS if we find it's necessary some time > down the road? BK is a superset of CVS. As such some data (not code) will be lost in such a transition. There's nothing you can do about this. > 3) Those who want to contribute will have to learn YASCCS. If you know RCS or SCCS learning BK is a doddle. Just do exactly the same things you used to do and put "bk" in the front of every string. $ bk get file.c $ bk co -l file.c After that its just a matter of adding the commit and resync commands and you're pretty well away to running. -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From claw@varesearch.com Wed Oct 13 23:16:20 1999 From: claw@varesearch.com (J C Lawrence) Date: Wed, 13 Oct 1999 15:16:20 -0700 Subject: [Mailman-Developers] Plea for Help In-Reply-To: Message from Victoriano Giralt of "Tue, 12 Oct 1999 18:35:24 +0200." Message-ID: On Tue, 12 Oct 1999 18:35:24 +0200 (MEST) Victoriano Giralt wrote: > My answer to point 3 is absolutely not. I'm trying to standardize > CVS for all our inhouse development, at the very least for my own > team and the teams in my area, and outside I'm the strongest > proponent-evangelist of free software, so I'm not going to propose > or spend a bit of effort on a proprietary product, once we are in > the road to learn CVS. As a tired voice of experience: Please come back when you've learned the agony of CVS. If you still think CVS is just fine, then there's little reason to even look at BK. On a more minor note, please read BK's license. While it is not Open Source, you do get access to the source, you are able to fix bugs and redistribute patches, there are no license fees (as long as you're willing to publish your changelogs), and everything reverts to GPL if BitMover Inc or Larry fails to maintain BK etc. Essentially it treads the very narrow line between Open Source and maintaining a business model that is capable of supporting a software company via commercial licensing (companies don't want their changelogs published as that becomes a shopping list for headhunters). -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From jafo@tummy.com Wed Oct 13 23:17:09 1999 From: jafo@tummy.com (Sean Reifschneider) Date: Wed, 13 Oct 1999 16:17:09 -0600 Subject: [Mailman-Developers] Plea for Help In-Reply-To: <14340.59590.668220.421674@anthem.cnri.reston.va.us>; from Barry A. Warsaw on Wed, Oct 13, 1999 at 04:17:10PM -0400 References: <19991013031310.N1005@tummy.com> <199910132009.WAA56410@maestria.wu-wien.ac.at> <14340.59590.668220.421674@anthem.cnri.reston.va.us> Message-ID: <19991013161709.F1005@tummy.com> On Wed, Oct 13, 1999 at 04:17:10PM -0400, Barry A. Warsaw wrote: >Not sure about the branches bit. We had a horrible experience >recently trying to use CVS branches on the Python tree. Okay, maybe >it's just me, but I would be very hesitant about using branches >again. I do not fully understand how branches work. While the core development team doesn't have a lot of time, that precious spare time may be better used to grok branches than to grok BitKeeper. Sean -- Reading computer manuals without the hardware is as frustrating as reading sex manuals without the software. -- Arthur C. Clarke Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD/BSDOS scanning software. From claw@varesearch.com Wed Oct 13 23:21:41 1999 From: claw@varesearch.com (J C Lawrence) Date: Wed, 13 Oct 1999 15:21:41 -0700 Subject: [Mailman-Developers] Plea for Help In-Reply-To: Message from "Barry A. Warsaw" of "Wed, 13 Oct 1999 16:17:10 EDT." <14340.59590.668220.421674@anthem.cnri.reston.va.us> Message-ID: On Wed, 13 Oct 1999 16:17:10 -0400 (EDT) Barry A Warsaw wrote: >>>>>> "GG" == Gerhard Gonter >>>>>> writes: GG> Summary: keep CVS, add CVS web and use branches > Not sure about the branches bit. We had a horrible experience > recently trying to use CVS branches on the Python tree. Okay, > maybe it's just me, but I would be very hesitant about using > branches again. Branches under CVS are the next thing to evil and early hair loss. CVS doesn't even attempt to handle renames or deletes in any way that pretends to be sensical. Reproducability under CVS is non-existent. Three-way merges are a nightmare. Change tracking is a royal pain (cf CVSBLAME). Even Aegis is a better choice than CVS, and that's not saying a whole lot for Aegis. -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From claw@varesearch.com Wed Oct 13 23:26:30 1999 From: claw@varesearch.com (J C Lawrence) Date: Wed, 13 Oct 1999 15:26:30 -0700 Subject: [Mailman-Developers] Plea for Help In-Reply-To: Message from Sean Reifschneider of "Wed, 13 Oct 1999 16:17:09 MDT." <19991013161709.F1005@tummy.com> Message-ID: On Wed, 13 Oct 1999 16:17:09 -0600 Sean Reifschneider wrote: > I do not fully understand how branches work. While the core > development team doesn't have a lot of time, that precious spare > time may be better used to grok branches than to grok BitKeeper. I have just over a dozen people using BK. The average learning time for them to get up to basic usability was under two hours, total. Admittedly many of these people are professional software engineers with history with Perforce, Clearcase, ptools, fcs/kcs, etc. More amusingly that history was more of a problem in their learning than an assist. BK is simple. Very simple. If you know RCS or SCCS, you can use BK right now. If you know CVS the learning curve is on the order of 20 minutes. -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From bwarsaw@python.org Wed Oct 13 23:36:44 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Wed, 13 Oct 1999 18:36:44 -0400 (EDT) Subject: [Mailman-Developers] Plea for Help References: <19991013031310.N1005@tummy.com> <199910132009.WAA56410@maestria.wu-wien.ac.at> <4.2.0.58.19991013175544.04ba5800@vtserf.cc.vt.edu> Message-ID: <14341.2428.386586.869623@anthem.cnri.reston.va.us> >>>>> "RJ" == Ron Jarrell writes: RJ> Works pretty well for BSD and INN... Just takes some practice. RJ> I'd ask one of the folks that set it up for them for RJ> advice... I had two really killer problems with CVS branches. First, I often had trouble getting new files checked into the branch. Second, when I went to merge the branch into the mainline, it pulled in gobs of old files that had long been Attic'd. -Barry From bwarsaw@python.org Wed Oct 13 23:40:53 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Wed, 13 Oct 1999 18:40:53 -0400 (EDT) Subject: [Mailman-Developers] Plea for Help References: <14339.21149.443863.835164@anthem.cnri.reston.va.us> Message-ID: <14341.2677.760419.782383@anthem.cnri.reston.va.us> Thanks for the info JC. The BK web pages seem pretty out of date though, and I didn't see anything about downloads. Interestingly enough I also didn't see any links to the supposedly public free software change logs :) Everything else sounds interesting. I'd like to come up with a solution that would eventually translate to all the projects we've got here (JPython and Python) so I want to investigate Aegis, and get Guido's feedback on things as well. I appreciate all the feedback, information and experience you guys share. -Barry From bwarsaw@python.org Wed Oct 13 23:45:50 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Wed, 13 Oct 1999 18:45:50 -0400 (EDT) Subject: [Mailman-Developers] Plea for Help References: <19991013031310.N1005@tummy.com> <199910132009.WAA56410@maestria.wu-wien.ac.at> <14340.59590.668220.421674@anthem.cnri.reston.va.us> <19991013161709.F1005@tummy.com> Message-ID: <14341.2974.845317.266445@anthem.cnri.reston.va.us> >>>>> "SR" == Sean Reifschneider writes: SR> I do not fully understand how branches work. While the core SR> development team doesn't have a lot of time, that precious SR> spare time may be better used to grok branches than to grok SR> BitKeeper. I'm fairly sure I understand how they're /supposed/ to work, I just think they're broken in some serious ways, at least with CVS 1.10.x BTW, anybody have real-world experience with Aegis? It's GPL'd but I've never heard of it before... http://www.canb.auug.org.au/~millerp/aegis/aegis.html Sure does have one mondo reference manual :) -Barry From ricardo@miss-janet.com Wed Oct 13 23:49:42 1999 From: ricardo@miss-janet.com (Ricardo - Miss Janet . Fanclub) Date: Thu, 14 Oct 1999 00:49:42 +0200 Subject: [Mailman-Developers] Re: [Mailman-Users] Usability patch: (D In-Reply-To: ; from Harald Meland on Thu, Oct 14, 1999 at 12:08:47AM +0200 References: Message-ID: <19991014004942.B1362@rix> Hi, On Thu, Oct 14, 1999 at 12:08:47AM +0200, Harald Meland wrote: > > On 18-Aug-99 Bernhard Reiter wrote: > > > I can understand that the developers are busy. > > same here... but i've never had any reactions to the suggestions i posted in > > here so i kind of got the feeling that nobody took me seriously... > It doesn't appear that anyone has answered this (posted nearly two > months ago), although it indeed does deserve comment. > For me, the last few months have been a bad case of Too Busy Doing > Real Work -- I'm sorry if anyone have gotten the impression that we > (the core developers/Mailman cabal[1]) aren't taking suggestions > seriously. thanks for reacting though... better late than never :) i've ended up hacking my wishes into the source myself -- most of which are in the posting moderate options (admindb.py) since we use that feature intensively... this will mean i'm probably going to have some sleepless nights when a new mailman version is being released and i will have to put back all the things i've added :) I do wish had some more free time on my hands so i could (a) learn myself some more python and (b) be an active developer for mailman... Ricardo. -- From claw@varesearch.com Thu Oct 14 01:37:15 1999 From: claw@varesearch.com (J C Lawrence) Date: Wed, 13 Oct 1999 17:37:15 -0700 Subject: [Mailman-Developers] (no subject) Message-ID: I forwarded some of the BK traffic to Larry. A reply: ------- Forwarded Message Date: Wed, 13 Oct 1999 15:46:14 -0700 From: Larry McVoy To: J C Lawrence Subject: Re: [Mailman-Developers] Plea for Help Check out the screen shots on bitkeeper.com - we've added GUI helptool and GUI csettool. The latter is cool beyond description. You give it one more cset revs as an arg and it walks you through them. You get to see . the list of files / revs in each cset . the cset comments and the file comments together . side by side diffs of the old/new versions of the file and you can move through the whole thing with the space bar - it will page the diffs, when you hit the end of the diffs, it goes to the next file which updates the comments window, and you repeat. Coolness? - -- - --- Larry McVoy lm@bitmover.com http://www.bitmover.com/lm ------- End of Forwarded Message -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From claw@varesearch.com Thu Oct 14 01:38:30 1999 From: claw@varesearch.com (J C Lawrence) Date: Wed, 13 Oct 1999 17:38:30 -0700 Subject: [Mailman-Developers] Plea for Help In-Reply-To: Message from "Barry A. Warsaw" of "Wed, 13 Oct 1999 18:45:50 EDT." <14341.2974.845317.266445@anthem.cnri.reston.va.us> Message-ID: On Wed, 13 Oct 1999 18:45:50 -0400 (EDT) Barry A Warsaw wrote: > BTW, anybody have real-world experience with Aegis? It's GPL'd > but I've never heard of it before... There's been some brief discussion on Linux-Kernel (searchable archives at http://www.mail-archive.com/), but not a whole lot. I've never seen a real installation or user report from other than the authors. -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From lm@bitmover.com Thu Oct 14 02:17:54 1999 From: lm@bitmover.com (Larry McVoy) Date: Wed, 13 Oct 1999 18:17:54 -0700 Subject: [Mailman-Developers] [lm@bitmover.com: Re: FW: Staging System - Requirements Meeting Recap] Message-ID: <19991013181754.15843@work.bitmover.com> hey there, two things: (a) is mailman better than majordomo? I assume it must be right, or you wouldn't be putting all this effort into it. I'm using majordomo now and I keep meaning to look for something that has better spam filters. Forgive the stupid questions, but should I switch? (b) JC has told me that you are considering maybe using BitKeeper for mailman development. I had a call from a large company today and they sent in their requirements and I spent a bunch of time answering them. It might be worth it for you to skim through the questions and answers, I suspect there is some overlap. I'd love it if it turned out that BK was useful to you (and I'd be equally bummed to find out it didn't work for you; if that's the case I want to know why: if there are technical reasons for you not using it, those will almost certainly be fixed, you guys have similar issues to everyone else so that means if it doesn't work for you, it doesn't work for very many other people). Finally, if you have questions, you can mail to me and/or dev@bitmover.com . The dev alias is all the people hacking on BK right now. Cheers, --lm -----Forwarded message----- Hi folks, here are BitMover's responses to your requirements. We think BitKeeper might be a good fit for you, let us know what you think. > Open Discussion - Requirements > a.. Direct FTP access We provide SSH (secure remote shell), RSH (BSD remote shell), and SMTP (email) as transports for moving stuff around. We could do a FTP transport but it seems questionable given that ssh is faster and more secure. If the issue is Windows, no problem, we support ssh on Windows. Use it all the time, in fact, between Windows and Unix. Oh, I forgot, we also work in local and networked file systems (NFS, SMB) and do resyncs between Unix and Windows using SMB. > b.. Graphical view of the file tree -or- dynamic tree structure We actually don't have this right now. But see the checkin response. We have it on Windows because we integrate with their GUI glop, but that's not much help. If we get far enough along and this is a go/no go thing for you, and you're buying 10,000 seats (:-) then we'll write one. Seriously, it's on the list. > c.. Check-in and check-out facilities Got 'em. Both command line and graphical. The command line stuff is like so bk new file - check a file into the system for the first time - aliases: bk delta -i, bk ci -i, bk admin -i bk edit file - check out a file locked for modification - aliases bk co -l, bk get -e bk ci file - check in modifications to a file - aliases: bk delta You can do all of the above on the entire tree, a sub tree, an explict list: bk -r new - checks in everything it finds bk -r edit - locks everything bk -r ci -yComment - checks in everything But the best tool is citool, which finds everything you've modified, lists in a graphical tool, and shows you the diffs as you're doing the check in. See http://www.bitkeeper.com/citool.html > d.. Open ended client support allowing developers to use any editing > tool - FTP to local machine with check-out - edit with whatever tool you > wish - FTP upload to server with check-in That's exactly the right answer. Use any editor you want. What you get with BK is the revision history files locally. If you've worked with RCS or SCCS, in many respects, BK is like that with all the added stuff you need to have multiple copies of the revision history. So every playpen is a repository, you can lock, edit, checkin, browse, etc., everything locally. No need for network connectivity except when you want to update your tree or the other tree. Oh, and you can update "sideways". One developer can slurp in the changes in a another developer's tree directly, without going through the "master" or "shared" tree. In CVS terms, I don't have to go back to the master repository, I can talk directly to you. The hierarchical nature of the system is strictly a convention thing, you can resync from anywhere to anywhere. > e.. Ability to cluster files into "Change Sets" for version control and > configuration management Chuckle. We have that in spades. We don't let you move data between playpens unless you've put it in a changeset (yeah, you could get the diffs and apply them with patch, we can't stop you, but if you want the system to do it, you have to "commit" whatever you have done to a changeset). The normal way you do this is when you pop into citool, there will be N+1 entries, where N are the files with mods, and the Nth+1 entry is the ChangeSet file. If you comment the ChangeSet file, you are creating a ChangeSet. The "diffs" shown for the ChangeSet file are the comments you have just typed in on all the other files like so src/foo.c Fix a bug in arg processing src/foo.h Include getopt.h with the idea being that the ChangeSet comments should be the idea or concept you just did, while the per file comments are implementation details. > f.. Allow user selectable update reports on one or more branches of the > development system I think this is what we call a LOD, but I need clarification. What exactly do you want? > g.. Ability for CGI to be accessible and scriptable from a remote shell - > should support Mac/PC/Linux/Unix/etc. Is this a source management system issue? I don't understand. And one huge bummer - we don't support the Mac; the system depends pretty heavily on various Unix tools (sed, sh, tr, diff, etc), which we provide for Windows but haven't worked up the ompf to do on the Mac. If the Mac is a requirement, we can support MacOS X no problem, that's Unix, but MacOS 8 is a real drag. Let me know, that might be a show stopper. There are ways we can work around this, using appletalk - you could do the source management crud on Linux and the editing on a Mac. Definitely a hack but I can relate to the requirement - the Mac has a bunch of useful tools for Web folks. Long term we will do a port. But that isn't likely to happen in the next few months. > h.. Change Logs You get these for free, it's the ChangeSet comment history. > i.. Concurrent Development of files - requires intelligent merging agent > for coordinating updates from multiple developers (CVS does this now) We do this better than anyone. Period. Everyone else screws up your history. Here's how: you have two developers A and B. They both do CVS update and have the same tree. They both modify file foo.c. A checks in first, so B "lost the race" and has to merge. What CVS will check in is not B's changes, it's B's changes plus whatever B had to do to merge. That is **two events** collapsed into one. Why is this a big deal? Undo. Suppose B's stuff was good and A's stuff wasn't. We can reconstruct B's stuff without the merge. CVS can't. It lost the information. Look at http://www.bitkeeper.com/sccstool.html - what you are seeing is the race and the merge. I'm "lm" and "awc" is my Windows guy. We were working parallel and the graph that you are seeing is the revision history after we merged. 1.89 is the merge delta, 1.86.1.1 and 1.86.1.2 are my deltas. If I want to reconstruct just my work, I do an undo and tell it which branch I want gone. And we do all this automagically. That tree of changes is a straight line, no branches tree as far as the user is concerned. The branches are created automatically when changes are merged in, you never have to do that. > j.. Access Control for each user of the development environment: Per user > basis and Per file basis We don't do this because this is an operating system issue. How you achieve the same effect is to restrict access using standard Unix file permissions on the master repository. > k.. Provide secure remote access to environment either through secure CRT, > SSL, domain restrictions, etc. SSH. > l.. Ability to differentiate gear, products and templates for exclusive > use (for one private label) and public use (all private labels) I don't understand this requirement. > Roles and Responsibilities > Engineering > a.. Priviledged access (on a user by user basis) to everything on the site > (cgi, kernels, html, graphics, etc.) This done through the OS. If you have an account and you can read and write the files, then you can read and write the files. > b.. Utilize a versioning source control system (SCS) for updates We provide something which is file format compatible with SCCS, AT&T's original revision control system from the 70's. A lot of people question this, there are claims that the SCCS file format is worse than RCS. That's not true, in fact, the opposite is true. RCS has one potential advantage that they don't even use: they store the most recent delta as a clear file and all the previous ones as diffs (backward diffs for going up the trunk and forward diffs for going down the branches). If RCS stored an offset and a size in the file, then they could seek to to the clear text and write the file out in one system call. They don't do that so they end up reading the whole file anyway (or most of it, it depends). Whatever. Someone could modify RCS to do what I said and it would still suck. Here's why: . No checksum. SCCS checksums the file and verifies the checksum every time you get the file. BK adds an additional per delta checksum. The point is that you put your IP into a system; that system should guard that IP very carefully. RCS makes a performance vs integrity tradeoff which will end up screwin you in the long run. . Annotation. SCCS can trivially give you a copy of the file with each line prefixed by any combination of the revision/user/date which added that line. In addition, BK can check out a copy of the file with every line in every revision in the file. Think about that. You know that somebody changed something and you know the string they changed but you don't know when. In BK you can find out by doing this bk sccscat -mu foo.c | grep string . ChangeSets. SCCS is a changeset engine, people just don't know it. What that means is that I can edit a file on one branch and say "I also want that delta over there which is on a different branch". SCCS will happily include it. You can creat new deltas and include/exclude any arbitrary list of deltas. It may not be obvious, but this is really cool and has far reaching ramifications. Not only can RCS not do this, if you tried to kludge it in, it would grow the file linearly for each include. In SCCS, including or excluding a delta costs you about 4 bytes per included delta. In other words, you can construct multiple different views of your data and it doesn't cost you. Ping me in the conference call about this if I did a poor job explaining it, it is profoundly important. It's what makes SCCS a ChangeSet engine and what makes RCS not a ChangeSet engine. > c.. Each engineer works in an independant workspace (currently known as > playpens) Yup. Each engineer can have as many playpens as s/he wants. Each are fully independent and get this: NO NO NO environment variables. You work in a playpen by saying cd ~/playpen/src bk vi foo.c If you want to work in a different playpen, you just say cd ~/different_playpen/src bk vi bar.c Environment variables suck. Just say no. Dare to break the environment variable habit :-) > d.. Depending on the engineer's privileges - able to push edits to staging > server at the branch or global levels If they have a login and write permissions on the staging area, they can. I really felt no need to reinvent Unix file permissions. Yeah, this screws the NT people but they can emulate the same thing by limiting access to the machine which has the staging area. > Web Development > a.. Priviledged access (on a user by user basis) to limited content on the > site (html, graphics, etc.) > b.. Utilize a versioning source control system (SCS) for updates > c.. Each developer works in an independant workspace (currently known as > playpens) > d.. Depending on the developers privileges - able to push edits to staging > server at the branch or global levels Same as above. > Quality Assurance > a.. Utilizes a selective build configuration management system (CMS) that > allows Q/A to selectivey test and build portions of the site We're weak here in some regards. We don't support partial repositories. In other words, when you do a resync, you get the whole tree. To deal with this, you will naturally split your project up into chunks. Each of these chunks is a repository. So far so good, but the one bummer is when you want to share data between two repositories. We currently don't have any way for data to be in two different "chunks" (we call 'em projects) at the same time. This needs more explanation so please ping me during the conference call. > b.. Ability to rollback change sets and individual files Chuckle. You bet. The easiest (but somewhat slow) way to roll back is like so: suppose you want to roll back to ChangeSet 1.123 (which was conviently tagged with alpha2). $ bk resync -r..alpha2 master alhpa2-test That will create a repository which is identical to the master repository when alpha2 went in (by the way, the tag is just for clarity, anywhere you use a tag you can use a revision). The other way is suppose you had a tree with ... alpha2 - 1.124 - 1.125 and you wanted alpha2. You can dothis $ bk undo 1.124,1.125 and that will DESTROY those two changesets. You'd better have a copy of them somewhere if you want 'em back). > c.. Tie in builds with bug tracking system to complete a closed loop > tracking process Busted. We want to do this but this is a 2.0 or perhaps 3.0 before we have it. We have a plan for doing it but right now we don't have diddly. > d.. Test and submit builds for Go Live! ??? > Release Management > a.. Schedules and approves builds for go live > b.. Coordinates builds with Q/A for testing Seems OK. > Private Label Partners > a.. Restricted access to their branch > b.. Access control based on a case by case basis I don't know what these are. --------------------------------------------- One thing you forgot to ask about is file renames. This is another place where people fall down. We don't (surprise!). We handle file pathname changes identically to file content changes. Pathnames are revisioned and propogate. Consider a couple of test cases: You Me Resync you to me mv foo bar nothing moves foo to bar in my tree change foo mv foo bar applies change in foo to bar in my tree mv foo bar mv foo blech prompts you with name conflict This is not a big deal until you need it to work but then it is a huge deal. It can bring your develpment to a halt for days while your engineers unscramble the mess. We just make that problem go away. You also forgot file permissions. We pick up the permissions as of the time that the file was originally checked in "bk new". After that, if you want to change them, you just say "bk chmod 755 foo.sh" and it saves the modes. On windows, only the top bits (owner permissions) are used, but it doesn't stomp on the lower bits. > Possible Vendors > a.. Continuus - Continuus http://www.continuus.com/ > b.. Interwoven - Teamsite http://www.interwoven.com/ > c.. Clear Case - Need Vendor Name Rational Software, http://www.rational.com > d.. Bit Keeper - Need Vendor Name BitMover, Inc. And it is "BitKeeper" if you want to be picky. http://www.bitkeeper.com Also consider the following: CVS (it's free and I can show you what you could do to sort of have some of these features, not all, but some). Perforce, http://www.perforce.com - I know Chris, great guy, nice little tool. It doesn't do what you want but it is quite popular and you should know it exists. TrueChange from TrueSoft, http://www.truesoft.com - this is the only commercially available ChangeSet engine other than BitKeeper. Cheers, Larry McVoy President, BitMover, Inc. -----End of forwarded message----- -- --- Larry McVoy lm@bitmover.com http://www.bitmover.com/lm From claw@varesearch.com Thu Oct 14 02:40:15 1999 From: claw@varesearch.com (J C Lawrence) Date: Wed, 13 Oct 1999 18:40:15 -0700 Subject: [Mailman-Developers] Plea for Help In-Reply-To: Message from "Barry A. Warsaw" of "Wed, 13 Oct 1999 18:40:53 EDT." <14341.2677.760419.782383@anthem.cnri.reston.va.us> Message-ID: On Wed, 13 Oct 1999 18:40:53 -0400 (EDT) Barry A Warsaw wrote: > Thanks for the info JC. The BK web pages seem pretty out of date > though, and I didn't see anything about downloads. Interestingly > enough I also didn't see any links to the supposedly public free > software change logs :) BK is not released *yet*. Access is currently restricted to people who sign the beta agreement etc. BK should be released fairly soon tho (Larry: What's the current predict?) > Everything else sounds interesting. I'd like to come up with a > solution that would eventually translate to all the projects we've > got here (JPython and Python) so I want to investigate Aegis, and > get Guido's feedback on things as well. Please note that I'm explicitly biased here. I've used and don't like CVS. I'm aware of Aegis only intellectually. Aegis follows a somewhat similar design model to BK, but with a much more overweaning and dictatorial (you will do things our way or you will not do anything so NYAH!) implementation. Compared to the various SCM tools I've used at HP, IBM, SGI, etc I'm damn near in love with BK, so no brownie points for guessing which I'd recommend. > I appreciate all the feedback, information and experience you guys > share. Absolutely. Some of the things I particularly like about BK: -- Cross platform. It is identical under Linux, Solaris, IRIX, Windows NT, etc. -- Resolves 95% of the three way merge problem. -- The GUI tools for merges (when they do happen) does almost exactly what you want a three-way merge tool to do. Some comments I wrote offlist comparing CVS and BK: -- BK removes 95% of the merge problem. That's enough alone to sell it to me. BK's merge tools are not perfect, but they're a sight better than anything else I've seen. -- BK gives you real audit trails for changes. CVS doesn't. No more CVSBLAME. -- BK handles file deletes and renames. CVS doesn't. -- BK allows you to stage work and to distribute only known-working source sets. CVS doesn't. -- Nothing in BK runs as root. CVS' pserver must run as root to allow UID changes, and pserver was not built with security in mind. -- BK can be run over SSH. CVS can run pserver connections over an SSH port forward, but its a pain (I've done it). CVS over SSH performance also sucks. BK over SSH is quite nippy. -- BK can use email, even PGP'ed email, as it transport. CVS can't. -- BK handles binary files transparently. CVS doesn't even pretend to. While BK's handling is not great (it checks in the UUencoded copy), it does work. -- Nothing happens to a BK repository that you don't explicitly Okay, and EVERYTHING can be rolled back to its prior state. Got a bum changeset in? No problem: Just back it out. There are few controls on what happens to a CVS repository other than user/passwd authentication, and absolutely no rollback capabilities. -- One of Larry's big items: BK is very very bandwidth light. You can easily (and often quickly) sync two massive repositories over a slow link. Basically under BK only the absolutely needed changes are sent, nothing else. CVS is not so generous. -- BK imposes no user heirachy. All BK work areas are first class repositories. Resync your work area from a repository and the result is bit identical to the other repository and anybody else can resync from you. CVS imposes a single central server/many-clients model. BK allows any sort of tree, or even mesh, to be used. -- BK handles branches fairly well, sorta. I'm still waiting for Larry's promised LinesOfDevelopment code so I can get a handle on what he's trying to do there. If it is what I understand it will be clean and fairly neat. CVS OTOH is just painful once you have anything more than a single branch. -- BK makes it very easy to seperate your work on a source tree into waht I call "projects" (eg a fix for bug X, new feature Y, etc), each distinct from the others and then lets you track and propagate them individually. While similar is possible under CVS, it is nowhere near as easy and the individual propagation just ain't there. -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From lm@bitmover.com Thu Oct 14 03:15:12 1999 From: lm@bitmover.com (Larry McVoy) Date: Wed, 13 Oct 1999 19:15:12 -0700 Subject: [Mailman-Developers] Plea for Help In-Reply-To: ; from J C Lawrence on Wed, Oct 13, 1999 at 06:40:15PM -0700 References: Message-ID: <19991013191512.43950@work.bitmover.com> On Wed, Oct 13, 1999 at 06:40:15PM -0700, J C Lawrence wrote: > On Wed, 13 Oct 1999 18:40:53 -0400 (EDT) > Barry A Warsaw wrote: > > > Thanks for the info JC. The BK web pages seem pretty out of date > > though, and I didn't see anything about downloads. Interestingly > > enough I also didn't see any links to the supposedly public free > > software change logs :) > > BK is not released *yet*. Access is currently restricted to people > who sign the beta agreement etc. BK should be released fairly soon > tho (Larry: What's the current predict?) We are trying to do one last beta starting around this Friday and ship 1.0 on or close to Nov 1. LODs will not be complete but it is way past the point that it is useful enough it is more a less a crime to keep it hidden. Just my opinion :-) More seriously, Zack Weinberg, one of people who work here on BK, has been pointing out that we should have shipped a month ago, around the time that VA started saying "No more betas, this works". The reason being that while we are busy polishing, there are some bugs that just aren't going to be exposed until we let it go out to the masses. I'm starting to agree. > > Everything else sounds interesting. I'd like to come up with a > > solution that would eventually translate to all the projects we've > > got here (JPython and Python) so I want to investigate Aegis, and > > get Guido's feedback on things as well. > > Please note that I'm explicitly biased here. I've used and don't > like CVS. I'm aware of Aegis only intellectually. Aegis follows a > somewhat similar design model to BK, but with a much more > overweaning and dictatorial (you will do things our way or you will > not do anything so NYAH!) implementation. Compared to the various > SCM tools I've used at HP, IBM, SGI, etc I'm damn near in love with > BK, so no brownie points for guessing which I'd recommend. Aegis has a bunch of problems, which you'll run into when you try it. No NT support and as much as I despise NT, it is as much of a player as Solaris, for example. A bunch of other issues, most of which stem from one problem: Aegis is a layer on top of the revision system, it can sit on SCCS or RCS or whatever. That means that it can only do as well as the greatest common denominator of all of those systems. Which isn't a good place. We rewrote all of SCCS from scratch and our implementation is substantially better than RCS or the other SCCS implementations out there. And we use all of the power of SCCS. SCCS has a bad name, Tichy did a great job badmouthing it when he did RCS, but the fact is that SCCS is a far better file format that RCS. It did have some problems, such as no tag support, no permissions support, no pathname support, etc., but we fixed all of those (in a way which is backwards compat - if you are a Sun machine, you can use Sun's SCCS to read/write our files). There are some non-obvious things that SCCS can do that we are planning to use extensively in BK for LOD support. This is probably the feature you will want the most over the long run. Imagine multiple branches, like the dev, stable, released branches. Imagine being able to be in a visual tool like http://www.bitkeeper.com/sccstool.html , and being able to see all the changesets (a changeset is a lot like what you might think of as a patch, just more formal). Now imagine saying "start up and show me the stable branch but hide the release branch, and hide everything that is in the dev branch that I haven't explicitly included or excluded into the stable branch". The world just became a less cluttered space. Now imagine being able to browse each changeset with http://www.bitkeeper.com/csettool.html and deciding which ones you want and which ones you don't. You can drag and drop the ones you want onto the stable branch and they show up there. And the next time you run this setup, those changes are now hidden in the dev branch. Does that make any sense? It's sort of graphical branch management which can be arbitrarily complex, with an arbitrary number of branches. (well almost arbitrary, we currently limit you to 65535 branches :-) The disk space required for all of those branches is proportional to the patch size. Another way to say this: suppose you had 10 branches and you had a 1GB change which lived in the outer most branch, then got included into each inner branch, one at a time. In RCS, you'd have a 10GB file. In BK, you have a 1GB file plus about 2K of meta data. it's cool stuff like that that we can do because we took the time to write a good revision engine. We looked hard at RCS and came to the conclusion that it was just profoundly broken for the things that we wanted to do and we couldn't fix it. > Absolutely. Some of the things I particularly like about BK: > > -- Cross platform. It is identical under Linux, Solaris, IRIX, > Windows NT, etc. Including ssh support - we got ssh server/client to work on NT. That was the last remaining issue. Other than stuff like group/world permissions and symlinks (which we support, you can have a file that was at different times in its life a symlink, a regular file, a revision controlled MDBM file), the NT world is identical to the Unix world. Whoops - not true, we also support integration with the Visual studio GUI so the NT version actually has that over the Unix stuff. > -- Resolves 95% of the three way merge problem. Man you ain't seen nothing yet. We figured out how to handle the two branch, merge only one way (old -> new, but not the other way), and not have the 3 way diff go to the ever more distance GCA. We can treat the last merge point as a legitimate GCA. And we save enough information that we can find this closer GCA. I went through and tried it both ways on all the merges in the BK source tree itself. On average 9/10 of merge conflicts went away. This is amazingly cool, you have to see it to believe it. > Some comments I wrote offlist comparing CVS and BK: > > -- BK removes 95% of the merge problem. That's enough alone to > sell it to me. BK's merge tools are not perfect, but they're a > sight better than anything else I've seen. You only have the two merge stuff. We have a somewhat broken threeway merge tool that you'll get in the next beta. > -- BK can be run over SSH. CVS can run pserver connections over > an SSH port forward, but its a pain (I've done it). CVS over SSH > performance also sucks. BK over SSH is quite nippy. Yeah it is. I'm supportng the Linux/PPC folks and I have to resync to a machine in bum-f*ck New Mexico that has the lossiest T1 line I've ever had the misfortune to encounter. BK rocks for that. It transfers close to the minimum that must be transfered. I'm realy tickled with this, it is completely reasonable to have remote modem access to huge projects. It works. It never plows through the remote tree to do a resync because we only resync changesets so all we have to look at is the ChangeSet log to see what needs to come across the wire. And we are currently lazy about that and transfer more data than we really need to. But since that over head is in the Kbyte area, we haven't gotten too excited about fixing it. We know how and will some day. > -- BK handles binary files transparently. CVS doesn't even > pretend to. While BK's handling is not great (it checks in the > UUencoded copy), it does work. Yeah, this sucks, in my opinion, in spite of your nice words. I could at the very least gzip and uuencode it (that is a supported mode, it just isn't the default). But the real answer is to have binary specific "plugins" which know how to break apart binaries so you can get meaningful diffs. Binaries are a pain and our support of them, while not horrible, is not anywhere near acceptable in my opinion. Anther long term thing to fix. > -- BK handles branches fairly well, sorta. I'm still waiting for > Larry's promised LinesOfDevelopment code so I can get a handle on > what he's trying to do there. If it is what I understand it will be > clean and fairly neat. CVS OTOH is just painful once you have > anything more than a single branch. The current branch support in BK sucks dog doo. It's non-existant, just basic branches with no way to manage them. That's not branch support. The LOD stuff will make your heart go flip-flop though. yeah, it's all vaporware as far as you are concerned (the first implementation just went into our dev tree), but I swear to you that this will rock your world. I have to get this to work right or Linus won't even consider using BK and I want it for my own tree. It's #! feature on the priority list. Anyway, that's a lot of salesman blather. Let me know if you have specific questions. I'll go check out mailman in the mean time. -- --- Larry McVoy lm@bitmover.com http://www.bitmover.com/lm From bwarsaw@python.org Thu Oct 14 04:26:53 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Wed, 13 Oct 1999 23:26:53 -0400 (EDT) Subject: [Mailman-Developers] Plea for Help References: <14341.2974.845317.266445@anthem.cnri.reston.va.us> Message-ID: <14341.19837.727117.80517@anthem.cnri.reston.va.us> >>>>> "JCL" == J C Lawrence writes: JCL> There's been some brief discussion on Linux-Kernel JCL> (searchable archives at http://www.mail-archive.com/), but JCL> not a whole lot. I've never seen a real installation or user JCL> report from other than the authors. And yet it appears to have been out since 1991. Interesting. From claw@varesearch.com Thu Oct 14 19:04:50 1999 From: claw@varesearch.com (J C Lawrence) Date: Thu, 14 Oct 1999 11:04:50 -0700 Subject: [Mailman-Developers] Plea for Help In-Reply-To: Message from "Barry A. Warsaw" of "Wed, 13 Oct 1999 23:26:53 EDT." <14341.19837.727117.80517@anthem.cnri.reston.va.us> Message-ID: On Wed, 13 Oct 1999 23:26:53 -0400 (EDT) Barry A Warsaw wrote: <> >>>>>> "JCL" == J C Lawrence writes: JCL> There's been some brief discussion on Linux-Kernel (searchable JCL> archives at http://www.mail-archive.com/), but not a whole lot. JCL> I've never seen a real installation or user report from other JCL> than the authors. > And yet it appears to have been out since 1991. Interesting. That's, umm, one way to put it. -- J C Lawrence Home: claw@kanga.nu ---------(*) Work: claw@varesearch.com ... Beware of cromagnons wearing chewing gum and palm pilots ... From lindsey@ncsa.uiuc.edu Thu Oct 14 20:42:54 1999 From: lindsey@ncsa.uiuc.edu (Christopher Lindsey) Date: Thu, 14 Oct 1999 14:42:54 -0500 (CDT) Subject: [Mailman-Developers] mailman vs majordomo In-Reply-To: <19991013181754.15843@work.bitmover.com> from "Larry McVoy" at Oct 13, 99 06:17:54 pm Message-ID: <199910141942.OAA13634@ferret.ncsa.uiuc.edu> > two things: (a) is mailman better than majordomo? I assume it must > be right, or you wouldn't be putting all this effort into it. I'm using > majordomo now and I keep meaning to look for something that has better spam > filters. Forgive the stupid questions, but should I switch? This is probably better on mailman-users... Anyhow, I think mailman and majordomo each have their own place. Majordomo is much more flexible and, in my opinion, powerful. The basic structure is simplistic, but it's very easy to change things. However, it is also pretty admin-intensive and has a braindead digest scheme. mailman takes administrative tasks away from the admin and puts them in the hands of the listowner. It saves time and is a lot easier to configure. Users also find the Web interface easier than an email one. However, Adding features is a pain in the butt, especially if you're not familiar with Python (i.e. I doubt that I'll ever see support for quoted addresses containing spaces, since Mailman splits on whitespace). So if you want to pass administrative tasks to the listowner and have a pretty Web interface, use mailman. If you need to do heavy-duty funky stuff as an admin, use majordomo. Don't get me wrong though -- I like mailman and find it very useful when I want to offload list responsibility. In fact, we're trying to implement it here at NCSA for a majority of our less complicated lists. Chris From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Oct 14 21:07:18 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 14 Oct 1999 16:07:18 -0400 (EDT) Subject: [Mailman-Developers] [lm@bitmover.com: Re: FW: Staging System - Requirements Meeting Recap] References: <19991013181754.15843@work.bitmover.com> Message-ID: <14342.14326.927619.545115@anthem.cnri.reston.va.us> >>>>> "LM" == Larry McVoy writes: LM> hey there, two things: (a) is mailman better than majordomo? I still firmly believe so. We had never ending problems with Majordomo on python.org, which is why (more than the philosophical discomfort :) we made a strong push to get Mailman in operational shape. I've since been able to completely wax Majordomo from my hard drives :) Yes, Mailman needs work. But there are some really great hackers on mailman-developers and I think we just need to structure the project better so that those folks can contribute more directly, without the frustration when the core 5 of us are busy with Real Work. LM> Oh, and you can update "sideways". One developer can slurp in LM> the changes in a another developer's tree directly, without LM> going through the "master" or "shared" tree. In CVS terms, I LM> don't have to go back to the master repository, I can talk LM> directly to you. The hierarchical nature of the system is LM> strictly a convention thing, you can resync from anywhere to LM> anywhere. This really fires me up. I would love to have Mailman's doco team announce "hey, we've got a new revision, please sync with our repository to check it out". Meanwhile the archivists say "we've got the new search engine ready for those who'd like to take a look". So then at some point I get an email saying that there's been enough testing and people are feeling confident about the changes. Until then, maybe I don't even look at the stuff, and only suck it into the master when there's been enough of that sideways development to make things stable. If I got vision right, that's exactly what I'm looking for LM> with the idea being that the ChangeSet comments should be the LM> idea or concept you just did, while the per file comments are LM> implementation details. Another very cool idea, because this is exactly how I'd like to work. Currently I put both levels of detail into the individual file log msgs, but I'd rather do it this way. Is there an equivalent of citool for Emacs? >> h.. Change Logs LM> You get these for free, it's the ChangeSet comment history. One important thing for GNU projects (although I've been lax about it) is the ability to generate GNU ChangeLogs. Emacs has tools for extracting this info out of RCS/CVS log msgs. It would be nice to have the same capability with BK. If there are aliases for "cvs log" then it might be a no-brainer. LM> We do this better than anyone. Period. Everyone else screws LM> up your history. Here's how: you have two developers A and B. LM> They both do CVS update and have the same tree. They both LM> modify file foo.c. A checks in first, so B "lost the race" LM> and has to merge. What CVS will check in is not B's changes, LM> it's B's changes plus whatever B had to do to merge. That is LM> **two events** collapsed into one. Why is this a big deal? LM> Undo. Suppose B's stuff was good and A's stuff wasn't. We LM> can reconstruct B's stuff without the merge. CVS can't. It LM> lost the information. LM> Look at http://www.bitkeeper.com/sccstool.html - what you are LM> seeing is the race and the merge. I'm "lm" and "awc" is my LM> Windows guy. We were working parallel and the graph that you LM> are seeing is the revision history after we merged. 1.89 is LM> the merge delta, 1.86.1.1 and 1.86.1.2 are my deltas. If I LM> want to reconstruct just my work, I do an undo and tell it LM> which branch I want gone. Um, drool. LM> . ChangeSets. SCCS is a changeset engine, people just don't LM> know it. What that means is that I can edit a file on one LM> branch and say "I also want that delta over there which is on LM> a different branch". Indeed, very cool, IIUC. Another thing that sucks in CVS, but which we need surprisingly often, is the ability to include a file in multiple projects. Example, in the Python project we've got a file called Lib/smtplib.py which Guido will edit and change as bug reports come into via the Python channel. Mailman usually just wants to use the latest smtplib.py file, but it lives under the Mailman project in Mailman/pythonlib/smtplib.py. When I see changes happen to the Python tree, I usually checkout the latest version, and commit it to the Mailman tree. This sucks because I've now lost the revision history to the file under Mailman. I can kludge around this by evil tricks like symlinking or hardlinking the ,v file in the repository. That sucks for any number of reasons (rsync to the anonCVS, what if I want to do this for lots of files all over the place, etc.) Does BK provide any kind of support for this? LM> We're weak here in some regards. We don't support partial LM> repositories. In other words, when you do a resync, you get LM> the whole tree. To deal with this, you will naturally split LM> your project up into chunks. Each of these chunks is a LM> repository. So far so good, but the one bummer is when you LM> want to share data between two repositories. We currently LM> don't have any way for data to be in two different "chunks" LM> (we call 'em projects) at the same time. Ah, so I think my answer to above is "no". Well, I guess I'm no worse off :) LM> and that will DESTROY those two changesets. You'd better have LM> a copy of them somewhere if you want 'em back). Hmm, it might be nice if some day those were re-doable. LM> One thing you forgot to ask about is file renames. Equally important is directory renames. Can't be done in CVS, so what you end up doing is creating the new directory, moving all the ,v files in the repository, then doing an update -d -P. The old dir doesn't go away, it's just pruned out 'cause it's empty. There's gotta be a better way. Thanks for all the info Larry, -Barry From will@connectcorp.net Fri Oct 15 00:33:58 1999 From: will@connectcorp.net (Will Leaver) Date: Thu, 14 Oct 1999 16:33:58 -0700 Subject: [Mailman-Developers] Multiple Deliveries Message-ID: <01fe01bf169c$96887de0$0300a8c0@ceo.connectcorp.net> Howdy to all! We are running four lists with Mailman 1.0, Python ver.1.5.1, Linux Red Hat, 5.?, and Sendmail, 8.9.3 We installed Mailman late in August. We have upgraded the smtplib.py to the current version. We are still sending duplicates of every post, and sometimes up to three or four copies. We have searched the archives, and think we understand the problem, but we are lacking clear direction to resolve it. Can anyone help? Will Leaver Joe Whittaker MASLOM, Inc. From a.eyre@optichrome.com Mon Oct 18 15:22:16 1999 From: a.eyre@optichrome.com (Adrian Eyre) Date: Mon, 18 Oct 1999 15:22:16 +0100 Subject: [Mailman-Developers] CVS Access Message-ID: <002801bf1974$2e139800$3acbd9c2@peridot.optichrome.com> The webpage mentions CVS access to sources, but not a CVSROOT. Does anyone have this string? -------------------------------------------- Adrian Eyre Optichrome Computer Solutions Ltd Maybury Road, Woking, Surrey, GU21 5HX, UK Tel: +44 1483 740 233 Fax: +44 1483 760 644 http://www.optichrome.com -------------------------------------------- From adrian.joseph@guardian.co.uk Fri Oct 22 11:55:30 1999 From: adrian.joseph@guardian.co.uk (Adrian Joseph) Date: Fri, 22 Oct 1999 11:55:30 +0100 Subject: [Mailman-Developers] Re: bug report id 146 Message-ID: <00fc01bf1c7b$f5040620$09d5060a@3100.guardian.co.uk> The problem proved to be with a particular message which could not be approved,rejected or discarded. I looked at the message and the sender seemed to be a little odd. So, I made the change below to ListAdmin.py and it seemed to work okay, I don't know if this might cause other problems. Adrian 160c160 < 'sender' : msg.GetSender(), --- > 'sender' : strquote(msg.GetSender()), From jerrya@fastrans.net Fri Oct 22 12:58:40 1999 From: jerrya@fastrans.net (Jerry Adlersfluegel) Date: Fri, 22 Oct 1999 06:58:40 -0500 (CDT) Subject: [Mailman-Developers] unable to edit my archive page Message-ID: I am trying to edit my Archives Index Page with the web interface, and my changes aren't showing up. The archive is private, and works just fine. I just finished configuring ht://dig to index the private archive and now I want to put the search doodads on the archive page. Changes I make on the web form show up in ~/lists/listname/archives.html but never make it to ~/archives/private/listname/index.html, even after someone sends mail to the list. The index.html file is overwritten everytime a message is posted, which blows away anything I tried to add there. Just to see if the web-based editor worked, I was able to successfully edit the General list information page. I would appreciate any help in modifying this file. (Mailman 1.0 on a RedHat 6.0 system.) Thanks! -- Jerry Adlersfluegel From Thomas.Esamie@uts.EDU.AU Wed Oct 27 04:52:07 1999 From: Thomas.Esamie@uts.EDU.AU (Thomas Esamie) Date: Wed, 27 Oct 1999 13:52:07 +1000 Subject: [Mailman-Developers] Mailman installation problems Message-ID: Hi, I'm attempting to install mailman 1.0 on a Mac OS X server and managed to install Python (1.5.2) without too many problems and I ran the ./configure script. When I get to the the "make install" stage for mailman it starts chugging along merrily until we get to the following sequence >for f in answer_majordomo_mail mailcmd mailowner post driver; \ >do \ > /usr/bin/install -c -m 644 $f /Local/Applications/mailman/scripts; \ >done >cc -c -I. -DPREFIX="\"/Local/Applications/mailman\"" -DPYTHON="\"/usr/local/bin/python\"" -DHELPFUL -g -O2 -DHAVE_STRERROR=1 -DHAVE_SETREGID=1 -DHAVE_SYSLOG=1 -DSTDC_HEADERS=1 -DHAVE_SYSLOG_H=1 -DGETGROUPS_T=gid_t -DHAVE_VSNPRINTF=1 ./common.c >./common.c:26: `PREFIX' undeclared here (not in a function) >./common.c:26: `scripts' undeclared here (not in a function) >./common.c:26: parse error before `;' >make[1]: *** [common.o] Error 1 >make: *** [install] Error 2 Well I had a look at common.c and there are these lines which appear to cause the problem #define SCRIPTDIR PREFIX ## "/scripts/" /* trailing slash */ #define MODULEDIR PREFIX /* no trailing slash */ const char* scriptdir = SCRIPTDIR; [note this line is line 26] PREFIX does not appear to be an environment variable and it is not explicitly set in common.h I know this is kind of scratchy stuff but any clues on what to do from here? Greetings, Thomas PS. I'm no guru so assume complete stupidity on my part in any explanation :-) From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Oct 29 16:12:08 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 29 Oct 1999 11:12:08 -0400 (EDT) Subject: [Mailman-Developers] Speeding up Mailman Message-ID: <14361.47432.588695.159990@anthem.cnri.reston.va.us> Here's a bit of low-hanging fruit that might speed up Mailman. I don't know exactly by how much, but it works by starting Python with the -S option. On my Sparc boxes I've seen 4-8x improvement in the startup times of the Python executable. I've tested the patch in that I'm sure it works, but I haven't put it in the python.org operation system yet. I plan on doing that next. Note that this only works for the CGI and mail wrappers, not the bin scripts, but it should still help out a lot. Let me know if you give this a shot, and whether you see any improvement or not. Thanks to Jeremy Hylton for the inspiration. -Barry -------------------- snip snip -------------------- Index: common.c =================================================================== RCS file: /projects/cvsroot/mailman/src/common.c,v retrieving revision 1.18 retrieving revision 1.19 diff -c -r1.18 -r1.19 *** common.c 1999/07/12 20:32:59 1.18 --- common.c 1999/10/29 15:06:43 1.19 *************** *** 196,212 **** newenv[j] = NULL; /* Now put together argv. This will contain first the absolute path ! * to the python executable, then the absolute path to the script, ! * then any additional args passed in argv above. */ ! newargv = (char**)malloc(sizeof(char*) * (argc + 2)); ! newargv[0] = python; ! newargv[1] = (char*)malloc(sizeof(char) * ( strlen(scriptdir) + strlen(script) + 1)); ! strcpy(newargv[1], scriptdir); ! strcat(newargv[1], script); /* now tack on all the rest of the arguments. we can skip argv's * first two arguments because, for cgi-wrapper there is only argv[0]. --- 196,215 ---- newenv[j] = NULL; /* Now put together argv. This will contain first the absolute path ! * to the Python executable, then the -S option (to speed executable ! * start times), then the absolute path to the script, then any ! * additional args passed in argv above. */ ! newargv = (char**)malloc(sizeof(char*) * (argc + 3)); ! j = 0; ! newargv[j++] = python; ! newargv[j++] = "-S"; ! newargv[j] = (char*)malloc(sizeof(char) * ( strlen(scriptdir) + strlen(script) + 1)); ! strcpy(newargv[j], scriptdir); ! strcat(newargv[j], script); /* now tack on all the rest of the arguments. we can skip argv's * first two arguments because, for cgi-wrapper there is only argv[0]. *************** *** 218,227 **** * * TBD: have to make sure this works with alias-wrapper. */ ! for (i = 2; i < argc; i++) ! newargv[i] = argv[i]; ! newargv[i] = NULL; /* return always means failure */ (void)execve(python, &newargv[0], &newenv[0]); --- 221,230 ---- * * TBD: have to make sure this works with alias-wrapper. */ ! for (i=2, j++; i < argc; i++) ! newargv[j++] = argv[i]; ! newargv[j] = NULL; /* return always means failure */ (void)execve(python, &newargv[0], &newenv[0]);