Re: [boost] [Boost-users] [filesystem][xpressive] Hotfix patches available for 1.36.0
On Fri, Aug 29, 2008 at 1:36 PM, Eric Niebler <eric@boostpro.com> wrote:
Michael Marcin wrote:
If the fixes are not critical enough to justify making a point release than they should wait until the next release.
So you're against hotfixes. <shrug> I would say, take the hotfix if you are experiencing the problem addressed by the hotfix. Otherwise, wait for the next release.
-- Eric Niebler BoostPro Computing http://www.boostpro.com
For some of us the answer is not <shrug>. Are hotfixes really the way forward? Not to pick on filesystem, threads or xpressive, but hotfixes are a bit difficult to manage in a coporate environment. It's hard enough to get boost accepted/updated without having to defend against people who argue that it's too risky to use boost due to "inadequate quality control" e.g. "boost 1.35.0 didn't work out of the box (windows thread bugs, filesystem compilation errors, etc.), boost 1.36.0 doesn't work out of the box, and there are no dot-releases planned". It really helps if there is a perception of stable, high quality, official, numbered releases. - Mat
Mat Marcus wrote:
On Fri, Aug 29, 2008 at 1:36 PM, Eric Niebler <eric@boostpro.com> wrote:
Michael Marcin wrote:
If the fixes are not critical enough to justify making a point release than they should wait until the next release. So you're against hotfixes. <shrug> I would say, take the hotfix if you are experiencing the problem addressed by the hotfix. Otherwise, wait for the next release.
For some of us the answer is not <shrug>.
That wasn't my answer. See above.
Are hotfixes really the way forward? Not to pick on filesystem, threads or xpressive, but hotfixes are a bit difficult to manage in a coporate environment. It's hard enough to get boost accepted/updated without having to defend against people who argue that it's too risky to use boost due to "inadequate quality control" e.g. "boost 1.35.0 didn't work out of the box (windows thread bugs, filesystem compilation errors, etc.), boost 1.36.0 doesn't work out of the box
1.36.0 works out of the box. But I get your point.
, and there are no dot-releases planned". It really helps if there is a perception of stable, high quality, official, numbered releases.
Understood. You want point releases. We don't have the resources right now. We are busy flushing the bugs out of a new release process that should give us quarterly releases. This is in response to feedback such as yours. Beman has said on this list that the issue of point releases will be reconsidered once we are meeting our quarterly release schedule. In the mean time, corporate users of Boost have a few options: (1) ignore hotfixes, (2) pay for support, (3) consider donating the testing resources we would need to produce point releases. In the future, I could imagine staggered releases ... something like a 3 month full release cycle, followed by 1 or 2 months to put out a point release. With extra resources, these two could happen in parallel, of course. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
Mat Marcus wrote:
On Fri, Aug 29, 2008 at 1:36 PM, Eric Niebler <eric@boostpro.com> wrote:
Michael Marcin wrote:
If the fixes are not critical enough to justify making a point release than they should wait until the next release. So you're against hotfixes. <shrug> I would say, take the hotfix if you are experiencing the problem addressed by the hotfix. Otherwise, wait for the next release.
For some of us the answer is not <shrug>.
That wasn't my answer. See above.
Are hotfixes really the way forward? Not to pick on filesystem, threads or xpressive, but hotfixes are a bit difficult to manage in a coporate environment. It's hard enough to get boost accepted/updated without having to defend against people who argue that it's too risky to use boost due to "inadequate quality control" e.g. "boost 1.35.0 didn't work out of the box (windows thread bugs, filesystem compilation errors, etc.), boost 1.36.0 doesn't work out of the box
1.36.0 works out of the box. But I get your point.
, and there are no dot-releases planned". It really helps if there is a perception of stable, high quality, official, numbered releases.
Understood. You want point releases. We don't have the resources right now. We are busy flushing the bugs out of a new release process that should give us quarterly releases. This is in response to feedback such as yours. Beman has said on this list that the issue of point releases will be reconsidered once we are meeting our quarterly release schedule. In the mean time, corporate users of Boost have a few options: (1) ignore hotfixes, (2) pay for support, (3) consider donating the testing resources we would need to produce point releases.
As I've already said, those "hotfixes" presently appear to be *totally untested*. I'd be happy to be proved wrong -- just point me at a tables of test results for 1.36.0 + hotfixes and I'll shut up. But if hotfixes are indeed untested, then I don't understand why creating 1.36.1, which is basically 1.36.0 + hotfixes in a single archive, would require *any testing resources at all*. Can you clarify? - Volodya
Vladimir Prus wrote:
Eric Niebler wrote: <snip>
In the mean time, corporate users of Boost have a few options: (1) ignore hotfixes, (2) pay for support, (3) consider donating the testing resources we would need to produce point releases.
As I've already said, those "hotfixes" presently appear to be *totally untested*.
They are tested in trunk, which hasn't yet diverged significantly from the 1.36 release.
I'd be happy to be proved wrong -- just point me at a tables of test results for 1.36.0 + hotfixes and I'll shut up.
You're right, no such testing is done officially. It is the responsibility of each developer to test their hotfix with the release locally before posting it, but that is not enforced.
But if hotfixes are indeed untested, then I don't understand why creating 1.36.1, which is basically 1.36.0 + hotfixes in a single archive, would require *any testing resources at all*.
Can you clarify?
You raise a fair point. My feeling is we couldn't in good faith issue an official point release without testing it. Hotfixes aren't (yet) official Boost releases and so meet a different criteria. That's a weak justification, but considering that we have limited resources, it seems like a good-faith effort to quickly get fixes into hands of users that need them. Perhaps we need a bold disclaimer stating that hotfixes are not official Boost releases and that buyer beware. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
But if hotfixes are indeed untested, then I don't understand why creating 1.36.1, which is basically 1.36.0 + hotfixes in a single archive, would require *any testing resources at all*.
Can you clarify?
You raise a fair point. My feeling is we couldn't in good faith issue an official point release without testing it. Hotfixes aren't (yet) official Boost releases and so meet a different criteria. That's a weak justification, but considering that we have limited resources, it seems like a good-faith effort to quickly get fixes into hands of users that need them.
Perhaps we need a bold disclaimer stating that hotfixes are not official Boost releases and that buyer beware.
Why we can call hotfixes "unofficial" and cannot call an archive file unofficial? We can even give it a name such as 1.36.unofficial-hotfixes-1 to make it absolutely clear. While I can understand why we cannot do regular testing on hotfix release due to resource constraints, why making hotfixes as hard to get as possible? Put yourself in a position of a user -- you have "official" 1.36.0 which is known to have serious issues, and you have "unofficial" hotfixes -- how does one decide which one to use? If we believe that 1.36.0+hotfixes is actually better than 1.36.0, then it's official position, and should be expressed explicitly. If we truly believe that 1.36.0+hotfixes is high-risk combination, then should we actually provide hotfixes? - Volodya
On Fri, 2008-08-29 at 15:34 -0700, Eric Niebler wrote:
Understood. You want point releases. We don't have the resources right now. We are busy flushing the bugs out of a new release process that should give us quarterly releases. This is in response to feedback such as yours. Beman has said on this list that the issue of point releases will be reconsidered once we are meeting our quarterly release schedule. In the mean time, corporate users of Boost have a few options: (1) ignore hotfixes, (2) pay for support, (3) consider donating the testing resources we would need to produce point releases.
I thnk the new branching policy is fine as far as it goes, and I think the long lived (cross release) release branch makes perfect sense. The proposed patching process otoh makes no sense to me. The hotfix process as described seems to eschew use of subversion and the boost testing system in favour of a completely manual process of creating,releasing, testing and applying the patches. The patches if I understand correctly aren't even beased against the release to which they are supposed to apply. This seems to create work for everybody while reducing quality. What is wrong with an approach where a branch is made from the release branch at the time of release (or later, from the tag). I'll call this branch "maintenance" in the following examples. Note that this branch need not be made if teh release is "perfect". Also note that this is eassentially a whole of boost equivalent to a per-lib approach Robert Ramey suggested earlier: Boost developer wishes to make a change to fix a "production issue" - possibly by applying a user supplied patch against the release version. The change is made directly on the developers local copy of the maintenace branch, locally tested to the developers satisfaction then applied to the maintenance branch. It may or may not get tested there (see note 1). The developer also merges the change into trunk. A boost user wants to get all bug fixes applicable to the release they are using. The user pulls the head of the maintenance branch for that release. The user then runs the tests and generates library status locally. A user wants to find and apply the patch for a specific issue only. Use trac, find the change that addresed the issue, get the patch. This is involves no additional work for the developer to produce patch release docs etc and gives full traceability. Note 1: Ideally tests would be run automatically on the maintenance branch and the results published regularly. Users could simply look at the latest results and decide whether to use the maintenance branch head or not. However, as test result publication is currently a major resource bottleneck, this would depend on the donation of additional resources. For now, a maintenance branch that requires users to run their own tests, but makes doing so easy, seems to be a step forward from what is currently available.
In the future, I could imagine staggered releases ... something like a 3 month full release cycle, followed by 1 or 2 months to put out a point release. With extra resources, these two could happen in parallel, of course.
That could work - is it reasonable to close the release branch for changes from trunk for say 1 month after a release, and instead use it as a "maintenance" branch? This would avoid any extra testing load but (hopefully) allow the important x.y.1 point release to catch any "oops" problems to be tested and released. Arguably this is just extending something similar to the pre-release checkin policy after the release, which perhaps shouldn't be necessary. But the fact is that until boost.org has anointed code as "released" a lot of users won't touch it (with good reason). That could be changed with a high qaulity and well publicised beta, that is left in beta for "long enough" - but in relaity this is just a labeling issue for the releases more than a change to the procedure I've just suggested (1.36.0 would be 1.36 beta, 1.36.1 would be 1.36 release). Regards Darryl PS I do think the 1.36 release process was a big step forward and has worked really well. Thanks to all concerned.
on Fri Aug 29 2008, "Mat Marcus" <mat-lists-AT-emarcus.org> wrote:
For some of us the answer is not <shrug>. Are hotfixes really the way forward? Not to pick on filesystem, threads or xpressive, but hotfixes are a bit difficult to manage in a coporate environment. It's hard enough to get boost accepted/updated without having to defend against people who argue that it's too risky to use boost due to "inadequate quality control" e.g. "boost 1.35.0 didn't work out of the box (windows thread bugs, filesystem compilation errors, etc.), boost 1.36.0 doesn't work out of the box, and there are no dot-releases planned". It really helps if there is a perception of stable, high quality, official, numbered releases.
Hi Mat, With apologies for the sales message: my company's Enterprise Support program offers the closest possible equivalent of point releases for Boost. We might be able to help you. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Sat, Aug 30, 2008 at 10:51 AM, David Abrahams <dave@boostpro.com> wrote:
With apologies for the sales message: my company's Enterprise Support program offers the closest possible equivalent of point releases for Boost. We might be able to help you.
Thanks for the note, Dave. I'm afraid that I didn't make my point very clearly. I am not looking for support for boost, nor am I in particularly in favor of dot-releases, except when necessary. I'm concerned about the boost "brand" and the perceived quality of the officially released versions. What gives me trouble is when I lobby for groups to upgrade to 1.35.0 and they pushback saying that no one should upgrade since there's a "serious runtime bug in windows threads" or "filesystem doesn't even compile". If such claims are accurate then I would have expect some action to be taken (beyond "wait for the next release", or "seek out the appropriate experimental hotfix"). One approach would be to produce a dot release. No doubt there are other approaches. Reliability, especially for mature core components, trumps new features when it comes to proliferating boost in our environment. My posts can be viewed as one data point that the perception of world-class reliability has weakened a bit in 1.35.0. I haven't worked with 1.36.0 long enough to know whether this was a one-time fluke. - Mat
on Sat Aug 30 2008, "Mat Marcus" <mat-lists-AT-emarcus.org> wrote:
On Sat, Aug 30, 2008 at 10:51 AM, David Abrahams <dave@boostpro.com> wrote:
With apologies for the sales message: my company's Enterprise Support program offers the closest possible equivalent of point releases for Boost. We might be able to help you.
Oops! I was pretty sure I didn't send that to the list, but I unfortunately left the list in the Cc: field. My apologies to all.
Thanks for the note, Dave. I'm afraid that I didn't make my point very clearly. I am not looking for support for boost, nor am I in particularly in favor of dot-releases, except when necessary. I'm concerned about the boost "brand" and the perceived quality of the officially released versions. What gives me trouble is when I lobby for groups to upgrade to 1.35.0 and they pushback saying that no one should upgrade since there's a "serious runtime bug in windows threads" or "filesystem doesn't even compile". If such claims are accurate then I would have expect some action to be taken (beyond "wait for the next release", or "seek out the appropriate experimental hotfix"). One approach would be to produce a dot release. No doubt there are other approaches.
I'd be interested to hear of them. Anyway, thanks for saying all that explicitly; that pretty much echoes my discomfort with our current direction.
Reliability, especially for mature core components, trumps new features when it comes to proliferating boost in our environment. My posts can be viewed as one data point that the perception of world-class reliability has weakened a bit in 1.35.0. I haven't worked with 1.36.0 long enough to know whether this was a one-time fluke.
I don't think it was a fluke, though I hope it will turn out to have been only one time. Among other things, we dramatically reduced the number of platforms for which a clean sheet of tests was a release requirement. I have been working on getting an Suse Linux x86_64 bundle ready for an enterprise customer and there are basic issues on x86_64 Linux that AFAICT would have been addressed had we been testing there as a release requirement. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (5)
-
Darryl Green -
David Abrahams -
Eric Niebler -
Mat Marcus -
Vladimir Prus