[1.34.0] Beta Showstoppers
Hi, The 1.34.0 branch creation was a long while ago and as has been remarked earlier progress on getting it release ready has been slow to non-existent depending on the particular point of view. This is not to say that there wasn't a significant amount of work done but if we ever want to release it we either have to scale back the requirements or try harder. The next step is putting out a beta. Here is what I think needs to be done before we can call it beta. - Fix regressions with respect to the prior release. The regression tests still show a fair amount of "broken" fields. - Update the "Getting Started" and build system documentation to reflect the change to build.v2. - Make v2 the default build system (is this already so?). - Fix *all* of the filename too long issues. - Fix as much of the inspection issues as possible. All in all the inspection report shows a frightening number of issues. What is our stance with respect to license/copyright missing? At this point I think it is unrealistic to set a date for the beta as far as I can see. I will set a date as soon as we made some significant progress. If I can somehow stick your name to the outstanding issues expect to be bugged from now on. I guess a volunteer for the documentation issues would be very much appreciated. If anyone feels like not being able to make progress due to some dependency please shoot me an email. Comments? Thomas Release Manager -- Thomas Witt witt@acm.org
Thomas Witt wrote:
At this point I think it is unrealistic to set a date for the beta as far as I can see. I will set a date as soon as we made some significant progress. If I can somehow stick your name to the outstanding issues expect to be bugged from now on. I guess a volunteer for the documentation issues would be very much appreciated.
Comments?
I feel a target date would be helpful, as when I'm juggling commitments I'll ultimately order by delivery date. At the moment, there are no target dates or milestones for 1.34, so it just keeps slipping away. On my 'to do' list is invistigating and either fixing or marking-up the failures for the Borland compilers. I also have a couple more test cases to add to the array library, and a workaround to add for MSVC (which will not be apparent without the new test cases!) -- AlisdairM
AlisdairM wrote:
I feel a target date would be helpful, as when I'm juggling commitments I'll ultimately order by delivery date. At the moment, there are no target dates or milestones for 1.34, so it just keeps slipping away.
Not that I can offer any direct help on fixing the issues (at least not for a month or two), but why not try target somethign like 10% of the simple issues per day or something similar? Obviously some of the failures are beyond the ability to give a firm time to fix, but it looks like some of the failures are simple enough this might be possible. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |
On Tue, 15 Aug 2006 21:53:41 -0700, Thomas Witt <witt@acm.org> wrote:
Hi,
Hi, those who don't die come back.
[...]
The next step is putting out a beta. Here is what I think needs to be done before we can call it beta.
- Fix regressions with respect to the prior release.
Ingenious! -- [ Gennaro Prota, C++ developer. Library designer. ] [ For Hire http://gennaro-prota.50webs.com/ ]
Thomas Witt <witt@acm.org> writes:
The next step is putting out a beta. Here is what I think needs to be done before we can call it beta.
- Fix regressions with respect to the prior release. The regression tests still show a fair amount of "broken" fields.
Trying. I am experiencing latency problems with our distributed structure. I think we need to somehow find/designate times when those people working on the release are all going to try to be online (and available via IM or skype or something). At least, that would make a huge difference in _my_ ability to make progress. I'd like to propose a "Boost bug day," probably on a weekend. I know this might make unreasonable demands on people in certain hemispheres who would rather be sleeping when the rest of us are working, but I don't know how else to handle this.
- Update the "Getting Started" and build system documentation to reflect the change to build.v2.
I planned to do that long ago, but I feel as though fixing regressions is a prerequisite. Also, many of the same communication latency issues will apply here.
- Make v2 the default build system (is this already so?).
That's very simple to do.
- Fix *all* of the filename too long issues.
Yep.
- Fix as much of the inspection issues as possible.
Yep. I'm having trouble knowing what to do with the pairs of inspection reports that are getting sent out. How are they intended to be read? Would it be possible to prefix each one with a short description of how to use it?
All in all the inspection report shows a frightening number of issues. What is our stance with respect to license/copyright missing?
It has to be fixed.
At this point I think it is unrealistic to set a date for the beta as far as I can see. I will set a date as soon as we made some significant progress. If I can somehow stick your name to the outstanding issues expect to be bugged from now on. I guess a volunteer for the documentation issues would be very much appreciated.
What do you mean by "the documentation issues," specifically?
If anyone feels like not being able to make progress due to some dependency please shoot me an email.
Noted above. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Thomas Witt <witt@acm.org> writes:
The next step is putting out a beta. Here is what I think needs to be done before we can call it beta.
- Fix regressions with respect to the prior release. The regression tests still show a fair amount of "broken" fields.
Trying. I am experiencing latency problems with our distributed structure. I think we need to somehow find/designate times when those people working on the release are all going to try to be online (and available via IM or skype or something).
Ad hoc live collaboration? Seems like an IRC channel might be a better solution.
- Fix as much of the inspection issues as possible.
Yep. I'm having trouble knowing what to do with the pairs of inspection reports that are getting sent out. How are they intended to be read? Would it be possible to prefix each one with a short description of how to use it?
What would the description say, other than "please look at the issues with your library"? NOTE: Anything that increases the length of the emails is problematic as they might start needing to be moderated again. So perhaps a separate doc page we can point to is best. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera <grafikrobot@gmail.com> writes:
David Abrahams wrote:
Thomas Witt <witt@acm.org> writes:
The next step is putting out a beta. Here is what I think needs to be done before we can call it beta.
- Fix regressions with respect to the prior release. The regression tests still show a fair amount of "broken" fields.
Trying. I am experiencing latency problems with our distributed structure. I think we need to somehow find/designate times when those people working on the release are all going to try to be online (and available via IM or skype or something).
Ad hoc live collaboration? Seems like an IRC channel might be a better solution.
Yep, might be.
- Fix as much of the inspection issues as possible.
Yep. I'm having trouble knowing what to do with the pairs of inspection reports that are getting sent out. How are they intended to be read? Would it be possible to prefix each one with a short description of how to use it?
What would the description say, other than "please look at the issues with your library"?
"Here's why you'd look at this report instead of the other one..." and *both* reports would include a complete key to the symbols!
NOTE: Anything that increases the length of the emails is problematic as they might start needing to be moderated again. So perhaps a separate doc page we can point to is best.
Fine by me, as long as there's a link in the email. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (6)
-
AlisdairM -
David Abrahams -
Gennaro Prota -
Kevin Wheatley -
Rene Rivera -
Thomas Witt