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.
On 05/13/2013 05:43 PM, Nick Coghlan wrote:
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.
It turns out I changed the way I was using the milestone field to track this without actually announcing the change in the meaning of that field. The dangers of making decisions on IRC when not everyone is there :)
So, the way the target milestone field now works:
A target milestone of "---" means "maybe, someday, we're still thinking about it". (time to availability is conceivably in years, unless we just haven't triaged it yet)
A target milestone of "1.0" means "this will be implemented before we declare any release to be the 1.0 release" (time to availability should be measured in months)
A target milestone of some particular "0.x" means the bug has been assigned to be included in that particular release (time to availability should be measured in weeks)
Occasionally bugs in the last category will be bumped to the next release, although we'll try to avoid that by only moving them from 1.0 to 0.x once we're confident they can be implemented in that time frame.
Cheers, Nick.
----- Original Message -----
From: "Nick Coghlan" ncoghlan@redhat.com To: beaker-devel@lists.fedorahosted.org Sent: Wednesday, June 5, 2013 1:10:09 PM Subject: Re: [Beaker-devel] The march towards Beaker 1.0
On 05/13/2013 05:43 PM, Nick Coghlan wrote:
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.
It turns out I changed the way I was using the milestone field to track this without actually announcing the change in the meaning of that field. The dangers of making decisions on IRC when not everyone is there :)
So, the way the target milestone field now works:
A target milestone of "---" means "maybe, someday, we're still thinking about it". (time to availability is conceivably in years, unless we just haven't triaged it yet)
A target milestone of "1.0" means "this will be implemented before we declare any release to be the 1.0 release" (time to availability should be measured in months)
A target milestone of some particular "0.x" means the bug has been assigned to be included in that particular release (time to availability should be measured in weeks)
Ok Just to be clear, are we talking about the 'Target Milestone' drop down, or the 'Flags', or both ?
Occasionally bugs in the last category will be bumped to the next release, although we'll try to avoid that by only moving them from 1.0 to 0.x once we're confident they can be implemented in that time frame.
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) _______________________________________________ Beaker-devel mailing list Beaker-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
On 06/05/2013 01:19 PM, Raymond Mancy wrote:
----- Original Message -----
From: "Nick Coghlan" ncoghlan@redhat.com To: beaker-devel@lists.fedorahosted.org Sent: Wednesday, June 5, 2013 1:10:09 PM Subject: Re: [Beaker-devel] The march towards Beaker 1.0 So, the way the target milestone field now works:
A target milestone of "---" means "maybe, someday, we're still thinking about it". (time to availability is conceivably in years, unless we just haven't triaged it yet)
A target milestone of "1.0" means "this will be implemented before we declare any release to be the 1.0 release" (time to availability should be measured in months)
A target milestone of some particular "0.x" means the bug has been assigned to be included in that particular release (time to availability should be measured in weeks)
Ok Just to be clear, are we talking about the 'Target Milestone' drop down, or the 'Flags', or both ?
The RH internal flags are just used for the "---" -> "1.0" transition. Once something has been flagged for 1.0 moving it around between 0.x releases is up to us without messing with the flags any further. While the final call on which release we target for a fix or feature does rest with me, I'm definitely open to suggestions about things that should be included and things which should be delayed (usually because they end up being harder than we expected), either here or through the internal planning meetings.
Integrating a couple of different internal processes with each other *and* a public open source project is certainly an interesting exercise, so I expect it's going to be quite a while before we get to something that's relatively stable :)
Cheers, Nick.
beaker-devel@lists.fedorahosted.org