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 ;)


Repoze-dev mailing list

Reply via email to