As a user I am concerned about the lack of a 1.35.1 release. We cannot use 1.35 because it contains a bug. When 1.36 is released it will fix this bug, but it will also inevitably introduce new bugs some of which may also be show-stoppers for us. Which means we have to wait for 1.37, and so on... We need to have bugfix releases for released version of boost that do not change anything that is not absolutely necessary to fix bugs. Without this we are going to have to manually patch bugs as fixes come out, which makes a mockery of the whole idea of having boost releases (and makes boost much less appealing as a library). Jim P Consider the environment. Please don't print this email. ________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________
James Talbut <James.Talbut <at> omg3d.com> writes: [...]
We need to have bugfix releases for released version of boost that do not change anything that is not absolutely necessary to fix bugs. Without this we are going to have to manually patch bugs as fixes come out, which makes a mockery of the whole idea of having boost releases (and makes boost much less appealing as a library).
How much is your company prepared to pay for this to happen, either by investing its employees' time or cash on a consultant to do it? And while we're at it, how much has your company invested in Boost library development since you started using the libraries? I don't mean to be provocatory, nor to pick on you or your company specifically; the same questions could be posed to every company that uses Boost. I'm convinced that Boost direly needs the continuous presence of someone who's paid to devote a good portion of her or his time to help with organization and infrastructure. Specifically I think it's unlikely that bug fix releases get issued regularly unless someone is paid to handle them. On a related note, I'd be curious to know how much of what's in Boost is the direct result of paid work. Is anybody out there paid specifically to manage their company's contribution to Boost? Cheers, Nicola Musatti
Nicola Musatti wrote:
James Talbut <James.Talbut <at> omg3d.com> writes: [...]
We need to have bugfix releases for released version of boost that do not change anything that is not absolutely necessary to fix bugs. Without this we are going to have to manually patch bugs as fixes come out, which makes a mockery of the whole idea of having boost releases (and makes boost much less appealing as a library).
How much is your company prepared to pay for this to happen, either by investing its employees' time or cash on a consultant to do it?
And while we're at it, how much has your company invested in Boost library development since you started using the libraries?
I don't mean to be provocatory, nor to pick on you or your company specifically; the same questions could be posed to every company that uses Boost.
I'm convinced that Boost direly needs the continuous presence of someone who's paid to devote a good portion of her or his time to help with organization and infrastructure. Specifically I think it's unlikely that bug fix releases get issued regularly unless someone is paid to handle them.
On a related note, I'd be curious to know how much of what's in Boost is the direct result of paid work. Is anybody out there paid specifically to manage their company's contribution to Boost?
Cheers, Nicola Musatti
In my opinion, if someone found a critical bug in boost and she knows how to fix it, in most cases, she will be glad to contribute the fix to the library. The question is how difficult to contribute a bug fix and make it OFFICIAL (not my local fixed copy) as a new bugfix release, for example 1.32.100?
Sergey Shandar <sergey <at> comrades.id.au> writes: [...]
In my opinion, if someone found a critical bug in boost and she knows how to fix it, in most cases, she will be glad to contribute the fix to the library. The question is how difficult to contribute a bug fix and make it OFFICIAL (not my local fixed copy) as a new bugfix release, for example 1.32.100?
There are two steps to this: one is to contribute the code, the other is to package the release. The first step is reasonably easy; you can post your patches to this list and wait for the library maintainer to take a look at it. Some times it may take a while and one or two additional posts, if the author is busy, but contributions are usually welcome. Once you gain one or two maintainers' trust you can apply for Subversion commit privileges. Afterwards you do the same, with the (explicit) provision that if your contributions aren't actively acknowledged or rejected in a few days time you proceed to commit them. On the other hand packaging a release involves a lot more effort, as can be evinced from the discussions in this newsgroup about issuing 1.35 . Cheers, Nicola Musatti
In my opinion, if someone found a critical bug in boost and she knows how to fix it, in most cases, she will be glad to contribute the fix to the library. The question is how difficult to contribute a bug fix and make it OFFICIAL (not my local fixed copy) as a new bugfix release, for example 1.32.100?
it is always a tradeoff between `code freeze' and `bug fixes' ... in the weeks before the 1.35 release, i posted some patches for gcc-4.3 compatibility, which were rejected since the code was already frozen ... imo, a boost 1.35.1 release, fixing bugs in 1.35.0 and with gcc-4.3 support is quite important ... if users are not able to use the latest release, but are forced to use a specific version, they need to maintain their own branch of boost ... best, tim -- tim@klingt.org http://tim.klingt.org Linux is like a wigwam: no windows, no gates, apache inside, stable.
on Tue May 27 2008, "James Talbut" <James.Talbut-AT-omg3d.com> wrote:
As a user I am concerned about the lack of a 1.35.1 release.
We cannot use 1.35 because it contains a bug. When 1.36 is released it will fix this bug, but it will also inevitably introduce new bugs some of which may also be show-stoppers for us. Which means we have to wait for 1.37, and so on...
We need to have bugfix releases for released version of boost that do not change anything that is not absolutely necessary to fix bugs. Without this we are going to have to manually patch bugs as fixes come out, which makes a mockery of the whole idea of having boost releases (and makes boost much less appealing as a library).
Hi James, That is one of the most important reasons we decided to offer http://www.boostpro.com/products/enterprise. Maybe we can help? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (5)
-
David Abrahams -
James Talbut -
Nicola Musatti -
Sergey Shandar -
Tim Blechmann