On 10/22/2013 03:14 PM, Raymond Mancy wrote:
> *Release and upgrade process*
>
> Currently, the release process involves tagging a new release using
> tito and pushing the tag to remote beah repository. Beah releases
> happen at the same time as new Beaker releases. Beah packages are served from
This is not actually the case. It has happened before that Beah has been released
at the same time as Beaker, but that's only been because it may have relied on
features in
Beaker, or that we were just in the mood for updating (and that we used to update Beaker
every 2 weeks).
In the past, versions of Beah have been released at different times than Beaker.
AFAIK, the only issue Nick has with the Beah release process, is that essentially it
doesn't have one.
It consists of an email and an RT ticket.
They're more tightly coupled than that:
1. the beah documentation is in the Beaker repo, and versioned according
to the Beaker version
2. beah fixes and enhancements are reported in the Beaker release notes
3. We schedule beah development based on the Beaker release cycle
In addition to the specific sections Amit mentioned,
http://beaker-project.org/docs/user-guide/task-environment.html is about
beah/rhts, not Beaker itself. Several other parts of
http://beaker-project.org/docs/user-guide/writing-tasks.html are really
dependent on the version of beah/rhts/beakerlib rather than the version
of Beaker.
Amit didn't mention it in the original post, but one of the key parts of
this is figuring out how to get to the point where we can sensibly
develop and publish developmental versions of beah as alternative
harnesses, so they can be properly tested *before* we promote them to
being the default version shipped with Beaker. The same mechanism should
then allow us to experiment with an IPv6 capable version based on
Twisted 13.0.
Based on Amit's write-up, here's something that I'm thinking something
along the lines of the following might work:
1. Set up a "Related Projects" page in the Beaker docs
2. Move the beah/harness docs into the beah repo
3. Link to the beah/harness docs from the Beaker "Related Projects" page
4. Create a "develop" branch in the beah repo (no release branches at
this point, just tags)
5. Add a "beah" section to the devel guide, just noting how it differs
from the normal Beaker patch process
6. Add release notes to the beah docs
7. Change the Beaker release notes to just mention when the default
version of beah changes, and link to the beah notes for details
beah changes are currently few enough that we could likely skip the
complexity of the Beaker release notes and just have a single-file
change log that is updated before each release.
This model would potentially work for other components like
beaker-system-scan as well.
I do think we need to figure out the documentation side of things before
we can change too much on the release process side, but I'm open to
suggestions on how best to accomplish that (the above is just the idea
that first occurred to me).
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (
http://beaker-project.org/)