So I would say you can check in a hack, for testing purposes only, provided:I disagree with this proposal, but i see the problem that is it is hard to test a hack and the changes it involves.
- it does not exceed 5 new or changed classes
- it does not involve changes in behavior of module.core classes
- it is expressly stated that the code is for tetsing
- it is documented how to rollback changes.
I think this would make actually reviewuing code before voting is made easier. We might however, in those cases extend the voting window with two workdays, as we will be assuming people test the (pre-committed) hack.
Putting some research in how to make a patch file, document this, and how to apply this patch on the code, and requesting a patchfile for a hack would be a better sollution.
This way it would be as easy to install as retrieving the source from cvs, the maximum classes to be changed has no upper limit. Also core modifications can be permitted this way.
Furthermore there is no need to state that it is for testing and rollback is not needed.
(Furthermore most people can read patch files i guess, so without looking in cvs you can see the changes...)
-- Time is on my side,....
Eduard Witteveen +316 414 789 23
