Hi all,
I have had some work recently for a client that was having difficulty
with their Plone deployments due to a proliferation of custom install
code working around missing features in standard Generic Setup handlers.
I've made some commits to a bunch of Plone core packages to fix many of
Is there any plan to make new releases of Zope 2.12 and Zope 2.13
integrating the patches that are meaningful for pure-Zope (non-Plone)
applications ?
Plone doesn't always use the latest version of Zope. These are backports.
Matt
smime.p7s
Description: S/MIME Cryptographic
Tres Seaver wrote:
Because it is a helluva lot of work, which can't be trivially scripted
(things can go wrong: each project needs a person who knows it well to
review the migrated repo).
When Plone did this the people involved wrote some scripts
https://github.com/plone/svn-migrate
I'm
Tres Seaver wrote:
What is needed is not scripts, but eyeballs: we need people who know the
various packages and*care* about getting them migrated to github to step
up. Softwward which doesn't have a champion willing to do the work
should stay behind on SVN.
The community as a whole cares
Jens Vagelpohl wrote:
Maintaining the chain of custody doesn't just consist of selecting pull
requests or patches coming from somewhere. It also means verifying the
contributor - be it the one who is creating the patch or pull request or the
one who is merging new code into the repository
On 2011-11-03, at 0025, Chris Withers wrote:
I'm experimenting with using nose as an alternative to zope.testrunner
so I can take advantage of the junit and cobertura compatible xml output
offered.
Using http://pypi.python.org/pypi/collective.xmltestreport might be easier? Not
sure if it
Log message for revision 121035:
The getaddrinfo API provides a superset of the info provided by gethostbyname
but isn't ipv4 specific.
Changed:
U Zope/trunk/src/ZServer/datatypes.py
-=-
Modified: Zope/trunk/src/ZServer/datatypes.py
Log message for revision 121036:
Detect IPv6 hosts and use the appropriate address family.
Changed:
U Zope/trunk/src/ZServer/medusa/http_server.py
U Zope/trunk/src/ZServer/tests/test_config.py
-=-
Modified: Zope/trunk/src/ZServer/medusa/http_server.py
Log message for revision 120989:
Initial branch for modifying Medusa and ZServer for serving over IPv6.
Changed:
A Zope/branches/MatthewWilkes-ipv6-support/
-=-
___
Zope-Checkins maillist - Zope-Checkins@zope.org
Log message for revision 114001:
This version of mailer.py is the same as the one in zope.sendmail, modulo
some whitespace changes and not all error handling from z.s being present. It
should therefore be safe to make this a deprecated alias.
Changed:
U
Log message for revision 114002:
Actually use the sendmail SMTPMailer.
Changed:
U Zope/branches/2.12/src/Products/MailHost/MailHost.py
-=-
Modified: Zope/branches/2.12/src/Products/MailHost/MailHost.py
===
---
On 2010-06-23, at 1359, Laurence Rowe wrote:
I think the Before Commit Hook option is probably best here.
DirectMailDelivery should only be used for testing anyway, or at least
only on very small sites in production - QueuedMailDelivery will scale
better.
Sorry, I'm somewhat late to this
Log message for revision 113979:
I want to use zope.deprecation and it's in the toolkit so let's bring it in.
Changed:
U Zope/trunk/setup.py
-=-
Modified: Zope/trunk/setup.py
===
--- Zope/trunk/setup.py 2010-06-29 15:18:21 UTC
Log message for revision 113980:
Remove the SMTPMailer duplicated from zope.sendmail and make its module a
deprecated alias to the equivalent in z.s.
Changed:
U Zope/trunk/src/Products/MailHost/MailHost.py
U Zope/trunk/src/Products/MailHost/mailer.py
-=-
Modified:
Log message for revision 113981:
Use zope.deferredimport instead of zope.deprecated for deprecations. Yay.
Changed:
U Zope/trunk/setup.py
U Zope/trunk/src/Products/MailHost/mailer.py
-=-
Modified: Zope/trunk/setup.py
===
On 2010-06-13, at 1348, Hanno Schlichting wrote:
On Sat, Jun 12, 2010 at 9:29 PM, David Glick davidgl...@groundwire.org
wrote:
Has the process of reviewing RestrictedPython against a new Python
release been documented anywhere?
Not that I know of. Stephan Richter and Sidnei da Silva were
On 2010-02-06, at 1257, Charlie Clark wrote:
Migrating from DTML to ZPT would add weight to the dog food
argument and
should be fairly straightforward. ZPT came on the scene shortly
after I
started playing with Zope and is one of the biggest reasons for me
sticking with it. The ZMI is
with HTML5 the frame-elements will die. It will probably take some
years before the browser-support of HTML4 will stop, but still. Are
there any alternative implementations for the Zope2-ZMI?
This is such a minor thing that if we do ever get to a stage where
we're having to get rid of the
On 2009-12-22, at 1627, Hanno Schlichting wrote:
I'd love to have Zope2 actually support WSGI out-of-the-box. It should
probably be based on either a simplified repoze.zope2 codebase or
simply something that gets the job done.
So what's your goal with this and is there any way I can help?
On 2009-12-23, at 0624, Marius Gedminas wrote:
Releasing 3.8.5 now.
…and it's broken. The testrunner directory isn't included in the
tarball so egg_info fails. In addition, the PyPI page has been
destroyed because of a ReST syntax error somewhere.
Matt
On 2009-11-25, at 1601, Benji York wrote:
I'm not sure I like the following suggestion better than the above,
but
throwing it out there anyway:
Multiadapter:
IFoo((x,y))
I know it's probably a spurious use case, but what if I want to adapt
a tuple?
Matt
Hi Chris,
On 2009-11-24, at 0324, Chris McDonough wrote:
In repoze.bfg, we've actually decided to use a subclass of the
component
registry which also inherits from dict. This makes it possible to
spell
common unnamed utility registrations and lookups as:
utility =
You may have Zope Component Developer's Eyes, a common disease in
these parts. ;-)
The goggles, they do nothing.
Under the hood, the system does something like this when a root
factory needs to be registered:
from repoze.bfg.interfaces import IRootFactory
from zope.component import
On 28 May 2009, at 12:39, Martijn Faassen wrote:
* Hm, I wonder whether it has something to do with local utilities.
I don't think I'd make this jump. I'd not be averse to a longer
package name if it made it more explicit.
Matt
___
Zope-Dev
On 26 Apr 2009, at 16:53, Martin Aspeli wrote:
We can fix this by introducing some code in OFS (and BTreeFolder2)
that
mimics what zope.container does.
Is there any risk involved in this? It looks ok in theory, just that
we're at a4 of Zope 2.12, we should be getting wary of features.
On 8 Apr 2009, at 16:40, Martijn Faassen wrote:
How to get out of that bind? We could consider renaming Zope 3. Is
there
any potential for this?
A thought that occurs to me is we could not rename Zope 2 or Zope 3
but abbreviate Zope 3 to z3 as much as possible. I'm not sure if
that's
On 1 Apr 2009, at 18:25, Chris Rossi wrote:
Additionally, if I was grokking Lennart correctly yesterday,
__metaclass__ is going away, so the current metaclass implementation
is going to need some rejiggering. What was unclear was whether a
single implementation could support both =2.5 and
On 3 Mar 2009, at 18:25, Martijn Faassen wrote:
Ah, so Plone currently has long term direction as they think 2
releases
ahead of just one?
Plone 4 discussions are happening around now, there are demos of
suggested concepts and people generally working on the codebase.
Plone 5 is a
On 2 Mar 2009, at 16:33, Martijn Faassen wrote:
What is the Zope project? The Zope project is an umbrella project for
a number of sub-projects. Its source code is in a repository managed
by the Zope Foundation. Within the Zope project, there are a number of
projects that ship full-stack web
Log message for revision 93183:
Typo: identicial in export object screen. Had been annoying me.
Changed:
U Zope/trunk/lib/python/OFS/dtml/importExport.dtml
-=-
Modified: Zope/trunk/lib/python/OFS/dtml/importExport.dtml
===
Log message for revision 93058:
Move ZEO include to 3.8 branch until new tag is made
Changed:
_U Zope/trunk/lib/python/
-=-
Property changes on: Zope/trunk/lib/python
___
Modified: svn:externals
- BTrees
Log message for revision 92793:
Backported DoomedTransaction handling from trunk r92792 to 2.11 branch
Changed:
U Zope/branches/2.11/lib/python/Zope2/App/startup.py
A Zope/branches/2.11/lib/python/Zope2/App/tests/testDoomedTransaction.py
-=-
Modified:
Log message for revision 92794:
Good catch Sidnei, damn you unexpected merge
Changed:
U Zope/branches/2.11/lib/python/Zope2/App/startup.py
-=-
Modified: Zope/branches/2.11/lib/python/Zope2/App/startup.py
===
---
Log message for revision 92792:
Add check for doomed transactions in default transaction manager, abort
silently if the tm tries to commit a doomed transaction
Changed:
U Zope/trunk/lib/python/Zope2/App/startup.py
A Zope/trunk/lib/python/Zope2/App/tests/testDoomedTransaction.py
-=-
Log message for revision 92606:
Make the SHA usage in mkzopeinstance a conditional import. Re-adds Python2.4
compatibility
Changed:
U Zope/trunk/utilities/mkzopeinstance.py
-=-
Modified: Zope/trunk/utilities/mkzopeinstance.py
35 matches
Mail list logo
