Re: [Zope-dev] ploneconf2009
Hello, I added a coactivate project: http://www.coactivate.org/projects/ploneconf2009-ztk-sprint/project-home Thursday, October 1, 2009, 6:18:05 PM, you wrote: FT> * 2009-09-30 18:04, Adam GROSZER wrote: >> And ZTK sprinting? FT> I'm not going to the Plone conference (at least officially), but I'd be FT> interested in the ZTK sprinting. Anyone joining us? :) FT> Fabio FT> ___ FT> Zope-Dev maillist - Zope-Dev@zope.org FT> https://mail.zope.org/mailman/listinfo/zope-dev FT> ** No cross posts or HTML encoding! ** FT> (Related lists - FT> https://mail.zope.org/mailman/listinfo/zope-announce FT> https://mail.zope.org/mailman/listinfo/zope ) -- Best regards, Adam GROSZERmailto:agros...@gmail.com -- Quote of the day: Only God can make random selections. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12.0 released
On Thu, Oct 1, 2009 at 6:09 PM, Chris Withers wrote: > Hanno Schlichting wrote: >> >> Yeah! I added the Windows binary eggs for Python 2.4 to 2.6 to PyPi. > > Someone still needs to do this for: > > http://pypi.python.org/pypi/ExtensionClass/2.11.3 > > I would, but I don't have the right PyPI access... Thanks. I added the missing binary eggs for the 2.11.2 and 2.11.3 releases. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: cleaning up the content-type story
Hello, That sounds impressing. Definitely something to watch in the refactoring process is having all this working on win32 ;-) Thursday, October 1, 2009, 5:11:10 PM, you wrote: HS> For mime type information it looks at: HS> - all information found in the HS> http://www.freedesktop.org/standards/shared-mime-info database HS> - magic codes based on gnome-vfs-mime-magic HS> - information form the Apache mime.types (local copy so it works on Windows) HS> - respects zope.contenttype and Python's mimetypes module HS> - on Windows respects the information found in the registry at HS> "HKEY_CLASSES_ROOT\MIME\Database\Content Type" HS> - a couple of its own definitions (for example Markdown, Textile, SVG, HS> new MS Office formats not yet present in the other sources) HS> If someone really wants to extend the functionality, this package HS> might be worth a look. The whole persistent registry idea of HS> MimeTypesRegistry is overkill, but most of the other code should have HS> little or no external dependencies and should be good after a bit of HS> refactoring. HS> Hanno HS> ___ HS> Zope-Dev maillist - Zope-Dev@zope.org HS> https://mail.zope.org/mailman/listinfo/zope-dev HS> ** No cross posts or HTML encoding! ** HS> (Related lists - HS> https://mail.zope.org/mailman/listinfo/zope-announce HS> https://mail.zope.org/mailman/listinfo/zope ) -- Best regards, Adam GROSZERmailto:agros...@gmail.com -- Quote of the day: Save yourself! Reboot in 5 seconds! ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ploneconf2009
* 2009-09-30 18:04, Adam GROSZER wrote: > And ZTK sprinting? I'm not going to the Plone conference (at least officially), but I'd be interested in the ZTK sprinting. Anyone joining us? :) Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12.0 released
Hanno Schlichting wrote: > On Thu, Oct 1, 2009 at 5:15 AM, Andreas Jung wrote: >> On behalf of the Zope 2 developers community I am pleased to announce >> the official release of Zope 2.12.0. > > Yeah! I added the Windows binary eggs for Python 2.4 to 2.6 to PyPi. Someone still needs to do this for: http://pypi.python.org/pypi/ExtensionClass/2.11.3 I would, but I don't have the right PyPI access... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: cleaning up the content-type story
Thomas Lotze wrote: > I also wonder whether it might make sense to utilise the /etc/mime.types > database (or the system's equivalent) for guessing based on the file-name > extension, The Python mimetypes module already uses that file in any of the "standard" Unix locations. > and libmagic (if available) for magic-number tests based on > file contents. But of course, these ideas don't have much to do with the > restructuring discussed in this thread. Two PyPI modules claim to do the magic number guessing thing: - http://pypi.python.org/pypi/python-magic/0.1 is a ctypes wrapper around libmagic -- no sdist ;( - http://pypi.python.org/pypi/magic/0.1 has its own database inlined in the module. It has no distributions at all, just a link to a bare magic.py file. Tres. -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.filerepresentation
2009/10/1 Martin Aspeli : > Hanno Schlichting wrote: >> The standard file implementation has no knowledge of its size, as this >> is sometimes impossible to get, when dealing with stream based >> file-like objects. Do we really need to have files to know their size? > > Well, for the writeFile() stuff maybe we don't. Thinking through my use > cases again, I can't see a need for passing the content type in, and > encoding can be set if we support setting the '.encoding' property. > > It's kind of important to be able to indicate the size and MIME type for > a read operation, though. In this case, I want to be able to put that > information into the Content-Type and Content-Length headers. The > IStreamData stuff in Zope 2 also wants to know the length before it > starts streaming. > > In some cases, it may not be possible to know, in which case we can fall > back on len(data), but in other cases, the length is known > (plone.namedfile and z3c.blobfile keep track of it, for example), in > which case having a way to ask the adapter means it can be done much > more efficiently. To find the length of a file: f.seek(0,2) # 0 bytes from the end of the file size = f.tell() # position in file. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: cleaning up the content-type story
On Thu, Oct 1, 2009 at 4:44 PM, Thomas Lotze wrote: > I also wonder whether it might make sense to utilise the /etc/mime.types > database (or the system's equivalent) for guessing based on the file-name > extension, and libmagic (if available) for magic-number tests based on > file contents. But of course, these ideas don't have much to do with the > restructuring discussed in this thread. Not related to the restructuring: Products.MimeTypesRegistry is currently tightly bound to Zope2. But it does have a far more advanced implementation for mimetype related functionality, like type guessing and file extension handling. For mime type information it looks at: - all information found in the http://www.freedesktop.org/standards/shared-mime-info database - magic codes based on gnome-vfs-mime-magic - information form the Apache mime.types (local copy so it works on Windows) - respects zope.contenttype and Python's mimetypes module - on Windows respects the information found in the registry at "HKEY_CLASSES_ROOT\MIME\Database\Content Type" - a couple of its own definitions (for example Markdown, Textile, SVG, new MS Office formats not yet present in the other sources) If someone really wants to extend the functionality, this package might be worth a look. The whole persistent registry idea of MimeTypesRegistry is overkill, but most of the other code should have little or no external dependencies and should be good after a bit of refactoring. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: cleaning up the content-type story
Tres Seaver wrote: > Thomas Lotze wrote: >> Following up to Martijn's observations on the ZTK, I'd like to propose a >> clean-up of how we handle content types. There are several unrelated >> pieces of code concerned with content types, these include at least >> zope.contenttype, zope.mimetype and zope.publisher.contenttype. >> >> - zope.contenttype does some content-type guessing from file names. It's >> just a few lines of code and comes with a table of some 30 >> associations of file-name extensions with content types. >> >> - zope.mimetype is a more substantial package that deals with >> content-type specific marker interfaces. I actually forgot to mention that zope.mimetype comes with another table associating content types with file name suffixes and other information. It would certainly be a good idea to have only one such data collection to maintain. >> - zope.publisher.contenttype contains a parser for content-type >> specifications. >> >> I propose merging those two packages and one module into one package, >> zope.contenttype. [...] > > - How do 'zope.file' and 'zope.filerepresentation' interact with these >modules? zope.file uses zope.mimetype to have a structured way of talking about content-type-related properties of file objects, and zope.publisher.contenttype for parsing content-type strings. zope.filerepresentation only defines some interfaces and uses none of the modules in question. > - How do these modules interact with the standard library's 'mimetypes' >module? Both zope.contenttype and zope.mimetype use the mimetypes module to guess content-types from file names. In fact, both even do some guesswork based on the first bytes of file content. Probably merging the two involves essentially dropping one of the implementations. I also wonder whether it might make sense to utilise the /etc/mime.types database (or the system's equivalent) for guessing based on the file-name extension, and libmagic (if available) for magic-number tests based on file contents. But of course, these ideas don't have much to do with the restructuring discussed in this thread. -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope2.zope.org launched
On Thu, Oct 1, 2009 at 04:50, Andreas Jung wrote: > I am pleased to announce the launch of a new website dedicated to the > Zope 2 application server: > > zope2.zope.org Cool! -- Sebastien Douche Twitter: http://bit.ly/afkrK (agile, python, open source) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: cleaning up the content-type story
Thomas Lotze wrote: > Following up to Martijn's observations on the ZTK, I'd like to propose a > clean-up of how we handle content types. There are several unrelated > pieces of code concerned with content types, these include at least > zope.contenttype, zope.mimetype and zope.publisher.contenttype. > > - zope.contenttype does some content-type guessing from file names. It's > just a few lines of code and comes with a table of some 30 associations > of file-name extensions with content types. > > - zope.mimetype is a more substantial package that deals with > content-type specific marker interfaces. > > - zope.publisher.contenttype contains a parser for content-type > specifications. > > I propose merging those two packages and one module into one package, > zope.contenttype. > > At present, zope.contenttype doesn't have any dependencies within the ZTK, > and zope.mimetype depends on zope.configuration, zope.component and > zope.interface. zope.publisher.contenttype doesn't import any zope code. > > - Switching packages that depend on zope.mimetype would therefore add no > additional dependencies to them. > > - There are three packages within the ZTK and the set of packages under > review which depend on zope.contenttype: zope.browserresource, > zope.app.file and zope.app.onlinehelp. All of them already depend on > zope.mimetype's dependencies, so there's nothing to be lost for them > either. > > - Finally, the same holds for zope.publisher which would only acquire a > new dependency on zope.contenttype if zope.publisher.contenttype were to > be merged with the latter. > > Further, the parser in zope.publisher.contenttype needs to be made more > conformant with RfC 2045 and be used by other code that does some > content-type matching of its own right now, such as zope.publisher.http. +1 on consolidation. A couple of questions: - How do 'zope.file' and 'zope.filerepresentation' interact with these modules? - How do these modules interact with the standard library's 'mimetypes' module? Tres. -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.filerepresentation
Am 01.10.2009, 15:51 Uhr, schrieb Martin Aspeli : > Haha. Maybe I'll have a property mimeType instead? That looks better, I > guess. +1 to use a property rather than a getter. Not sure about content-type vs. mime-type. If this is used only in an HTTP environment then I'd prefer to stick with content-type otherwise I'd suggest the email module's content-type handling. > But we *are* in a Zope package, so Zope naming conventions probably > apply. I go with Pythonic conventions wherever possible. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtztstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.filerepresentation
Hanno Schlichting wrote: > On Thu, Oct 1, 2009 at 2:13 AM, Martin Aspeli > wrote: >> Hanno Schlichting wrote: >> >>> Is there any reason to invent a new API and not just use Python's file API? >> I don't know. IReadFile and IWriteFile have been around for ever and are >> used by a number of things in Zope. They have read(), write() and >> size(). The first two are on file, the last one isn't. I'd like to be >> able to use this API as a base, since it's used for things like >> z3c.blobfile already, and is documented as the way to do this kind of >> thing in Philipp's book. > > Ok. I have a feeling that Zope3 at various times invented a new > Java-ish API instead of using standard Python protocols. I'd just like > to avoid going down that way even more. > >> class IReadFile(Interface): >> """Provide read access to file data >> """ >> >> def read(): >> """Return the file data as a str >> """ >> >> def size(): >> """Return the data length >> """ > > This needs a clarification on what kind of length this is. Is it the > length of the binary data? Since these interfaces also know about > encoding, it's otherwise not clear if the size for textual data might > be its Unicode length. I assume so. Note that this interface already exists, so I'm not proposing to change it. ;-) >> class ILargeReadFile(IReadFile): >> """Provide efficient read access to file data >> """ >> >> def getContentType(): >> """Get the content/MIME type of the file as a string in the form >> 'major/minor'. Return None if this is not known or undefined. >> """ >> >> name = schema.TextLine(title=u"Filename", readonly=True) >> encoding = schema.ASCIILine(title=u"Encoding", readonly=True) > > encoding only makes sense for text/*, so maybe some small hint at that? Sure, yeah. >> def __iter__(): >> """Get an iterator""" >> >> def next(): >> """See file""" >> >> def seek(): >> """See file""" >> >> def tell(): >> """See file""" >> >> class IWriteFile(Interface): >> >> def write(data): >> """Update the file data >> """ >> >> class ILargeWriteFile(IWriteFile): >> >> def write(data): >> """Write a chunk of data >> """ >> >> name = schema.TextLine(title=u"Filename", readonly=False) >> encoding = schema.ASCIILine(title=u"Encoding", readonly=False) >> >> def tell(): >> """See file""" >> >> def close(): >> """See file"" >> >> I've still got the content type as a method (maybe make it a read-only >> property?) that may return None. That could be in a separate adapter, >> but that feels like overkill to me. :) > > There's no standard way to spell "content type", so I don't really > care. On the pure file level it's even called mime type and only > internet data handling uses "content type". So you have to look things > up anyways. Compared to the other attributes/methods "getContentType" > looks like a Java-intruder in otherwise Python naming conventions, > though. Haha. Maybe I'll have a property mimeType instead? That looks better, I guess. But we *are* in a Zope package, so Zope naming conventions probably apply. Ok, I'm going to do this shortly, unless anyone objects. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12.0 released
On Thu, Oct 1, 2009 at 5:15 AM, Andreas Jung wrote: > On behalf of the Zope 2 developers community I am pleased to announce > the official release of Zope 2.12.0. Yeah! I added the Windows binary eggs for Python 2.4 to 2.6 to PyPi. > I would like to thank all people having contributed to this release. > Special thanks to Tres Seaver for his tireless efforts in fixing bugs > and maintaining the Zope 2 codebase and Hanno Schlichting who worked > hard and steadfast on the eggification of Zope 2 and on the cleanup of > various dark corners of the Zope 2 codebase. Thank you Andreas! Especially for making sure this release didn't grew out-of-scope, but has seen the light of the day now :) Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Wed Sep 30 12:00:00 2009 UTC to Thu Oct 1 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Wed Sep 30 20:47:30 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012672.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Wed Sep 30 20:49:30 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012673.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Wed Sep 30 20:51:30 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012674.html Subject: OK : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Wed Sep 30 20:53:30 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012675.html Subject: OK : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Wed Sep 30 20:55:30 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012676.html Subject: OK : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Wed Sep 30 20:57:30 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012677.html Subject: OK : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Wed Sep 30 20:59:30 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012678.html Subject: OK : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Wed Sep 30 21:01:31 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012679.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.filerepresentation
On Thu, Oct 1, 2009 at 2:13 AM, Martin Aspeli wrote: > Hanno Schlichting wrote: > >> Is there any reason to invent a new API and not just use Python's file API? > > I don't know. IReadFile and IWriteFile have been around for ever and are > used by a number of things in Zope. They have read(), write() and > size(). The first two are on file, the last one isn't. I'd like to be > able to use this API as a base, since it's used for things like > z3c.blobfile already, and is documented as the way to do this kind of > thing in Philipp's book. Ok. I have a feeling that Zope3 at various times invented a new Java-ish API instead of using standard Python protocols. I'd just like to avoid going down that way even more. > class IReadFile(Interface): > """Provide read access to file data > """ > > def read(): > """Return the file data as a str > """ > > def size(): > """Return the data length > """ This needs a clarification on what kind of length this is. Is it the length of the binary data? Since these interfaces also know about encoding, it's otherwise not clear if the size for textual data might be its Unicode length. > class ILargeReadFile(IReadFile): > """Provide efficient read access to file data > """ > > def getContentType(): > """Get the content/MIME type of the file as a string in the form > 'major/minor'. Return None if this is not known or undefined. > """ > > name = schema.TextLine(title=u"Filename", readonly=True) > encoding = schema.ASCIILine(title=u"Encoding", readonly=True) encoding only makes sense for text/*, so maybe some small hint at that? > def __iter__(): > """Get an iterator""" > > def next(): > """See file""" > > def seek(): > """See file""" > > def tell(): > """See file""" > > class IWriteFile(Interface): > > def write(data): > """Update the file data > """ > > class ILargeWriteFile(IWriteFile): > > def write(data): > """Write a chunk of data > """ > > name = schema.TextLine(title=u"Filename", readonly=False) > encoding = schema.ASCIILine(title=u"Encoding", readonly=False) > > def tell(): > """See file""" > > def close(): > """See file"" > > I've still got the content type as a method (maybe make it a read-only > property?) that may return None. That could be in a separate adapter, > but that feels like overkill to me. :) There's no standard way to spell "content type", so I don't really care. On the pure file level it's even called mime type and only internet data handling uses "content type". So you have to look things up anyways. Compared to the other attributes/methods "getContentType" looks like a Java-intruder in otherwise Python naming conventions, though. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope2.zope.org launched
Andreas Jung wrote: > I am pleased to announce the launch of a new website dedicated to the > Zope 2 application server: > > zope2.zope.org > > This site gives the Zope 2 application a much better representation on > the web (which was more than necessary after having lived for years with > the current old www.zope.org site). > > zope2.zope.org is not a community site. You will not be able to register > or upload personal content (use www.zope.org for the time being). We > will publish content on request (events, news etc.) - please contact the > webmaster in such a case. > > It took more than half a year in order to get this site done and I would > like to thank the following people for their involvement in this project: > > - Alma Ong (Design) > - Robert Rottermann and Gerhard Hug (implementation of the Plone theme) > - Jens Vagelpohl (server setup, technical support, content review) > - Matthew Wilkes (content review) > - Sidnei da Silva (moving Zope 2 downloads to Launchpad) > - Michael Haubenwaller (the Zope webmaster) > > Andreas Jung > Zope 2 Release Manager Fantastic stuff! :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
