I was supposing that the utility configuration was a 1.7 hack, not 1.6.The adaptation is, of course, backwards compatible, and very convenient for organizations that are using MMBase 1.6 in a production environment.
I don't really mind (as long as config files are not required to be present, so the system is backwards compatible), but I suggest that, unless specified explicitly in a call, hacks are intended for the CVS Head version (1.7), and not for the patch. If people agree, this would make voting for hacks a bit more transparent.
I agree we should make it more explicitly, in our calls, to which branches the code changes are going to be submitted.
I would also like your views on checking in Hacks during a vote.Personally i am not in favour for this, just see the extra rules you have to introduce. I really like to keep the number of rules to a minimum, to keep things easy to understand. Should code not be tested before you are going to propose it as a hack ? Personally i would like to see more discussions on the devlist, and testing before hacks are actually checked in.
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.
greetings Rob
