Bazaar Buildbot, now For Real(TM)

[Vincent Ladeuil]

Redirecting to the list for wider exposure.

>>>>> "Sidnei" == Sidnei da Silva <sidnei.da.silva at canonical.com> writes:

<snip/>

    Sidnei> There needs to be some agreement here.

Right, hence we need everybody involved, core bzr devs as well as
plugin authors.

    Sidnei> What would generally be useful as a nightly build?

    Sidnei> - I suspect a nightly build with bzr.dev + trunk of
    Sidnei> plugins might be slightly too unstable, and only
    Sidnei> useful in the sense that building it can reveal
    Sidnei> potential brokenness on the build process itself.

I disagree here, apart from bugs in the build process that needs
to be fixed as soon as they appear anyway, the goal here will be
to alert plugin authors early about failures in their trunk and
reassure them, early too, once they have fixed the problem.

That would work best for plugins that have a significant test
suite of course.

    Sidnei> - I am mostly confident that a nightly build with
    Sidnei> bzr.dev + release version of plugins would be useful
    Sidnei> as a nightly build.

That would provide the equivalent of the trunk to the windows
users *without* the constraint to build the extensions themselves
or any other binaries requiring a toolchain. So yes, definitely a
big plus but I'd like feedback here as I think that many plugin
authors will be happy if we just package their trunk if it works
at the time bzr is released. 

So release version of plugins needs to be clarified: is it
official in the sense that the plugin author make a dot release
or can it just be a revno on trunk known to be good to package
with bzr ?

    Sidnei> This release should be tagged (both in the download
    Sidnei> filename and in other possible ways) with the
    Sidnei> revision number of bzr.dev

nightly builds for the source already do that right ?

    Sidnei> - I'm 100% confident that nightly build of
    Sidnei> bzr-release + release version of plugins is useless,
    Sidnei> since everything would be frozen.

:-)

    Sidnei> Also, installer builds should depend on the tests
    Sidnei> passing.

Sure. 

Err, no wait, you realize the tests aren't passing for windows
right now ? You are not seriously proposing that we should wait
until we have a passing test suite to build the windows
installers ? :-D

Of course we should make the test suite passing and from there
refuse to build the installers, but until we have such a test
suite, let's build the installers, ok ?

    Sidnei> My proposal thus for what each builder should do is:

    Sidnei> - Replacing the 4 experimental builds we have right now by 3 official builds:
    Sidnei>   - bzr.dev + trunk of plugins runs on every commit, installer is not
    Sidnei> uploaded anywhere
    Sidnei>   - bzr.dev + release of plugins runs nightly, installer is uploaded
    Sidnei> to a 'nightly' release area
    Sidnei>   - bzr-release + release of plugins runs on-demand, only once for
    Sidnei> each release to create the official installer which then gets uploaded
    Sidnei> to the official location.

Right, I thought that whatever is used to define the builders
should end up in some file being versioned in bzr.dev[1]. At
release time, the RM will had the final word and can request a
build from its release branch instead of trunk. So really that
third build is just a variant of the second one.

    Sidnei> Each builder would:

    Sidnei>   - Set up the environment for building, with all the
    Sidnei>   dependencies in place

That includes isolating the slave from the user running it so
that each build can control precisely which plugins are taken
into account.

    Sidnei>   - Run the tests for bzr and each of the plugins -
    Sidnei>   If all the tests pass, build an installer.

Right, that's mostly what exists today except for the tests
(which needs discussion but should be something like 'make
check' anyway).

<snip/>

    Sidnei> I have a slightly different proposal.

    Sidnei> With the newly-released 'product release finder' [1],
    Sidnei> we should be able to create a series named 'nightly'
    Sidnei> on Launchpad, and have Launchpad crawl directory of
    Sidnei> the buildmaster containing the nightly releases. That
    Sidnei> way we can use the 'DirectoryUpload' functionality of
    Sidnei> the buildbot to copy the installers from the slave up
    Sidnei> to the master.  Then Launchpad would find the
    Sidnei> installers and make them happily available from the
    Sidnei> same location as the official builds, but attached to
    Sidnei> a series named 'nightly'.

Fine with me as long as that's used only for the nightlies and
not for the releases.

    Vincent

[1]: Strictly speaking there should be a branch derived from
bzr.dev containing only the windows distribution related files
including the one that define what plugins/version should be
packaged. In the same vein we should have a branch for each
distribution: debian, Ubuntu, OSX, Fedora, etc.