[Linux-HA] More thoughts about 2.1.1 - SCHEDULE CHANGE - 23 July,
beekhof at gmail.com
Fri Jul 13 10:55:22 MDT 2007
I thoroughly agree with what you are proposing.
You may find the attached script (my own work) useful for cherry-picking
patches from one mercurial repo to another.
In particular, it preserves the log, timestamp and author which is useful
when trawling through changesets at a later date. It uses this information
to detects when changesets have already been applied and skips them.
Basic usage for importing patches from 'dev' into 'test' is:
# cd test
# hgpatch ../dev
Although I encourage the use of --blacklist <filename> so that you are not
re-prompted to apply skipped patches next time.
Oh, and it probably requires bash.
On 7/13/07, Alan Robertson <alanr at unix.sh> wrote:
> 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:
> or here http://hg.linux-ha.org/test/archive/tip.tar.gz
> You can see the patches and so on in this release here:
> 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 <alanr at unix.sh>
> "Openness is the foundation and preservative of friendship... Let me
> claim from you at all times your undisguised opinions." - William
> Linux-HA mailing list
> Linux-HA at lists.linux-ha.org
> See also: http://linux-ha.org/ReportingProblems
More information about the Linux-HA