On 5/12/09 11:54 AM, Hanno Schlichting wrote:
> Chris McDonough wrote:
>> I think this package is becoming less "repoze.zope2" than some other more
>> experimental system. Which is fine. But there's no way I'm going to be able
>> to give people help with it on IRC or the maillist when it breaks because
>> they're using an API that we removed. I have more fun things to do. ;-)
>> FTR, the cruft-removal-at-all-costs goal is not the goal of the original
>> of repoze.zope2. The original goal was 100% compatibility with existing
>> applications. The reason I started BFG was because I thought losing b/w
>> with stock Zope 2 was an antigoal. It just doesn't seem to be a win to
>> and make bold changes in order to get a still-horribly-crufty system, but
>> now isn't even backwards compatible.
>> If we ever do release an 80%-compatible publisher replacement, we should
>> call it
>> something other than "repoze.zope2".
> I don't particularly care about names of anything at all here.
> repoze.zope2 seems to be the closest thing out there which allows me to
> move in some form of evolutionary approach from current Plone/Zope2 to
> something that has a reasonable chance of loosing its Zope2
> underpinnings before hell freezes over.
> I still think the general goal is to decompose things and use WSGI for
> this package, so it fits the Repoze umbrella. If you have a suggestion
> on what to name it instead, that'd be more than welcome - don't let
> Germans name anything ;)
I added some more test coverage on the trunk. It's still pretty poor right now.
Repoze-dev mailing list