Beaker has been doing 0.x releases for a long time. We've been talking
about the release later this month being 1.0, but before we declare
we've reached that milestone, I'd really like us to be at the point
where someone could reasonably expect to grab the Beaker RPMs from
beaker-project.org, and using just our documentation, set up and start
running their own Beaker instance, including writing new tests using
either beah or autotest.
We're not there yet, and we're not going to get there this month, so the
next release will be 0.13 and we'll continue with regular 0.x releases
until we're happy we have something we consider worthy of the "Beaker
1.0" title. I don't think we're all that far away - we may need a 0.14,
but I'll be surprised if we see 0.15.
For planning purposes, I'd like to keep marking the backlog as "1.0" -
the 0.x releases will then just be snapshots that make useful chunks of
functionality available to users, rather than having to wait until we're
done with everything we want to include for the 1.0 milestone.
This will throw out the currently predicted releases in
http://beaker-project.org/dev/proposals/handling-large-installations.html and
the associated design proposals, but I'm not really worried about that.
In some respects, it works out better, as it means we can add the
"Effective Job Priorities" proposal to our targets for Beaker 1.0, and
that's the *real* objective of several of the changes we're currently
working on.
Once we're happy we know what we would like to include in 1.0, then I
can go back and adjust those design proposals and the tech roadmap
accordingly.
Based on the off-list discussions, here's what I would like to aim for
as our 1.0 milestone:
* The Effective Job Priorities design proposal (and its dependencies)
* Full Fedora compatibility (including the test suite)
* A stable alternate harness API (ideally with the corresponding
autotest patches merged on their side)
* A harness independent reservesys mechanism
* Moving any remaining hardcoded Red Hat specific settings into
configuration files
* Documentation improvements, including
* an architectural guide that at least explains all of Beaker's
external interfaces
* an explanation of the local watchdog hooks
* more general advice on job design (including effectively using
features like the job matrix)
* Self tests that exercise beah, the legacy harness API and the new
harness API
* Having a public page giving at least basic info on how Beaker is used
at Red Hat
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Test Automation Team Lead
Beaker Development Lead (
http://beaker-project.org/)
PulpDist Development Lead (
http://pulpdist.readthedocs.org)