Bazaar Buildbot, now For Real(TM)

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vincent Ladeuil wrote:
> 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.

I think it would be good to run a test suite across them. I'm not sure
that it is really what we want as the "nightly installer".

Note that what Sidnei proposed is pretty much exactly what people get
*today* when they run bzr-nightlies. You get the nightly release of
bzr.dev, and you run with whatever the last release of
bzr-svn/bzr-gtk/qbzr/etc was.

Though I thought there was some people requesting nightlies of plugins.
Mostly because 'bzr-svn' has a "require_version()" so when bzrlib
decides to bump its internal 'api_version' data, it causes bzr-svn to
forcibly stop working until you get a new version of bzr-svn that sets
the 'no, I really am compatible' flag.

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

I certainly don't think that most of our plugins follow the same
stability guarantee that "trunk always passes the full test suite". If
only because their test suites are ad hoc, (most plugins have really
poor automated tests.)


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

At present the build chain doesn't do any tagging that I can see. It is
something we need to update.

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

Well, my personal thought was to actually run the test suite *from* the
installer. Just to work out any packaging bugs at the same time. (So
build the installer, install it, run the test suite.)

I do think we have a couple tests that require the original working
tree, though.

...

>     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.

Why? It would certainly be nice to get bzr to have an auto-update style
functionality.

> 
>     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.
> 

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkp8l04ACgkQJdeBCYSNAAPajwCfezaeR9cLSeMkwlWkSk6bThHP
QpYAoNMnDF2cYd2os5U82r/R7+OFS93X
=Q2u4
-----END PGP SIGNATURE-----