[feature freeze] range issue
Thomas, Do you have anything to add to the discussion on committing the new version of boost.range? -Thorsten
Thorsten Ottosen wrote:
Thomas,
Do you have anything to add to the discussion on committing the new version of boost.range?
Sorry for the late reply my internet connectivity over the last few days was worse than expected. Given the fact that we don't want destabilizing changes in feature freeze I would really like to move this to 1.35. Thomas -- Thomas Witt witt@acm.org
Thomas Witt wrote:
Thorsten Ottosen wrote:
Thomas,
Do you have anything to add to the discussion on committing the new version of boost.range?
Sorry for the late reply my internet connectivity over the last few days was worse than expected.
Given the fact that we don't want destabilizing changes in feature freeze I would really like to move this to 1.35.
I dno't like it. For one, bug-fixes must be applied again in a freah-check out. Secondly, people will keep on using the wrong protocol for range conformance. Can't we just roll-back to the current cvs if we cannot stabalize it within, say, a week? -Thorsten
Thorsten Ottosen wrote:
Thomas Witt wrote:
Thorsten Ottosen wrote:
Thomas,
Do you have anything to add to the discussion on committing the new version of boost.range?
Sorry for the late reply my internet connectivity over the last few days was worse than expected.
Given the fact that we don't want destabilizing changes in feature freeze I would really like to move this to 1.35.
I dno't like it. For one, bug-fixes must be applied again in a freah-check out. Secondly, people will keep on using the wrong protocol for range conformance.
I've been following discussions on Range issues and the issues Thorsten was solving looked pretty serious. Boost.Range offers an important set of Concepts that users are encouraged to implement and extend. IIUC, there were issues in the customization interface and both issues and fixes were discussed at length on the mailing lists. It seems very bad to have them wrong for another Boost release. Anyway, Thorsten is better positioned than I am to elaborate on the specific issues and fixes he wishes to commit. Perhaps looking at the issues involved would help in the decision. FWIW, I vote to give this a shot. Regards, João
João Abecasis <jpabecasis@gmail.com> writes:
Thorsten Ottosen wrote:
Thomas Witt wrote:
Thorsten Ottosen wrote:
Thomas,
Do you have anything to add to the discussion on committing the new version of boost.range?
Sorry for the late reply my internet connectivity over the last few days was worse than expected.
Given the fact that we don't want destabilizing changes in feature freeze I would really like to move this to 1.35.
I dno't like it. For one, bug-fixes must be applied again in a freah-check out. Secondly, people will keep on using the wrong protocol for range conformance.
I've been following discussions on Range issues and the issues Thorsten was solving looked pretty serious. Boost.Range offers an important set of Concepts that users are encouraged to implement and extend.
IIUC, there were issues in the customization interface and both issues and fixes were discussed at length on the mailing lists. It seems very bad to have them wrong for another Boost release.
If it's just about naming in the customization interface, I don't think that's serious enough to hold up a release. If it's something deeper, then somebody had better explain it to us. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Fri, Feb 17, 2006 at 11:30:06AM -0500, David Abrahams wrote:
Jo?o Abecasis <jpabecasis@gmail.com> writes:
Thorsten Ottosen wrote:
Thomas Witt wrote:
Thorsten Ottosen wrote:
Thomas,
Do you have anything to add to the discussion on committing the new version of boost.range?
Sorry for the late reply my internet connectivity over the last few days was worse than expected.
Given the fact that we don't want destabilizing changes in feature freeze I would really like to move this to 1.35.
I dno't like it. For one, bug-fixes must be applied again in a freah-check out. Secondly, people will keep on using the wrong protocol for range conformance.
I've been following discussions on Range issues and the issues Thorsten was solving looked pretty serious. Boost.Range offers an important set of Concepts that users are encouraged to implement and extend.
IIUC, there were issues in the customization interface and both issues and fixes were discussed at length on the mailing lists. It seems very bad to have them wrong for another Boost release.
If it's just about naming in the customization interface, I don't think that's serious enough to hold up a release. If it's something deeper, then somebody had better explain it to us.
As far as I know, the most important/problematic change deals with character arrays. This change is important, but it will have quite a large impact on the string algorithm library. Regards, Pavol
Pavol Droba wrote:
On Fri, Feb 17, 2006 at 11:30:06AM -0500, David Abrahams wrote:
IIUC, there were issues in the customization interface and both issues and fixes were discussed at length on the mailing lists. It seems very bad to have them wrong for another Boost release.
If it's just about naming in the customization interface, I don't think that's serious enough to hold up a release. If it's something deeper, then somebody had better explain it to us.
As far as I know, the most important/problematic change deals with character arrays. This change is important, but it will have quite a large impact on the string algorithm library.
Right. All we have now is a deprecation warning in the docs. Even though most code is simply a refactoring of old code, I do suspect that any commit will require help from people with challenged compilers. -Thorsten
Pavol Droba <droba@topmail.sk> writes:
As far as I know, the most important/problematic change deals with character arrays. This change is important, but it will have quite a large impact on the string algorithm library.
Yep, that's an important one. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Thorsten Ottosen <tottosen@dezide.com> writes:
Thomas Witt wrote:
Thorsten Ottosen wrote:
Thomas,
Do you have anything to add to the discussion on committing the new version of boost.range?
Sorry for the late reply my internet connectivity over the last few days was worse than expected.
Given the fact that we don't want destabilizing changes in feature freeze I would really like to move this to 1.35.
I dno't like it. For one, bug-fixes must be applied again in a freah-check out.
You're allowed to apply bugfixes now, just not check in new features. Am I misunderstanding what you mean?
Secondly, people will keep on using the wrong protocol for range conformance.
Yep, the existing protocol will become more entrenched.
Can't we just roll-back to the current cvs if we cannot stabalize it within, say, a week?
Thorsten, it's now a week past the freeze date, which was announced long ago. Yeah, none of us are perfect -- I begged for an extension, but I had a checkin ready to go the moment that I noticed the freeze announcement had gone out, and it was done and the code stabilized the instant Thomas approved it. I want the new Range features, too, but it seems to me that unless you can come up with some really convincing argument why this particular library warrants making a special exception to the rules -- and I'm still open to hearing one -- we have to respect Thomas' decision as release manager. That said, I think we should add the posting of a series of pre-freeze reminders to the release process, so those who lose track of the original announcement will be more likely to tie up their loose ends in time. This procedure will ultimately save lots of work for release managers as well (fewer extension requests). -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Thorsten, it's now a week past the freeze date, which was announced long ago.
Just to be fair this is to a large part not Thorsten's fault. That being said my decision would have been the same a week ago.
I want the new Range features, too, but it seems to me that unless you can come up with some really convincing argument why this particular library warrants making a special exception to the rules -- and I'm still open to hearing one -- we have to respect Thomas' decision as release manager.
I agree with Dave (on the really-convincing-reason part as well as the I-am-open part). The real issue is does it justify holding up everybody else.
That said, I think we should add the posting of a series of pre-freeze reminders to the release process, so those who lose track of the original announcement will be more likely to tie up their loose ends in time.
I agree that reminders as a courtesy are a good idea and I will try to do better in the future. I am unwilling to see their absence as an excuse.
This procedure will ultimately save lots of work for release managers as well (fewer extension requests).
I wasn't aware you're such an optimistic person ;-) Thomas -- Thomas Witt witt@acm.org
David Abrahams wrote:
Thorsten Ottosen <tottosen@dezide.com> writes:
Thomas Witt wrote:
Thorsten Ottosen wrote:
I dno't like it. For one, bug-fixes must be applied again in a freah-check out.
You're allowed to apply bugfixes now, just not check in new features. Am I misunderstanding what you mean?
Well, my files are a mix of fixes and refactorings. I need to apply fixes to a newly checked out copy. But I can manage that. -Thorsten
Thorsten, Thorsten Ottosen wrote:
I dno't like it.
Seriously, I don't like it either. I'd much rather have an updated range lib in 1.34 but time just ran out. Let me add some rationale. The reason the reason the range update will be postponed and some other last minute things weren't is the fact that a fair amount of stuff depends on range and at least one library author has raised concerns. So it's not simply an issue of try and revert if ti fails. Other libraries potentially loose stabilization time and might have to revert changes they made in case the range update is pulled. So there is a huge potential for delaying the whole process. So the trade-off is either delaying the range update or delaying future boost releases and thereby delaying updates to all other boost libs. In this case I don't think the issues in boost.range are serious enough to justify holding up everything else.
For one, bug-fixes must be applied again in a freah-check out. Secondly, people will keep on using the wrong protocol for range conformance.
Can't we just roll-back to the current cvs if we cannot stabalize it within, say, a week?
This is possible taking a week or more out of a planned 4 week freeze period where things need to stabilize. We just don't have that time if we want more frequent releases. Thomas -- Thomas Witt witt@acm.org
Thorsten Ottosen wrote:
Thomas Witt wrote:
Thorsten,
This is possible taking a week or more out of a planned 4 week freeze period where things need to stabilize. We just don't have that time if we want more frequent releases.
Ok, I'll respect your decision.
Thanks! Thomas -- Thomas Witt witt@acm.org
participants (6)
-
David Abrahams -
João Abecasis -
Neal Becker -
Pavol Droba -
Thomas Witt -
Thorsten Ottosen