I would also like your views on checking in Hacks during a vote.
I think that, for small hacks, checking code in in CVS makes it easier for people to test it (actually I thought we had a discussion on this earlier but I may be wrong.).
So I would say you can check in a hack, for testing purposes only, provided:
- 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.
Hmmmm...I don't like the idea of adding more rules. And I think if an Hack is a real hack (ie a big change) it must be voted upon before adding it to cvs and the hack must contain patch files. I also like to see some more discussion about possible hacks before the actual vote takes place. Maybe first have a proposal where it can be discussed and after the discussion the vote?
If the hack is a small change (but what's a small change?) it's not a hack.....and it can be added to cvs without vote and reviewed afterwards....and if needed reverted, or voted about.
Gerard
