On Feb 9, 2007, at 2:38 PM, Max Hofer wrote:
Hi Andrew,
Thanks for pointing out the new release schema.
On Monday 29 January 2007 19:30, Andrew Beekhof wrote:
Good morning sports fans.
Over at Heartbeat Central we've been talking and have decided to do
releases a little differently from now on.
If have a question.
Would it possible to have a long-time-release (LTR). This would be a
Feature (Minor) Release choosen by you (or whoever is coordinating
the project).
<gratuitous_plug>
If you purchase a Novell/SUSE support contract then I'll be forced to
provide you with such bugfixes for a number of years :-)
</gratuitous_plug>
That said, I understand many people can't/won't run SLES for various
reasons, so there is some merit in your request.
However, I'd like to see how the proposed arrangement works out first
before committing to anything else.
2.1 (when it comes out) should still be receiving updates until at
least the end of the year. Perhaps at that time it will be apparent
that Current+LTR is a better alternative than Current+Previous. On
the other-hand, if the number of required bug-fixes is few then
Current+Previous may be plenty for people.
The LTR would not get any new features but just backports of
bugfixes from future minor releases.
The point in making such LTR is to avoid major changes in running
systems. So admins would try and stick to a LTR and decide to
upgrade minor versions of the LTR only if really needed.
Understood. That was the starting point for the proposal I made.
However there needs to be a balance between this and the reality that
we're only really paid to work on the current version (unless there
is a SLES support contract involved of course :-)
Clairly it would make no sense to define too many LTR (each 5
minor releases? .. only a suggestion).
Is there a way to track down bugfixes on the current source? I mean
a clean separation of "this patch is a new feature" or "this is a
bugfix"?
Anything related to a Novell or OSDL bugzilla entry includes the bug
number in the commit message.
With that in mind, it is our intent that this is what you can expect
from the Heartbeat team:
Architectural (aka. Major) Releases:
* Contents: Architectural changes
* Frequency: As required but hopefully not often
* Supported Version: Current and previous (for a limited period)
* Release Criteria: 5000 CTS Iterations of a 4 node cluster or
equivalent^
Feature (aka. Minor) Releases:
* Contents: New features + bug-fixes
* Frequency: Three releases per year
* Supported Versions: Current and previous
* Release Criteria: 5000 CTS Iterations of a 4 node cluster or
equivalent^
* Notes:
- The timing will probably be March, July and November
- We may at times decide to skip a feature release, in such cases
we will make
an annoucement to this effect
- Each feature release will have its own (numbered) Hg repository
on http://hg.linux-ha.org
Bug (aka. Point) Releases:
* Reason: Urgent bug-fixes and/or new resource agent scripts
* Frequency: Monthly (providing there are bug-fixes pending release)
* Supported Versions: Current only
* Release Criteria: 1000 CTS Iterations of a 4 node cluster or
equivalent^
* Notes:
- No new features
- If no new bugs have been fixed we'll just make an announcement
explaining
this and not put out a release.
- Each bug release will be a tag in the Hg repository of it's
Feature release
- If every month becomes too much overhead for me, we may move to
bi-monthly releases
^ eg. an 8 node cluster would need somewhere in the order of 50%
less iterations to perform an equivalent workload
So, given all that, it is my hope that come March we will be able to
put out 2.1.0 and from then on follow the above strategy. We will
then review this approach every so often to ensure it is still
appropriate.
regards,
Andrew
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
