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