On 15.04.2013 18:12, Herbert Dürr wrote:
On 2013/04/15 4:00 PM, Andre Fischer wrote:
I would like to change the build type of the Windows7 nightly build from
incremental to clean.
Reasons in favor of a clean build are:
- Developers don't have to know if a change is incompatible and thus
have to (somehow) trigger a clean build.
- Developers don't have to learn how to trigger a clean build.
- We avoid very subtle bugs that are introduced when an incremental
build is made on incompatible changes.
Issues 122047 and 122048 may be caused by such a broken build: the
office works in general, only commands are mapped to the wrong ids.
It is not acceptable to have builds that we can not rely on.
I'm having a deja vue moment ;-)
[1] http://markmail.org/message/lpprmeahwurvepx5
No, this thread does not apply. It was centered on the idea to change
the bootstrap file and thus to affect every build, not just the ones on
the buildbot. I don't want to change any files in SVN, only the
buildbot setup.
If no one objects in the coming 72 hours then I will change the buildbot
configuration file to make clean Windows7 nightly builds. I will then
try to pinpoint and fix any build errors. Any help is appreciated.
As Andrew pointed out in his mail he prefers an incremental build on
the w7bot for several reasons such as problems with hung processes and
wrong dependencies that currently have to be cleaned out manually by
him, as he is the only one with machine level access. So forcing a
clean build would add additional work on him as volunteer. I trust
Andrew's assessment.
I am thankful for your and Andrew's work but you describe a problem with
the current process, not with clean builds. We have to make this
process more transparent. It has to be documented and understood by
more than one or two people. If there are known problems with our build
then we have to fix them. And if these are buildbot-only problems that
nobody else can reproduce on other machines then we have to think about
setting them up new or differently.
Server load was a another serious concern.
Regarding the argument that a buildbot should always do a clean build
whereas builds outside of that system should default to be
incremental: There is some merit to the concept that the buildbot
shouldn't always have to use some extra steps that the default build
does not do.
Firstly, builds do not default to incremental. Clean or incremental
depends on whether or not the user or the buildbot deletes old build
artifacts prior to building.
Secondly, we have to decide what we need the buildbots for. If it is
only to check that modified files still compile, then we can setup the
buildbot very differently to save a lot of time (no linking, no creation
of installation sets). But if we want to use the installation sets for
functional verification (does the modification not only compile but
really fix the problem) then buildbots have to produce reliable
results. It is better when the build fails (because then we know that
it failed) than to complete but contain subtle build errors (because
then we do NOT know that it failed).
I prefer the second option and it seems obvious to me that we need clean
builds for that.
I have started to collect the available documentation on the buildbots
[1] but many parts are missing. For example I have not yet found much
on the buildbot configuration file. Anyone who knows more, please
update the wiki page.
Anyone considering a change to the configuration file [2] is well
advised to get familiar with its extensive documentation [3] provided
by the buildbot project first. Every slave-bot only has about a dozen
steps...
Do you have anything on your mind in particular?
Maybe you can help with that?
BTW, was that a -1 or a 0 to my proposal?
-Andre
[2]
https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/openofficeorg.conf
[3] http://docs.buildbot.net/current/manual/configuration.html
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
