Hi, 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 screws harder.
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.
Yes.
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 prerequisite AFAICS.
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 -- Thomas Witt witt@acm.org