[Linux-HA] More thoughts about 2.1.1 - SCHEDULE CHANGE - 23 July, 2007

[Andrew Beekhof]

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:
>
> 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 <alanr at unix.sh>
>
> "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
> Linux-HA at lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
>