> > [...]
> >> 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
> 2. specialized an event so that filtering was made easier for
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.
>>> 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
> GODDAMIT READ THE CODE FOLKS!
Belive me I did.
But perhaps we wrote to many unit tests and this is bad for
> Florent Guillaume, Nuxeo (Paris, France) Director of R&D
> +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
END OF MESSAGE
Zope3-dev mailing list