directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Convo summary: Procedures for Directory committers working on trunks
Date Fri, 24 Feb 2006 21:50:41 GMT
Ersin Er a écrit :

>Hi all,
Hi all, too !

>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.
It has to be a strong set of rules.

>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.
+1. And triple may not be enough :) That means, to the least, no commit 
before having run successfully a mvn -Dregressions test

>* 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
I agree to some extent : we should just apply fixes to 1.0 trunk. No new 
feature, just fixes.

>* 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).
+1 !

>* We should try to write better commits logs to able to track changes
>and problems easier.
Yeah... Is it a good idea to add the JIRA reference number in the comment ?

>* 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).
What about a file named change.txt in each sub-project root which will 
gather doco about modification?

>*** 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!)
What about writing new unit-tests? Or checking the code for style 
violation? Ah, sorry, we don't have any style, isn't it? ;-)

Btw, we badly need some doco !

-- Emmanuel

View raw message