Re: buildbot setup

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 30 Jun 2010 23:34:45 +0200 Lennart Borgman <lennart.borgman@gmail.com> wrote: 

LB> 2010/6/30 Ted Zlatanov <tzz@lifelogs.com>:
>> We could use a tag.  But as I mentioned there's a lot of complexity to a
>> "success" especially if we care about more than one platform and set of
>> libraries.

LB> Would it be possible to write a web page with something like this below?
LB>   To get last successful builds:
LB>     GNU/Linux:  bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk -r nnnnn1
LB>     w32: bzr ... -r nnnn2
LB>     ... etc

Buildbot can do that, I think.  I don't think it's *useful*.  Do you
expect users to go to this web page, read it, copy the revision, then do
a checkout?  They are just going to check out the trunk and complain if
it doesn't work.

On Thu, 01 Jul 2010 03:43:06 +0200 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> I'm not crazy about using a branch to announce a build success.

SM> That's OK.  You can also use a tag, of course.

I'm not crazy about using a DVCS (specifically the Emacs Bazaar repo) to
announce build results.  My point is that it clutters the DVCS with
extraneous information; if we publish builds with tags then why not
publish a "best-performing-this-year" tag based on profiling results?

>> How do we test multiple platforms and coordinate a push when
>> they are all successful?

SM> The "tested" branch should correspond to "no known problem during
SM> build&test", so if there's a problem on one platform it should probably be
SM> considered as a global failure.  But I don't think such problems matter
SM> much at this stage.

I do.  It may work for one platform but soon enough we'll have 20 jammed
into this system and then it will just be confusing for users and
developers alike.  See the CPAN testers reports
(http://cpantesters.org/distro/E/Every.html for example).

>> I think it's better and less confusing to simply announce failures
>> through another channel, perhaps as bugs.  Then silence will be the
>> default, which is good for everyone, and builds will not have any
>> effect on the repository.

SM> Many people who track Emacs's trunk don't read the mailing-list (or not
SM> regularly enough) and they get annoyed when the build fails.

OK, I think I see the misunderstanding.  You want something for the
users.  I want something for the developers that can actually fix the
problem and read the mailing list.  My target for reporting a broken
build is everyone who comitted since the last successful build and
perhaps it makes sense to simply CC them on the report.  If users
benefit by tracking these announcements, great, but I don't think they
should be targeted by an automatic build system.

Ted