How to avoid build breaks

[Raymond Feng <en...@gmail.com>]

Hi,

As being discussed on the other thread, we all agree that it's very 
important to keep the trunk build successfully all the time. There are 
different factors that contribute to the build breaks:

1) Changes are checked in without a full clean build before the commit

We should always try to run a full build before we check in the changes. 
Don't assume one line of change is safe :-).

2) Some files are missing from the commit (for example, forget to select the 
new files...)

Mistakes can happen and we should pay more attentions. Some svn tools can 
help. For example, run "svn stat" to see if some files are missed after the 
commit. The key is to get notified if the break happens and try to fix it 
ASAP.

3) Some intermittent errors

This is tricky. It can be timing issue, environment issue. We can disable 
the test with @Ignore("JIRA#") pattern while we investigate.

4) Code behaviors that are OS or JDK specific

This is tricky. By my experience, some of the issues lay in our code, for 
example, Linux may give us a different order for the file list in a jar or 
entries in a map. Reproduce the problem and debug often reveal bugs in our 
code (such as conflicting artifacts). Others may be related to some JDK 
bugs.

Thanks,
Raymond 

Re: How to avoid build breaks

[Luciano Resende <lu...@gmail.com>]

On Fri, Jul 25, 2008 at 4:07 PM, ant elder <an...@gmail.com> wrote:
>
>
> On Fri, Jul 25, 2008 at 9:44 PM, Raymond Feng <en...@gmail.com> wrote:
>>
>> Hi,
>>
>> As being discussed on the other thread, we all agree that it's very
>> important to keep the trunk build successfully all the time.
>

I don't think it's a must to have it successfully building at all times.

> Builds will break its a fact of life, and this is especially true in an open
> source development environment with a diverse range of committers and with
> Tuscany as it has got so big. Don't get take this wrong sure its better when
> the trunk builds cleanly but I'd like to understand who is this "very
> important" to and is there something else we could be doing to make things
> better for them.
>

I agree that builds will break, and I have done that multiple times.
But I also expect that, if the build breaks, the person that caused
the build issue would take a look and try to fix it. What I don't
think it's  desirable is to get a broken build for several weeks, I
think this can affect the overall community.

> From my perspective as an active developer on Tuscany although the trunk has
> been getting broken a bit recently that hasn't been causing me so much
> inconvenience as its usually easy enough to work around things by using mvn
> -fn or -Dmaven.test.skip=true or commenting something out locally. It takes
> a little more work but i think its worth it as we've seen in that past
> people get put off when they're made to feel scared to commit in case they
> do something wrong.
>

Agree that we can easily workaround it, and we should document this
for others as well. The issue is when there are dependencies on the
broken modules.

> Tuscany builds take ages so I often don't do a full build before checking
> things in. If i've just made changes in say the jms binding why build the
> demos, tutorials, and vtests when none of those use JMS? If I just change an
> itest why build anything else at all? I often work like this and (fingers
> crossed) hardly ever break the build, and this is also the way our maven
> incremental builder works.
>
> I don't think trunk breaks will be bothering our users much as they mostly
> use the releases or published snapshots.
>
> If there are some people who really need clean builds then maybe we should
> look at something like a more stable branch which we do try hard to keep
> building cleanly all the time. Or if we did releases more often like we did
> back with the monthly 0.9x releases then we'd have those more stable
> branches anyway and reasonably closely tracking the trunk changes.
>
> Newer developers to Tuscany may have more trouble with trunk breaks but they
> first probably have more trouble battling with maven to get the vast array
> of dependencies downloaded successfully from the repositories.
>
> Maybe Tuscany is just getting too big for the current structure and one
> option could be to look at splitting things up somehow into more smaller
> discrete functional parts which may make it easier to work on?
>
>    ...ant
>
>



-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: How to avoid build breaks

[ant elder <an...@gmail.com>]

On Fri, Jul 25, 2008 at 9:44 PM, Raymond Feng <en...@gmail.com> wrote:

> Hi,
>
> As being discussed on the other thread, we all agree that it's very
> important to keep the trunk build successfully all the time.


Builds will break its a fact of life, and this is especially true in an open
source development environment with a diverse range of committers and with
Tuscany as it has got so big. Don't get take this wrong sure its better when
the trunk builds cleanly but I'd like to understand who is this "very
important" to and is there something else we could be doing to make things
better for them.

>From my perspective as an active developer on Tuscany although the trunk has
been getting broken a bit recently that hasn't been causing me so much
inconvenience as its usually easy enough to work around things by using mvn
-fn or -Dmaven.test.skip=true or commenting something out locally. It takes
a little more work but i think its worth it as we've seen in that past
people get put off when they're made to feel scared to commit in case they
do something wrong.

Tuscany builds take ages so I often don't do a full build before checking
things in. If i've just made changes in say the jms binding why build the
demos, tutorials, and vtests when none of those use JMS? If I just change an
itest why build anything else at all? I often work like this and (fingers
crossed) hardly ever break the build, and this is also the way our maven
incremental builder works.

I don't think trunk breaks will be bothering our users much as they mostly
use the releases or published snapshots.

If there are some people who really need clean builds then maybe we should
look at something like a more stable branch which we do try hard to keep
building cleanly all the time. Or if we did releases more often like we did
back with the monthly 0.9x releases then we'd have those more stable
branches anyway and reasonably closely tracking the trunk changes.

Newer developers to Tuscany may have more trouble with trunk breaks but they
first probably have more trouble battling with maven to get the vast array
of dependencies downloaded successfully from the repositories.

Maybe Tuscany is just getting too big for the current structure and one
option could be to look at splitting things up somehow into more smaller
discrete functional parts which may make it easier to work on?

   ...ant