From: Thomas Witt (witt_at_[hidden])
Date: 2006-05-15 20:26:43
I am just replying to Jeff for convenience as he brings up a few points
I like to addressed.
Jeff Garland wrote:
> On Sat, 13 May 2006 12:34:41 +0400, Vladimir Prus wrote
>> Jeff Garland wrote:
>> Huh? Sorry, this is FUD. Though V2 initially caused quite a number
>> of issues on it's own, they were fixed pretty quickly, and the
>> remaining issues can be knocked down quickly too.
> Hi Vladimir -
> Please, don't get upset -- I'm not trying to single you out -- there's plenty
> of good reasons for the release delay I'm sure. And I'm sorry, you're right I
> shouldn't have used an example I don't really have first hand knowledge of --
> I haven't paid attention enough to know if V2 is really stalling the current
> release. Only Thomas can say.
Boost.Build is not the only issue that is causing a stall. Though it
being basic infrastructure it's part of some chicken and egg issues.
I.e. I can't fix unless testing works finding build issues is hindered
by other outstanding issues. AFAICS this makes for slow progress. If
anybody here is worth to single out it's me for not putting on the
> Nothing at all. I've been a bit busy so I haven't looked lately and Doug's
> failure nag seems to have gone away. Of course with no changes in date-time
> for a month and barely any since the last release it's probably a problem
> elsewhere, but who knows. I'll try to look today.
The regression results are readily available. Even without the nag I
think it's reasonable to assume for developers to check them. I am not
pointing that out as an accusation but to show that we all work under
certain time constraints and that they seem to make impossible what
otherwise might be reasonably expected.
The reason for the nag to be still inactive is that I was not convinced
that not a significant part of the nagging is about testing/build
issues, I need to review this decision given the current situation. I
did not want people to ignore it for a low signal to noise ratio.
> Of course even if all the
> regressions were fixed today, someone would realize we need to run the license
> checker and that would spiral us into another week of fixing, etc, etc.
> Sure it would. It would change the process in a way that would stop the
> endless delays and waiting for everything to be fixed. Since the process
> would be much faster there could be more releases and the fact that date_time
> or anything else was reverted wouldn't be such a big deal. Again, I'm not
> suggesting this policy for the current release (frankly it's too late), just
> pointing out an alternative to the current process that I believe would make
> the process shorter.
I've been giving this some thought and frankly I am not so optimistic.
The whole idea of stability is based on reverting to a known stable
state. I think this idea is flawed in that we are operating in an ever
changing environment. If you looked at the regression table few entries
are of the what used to work is now broken variety. Compiler and OS
changes are issues that can't be dealt with by reverting. Library
interdependencies are another issue. Let's say lib A uses some
undocumented feature/corner-case of lib B what happens if B is upgraded
and breaks A? Who is at fault who is responsible, who finds out?
I think the biggest potential in improving things is to better handle
change. The biggest issue here is infrastructure to me. Somebody already
mentioned testing resources turnaround times and compiler availability.
As I've learned the hard way the supporting infrastructure for boost is
huge and there are not always clear responsibilities. Given this the
reliability is just insufficient. Most people here are part time
boosters they just don't have the time to learn all the intricate
details of the system, so every failure is a stumbling block. AFAICS the
problem starts at the sf level. We have seen way to many
outages/breaking changes recently. As an example regression testing
looks broken due to their server renaming. In my opinion being able to
run the nagging script continuously would go a long way and this goal
does not even interfere with the "stable branch" idea but is a
> That sounds vaguely like what I was proposing ;-) As I tried to say, I'm
> generally a supporter of Beman's proposal because it basically enforces what
> I'm talking about -- fix it or it's reverted. Until we get serious about
> enforcing that no one will pay attention.
In general I agree, I just don't think it (alone) fixes the problem.
-- Thomas Witt witt_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk