Ok, I thought about that a bit. I think I'd be happy to add committers to pypi. Hwowever. I don't have time to write a script right now and I don't have time to do it manually. If someone gives me a script and a list of people that are committers that should be added, then I'll run it with my account.

srichter: well, all i'm going to say is that if you had planned (by advice of J1m or whatever) to make egg releases for a while, then i wonder why you need those access rights in a hurry now. you know pypi as well as the rest of us do

Hi, I'm trying to backport the Decimal field to 3.3 (in 2.10.4), but I'm getting a ConfigurationError: ('Invalid directive', u'factory') when I try to make the registrations (which I've taken from zope/app/schema/configure.zcml). Any idea what I could be doing wrong?

philiKON, Theuni, projekt01, srichter and all : I can spend sometime to give access to srichter and projekt01 manually for whatever packages I owned, for rest of the packages you can ask their owners, is it ok now?

wiggy: I'm not really disagreeing all that much. I'm just saying that our requirements may be exactly the same but our *primary* requirements may diverge. factoring out the stuff from existing packge management systems seems like a, um, significant project, as well. :)

benji: saying that the solution is possible or that it's easy or that you have done it doesn't mean it's community standard practice. that takes communication, possibly code release, and such things. otherwise nobody actually *knows* what the hell to do. philipp and I only knew about version pinning 3 weeks ago!

spython: Well, there aren't that many of them, and you would have to specify that you want the 3.3 version and so on. It's probably possible, but I wouldn't be able to tell you how. And besides, wy would you want to?

I'm talking about *releasing* a framework that continues to work after a few days. The only way I can do this is if I can specify explicitly what versions it requires and that all applications that reuse this framework take this into account.

ignas: philipp makes the argument that this locks people in when they develop their own app. if they know what they're doing this should be able to user a newer version of a particular dependency explicitly.

ignas: and if you have a layered tree of dependencies, you might want to let some zope 3 egg determine *its* exact dependencies, and have grok depend on it, instead of grok having to maintain its own full list.

projekt01: and while i'm at it, zope.app.error produces a deprecation warning talking about "removal in zope 3.6". first of all, i don't think there'll be a zope 3.6 (at least it seems that nobody will want to continue making one big zope 3 releae), and second of all i thought we weren't going to remove stuff anymore