From stephen at xemacs.org Tue May 1 07:57:08 2007 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 01 May 2007 14:57:08 +0900 Subject: [Mailman-Developers] Templating the interface In-Reply-To: <46351861.4060904@inetspec.com> References: <46351861.4060904@inetspec.com> Message-ID: <87hcqxgk7f.fsf@uwakimon.sk.tsukuba.ac.jp> Jon Reese writes: > My desired hopes would include Mailman 2.1.9 support for Python 2.2.3 > without patches or changes to Python coding (for users of RHEL3 and > CentOS3); This is a cart-horse inversion IMO. Let's get the template system, with whatever Python and email module Barry feels like mandating, and *then* think about backporting to other Python versions. From barry at python.org Tue May 1 15:41:58 2007 From: barry at python.org (Barry Warsaw) Date: Tue, 1 May 2007 09:41:58 -0400 Subject: [Mailman-Developers] Templating the interface In-Reply-To: References: Message-ID: <1F65AD6E-99DD-41F6-81B3-921FE5E9C047@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 27, 2007, at 4:53 PM, Aaron Crosman wrote: > That said, I'm not clear where this project stands. I've been > reviewed > the summary from last summer's SoC work, and while that's given me > some > idea of what was done, I don't have a good sense of how and where > to get > started on helping. Can you all offer some suggestions about what > I can > do to be helpful and contribute? I think the SoC work is interesting from an experimental standpoint, but we're probably going to have to re-do most of that work for inclusion in the trunk. Because Mailman 2.1 is in stable maintenance release, we can't officially include any changes to its templating system. Mailman trunk is where the work should be conducted, and I'm all for getting folks to help out with this effort. There are several problems with MM2.1's web u/i, aside from the obvious creaky decade-old look, and css and xhtml-unfriendly style. The big problem is that there /is/ no one templating system. Some of the web pages are generated from Python code, some are substituted in from the language-specific templates. The problem with the latter is that every natural language has its own copy of the templates, so if you change the English version (say to add a widget), you've now broken all the other languages. What I would really like to see is the adoption of one of the state- of-the-art Python-based templating systems, and converting the entire Mailman web u/i to use this system. It's too early to mandate something, but Genshi seems like the prime candiate. I've personally tried ZPT and had lots of problems when I started to internationalize it. I believe Ethan used Kid in the SoC branch initially and ran into problems there too. He may have moved to Genshi toward the end of the project. I know there are many other templating systems out there, such as PTL (from Quixote) but I don't have much experience with them. I would encourage folks who have experience with templating systems to throw their hats in the ring here, or if you want to help out with this effort, go download some of these systems and try them out, and report back here. We'll use http://wiki.list.org/display/DEV/TemplatingNotes to keep track of this project. I know Andrew Kuchling is quite interested in this project too, especially as it pertains to the archiver, since the next gen archiver will use the same templating system. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRjdDrXEjvBPtnXfVAQI2PQP/bWUry7bGw6ISOwBslxCpUQ8IRNWX6Asw uj8oCGEQatZZuhx9cpS/TEM51qh4Q3vXRw9sL0DBfncS1F7v1nwKX5R51BDC1VoR hLIMh/CImQniSHHjrJ0+eeAMPCQvAc/QcT9THoB1Y+j+jxSiUDYESlIfbUzmY6wN 2Y+2RAZEhfo= =0RIN -----END PGP SIGNATURE----- From barry at python.org Tue May 1 15:45:41 2007 From: barry at python.org (Barry Warsaw) Date: Tue, 1 May 2007 09:45:41 -0400 Subject: [Mailman-Developers] Templating the interface In-Reply-To: References: Message-ID: <8E6BD654-48E6-4F59-A684-34636BEAFAFE@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 30, 2007, at 11:41 AM, Terri Oda wrote: > Ideally, I think it should be possible to skin mailman just using > CSS, so I'd say we should start there. And once that's done, maybe > someone could sit down and try making a few different skins so people > can have some enriched examples? read: examples with some > documentation inline so people can modify them easily. > > I think that could be a good starting point, since no matter what > further templating we want to do, getting workable (X)HTML coming out > of the interface seems like it would be a useful step. > > Terri > > PS - I'd also like to make our interface more usable, but making it > easy to use with stylesheets is a good goal even if we don't change > any of the content. :) Let me add something else. The trunk may not be stable enough to actually do much of the u/i rework yet. I'm really trying to spend all my spare time getting the trunk to a stable place, based on SQLAlchemy for the back-end. It's a disruptive chunk of work, but I'm making progress. If there are folks who want to start working on a new web u/i, either to integrate a new templating system, or to prototype better content or usability, then in the short term the thing to do would be to branch Mailman 2.1 and let you have at it. In order to get commit access, you'll need to assign your changes to the FSF. I can help you get all that paperwork in place. What do you think about going down that route? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRjdEhnEjvBPtnXfVAQLfkAP+P4CzeuZqGSHy9iOh3dClbzwk97hKd1uj K/vVfY8v8xIB/8aHopmR+HERGa+RNTkznMKv6/E7ZnG6D1F7OT58YmhCarvcS5u+ fCkm0Rs+81WaU11KrqwTXpvYIl4zXYr2mcYQ1qgbAq5zXzxv8KuCOF4vAFC7mo6Z 89BoFzasak8= =H28e -----END PGP SIGNATURE----- From jdennis at redhat.com Tue May 1 16:06:08 2007 From: jdennis at redhat.com (John Dennis) Date: Tue, 01 May 2007 10:06:08 -0400 Subject: [Mailman-Developers] Templating the interface In-Reply-To: <46351861.4060904@inetspec.com> References: <46351861.4060904@inetspec.com> Message-ID: <1178028368.14648.23.camel@finch.boston.redhat.com> On Sun, 2007-04-29 at 17:12 -0500, Jon Reese wrote: > Unfortunately there are a number of package related versions that cannot > be upgraded easily because the packagers have not brought the RPMs up to > date with the current stable release of Mailman (2.1.9). They may have > reasons for this, including versions of Python that are supported in > various packages as well as their own development cycles and lack of > manpower. If I am not mistaken, RHEL3, and CentOS3 are still relegated > to Mailman 2.1.5 due to a reliance on an earlier version of Python > (again the packagers have not upgraded the RPMs). I have at least two > machines that I would like to bring to Mailman 2.1.9, but it would do > more harm than good and other factors prevent OS upgrades. > > My desired hopes would include Mailman 2.1.9 support for Python 2.2.3 > without patches or changes to Python coding (for users of RHEL3 and > CentOS3); Perhaps you are laboring under a misconception concerning package upgrades within RHEL. By definition RHEL is version stable, once a version of RHEL is released a package never undergoes a version upgrade otherwise it would violate the guarantee of stability. There are of course some exceptions, occasionally RHEL will upgrade a package version in extraordinary circumstances, but there is nothing here which suggests mailman falls into this category. If you would like to upgrade the mailman version on RHEL3 you can do so yourself, either directly via the mailman source distribution or by installing an RPM from another release, but this would be a site customization unsupported by Red Hat. -- John Dennis Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007 From ACrosman at afsc.org Tue May 1 19:04:56 2007 From: ACrosman at afsc.org (Aaron Crosman) Date: Tue, 1 May 2007 13:04:56 -0400 Subject: [Mailman-Developers] Templating the interface In-Reply-To: <4637611C.4090400@mindlace.net> References: <8E6BD654-48E6-4F59-A684-34636BEAFAFE@python.org> <4637611C.4090400@mindlace.net> Message-ID: >From my reading of the responses to my question I see two ways that people are thinking of proceeding, which I think might complement each other well. First, there's the approach of fixing the current pages by moving the style information out of the Python code and into a CSS file. Second, there's the more extensive work to switch to a proper templating system like Genshi. I think in the long run, getting all the XHTML into external files is where the project should go. That will give users the most freedom to redesign how they see fit (good design of the default templates would still have that be styled using CSS), but it looks like there are a lot of work to make good progress in that area. I'd like to suggest a mixed approach. If we started to working fixing the 2.1 branch to have better output (even if it's never properly released), that would allow some people to do useful work while Barry firms up the trunk and we make a final choice of a templating engine. Once a template engine is inserted, that improved output could serve as the basis for the first templates for the system. Also, while we're finding a changing the HTML in the current python code, we could mark that code to be easy to find later. We also need to attend to the "creaky decade-old look", but I would suggest that really be taken on as part of the work to move to a real template system, not as part of picking off the low hanging fruit. Aaron From i at mindlace.net Tue May 1 17:47:40 2007 From: i at mindlace.net (Ethan Fremen) Date: Tue, 01 May 2007 11:47:40 -0400 Subject: [Mailman-Developers] Templating the interface In-Reply-To: <8E6BD654-48E6-4F59-A684-34636BEAFAFE@python.org> References: <8E6BD654-48E6-4F59-A684-34636BEAFAFE@python.org> Message-ID: <4637611C.4090400@mindlace.net> Barry Warsaw wrote: > If there are folks who want to start working on a new web u/i, either > to integrate a new templating system, or to prototype better content > or usability, then in the short term the thing to do would be to > branch Mailman 2.1 and let you have at it. In order to get commit > access, you'll need to assign your changes to the FSF. I can help > you get all that paperwork in place. Hello! After much absence I am something on the order of back. I have just landed a contract that will allow me to 'continue' my work on the mailman web ui, and my semester is ending, so I will actually have some time. Having struggled mightily to find a way to improve templating while not moving to python 2.4 (at least), I have to confess I don't think there's a good way to get there. I tried a couple of "scorched earth" approaches and I think that was part of why I didn't get something that worked. Right now, I think the "low hanging fruit" is to rip out all the HTML 'style' markup and make all the style applied via stylesheets. I would dearly love to have anyone to work with on this project. ... oh yeah, and I will submit my paperwork to the FSF June 1st, which I know is "hella late". ~ethan From barry at python.org Tue May 1 23:58:00 2007 From: barry at python.org (Barry Warsaw) Date: Tue, 1 May 2007 17:58:00 -0400 Subject: [Mailman-Developers] Templating the interface In-Reply-To: <4637611C.4090400@mindlace.net> References: <8E6BD654-48E6-4F59-A684-34636BEAFAFE@python.org> <4637611C.4090400@mindlace.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 1, 2007, at 11:47 AM, Ethan Fremen wrote: > Having struggled mightily to find a way to improve templating while > not > moving to python 2.4 (at least), I have to confess I don't think > there's > a good way to get there. That shouldn't be an obstacle for the Mailman trunk. Python 2.5 is required. Does this help give us a good way to get "there"? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRje36XEjvBPtnXfVAQJCLQP+KoNHXbDF3NYtpL1Ei5GKoQgiKuEglZcd vmJNnIg0DUoihocMk7y7RUAUcB+geiMCFpTgti13lhnMUO+1j1X2zl/IpJmv0D04 OQUp6UHCkLqGcvFylR1t2PE1Kw74pijRyr3LNn8ihcDaeUt+WuHaFoBfct1Ui1N7 M4VrnnvrE40= =X+GX -----END PGP SIGNATURE----- From barry at python.org Wed May 2 00:00:44 2007 From: barry at python.org (Barry Warsaw) Date: Tue, 1 May 2007 18:00:44 -0400 Subject: [Mailman-Developers] Templating the interface In-Reply-To: References: <8E6BD654-48E6-4F59-A684-34636BEAFAFE@python.org> <4637611C.4090400@mindlace.net> Message-ID: <7BAC2B2B-6E8B-4FC1-95D9-2FC6C68ECA00@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 1, 2007, at 1:04 PM, Aaron Crosman wrote: >> From my reading of the responses to my question I see two ways that > people are thinking of proceeding, which I think might complement each > other well. > > First, there's the approach of fixing the current pages by moving the > style information out of the Python code and into a CSS file. Second, > there's the more extensive work to switch to a proper templating > system > like Genshi. I think in the long run, getting all the XHTML into > external files is where the project should go. Totally agreed. One of the design goals of the trunk is to allow people to run Mailman without the web u/i, e.g. driven by Zope, TG, Django, etc. Once I get a little farther with my SQLAlchemy/Elixir branch, the next thing I'm going to do is egg-ify the code. I desperately want to get rid of configure. > That will give users the > most freedom to redesign how they see fit (good design of the default > templates would still have that be styled using CSS), but it looks > like > there are a lot of work to make good progress in that area. I'd > like to > suggest a mixed approach. If we started to working fixing the 2.1 > branch to have better output (even if it's never properly released), > that would allow some people to do useful work while Barry firms up > the > trunk and we make a final choice of a templating engine. Once a > template > engine is inserted, that improved output could serve as the basis for > the first templates for the system. Also, while we're finding a > changing the HTML in the current python code, we could mark that > code to > be easy to find later. > > We also need to attend to the "creaky decade-old look", but I would > suggest that really be taken on as part of the work to move to a real > template system, not as part of picking off the low hanging fruit. Agreed. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRje4jHEjvBPtnXfVAQLm9wQAqhU2ISlP0j5jD9OKBlc6Nc2F/qJSuSfB yxWk0YZXNUAcgzOc58NXL6fxyjd/112A5ait+1/WhgyCLOhrzwujrn3NMGldNYOf XkiUDKuko4F2Fi4/ELdX8uoBSUeGAXAheRZZXFLGavlUVzwKi6dPRnn7/RJyh2yf FIpoLOr0Yk0= =dhpL -----END PGP SIGNATURE----- From mads at kiilerich.com Wed May 2 00:09:14 2007 From: mads at kiilerich.com (Mads Kiilerich) Date: Wed, 02 May 2007 00:09:14 +0200 Subject: [Mailman-Developers] Templating the interface In-Reply-To: <46351861.4060904@inetspec.com> References: <46351861.4060904@inetspec.com> Message-ID: <4637BA8A.50203@kiilerich.com> Developers and Admins, It is understandable that some admins request a Mailman that works on their RHEL3 or older. But please don't let that hold development back at all. Admins really should appreciate that the developers look forward and focus on creating a system that is state-of-the-art. What they come up with now will probably be easy to install on RHEL5, and it will probably be included in RHEL6. RHEL3 is a "don't touch it if it works" system. And it probably works quite well. And if a part of the system has to be upgraded, then upgrade the whole system to RHEL5. And if upgrading isn't an option: It doesn't take long time to build a /usr/local/python2.5-for-mailman-only/ on an old system! /Mads RHCE From i at mindlace.net Wed May 2 02:35:03 2007 From: i at mindlace.net (Ethan Fremen) Date: Tue, 01 May 2007 20:35:03 -0400 Subject: [Mailman-Developers] Templating the interface In-Reply-To: <8E6BD654-48E6-4F59-A684-34636BEAFAFE@python.org> References: <8E6BD654-48E6-4F59-A684-34636BEAFAFE@python.org> Message-ID: <4637DCB7.5030300@mindlace.net> Let's see if python.org is ok with me now... Barry Warsaw wrote: > If there are folks who want to start working on a new web u/i, either > to integrate a new templating system, or to prototype better content > or usability, then in the short term the thing to do would be to > branch Mailman 2.1 and let you have at it. In order to get commit > access, you'll need to assign your changes to the FSF. I can help > you get all that paperwork in place. Hello! After much absence I am something on the order of back. I have just landed a contract that will allow me to 'continue' my work on the mailman web ui, and my semester is ending, so I will actually have some time. Having struggled mightily to find a way to improve templating while not moving to python 2.4 (at least), I have to confess I don't think there's a good way to get there. I tried a couple of "scorched earth" approaches and I think that was part of why I didn't get something that worked. Right now, I think the "low hanging fruit" is to rip out all the HTML 'style' markup and make all the style applied via stylesheets. I would dearly love to have anyone to work with on this project. ... oh yeah, and I will submit my paperwork to the FSF June 1st, which I know is "hella late". ~ethan From andy at insectnation.org Tue May 1 23:18:01 2007 From: andy at insectnation.org (Andy Buckley) Date: Tue, 01 May 2007 22:18:01 +0100 Subject: [Mailman-Developers] Templating the interface In-Reply-To: References: <8E6BD654-48E6-4F59-A684-34636BEAFAFE@python.org> <4637611C.4090400@mindlace.net> Message-ID: <4637AE89.6010902@insectnation.org> Aaron Crosman wrote: > From my reading of the responses to my question I see two ways that > people are thinking of proceeding, which I think might complement > each other well. I'm reading this thread with interest, as the problems of working with the current templates are really why I'm on this list even though I've never got round to raising the issue! Can I request that if the templates are being re-written some attention should be paid to the idea of making Mailman embeddable within a parent site's HTML framework and styles. For example, I run a system called HepForge where several content sources are hidden behind Apache and the page headers and footers, including CSS imports, are added by Apache output filters. A significant amount of work is currently required to edit Trac and Mailman templates to make them work with this sort of system - see http://trac.edgewall.org/ticket/4264 for a bit more detail on the issues with Trac's templates. This is a problem which is largely agnostic to the templating technology used and has more to do with design. In particular, it would be really nice if * the bits of the template which define , etc. are defined in one pair of header and footer files, so they can be turned off easily; * the CSS files "namespace" everything by placing all Mailman content within a div, e.g.
...
and then prefix all CSS rules with "#mailman" - this stops the Mailman styles from leaking out into the parent page elements. I can add this to the wiki if it's useful. Is it? (Sorry to dwell on implementation specifics at this stage, but it's an issue that's often ignored but is actually pretty important to people who want to incorporate external packages into their own framework.) > First, there's the approach of fixing the current pages by moving the > style information out of the Python code and into a CSS file. > Second, there's the more extensive work to switch to a proper > templating system like Genshi. Genshi has been mentioned a few times. My impression was that it insists on producing valid XML output, which is nice, but doesn't necessarily play well with ideas like factorisable head/foot portions. Also, can it be used for templating the automated email messages, i.e. plain text rather than XML? I'm not speaking from exceptional familiarity with Genshi here, but these suspicions made me use Cheetah in place of Genshi for one of our projects... can anyone confirm/refute these prejudices (off-list if necessary)? Andy From jon.reese at inetspec.com Wed May 2 01:49:10 2007 From: jon.reese at inetspec.com (Jon Reese) Date: Tue, 01 May 2007 18:49:10 -0500 Subject: [Mailman-Developers] Templating the interface In-Reply-To: References: <8E6BD654-48E6-4F59-A684-34636BEAFAFE@python.org> <4637611C.4090400@mindlace.net> Message-ID: <4637D1F6.70200@inetspec.com> Ethan, welcome back. Aaron, I like your idea of a multi-pronged approach and am very willing to focus on specific files or whatever portions that you or Ethan would like me to. Terri, I also like the idea of the "skin" approach and other UI systems that I have developed for did use that approach. It makes a good deal of sense if the list administrator could change the look and feel by selecting a "skin" from a predefined set. Perhaps, a series of CSS files in the form of "skin_name.css" inside the template directory. If the results can be used in MM 2.1 and make the forward movement of MM 2.2 that much easier, then I am all for it. I can probably donate 4 to 8 hours a week starting immediately or as required. John, I apologize if you thought I was poking at RHEL. Actually, just the opposite. I appreciate the stability and support offered by the packaged structure and do understand the bugfix policy. I just hope to extend any benefit to other users of RHEL in a way that is easier to implement. From barry at python.org Wed May 2 15:31:53 2007 From: barry at python.org (Barry Warsaw) Date: Wed, 2 May 2007 09:31:53 -0400 Subject: [Mailman-Developers] Templating the interface In-Reply-To: <4637AE89.6010902@insectnation.org> References: <8E6BD654-48E6-4F59-A684-34636BEAFAFE@python.org> <4637611C.4090400@mindlace.net> <4637AE89.6010902@insectnation.org> Message-ID: <98F5AA3E-2B7F-4CA5-A014-BB27C812B5D1@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 1, 2007, at 5:18 PM, Andy Buckley wrote: > In particular, it would be really nice if > > * the bits of the template which define , etc. are > defined > in one pair of header and footer files, so they can be turned off > easily; > * the CSS files "namespace" everything by placing all Mailman > content > within a div, e.g.
...
and then prefix all CSS > rules with "#mailman" - this stops the Mailman styles from leaking out > into the parent page elements. > > I can add this to the wiki if it's useful. Is it? It is, please do! I see a couple of stops along the web u/i configurability track. Most sites won't care and will just use Mailman right out of the box. Others will be content with just tweaking a little CSS to get their colors right. Still others will want to embed the Mailman u/i in their own web pages. And finally, hard core users may want to ditch the u/i all together, writing their own or running Mailman without a web u/i at all. I think we can and should support all of these scenarios. > Genshi has been mentioned a few times. My impression was that it > insists > on producing valid XML output, which is nice, but doesn't necessarily > play well with ideas like factorisable head/foot portions. Also, > can it > be used for templating the automated email messages, i.e. plain text > rather than XML? I'm not speaking from exceptional familiarity with > Genshi here, but these suspicions made me use Cheetah in place of > Genshi > for one of our projects... can anyone confirm/refute these prejudices > (off-list if necessary)? Please keep it on-list. I'm interested in the discussion too! I forgot to mention Cheetah -- Ethan, did you play with it at one point? Templating the email messages would be nice to have, but it's not as critical as the web u/i. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRjiSyXEjvBPtnXfVAQJFvwP/XrSSoBe3zByYL9YHGUj3N61pq53GajhQ hKsJz1zAaWBmXfChrOvhR4nhJyGFRZ/P+rKT67q4oXkYAgFDJqRpTL8aKupwaw1S C5oV8MPy0yJ7GFUjHaS0WueNYHPVGana1CQQSkkpF0xBxbYyHLQPuZBEf/IXURDG NlnO88zK098= =LEdB -----END PGP SIGNATURE----- From amk at amk.ca Wed May 2 16:21:39 2007 From: amk at amk.ca (A.M. Kuchling) Date: Wed, 2 May 2007 10:21:39 -0400 Subject: [Mailman-Developers] Templating the interface In-Reply-To: <4637611C.4090400@mindlace.net> References: <8E6BD654-48E6-4F59-A684-34636BEAFAFE@python.org> <4637611C.4090400@mindlace.net> Message-ID: <20070502142139.GB4971@localhost.localdomain> On Tue, May 01, 2007 at 11:47:40AM -0400, Ethan Fremen wrote: > Right now, I think the "low hanging fruit" is to rip out all the HTML > 'style' markup and make all the style applied via stylesheets. Agreed. I'd be happy to embark on that effort while waiting for the trunk to settle down. --amk From amk at amk.ca Wed May 2 16:22:52 2007 From: amk at amk.ca (A.M. Kuchling) Date: Wed, 2 May 2007 10:22:52 -0400 Subject: [Mailman-Developers] Templating the interface In-Reply-To: <1F65AD6E-99DD-41F6-81B3-921FE5E9C047@python.org> References: <1F65AD6E-99DD-41F6-81B3-921FE5E9C047@python.org> Message-ID: <20070502142252.GC4971@localhost.localdomain> On Tue, May 01, 2007 at 09:41:58AM -0400, Barry Warsaw wrote: > initially and ran into problems there too. He may have moved to > Genshi toward the end of the project. I know there are many other > templating systems out there, such as PTL (from Quixote) but I don't > have much experience with them. I would encourage folks who have I think the critical question is audience: who will be customizing Mailman? Can we assume they know XML? can they keep their HTML well-formed XML? will they use an HTML editor or just a text editor like vi/emacs? Some toolkits (Genshi, ZPT, Nevow) demand that the input be well-formed XML and work to ensure their output is well-formed. Here's an example from the Nevow for python.org:
    • This produces {content of label slot}. Other toolkits don't enforce this: you write something like:
      %for link_2, level3_links in level2_links:
    • ${link_2.as_html()}
      • %endfor
    Make a typo and change to , and this will happily generate bad HTML. But it's also easier to hack away at a page and generate output, albeit possibly-invalid output. So, who do we picture customizing Mailman's templates? Core developers? Sysadmins? Skilled web designers? Beginning web designers? (I'd rule out Quixote's PTL: too idiosyncratic, and Mailman's target audience may want to customize the look while not knowing Python. Plus the import hook complicates life.) --amk From barry at python.org Wed May 2 16:44:29 2007 From: barry at python.org (Barry Warsaw) Date: Wed, 2 May 2007 10:44:29 -0400 Subject: [Mailman-Developers] Templating the interface In-Reply-To: <20070502142139.GB4971@localhost.localdomain> References: <8E6BD654-48E6-4F59-A684-34636BEAFAFE@python.org> <4637611C.4090400@mindlace.net> <20070502142139.GB4971@localhost.localdomain> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 2, 2007, at 10:21 AM, A.M. Kuchling wrote: > On Tue, May 01, 2007 at 11:47:40AM -0400, Ethan Fremen wrote: >> Right now, I think the "low hanging fruit" is to rip out all the HTML >> 'style' markup and make all the style applied via stylesheets. > > Agreed. I'd be happy to embark on that effort while waiting for the > trunk to settle down. It sounds like the right course of action is to branch the branches/ Release_2_1-maint branch to let you guys hack on this. How about branches/modernize_21_webui ? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRjijzXEjvBPtnXfVAQKoTwQAr8Fr2XPEQj/KOqAt/9+kuIiyp8S5r8UK GWF2rWwlpRkjAbbF13sruUO7G613h5vbnHhhZ4sFEOdKHDn+swCj2GpxeVu3VzTW N1e1/PUHCjX0bOjfIbtF8PtClA7vlZCPfNdKMqIcO2FNVKWpq1oWLJwWqpP9Xd5k MPPUJjXs610= =wYzS -----END PGP SIGNATURE----- From barry at python.org Wed May 2 17:14:38 2007 From: barry at python.org (Barry Warsaw) Date: Wed, 2 May 2007 11:14:38 -0400 Subject: [Mailman-Developers] Templating the interface In-Reply-To: <20070502142252.GC4971@localhost.localdomain> References: <1F65AD6E-99DD-41F6-81B3-921FE5E9C047@python.org> <20070502142252.GC4971@localhost.localdomain> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 2, 2007, at 10:22 AM, A.M. Kuchling wrote: > On Tue, May 01, 2007 at 09:41:58AM -0400, Barry Warsaw wrote: >> initially and ran into problems there too. He may have moved to >> Genshi toward the end of the project. I know there are many other >> templating systems out there, such as PTL (from Quixote) but I don't >> have much experience with them. I would encourage folks who have > > I think the critical question is audience: who will be customizing > Mailman? Can we assume they know XML? can they keep their HTML > well-formed XML? will they use an HTML editor or just a text editor > like vi/emacs? Great questions, thanks Andrew. Here are my thoughts, but I'm open to other opinions. Related to the different levels of customizability, I'd say that it should be easy for folks to change some color schemes and basic look with just a passing understanding of CSS. That suggests weekend warrior web designers with a text editor and something like http:// www.w3schools.com/css/default.asp open in their browsers. > So, who do we picture customizing Mailman's templates? Core > developers? Sysadmins? Skilled web designers? Beginning web > designers? For anything more complex, I think our audience is skilled web designers and experienced developers. As much as possible, I'd like for someone who is a moderately to very skilled web designer, and understands XHTML and XML but probably not Python, to be able to do 80% of the web customization they'd need. I think it's okay if we relegate the really complex 20% (e.g. ditching our wsgi web publisher and integrating with Zope) to be a skilled Python developer. One thing this will require from the core is moving all the logic out of the Mailman/Cgi modules and into the core libraries. This will also make it feasible to mirror more of the web functionality into other channels, such as email and command line (or possibly even a fat u/i interface). That's a task that's on my list for the trunk. > (I'd rule out Quixote's PTL: too idiosyncratic, and Mailman's target > audience may want to customize the look while not knowing Python. > Plus the import hook complicates life.) That's great to know, thanks! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRjiq33EjvBPtnXfVAQJfPwP/YVaBXtt8QUsJQ+1bO5Mctvaj0ChAdAe2 TS52Mc3Zk0jSKWL7eCMKbUpyvTS5s87wtTUAi2jq6VietyErRotDT4Gj8gCCpWo0 gtCzOemC9VkicWAuc02D1MtYjXPVOlVmezU9yKrjJIn3KVoUiGqP8Y9LGvyj3umN o7rDqO7jIww= =mMNm -----END PGP SIGNATURE----- From Jeff.Kunzelman at dhl.com Wed May 2 17:11:48 2007 From: Jeff.Kunzelman at dhl.com (Jeff Kunzelman (DHL)) Date: Wed, 2 May 2007 08:11:48 -0700 Subject: [Mailman-Developers] Templating the interface In-Reply-To: <4637D1F6.70200@inetspec.com> References: <8E6BD654-48E6-4F59-A684-34636BEAFAFE@python.org> <4637611C.4090400@mindlace.net> <4637D1F6.70200@inetspec.com> Message-ID: <83EB3FBBDF867245A54F47D4136B68C5D0E4B5@PHXDCEX012.phx-dc.dhl.com> Is there a way that I can use the withlist command to change the display name of a mailman list? From barry at python.org Thu May 3 00:09:15 2007 From: barry at python.org (Barry Warsaw) Date: Wed, 2 May 2007 18:09:15 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? Message-ID: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm very encouraged and excited by all the interest from developers who want to get involved in the Mailman project. I've always wanted to broaden the sphere of developers beyond the current core three (though I can't say enough about the great job Tokio and Mark do). I think this is a good time to ask whether we should move from Subversion to Bazaar for our source code revision control system. There are plusses and minuses, and I will not make the decision unilaterally (unless you want me to. :). Certainly, Tokio's and Mark's opinions are very important here because they are currently doing exceptional work on the 2.1 branch and I don't want to jeopardize that! Let me outline my thinking here and get your feedback. Bazaar is a distributed version control system. This is really the crucial different between centralized systems such as Subversion and CVS, and it's the main draw for wanting to switch. Using a dvcs such as Bazaar really changes the way we as developers work on the code, and the way other non-privileged developers can interact with the project. The biggest differences are that you can work completely disconnected from the central server, and you need have no special permissions to have *and publish* fully revision controlled personal branches. The cons are that it's not as mature as Subversion or CVS, but I have confidence that it's pretty stable. It has not yet reached a 1.0 release, but I think that's coming soon. (It's been ported to *nix, OS X, and Windows, and it's written in Python if that matters). It does not have all the features of Subversion (e.g. nested branches or externals), but it has enough to make it useable for everyday development. It takes some getting used to for existing Subversion and CVS users, and the documentation is not as good. But I think people can pick it up fairly quickly and there's a lot of effort being put into it. Full disclosure: my company Canonical is the driving force behind Bazaar, and uses it internally for all our development. It's free software though, so no worries on that front. I would not recommend it for the Mailman project though unless I thought it could solve some real problems, that it was stable enough to rely on, and that Mailman would benefit from using it. Having insiders to heckle helps, but it wouldn't be enough if that's all there was. What problems does it solve? Well, I'm /still/ struggling to merge in the work I did while on the train to PyCon in Dallas because of all the contortions I had to go through to work off-line for a couple of days. Bazaar solves this by allowing me to do everything I need to do while completely disconnected, except push my changes to the master branch. I could have committed, branched, merged, reverted, etc. all in a completely revision controlled way while off-line, and then I could have merged all my changes back to the master branch when I got back on-line. It also solves a problem I have of many live branches. Branches in Bazaar are cheap, unlike in Subversion. This means I can easily create branches for my Elixir experiments, for the move to eggs, for playing with 5 different templating engines, etc. And it's easy to merge between these. I can also have private branches that need never see the embarrassing light of day until they are stable enough to merge into the main line. What problems does it solve for you? Well, if you're a developer wanting to contribute to Mailman but we don't know you well enough to give you commit privileges, you almost don't care. You can branch from the main branch, and have a fully revision controlled private branch at your disposal. You can do commits, branches, merges, etc. on your local branches. You can even publish them via http, bzr+ssh, or sftp. Why is that cool? Well, say you created the best damn templating patch EVAR and you wanted everyone to see it. Just publish your branch (or create a bundle -- a mailable tarball-like unit of your changes) and pass around the URL. Anyone can then take a look at your branch, and the core developers can merge them into the mainline if we like them. It's a great way for new developers to earn some street cred with minimal admin overhead. And if we /don't/ like your changes, you do not have to maintain them as a disembodied patch. You can say "screw the Mailman guys, here's my cool fork" and have a fully revision controlled version of your own, in a way that's much easier to track with upstream than with Subversion or CVS. One more thing. If we move to Bazaar, I would host the branches on Launchpad.net, which -- full disclosure again -- is developed, managed, and paid for by my employer. Why Launchpad? Because it's convenient, I have insiders I can bug, and because it already supports hosted Bazaar branches. Let me emphasis that Canonical is in no way driving this. They don't care what we do for Mailman, and understand fully that stuff like this are community decisions. I personally think Bazaar+Launchpad will make some of our lives easier, but if you guys do not agree, we'll stick with what we've got, no harm, no foul. Please do share your opinions freely here in public, or via private email. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRjkMDHEjvBPtnXfVAQLcXgP/fnriiMwu9gAQEvXmUiGLXLSfkcmkzyAm cqbu2QjmTm7uZapFq3WLmItfBuoVP3HkOdaa+ibpgR8WJUxt6UksbFXCSPPxmWlR tPI8BS65r0gnf0MUM3dvbvkhizGVmYkhK7gAW6dmH43Um1o5CbskkbaWjIMLJ+0L ter/gGwLu+8= =ftG9 -----END PGP SIGNATURE----- From fil at rezo.net Thu May 3 00:25:11 2007 From: fil at rezo.net (Fil) Date: Thu, 3 May 2007 00:25:11 +0200 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> Message-ID: Hi Barry, when I tried to do some work on Mailman, a while ago (a few years, in fact), I was not put off by the (then) CVS system used, but more by the fact that it seemed very difficult to get write priviledges (I didn't insist enough either, though I got the GNU assignment papers); and by the fact that the GNU requirements are quite strict, which lead me to wonder what was really "mine" in the patch I would have liked to offer (as it was inspired in part by someone else's patch). The ticket system at Sourceforge is/was almost unusable. So, in the end, I have my own little patch on my personal SVN server, which of course almost no one has read, and which evidently got outdated, and, well, will stay in that state until I find the time to upgrade it again, compare all by hand and test. I'm not sure a new versioning system can help for this kind of problem, but if it can, I'm all for it (though I don't really fancy learning yet another versioning system, as I'm very happy with SVN for my developments). Not really an answer, and a bit off-topic, sorry. :) HTH anyway -- Fil From jdennis at redhat.com Thu May 3 00:37:18 2007 From: jdennis at redhat.com (John Dennis) Date: Wed, 02 May 2007 18:37:18 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> Message-ID: <1178145438.26445.32.camel@finch.boston.redhat.com> On Wed, 2007-05-02 at 18:09 -0400, Barry Warsaw wrote: > I think this is a good time to ask whether we should move from > Subversion to Bazaar for our source code > revision control system. > Bazaar is a distributed version control system. This is really the > crucial different between centralized systems such as Subversion and > CVS I'm all for distributed SCM's, using a distributed SCM is a good move. Internally here there is a *lot* of interest in switching from CVS to a distributed SCM. The big question is not whether to switch to a distributed SCM but which one. Out of the many options two seem to have bubbled to the top as true contenders, GIT and Mercurial. Mercurial is also written in Python. It seems to be in wide use, it seems to stable, and other projects support it as an SCM (e.g. Trac, another popular Python project). I've used Mercurial now for about 5 months and it has worked well. FWIW we have other projects also using Mercurial. I'll confess I'm not familiar with Bazaar and what it has to offer, it may be the optimal choice, but I'm wondering, have you given Mercurial serious consideration? -- John Dennis Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007 From ee at uncanny.net Thu May 3 00:31:26 2007 From: ee at uncanny.net (Edward Elhauge) Date: Wed, 2 May 2007 15:31:26 -0700 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> Message-ID: <20070502223126.GA54891@uncanny.net> Hi Barry, Would you compare Bazaar to GnuArch (tla): http://www.gnuarch.org/arch/ Is your Bazaar a different branch of Arch? I ask because I've used tla a lot and liked it. On the Arch page they have the main Arch repository as: http://bazaar.canonical.com/ * Barry Warsaw wrote on [2007-05-02 15:09]: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'm very encouraged and excited by all the interest from developers > who want to get involved in the Mailman project. I've always wanted > to broaden the sphere of developers beyond the current core three > (though I can't say enough about the great job Tokio and Mark do). I > think this is a good time to ask whether we should move from > Subversion to Bazaar for our source code > revision control system. ... ---end quoted text--- -- Edward Elhauge "The life which is unexamined is not worth living." -- Plato From stephen at xemacs.org Thu May 3 14:03:33 2007 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 03 May 2007 21:03:33 +0900 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <20070502223126.GA54891@uncanny.net> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <20070502223126.GA54891@uncanny.net> Message-ID: <87odl2f71m.fsf@uwakimon.sk.tsukuba.ac.jp> Edward Elhauge writes: > Would you compare Bazaar to GnuArch (tla): > http://www.gnuarch.org/arch/ > > Is your Bazaar a different branch of Arch? Yes. The bazaar Barry is talking about is commonly called "bzr" (the name of the command) or "bazaar-ng". It's similar in that it is a distributed SCM. If you like *Arch* as opposed to the features offered by all the dSCMs (git, Mercurial, Darcs, ...), you may be distressed by bzr, as internally it's quite different from Arch. The repo model is very different, many of Arch's commands are gone or work differently, etc. YMMV, of course; it depends on how much your use cases depend on those aspects of Arch. The pluses to bzr, compared to larch, ArX, tla, or bazaar (aka baz), in order of importance to the seasoned tla user: 1. Fast. The different repository model allows much faster transactions, both locally and across the internet. 2. Everyday workflow (branch, routine merge, commit, new project, ...) is very similar to tla. But then, it's very similar to git or darcs, too. :-) 3. The "best available" diff algorithm for code. It's marginally slower than GNU diff or python difflib for very small diffs, but traditional diffs are O(N^3) while patiencediff use by bzr is O(N^2). Furthermore, it is claimed by its author (Bram Cohen, who you may know better as "Mr. BitTorrent") to give much more readable output in many cases. It is plug compatible with other diffs (ie, can be tuned to give diff -c or diff -u output), so it seems likely that other projects (Darcs is considering it right now) will adopt it, at least as an option. It generally produces larger diffs, but if you prefer -U 3, you obviously aren't interested in minimizing diff size. :-) 4. Better error reporting and warnings. Not that that's difficult compared to tla. :-( From stephen at xemacs.org Thu May 3 15:01:22 2007 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 03 May 2007 22:01:22 +0900 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> Message-ID: <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > think this is a good time to ask whether we should move from > Subversion to Bazaar for our source code > revision control system. I would rank Bazaar(-ng == bzr) third behind git and Mercurial. I like git because it tastes like Mom's home cooking. Er, I mean, the git model has a strong flavor of Lisp, although "cons", "car", "cdr", and "get" are about the only operations fully implemented yet. This has long been the way I think about vcses, despite long flirtations with GNU Arch and Darcs. While Linus is not primarily interested in vcses, the fact that he chose to implement his personal vcs as a dialect of the oldest (and still going strong) computer language is indicative of future possibilities. If there's going to be another quantum leap in vcses in the next few years, my bet is that the prototype will be a child of git. Mercurial is second because it is likely to be the choice of my main project, XEmacs. It has strong recommendations from people working at Sun, where it is already becoming widespread. Documentation is better than git's, and much better for the new user. It's developed by vcs pros. Bazaar is close to Mercurial, for similar reasons (s/Sun/Canonical/). However, I give Mercurial the edge because it is being developed by people who develop vcses for their own sake, while Canonical has demonstrated that their interest in vcses is instrumental to their development business. Nothing wrong with that per se, but I think that dvcses have a long way to go to reach maturity (viz Darcs's "theory of patches" approach and its innovative and addictive UI not yet copied by any of the other main contenders). I think it's worth going with Mercurial for the possibility of picking up on the "next next" generation early. While the whole point of bzr is to be to tla as svn is to cvs. :-) I should remark that bzr's diffs are currently the best in the business. See my reply to Edward Elhauge and also Bram Cohen's blog http://bramcohen.livejournal.com/37690.html. This advantage probably won't last long, though---git and Mercurial both have their diff commands well-modularized, it won't be hard to add. Re some vcses that IMO won't fly: Darcs, although very interesting as a radical departure from the other dvcses, is IMO not ready for prime time yet. Development is somewhat slowed by being written in Haskell, which makes it hard for most users to contribute directly. It also has some really dire performance problems that show up in ordinary usage for a non-negligible fraction of projects. The Arch 1 family (arx, tla, baz) is a non-starter. It's very usable, but for future development, it's orphaned. The main author, Tom Lord, is once again being a radical innovator, movint on to Arch 2. But Arch 2 (also known as "revc") is not ready for "real work" yet, it may not even be self-hosting at this point. In any case, Tom is not currently able to push development very actively. There are a couple of others out there, but I think the main contenders are Bazaar, git, and Mercurial. IMO any of them will do. > Bazaar is a distributed version control system. This is really the > crucial different between centralized systems such as Subversion and > CVS, and it's the main draw for wanting to switch. It also means that at the present time there's very little difference between git, Mercurial, and Bazaar in use. The real difference is in the goals of the maintainers, namely "keeping Linus happy", "making the best possible dvcs", and "what we use at work." All of these have their advantages. Everything that Barry wrote that I've cut out I agree with, strongly. > One more thing. If we move to Bazaar, I would host the branches on > Launchpad.net, which -- full disclosure again -- is developed, > managed, and paid for by my employer. Why Launchpad? Because it's > convenient, I have insiders I can bug, and because it already > supports hosted Bazaar branches. IMO, this is an important advantage to Bazaar. Similarly, the Debian project sponsors a Mercurial host on Alioth, which I would imagine is pretty professionally run. Barry being an insider at Launchpad is a good thing, though. Does use of Launchpad imply access to the patch queue manager, too? Or is that Canonical-only? (Not a problem if it is Canonical-only, but it's a nice-to-have feature!) > Let me emphasis that Canonical is in no way driving this. Good. AFAICT, Canonical is a big business, it behaves like a big business, but it talks like a charity. Nothing wrong with the first two, but the third confuses me. I'd recommend keeping arms' length. > I personally think Bazaar+Launchpad will make some of our lives > easier, +1 on that. I've now done merges of multi-megabyte patches with both Darcs and git. It's thinkable. Doing it with CVS or Subversion no longer is. (That would apply to bazaar, too, I'm sure, though I have no experience with it.) One caveat: as the dvcs proponents are always pointing out, it's not necessary to actually use them in a distributed fashion. In fact it's *easy* to just drop them in to the same old workflow. This gives a perceptible improvement for insiders, but in open source you can get lot more! I hope, Barry, that you will allocate some time to reorganizing the Mailman workflow to encourage participation from third parties (eg, Fil, the MHonArc patch, etc). From barry at python.org Thu May 3 16:34:09 2007 From: barry at python.org (Barry Warsaw) Date: Thu, 3 May 2007 10:34:09 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> Message-ID: <2D08881F-A227-47B2-B241-5EE0BDFAD9B1@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for all the excellent feedback folks! On May 2, 2007, at 6:25 PM, Fil wrote: > when I tried to do some work on Mailman, a while ago (a few years, in > fact), I was not put off by the (then) CVS system used, but more by > the fact that it seemed very difficult to get write priviledges (I > didn't insist enough either, though I got the GNU assignment papers); > and by the fact that the GNU requirements are quite strict, which lead > me to wonder what was really "mine" in the patch I would have liked to > offer (as it was inspired in part by someone else's patch). I read a blog entry by Ian Bicking about this subject, which I think he wrote back in 2005. He also pointed out that write privileges are a big sticking point for community participation in code development, to which I agree. However, he also concluded that dvcs's are /bad/ for open source because they encourage private branches, and everything should be done in the open. I agree that we should strive for maximal openness, but I don't agree that dvcs's necessarily make things less open. I think it's entirely possible they make things /more/ open. There's certainly nothing preventing anyone from publishing their own dvcs branches, perhaps even competing with the main line. While I don't want to encourage forks of my own projects, the potential for increased competition does keep us honest. And I think interested ideas that folks like you have Fil, can better compete in the marketplace when they are just as first class as the main branch. IOW, having your own branches instead of patches means that the successful ones should be able to garner more community support, thus improving the likelihood that the main line will accept them. So I think the jury is still out on whether dvcs's increase overall openness or decrease it. I'm putting my money on the former. Of course, I think it /will/ make our lives harder in some ways. As we've seen, folks like cPanel have their own forks that they modify, and then their users come looking to us for support, which we can't give them. Having more public branches out there will increase our support costs. We may need to be more careful about blessing the official branches and making it clear (on web page footers and such) which is being used. All that being said, the plight that you, Fil, and others go through, and the desire on my part to open up the development process more, is a big driving factor for me finally getting off my ass and doing something about it. Moving to a dvcs is the first step. > The ticket system at Sourceforge is/was almost unusable. That's a side issue, and one I whole-hearted agree with. Remember that Atlassian has provided us with free hosted Jira, which is just waiting for us. The blocker there is that neither I, nor my contact at Atlassian, has had time to complete the SF export and Jira import. A case of e-beers and a year's worth of FLOSS karma goes to whoever volunteers to help make this happen. > So, in the end, I have my own little patch on my personal SVN server, > which of course almost no one has read, and which evidently got > outdated, and, well, will stay in that state until I find the time to > upgrade it again, compare all by hand and test. > > I'm not sure a new versioning system can help for this kind of > problem, but if it can, I'm all for it (though I don't really fancy > learning yet another versioning system, as I'm very happy with SVN for > my developments). I don't think there's any controversy that moving to a dvcs will be an overall win for all of us. Certainly learning bzr was pretty easy, an hg looks just as easy. (More on that next.)_ > Not really an answer, and a bit off-topic, sorry. :) HTH anyway Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRjny4nEjvBPtnXfVAQKV8QQAjnnaA+szCnJaCRmotjELMRVyIzdtpOzi 8grfKrtOgOYhWtIjwwfGyyoT/YsiZtWRs6gOtzh2XMLW2yg0K/f2xg/ibtgcKYUm NQN27V/xiV4pug9to8mgSb1gtUiV5kWC8+tr0Tra+Hb5hmGKg6iIh974qWt9zmc6 HKADJcCtNEI= =gFwp -----END PGP SIGNATURE----- From barry at python.org Thu May 3 16:35:45 2007 From: barry at python.org (Barry Warsaw) Date: Thu, 3 May 2007 10:35:45 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <1178145438.26445.32.camel@finch.boston.redhat.com> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <1178145438.26445.32.camel@finch.boston.redhat.com> Message-ID: <1BDE939B-22A2-4860-B9CA-7C6ED170793D@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 2, 2007, at 6:37 PM, John Dennis wrote: > I'll confess I'm not familiar with Bazaar and what it has to offer, it > may be the optimal choice, but I'm wondering, have you given Mercurial > serious consideration? It was on my radar, but no, I hadn't. I will though. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRjnzQ3EjvBPtnXfVAQIkMAP/dJ9F6K528RDmrCCpSj9NdW1etKpRfKPJ VhdwCldUcB1JW5eQ/hQWeEaoh+r234FGkiC1E9YH7UewQUlZ96+lK4k6LlWOj2uy G1FqKLct2wIEEoO/Lf4ycP+ItTFdvndVtLNqZHr3biUvpRz+gke0IXyBf2od0ENc J4bZysB+Kps= =0oXT -----END PGP SIGNATURE----- From jdennis at redhat.com Thu May 3 16:37:37 2007 From: jdennis at redhat.com (John Dennis) Date: Thu, 03 May 2007 10:37:37 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <1178203057.2688.22.camel@junko.usersys.redhat.com> On Thu, 2007-05-03 at 22:01 +0900, Stephen J. Turnbull wrote: [ superb summary, snipped for brevity ] Thank you Stephen for your excellent summary, it was very informative and even handed. I tend to share your view that git and mercurial are the current best of breed. At the moment the open source world is boiling with SCM innovation after nearly 20 years of stability anchored by CVS. This is good. What is not good for developers is the current fracturing. Projects have selected different SCM's requiring developers to become familiar with each of them. If one wants to be productive for better or worse there is a significant learning curve. I'm already seeing issues where cooperating organizations can no longer work together because they no longer can manipulate their partner's SCM, or worse have invested heavily in tools which only work with a particular SCM (e.g. CVS). Eventually this will sort itself out as one or two SCM's generate enough gravity to cause convergence. But in the meantime this fracturing is producing barriers to productivity. If in the decision making process this concern could be taken into account I think it would be beneficial. By restricting the options to the SCM's which currently have the most mindshare the pain threshold for developers would be mitigated and the project would have stronger assurances of on-going future support for the SCM. -- John Dennis From barry at python.org Thu May 3 17:16:57 2007 From: barry at python.org (Barry Warsaw) Date: Thu, 3 May 2007 11:16:57 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <18450C07-EF3F-4B24-8713-ECA79BFC3EB2@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 3, 2007, at 9:01 AM, Stephen J. Turnbull wrote: > Barry Warsaw writes: > >> think this is a good time to ask whether we should move from >> Subversion to Bazaar for our source code >> revision control system. > > I would rank Bazaar(-ng == bzr) third behind git and Mercurial. I > like git because it tastes like Mom's home cooking. Unless there's a strong constituency behind git, I view it as lower on the list than bzr or hg, primarily because of my own sentimental bias toward a Python solution. I like having the ability (and desire) to investigate and fix bugs in our vcs if necessary. Steve says, and I agree, that any of the three would suit our purposes. I think any three would be fast enough, easy enough to learn, stable enough, and would solve our current issues, so I don't think we can go wrong either way. BTW, I also think that once we move to /any/ dvcs, moving among them will be fairly easy. E.g. we could bring up a Tailor instance if we wanted. The conversion from svn can be a bit painful, but it looks like it'll be doable for either hg or bzr. I don't have much time to investigate all the dvcs's out there, so unless someone says "you will not be able to live without feature X which only D has!", I'd like to narrow the choice down to either Mercurial or Bazaar-ng. > Mercurial is second because it is likely to be the choice of my main > project, XEmacs. It has strong recommendations from people working at > Sun, where it is already becoming widespread. Documentation is better > than git's, and much better for the new user. It's developed by vcs > pros. > > Bazaar is close to Mercurial, for similar reasons (s/Sun/Canonical/). > However, I give Mercurial the edge because it is being developed by > people who develop vcses for their own sake, while Canonical has > demonstrated that their interest in vcses is instrumental to their > development business. Nothing wrong with that per se, but I think > that dvcses have a long way to go to reach maturity (viz Darcs's > "theory of patches" approach and its innovative and addictive UI not > yet copied by any of the other main contenders). I think it's worth > going with Mercurial for the possibility of picking up on the "next > next" generation early. While the whole point of bzr is to be to tla > as svn is to cvs. :-) > > I should remark that bzr's diffs are currently the best in the > business. See my reply to Edward Elhauge and also Bram Cohen's blog > http://bramcohen.livejournal.com/37690.html. This advantage probably > won't last long, though---git and Mercurial both have their diff > commands well-modularized, it won't be hard to add. I really appreciate the information Steve. I've just installed Mercurial and I'm going to spend a few days playing with it. > There are a couple of others out there, but I think the main > contenders are Bazaar, git, and Mercurial. IMO any of them will do. Agreed. >> One more thing. If we move to Bazaar, I would host the branches on >> Launchpad.net, which -- full disclosure again -- is developed, >> managed, and paid for by my employer. Why Launchpad? Because it's >> convenient, I have insiders I can bug, and because it already >> supports hosted Bazaar branches. > > IMO, this is an important advantage to Bazaar. Similarly, the Debian > project sponsors a Mercurial host on Alioth, which I would imagine is > pretty professionally run. Barry being an insider at Launchpad is a > good thing, though. Does use of Launchpad imply access to the patch > queue manager, too? Or is that Canonical-only? (Not a problem if it > is Canonical-only, but it's a nice-to-have feature!) Alioth is for Debian only, right? Would they host Mercurial branches for other FLOSS software like Mailman? If we go with Mercurial, we'll need someone reliable to host the official branches. I certainly don't want to do that myself! Is there a Mercurial equivalent to SF for cvs and svn, or Launchpad for bzr? I asked around about pqm, but right now Launchpad does not provide general pqm services. I agree it would be very cool to have. >> Let me emphasis that Canonical is in no way driving this. > > Good. AFAICT, Canonical is a big business, it behaves like a big > business, but it talks like a charity. Nothing wrong with the first > two, but the third confuses me. I'd recommend keeping arms' length. There will of course be advantages to using Launchpad and bzr, based on my relationship with the company that hosts those. I will, as always, strive to be as open and transparent as possible with the Mailman project so that you guys can keep me honest. IMHO I don't think Canonical would want it any other way, but that's speaking as an insider. If ever Y'all ever think decisions are not being made in the best interest of Mailman, please speak up! >> I personally think Bazaar+Launchpad will make some of our lives >> easier, > > +1 on that. I've now done merges of multi-megabyte patches with both > Darcs and git. It's thinkable. Doing it with CVS or Subversion no > longer is. (That would apply to bazaar, too, I'm sure, though I have > no experience with it.) I agree about cvs and svn. Wanna compare scars? :) > One caveat: as the dvcs proponents are always pointing out, it's not > necessary to actually use them in a distributed fashion. In fact it's > *easy* to just drop them in to the same old workflow. This gives a > perceptible improvement for insiders, but in open source you can get > lot more! I hope, Barry, that you will allocate some time to > reorganizing the Mailman workflow to encourage participation from > third parties (eg, Fil, the MHonArc patch, etc). Absolutely. The Mailman developer community must grow and the development process must become more open. Moving to a dvcs is the first step, but an important one. There are other things we can do to encourage participation as well. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRjn86nEjvBPtnXfVAQIajQP+MsY23H78RWkFFpQmJoS6q7IcKnrc1abp ZunpiXy+1ClW35MUMooIOTsZ0p1H473rP6EISUDYzgKgvTqc3oQ1fifEZgXeUE48 L8gsbhUis4aCWXvcmROx6BY5tZ2A7FeLj+gWLTNYOT4nCDaJSUFi1bWiLIj3PTkH 8amYEL87p+o= =9mEU -----END PGP SIGNATURE----- From barry at python.org Thu May 3 17:25:18 2007 From: barry at python.org (Barry Warsaw) Date: Thu, 3 May 2007 11:25:18 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <1178203057.2688.22.camel@junko.usersys.redhat.com> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <1178203057.2688.22.camel@junko.usersys.redhat.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 3, 2007, at 10:37 AM, John Dennis wrote: > On Thu, 2007-05-03 at 22:01 +0900, Stephen J. Turnbull wrote: > > [ superb summary, snipped for brevity ] Agreed! I also agree with your assessment John. It's an evolutionary battle: cvs ate rcs, svn ate cvs, and now the next generation is battling for dominance. I think it's too early to pick a winner, the way cvs was a clear win for so long, and svn was a no brainer after that. > If in the decision making process this concern could be taken into > account I think it would be beneficial. By restricting the options to > the SCM's which currently have the most mindshare the pain > threshold for > developers would be mitigated and the project would have stronger > assurances of on-going future support for the SCM. Your point about interoperability is an important one, and definitely a factor in the decision. I think the risk is mitigated by tools like Tailor, and I have confidence that should we choose hg, bzr or something else, we'll be able to fairly easily convert if a clear winner emerges. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRjn+4HEjvBPtnXfVAQIQdgP+JpcNOC+a5ZXanIF8NnL91a3mveR2rCu2 yemhPPv7HaJ7FyWKr7W9vAe1cyl7xG6lAsVvlARQNIyFyKxO76NvuZKb8mqUuUUz 7m+PPaJBW1uzTnmPQpxYPmWndZCkAQxjGzWZCNK9IkTg38RyrIIdzgzBqvY1XjAG ONadNBKUEU8= =Q/P4 -----END PGP SIGNATURE----- From fil at rezo.net Thu May 3 17:37:29 2007 From: fil at rezo.net (Fil) Date: Thu, 3 May 2007 17:37:29 +0200 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <2D08881F-A227-47B2-B241-5EE0BDFAD9B1@python.org> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <2D08881F-A227-47B2-B241-5EE0BDFAD9B1@python.org> Message-ID: > write privileges are > a big sticking point for community participation in code development, > to which I agree. However, he also concluded that dvcs's are /bad/ > for open source because they encourage private branches, and > everything should be done in the open. My own experience with SPIP (www.spip.net, a project now 7 years old and that I "guide") is that there was a lot a frustration when we had a 3-devs SVN system. The "big guys" spent time evaluating (and rejecting) proposals that were not "good enough". Two years ago we opened a secondary SVN server, named "spip-zone", with a motto of "anything that's free software and relates to SPIP". It now has 150+ devs and thousands of projects positively blossom (to quote Chairman Mao). This has been a place where shy developers have been more able to express themselves, and now the "core" team has expanded, integrating some of these developers. But most surely the "core" is more focused, and frustration has almost disappeared. -- Fil From jdennis at redhat.com Thu May 3 17:42:27 2007 From: jdennis at redhat.com (John Dennis) Date: Thu, 03 May 2007 11:42:27 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <18450C07-EF3F-4B24-8713-ECA79BFC3EB2@python.org> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <18450C07-EF3F-4B24-8713-ECA79BFC3EB2@python.org> Message-ID: <1178206948.2688.25.camel@junko.usersys.redhat.com> On Thu, 2007-05-03 at 11:16 -0400, Barry Warsaw wrote: > Alioth is for Debian only, right? Would they host Mercurial branches > for other FLOSS software like Mailman? If we go with Mercurial, > we'll need someone reliable to host the official branches. I > certainly don't want to do that myself! Is there a Mercurial > equivalent to SF for cvs and svn, or Launchpad for bzr? The Fedora Project has started project hosting as well. At the moment it is Trac based with Mercurial as one of the SCM options. -- John Dennis From barry at python.org Thu May 3 17:49:30 2007 From: barry at python.org (Barry Warsaw) Date: Thu, 3 May 2007 11:49:30 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <2D08881F-A227-47B2-B241-5EE0BDFAD9B1@python.org> Message-ID: <4E97418C-8131-483E-8F1E-F53D62E8F5E7@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 3, 2007, at 11:37 AM, Fil wrote: >> write privileges are >> a big sticking point for community participation in code development, >> to which I agree. However, he also concluded that dvcs's are /bad/ >> for open source because they encourage private branches, and >> everything should be done in the open. > > My own experience with SPIP (www.spip.net, a project now 7 years old > and that I "guide") is that there was a lot a frustration when we had > a 3-devs SVN system. The "big guys" spent time evaluating (and > rejecting) proposals that were not "good enough". > > Two years ago we opened a secondary SVN server, named "spip-zone", > with a motto of "anything that's free software and relates to SPIP". > It now has 150+ devs and thousands of projects positively blossom (to > quote Chairman Mao). > > This has been a place where shy developers have been more able to > express themselves, and now the "core" team has expanded, integrating > some of these developers. But most surely the "core" is more focused, > and frustration has almost disappeared. I think we can do the same thing, without all the pain that svn brings with it. Remember that in bzr (and I'm sure hg is the same), branches are /really/ cheap. In fact, it's encouraged to keep your branch changes small, and not worry about branch proliferation. Small focussed branches make it easier to review, and merge into the main line. In fact, because you don't need to coordinate with /me/ to create and publish branches means anyone can do it. I envision that the really great patches will be easier to merge, and the really great developers will be easier to promote. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRjoEi3EjvBPtnXfVAQKFCAQAgcNkIaot1Hlv+DffA9RlTk5njvb8bOo0 ViELnkoJQxfb4ocBexw6QA09kpDYm3HSYXAN9KUq3BZyH87aMkUSK8Ck1iLGhfye q4oLOdy0/hEE/AHiAtLxYWwb79Wv7d5DoGkWy+aweiZ4FNtvU02Qcqg5Uqz34hqQ AJNPefSceFI= =bj1Z -----END PGP SIGNATURE----- From barry at python.org Thu May 3 17:54:16 2007 From: barry at python.org (Barry Warsaw) Date: Thu, 3 May 2007 11:54:16 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <1178206948.2688.25.camel@junko.usersys.redhat.com> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <18450C07-EF3F-4B24-8713-ECA79BFC3EB2@python.org> <1178206948.2688.25.camel@junko.usersys.redhat.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 3, 2007, at 11:42 AM, John Dennis wrote: > On Thu, 2007-05-03 at 11:16 -0400, Barry Warsaw wrote: >> Alioth is for Debian only, right? Would they host Mercurial branches >> for other FLOSS software like Mailman? If we go with Mercurial, >> we'll need someone reliable to host the official branches. I >> certainly don't want to do that myself! Is there a Mercurial >> equivalent to SF for cvs and svn, or Launchpad for bzr? > > The Fedora Project has started project hosting as well. At the > moment it > is Trac based with Mercurial as one of the SCM options. Cool, thanks for the pointer. I found this wiki page: http://fedoraproject.org/wiki/Infrastructure/ProjectHosting?highlight= %28hosting%29 Looks like the service is beta-ish, but provides multiple vcs support. We'd probably need to coordinate with the Fedora folks to get a project hosted (no auto-registration), but let's keep this one in mind. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRjoFqXEjvBPtnXfVAQLgCAQAl5AAh+FzZ+w69Es/sCLpk6J6zo3d8wU8 LPaJsm7ZWBnPIjXh9KzsnronzLle9Lgut/yLOUjEm5q/TgMzdZ3b1Ndh8FZ67RQE S/zk2nSiWGIM45rRKn2yjYi2WpceYLvRG+yZOkQXO0mWnxK+3wdkUVNWRMlDryJE 7fNJukgtE5A= =a6xN -----END PGP SIGNATURE----- From jon at latchkey.com Thu May 3 17:50:16 2007 From: jon at latchkey.com (Jon Scott Stevens) Date: Thu, 3 May 2007 08:50:16 -0700 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <1178203057.2688.22.camel@junko.usersys.redhat.com> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <1178203057.2688.22.camel@junko.usersys.redhat.com> Message-ID: <8C192910-011F-4FFF-85DF-1B6B825EB0AE@latchkey.com> Since I haven't seen anyone else mention this... there is also: http://en.wikipedia.org/wiki/SVK I say stick with Subversion/SVK: #1. *everyone* knows how to use it and almost all OSS software projects use it. #2. The subversion developers are *awesome*. I used to work with them at CollabNet and know them personally. Very smart great guys. #3. SVK solves the problems that you are talking about. #4. It would allow you to host your source code on code.google.com for free and be able to have the benefits of taking advantage of google's infrastructure. > Branches in Bazaar are cheap, unlike in Subversion. I'm really sorry Barry, but that's just plain untrue. Read this: http://svnbook.red-bean.com/en/1.0/ch04s02.html "Cheap Copies" jon stevens http://subetha.tigris.org/ From stephen at xemacs.org Thu May 3 18:57:21 2007 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 04 May 2007 01:57:21 +0900 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <1178203057.2688.22.camel@junko.usersys.redhat.com> Message-ID: <877irpg80e.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > Your point about interoperability is an important one, and definitely > a factor in the decision. I think the risk is mitigated by tools > like Tailor, Tailor is great, but "mitigated" is as far as you can go. The basic stuff like branches and committer id is properly moved from one to the other. However, you can lose some metadata going from one dvcs to another if the target doesn't support it. For example, git supports both author and committer IDs for each commit, which others don't, and git has its signed tags. Dublin Core, anyone? From mads at kiilerich.com Thu May 3 20:06:52 2007 From: mads at kiilerich.com (Mads Kiilerich) Date: Thu, 03 May 2007 20:06:52 +0200 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <18450C07-EF3F-4B24-8713-ECA79BFC3EB2@python.org> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <18450C07-EF3F-4B24-8713-ECA79BFC3EB2@python.org> Message-ID: <463A24BC.1050805@kiilerich.com> Barry Warsaw wrote, On 05/03/2007 05:16 PM: > Alioth is for Debian only, right? Would they host Mercurial branches > for other FLOSS software like Mailman? If we go with Mercurial, > we'll need someone reliable to host the official branches. I > certainly don't want to do that myself! Is there a Mercurial > equivalent to SF for cvs and svn, or Launchpad for bzr? > Mr Mercurial might soon come up with an alternative: http://marc.info/?l=mercurial&m=117753118122082 and John Dennis wrote, On 05/03/2007 04:37 PM: > What is not good for developers is the current fracturing. Projects have > selected different SCM's requiring developers to become familiar with > each of them. If one wants to be productive for better or worse there is > a significant learning curve. I'm already seeing issues where > cooperating organizations can no longer work together because they no > longer can manipulate their partner's SCM, or worse have invested > heavily in tools which only work with a particular SCM (e.g. CVS). > Eventually this will sort itself out as one or two SCM's generate enough > gravity to cause convergence. But in the meantime this fracturing is > producing barriers to productivity. > I think there is a trend in the direction that conversion between SCMs can be done trivially on the fly, so that you can use whatever SCM you like and still be able to work with upstream whatever SCM they use. /Mads From amk at amk.ca Thu May 3 22:49:21 2007 From: amk at amk.ca (A.M. Kuchling) Date: Thu, 3 May 2007 16:49:21 -0400 Subject: [Mailman-Developers] Starting a CSS wiki page Message-ID: <20070503204921.GA20549@localhost.localdomain> I've started a page with random notes about adding CSS: http://wiki.list.org/display/DEV/StyledPages Edit away! Given my interest in the archiver, I'm starting by looking at the archive templates and noting some ideas for what should be added. --amk From amk at amk.ca Fri May 4 03:03:18 2007 From: amk at amk.ca (A.M. Kuchling) Date: Thu, 3 May 2007 21:03:18 -0400 Subject: [Mailman-Developers] Styling patch Message-ID: <20070504010318.GA949@andrew-kuchlings-computer.local> Patch #1415956 from Bryan Carbonnell adds CSS for styling purposes and changes the HTML to be valid XHTML1.0. It still needs some tidying up, and it still uses tables for layout, but that patch takes us halfway there. It presents one big compatibility issue that will probably need to be fixed. The patch removes the colour settings (WEB_HEADER_COLOR, WEB_ERROR_COLOR, WEB_ADMINITEM_COLOR, etc.) and replaces them with CSS class declarations. It's probably unacceptable to break the use of these settings, so there needs to be some compatibility fix. Colours could be substituted into the .css file somehow, or a 'style' attribute could be added as well as a 'class' attribute. Does anyone have suggestions for what to do? Patch URL: [Aside: are there many patches in the tracker that could be useful? I don't know how actively they've been getting processed. Does there need to be a push to process bugs and patches?] --amk From amk at amk.ca Fri May 4 03:45:35 2007 From: amk at amk.ca (A.M. Kuchling) Date: Thu, 3 May 2007 21:45:35 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <8C192910-011F-4FFF-85DF-1B6B825EB0AE@latchkey.com> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <1178203057.2688.22.camel@junko.usersys.redhat.com> <8C192910-011F-4FFF-85DF-1B6B825EB0AE@latchkey.com> Message-ID: <20070504014525.GA1213@andrew-kuchlings-computer.local> On Thu, May 03, 2007 at 08:50:16AM -0700, Jon Scott Stevens wrote: > http://en.wikipedia.org/wiki/SVK What about SVK's speed, though? There was discussion of providing a DVCS mirror of the Python SVN, so I tried at making a copy of the repository via SVK, and SVK looked like it was going to be painfully slow; I calculated something like 13 hours to create the initial mirror (but I killed it after an hour, so that's an estimate). Python has about 55,000 revisions, so mirroring is obviously a big job, but that seems unusably slow. Maybe Mailman is small enough to take a more reasonable time. --amk From i at mindlace.net Fri May 4 04:42:15 2007 From: i at mindlace.net (Ethan Fremen) Date: Thu, 03 May 2007 22:42:15 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <2D08881F-A227-47B2-B241-5EE0BDFAD9B1@python.org> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <2D08881F-A227-47B2-B241-5EE0BDFAD9B1@python.org> Message-ID: <463A9D87.1040302@mindlace.net> Barry Warsaw wrote: > Of course, I think it /will/ make our lives harder in some ways. As > we've seen, folks like cPanel have their own forks that they modify, > and then their users come looking to us for support, which we can't > give them. Having more public branches out there will increase our > support costs. I would submit that much of what has caused people in the Mailman community to maintain their own forks is because the software design is insufficiently open, not so much on account of checkin privileges. Moving Mailman development to distributed trees will force, I suspect, more modularization and extensibility of the code, which will reduce the need for long-lived, independent forks. Basically, I suspect that while it might increase support issues in the short term, it will ultimately reduce the support-to-participant ratio. ~ethan From i at mindlace.net Fri May 4 04:48:21 2007 From: i at mindlace.net (Ethan Fremen) Date: Thu, 03 May 2007 22:48:21 -0400 Subject: [Mailman-Developers] Templating the interface In-Reply-To: References: <8E6BD654-48E6-4F59-A684-34636BEAFAFE@python.org> <4637611C.4090400@mindlace.net> <20070502142139.GB4971@localhost.localdomain> Message-ID: <463A9EF5.3010708@mindlace.net> Barry Warsaw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On May 2, 2007, at 10:21 AM, A.M. Kuchling wrote: > >> On Tue, May 01, 2007 at 11:47:40AM -0400, Ethan Fremen wrote: >>> Right now, I think the "low hanging fruit" is to rip out all the HTML >>> 'style' markup and make all the style applied via stylesheets. >> Agreed. I'd be happy to embark on that effort while waiting for the >> trunk to settle down. > > It sounds like the right course of action is to branch the branches/ > Release_2_1-maint branch to let you guys hack on this. How about > > branches/modernize_21_webui great by me! ~ethan From i at mindlace.net Fri May 4 04:54:58 2007 From: i at mindlace.net (Ethan Fremen) Date: Thu, 03 May 2007 22:54:58 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> Message-ID: <463AA082.7010500@mindlace.net> I think it is an excellent idea to move to a distributed source code system, and my time in the trenches with Barry doing python.org mail stuff makes me think that the easier it is for the lead developers to work directly with the support people, the better it is for the software project. I've really appreciated the quality of the hosted wiki solution lists.org uses, and directly experienced the difficulty of maintaining a host of services on a volunteer basis; system administration is really not a great hobby. So I would land firmly on the side of going with bazaar and frankly all the cool kids are on Launchpad already. The fact that Barry can be there to apply gentle suasion is a key bonus. I think any other option would be less ideal if it had less of the human component than this option does. ~ethan From i at mindlace.net Fri May 4 05:19:36 2007 From: i at mindlace.net (Ethan Fremen) Date: Thu, 03 May 2007 23:19:36 -0400 Subject: [Mailman-Developers] Developing for mailman is hard Message-ID: <463AA648.6020509@mindlace.net> Hi! I'm a spoiled young brat who used to have ambitions to be a graphic designer, did a couple of underground 'zines right around when this whole "web" thing started. Anyway, so I got dragged kicking and screaming into the programming side of things- astute googling would find some posts of me complaining that there's no good GUI for Apache. What drew me to mailman back in the mid 90's was the fact that it had a nice web interface, so I have always thought of mailman as a web app that happens to handle message processing. Client side web development is really kind of dreamy; you edit the file, upload it to the server, see what's changed, lather rinse repeat. PHP doesn't stray far from this model; most PHP "apps" are "drop this folder into your DOCHOME and give it DB privs" to set up. Usually, developing for these apps can be done right from a checkout, or at the very least once the build process is complete there aren't any dependencies on it. I can find no way to get anywhere close to this model in trying to improve the web UI. To be clear, my ignorance of make, ant, and all that is pretty much nonexistent, so I'm hoping my most crucial problems are merely on account of that ignorance. * running instance -> checkout issues. I want to make changes to mailman python objects and get those changes back into a checkin. The closest I came to a working approach was: 1.) build mailman. 2.) fiddle settings so that the web UI doesn't interfere with other mailman install. 3.) remove the Mailman directory and symlink the Mailman directory from the repository. This more or less works, but any time I want to add, rename or delete anything I have to fix all the makefile stuff in order for the branch to be buildable. I also can't re-run the build process without repeating the delete/symlink dance. (also, the HTTPserver has to be restarted on each change... i vaguely fixed that on my branch, but I have no idea if that made it in elsewhere). This will partially be mitigated if we move to a distributed source code model, because I can just maintain all the utterly gerfucked branches I need to and I won't be cluttering other people's revision logs with all sorts of SVN modifications. How do you "round trip" between a test instance and source code? * Templates bult on compile. I want to make changes to the templates and then make sure they build properly in all languages, I have the right i18n strings, etc. The UI templates seem to be built during compile time; while there is vast consensus that pre-building templates should change, is there any way to just rebuild templates from the command line? There are a bunch of other itches I have, but this is the one that makes scratching most difficult for me at the moment. Thanks for listening ;) ~ethan From i at mindlace.net Fri May 4 05:27:19 2007 From: i at mindlace.net (Ethan Fremen) Date: Thu, 03 May 2007 23:27:19 -0400 Subject: [Mailman-Developers] Styling patch In-Reply-To: <20070504010318.GA949@andrew-kuchlings-computer.local> References: <20070504010318.GA949@andrew-kuchlings-computer.local> Message-ID: <463AA817.7090006@mindlace.net> A.M. Kuchling wrote: > Patch #1415956 from Bryan Carbonnell adds CSS for styling purposes and > changes the HTML to be valid XHTML1.0. It still needs some tidying > up, and it still uses tables for layout, but that patch takes us > halfway there. For the moment, I can make at least IE7/firefox "ignore" the tables via css commands, so I could make a lot of progress with just this patch. The next thing I would do/like to see happen is a minimum-markup table-free version, as that would make UI experimentation much easier. ~ethan From i at mindlace.net Fri May 4 05:56:28 2007 From: i at mindlace.net (Ethan Fremen) Date: Thu, 03 May 2007 23:56:28 -0400 Subject: [Mailman-Developers] Templating the interface In-Reply-To: References: <1F65AD6E-99DD-41F6-81B3-921FE5E9C047@python.org> <20070502142252.GC4971@localhost.localdomain> Message-ID: <463AAEEC.5000703@mindlace.net> Barry Warsaw wrote: \ > Related to the different levels of customizability, I'd say that it > should be easy for folks to change some color schemes and basic look > with just a passing understanding of CSS. I agree with this, and think that a vast swath of customization needs could be met with CSS manipulations only, assuming the (x)html is decent. CSSZenGarden.com is a good example of this. To clarify the situation with Genshi a tiny bit, it does have the capability to deal with less-than-flawless xml; which is good because you have to break certain rules sometimes to make browsers do the right thing. > One thing this will require from the core is moving all the logic out > of the Mailman/Cgi modules and into the core libraries. What are the "core libraries" in this context? ~ethan From stephen at xemacs.org Fri May 4 07:07:18 2007 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 04 May 2007 14:07:18 +0900 Subject: [Mailman-Developers] Styling patch In-Reply-To: <20070504010318.GA949@andrew-kuchlings-computer.local> References: <20070504010318.GA949@andrew-kuchlings-computer.local> Message-ID: <87mz0ldvnd.fsf@uwakimon.sk.tsukuba.ac.jp> A.M. Kuchling writes: > [Aside: are there many patches in the tracker that could be useful? "Could be useful", definitely. I've used several at one time or another. But typically they're unsatisfactory as-is because they hard-code the intended behavior. OTOH, they are non-trivial to integrate as options, so neither the original submitter nor the core devs do so. Nor us downstream users. :-( > I don't know how actively they've been getting processed. My impression is that many get considered when first submitted, but then languish indefinitely due to the above kind of problem. > Does there need to be a push to process bugs and patches? I suspect getting more modularity, making it easier to turn interesting ideas into generally available options, should be given precedence. Especially since that's where Barry is headed in Mailman 3 AIUI. If the Triumvirate could free up some time for it, an MvL-like review-for-5-reviews policy, even if only a limited-time offer, could help clean up the backlog, though. From dgc at uchicago.edu Fri May 4 07:53:11 2007 From: dgc at uchicago.edu (David Champion) Date: Fri, 4 May 2007 00:53:11 -0500 Subject: [Mailman-Developers] Batch-level list configuration In-Reply-To: <83EB3FBBDF867245A54F47D4136B68C5D0E4B5@PHXDCEX012.phx-dc.dhl.com> References: <8E6BD654-48E6-4F59-A684-34636BEAFAFE@python.org> <4637611C.4090400@mindlace.net> <4637D1F6.70200@inetspec.com> <83EB3FBBDF867245A54F47D4136B68C5D0E4B5@PHXDCEX012.phx-dc.dhl.com> Message-ID: <20070504055311.GZ24134@monkey.uchicago.edu> * On 2007.05.02, in <83EB3FBBDF867245A54F47D4136B68C5D0E4B5 at PHXDCEX012.phx-dc.dhl.com>, * "Jeff Kunzelman (DHL)" wrote: > > Is there a way that I can use the withlist command to change the display > name of a mailman list? You can, but you must write valid python code that manipulates properties of the list object. Withlist's function is to instantiate a list object to facilitate these manipulations. This attached program is something we developed here for uchicago.edu some years ago, and have been using for a variety of batch and/or bulk manipulations of list properties. It's a bit more convenient than withlist or the config_list program that appears is more recent Mailman versions. In short, you can use configlist to display or set any list property *entirely on the command line*. Values are displayed as python expressions, and when setting a value, it must be set to a valid expression, but you don't need to write any actual code. I don't think that I've posted this before -- I'm sorry if I'm wrong about that. Feel free to use it without any warranty, etc. Examples: $ configlist.py mylist [ shows all properties of the list as python expressions ] $ configlist.py mylist description description: 'This is the display name as shown on the listinfo page.' $ configlist.py mylist description="'The mylist list is for me.'" [ sets description. Note the redundant quoting to protect the python expression from shell. ] $ configlist.py mylist description=s/mylist/MyList/ [ use the s/// expression to munge the existing value of description ] Configlist.py can be rather dangerous, because it allows changing any list property at all without any of the constraints that may be built into the web UI. Be sure you know what you're doing. You can use configlist.py before and after a web UI change to get a feel for how to script the same change in the future. I apologize that the code is probably horrific to python enthusiasts. It was among my first efforts and I've not revisited it since actually learning the language. -- -D. dgc at uchicago.edu, an Element of NSIT University of Chicago -------------- next part -------------- #!/opt/bin/python ## ## Sets/gets a mailing list's parameters. Any of them. ## Danger, Will Robinson. ## ## $Id: configlist.py,v 1.7 2004/01/20 21:19:19 dgc Exp $ ## """usage: configlist.py [-h|--help] configlist.py [-n|--not-really] listname configlist.py [-n|--not-really] listname param ... configlist.py [-n|--not-really] listname param=value ... configlist.py [-n|--not-really] listname param=/rx/value/flags ... configlist.py [-n|--not-really] listname param=s/rx/subst/flags ... configlist.py [-l|--no-lock] .... NOTE WELL: so that we can support all data types, parameter assignment must follow Python syntax. In particular, this means that string literals are quoted. For example: configlist.py list numeric_value=3 configlist.py list string_value="'foo'" configlist.py list array_value="['foo', 'bar']" configlist.py list dict_value="{'num': 3, 'str': 'foo'}" configlist.py list any_value="s/foO/bar/ig" See %(myname)s for more usage details. """ # # + If no parameters are named, the entire dictionary is dumped. # + If a parameter has no predicate, that parameter is displayed. # + With an "=value" predicate, that value is assigned. # + With an "=/rx/value/flags" predicate, the value is assigned if the regular # expression matches. "flags" are the usual regex flags. # + With an "=s/rx/subst/flags" predicate, a substitition is applied to the # portion of the original value which matches the regex. Flags are the usual. # # With the -n flag, all the same work is done and results displayed; but the # changes are not saved. # # regex matches apply to all the stringified python data, not just values. # this is particularly relevant for dictionaries: the dict keys are subject # to the substs just as the dict values are. # import os import sys sys.path.insert(0, "/opt/pkgs/mailman") import getopt import string import grp import pwd import paths import re from Mailman.MailList import MailList, Errors myname = sys.argv[0] def usage(msg=''): print __doc__ % globals() if msg: print "Error: " + msg sys.exit(1) def dump_params(list): ## get keys, sort a = list.__dict__.keys() a.sort() ## iterate and print for param in a: print param + ": " + eval("repr(list." + param + ")") def do_params(list, args): changed = -1 for arg in args: if string.find(arg, '=/') > -1: try: param, more = string.split(arg, '=/') except: usage() try: search, replace, flags = string.split(more, '/') except: usage() if flags: rx = re.compile(search + "(?" + string.lower(flags) +")") else: rx = re.compile(search, 0) value = eval("repr(list." + param + ")") if rx.search(value): changed = 1 exec("list." + param + " = " + replace) print param + ": " + eval("repr(list." + param + ")") elif string.find(arg, "=s/") > -1: try: param, more = string.split(arg, '=s/') except: usage() try: search, replace, flags = string.split(more, '/') except: usage() value = eval("repr(list." + param + ")") if flags: rx = re.compile(search + "(?" + string.lower(flags) +")") else: rx = re.compile(search, 0) nvalue = rx.sub(replace, value); if value != nvalue: changed = 1 exec("list." + param + " = " + nvalue) print param + ": " + eval("repr(list." + param + ")") elif string.find(arg, '=') > -1: param, value = string.split(arg, '=') exec("list." + param + " = " + value) print param + ": " + eval("repr(list." + param + ")") changed = 1 else: print eval("list." + arg) changed = 0 return changed def main(): cautious = 0 dolock = 1 try: opts, args = getopt.getopt(sys.argv[1:], 'hnl', ['help', 'not-really', 'no-lock']) except getopt.error, msg: usage(msg) if len(args) < 1: usage('A list name must be supplied.') name = args[0] for opt, arg in opts: if opt in ('-h', '--help'): usage() if opt in ('-n', '--not-really'): cautious = 1 if opt in ('-l', '--no-lock'): dolock = 0 ## Load the list, or else emit an error immediately. try: list = MailList(name, 0) except Errors.MMUnknownListError, msg: usage(msg) ## Find appropriate user information. group = grp.getgrnam('mailman') gid = group[2] passwd = pwd.getpwnam('mailman') uid = passwd[2] ## Lock the list. if dolock: list.Lock() ## If no parameters named, dump all dictionary pairs. if len(args) == 1: dump_params(list) changed = 0 ## For each param, try to split on "=", and get or set accordingly. else: changed = do_params(list, args[1:]) ## If something was altered, save the list and set permissions. if changed: rc = 0 if cautious: print "List " + name + " not saved (cautious)" else: print "Saving changed list \"" + name + "\"." list.Save() os.chown(list._full_path + "/config.db", uid, gid) os.chmod(list._full_path + "/config.db", 00664) elif changed < 0: print "List " + name + " unchanged." rc = 1 else: rc = 0 ## Unlock and quit. if dolock: list.Unlock() sys.exit(rc) main() ## ## $Log: configlist.py,v $ ## Revision 1.7 2004/01/20 21:19:19 dgc ## regex operations added ## -n (test mode) flag added ## help text updated to soothe complexity of syntax ## ## Revision 1.6 2001/06/07 23:04:31 dgc ## A touch further documentation in the help text. ## ## Revision 1.5 2001/06/06 13:18:08 dgc ## Renamed list_param.py to configlist.py -- a little more conventional ## ## Revision 1.4 2001/06/06 08:42:05 dgc ## path fix ## ## Revision 1.3 2001/06/06 07:39:08 dgc ## No longer prints "Saving list (foo)" on save ## ## Revision 1.2 2001/06/06 07:35:49 dgc ## cleaned up code a bit, added permission & owner fixes on save ## From j.e.vanbaal at uvt.nl Fri May 4 14:02:07 2007 From: j.e.vanbaal at uvt.nl (Joost van Baal) Date: Fri, 4 May 2007 14:02:07 +0200 Subject: [Mailman-Developers] alioth.debian.org and mercurial (was: Re: Should we move to Bazaar?) In-Reply-To: <18450C07-EF3F-4B24-8713-ECA79BFC3EB2@python.org> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <18450C07-EF3F-4B24-8713-ECA79BFC3EB2@python.org> Message-ID: <20070504120207.GH8834@banach.uvt.nl> Hi, On Thu, May 03, 2007 at 11:16:57AM -0400, Barry Warsaw wrote: > Alioth See http://wiki.debian.org/Alioth and https://alioth.debian.org/projects/siteadmin/ for information about this service. > is for Debian only, right? "Any free software project where a Debian Developer is involved is fine." > Would they host Mercurial branches for other FLOSS software like Mailman? "The hg.debian.org admins will create a directory named /srv/hg.debian.org/hg/project-name owned by your project group which will be accessible by hg ssh or http for read-only access. Within that directory, you can hg init/clone/whatever as many branches/repos as you like." Of course, other hosting offerings might be more suitable. Bye, Joost -- Joost van Baal http://abramowitz.uvt.nl/ Tilburg University j.e.vanbaal at uvt.nl The Netherlands -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: Digital signature Url : http://mail.python.org/pipermail/mailman-developers/attachments/20070504/7092ec96/attachment.pgp From barry at python.org Fri May 4 15:23:43 2007 From: barry at python.org (Barry Warsaw) Date: Fri, 4 May 2007 09:23:43 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <8C192910-011F-4FFF-85DF-1B6B825EB0AE@latchkey.com> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <1178203057.2688.22.camel@junko.usersys.redhat.com> <8C192910-011F-4FFF-85DF-1B6B825EB0AE@latchkey.com> Message-ID: <02BA9388-7493-425B-B5B6-D540D708B56E@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 3, 2007, at 11:50 AM, Jon Scott Stevens wrote: > Since I haven't seen anyone else mention this... there is also: > > http://en.wikipedia.org/wiki/SVK > > I say stick with Subversion/SVK: > > #1. *everyone* knows how to use it and almost all OSS software > projects use it. > #2. The subversion developers are *awesome*. I used to work with them > at CollabNet and know them personally. Very smart great guys. > #3. SVK solves the problems that you are talking about. > #4. It would allow you to host your source code on code.google.com > for free and be able to have the benefits of taking advantage of > google's infrastructure. Does svk solve some of svn's problems? - - The need to use svnmerge or similar tool so that revisions in different branches don't merge multiple times - - The need to sometimes commit changes before you're ready (i.e. double moves) - - Inexplicable errors with cryptic error messages - - Inability to merge across renames - - True nested branches (svn:externals is broken). Don't get me wrong, I love svn, and it definitely accomplished its mission of being a better cvs. It's got its quirks and annoyances, and we'd be fools to think that the other vcs's don't have their own share. I'm skeptical that svk will substantially improve the development model over svn, but maybe I'm just guilty of a greener pastures mentality. >> Branches in Bazaar are cheap, unlike in Subversion. > > I'm really sorry Barry, but that's just plain untrue. Read this: > > http://svnbook.red-bean.com/en/1.0/ch04s02.html > "Cheap Copies" It's not the same thing. svn cp is pretty heavyweight compared to bzr branch. To have an svn branch revision controlled it has to be committed back to the server and that's what makes it so heavy. With bzr (and I'm assuming hg), you can branch locally 'til the cows come home, and each branch is fully revision controlled right away, with no need to communicate with the parent branch (if say it were on a separate server). - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRjsz33EjvBPtnXfVAQLIsQP9GAzWSy4KSOrHMd6WqK/yGgfz3NFqIFRI mwVwyZdXqKQrnBCKFcENB0IjbQXhnAvSIxxKH/CO1iFCbUkSv5/utJa3ceX6MoXP NI6wwp/xi427RJ4CXmnW77tRxGGJjAo/MGNKj3ijVs0ksPj83wXZGQrsVS5qg6R2 +7MDlZCNEw8= =XCOS -----END PGP SIGNATURE----- From barry at python.org Fri May 4 15:27:35 2007 From: barry at python.org (Barry Warsaw) Date: Fri, 4 May 2007 09:27:35 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <877irpg80e.fsf@uwakimon.sk.tsukuba.ac.jp> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <1178203057.2688.22.camel@junko.usersys.redhat.com> <877irpg80e.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <0220F631-2F50-4765-9751-8D28102FD5F5@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 3, 2007, at 12:57 PM, Stephen J. Turnbull wrote: > Barry Warsaw writes: > >> Your point about interoperability is an important one, and definitely >> a factor in the decision. I think the risk is mitigated by tools >> like Tailor, > > Tailor is great, but "mitigated" is as far as you can go. The basic > stuff like branches and committer id is properly moved from one to the > other. However, you can lose some metadata going from one dvcs to > another if the target doesn't support it. For example, git supports > both author and committer IDs for each commit, which others don't, and > git has its signed tags. So my take away from this is that while a conversion would be / possible/ it's not completely seamless or automatic. If we choose wrong, we'll suffer some pain, but we'll recover. ;) Would you say that's accurate? I could live with that. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRjs0x3EjvBPtnXfVAQJ/kAP/SuvnK3sZyiAJSt+xilwWJxF9wOo04Dbw uzk/e8yEOWg8UoAxSZAUny5c+sIb7QI0PI+AWI7gJuUrhu2HM24nAUT1zztmSHk1 pSpAitzHK15uknyntbtS3opYkZPJe/q8qiraITC4PEfvjOF67KbiImWlz+IgU0Kv P5m0f8q5UmQ= =p9+f -----END PGP SIGNATURE----- From barry at python.org Fri May 4 15:28:58 2007 From: barry at python.org (Barry Warsaw) Date: Fri, 4 May 2007 09:28:58 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <463A24BC.1050805@kiilerich.com> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <18450C07-EF3F-4B24-8713-ECA79BFC3EB2@python.org> <463A24BC.1050805@kiilerich.com> Message-ID: <4004CCE4-5752-4802-B09D-724ACDC0DFBC@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 3, 2007, at 2:06 PM, Mads Kiilerich wrote: > Barry Warsaw wrote, On 05/03/2007 05:16 PM: >> Alioth is for Debian only, right? Would they host Mercurial branches >> for other FLOSS software like Mailman? If we go with Mercurial, >> we'll need someone reliable to host the official branches. I >> certainly don't want to do that myself! Is there a Mercurial >> equivalent to SF for cvs and svn, or Launchpad for bzr? >> > > Mr Mercurial might soon come up with an alternative: > http://marc.info/?l=mercurial&m=117753118122082 That could be very interesting. I know that was just a couple of weeks ago, but have you heard of an eta for such hosting? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRjs1GnEjvBPtnXfVAQJiQQP/Rh+AAFDT43Mn4+WCjLEhxriXLUASsBoN es8bJohwd76wqUvL83VL8UedIIxW0g8UdRB7v+NtD/k12bL8F3RPBUZQqw/lhYUb gYrPT2uNfQ73GDf3VzXPc6YIITEoTKuuSlg8YWY0C6hcvWdTfC78LMX4MclC+NU2 Jz1uz6I1GjU= =B5Ze -----END PGP SIGNATURE----- From barry at python.org Fri May 4 15:30:45 2007 From: barry at python.org (Barry Warsaw) Date: Fri, 4 May 2007 09:30:45 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <20070504014525.GA1213@andrew-kuchlings-computer.local> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <1178203057.2688.22.camel@junko.usersys.redhat.com> <8C192910-011F-4FFF-85DF-1B6B825EB0AE@latchkey.com> <20070504014525.GA1213@andrew-kuchlings-computer.local> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 3, 2007, at 9:45 PM, A.M. Kuchling wrote: > On Thu, May 03, 2007 at 08:50:16AM -0700, Jon Scott Stevens wrote: >> http://en.wikipedia.org/wiki/SVK > > What about SVK's speed, though? > > There was discussion of providing a DVCS mirror of the Python SVN, so > I tried at making a copy of the repository via SVK, and SVK looked > like it was going to be painfully slow; I calculated something like 13 > hours to create the initial mirror (but I killed it after an hour, > so that's an estimate). > > Python has about 55,000 revisions, so mirroring is obviously a big > job, but that seems unusably slow. Maybe Mailman is small enough to > take a more reasonable time. Mailman is currently at revision 8197. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRjs1hXEjvBPtnXfVAQLmNQQAnT4nozIYUL9bPmNBB/7fb25Cb1UBTiKg fy8pXFYZRhBegl1Cdg24q+h4d7IZXAzTslTHhaE0J9yPBiKoslovpBX50EMrE8I6 0iYZqjO39O1aAag3nvWTw1QhDCGBH6+4ukjg/XDL2XQIrJwlkNPq+jyJp3tX0mp6 hZcypTuPmAI= =A0Za -----END PGP SIGNATURE----- From barry at python.org Fri May 4 15:35:25 2007 From: barry at python.org (Barry Warsaw) Date: Fri, 4 May 2007 09:35:25 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <463A9D87.1040302@mindlace.net> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <2D08881F-A227-47B2-B241-5EE0BDFAD9B1@python.org> <463A9D87.1040302@mindlace.net> Message-ID: <5F896568-A6BA-40D8-89A0-6F024C52AD6E@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 3, 2007, at 10:42 PM, Ethan Fremen wrote: > Barry Warsaw wrote: > >> Of course, I think it /will/ make our lives harder in some ways. As >> we've seen, folks like cPanel have their own forks that they modify, >> and then their users come looking to us for support, which we can't >> give them. Having more public branches out there will increase our >> support costs. > > I would submit that much of what has caused people in the Mailman > community to maintain their own forks is because the software > design is > insufficiently open, not so much on account of checkin privileges. It's both I think, and they're related. The link is the FSF copyright assignment requirement, but that is a can of worms I really don't want to open up right now. My hope is that a dvcs will allow us to break that link and let innovation occur independently of the legal impositions. > Moving Mailman development to distributed trees will force, I suspect, > more modularization and extensibility of the code, which will > reduce the > need for long-lived, independent forks. Modularization is a very high priority for me in the next release. > Basically, I suspect that while it might increase support issues in > the > short term, it will ultimately reduce the support-to-participant > ratio. That's my hope too. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRjs2nnEjvBPtnXfVAQIiUgP9GgqTRLbD/cxYQ/bv/0FLbHxbGFiUBBPw StxUjn7Yo9smnv2V/ek3eEeB3ygyBNREYE08Jwj488jBIdVerGZmKxOpMxlg4H4i Q0/HwmnX/n45+zOYGidYgfJdjCeELnC4JUabuqRoI21z1N4kbkX49l5geueJ+Mcs cAjKbQcPYE0= =Jr3C -----END PGP SIGNATURE----- From barry at python.org Fri May 4 15:41:11 2007 From: barry at python.org (Barry Warsaw) Date: Fri, 4 May 2007 09:41:11 -0400 Subject: [Mailman-Developers] alioth.debian.org and mercurial (was: Re: Should we move to Bazaar?) In-Reply-To: <20070504120207.GH8834@banach.uvt.nl> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <18450C07-EF3F-4B24-8713-ECA79BFC3EB2@python.org> <20070504120207.GH8834@banach.uvt.nl> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 4, 2007, at 8:02 AM, Joost van Baal wrote: > Hi, > > On Thu, May 03, 2007 at 11:16:57AM -0400, Barry Warsaw wrote: > >> Alioth > > See http://wiki.debian.org/Alioth and > https://alioth.debian.org/projects/siteadmin/ for information about > this > service. > >> is for Debian only, right? > > "Any free software project where a Debian Developer is involved is > fine." > >> Would they host Mercurial branches for other FLOSS software like >> Mailman? > > "The hg.debian.org admins will create a directory named > /srv/hg.debian.org/hg/project-name owned by your project group which > will be accessible by hg ssh or http for read-only access. > Within that directory, you can hg init/clone/whatever as many > branches/repos as you like." > > Of course, other hosting offerings might be more suitable. Thanks for the info Joost. We're really pretty independent of Debian, though I think they'd probably give us branch hosting if we asked. It's an option. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRjs393EjvBPtnXfVAQJS+gQAnE+31h9OsNM9HpWekFvwmoUME2/7Iv7E vLaFa5EBOvVcOR32Yy6a8hCSYM25oc2PXXP7VwPCalQXixfmTKiX5/5ThgKrXEfY VwD8NIeD03tplhebRzdGsqoJ4FvAZ0w+NAd8DEjOPIhMneY5OQp0DzamjxbNk+Qi HZYo2Gg9PxE= =K+rf -----END PGP SIGNATURE----- From barry at python.org Fri May 4 16:02:32 2007 From: barry at python.org (Barry Warsaw) Date: Fri, 4 May 2007 10:02:32 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <8C192910-011F-4FFF-85DF-1B6B825EB0AE@latchkey.com> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <1178203057.2688.22.camel@junko.usersys.redhat.com> <8C192910-011F-4FFF-85DF-1B6B825EB0AE@latchkey.com> Message-ID: <4A2FBD5B-B1AC-4377-B8DA-96E79C143EC5@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On the Mercurial front, last night I tried to use yasvn2hg to convert the Mailman repository to hg. The conversion failed however: Error: could not classify changeset 102 I haven't had time to try some of the other conversion scripts. I'd bet this problem is related to the way SF did the original cvs to svn conversion. 'svn log -r102' is unhelpful and 'svn diff -r102' produces gobnormous amounts of output (537k lines). It looks like a revision that copied things from the trunk to the Release_2_1-maint branch. To be honest, I haven't tried the bzr conversion, but I know that at one point (way before I joined Canonical) it was done successfully. The current Launchpad branches are using the old SF urls and are out of date, but I'm getting that fixed. Is anybody interested in trying to complete the Mercurial conversion? I can make a bz2-tarball of the svn repository available if you want to give it a shot. It's about 87MB. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRjs8+HEjvBPtnXfVAQLkgwQApstdKvV5b26btKiEwWlHFnM9j1IlqTw1 Hg1HZlKl/A8bm6ae4FKk5w4hsu7iJOzZBWT7zWCrBko2jP6RlbUL+ZjMMlCsS+W3 Kq5FtC5Cb+Tg1GHomFTNcOpzTq7gdavFdxXpm108lg9eOzoGPgQaXaIc6BZcf9ej XB7GxUqhVy0= =NlBu -----END PGP SIGNATURE----- From stephen at xemacs.org Fri May 4 20:18:58 2007 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 05 May 2007 03:18:58 +0900 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <0220F631-2F50-4765-9751-8D28102FD5F5@python.org> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <1178203057.2688.22.camel@junko.usersys.redhat.com> <877irpg80e.fsf@uwakimon.sk.tsukuba.ac.jp> <0220F631-2F50-4765-9751-8D28102FD5F5@python.org> Message-ID: <87d51ge9kd.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > So my take away from this is that while a conversion would be / > possible/ it's not completely seamless or automatic. If we choose > wrong, we'll suffer some pain, but we'll recover. ;) Would you say > that's accurate? I could live with that. I really doubt we'd suffer much pain, since current capabilities are so similar. But my experience with Tailor is that it's not perfect, there is some risk depending on the quality of the adapters to the VCSes in question. For example, CVS will give you user names for committers, while modern systems use fullname-email pairs. You'd like to automatically convert (this is not rocket science ...), but Tailor currently gives no way to feed in a dictionary. I mentioned that git gives you the distinction between committer and author (if you have Linus's legal problems, you might care, no?) That kind of thing. What you won't have a problem with is commit-is-transaction semantics. The version graph of the project will be preserved intact. That should be good enough. From stephen at xemacs.org Fri May 4 20:21:52 2007 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 05 May 2007 03:21:52 +0900 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <4A2FBD5B-B1AC-4377-B8DA-96E79C143EC5@python.org> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <1178203057.2688.22.camel@junko.usersys.redhat.com> <8C192910-011F-4FFF-85DF-1B6B825EB0AE@latchkey.com> <4A2FBD5B-B1AC-4377-B8DA-96E79C143EC5@python.org> Message-ID: <87bqh0e9fj.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > Is anybody interested in trying to complete the Mercurial > conversion? I can make a bz2-tarball of the svn repository available > if you want to give it a shot. It's about 87MB. I'll take svn2hg via Tailor, since that's what I'm using anyway for XEmacs. From stephen at xemacs.org Fri May 4 21:57:44 2007 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 05 May 2007 04:57:44 +0900 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <02BA9388-7493-425B-B5B6-D540D708B56E@python.org> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <1178203057.2688.22.camel@junko.usersys.redhat.com> <8C192910-011F-4FFF-85DF-1B6B825EB0AE@latchkey.com> <02BA9388-7493-425B-B5B6-D540D708B56E@python.org> Message-ID: <87abwke4zr.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > On May 3, 2007, at 11:50 AM, Jon Scott Stevens wrote: > > #1. *everyone* knows how to use it and almost all OSS software > > projects use it. You could say the same for Microsoft Windows. But not for svk. svk apparently uses an idiosyncratic notation, not horrible or anything, but not the same as svn either. > > #2. The subversion developers are *awesome*. I used to work with them > > at CollabNet and know them personally. Very smart great guys. And (at least as of 8 months ago) still making no moves in the direction of implementing lightweight branch and merge operations. > > #3. SVK solves the problems that you are talking about. Does it? I browsed the svk site trying to find something like Martin Poole's design notes for bzr or hg's design whitepaper or git(7) or Darc's Theory of Patches appendix. Most of the stuff that would be relevant to the problems Barry describes comes under links that point to empty or nonexistent pages. :-( The book apparently has not been worked on since mid-November. http://svkbook.elixus.org/nightly/en/svk-book.html If the documentation is any indication, svk cannot be considered mature. The article at perl.com is useful overview though: http://www.perl.com/pub/a/2004/03/03/svk.html. > > #4. It would allow you to host your source code on code.google.com > > for free and be able to have the benefits of taking advantage of > > google's infrastructure. > Does svk solve some of svn's problems? > > - - The need to use svnmerge or similar tool so that revisions in > different branches don't merge multiple times svk claims to implement some of the advanced merges pioneered by Tom Lord in Arch. That would go a long way (the same algorithms are implemented in bzr, of course). However, choice of merge strategy in Arch is a black art. > - - The need to sometimes commit changes before you're ready (i.e. > double moves) > - - Inexplicable errors with cryptic error messages > - - Inability to merge across renames > - - True nested branches (svn:externals is broken). > share. I'm skeptical that svk will substantially improve the > development model over svn, but maybe I'm just guilty of a greener > pastures mentality. You'd need somebody who uses it heavily to say. But the home page talks the talk; it could be equivalent to bzr on that front (up to a point; the theory on that wiki is all by reference to Tom Lord and Martin Poole and David Roundy). Does it walk the walk? I also don't see a lot about how to use svk in a distributed project. It seems like the author is normally the only user of his repositories; he just didn't want to be tied to a central server. (That's probably not true, but the documentation reads that way.) And, dare I mention that svk is a Perl application? > >> Branches in Bazaar are cheap, unlike in Subversion. > > > > I'm really sorry Barry, but that's just plain untrue. Read this: > > > > http://svnbook.red-bean.com/en/1.0/ch04s02.html > > "Cheap Copies" > > It's not the same thing. svn cp is pretty heavyweight compared to > bzr branch. To have an svn branch revision controlled it has to be > committed back to the server and that's what makes it so heavy. With > bzr (and I'm assuming hg), you can branch locally 'til the cows come > home, That's right. In my integration workspace maintained under git, I basically branch for *every* commit back to the XEmacs CVS, and delete the branch when I see the commit notice. In my sandbox, I have about 75 branches. I branch for reviewing others' patches, I branch for typo fixes that can be pushed to mainline immediately. I switch branches when I fix typos while working on larger tasks, then switch back and pull the typo. I cannot imagine doing that in CVS or Subversion, nor have I yet seen a ViewCVS of an svn repo that looks like that. But Arch (tla or bzr), git, and hg repos all have more branches than a centipede has legs, at least for active projects. It's possible that svk could support that style, though, since it is decentralized. The other question about svn/svk is does it have a rebase operation? ("Rebase" is from git; it's called "tla update" in Arch, probably the same in bzr, "patch commutation" in Darcs.) That is, suppose you have a revision graph A --> B --> C mainline \ \-> D --> E experiment Can it be transformed to A --> B --> C mainline \ \-> D --> E experiment when you realize that "experiment" is not ready for immediate merge? Or to A --> B --> C mainline \ \-> D --> E experiment if you know that E conflicts with C (either textually, or because they're different ways to implement the same change)? That's really a more important operation to distributed development than starmerge (unless you're Linus), because it is the fundamental operation for non-core developers producing the occasional patch or perhaps a single, long-lived variant (think Richard Barrett's MHonArc patch). To be honest, since I don't know svk, I can't deprecate it as an app. I don't see any indication that it's an improvement over bzr or hg. OTOH, the documentation is poor compared to bzr or hg. Bottom line: if you can find a champion for it, who will go the distance to support Mailman using it, it might be a choice worth considering. But without a champion, no need to go out of your way IMO. From jrhett at netconsonance.com Fri May 4 21:39:46 2007 From: jrhett at netconsonance.com (Jo Rhett) Date: Fri, 4 May 2007 12:39:46 -0700 Subject: [Mailman-Developers] status of backscatter prevention? Message-ID: <787D93EA-87C4-4C16-8B17-8D1E104E1324@netconsonance.com> I remember a number of threads about backscatter prevention, but I don't remember the result. Perusing the archives isn't much more enlightening. Where are we on this? In particular, other than removing all but one of the aliases, have we made it easier for people to run a backscatter proof list? Meaning that all subscribe, unsubscribe, etc are done on the web ui and nothing in the server automatically responds to e-mail other than legitimate list mail sent by subscribers? I also remember discussions about honoring SpamAssassin headers to detect spam. Status of this? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From barry at python.org Fri May 4 23:20:34 2007 From: barry at python.org (Barry Warsaw) Date: Fri, 4 May 2007 17:20:34 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <87bqh0e9fj.fsf@uwakimon.sk.tsukuba.ac.jp> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <1178203057.2688.22.camel@junko.usersys.redhat.com> <8C192910-011F-4FFF-85DF-1B6B825EB0AE@latchkey.com> <4A2FBD5B-B1AC-4377-B8DA-96E79C143EC5@python.org> <87bqh0e9fj.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <59B4464C-9AB7-43C2-896F-8AF670738076@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 4, 2007, at 2:21 PM, Stephen J. Turnbull wrote: > Barry Warsaw writes: > >> Is anybody interested in trying to complete the Mercurial >> conversion? I can make a bz2-tarball of the svn repository available >> if you want to give it a shot. It's about 87MB. > > I'll take svn2hg via Tailor, since that's what I'm using anyway for > XEmacs. Cool thanks. To prevent it from getting into the archives, I'll send you the url under separate cover. I'd love to see what you come up with. BTW, I have the answers to hosting questions for Bazaar-on- Launchpad. We can definitely do it, and I'm in the process of getting the branches in the current Mailman project on Launchpad updated. They were using the old SF urls, which no longer work. I'm hoping the branches will be updated by sometime next week. A couple of other points. Permissions would be managed on a team basis. What this means is that the official mainline branch would be owned by a "Mailman Coders" or other special team which I will create. I'll close membership in the team so that only approved devs will have access. We can basically invite all those devs that are still active SF devs to join this team. Any team member will be able to create new branches, push changes, etc. to the team owned filesystem namespace. If you're /not/ a team member, you can still make your own branches. If you're a Launchpad member, you can even host those branches on Launchpad's supermirror, basically by branching from the official mainline branch to your local workspace, then pushing your branches to Launchpad under the filesystem namespace that your user owns. This sounds like it will work great because everyone can start hacking on the code immediately, they can publish branches for the rest of the community by pushing to Launchpad, we core devs can merge in your changes, check them out, etc. but it's up to us to merge them into the mainline and commit them back. An advantage to this is that we only need to verify paperwork for the merge into mainline, and you don't have to worry about it at all unless and until we want to merge your stuff in. It's up to us to verify the paperwork before we merge. (Getting rid of the paperwork requirement is a different matter.) But there's absolutely no obstacle to you maintaining your own branches for interesting work you want to do... and publish. Another nice thing is that we can set up the supermirror to, er, mirror the Subversion trunk, basically giving us a free way to try it out. If we decide to make the switch, we'd simply turn off the mirroring and disable the svn trunk on SF. I propose that no matter which way we go (Mercurial, Bazaar or something else), we convert only the trunk. Let's leave the stable 2.1 branch on SF under Subversion, but do all new development in the dvcs. It will be a bit more painful to commit fixes across both branches (sorry Mark, Tokio!) but that will probably be the case fairly soon anyway, as it's unavoidable that the trunk is going to diverge (<3.0 cough>). For the very short term, your first branch of the mainline, and your first push to a supermirror branch will be rather slow, with the actual time dependent on the speed of your network connection. The problem is that you'll have to pull all the history for 8100+ revisions to your disk the first time, and you will have to push all those revisions back to the supermirror. However, if you put your revs in a bzr repo on your local system (highly recommended), you'll only incur this pain once (and even then, I don't know how painful it will actually be -- we'll have to see). bzr repositories make things really fast, and the supermirror automatically puts things in a repository so subsequent pushes, pulls, and branches can be very fast. I've been told that Launchpad will soon be addressing this by allowing you to "pre-seed" your supermirror branch, and I think, doing something like rsync over the full history the first time. IOW, this initial speed bump will only affect you the first time, and work is actively being done to reduce even this initial speed bump. Let's give Steve a shot at doing the Mercurial conversion. We'll also set up the Launchpad mirror. Then we can do some more real comparisons and make a decision from there. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRjujo3EjvBPtnXfVAQLyHAP8C98v6vcgin7G4xBnuui4pGKAqch4v3EP TORU+PUAiJvepTesJMbAtaz93YIamo+orkkHnnNDgaewqgzguAnbseGPXwMhQ5UP CnlyYnVxU3C794fkfaxiCZ0ucFayOmfWg6k1L5o0EXVB6orBjpa1h3dkXRPK0Dt4 tttC1wGyWJE= =q/CV -----END PGP SIGNATURE----- From barry at python.org Fri May 4 23:54:12 2007 From: barry at python.org (Barry Warsaw) Date: Fri, 4 May 2007 17:54:12 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <87abwke4zr.fsf@uwakimon.sk.tsukuba.ac.jp> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <1178203057.2688.22.camel@junko.usersys.redhat.com> <8C192910-011F-4FFF-85DF-1B6B825EB0AE@latchkey.com> <02BA9388-7493-425B-B5B6-D540D708B56E@python.org> <87abwke4zr.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <0C94562E-B838-40B8-A288-598FCFBDA3DA@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 4, 2007, at 3:57 PM, Stephen J. Turnbull wrote: > That's right. In my integration workspace maintained under git, I > basically branch for *every* commit back to the XEmacs CVS, and delete > the branch when I see the commit notice. In my sandbox, I have about > 75 branches. I branch for reviewing others' patches, I branch for > typo fixes that can be pushed to mainline immediately. I switch > branches when I fix typos while working on larger tasks, then switch > back and pull the typo. I do the same thing. It's really a fundamentally different way to think about developing software, IME. Since CVS we're so conditioned to the weight of branches that this is a really liberating enlightenment. > I cannot imagine doing that in CVS or Subversion, nor have I yet seen > a ViewCVS of an svn repo that looks like that. But Arch (tla or bzr), > git, and hg repos all have more branches than a centipede has legs, at > least for active projects. It's possible that svk could support that > style, though, since it is decentralized. > > The other question about svn/svk is does it have a rebase operation? > ("Rebase" is from git; it's called "tla update" in Arch, probably the > same in bzr, "patch commutation" in Darcs.) That is, suppose you have > a revision graph > > A --> B --> C mainline > \ > \-> D --> E experiment > > Can it be transformed to > > A --> B --> C mainline > \ > \-> D --> E experiment > > when you realize that "experiment" is not ready for immediate merge? > Or to > > A --> B --> C mainline > \ > \-> D --> E experiment > > if you know that E conflicts with C (either textually, or because > they're different ways to implement the same change)? I've not needed to do this yet, but I can see where it would be a very useful feature to have. Here's what the www.bazaar-vcs.org pages have to say about it. From http://bazaar-vcs.org/ShowStoppers/Samba A rebase plugin would be very nice, with a rebase-push command. It should be used in combination with bound branches. The rebase-push command should try to rollback local commits, then pull all new revisions from the master branch and recommit to the master branch one by one. And then pull the new commits back to the local branch. Maybe a rebase-pull command would do the same but not directly push the local changes, but instead recommit locally. This features seems to be related to patch reordering, patch refactoring and a bzr sync- trees command. See also http://www.kernel.org/pub/software/scm/git/ docs/git-rebase.html. The rebase feature should be only used on integration branches with unrelated patches, so that they don't appear as one big merge revision in the master branch. For feature specific branches normal 'merge --pull' and a final 'push' should be used. > That's really a more important operation to distributed development > than starmerge (unless you're Linus), because it is the fundamental > operation for non-core developers producing the occasional patch or > perhaps a single, long-lived variant (think Richard Barrett's MHonArc > patch). I do something similar all the time, but generally what I do is branch a local "pristine" branch off the mainline branch, then all my dev branches are branches off of pristine. When I need to pull the mainline into a dev branch, I 'bzr pull' the pristine branch to get the tip of mainline, then I merge & commit in any dev branch that I want to rebase to the tip. I've not needed to rebase to anything other than the tip (though I do occasionally have to resolve conflicts of course), but I could imagine that'd be doable by manually specifying a revision to branch from. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRjurhXEjvBPtnXfVAQKpWQP/ctmR9pNJqCj4vRJ9jWNltPVvvBpnpUqf Sc0FWtGa3KYdgxsGIMmhXtcusfmUOcu7oeoaFsU3GG3npDbDi6p6SOy5XajjWOla 2DMDNwD7FJTZOW4kKx6ghF7YDDdm1LfMJlGJi6NMQX5h0W++WAOTYrqEOy/rXej4 tC8ff0hKLyo= =Rx3Z -----END PGP SIGNATURE----- From msapiro at value.net Sat May 5 01:05:37 2007 From: msapiro at value.net (Mark Sapiro) Date: Fri, 4 May 2007 16:05:37 -0700 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <59B4464C-9AB7-43C2-896F-8AF670738076@python.org> Message-ID: Barry Warsaw wrote: > >I propose that no matter which way we go (Mercurial, Bazaar or >something else), we convert only the trunk. Let's leave the stable >2.1 branch on SF under Subversion, but do all new development in the >dvcs. It will be a bit more painful to commit fixes across both >branches (sorry Mark, Tokio!) but that will probably be the case >fairly soon anyway, as it's unavoidable that the trunk is going to >diverge (<3.0 cough>). I'm just now trying to catch up on this thread. Mostly, I have nothing to contribute because I have no experience with any dvcs. That said, for me personally, I don't mind learning something new. It's one of the underlying reasons why I'm here in the first place. And while its always nice to have a pain free way to get from A to B, the pain can be managed if B is a clear improvement. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From stephen at xemacs.org Sat May 5 04:18:52 2007 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 05 May 2007 11:18:52 +0900 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <59B4464C-9AB7-43C2-896F-8AF670738076@python.org> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <1178203057.2688.22.camel@junko.usersys.redhat.com> <8C192910-011F-4FFF-85DF-1B6B825EB0AE@latchkey.com> <4A2FBD5B-B1AC-4377-B8DA-96E79C143EC5@python.org> <87bqh0e9fj.fsf@uwakimon.sk.tsukuba.ac.jp> <59B4464C-9AB7-43C2-896F-8AF670738076@python.org> Message-ID: <877irodncj.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > I propose that no matter which way we go (Mercurial, Bazaar or > something else), we convert only the trunk. Let's leave the stable > 2.1 branch on SF under Subversion, but do all new development in the > dvcs. Why not do both? That is, if Tailor does its thing well, we can cheaply have a dvcs mirror auto-synced to the svn 2.1 branch. If Mark and Tokio *both* agree, then we can abandon the svn branch. *Until* they do agree, people submit patches to the tracker as usual. I predict they'll get used to the "pull the 'this-patch' branch from my repo @ URL" style right quick, though. From tkikuchi at is.kochi-u.ac.jp Sat May 5 08:17:09 2007 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sat, 05 May 2007 15:17:09 +0900 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: References: Message-ID: <463C2165.4000304@is.kochi-u.ac.jp> Hi all, Sorry that I can't say anything nice on this thread but my feelings on this distributed somthing :-P is just the same as Mark's. Currently, I am extremely busy on everyday duties and difficult to find time to code. I will be able to spare more time for mailman when the cemester ends in July. I will catch up any change in the version control system then. So please feel free to select anything better. Mark Sapiro wote: > Barry Warsaw wrote: >> I propose that no matter which way we go (Mercurial, Bazaar or >> something else), we convert only the trunk. Let's leave the stable >> 2.1 branch on SF under Subversion, but do all new development in the >> dvcs. It will be a bit more painful to commit fixes across both >> branches (sorry Mark, Tokio!) but that will probably be the case >> fairly soon anyway, as it's unavoidable that the trunk is going to >> diverge (<3.0 cough>). > > > I'm just now trying to catch up on this thread. Mostly, I have nothing > to contribute because I have no experience with any dvcs. > > That said, for me personally, I don't mind learning something new. It's > one of the underlying reasons why I'm here in the first place. And > while its always nice to have a pain free way to get from A to B, the > pain can be managed if B is a clear improvement. > -- Tokio Kikuchi, tkikuchi at is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From terri at zone12.com Sat May 5 10:08:11 2007 From: terri at zone12.com (Terri Oda) Date: Sat, 5 May 2007 04:08:11 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4-May-07, at 7:05 PM, Mark Sapiro wrote: > I'm just now trying to catch up on this thread. Mostly, I have nothing > to contribute because I have no experience with any dvcs. > > That said, for me personally, I don't mind learning something new. I, like Mark, have little to say about dvcs (I've only passingly used Bazaar) but I'm happy to learn whatever I need to know. However, I would like to say that I hope this discussion doesn't dissuade people from doing that UI work right now. Please please please don't wait on this, 'cause if we wait for the Next Big Thing we're going to wind up with no updated UI, once again. Not that I'm a cynic. ;) Terri (who, uh, maybe, might sorta have some unfinished admin documentation that got left alone 'cause it seemed like MM3 had to be just around the corner... three years ago. ;) ) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGPDtxYWvHDqWmQaoRAh7yAKDOgK/6+kTNV9cV/RQJGJAP2XTJTACfWBhJ qMsOaY8S/RzQ8zgZ2mt0gh4= =7012 -----END PGP SIGNATURE----- From terri at zone12.com Sat May 5 17:24:27 2007 From: terri at zone12.com (Terri Oda) Date: Sat, 5 May 2007 11:24:27 -0400 Subject: [Mailman-Developers] Styling patch In-Reply-To: <20070504010318.GA949@andrew-kuchlings-computer.local> References: <20070504010318.GA949@andrew-kuchlings-computer.local> Message-ID: <6610B350-207C-4E38-AD13-F90F1F269102@zone12.com> On 3-May-07, at 9:03 PM, A.M. Kuchling wrote: > Patch #1415956 from Bryan Carbonnell adds CSS for styling purposes and > changes the HTML to be valid XHTML1.0. It still needs some tidying > up, and it still uses tables for layout, but that patch takes us > halfway there. It does look very promising! I'm a big fan of going to XHTML, and given that it sounds like some of the templating systems are going to want clean, closed tags, this seems like the best way of keeping our options open while still moving forwards. > It presents one big compatibility issue that will probably need to be > fixed. The patch removes the colour settings (WEB_HEADER_COLOR, > WEB_ERROR_COLOR, WEB_ADMINITEM_COLOR, etc.) and replaces them with > CSS class declarations. > > It's probably unacceptable to break the use of these settings, so > there needs to be some compatibility fix. Colours could be > substituted into the .css file somehow, or a 'style' attribute could > be added as well as a 'class' attribute. Does anyone have suggestions > for what to do? Some thoughts with positive (+) and negative (-) notes: Have the CSS generated by a CGI (which could then use these variables if they're available). - extra processing for each web request + could lay groundwork to make it possible to change settings on a per-list (or per virt-domain) basis rather than site-wide. Use a Makefile to generate the CSS once from this file (and leave note in file saying that further config is in CSS) + processing happens once - can't be applied easily as a patch, requires an actual rebuild to take effect Use a "style" attribute as well as a "class" one: + might make conversion from one type of settings to another easier - just going to look inexplicable and hackish later, potentially make it more awkward to do CSS-only skins Not clear to me what would be best just yet... Terri From turnbull at sk.tsukuba.ac.jp Sat May 5 18:49:22 2007 From: turnbull at sk.tsukuba.ac.jp (Stephen J. Turnbull) Date: Sun, 06 May 2007 01:49:22 +0900 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <59B4464C-9AB7-43C2-896F-8AF670738076@python.org> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <1178203057.2688.22.camel@junko.usersys.redhat.com> <8C192910-011F-4FFF-85DF-1B6B825EB0AE@latchkey.com> <4A2FBD5B-B1AC-4377-B8DA-96E79C143EC5@python.org> <87bqh0e9fj.fsf@uwakimon.sk.tsukuba.ac.jp> <59B4464C-9AB7-43C2-896F-8AF670738076@python.org> Message-ID: <87odkzcj1p.fsf@uwakimon.sk.tsukuba.ac.jp> [Mike -- I'll get back to you on this, but wanted make sure I pinged you before I forget ....] Barry Warsaw writes: > On May 4, 2007, at 2:21 PM, Stephen J. Turnbull wrote: > > I'll take svn2hg via Tailor, since that's what I'm using anyway for > > XEmacs. > > Cool thanks. I'd love to see what you come up with. OK, I'm 20% through (~svn rev 1500) and it's after 1am, and tomorrow's Sunday/family day, so I'm going to jump the gun a bit and hope it does finish and give me a repo. Report: I'm now a lot less happy with Mercurial than I was a day ago. 1. Mercurial tracks only files directly, and represents directories in metadata somehow, apparently ad hoc, and buggily. Operations it handles fine with files cause exceptions leading to abort with directories. 2. This resulted in a situation (at svn rev 745) where the mailman/cgi directory was removed. hg proceeded to throw a mercurial.util.Abort exception when asked to commit the deletion to the repo, the exception propagated back up to tailor, which then does abort. I worked around by trapping that particular case and assuming that any Abort at that point was due to file not found. 3. In the process of analyzing and patching, it became apparent that Mercurial basically just terminates on such unexpected conditions, because Abort was the only exception I found in use! (Granted, this is pretty high-level/ui-oriented stuff, the module is called commands.py. In a UI asking the user to try again is not that unreasonable.) Worse, the Abort exception takes an error message as an attribute, but translates it via gettext *at initialization*! So there's no way to reliably catch these exceptions, differentiating on the error message. :-( 4. Tailor logs the svn log message, but the Mercurial repo's "short summaries" just cite the svn rev no. It's possible to get the whole commit message with "hg log -v", but this basically makes the short summary useless. More hacking needed .... Mercurial still seems like a fine dvcs---obviously these problems don't affect ordinary use. But it would seem risky to extensible or embed. (BTW, it's 1:36 and I'm up to rev 3890, about halfway. Go, Tailor, go!) ?Buenas noches! From i at mindlace.net Sat May 5 18:54:28 2007 From: i at mindlace.net (Ethan Fremen) Date: Sat, 05 May 2007 12:54:28 -0400 Subject: [Mailman-Developers] Templating the interface In-Reply-To: <98F5AA3E-2B7F-4CA5-A014-BB27C812B5D1@python.org> References: <8E6BD654-48E6-4F59-A684-34636BEAFAFE@python.org> <4637611C.4090400@mindlace.net> <4637AE89.6010902@insectnation.org> <98F5AA3E-2B7F-4CA5-A014-BB27C812B5D1@python.org> Message-ID: <463CB6C4.6000105@mindlace.net> Barry Warsaw wrote: >> Genshi has been mentioned a few times. My impression was that it >> insists >> on producing valid XML output, which is nice, but doesn't necessarily >> play well with ideas like factorisable head/foot portions. It doesn't; it has an HTML output mode. Yes, you should have a combined header and footer, but that's not a big obstacle to factoring. >> be used for templating the automated email messages, i.e. plain text >> rather than XML? Genshi can be used to generate plain text, yes. > Please keep it on-list. I'm interested in the discussion too! I > forgot to mention Cheetah -- Ethan, did you play with it at one point? I don't care for cheetah because it's another one of those php-style markup approaches. Genshi is really the best templating there is for Python right now, imo; I would be reluctant to use anything else. ~ethan From mads at kiilerich.com Sat May 5 21:03:04 2007 From: mads at kiilerich.com (Mads Kiilerich) Date: Sat, 05 May 2007 21:03:04 +0200 Subject: [Mailman-Developers] Styling patch In-Reply-To: <6610B350-207C-4E38-AD13-F90F1F269102@zone12.com> References: <20070504010318.GA949@andrew-kuchlings-computer.local> <6610B350-207C-4E38-AD13-F90F1F269102@zone12.com> Message-ID: <463CD4E8.9050009@kiilerich.com> Terri Oda wrote, On 05/05/2007 05:24 PM: >> It presents one big compatibility issue that will probably need to be >> fixed. The patch removes the colour settings (WEB_HEADER_COLOR, >> WEB_ERROR_COLOR, WEB_ADMINITEM_COLOR, etc.) and replaces them with >> CSS class declarations. >> >> It's probably unacceptable to break the use of these settings, so >> there needs to be some compatibility fix. Colours could be >> substituted into the .css file somehow, or a 'style' attribute could >> be added as well as a 'class' attribute. Does anyone have suggestions >> for what to do? >> > > Some thoughts with positive (+) and negative (-) notes: > > Have the CSS generated by a CGI (which could then use these variables > if they're available). > - extra processing for each web request > + could lay groundwork to make it possible to change settings on a > per-list (or per virt-domain) basis rather than site-wide. > Perhaps that part of the CSS could be included inline in the already cgi-generated html header. It will probably only be a couple of lines. If placed before inclusion of custom css then customizers can override it if they want to. (That would be very close to how it is done in Plone.) IMHO that addresses the only minus of this solution. Just a thought... /Mads From amk at amk.ca Sat May 5 22:57:11 2007 From: amk at amk.ca (A.M. Kuchling) Date: Sat, 5 May 2007 16:57:11 -0400 Subject: [Mailman-Developers] Styling patch In-Reply-To: <6610B350-207C-4E38-AD13-F90F1F269102@zone12.com> References: <20070504010318.GA949@andrew-kuchlings-computer.local> <6610B350-207C-4E38-AD13-F90F1F269102@zone12.com> Message-ID: <20070505205711.GB1571@andrew-kuchlings-computer.local> On Sat, May 05, 2007 at 11:24:27AM -0400, Terri Oda wrote: > Have the CSS generated by a CGI (which could then use these variables > if they're available). > - extra processing for each web request > + could lay groundwork to make it possible to change settings on a > per-list (or per virt-domain) basis rather than site-wide. The extra processing may not be too bad if we set an Expires: header on the CSS output. I imagine most crawlers, well- or badly-behaved, don't crawl the stylesheet linked from HTML pages. > Use a Makefile to generate the CSS once from this file (and leave > note in file saying that further config is in CSS) > + processing happens once > - can't be applied easily as a patch, requires an actual rebuild to > take effect I don't think this choice would work very well; requiring a rebuild would break backward compatibility. I don't know if that breakage would be OK for Mailman 2.2 or 3, but it's surely off-limits for a 2.1 point-release. > Use a "style" attribute as well as a "class" one: > + might make conversion from one type of settings to another easier > - just going to look inexplicable and hackish later, potentially make > it more awkward to do CSS-only skins - May also make the Python code messier; instead of generating a div or span with a class attribute, it will need to generate a style attribute as well. + On the other hand, we could skip generating the style attribute if the corresponding mm_cfg setting is None. That provides a nice path for people to switch from setting colours in mm_cfg to providing their own custom CSS. Either the first or third choice would work for me. I'd be inclined to try #3 first and see how well it works; maybe it's not that messy in practice. --amk From i at mindlace.net Sun May 6 01:44:29 2007 From: i at mindlace.net (Ethan Fremen) Date: Sat, 05 May 2007 19:44:29 -0400 Subject: [Mailman-Developers] Styling patch In-Reply-To: <20070505205711.GB1571@andrew-kuchlings-computer.local> References: <20070504010318.GA949@andrew-kuchlings-computer.local> <6610B350-207C-4E38-AD13-F90F1F269102@zone12.com> <20070505205711.GB1571@andrew-kuchlings-computer.local> Message-ID: <463D16DD.4050205@mindlace.net> A.M. Kuchling wrote: > On Sat, May 05, 2007 at 11:24:27AM -0400, Terri Oda wrote: >> Have the CSS generated by a CGI (which could then use these variables >> if they're available). >> - extra processing for each web request >> + could lay groundwork to make it possible to change settings on a >> per-list (or per virt-domain) basis rather than site-wide. > > The extra processing may not be too bad if we set an Expires: header > on the CSS output. I imagine most crawlers, well- or badly-behaved, > don't crawl the stylesheet linked from HTML pages. I do not think this is a good idea. It is better to have a CSS file that just declares the colors and then use those definitions elsewhere. Backward compatibility would involve reading the color definitions from mm_cfg, deleting them from the config, and writing them into the css file. There are very few good reasons to put dynamic markup in CSS. Designers are very comfortable with CSS files. Having to edit a python file to set colors is very much out of their comfort zone. It is possible to have multiple classes per element, eg class="aLegacyClass aClass". This has excellent support across browsers. Changing this list dynamically is the best way to change styles "in code". Any time we need multiple style-states for one element, we should have multiple classes. If the set of states exceeds that which should reasonably be typed out - like the location if one is allowing dynamic dragging- then the style manipulations should be achieved by javascript that may be partially dynamically generated or better by static javascript that gets whatever server data it needs via JSON. >> Use a "style" attribute as well as a "class" one: We should never use the style attribute if we can at all avoid it, as there is no (easy) way for a CSS stylesheet to override the style attribute. The exception is manipulating element.style in javascript. ~ethan From stephen at xemacs.org Sun May 6 11:00:57 2007 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sun, 06 May 2007 18:00:57 +0900 Subject: [Mailman-Developers] Styling patch In-Reply-To: <20070505205711.GB1571@andrew-kuchlings-computer.local> References: <20070504010318.GA949@andrew-kuchlings-computer.local> <6610B350-207C-4E38-AD13-F90F1F269102@zone12.com> <20070505205711.GB1571@andrew-kuchlings-computer.local> Message-ID: <87lkg2comu.fsf@uwakimon.sk.tsukuba.ac.jp> A.M. Kuchling writes: > I don't think this choice would work very well; requiring a rebuild > would break backward compatibility. I don't know if that breakage > would be OK for Mailman 2.2 or 3, but it's surely off-limits for a 2.1 > point-release. Going to CSS at all is presumably off-limits for a 2.1 release. I think it would be a very bad idea to constrain the design to be backwards compatible to a non-CSS solution, but not doing so is unfair to people who expect a 2.1 release to be a 2.1 release. IMO, the point of doing the CSS branch off of 2.1 is so that people who want to experiment with CSS but aren't core Mailman developers can avoid working with experimental distribution code. Sorta like you don't have the plastic surgeon doing a facelift while the orthopedic guy is slicing into your knee. But hoping for a 2.1 release with CSS is just dreaming. > Terri Oda writes: > > Use a "style" attribute as well as a "class" one: > > + might make conversion from one type of settings to another easier > > - just going to look inexplicable and hackish later, potentially make > > it more awkward to do CSS-only skins -1. This is precisely the kind of thing we need to avoid at all costs. You aren't going to decrease the pain of deprecating colors- in-mm_cfg.py by postponing it, so may as well release CSS-only as 2.2 as soon as CSS is ready for release (and have at least one more 2.1 release for those who aren't ready to go to 2.2). In the transition, I think that we should definitely use the cascade. The multiple class method that Ethan describes is a good way to provide a deprecation path over time as the code matures, although I wonder if it's even necessary. In a different dimension, we probably should have a mailman.css analogous to Defaults.py. Site and list admins never touch this. Then there would be a site.css, analogous to mm_cfg.py, and finally a $list.css for each list, in order of increasing preference. For the sake of virtual hosts, site.css should either be kept in a site-specific folder, or given a site-specific name. As Ethan points out, these should be "real" files, not inline CSS in the HEAD element generated by the cgi. It should be possible to generate simple site and list stylesheets (eg, changing colors) for the default templates through-the-web, but designers will want to deal with CSS, not Python code. Note that with a little care, the same module that does the t-t-w CSS generation could probably accept an mm_cfg.py and (a) use the variables defined in mm_cfg.py to generate site.css and (b) remove them (warning loudly that setting them in the future will have no effect). Finally, we could have a check_config script analogous to check_perms, but it would examine mm_cfg.py and the list configs, looking for variables that are deprecated and variables that Mailman doesn't even use, odd values and stuff like that. From mads at kiilerich.com Sun May 6 21:48:04 2007 From: mads at kiilerich.com (Mads Kiilerich) Date: Sun, 06 May 2007 21:48:04 +0200 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <4004CCE4-5752-4802-B09D-724ACDC0DFBC@python.org> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <18450C07-EF3F-4B24-8713-ECA79BFC3EB2@python.org> <463A24BC.1050805@kiilerich.com> <4004CCE4-5752-4802-B09D-724ACDC0DFBC@python.org> Message-ID: <463E30F4.6070104@kiilerich.com> Barry Warsaw wrote, On 05/04/2007 03:28 PM: >> Mr Mercurial might soon come up with an alternative: >> http://marc.info/?l=mercurial&m=117753118122082 > > That could be very interesting. I know that was just a couple of > weeks ago, but have you heard of an eta for such hosting? I asked them and just got a reply from Matt that "hgserve.org now exists", http://selenic.com/pipermail/mercurial/2007-May/013105.html - but I haven't heard any further details yet. /Mads From barry at python.org Mon May 7 17:37:20 2007 From: barry at python.org (Barry Warsaw) Date: Mon, 7 May 2007 11:37:20 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 5, 2007, at 4:08 AM, Terri Oda wrote: > I, like Mark, have little to say about dvcs (I've only passingly used > Bazaar) but I'm happy to learn whatever I need to know. Excellent. I think we have consensus for a switch if/when we find a dvcs we like. > However, I would like to say that I hope this discussion doesn't > dissuade people from doing that UI work right now. Please please > please don't wait on this, 'cause if we wait for the Next Big Thing > we're going to wind up with no updated UI, once again. Not that I'm > a cynic. ;) Here is my current thinking, and I'd like to know what you all think about this. Andrew created the mondernize_21_webui branch and applied the xhtml and css patches to it. We could conceivably keep these changes very conservative, i.e. just u/i and *possibly* the top 3 new features. Then we'd release this as Mailman 2.2 and rename the really advanced work Mailman 3.0. I know I've gone back and forth on all this numbering stuff, but if we try really really really hard to keep our focus, I think we could get out a 2.2 that looks and acts a lot like 2.1 but with a better look and feel, as well as reducing a couple of big pain points. > Terri (who, uh, maybe, might sorta have some unfinished admin > documentation that got left alone 'cause it seemed like MM3 had to be > just around the corner... three years ago. ;) ) Guilty as charged. :) Thoughts? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRj9HsXEjvBPtnXfVAQKHHAP9FHEHpg18wzQk2xXyVOcAKYtS3aDX5//T /R5bEH4bmUOMcfuMUWXrKAq+EXpH9Hi2idSDByxdKcL7z3ePl5OkVuTpjK7czU9H EwB/elDX3VRdqQSH1Yvmgxv0tcxwk5pBXbBvzPBeBZJlfCPPBt57lyJXCFbJoSif UYi1+H3mZ48= =3vSu -----END PGP SIGNATURE----- From barry at python.org Mon May 7 17:39:06 2007 From: barry at python.org (Barry Warsaw) Date: Mon, 7 May 2007 11:39:06 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <87odkzcj1p.fsf@uwakimon.sk.tsukuba.ac.jp> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <1178203057.2688.22.camel@junko.usersys.redhat.com> <8C192910-011F-4FFF-85DF-1B6B825EB0AE@latchkey.com> <4A2FBD5B-B1AC-4377-B8DA-96E79C143EC5@python.org> <87bqh0e9fj.fsf@uwakimon.sk.tsukuba.ac.jp> <59B4464C-9AB7-43C2-896F-8AF670738076@python.org> <87odkzcj1p.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 5, 2007, at 12:49 PM, Stephen J. Turnbull wrote: > I'm now a lot less happy with Mercurial than I was a day ago. Bummer. I'm about to head up to New York City for the day, so just a quick note of thanks for taking a look at this. Once you're done will we be able to get a bzr branch from Tailor or will we have to do another import? Please keep us up to date about how it goes. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRj9IG3EjvBPtnXfVAQKx7QQAgDLOp5xfQrhnpK80/DQr44GBd2GKQRbj RCGajy5hxz+PeTrAKvduAZhd0uG3RjUCdKR0hvYYWIfTipt337rcYV2QxElvAuBT qlXo1b1wfWRadrSARbMUn0Cuvp05pC7NeGsw3HH9tX3fYdjrN7xyHOc1cYVCW7I9 tFGbHdcdtHg= =P467 -----END PGP SIGNATURE----- From barry at python.org Mon May 7 17:41:35 2007 From: barry at python.org (Barry Warsaw) Date: Mon, 7 May 2007 11:41:35 -0400 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: <463E30F4.6070104@kiilerich.com> References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <18450C07-EF3F-4B24-8713-ECA79BFC3EB2@python.org> <463A24BC.1050805@kiilerich.com> <4004CCE4-5752-4802-B09D-724ACDC0DFBC@python.org> <463E30F4.6070104@kiilerich.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 6, 2007, at 3:48 PM, Mads Kiilerich wrote: > Barry Warsaw wrote, On 05/04/2007 03:28 PM: >>> Mr Mercurial might soon come up with an alternative: >>> http://marc.info/?l=mercurial&m=117753118122082 >> >> That could be very interesting. I know that was just a couple of >> weeks ago, but have you heard of an eta for such hosting? > > I asked them and just got a reply from Matt that "hgserve.org now > exists", > http://selenic.com/pipermail/mercurial/2007-May/013105.html - but I > haven't heard any further details yet. Cool, thanks Mads. One of the Launchpad admins is doing a new import of the MM2.1 branch, and possibly the trunk (though that's lower priority). This will not be a full-history import, but it will sync daily with upstream svn. I'll let you know when it's ready so people can play with it. After talking with them, it seems like the best thing to do is, if we decide to switch to bzr, we'll take svn off-line for a bit, do a full- history bzr import, then turn svn on read-only and start to develop all code on bzr. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRj9Ir3EjvBPtnXfVAQL0iwQAtgw5uNFKfbARQWM76Y+oIvmL7wJdgI1E M7PVybyUlL3F2gNsHFsUoOuh/3STrRDyGWno9UKnl2/JGUtEiQgLL+ziAtFopxjQ ff+lQwNs0p5lnwlKp79uwz9uOLPSjQR7ufkcXlKub6gdc/Gso/o0Jc7JXluDVRsn va1NQSKKRBY= =fDH9 -----END PGP SIGNATURE----- From stephen at xemacs.org Tue May 8 05:48:26 2007 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 08 May 2007 12:48:26 +0900 Subject: [Mailman-Developers] Should we move to Bazaar? In-Reply-To: References: <2888B02E-B831-4D0A-987F-DC79EAB9379D@python.org> <87mz0mf4d9.fsf@uwakimon.sk.tsukuba.ac.jp> <1178203057.2688.22.camel@junko.usersys.redhat.com> <8C192910-011F-4FFF-85DF-1B6B825EB0AE@latchkey.com> <4A2FBD5B-B1AC-4377-B8DA-96E79C143EC5@python.org> <87bqh0e9fj.fsf@uwakimon.sk.tsukuba.ac.jp> <59B4464C-9AB7-43C2-896F-8AF670738076@python.org> <87odkzcj1p.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <87r6psasc5.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > On May 5, 2007, at 12:49 PM, Stephen J. Turnbull wrote: > > > I'm now a lot less happy with Mercurial than I was a day ago. > > Bummer. Well, Mike (XEmacs's Mercurial champion) accuses Tailor of abusing the Mercurial APIs. He has a point, although my worries retain some validity, I think. > I'm about to head up to New York City for the day, so just a > quick note of thanks for taking a look at this. Once you're done > will we be able to get a bzr branch from Tailor or will we have to do > another import? I'm not sure what you mean. I don't think it's a good idea to go svn->hg->bzr, if that's what you mean; there's some degradation of metadata in each transition. I'll give a Tailor svn->bzr conversion a shot. Let me know what you want to do about giving "concerned parties" access to them (I presume you don't want them sitting on a Googlable webserver at this point). Please note that no conversion has taken as much as three hours. One svn rev per second seems to be the going rate for all of the conversion tools I've tried, and the initialization from the svn log takes only a few seconds. IOW, I can surely make full imports faster than you can evaluate them. The question will be preserving or injecting desired metadata (eg, sensible summary logs, user id mapping), which for most tools will take some hacking. > Please keep us up to date about how it goes. OK, at this point, I've temporarily given up on Tailor for svn->hg. There's a locking deadlock (I think) in Mercurial at about r7721, and it will take some time to diagnose that. I did get both a full trunk conversion and a "trunk/mailman" only conversion from the hgsvn tool (which is just a one-way sync, svn to hg). hgsvn has the advantage of being a PyPI project. easy_install hgsvn if somebody wants to try. (If you don't have easy_install, you can get it from http://peak.telecommunity.com/DevCenter/EasyInstall.) I also tried Eric Hopper's svn2hg (there are a couple of tools by that name). It looks well-coded, but it's not ready for general use. From acrosman at afsc.org Tue May 8 15:16:30 2007 From: acrosman at afsc.org (Aaron Crosman) Date: Tue, 08 May 2007 09:16:30 -0400 Subject: [Mailman-Developers] Styling patch In-Reply-To: <87lkg2comu.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: On 5/6/07 5:00 AM, "Stephen J. Turnbull" wrote: > A.M. Kuchling writes: > >> I don't think this choice would work very well; requiring a rebuild >> would break backward compatibility. I don't know if that breakage >> would be OK for Mailman 2.2 or 3, but it's surely off-limits for a 2.1 >> point-release. > > Going to CSS at all is presumably off-limits for a 2.1 release. I > think it would be a very bad idea to constrain the design to be > backwards compatible to a non-CSS solution, but not doing so is unfair > to people who expect a 2.1 release to be a 2.1 release. > > IMO, the point of doing the CSS branch off of 2.1 is so that people > who want to experiment with CSS but aren't core Mailman developers can > avoid working with experimental distribution code. Sorta like you > don't have the plastic surgeon doing a facelift while the orthopedic > guy is slicing into your knee. But hoping for a 2.1 release with CSS > is just dreaming. > >> Terri Oda writes: > >>> Use a "style" attribute as well as a "class" one: >>> + might make conversion from one type of settings to another easier >>> - just going to look inexplicable and hackish later, potentially make >>> it more awkward to do CSS-only skins > > -1. This is precisely the kind of thing we need to avoid at all > costs. You aren't going to decrease the pain of deprecating colors- > in-mm_cfg.py by postponing it, so may as well release CSS-only as 2.2 > as soon as CSS is ready for release (and have at least one more 2.1 > release for those who aren't ready to go to 2.2). > > In the transition, I think that we should definitely use the cascade. > The multiple class method that Ethan describes is a good way to > provide a deprecation path over time as the code matures, although I > wonder if it's even necessary. In a different dimension, we probably > should have a mailman.css analogous to Defaults.py. Site and list > admins never touch this. Then there would be a site.css, analogous to > mm_cfg.py, and finally a $list.css for each list, in order of > increasing preference. For the sake of virtual hosts, site.css should > either be kept in a site-specific folder, or given a site-specific > name. > > As Ethan points out, these should be "real" files, not inline CSS in > the HEAD element generated by the cgi. It should be possible to > generate simple site and list stylesheets (eg, changing colors) for > the default templates through-the-web, but designers will want to deal > with CSS, not Python code. Note that with a little care, the same > module that does the t-t-w CSS generation could probably accept an > mm_cfg.py and (a) use the variables defined in mm_cfg.py to generate > site.css and (b) remove them (warning loudly that setting them in the > future will have no effect). > > Finally, we could have a check_config script analogous to check_perms, > but it would examine mm_cfg.py and the list configs, looking for > variables that are deprecated and variables that Mailman doesn't even > use, odd values and stuff like that. In general I agree with Ethan and Stephen, designers want CSS to be in its own file (for good reasons) and don't want to have to work in python or XML files if they don't have to. Since we're concerned about maintaining compatibly with 2.1 users that have modified the templates using the current limited options, we shouldn't do a great deal under 2.1. But I think we can do more in 2.1 than Stephen proposes. If we don't edit the HTML content of the existing pages much, we can attach a CSS file that would allow people to do a great deal to customize their sites without needed to worry about breaking old behaviors. Ethen's ideas about how to handle dynamic setting of classes or style sheets might overcome any conflicts that might occur. Even if we didn't go that far, just linking in an empty style-sheet, or creating an option in mm_cfg.py to link your own in would help some users (the user that started the discussion on mailman-users that in turn sparked this conversation was hoping for a feature of that nature). It would leave people in a very hackish position, but at least they wouldn't have to hack the python to do what they want. Certainly adding something simple like that wouldn't cause problems for exiting 2.1 users that don't want to use it. For 2.2 we could move to better XHTML/CSS design, which would break backward compatibility with old templates. Since it would be a more significant version change that would be acceptable to most people. At that point I think we need to remove all the current python-based settings and move them all into CSS. If we feel the need to have good through the web support I would suggest for mailman 3.0 we build it in a manner similar to the garland theme in Drupal 5 (which provides a color wheel to select the colors, and then generates a CSS file). You can still edit the CSS directly if you'd like, but it'll do any colorization work for you. I'd also suggest that we avoid putting template links into mm_cfg.py settings, rather use a predefined path like mailman currently does. A theme switcher probably doesn't make sense in Mailman, but being able to change a the look and feel just by updating a CSS file would be a big plus (no restarting mailman). It would be easy enough to define a structure that would allow for CSS files for a given list to live in a particular directory. Finally I'd like to suggest we avoid using JavaScript until we absolutely have to (a color picker would require it, other ideas might as well), since there isn't any JS in the code base at the moment, and its introduction will add complexity. Also, we'll probably want to find a good library to work with to help set coding standards and allow for some AJAX calls for some elements. Aaron From barry at python.org Tue May 8 15:47:22 2007 From: barry at python.org (Barry Warsaw) Date: Tue, 8 May 2007 09:47:22 -0400 Subject: [Mailman-Developers] Styling patch In-Reply-To: <20070504010318.GA949@andrew-kuchlings-computer.local> References: <20070504010318.GA949@andrew-kuchlings-computer.local> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 3, 2007, at 9:03 PM, A.M. Kuchling wrote: > It presents one big compatibility issue that will probably need to be > fixed. The patch removes the colour settings (WEB_HEADER_COLOR, > WEB_ERROR_COLOR, WEB_ADMINITEM_COLOR, etc.) and replaces them with > CSS class declarations. If we call the version that gets released with the new u/i "Mailman 2.2" then I don't have a problem breaking this. I don't think we can reasonably release this stuff as "Mailman 2.1" either way. > [Aside: are there many patches in the tracker that could be useful? I > don't know how actively they've been getting processed. Does there > need to be a push to process bugs and patches?] I know Mark often does triage and commits fixes, but the tracker could certainly use a lot of love. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRkB/anEjvBPtnXfVAQJqLwP/SFmDBY+BapGRQR9EgWdmhic3Ka61EXup lS90vXglmW3kEbT/clm/9xkv9y179fQIT077OLGHGDPx18JWnIc2sPP+o8Hwb1wR KF+WAQKZUCSbAi5kD6LxBQIHcFjOMyQRIaoXK913CrVRGHKDqYpq2ALZHx3KkhGL jrhpDt37+Ao= =8cQj -----END PGP SIGNATURE----- From barry at python.org Tue May 8 15:51:05 2007 From: barry at python.org (Barry Warsaw) Date: Tue, 8 May 2007 09:51:05 -0400 Subject: [Mailman-Developers] Styling patch In-Reply-To: <6610B350-207C-4E38-AD13-F90F1F269102@zone12.com> References: <20070504010318.GA949@andrew-kuchlings-computer.local> <6610B350-207C-4E38-AD13-F90F1F269102@zone12.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 5, 2007, at 11:24 AM, Terri Oda wrote: > Have the CSS generated by a CGI (which could then use these variables > if they're available). > - extra processing for each web request > + could lay groundwork to make it possible to change settings on a > per-list (or per virt-domain) basis rather than site-wide. > > Use a Makefile to generate the CSS once from this file (and leave > note in file saying that further config is in CSS) > + processing happens once > - can't be applied easily as a patch, requires an actual rebuild to > take effect > > Use a "style" attribute as well as a "class" one: > + might make conversion from one type of settings to another easier > - just going to look inexplicable and hackish later, potentially make > it more awkward to do CSS-only skins Mailman trunk already has a wsgi based server of its own. It's my intention to deploy it without the (traditional) cgi scripts. By default Mailman would simply provide its own simple web server, but be compatible with wsgi for alternative publishing options. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRkCASnEjvBPtnXfVAQLhXwQAk1iamo4BCATpDX0nSO1fdayzPO8pif1G dYXhy+Pmea0g5/QPrUK8Yk4lcrwCZX7Tf/ggmV2g02jVdGwD+t/ST1nz/mjwa/ws w4RM99BaR+cXRiJshUJ7DoHs//5ihC7wPKiH/mcCnhJMfhJR5kWqkpqNLpQkAcXx g12dn0NBbbE= =4XyB -----END PGP SIGNATURE----- From barry at python.org Tue May 8 16:43:36 2007 From: barry at python.org (Barry Warsaw) Date: Tue, 8 May 2007 10:43:36 -0400 Subject: [Mailman-Developers] Styling patch In-Reply-To: <87lkg2comu.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20070504010318.GA949@andrew-kuchlings-computer.local> <6610B350-207C-4E38-AD13-F90F1F269102@zone12.com> <20070505205711.GB1571@andrew-kuchlings-computer.local> <87lkg2comu.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <7C586F0F-117E-4EAA-A598-31E05D045238@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 6, 2007, at 5:00 AM, Stephen J. Turnbull wrote: > Going to CSS at all is presumably off-limits for a 2.1 release. I > think it would be a very bad idea to constrain the design to be > backwards compatible to a non-CSS solution, but not doing so is unfair > to people who expect a 2.1 release to be a 2.1 release. Agreed. Andrew, when you created the modernize_21_webui branch, did you set it up with svnmerge? I think it would be a good idea to systematically merge 2.1 branch changes into the modernize branch. > -1. This is precisely the kind of thing we need to avoid at all > costs. You aren't going to decrease the pain of deprecating colors- > in-mm_cfg.py by postponing it, so may as well release CSS-only as 2.2 > as soon as CSS is ready for release (and have at least one more 2.1 > release for those who aren't ready to go to 2.2). Agreed. There will definitely be a 2.1.10 (Mark just committed a bunch of fixes), but I'm with Guido in hating two-digit point release numbers. > In the transition, I think that we should definitely use the cascade. > The multiple class method that Ethan describes is a good way to > provide a deprecation path over time as the code matures, although I > wonder if it's even necessary. In a different dimension, we probably > should have a mailman.css analogous to Defaults.py. Site and list > admins never touch this. Then there would be a site.css, analogous to > mm_cfg.py, and finally a $list.css for each list, in order of > increasing preference. For the sake of virtual hosts, site.css should > either be kept in a site-specific folder, or given a site-specific > name. Would you make $list.css editable by the list admin, a la listinfo.html? Does doing so open any additional security vulnerabilities? > As Ethan points out, these should be "real" files, not inline CSS in > the HEAD element generated by the cgi. It should be possible to > generate simple site and list stylesheets (eg, changing colors) for > the default templates through-the-web, but designers will want to deal > with CSS, not Python code. Note that with a little care, the same > module that does the t-t-w CSS generation could probably accept an > mm_cfg.py and (a) use the variables defined in mm_cfg.py to generate > site.css and (b) remove them (warning loudly that setting them in the > future will have no effect). I don't like being able to upload mm_cfg.py ttw, even if it's just to suck a few ui variables out of it. If we're going to allow ttw updating to the css, let's just do that directly instead of going through Python code. > Finally, we could have a check_config script analogous to check_perms, > but it would examine mm_cfg.py and the list configs, looking for > variables that are deprecated and variables that Mailman doesn't even > use, odd values and stuff like that. +1 - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRkCMmHEjvBPtnXfVAQIhigP/b837+mCQMIBsmS99dRDSrpeUCsDPTbL3 XlsZYiKBQVu8Xn4EFy0cklu4O/T51zoKHPJmnmVEXhcDLoMsAXlQf6wzOzekOO/P OJZZi8VPMRTpEteHz34Sx3/4XZF53Xioqoqwn+mxtayA4cykaYjq4+yUOODup9FN DY7SEKP1xzY= =/F99 -----END PGP SIGNATURE----- From barry at python.org Tue May 8 17:06:14 2007 From: barry at python.org (Barry Warsaw) Date: Tue, 8 May 2007 11:06:14 -0400 Subject: [Mailman-Developers] Styling patch In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 8, 2007, at 9:16 AM, Aaron Crosman wrote: > In general I agree with Ethan and Stephen, designers want CSS to be > in its > own file (for good reasons) and don't want to have to work in > python or XML > files if they don't have to. Since we're concerned about maintaining > compatibly with 2.1 users that have modified the templates using > the current > limited options, we shouldn't do a great deal under 2.1. But I > think we can > do more in 2.1 than Stephen proposes. I'm not so sure. I feel very uncomfortable making /any/ non-bug-fix changes to 2.1, perhaps even limiting them to critical bug fixes that address security or reliability issues. Better (IMO) to fairly quickly get a conservative 2.2 out sooner, along the lines I described in an earlier message. > If we feel the need to have good through the web support I would > suggest for > mailman 3.0 we build it in a manner similar to the garland theme in > Drupal 5 > (which provides a color wheel to select the colors, and then > generates a CSS > file). You can still edit the CSS directly if you'd like, but it'll > do any > colorization work for you. I'd also suggest that we avoid putting > template > links into mm_cfg.py settings, rather use a predefined path like > mailman > currently does. A theme switcher probably doesn't make sense in > Mailman, > but being able to change a the look and feel just by updating a CSS > file > would be a big plus (no restarting mailman). It would be easy > enough to > define a structure that would allow for CSS files for a given list > to live > in a particular directory. For MM3.0, we should use the 80/20 rule. IOW what /out of the box/ will give most people the best value without complicating the code, or our security or reliability story? Keep in mind use cases like cPanel where people will not have shell access. In that case, allowing for CSS editing t-t-w seems like a reasonably powerful and safe trade-off. More intensive web page editing, I'm not so sure. The other thing to keep in mind is that MM3.0 will be modular enough that people could build more extensive integrations with true content management systems or t-t-w editing environments. > Finally I'd like to suggest we avoid using JavaScript until we > absolutely > have to (a color picker would require it, other ideas might as > well), since > there isn't any JS in the code base at the moment, and its > introduction will > add complexity. Also, we'll probably want to find a good library > to work > with to help set coding standards and allow for some AJAX calls for > some > elements. Our basic design requirement here has been that JS is okay in the default u/i as long as the usability degrades gracefully when it is not enabled (either because the site disables it or the browser has). - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRkCR53EjvBPtnXfVAQKgcQP9HpB9BLbBHYoe4aMGINZCL5iO1whYIQKg uS1G3cGMOjYyBkt5jc7a5N9/jKkmrLU8BJ++yBZXBzvxFEbOn3rlSatpnvQ9Kh6+ cXrQJhpqhJgVYuNpNQSu/RjGVTYYMCOghzKigxjLcpgs+m2n7Wizkly4PsObPR6j vzq/gP+5YmA= =7nhD -----END PGP SIGNATURE----- From amk at amk.ca Tue May 8 19:50:22 2007 From: amk at amk.ca (A.M. Kuchling) Date: Tue, 8 May 2007 13:50:22 -0400 Subject: [Mailman-Developers] Styling patch In-Reply-To: References: Message-ID: <20070508175022.GB15034@localhost.localdomain> On Tue, May 08, 2007 at 11:06:14AM -0400, Barry Warsaw wrote: > I'm not so sure. I feel very uncomfortable making /any/ non-bug-fix > changes to 2.1, perhaps even limiting them to critical bug fixes that > address security or reliability issues. Better (IMO) to fairly > quickly get a conservative 2.2 out sooner, along the lines I > described in an earlier message. I have an idea for a proposed conservative approach for 2.1: * Add two mm_cfg settings: CSS_FILES and JS_FILES, while are lists (alternatively, whitespace-separated strings): CSS_FILES = ['/css/mailman.css', '/css/custom.css'] JS_FILES = ['/js/switcher.js', '/js/foo.js'] * Make generated HTML pages contain for each of the CSS files, and