Re: [boost] Proposal for radically altered approach to releases

From: Thomas Witt (witt_at_[hidden])
Date: 2006-05-15 20:26:43

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_at_[hidden]