Hi Florent > > [...] > > > >> Florent > > > > I'm not happy with this changes too. But I hope I can live > > with that. > > > > But I'm really not happy how this code get into the core. > > We defined a proposal based process for announce such changes. > > Oh come on, I did two simple things: > 1. fixed a bug where subobject reordering didn't send a modification > event, > 2. specialized an event so that filtering was made easier for > subscribers.
On every other package I whouldn't say anything. But the event concept isn't that simply as you can change it everytime a bug has to be fixed. I call this changes fundamental and this can't be done adhoc. > > It's really bad if such changes break our unit tests and > > existing applications. > > ??? Where does that come from? What unit tests would break? Remember there are other applications where have unit tests. The test method "getEvents" reported new events after your changes. like: >>> events = getEvents() >>> [event.__class__.__name__ for event in events] ['ObjectCopiedEvent', 'ObjectAddedEvent', 'ContainerModifiedEvent'] > > Especially if this happens because > > of new events where are really ugly to trace down. > > I DIDN'T ADD NEW EVENTS EXCEPT FOR FIXING ONE BUG!!!!! Ok, I whould simply say you did. I whould agree if it whould be the only one method to fix this bug. But your fix can break existing tests. > GODDAMIT READ THE CODE FOLKS! Belive me I did. But perhaps we wrote to many unit tests and this is bad for such changes. > -- > Florent Guillaume, Nuxeo (Paris, France) Director of R&D > +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] Regards Roger Ineichen Projekt01 GmbH www.projekt01.ch _____________________________ END OF MESSAGE _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
