Is it time for another bug sprint? (Post 1.45 release, I mean)
----- Original Message ----- From: "Marshall Clow" <mclow.lists@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, October 26, 2010 6:23 PM Subject: [boost] Is it time for another bug sprint? (Post 1.45 release,I mean)
What do people think?
+1. But I will be busy until end of Boost.Chrono review. So 15th November could be a good date. Vicente
On Oct 26, 2010, at 11:00 AM, vicente.botet wrote:
----- Original Message ----- From: "Marshall Clow" <mclow.lists@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, October 26, 2010 6:23 PM Subject: [boost] Is it time for another bug sprint? (Post 1.45 release,I mean)
What do people think?
+1. But I will be busy until end of Boost.Chrono review. So 15th November could be a good date.
What do other people think about 15-November? That's a Monday - and for us USA people Thanksgiving is the 25th. Another option - we could start on Saturday the 13th, and run through Sunday the 21st. Ways that people can contribute: * Characterizing/investigating/replicating bugs. * Proposing patches. * Fixing bugs. * Writing docs (there are a bunch of bugs that are of the form "XXX needs to be documented") What else? -- Marshall There are only two hard problems in computer science: naming things, cache invalidation, and off-by-one errors.
On Oct 26, 2010, at 7:24 PM, Jim Bell wrote:
On 1:59 PM, Marshall Clow wrote:
What do people think?
What's the benefit of releasing 1.45 before a bug sprint?
The point of the bug sprint is to get the number of issues that have piled up (in the Trac) down to a more manageable level. Some of these are bugs, others are feature requests, documentation updates/requests, and just misunderstandings. Right before a release is not (IMHO) a time to be making many changes to the code base. It's a time for care, and limiting change (and risk). Doing bug sprints (I was going to abbreviate that but I decided that BS was not the best acronym) right after a release gives the fixes were made in the sprint "time to bake" - to make sure that they fix the reported problems (and not introduced more).
Particularly with the regression test matrix having as much yellow as it does?
The large abounds of yellow in the regression matrix is a different matter - and I suspect that the release managers are worrying about that. -- Marshall
Marshall Clow wrote:
On Oct 26, 2010, at 7:24 PM, Jim Bell wrote:
On 1:59 PM, Marshall Clow wrote:
What do people think?
What's the benefit of releasing 1.45 before a bug sprint?
The point of the bug sprint is to get the number of issues that have piled up (in the Trac) down to a more manageable level. Some of these are bugs, others are feature requests, documentation updates/requests, and just misunderstandings.
Right before a release is not (IMHO) a time to be making many changes to the code base. It's a time for care, and limiting change (and risk).
Doing bug sprints (I was going to abbreviate that but I decided that BS was not the best acronym) right after a release gives the fixes were made in the sprint "time to bake" - to make sure that they fix the reported problems (and not introduced more).
Particularly with the regression test matrix having as much yellow as it does?
The large abounds of yellow in the regression matrix is a different matter - and I suspect that the release managers are worrying about that.
I've always held the view that each release should be strictly better then the previous one. I interpret that to mean a) In current code - less bugs than the previous version b) 0 or more new features c) no more yellow columns than the previous version. Only under these circumstances should code be moved to the release branch from the trunk. So the a), b) and c) above should be true for every release regardless of when it's scheduled. As far as the serialization library is concerned right now. There are changes in the trunk that can/should be moved to the release branch and this will be consistent with a, b, and c above. There is one change which has caused regressions in the trunk and this should not be merged into the release branch. We should be focusing on release branch testing now. The mechanics of moving all the changes but one is somewhat tedious. We'll have to decide very soon how to do this. I made the mistake of not merging in the changes into the release branch before a higher risk change was made in the trunk. We'll decide how to address this soon. Robert Ramey
Robert Ramey wrote:
Marshall Clow wrote:
On Oct 26, 2010, at 7:24 PM, Jim Bell wrote:
On 1:59 PM, Marshall Clow wrote:
What do people think?
What's the benefit of releasing 1.45 before a bug sprint?
The point of the bug sprint is to get the number of issues that have piled up (in the Trac) down to a more manageable level. Some of these are bugs, others are feature requests, documentation updates/requests, and just misunderstandings.
Right before a release is not (IMHO) a time to be making many changes to the code base. It's a time for care, and limiting change (and risk).
Doing bug sprints (I was going to abbreviate that but I decided that BS was not the best acronym) right after a release gives the fixes were made in the sprint "time to bake" - to make sure that they fix the reported problems (and not introduced more).
Particularly with the regression test matrix having as much yellow as it does?
The large abounds of yellow in the regression matrix is a different matter - and I suspect that the release managers are worrying about that.
I've always held the view that each release should be strictly better then the previous one. I interpret that to mean
a) In current code - less bugs than the previous version b) 0 or more new features c) no more yellow columns than the previous version.
Only under these circumstances should code be moved to the release branch from the trunk. So the a), b) and c) above should be true for every release regardless of when it's scheduled.
As far as the serialization library is concerned right now. There are changes in the trunk that can/should be moved to the release branch and this will be consistent with a, b, and c above. There is one change which has caused regressions in the trunk and this should not be merged into the release branch. We should be focusing on release branch testing now. The mechanics of moving all the changes but one is somewhat tedious. We'll have to decide very soon how to do this. I made the mistake of not merging in the changes into the release branch before a higher risk change was made in the trunk. We'll decide how to address this soon.
I don't think there's much to decide. "svn merge --help" tells you all you need to know. - Volodya
Vladimir Prus wrote:
I don't think there's much to decide. "svn merge --help" tells you all you need to know.
That's not it. The problem is that if this has to happen, it would be on only a subset of the files on the trunk. But if one does this, then what one is merging in is not what one is testing on the trunk. So then the release branch effectively has an untested set of files. It's not that this is not addressable. It's just that it's not just a question of merging over all the files in the trunk as it usualy is. Robert Ramey
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
----- Original Message ----- From: "Robert Ramey" <ramey@rrsd.com> To: <boost@lists.boost.org> Sent: Wednesday, October 27, 2010 7:23 AM Subject: Re: [boost] Is it time for another bug sprint? (Post 1.45 release,I mean)
Marshall Clow wrote:
On Oct 26, 2010, at 7:24 PM, Jim Bell wrote:
On 1:59 PM, Marshall Clow wrote:
What do people think?
What's the benefit of releasing 1.45 before a bug sprint?
The point of the bug sprint is to get the number of issues that have piled up (in the Trac) down to a more manageable level. Some of these are bugs, others are feature requests, documentation updates/requests, and just misunderstandings.
Right before a release is not (IMHO) a time to be making many changes to the code base. It's a time for care, and limiting change (and risk).
Doing bug sprints (I was going to abbreviate that but I decided that BS was not the best acronym) right after a release gives the fixes were made in the sprint "time to bake" - to make sure that they fix the reported problems (and not introduced more).
Particularly with the regression test matrix having as much yellow as it does?
The large abounds of yellow in the regression matrix is a different matter - and I suspect that the release managers are worrying about that.
I've always held the view that each release should be strictly better then the previous one. I interpret that to mean
a) In current code - less bugs than the previous version b) 0 or more new features c) no more yellow columns than the previous version.
Only under these circumstances should code be moved to the release branch from the trunk. So the a), b) and c) above should be true for every release regardless of when it's scheduled.
As far as the serialization library is concerned right now. There are changes in the trunk that can/should be moved to the release branch and this will be consistent with a, b, and c above. There is one change which has caused regressions in the trunk and this should not be merged into the release branch. We should be focusing on release branch testing now. The mechanics of moving all the changes but one is somewhat tedious. We'll have to decide very soon how to do this. I made the mistake of not merging in the changes into the release branch before a higher risk change was made in the trunk. We'll decide how to address this soon.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 1:59 PM, Robert Ramey wrote:
Marshall Clow wrote:
On 1:59 PM, Marshall Clow wrote:
What do people think? What's the benefit of releasing 1.45 before a bug sprint? The point of the bug sprint is to get the number of issues that have
On Oct 26, 2010, at 7:24 PM, Jim Bell wrote: piled up (in the Trac) down to a more manageable level. Some of these are bugs, others are feature requests, documentation updates/requests, and just misunderstandings.
Right before a release is not (IMHO) a time to be making many changes to the code base. It's a time for care, and limiting change (and risk).
Doing bug sprints (I was going to abbreviate that but I decided that BS was not the best acronym) right after a release gives the fixes were made in the sprint "time to bake" - to make sure that they fix the reported problems (and not introduced more).
I'm with you on letting changes "bake." But aren't you suggesting that all those bugs demanding the sprint should go out in the next release?
Particularly with the regression test matrix having as much yellow as it does? The large abounds of yellow in the regression matrix is a different matter - and I suspect that the release managers are worrying about that.
Who are the release managers, and are they worrying about it? I'd love to hear what they're thinking. And I hope they're NOT thinking, "well, the calendar says 'release' so here we go..." Do they publish their thinking along the way?
I've always held the view that each release should be strictly better then the previous one. I interpret that to mean
a) In current code - less bugs than the previous version b) 0 or more new features c) no more yellow columns than the previous version.
Agreed.
On 10/27/2010 04:56 AM, Jim Bell wrote:
Who are the release managers, and are they worrying about it? I'd love to hear what they're thinking.
And I hope they're NOT thinking, "well, the calendar says 'release' so here we go..."
Do they publish their thinking along the way?
Jim - Eric Niebler who has been kindly engaging you is one of the release managers. It seems that he has patiently provided his point-of-view. The release process has been greatly improved over the past year thanks to the hard work and dedication of the current managers. Is there room for improvement? Certainly, but let me suggest that you also familiarize yourself with how the process works and observe a release cycle. It will only be 3-month before the craziness starts again. You can find answers to some of your questions here: <https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList> Looking at the dev mail list history will also give you a good idea of what occurs during a release and the efforts by the release team. michael
On 10/27/2010 8:28 AM, Michael Caisse wrote:
On 10/27/2010 04:56 AM, Jim Bell wrote:
Who are the release managers, and are they worrying about it? I'd love to hear what they're thinking.
And I hope they're NOT thinking, "well, the calendar says 'release' so here we go..."
Do they publish their thinking along the way?
You've heard my thoughts, so yes. :-)
Eric Niebler who has been kindly engaging you is one of the release managers. It seems that he has patiently provided his point-of-view.
I am helped by Beman Dawes, who is the chief cat-herder, and Vladimir Prus. There's one more release manager---Jeff Garland or Rene Rivera, I forget which---who has been largely inactive as release manager.
The release process has been greatly improved over the past year thanks to the hard work and dedication of the current managers. Is there room for improvement? Certainly, but let me suggest that you also familiarize yourself with how the process works and observe a release cycle. It will only be 3-month before the craziness starts again.
You can find answers to some of your questions here: <https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList>
Looking at the dev mail list history will also give you a good idea of what occurs during a release and the efforts by the release team.
Thanks, Michael. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 10/27/2010 1:01 PM, Eric Niebler wrote:
On 10/27/2010 8:28 AM, Michael Caisse wrote:
Eric Niebler who has been kindly engaging you is one of the release managers. It seems that he has patiently provided his point-of-view.
I am helped by Beman Dawes, who is the chief cat-herder, and Vladimir Prus. There's one more release manager---Jeff Garland or Rene Rivera, I forget which---who has been largely inactive as release manager.
Depending on the season.. I might be largely inactive as release manager. But Jeff has definitely been more inactive than myself. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 27 October 2010 03:24, Jim Bell <Jim@jc-bell.com> wrote:
On 1:59 PM, Marshall Clow wrote:
What do people think?
What's the benefit of releasing 1.45 before a bug sprint?
http://beta.boost.org/users/news/version_1_45_0 That's a lot of fixes. What's the benefit of not releasing them? Daniel
On 1:59 PM, Daniel James wrote:
On 27 October 2010 03:24, Jim Bell <Jim@jc-bell.com> wrote:
On 1:59 PM, Marshall Clow wrote:
What do people think? What's the benefit of releasing 1.45 before a bug sprint?
http://beta.boost.org/users/news/version_1_45_0
That's a lot of fixes. What's the benefit of not releasing them?
Thanks for the link. That's the view I was looking for! I see thirteen libraries on the list. Are these entries submitted by their authors? I don't want to rehash the AWOL-Authors discussion, and I realize this is a work in progress, but only 13 libraries are represented. I presume serialization and thread will be added, but that still seems like only a fraction of the libraries showing yellow on the regression matrix. Do the release managers take on library work? Do they assess the regression matrix? By the way, I appreciate all the work that everyone puts into boost, and hope all my comments are taken in the good sportsmanship they're intended.
On 27 October 2010 15:44, Jim Bell <Jim@jc-bell.com> wrote:
Thanks for the link. That's the view I was looking for!
I see thirteen libraries on the list. Are these entries submitted by their authors?
Yes. It'd take too long to go through every library's changes. It might be possible to do something automatic with Trac, but people don't tend to mark the milestones correctly. It might be possible to take a list of the open bugs at each release, and then diff them. I don't know how well Trac supports that kind of thing.
I don't want to rehash the AWOL-Authors discussion, and I realize this is a work in progress, but only 13 libraries are represented. I presume serialization and thread will be added, but that still seems like only a fraction of the libraries showing yellow on the regression matrix.
I include what I'm sent (or is added by someone else). Antony Williams usually adds the thread notes himself. I don't think Serialization has ever been included, but it has its own release notes, I might start linking to that, but it doesn't seem to have any changes for this release at the moment. Daniel
Marshall Clow wrote:
What do people think?
Count me in! Additionally i would like to bring up the idea of "Bug-Fix only release" No new features, just the old ones fixed. Every other release would be great for that. (I do realize that this was discussed once, I hope the mindset has changed since then)
participants (11)
-
Daniel James -
Eric Niebler -
Jim Bell -
joel falcou -
Marshall Clow -
Michael Caisse -
Rene Rivera -
Robert Ramey -
Thomas Heller -
vicente.botet -
Vladimir Prus