directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <>
Subject Re: Convo summary: Procedures for Directory committers working on trunks
Date Fri, 24 Feb 2006 22:01:19 GMT
On 2/24/06, Emmanuel Lecharny <> wrote:
> 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

I agree. And one problem I face is files I've forget to commit. So in
case our tests pass, our patch may not cause the same effect in trunks
on the server. So we need to be sure that we added all our changes to
the patch (or svn added them).

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

This is more about making fixes to both branches. The important point
is applying the fix to 1.0 first. Because applying it to 1.1 first and
creating a patch and then applying it to 1.0 can cause mess. But the
vise versa may not hurt that much.

> >* 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 ?

Yeah, I like it. Adding JIRA reference number is good. And also adding
svn commit version to JIRA issues while closing them is also good!

> >* 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?

We need to agree on this. If we're speaking about code changes, svn
logs may be enough. But structure changes may need extra doco. And
doco is always good.. :)

> >*** 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? ;-)

I agree for writing unit tests. And for style, Alex has added his
eclipse formatter's xml to trunks. It may be a starting point. And yes
we need a style doco ;-)

> Btw, we badly need some doco !
> >Cheers,
> >
> >--
> >Ersin
> >
> >
> -- Emmanuel

View raw message