what happens between "fixed in development" and "available in release"?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

what happens between "fixed in development" and "available in release"?

Oswin Krause
Hi,

Question is in the subject. What has to happen after a fix of a bug in
development stage before it enters an official release?

Do not get me wrong, I like boost and all it does for the community and
all the effort people put into it. And i really would like to help to
speed up certain...processes, but for this i have to know what can block
this step?

Apparently a bug in serialisation - which totally breaks my software to
the point where it can not be compiled on several linux distributions
und MacOsX since release of boost 1.56 - is fixed in development even
prior to 1.57 and is still not available in 1.58. And what I hear from
several mails across the mailing list, this is not the only change that
got stuck. And somehow i have the feeling that the new boost release
cycle won't make the situation any better.

As I said, do not get me wrong, but this situation becomes unbearable as
these boost versions spread more and more through the ecosystem and
there is really nothing on my side I can do about it, except rolling my
own implementation and maintaining it, until this whole thing is faded
out of all major distributions(you might already get the feeling that I
am not really happy about doing that).

if there is something i can do to help, I will do it. But I now know
that "report bugs and investigate possible fixes and send patches" does
not necessarily lead to a fast fix and i am pretty frustrated by the
situation.

Best,
Oswin
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: what happens between "fixed in development" and "available in release"?

Edward Diener-3
On 3/18/2015 10:40 AM, oswin krause wrote:

> Hi,
>
> Question is in the subject. What has to happen after a fix of a bug in
> development stage before it enters an official release?
>
> Do not get me wrong, I like boost and all it does for the community and
> all the effort people put into it. And i really would like to help to
> speed up certain...processes, but for this i have to know what can block
> this step?
>
> Apparently a bug in serialisation - which totally breaks my software to
> the point where it can not be compiled on several linux distributions
> und MacOsX since release of boost 1.56 - is fixed in development even
> prior to 1.57 and is still not available in 1.58. And what I hear from
> several mails across the mailing list, this is not the only change that
> got stuck. And somehow i have the feeling that the new boost release
> cycle won't make the situation any better.
>
> As I said, do not get me wrong, but this situation becomes unbearable as
> these boost versions spread more and more through the ecosystem and
> there is really nothing on my side I can do about it, except rolling my
> own implementation and maintaining it, until this whole thing is faded
> out of all major distributions(you might already get the feeling that I
> am not really happy about doing that).
>
> if there is something i can do to help, I will do it. But I now know
> that "report bugs and investigate possible fixes and send patches" does
> not necessarily lead to a fast fix and i am pretty frustrated by the
> situation.

Putting '[serialization]' as the start of the subject to your message
has more chance of alerting the Boost developer of the serialization
library to your issue. Also citing the actual bug report that has been
fixed in serialization on the 'develop' branch would help to specify the
actual case of which you are concerned.

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: what happens between "fixed in development" and "available in release"?

Leon Mlakar-2
On 18.03.2015 22:31, Edward Diener wrote:

> On 3/18/2015 10:40 AM, oswin krause wrote:
>> Hi,
>>
>> Question is in the subject. What has to happen after a fix of a bug in
>> development stage before it enters an official release?
>>
>> Do not get me wrong, I like boost and all it does for the community and
>> all the effort people put into it. And i really would like to help to
>> speed up certain...processes, but for this i have to know what can block
>> this step?
>>
>> Apparently a bug in serialisation - which totally breaks my software to
>> the point where it can not be compiled on several linux distributions
>> und MacOsX since release of boost 1.56 - is fixed in development even
>> prior to 1.57 and is still not available in 1.58. And what I hear from
>> several mails across the mailing list, this is not the only change that
>> got stuck. And somehow i have the feeling that the new boost release
>> cycle won't make the situation any better.
>>
>> As I said, do not get me wrong, but this situation becomes unbearable as
>> these boost versions spread more and more through the ecosystem and
>> there is really nothing on my side I can do about it, except rolling my
>> own implementation and maintaining it, until this whole thing is faded
>> out of all major distributions(you might already get the feeling that I
>> am not really happy about doing that).
>>
>> if there is something i can do to help, I will do it. But I now know
>> that "report bugs and investigate possible fixes and send patches" does
>> not necessarily lead to a fast fix and i am pretty frustrated by the
>> situation.
>
> Putting '[serialization]' as the start of the subject to your message
> has more chance of alerting the Boost developer of the serialization
> library to your issue. Also citing the actual bug report that has been
> fixed in serialization on the 'develop' branch would help to specify
> the actual case of which you are concerned.
>
I believe the core question was how could he (the poster) contribute to
speed the things up. About the process, not so much about the particular
library or the particular bug. Something I was wondering about in the
past, too. Your reply emphasizing indicates that there probably isn't a
single "Boost-wide" process but that everything is in the hands of
library maintainers, and that it differs from library to library.

Cheers,

Leon
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: what happens between "fixed in development" and "available in release"?

Oswin Krause
Hi

>> Putting '[serialization]' as the start of the subject to your message
>> has more chance of alerting the Boost developer of the serialization
>> library to your issue. Also citing the actual bug report that has
>> been fixed in serialization on the 'develop' branch would help to
>> specify the actual case of which you are concerned.
>>
> I believe the core question was how could he (the poster) contribute
> to speed the things up. About the process, not so much about the
> particular library or the particular bug. Something I was wondering
> about in the past, too. Your reply emphasizing indicates that there
> probably isn't a single "Boost-wide" process but that everything is in
> the hands of library maintainers, and that it differs from library to
> library.
This is exactly my question. If it would be in the hands of the single
maintainers to push their changes to release, this would be kind of
unfortunate as this makes it hard to enforce any policy, e.g. "this type
of bug is serious and can not be delayed" or "every library needs a
'development' and a 'bug fix' branch and the latter is always merged
into release". I guess, right now, bug fixes can be delayed when there
are other changes in development that still needs testing.

Best,
Oswin
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: what happens between "fixed in development" and "available in release"?

Edward Diener-3
On 3/19/2015 12:46 AM, oswin krause wrote:

> Hi
>>> Putting '[serialization]' as the start of the subject to your message
>>> has more chance of alerting the Boost developer of the serialization
>>> library to your issue. Also citing the actual bug report that has
>>> been fixed in serialization on the 'develop' branch would help to
>>> specify the actual case of which you are concerned.
>>>
>> I believe the core question was how could he (the poster) contribute
>> to speed the things up. About the process, not so much about the
>> particular library or the particular bug. Something I was wondering
>> about in the past, too. Your reply emphasizing indicates that there
>> probably isn't a single "Boost-wide" process but that everything is in
>> the hands of library maintainers, and that it differs from library to
>> library.
> This is exactly my question. If it would be in the hands of the single
> maintainers to push their changes to release, this would be kind of
> unfortunate as this makes it hard to enforce any policy, e.g. "this type
> of bug is serious and can not be delayed" or "every library needs a
> 'development' and a 'bug fix' branch and the latter is always merged
> into release". I guess, right now, bug fixes can be delayed when there
> are other changes in development that still needs testing.

A number of libraries are in the hands of more than one maintainer.


_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: what happens between "fixed in development" and "available in release"?

Niall Douglas
In reply to this post by Oswin Krause
On 18 Mar 2015 at 15:40, oswin krause wrote:

> Question is in the subject. What has to happen after a fix of a bug in
> development stage before it enters an official release?
>
> Do not get me wrong, I like boost and all it does for the community and
> all the effort people put into it. And i really would like to help to
> speed up certain...processes, but for this i have to know what can block
> this step?
>
> Apparently a bug in serialisation - which totally breaks my software to
> the point where it can not be compiled on several linux distributions
> und MacOsX since release of boost 1.56 - is fixed in development even
> prior to 1.57 and is still not available in 1.58. And what I hear from
> several mails across the mailing list, this is not the only change that
> got stuck. And somehow i have the feeling that the new boost release
> cycle won't make the situation any better.
If Robert is holding back a fix to Seralisation, I would be sure he
has a very good reason to do so.

> As I said, do not get me wrong, but this situation becomes unbearable as
> these boost versions spread more and more through the ecosystem and
> there is really nothing on my side I can do about it, except rolling my
> own implementation and maintaining it, until this whole thing is faded
> out of all major distributions(you might already get the feeling that I
> am not really happy about doing that).
>
> if there is something i can do to help, I will do it. But I now know
> that "report bugs and investigate possible fixes and send patches" does
> not necessarily lead to a fast fix and i am pretty frustrated by the
> situation.
Most Boost libraries with active maintainers are pretty good about
merging develop to master regularly. Those libraries without active
maintainers I would personally avoid as you're always going to be
fighting to find someone willing to merge fixes.

A huge advantage of header only Boost libraries is you are free of
dependency on the system provided version. Although you shouldn't do
this, often you can get away with replacing a header only library
locally with the latest, yet still link to the shared library
dependencies of a much older Boost version. I should stress the "get
away with" part of that statement.

Niall
--
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/



_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users

SMime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: what happens between "fixed in development" and "available in release"?

Oswin Krause
Hi,
> If Robert is holding back a fix to Seralisation, I would be sure he
> has a very good reason to do so.
I trust him. However, in the ticket regarding the bug, he told me that
it is fixed in development and that I could check out the development
branch if I needed it very urgently. This was for me a "should be
available in the next release" which was enough for me to not poke any
further. But it is now 2 releases since then. If there were problems I
would have liked to hear about it as I would have been willing to test
and/or provide further patches.
> Most Boost libraries with active maintainers are pretty good about
> merging develop to master regularly. Those libraries without active
> maintainers I would personally avoid as you're always going to be
> fighting to find someone willing to merge fixes.
Is there a list of libraries searching a new active maintainer? It does
not really state in the official documentation which libraries to stay
away from and i am not remembering people asking for some bug-fix
maintainers. I would certainly willing to clean up the bug-tracker of
one of the libraries I use. On the other hand: i do not mind bugs in a
library I just mind bugs in a library that just pop up after an update.

> A huge advantage of header only Boost libraries is you are free of
> dependency on the system provided version. Although you shouldn't do
> this, often you can get away with replacing a header only library
> locally with the latest, yet still link to the shared library
> dependencies of a much older Boost version. I should stress the "get
> away with" part of that statement.
I do not really want to run into ODR violations(and serialization is not
header only). I was thinking about providing my own code for this file
and just include it first, trying to diagnose if the "official" version
was included first and bail out with an error if it was. But this is a)
super messy b) prone to ODR violations and c) i have to maintain the fix
for several years.

The cleanest solution for a regression like this would be if the fix
would be out and a patch would be available so that we can poke the
distro maintainers to include it into their libboost-1.56/7/8.
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: what happens between "fixed in development" and "available in release"?

Robert Ramey
In reply to this post by Oswin Krause
Oswin Krause wrote
Hi,

Question is in the subject. What has to happen after a fix of a bug in
development stage before it enters an official release?
What has to happen is that I have to merge the serialization develop branch to the master branch.  My procedure is:
a) switch my local copy of the serialization library to master branch.
b) merge in current develop branch
c) update my local modular boost tree - which is always kept on the master branch
d) (re)run all serialization library tests with clang and gcc compilers for DLL and static libraries and debug and release libraries.  These combinations come to about 2000 tests which are presented in a giant table which has to come out all "green"  This isn't really enough as it should include a couple of versions of VS but I don't have that around.

In this particular instance, I had trouble with step c).  This is not unusual as I have to confess the git submodule setup is pretty confusing and I don't do it all that frequently.  When I finally managed to get this done, I found that the code that I use to review the results (tools/regression) has been removed from the master branch.  Of course this was a surprise to me!  Apparently I'm the only one that uses this code (not a huge surprise, I'm not sure why though).  So now I have to remember how to get this thing built again and figure out where I'm going to keep it.

So all in all this ends up taking a lot more time than one would expect.

You might ask - why not just merge develop into master and watch the test results?  I would answer that I've learned the hard way that taking a "shortcut" can lead to repercussions which such up lots, lots more time.  Even investing the effort above, the bug that provokes this email still managed to creep in and was not detected by my tests.

Note that all the above doesn't actually include the time finding reported bugs.  These are pretty infrequent these days - but are often a major bitch to reproduce, find and fix. Often they are artifacts of standard library implementations which are very time consuming to track down.

I hope that answer's your question.

Robert Ramey
Reply | Threaded
Open this post in threaded view
|

Re: what happens between "fixed in development" and "available in release"?

Patrick J. LoPresti
In reply to this post by Niall Douglas
"Niall Douglas" <[hidden email]> writes:

> Those libraries without active maintainers I would personally avoid as
> you're always going to be fighting to find someone willing to merge
> fixes.

Sounds like sage advice. As a Boost user, how do I know which is which?

 - Pat
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: what happens between "fixed in development" and "available in release"?

Niall Douglas
In reply to this post by Robert Ramey
On 19 Mar 2015 at 8:41, Robert Ramey wrote:

> In this particular instance, I had trouble with step c).  This is not
> unusual as I have to confess the git submodule setup is pretty confusing and
> I don't do it all that frequently.  When I finally managed to get this done,
> I found that the code that I use to review the results (tools/regression)
> has been removed from the master branch.  Of course this was a surprise to
> me!  Apparently I'm the only one that uses this code (not a huge surprise,
> I'm not sure why though).  So now I have to remember how to get this thing
> built again and figure out where I'm going to keep it.
>
> So all in all this ends up taking a lot more time than one would expect.
I hear this. It cost me 200 hours to make a release of AFIO. That's
six weeks of working till 5am night after night after your day job,
with associated exhaustion, poor performance at work, and family
irritation with you. Once per year for me I think, no more.

> You might ask - why not just merge develop into master and watch the test
> results?  I would answer that I've learned the hard way that taking a
> "shortcut" can lead to repercussions which such up lots, lots more time.
> Even investing the effort above, the bug that provokes this email still
> managed to creep in and was not detected by my tests.

Personally speaking, I'd do that exact merge straight after a Boost
release. That gives you the time to find and fix any problems before
the next release. In other words, develop lags master by one major
Boost release.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/



_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users

SMime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: what happens between "fixed in development" and "available in release"?

Niall Douglas
In reply to this post by Patrick J. LoPresti
On 19 Mar 2015 at 8:58, Patrick J. LoPresti wrote:

> > Those libraries without active maintainers I would personally avoid as
> > you're always going to be fighting to find someone willing to merge
> > fixes.
>
> Sounds like sage advice. As a Boost user, how do I know which is which?

Check the release notes to see if the changelog hasn't mentioned the
maintainer in many years. Ditto for the commit log. Another good sign
is how old the oldest unfixed bugs on the issue tracker are. By those
measures, perhaps as many as 20% of Boost libraries are looking
unmaintained or poorly maintained. Symptom of maturity.

If a maintainer formally resigns or is known to be no longer
available, the CMT can take over the library. However, most orphaned
libraries right now are still technically maintained by their named
maintainer even if we haven't see the maintainer in many years. The
problem as always is finding new maintainer willing to sacrifice
themselves sufficiently to be a good library maintainer.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/



_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users

SMime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: what happens between "fixed in development" and "available in release"?

Robert Ramey
In reply to this post by Niall Douglas
Niall Douglas wrote
On 19 Mar 2015 at 8:41, Robert Ramey wrote:
Personally speaking, I'd do that exact merge straight after a Boost
release. That gives you the time to find and fix any problems before
the next release. In other words, develop lags master by one major
Boost release.
My practice is to

a) decide to address something - feature tweak like adding support for std smart pointers, fixing outstanding bugs or whatever.
b) fix them in develop.  This includes ancillary stuff like adjusting documentation
c) run my test scenario as described above
d) merge into master.

I do this independent of the release schedule and do it is "smallish" chunks.  This generally works pretty well and the serialization library on the master is of the state "no known fixable bugs".  It does suck a lot of CPU time but that's free for me now.  The problem comes when something "breaks".  I might forget how to do something, the build system might have evolved, etc.  Then I have to call some mental subroutine which takes a lot of time to get back on track.  The risk of this happening dissuades me from doing this procedure more often.   In this particular case, he release came up in the middle of my cycle.

Having said this, the situation is still much, much better than it use to be.

a) The git system is pretty friendly for making fixes on branches and merging them in.
b) the git submodule system works pretty well for us.  It permits me to leave all the rest of boost (that I depend upon but don't mess with) on the master branch while the stuff I'm working on is on develop.  A great way to keep other's experiments from sawing the chair out from under me.
c) C++ standard libraries and compilers are better saving time chasing stuff down there

On the other hand boost build is still too fragile - it seems every time I want run it I have to do another troll of how the exact command line to use, or whatever.  I found it easier to set up CMake for serialization and use that.  But then of course i risk being surprised when I want to run boost build tests to be sure I'm still in sync.

So much progress has been made.  Still more to go.

Robert Ramey
Reply | Threaded
Open this post in threaded view
|

Re: what happens between "fixed in development" and "available in release"?

Thomas M
On 19/03/2015 18:23, Robert Ramey wrote:

> Niall Douglas wrote
>> On 19 Mar 2015 at 8:41, Robert Ramey wrote:
>> Personally speaking, I'd do that exact merge straight after a Boost
>> release. That gives you the time to find and fix any problems before
>> the next release. In other words, develop lags master by one major
>> Boost release.
>
> My practice is to
>
> a) decide to address something - feature tweak like adding support for std
> smart pointers, fixing outstanding bugs or whatever.
> b) fix them in develop.  This includes ancillary stuff like adjusting
> documentation
> c) run my test scenario as described above
> d) merge into master.
>
> I do this independent of the release schedule and do it is "smallish"
> chunks.  This generally works pretty well and the serialization library on
> the master is of the state "no known fixable bugs".  It does suck a lot of
> CPU time but that's free for me now.  The problem comes when something
> "breaks".  I might forget how to do something, the build system might have
> evolved, etc.  Then I have to call some mental subroutine which takes a lot
> of time to get back on track.  The risk of this happening dissuades me from
> doing this procedure more often.   In this particular case, he release came
> up in the middle of my cycle.


I am just a boost user, not developer, and don't follow this list
closely. Here are my 2 cents, I hope they are not completely off:

What about making an upcoming release, e.g. 1.59, a "bug-fix" release
only with the goal that all (or almost all) open issues get merged to
master? No new features get added.
If a library is stable (i.e. no open issues) leave it as it is (freeze
it) and communicate that to other maintainers, so they can rely on a
given version. Same for boost build and other tools, provide reference
versions to rely on, no extensions. Give maintainers the time to get
their issues fixed, do thorough testing etc. - if it takes half a year
or longer, so it be, fine.

As user I too find it increasingly difficult to overview the status and
reliability of boost versions, and switching to a new release can make
matters worse (for me as user) then sticking to a "working" previous
release.
On the other hand I think that I can understand the tremendous amount of
effort and commitment required from library maintainers. And yes I know
that things can break so unexpectedly and distract for ages from main
aims (last time here: a VS extension installed broke the default
configurations set by boost build, and that did take us a lot of time).
So as user I feel the responsibility to not expect miracles or
unrealistic things from maintainers.

Note that my proposal aims at helping both users and maintainers: The
former to get a hopefully stable release, and the latter to give them
the time needed to make their developments and testing, without
everything else in boost changing all the time.

Thomas

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: what happens between "fixed in development" and "available in release"?

Niall Douglas
On 20 Mar 2015 at 8:43, Thomas wrote:

> > I do this independent of the release schedule and do it is "smallish"
> > chunks.  This generally works pretty well and the serialization library on
> > the master is of the state "no known fixable bugs".  It does suck a lot of
> > CPU time but that's free for me now.  The problem comes when something
> > "breaks".  I might forget how to do something, the build system might have
> > evolved, etc.  Then I have to call some mental subroutine which takes a lot
> > of time to get back on track.  The risk of this happening dissuades me from
> > doing this procedure more often.   In this particular case, he release came
> > up in the middle of my cycle.
>
> I am just a boost user, not developer, and don't follow this list
> closely. Here are my 2 cents, I hope they are not completely off:
By sheer good fortune myself and Robert are the leads of the two most
articulated schools of thought on the future of Boost. We disagree,
though less than in the past. I think C++ Now may see us move closer
again.

> What about making an upcoming release, e.g. 1.59, a "bug-fix" release
> only with the goal that all (or almost all) open issues get merged to
> master? No new features get added.
> If a library is stable (i.e. no open issues) leave it as it is (freeze
> it) and communicate that to other maintainers, so they can rely on a
> given version. Same for boost build and other tools, provide reference
> versions to rely on, no extensions. Give maintainers the time to get
> their issues fixed, do thorough testing etc. - if it takes half a year
> or longer, so it be, fine.
>
> As user I too find it increasingly difficult to overview the status and
> reliability of boost versions, and switching to a new release can make
> matters worse (for me as user) then sticking to a "working" previous
> release.
> On the other hand I think that I can understand the tremendous amount of
> effort and commitment required from library maintainers. And yes I know
> that things can break so unexpectedly and distract for ages from main
> aims (last time here: a VS extension installed broke the default
> configurations set by boost build, and that did take us a lot of time).
> So as user I feel the responsibility to not expect miracles or
> unrealistic things from maintainers.
>
> Note that my proposal aims at helping both users and maintainers: The
> former to get a hopefully stable release, and the latter to give them
> the time needed to make their developments and testing, without
> everything else in boost changing all the time.
I'll answer this from my perspective on this. Robert may do so from
his perspective.

Since the economic crash around 2008-2009, commercially sponsored
work on Boost has enormously dried up which forced some of the big
names to leave for greener pastures (e.g. Boost Consulting wound up),
plus we got hit with a double whammy of the C++ 11 STL providing much
of Boost, thus eliminating the commercial need to sponsor Boost
specifically fixes in Boost.

I have managed to make an hourly paid living this past year from some
very limited Boost related commercial sponsorship, but just recently
they decided that C++ takes too long and are rewriting everything
into Rust, so I suspect I'll have to leave Boost for greener pastures
myself in six months or so.

Anyway, from my perspective the big problem is funding, or lack
thereof. It takes a lot of time and effort to fix bugs, and very few
maintainers want to exchange their unpaid family time for fixing bugs
when they could be doing interesting stuff instead. Don't get me
wrong, I think the community has done a lousy job relative to other
open source communities on the business side of things on constantly
lobbying for and funnelling monies into Boost - we only gained a
Donate facility last year, and it was I who made that happen, and it
tooks months of effort. I also think we do a lousy job of creating
incentives (Robert would call it blackmail) for commercial
sponsorship of older libraries by routinely kicking anything not
maintained out of the main distro so we regain a lean, slim and
tightly focused Boost. I personally am aiming to fork Boost into a
C++ 11 only 2.0, and indeed this C++ Now I'll present on tooling to
help with that.

Myself and Robert do agree though that users don't pay their fair
share. They get high quality libraries, but don't pay a commensurate
amount for that. Equally, many of them would *like* to pay for it, in
particular they would *love* to pay for timely bug fixes. The
Steering Committee has not smiled on those arguments though. And
without community consensus, it's tough to create movement.

I might add that Robert has his incubator
http://rrsd.com/blincubator.com/ where I think he has a bug bounty
system configured? I personally think the bug bounty system needs a
monthly emailed scoreboard, with escrow for the bounties. Again
though, that would need community consensus to make happen. There is
a strong antipathy against making Boost into a viable business.
Stemming from its origins, it's supposed to be about the pet "hero"
library project, not making a living.

Robert is speaking at C++ Now about the future of Boost, and I'll be
there too.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/



_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users

SMime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: what happens between "fixed in development" and "available in release"?

Oswin Krause
In reply to this post by Robert Ramey
On 19.03.2015 16:41, Robert Ramey wrote:

> Oswin Krause wrote
>> Hi,
>>
>> Question is in the subject. What has to happen after a fix of a bug in
>> development stage before it enters an official release?
> What has to happen is that I have to merge the serialization develop branch
> to the master branch.  My procedure is:
> a) switch my local copy of the serialization library to master branch.
> b) merge in current develop branch
> c) update my local modular boost tree - which is always kept on the master
> branch
> d) (re)run all serialization library tests with clang and gcc compilers for
> DLL and static libraries and debug and release libraries.  These
> combinations come to about 2000 tests which are presented in a giant table
> which has to come out all "green"  This isn't really enough as it should
> include a couple of versions of VS but I don't have that around.
>
> In this particular instance, I had trouble with step c).  This is not
> unusual as I have to confess the git submodule setup is pretty confusing and
> I don't do it all that frequently.  When I finally managed to get this done,
> I found that the code that I use to review the results (tools/regression)
> has been removed from the master branch.  Of course this was a surprise to
> me!  Apparently I'm the only one that uses this code (not a huge surprise,
> I'm not sure why though).  So now I have to remember how to get this thing
> built again and figure out where I'm going to keep it.
>
> So all in all this ends up taking a lot more time than one would expect.
>
> You might ask - why not just merge develop into master and watch the test
> results?  I would answer that I've learned the hard way that taking a
> "shortcut" can lead to repercussions which such up lots, lots more time.
> Even investing the effort above, the bug that provokes this email still
> managed to creep in and was not detected by my tests.
>
> Note that all the above doesn't actually include the time finding reported
> bugs.  These are pretty infrequent these days - but are often a major bitch
> to reproduce, find and fix. Often they are artifacts of standard library
> implementations which are very time consuming to track down.
>
> I hope that answer's your question.
>
> Robert Ramey
Hi Robert,

Thank you for your reply. I am reading all replies and comments but
right now I do not see that I can propose anything to help the current
situation or to "relieve the burden", other then waiting patiently until
this is done. In general it seems to be a bit problematic to actually
help boost overall. Maintainers seem to have a very high workload (which
only very few people would accept to do besides work) and there is not
much one can do to help. Squashing bugs is one thing. If the merging and
testing part takes 200h this is something i would not be able to do.

So what do you guys think: is there something one can do with a
reasonable workload ~20h/month to help the overall situation?
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: what happens between "fixed in development" and "available in release"?

Niall Douglas
On 20 Mar 2015 at 14:45, oswin krause wrote:

> So what do you guys think: is there something one can do with a
> reasonable workload ~20h/month to help the overall situation?

A big problem for a lot of Boost libraries is lack of issue
verification, so when someone submits an issue you really could do
with an independent third party to replicate it. That usually filters
out a good 70% of reported issues, so it's very valuable. Any
maintainer hugely appreciates it.

Another useful thing to do is to configure a Jenkins CI or a Travis
CI for a project which runs a useful subset of unit tests per commit.
Since I added Thread to my Jenkins install, Vicente the maintainer -
who won't use Windows - hasn't broken the Windows build on develop
branch. A big help.

Finally, for bug fixes or feature adds the no 1 biggest mistake
contributers make is not clearing how best to fix or add the feature
with the maintainer before writing any code. This cause is a big part
of the 50% or 60% ignoring of patches and pull requests submitted.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/



_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users

SMime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[boost 2.0] was ...

Robert Ramey
In reply to this post by Niall Douglas
Niall Douglas wrote
Since the economic crash around 2008-2009, commercially sponsored
work on Boost has enormously dried up which forced some of the big
names to leave for greener pastures (e.g. Boost Consulting wound up),
plus we got hit with a double whammy of the C++ 11 STL providing much
of Boost, thus eliminating the commercial need to sponsor Boost
specifically fixes in Boost.
My view is simpler.  I believe that boost has been successful in it's original
mission and needs to find a new / related one.  I have my own agenda
for this "new" mission and I work hard to promote it.
Myself and Robert do agree though that users don't pay their fair
share.
LOL, I have no expectation that life is going to start being "fair".
They get high quality libraries, but don't pay a commensurate
amount for that. Equally, many of them would *like* to pay for it, in
particular they would *love* to pay for timely bug fixes.
But I am interested in finding a way to fund quality library development.
And I to my my mind this line of thinking points in the right direction.
I have some ideas - but they aren't well developed and I'm happy
that others are thinking about it and making suggestions.
The Steering Committee has not smiled on those arguments though. And
without community consensus, it's tough to create movement.
I don't think that a consensus is possible, but neither do I think it's
a requirement. I don't think boost needs to have anything to do
with funding library development/maintainence.  In fact, for a number
of reasons I think it's better if doesn't.  This is still a wide open
topic.
I might add that Robert has his incubator
http://rrsd.com/blincubator.com/ where I think he has a bug bounty
system configured? I personally think the bug bounty system needs a
monthly emailed scoreboard, with escrow for the bounties. Again
though, that would need community consensus to make happen.
I don't have such a "bounty" system configured.  I'm not convinced that
its the way to go.  If you look at www.blincubator.com you can find
the information regarding "library sponsorship".  It isn't featured
prominently as I have my hands full with other stuff and I'm not in
a position to promote it. I'm also reluctant to dilute my current focus of
getting the incubator "sold" as "the" way to get a library developed
and reviewed.  But I am interested in it.
There is a strong antipathy against making Boost into a viable business.
Stemming from its origins, it's supposed to be about the pet "hero"
library project, not making a living.
This is why I think that funding of library development has to occur
outside of boost.  Boost can maintain it's role of gatekeeper of software
quality while permitting funding of libraries independent of boost.  
Certainly, some libraries have been funded this way - Gil .
Robert is speaking at C++ Now about the future of Boost, and I'll be
there too.
Thanks for plugging my talk.  It's 8:30 in the evening of the first day.
I certainly hope that I get more than the 35 attendees I got the last
time!.

I've looked over the conference schedule.  There are a number of presentations
of varying lengths which touch related topics.  It is my plan to preview
the substance of my presentation with those other presenters in advance.
This will give them the opportunity to contrast their ideas with my proposals
if they so desire.

This could be the most exciting Boost Conference yet !!!

Robert Ramey
Reply | Threaded
Open this post in threaded view
|

Re: what happens between "fixed in development" and "available in release"?

John Maddock-2
In reply to this post by Oswin Krause

>
> So what do you guys think: is there something one can do with a
> reasonable workload ~20h/month to help the overall situation?

Yes for sure:

1) focus: decide which parts of Boost you're interested in and largely
stick to those.
2) Try to help the maintainer make the test suite bullet-proof.  IMO the
best maintained libraries are those with the most complete test
coverage.  Obviously it varies a bit how much this helps: things like
thread, futures, or other things that hit the OS directly are likely to
be the hardest to test empirically, which may be why Niall has had such
a hard time!
3) Filter bug reports, try to reproduce, convert bug reports into PR's,
with really good enhancements to the test suite to prevent recurrences.
4) Talk to the maintainer, find out what really needs doing, what the
blockers are, how PR's can be structured so that accepting the patches
is a no-brainer.
5) If a library has a lot of bug reports and/or PR's try to figure out
why that is.  OK no lib is perfect, but we should be aiming for as close
to "zero maintenance" as we can get (excluding new features and/or
modernizations).  Is it lack of testing?  A conceptual deficit?  Poorly
structured code that can't be maintained?

Above all.... don't be scared to get stuck in!

HTH, John.
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users