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 
>> version
>> of repoze.zope2.  The original goal was 100% compatibility with existing
>> applications.  The reason I started BFG was because I thought losing b/w 
>> compat
>> with stock Zope 2 was an antigoal.  It just doesn't seem to be a win to 
>> innovate
>> and make bold changes in order to get a still-horribly-crufty system, but 
>> which
>> 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 ;)
> Hanno

I added some more test coverage on the trunk.  It's still pretty poor right now.

- C
Repoze-dev mailing list

Reply via email to