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 _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
