Hi all, Today, we had a convo with Alex about the procedures that we need to follow while committing our changes to 1.1 trunks from now on. Of course this is not a strong set of rules but reflects what Alex would like all of us to pay attention.
The convo started with my question "What procedure would we follow for backporting some 1.1 trunk changes (fixes) to 1.0 ?" And the convo evolved then and I'm summarizing Alex's points here: * We need to be much more carefull from now on because we have a more complicate structure with releases and branches. We should triple check our work. * When we want to apply a change to 1.0 and 1.1, we should first apply it to 1.0 and then port to 1.1. Because trunks is more unstable and more available for messes *** Doing the serious job first in 1.0 is better. * We should apply the patches from buttom to up, not from top to buttom, meaning we should do it with commits as small as possible (file based prefered). * We should try to write better commits logs to able to track changes and problems easier. * We should document our important permanent/temporary changes (for example I had commented out mina's netty codec module in mina pom while it caused some pb with site generation and cause Alex did not know it he needed to do some extra work). *** And an offer from Alex: Breakage in trunks is not acceptable, so a committer who causes breakage in main branches or trunks will be responsible for making documentation for one week. A punishment ;-) (And yes, we need doco!) Cheers, -- Ersin
