Hi,
I have a few things to say here, and a change of mind, which I'll
explain in more detail.
First, I appreciate the work that Andrew and Dejan and Dave and others
have gone to to get us what looks like a really solid release. Awesome
work guys!
Second, I want to apologize for not fully understanding what Mercurial
can do for us in better managing our releases. My lack of gut-level
understanding (which is now hopefully mostly past) led me to follow the
procedures we'd used in the past - which worked out OK, but weren't
optimal. In addition, I want to thank Andrew for prodding me into using
Mercurial the way it was meant to be used. Now I get it.
As a result, I now have some freedom in putting out the release which I
didn't have pre-Mercurial, because there is no need for a code freeze at
all. In spite of "getting it" there is still a bit of a learning curve
to go through here, in terms of how to get more community involvement,
and so on. No doubt I'm not not done with learning. I reserve the
right to get smarter.
Some people are concerned that we haven't put enough effort into testing
this release, and are don't have as much confidence as I think they
should in this process. Rather than arguing that I know what I'm doing
(which I think I do), I'd rather just delay the release, and put in some
more testing, and shore up that confidence through more testing, and
more opportunity for others to do testing.
To accommodate this, I've decided to delay the release for one week.
The official release date for 2.1.1 is now 23 July, 2007.
You can get the latest source for this release here:
http://hg.linux-ha.org/test/archive/tip.tar.bz2
or here http://hg.linux-ha.org/test/archive/tip.tar.gz
You can see the patches and so on in this release here:
http://hg.linux-ha.org/test/
Here are the proposed rules of engagement for this one week period:
- Each additional changeset will have a bugzilla for it, and will be
linked to by the bugzilla, and the changeset on 'dev'
will link to the bugzilla entry.
- Every proposed bug fix will be announced on the -dev mailing list
- Every proposed changeset will be inspected by myself and the
community before being accepted.
- Each accepted changeset will be announced on the -dev list
right after it has been pushed to the 'test' repository
- I have final authority on whether a given fix will go in
during this time.
Here are some of the criteria I will use to decide if a fix will go in:
- Does it fix a regression?
Fixes that fix regressions will be given priority
- Does it fix something that would cause data damage?
Fixes that fix data damage will be given high priority.
- Is the patch "obviously harmless"? - like a documentation
or release description change, or comments, or similar.
- Will it require starting our long-running tests over?
Things which will require this will likely have to wait for
the next release, unless they are likely to destroy data.
- Is it something that our long-running CTS tests don't test for?
If so, then we won't have to start tests over.
For example, if it's a *BSD-only fix, or a GUI fix, and
if it's early enough to get reasonable manual testing, then
I may take it.
These are not exhaustive, but indicative of the criteria I will use.
If we find too many regressions or probable data damage fixes (which is
unlikely), then we would likely have to delay the release.
--
Alan Robertson <[EMAIL PROTECTED]>
"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
