If there are issues fixed in develop branch, it would help a lot to inform users by updating the tickets accordingly.

...

If there are issues fixed in develop branch, it would help a lot to inform users by updating the tickets accordingly.

Here is a blanket update message: at this point all the issues with Boost.Test are fixed on devel branch ;).

a) fixes are useless to users if they are not made available. read: not merged from develop to master. if you fail to do that for whatever reason, don't call it "fixed". b) 'blanked update messages' about anything that is done on an a develop branch, is useless for people who are submitting and/or watching tickets. ---- if for whatever reason you are not able to maintain boost.test or cannot devote any time on this, you might want to accept help from others. that said: i had been in the situation that tests for one of my boost libraries failed in the master branch due to bugs in boost.test, which "are fixed in develop". it is simply unacceptable for a framework like boost not to be able to rely on its own testing library. br, tim

...

b) 'blanked update messages' about anything that is done on an a develop branch, is useless for people who are submitting and/or watching tickets.

When one is expected to close the ticket? When fix is checked into devel or when fix is merges into master? Former is better for developer who can put the trac number into commit message and be done with it. Later is better for users, since there always will be some gap between commit and master merge. Yet it requires more effort/discipline from developer. I am not convinced which one is better. Maybe we can mark ticket as fixed at commit time, and make it merged/publically available when fix is merged to master. Can we tweak trac/svn hooks so that we introduce another state change?

https://svn.boost.org/trac/boost/ticket/7410 status: closed, "fixed" https://svn.boost.org/trac/boost/ticket/7397 https://svn.boost.org/trac/boost/ticket/7417 https://svn.boost.org/trac/boost/ticket/7419 https://svn.boost.org/trac/boost/ticket/10888 status: new 7410 was "fixed" 2 years ago. it is not fixed from the perspective of any user of a released version of boost, though. 7397, 7417 and 7419 are open for over 2 years with *NO* comment, except for your "blanked update message". -- personally i'd resolve an issue as "fixed", iff the end user will receive the fix in the next release.

...

if for whatever reason you are not able to maintain boost.test or cannot devote any time on this, you might want to accept help from others.

For various reasons, what needs to be done here seriously exceed the volume of regular maintenance, which I am fine with. Thus the delay. That said I did ask for help with this work. One person replied and we are working on making this happen. Now it seems more people are interested, so I can be somewhat positive on claiming that you should see real process soon.

is "soon" a matter of days, weeks, months or years?

Rob Stewart writes:

I agree that "fixed" must be reserved for when the issue hits a Boost release.

Until trac is fixed/changed unfortunately the things are going to stay as is. I am putting trac number into commit message when the specific changes are actually committed. Single commit which is going to be used to move things from develop to master is not a good fit for the "fix revision". I am fine with adding some track numbers to this commit which would mark these tickets as "released", but this is not possible at the moment AFAIK. Gennadiy

Vladimir Prus writes:

Gennadiy,

I might be mistaken, but in Trac, you can either say:

Addresses #100

or

Fixes #100

The former adds a comment to issue, so keep everybody updated. The latter does the same, and also completely closes the issue.

Would that work for you?

I might consider this, but what I was after is something different. I want to fix the ticket with actual commit and than in a commit which brings changes from develop to master I do not really want to remember which tickets this fixes/addresses (especially since I might be doing it half a year later with potentially dozen or more fixes bundled together) . I'd rather say something like: I am releasing all the fixes since last release and that should change the status of all fixed, but not released tickets into "released". Vlad I have a separate request for you. Would you mind giving me a hand as Boost.Build expert. I've been trying to use doxygen rule, but I find it ... essentially unusable. The output it produces has number of issues: * it is missing all class level sections * it only generates "file view", while "official" doxygen output is much more rich. Class view, namespaces view, module view etc. * the output format is very rigid, resulting in some text running out of the screen There is significant (and important) part of documentation I want to place into the reference section. I can't find anyone to help me with the doxygen rule. So now I am asking: would it be possible to just run native doxygen command, collect the output as is and somehow bind it to my quickbook based docs? Any help would be appreciated. Gennadiy

Gennadiy, On 12/31/2014 01:44 PM, Gennadiy Rozental wrote:

Vladimir Prus writes:

...

Gennadiy,

I might be mistaken, but in Trac, you can either say:

Addresses #100

or

Fixes #100

The former adds a comment to issue, so keep everybody updated. The latter does the same, and also completely closes the issue.

Would that work for you?

I might consider this, but what I was after is something different. I want to fix the ticket with actual commit and than in a commit which brings changes from develop to master I do not really want to remember which tickets this fixes/addresses (especially since I might be doing it half a year later with potentially dozen or more fixes bundled together) . I'd rather say something like: I am releasing all the fixes since last release and that should change the status of all fixed, but not released tickets into "released".

There might not be a fully automatic solution, but some fairly lightweight conventions can make this almost painless: - Adopt "Linux" style for commit messages, where first line is a brief summary of the change. - Further include Trac issue in that line. - When you merge from develop to master, use "git shortlog master..develop" to get a list of those one-line summaries that are to be merged, and base commit message for the merge on the output. That way, it will be not much work to actually close all merged tickets, and it will be easy to create automation to do this in future.

Vlad I have a separate request for you. Would you mind giving me a hand as Boost.Build expert. I've been trying to use doxygen rule, but I find it ... essentially unusable. The output it produces has number of issues:

* it is missing all class level sections * it only generates "file view", while "official" doxygen output is much more rich. Class view, namespaces view, module view etc. * the output format is very rigid, resulting in some text running out of the screen

I would like to help, but Boost.Build only runs doxygen and then invokes various XSLT tarnsforms. Everything else is either doxygen itself, or Boost.Book, where I can only make trivial tweaks.

There is significant (and important) part of documentation I want to place into the reference section. I can't find anyone to help me with the doxygen rule. So now I am asking: would it be possible to just run native doxygen command, collect the output as is and somehow bind it to my quickbook based docs?

What do you mean by 'bind' here? Maybe you can ask a separate thread, describing what you want, so that Boost.Book experts notice it more easily? Thanks, -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

Paul A. Bristow writes:

I'm not sure if the above are not 'features',

I am afraid some of them are. And that's why I want to drop this completely.

but can I look at your work so far in the develop branch?

Yes you can.

Also are you confident that the various parameters in the doxyfile the same as passed to Quickbook tools chain?

Raffi, can you comment on this?

Is your doxyfile saved somewhere (I have created a doc/doxygen folder for this purpose)

Yes. The same place.

Are you using autoindex yet? This may allow people to find what they want rather than looking at a class/module/namespace view?

Yes. I'd like to use auto index (may not be in a first cut of new docs). Yet IMO this is not replacement for a proper reference docs. Maybe it can allow me to get rid of Glossary section. Gennadiy

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Raffi Enficiaud Sent: 04 January 2015 01:06 To: boost@lists.boost.org Subject: Re: [boost] [test] boost.test owner unresponsive to persistent

problems for

multiple years

Gennadiy Rozental writes:

...

Paul A. Bristow writes:

...

Also are you confident that the various parameters in the doxyfile the same as passed to Quickbook tools chain?

Raffi, can you comment on this?

Hi,

My name is Raffi and I am working on boost.test with Gennadiy.

I enabled the options that show everything but the private and @internal documentation. What I do is that I look at the intermediate XML generated by the doxygen bjam target. If the documented entities are there, I suppose that the doxygen configuration is correct.

Some of the problems we encountered: - @overload works for free functions but generates warnings in quickbook for member functions - grouping of member function using @name completly hides those in quickbook (no warning) - @section not shown - @param is sometimes not shown in the generated Quickbook

First, I can confirm that I can build the Quickbook docs and the standalone Doxygen docs. Second, I think you have done a *great job* here - looks nice and I could find my way around easily. Third This should definitely go into master ready for the next release. Even with some wrinkles noted above, it will help users a great deal. Fourth The Standalone Doxygen shows the structure and how it works internally. It makes the code maintainable at last, but should not be necessary for the users. So just providing the doxyfile in the /doc folder seems fine to me. Anyone wanting to do maintenance (or ferret in the innards) can build it easily using the Doxywizard. (For Windows users, I favour renaming it to a unique name and file type, say test_doxyfile.txt). This makes up for any limitations in the Quickbook C++ Reference section. My only immediate criticism is that I think placing the Output in a second box to the right of the Code makes assumptions about page width that are probably unjustified, especially on tablets and phones (which are often used as a second screen to display manuals etc). The output box is certain to overflow many screens and will definitely mess up a PDF version making it useless. I can see that it makes sure that the output is close to the source, but vertical space is unlimited, whereas width is precious. I have yet to understand if/how you are using Quickbook code snippets - all the examples seem to have the same name "example_code" ? And this example at least doesn't use a code snippet. `` #define __BOOST_TEST_MODULE__ My Test #include __BOOST_AUTO_TEST_CASE__(first_test) { __BOOST_TEST__(true); int i = 1; __BOOST_TEST__(i == 2); } `` Code snippets are valuable because the ensure that the code in the docs is the code in the example and actually runs. Similarly the output can make ensuring this much easier. As to the problems above, I have yet to find time to study in detail, but getting free of warnings may not be practical (at least until Doxygen is modified to use the Clang compiler, when it will *really* understand C++ code). Its current parsing is impressive considering the labyrinthineness of C++ language, but imperfect. One thing I am fairly sure is that the @internal command was not found to work right by Steven Watanabe (our expert on Quickbook internals whose has fixed some previous bugs, but currently busy on other things). I have, at his suggestion, used the \cond ... \endcond command instead to remove implementation details from Doxygen's sight. So this is method to use for this (and using a name \cond DETAILS ... ) allows the maintainer to show everything, including things brackets by DETAILS, or not). Some of the bug reports suggest that @ as a trip character may produce different (wrong?) results compared to backslash \ as trip. This may be 'cured' now. I've built with the hot-off-the-press bug-fix release 1.8.9.1. I'll see if I can deal with any of the other wrinkles above later. HTH Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Raffi Enficiaud Sent: 06 January 2015 01:53 To: boost@lists.boost.org Subject: Re: [boost] [test] boost.test owner unresponsive to persistent

problems for

multiple years

You have a point. Our current concern is that the documentation is huge and it is hard to find a good way of presenting all the features in boost.test. Parts such as execution monitor are very advanced, and have enough content to have their own section. This thing is that, from a user perspective, it is hard to understand what such parts have to do with boost.test. So we think it is better to have a separate document for these parts.

One option is to have these parts documented in doxygen only, with \sections and everything doxygen is able to provide. The other option is to have several quickbook documents (users guide, users reference, advanced topics, full reference), but I do not know if it would address the issue.

I'm not understanding why you can't use a separate Quickbook section called "Advanced" and provide the execution monitor stuff there. What is it that is so different about this that the Quickbook structure etc cannot provide? The document size is irrelevant - what counts is finding what you want to know. The TOC is the first weapon, and the (auto-)index second, and the C++ reference third.

...

My only immediate criticism is that I think placing the Output in a second box to the right of the Code makes assumptions about page width that are probably unjustified, especially on tablets and phones (which are often used as a second screen to display manuals etc).

...

The output box is certain to overflow many screens and will definitely mess up a PDF version making it useless. I can see that it makes sure that the output is close to the source, but vertical space is unlimited, whereas width is precious.

...

...

I have yet to understand if/how you are using Quickbook code...

We use a template, and those changes are straightforward. I was wondering if, with quickbook, it would be possible to have: - either an output that is "folded" by default and "unfolded" dynamically when the user clicks it - or an output created on another page, without creating a section under the current one - and finally if all these can be easily disabled for the PDF output

Finally, for the arrangement of the table columns, would some "fluid container" provided by bootstrap address this issue?

There are some conditional tools in Quickbook - see the manual " Conditional Generation Like C++ #ifdef, you can generate phrases depending on the presence of a macro. Example: ... " that may make this possible? With some work and yet more complexity :-( But IMO having the output to the right just isn't helpful anyway. I really don't see the benefit (and lots of non-benefits ;-). However, you two obviously like it - so why not put the built html somewhere and let the users comment on whether they like it? Ship the whole built /doc and subfolder like/html and /doxygen section to your Dropbox or somewhere and provide a link to it?

We use code snippet almost everywhere. The example you mention has also its .cpp and has been checked, although not in an automated manner. We reproduced the code in this very example because we wanted the macros expansion. All snippets have the same markup "example_code" (looks like a trick to quickbook) and allows us to use the same template for all snippets/examples. This is also the case for the outputs.

Ah - I see why you have done this now. (Not sure I would have done but ...)

Ok. What I see is that the \internal pieces appear in the final XML, without any mention of the internal itself.

\code ... \endcond works for me.

I also noticed that the operator overload is not properly rendered.

Others have noted difficulties with this - and recently. Not sure if and how it can be fixed.

...

Some of the bug reports suggest that <at> as a trip character may produce different (wrong?) results compared to backslash \ as trip. This may be 'cured' now. I've built with the hot-off-the-press bug-fix release 1.8.9.1.

One last question: I just noticed the existence of the develop doc website http://www.boost.org/doc/libs/develop/libs/libraries.htm

How often is it updated?

Daniel James is your man to ask. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Gennadiy Rozental Sent: 08 January 2015 17:35 To: boost@lists.boost.org Subject: Re: [boost] [test] boost.test owner unresponsive to persistent

multiple years

Paul A. Bristow writes:

...

I'm not understanding why you can't use a separate Quickbook section called "Advanced" and provide the execution monitor stuff there.

I am trying to make Boost.Test UTF the interface these docs will describe (isn't this what you wanted?). Thus we dropped: test execution monitor, program execution monitor, execution monitor from all the user's guide and advanced usage

problems for sections. I can't see why you want to hide these from view. Some users may want them?

Few components which I still want to cover I placed in reference docs. This location makes most since this is really is a programmer interface with some semantic behind it.

...

The document size is irrelevant - what counts is finding what you want to know.

Yes and No. The main intention here is to ensure that users will never get confused these components as public interfaces of UTF. I intentionally want them to look very different.

...

The TOC is the first weapon, and the (auto-)index second, and the C++ reference third.

Not quite sure how index is going to help with what I am after.

The index may not help you but it should help the *user* find what he wants to know. It's just one tool in the navigation game. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Gennadiy Rozental Sent: 08 January 2015 17:25 To: boost@lists.boost.org Subject: Re: [boost] [test] boost.test owner unresponsive to persistent

problems for

multiple years

Paul A. Bristow writes:

Hi Paul,

...

Second, I think you have done a *great job* here - looks nice and I could find my way around easily.

...

Fourth The Standalone Doxygen shows the structure and how it works internally. It makes the code maintainable at last, but should not be necessary for the users. So just providing the doxyfile in the /doc folder seems fine to me. Anyone wanting to do maintenance (or ferret in the innards) can build it easily using the Doxywizard.

I have to disagree with you on this point:

1. We deliver C++ libraries. Reference documentation is essential part of that which. One of the long standing criticism of Boost.Test docs was an absence of proper reference docs. Thus I believe these pages are not (only) for library

OK - well how about providing just the Standalone Doxygen docs, prebuilt in doc/doxygen, and accessible view a link from the main docs TOC? maintainers,

even though User's guide cover all the most common interfaces users need in more friendly format. There are number of extension APIs which require understanding of specific classes (for example to implement custom log output formatter)

2. Another long standing complain from several people (including you if I am not mistaken) was that Boost.Test documentation is poorly organized and just too big. Some people (not to point fingers) suggested to just drop documentation for some of the components of Boost.Test, because they are not important (not used) and confuse the users.

IMO they are wrong - it is not the *size* but the *search and navigation* that were missing/misleading. But for others to comment usefully on Boost.Test new docs , you need to put the *built* docs somewhere (most people don't have tools to build in place). Putting the derived files in /doc/html in GIT is a recipe for trouble (as we have found with Boost.Math) if you have more than one author. But as a *temporary measure* while you get comments this might be good? Dropbox? (but then it looks horrible without access to the .css, icons and logo etc)

To improve the organization of documentation for this version I've split the docs into three separate "domains": User's guide, Advanced Usage Scenarios (I am open for better name here) and Reference. Most public interfaces and components are covered in a first one. Some uncommon customization options and advanced components of Boost.Test (interaction testing for example) are going to be covered in a second. Finally some of the components on Boost.Test which are not part of public API, but can be used independently of Boost.Test plus specific API of classes which are used for code level customization are covered in reference section.

I would like to see all three sections to be accessible online and not require users to generate one when necessary.

3. Having "castrated" reference along the Users's guide and real reference on a side seem a rather strange setup.

4. Reference pages produced by quickbook/doxygen rule are unacceptably ugly, missing lots of things (for example they are missing all class level sections and [in] designation for function arguments among many other things). They are also uses least useful file based view on a reference.

In a summary: if I can help it we will drop the doxygen rule and just generate proper reference pages.

OK - If you think that Quickbook/Doxygen C++ reference section is unhelpful, then use the Standalone Doxygen, and just link to it, something like "Boost.Sort C++ Reference section is provided in Doxygen format at" [@/doxygen/index.html] But it is the content of the Doxygen comments and links, especially to examples, that are the key to it being useful to the user (rather than to maintainers).

...

My only immediate criticism is that I think placing the Output in a second box

I agree with you here. I do not like the current output as well. What do you suggest instead? You seem to dislike my toggle idea.

I'd just put the output is a snippet below. It doesn't matter if it is long and tedious - users will scroll over or hyperlink somewhere else quickly. This seems to work perfectly well in many libraries. Another way is to use callouts (I dislike these, as footnotes, because they force the user to move his eye down to the bottom of a potentially-off-the-page page). For simple one-line outputs, you can add inline comments std::cout << 2 + 2 << std::endl; // Outputs: 4 HTH Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

Vladimir Prus wrote:

I might be mistaken, but in Trac, you can either say:

Addresses #100

or

Fixes #100

You're not mistaken, this is what I did in the SVN days, except I used "Refs #100" when committing to trunk, and then "Fixes" when merging to release. One needed to keep track of what commit fixed what ticket though. But we're no longer on SVN. Do those work today?

On 31. des. 2014 15:49, Vladimir Prus wrote:

On 12/31/2014 04:04 PM, Peter Dimov wrote:

...

Vladimir Prus wrote:

...

I might be mistaken, but in Trac, you can either say:

Addresses #100

or

Fixes #100

You're not mistaken, this is what I did in the SVN days, except I used "Refs #100" when committing to trunk, and then "Fixes" when merging to release. One needed to keep track of what commit fixed what ticket though.

But we're no longer on SVN. Do those work today?

I though there was effort to make this happen, but looking now, don't see any webhooks on our git repositories. Daniel, would it be easy to revive?

It looks at least to be supported from trac 1.0 onward, and as a third party plugin before that. http://trac.edgewall.org/wiki/TracGit which mention http://trac.edgewall.org/wiki/CommitTicketUpdater to do these things. The pages does however indicate some performance issues with larger repositories and the Git integration. There need to be tracking local clones of the repositories at the trac server. Tighter integration with GitHub repositories and features than what this plugin currently seems to support may be desirable. Maybe: https://github.com/aaugustin/trac-github could be used. I suspect migrating away from trac in a sensible way is a lot more work though, so this may be worth it. -- Bjørn

[Please do not mail me a copy of your followup] Gennadiy Rozental spake the secret code thusly:

...

is "soon" a matter of days, weeks, months or years?

We had a good progress recently. If things go well (more people join the effort) - weeks. Less optimistic - months.

Why does it take weeks or months to release a fix that has BEEN DEVELOPED YEARS AGO? Honestly, this snails pace is maddening. Yes, there's always an excuse, but we're talking a simple bug fix here that has been prevented from appearing in a release FOR FIVE YEARS. "Fixing" to a development branch is not fixing. It's not fixed until it shows up in a released version of boost. Five years is long enough to wait, any reasonable observer would conclude at this point that there is noone seriously working to fix anything in this library and they'll just use google test which releases fixes promptly. -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

On Sat, Jan 3, 2015 at 2:45 AM, Gennadiy Rozental wrote:

Richard writes:

...

[Please do not mail me a copy of your followup]

Gennadiy Rozental spake the secret code thusly:

...

...

is "soon" a matter of days, weeks, months or years?

We had a good progress recently. If things go well (more people join the effort) - weeks. Less optimistic - months.

Why does it take weeks or months to release a fix that has BEEN DEVELOPED YEARS AGO?

I appreciate that you care a lot about the quality of our library. If you had accepted my offer of collaboration a year ago, I think we would be in much better shape now. As it is, we should be fine as well, but it takes somewhat longer.

Why does it take so long? -- Olaf

Hi! Am Montag, 5. Januar 2015, 19:07:51 schrieb Richard:

[Please do not mail me a copy of your followup]

You have said before that you are pressed for time to work on this library and move things forward in a timely manner. Simple fixes that take more than 5 years to appear in a release speak volumes to this.

The main issue seems to be the major refactorings in the develop branch. It is easy to blame the tool, but the new functionality should have been develop in a separate feature branch. This is what several other projects do with success. And the monolitic svn repository made this difficult at least. "develop" should really be treated like "maintenance" in my opinion. And regularly be merged to master.

If you don't have time to maintain this library in a realistic manner, then you should hand it over to someone else. Even with collaboration, you're saying it will takes weeks and months to get fixes released that have been prepared over 5 years ago.

I think Gennadiy is refering to the whole docs and _refactorings_ release which will of course include the bug fixes. And this unfortunately takes time.

That just plain sucks. There's no way to sugar coat it.

As both fixes and features are intertwined, the only other solution would be to get a list of only the "fixes" and cherry-pick them to the release branch as quick as possible. Just prepare a set of pull request for master doing this. One thing git is good for and which really sucks with svn. In my eyes the main lesson this teaches us is to always to massive refactorings and features on dedicated branches with git. Testing those is a different matter, of course... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany

On 9/01/2015 06:51, Gennadiy Rozental wrote:

Jürgen Hunold writes:

...

The main issue seems to be the major refactorings in the develop branch. It is easy to blame the tool, but the new functionality should have been develop in a separate feature branch.

When development started we were still in svn. I think we'll use this model from now on.

Just as a bystander comment -- I haven't looked into the specific issues in question here and what severity they have -- but what I've gathered from the thread so far is that the develop branch is in the middle of a long and winding refactoring/redesign that is likely to take quite a bit longer before it is all finished off and ready to release, and that several bugfixes (whether major or minor I don't know) have been caught up in this and held back from release as a result. One of the nice things about git is that branches are just labels. They carry no meaning beyond what you care to assign to them, and can easily be moved around. In particular the only magic thing about the "develop" branch, as far as I understand it, is that the automated tests can be run against it. This suggests a way out, if you want to satisfy both goals of quickly getting these bugfixes into a releasable state while also continuing work on the larger refactoring: 1. Rename the current "develop" branch to "bigrefactor" or similar. 2. Create a new "develop" branch from "master". 3. Cherry-pick or apply as new the individual fixes for whichever issues you want to get releasable. 4. Let the automated tests cycle and do anything else necessary to be happy with the fixes. While waiting for automated tests or anything else you can continue working on the big refactor in its separate branch. 5. Once all is happy, merge develop to master. 6. Rebase "bigrefactor" onto the new master. (Optional, but keeps things tidier, albeit at the cost of possibly annoying anyone else who has a clone of it.) 7. Either rename "bigrefactor" back to "develop" or leave it separate for future quick-fixes. As to whether this is worth it for these particular issues -- well, only you can decide that.

[Please do not mail me a copy of your followup] =?ISO-8859-1?Q?J=FCrgen?= Hunold spake the secret code <21551292.TRXuOOeVXD@speed> thusly:

Am Montag, 5. Januar 2015, 19:07:51 schrieb Richard:

...

[Please do not mail me a copy of your followup]

...

You have said before that you are pressed for time to work on this library and move things forward in a timely manner. Simple fixes that take more than 5 years to appear in a release speak volumes to this.

The main issue seems to be the major refactorings in the develop branch.

...but we only got to this sad, sorry state because the develop branch was allowed to diverge from master for MANY YEARS without ever releasing anything. That has nothing to do with refactoring and everything to do with how the library has been maintained. -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Raffi Enficiaud Sent: 06 January 2015 00:39 To: boost@lists.boost.org Subject: Re: [boost] [test] boost.test owner unresponsive to persistent problems for multiple years

Richard writes:

...

If you don't have time to maintain this library in a realistic manner, then you should hand it over to someone else. Even with collaboration, you're saying it will takes weeks and months to get fixes released that have been prepared over 5 years ago.

We have time and we are 2/3 good willing people now.

...

That just plain sucks. There's no way to sugar coat it.

I think an overall change of tone would be appreciated.

Can the Boost.Test docs at least acknowledge that Richard (Anonymous) has made a big contribution to providing fixes, did lots of work showing the way for improved documentation, and finally spurred Gennadiy into some (a lot of) real action to get Boost.Test in a working-properly state? And then call it a day on this thread? Paul PS I think the Boost community has handled this badly - we should never have gotten into a situation where a lone worker was solely controlling a key library used by almost all others. We've avoided it on all other key libraries (like Boost.Config); we must never get in this mess again. --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

Stephen Kelly wrote:

Paul A. Bristow wrote:

...

a situation where a lone worker was solely controlling a key library used by almost all others.

Isn't that exactly how boost is designed to work?

No. A design is not synonymous with its failure modes.

Paul A. Bristow wrote:

Things that effect *everyone* require consultation and some degree of consensus.

The maintainer is always the decider. Consensus, even loose consensus, doesn't affect Boost at all afaik. I realize you don't see it that way. Thanks, Steve.

[Please do not mail me a copy of your followup] Edward Diener spake the secret code thusly:

On 1/8/2015 2:19 PM, Stephen Kelly wrote:

...

Paul A. Bristow wrote:

...

Things that effect *everyone* require consultation and some degree of consensus.

The maintainer is always the decider. Consensus, even loose consensus, doesn't affect Boost at all afaik. I realize you don't see it that way.

I approve the fact that a primary maintainer is the decider. Someone has to be in charge, and surely that someone who did all the work of creating the library in the first place is the best candidate. If you disagree enough with the primary maintainer and feel your ideas/implementation are not being regarded and are better you can always create another library that reflects your own ideas and notify people on this mailing list about your own library.

In this case, that's already been done. It's called google test (gtest). -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

[Please do not mail me a copy of your followup] =?windows-1252?Q?Bj=F8rn_Roald?= spake the secret code <54B0E109.8060307@4roald.org> thusly:

On 10. jan. 2015 02:06, Richard wrote:

...

[Please do not mail me a copy of your followup]

Edward Diener spake the secret code thusly:

...

On 1/8/2015 2:19 PM, Stephen Kelly wrote:

...

Paul A. Bristow wrote:

...

Things that effect *everyone* require consultation and some degree of consensus.

The maintainer is always the decider. Consensus, even loose consensus, doesn't affect Boost at all afaik. I realize you don't see it that way.

I approve the fact that a primary maintainer is the decider. Someone has to be in charge, and surely that someone who did all the work of creating the library in the first place is the best candidate. If you disagree enough with the primary maintainer and feel your ideas/implementation are not being regarded and are better you can always create another library that reflects your own ideas and notify people on this mailing list about your own library.

In this case, that's already been done. It's called google test (gtest).

I am confused, are you responding on behalf of Paul, or yourself Richard?

I always speak on behalf of myself. All I'm saying is that gtest is gaining acceptance because it supports its community of users in a reasonable way. Boost.Test is losing ground and has been losing ground for 5+ years. How often do you see anyone out there making a library that duplicates the functionality of a boost library? I haven't seen it happen very often and at the moment, the only example I can think of is Boost.Test. There are MULTIPLE test frameworks out there that are gaining users at the expense of Boost.Test. The idea of "well, if you don't like what's happening, you should fork and go your own route" is not interesting to me, because if I'm going to abandon Boost.Test, I'll just use gtest. There's no need to reinvent my own test framework when there are other options out there.

if your intentions are too take over Boost.Test ownership and make it more or less into gtest, possibly breaking compatibility with existing test code.

I offered to take over maintenance ownership of the library a while back (9 months ago? I don't remember exactly when) and the offer was declined. Had I been given that authority, then the docs and simple fixes waiting 5 years to appear in a release would already have shipped with 1.56 and we'd be moving on. Instead, we're still waiting for simple fixes to show up after 5 years of waiting. We're told that we'll have to keep waiting for simple fixes that were prepared 5 years ago to show up. With that sort of progress, I can't fault anyone for using google test. That is exactly the sort of attitude that results in the really great book "Modern C++ Programming with Test-Driven Development" by Jeff Langr http://amzn.to/15bvh9C relegating Boost.Test to a bare mention in an appendix and using gtest throughout the book for all the examples. Boost.Test is not leading mindshare. With an attitude that 5 years of waiting for simple fixes is acceptable, why would anyone be surprised?

Thanks for your effort by the way Richard! I do however think you should moderate your tone, hidden or literate, in some of your postings given the maintainer seems to be responding now and have co-maintainers/helpers.

The time for laughing with puppy dogs and picking daisies in a sunny verdant field is long gone. After waiting 5 years for the simple issue cited in this thread to be resolved I'm told that I have to keep waiting and to be patient. 5 years is long enough for anyone to wait. My patience has long since been exhausted. -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

On 1/21/2015 5:26 PM, Richard wrote:

[Please do not mail me a copy of your followup]

=?windows-1252?Q?Bj=F8rn_Roald?= spake the secret code <54B0E109.8060307@4roald.org> thusly:

...

On 10. jan. 2015 02:06, Richard wrote:

...

[Please do not mail me a copy of your followup]

Edward Diener spake the secret code thusly:

...

On 1/8/2015 2:19 PM, Stephen Kelly wrote:

...

Paul A. Bristow wrote:

...

Things that effect *everyone* require consultation and some degree of consensus.

The maintainer is always the decider. Consensus, even loose consensus, doesn't affect Boost at all afaik. I realize you don't see it that way.

I approve the fact that a primary maintainer is the decider. Someone has to be in charge, and surely that someone who did all the work of creating the library in the first place is the best candidate. If you disagree enough with the primary maintainer and feel your ideas/implementation are not being regarded and are better you can always create another library that reflects your own ideas and notify people on this mailing list about your own library.

In this case, that's already been done. It's called google test (gtest).

I am confused, are you responding on behalf of Paul, or yourself Richard?

I always speak on behalf of myself.

All I'm saying is that gtest is gaining acceptance because it supports its community of users in a reasonable way. Boost.Test is losing ground and has been losing ground for 5+ years.

How often do you see anyone out there making a library that duplicates the functionality of a boost library? I haven't seen it happen very often and at the moment, the only example I can think of is Boost.Test. There are MULTIPLE test frameworks out there that are gaining users at the expense of Boost.Test.

The idea of "well, if you don't like what's happening, you should fork and go your own route" is not interesting to me, because if I'm going to abandon Boost.Test, I'll just use gtest. There's no need to reinvent my own test framework when there are other options out there.

My remark was a general one, and I am totally sympathetic to your viewpoint that Boost.Test has been badly neglected.

...

if your intentions are too take over Boost.Test ownership and make it more or less into gtest, possibly breaking compatibility with existing test code.

I offered to take over maintenance ownership of the library a while back (9 months ago? I don't remember exactly when) and the offer was declined. Had I been given that authority, then the docs and simple fixes waiting 5 years to appear in a release would already have shipped with 1.56 and we'd be moving on. Instead, we're still waiting for simple fixes to show up after 5 years of waiting. We're told that we'll have to keep waiting for simple fixes that were prepared 5 years ago to show up. With that sort of progress, I can't fault anyone for using google test.

This is strictly my opinion but if you had forked Boost.Test, fixed the bugs, offered your updated documentation, and submitted it as a new library and as an improved version of Boost.Test I would have voted for its inclusion into Boost. Occasionally some library, which is an improvement over an already accepted Boost library, is likewise accepted as a separate Boost library ( signals/signals2 ) and I personally see nothing wrong with this idea.

[Please do not mail me a copy of your followup] Rob Stewart spake the secret code <05FD3F39-E270-408C-9400-C9CDE77638E7@verizon.net> thusly:

Your patience may be exhausted, but attacks are not helpful and aren't appropriate for the Boost community. If you can't restrain yourself, it would be better if you don't post until you can.

Please quote the attacks in my posts, so I know specifically to what you refer. Then we can get on with some specifics instead of a general admonishment. -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

I've been reading this thread today and I've found it adding more amusement to the Boost.Test Saga (perhaps I should call it a soap opera instead, but I just flew on Icelandair and they call First Class, Saga Class, so I figure Saga is better in that light). Boost.Test hasn't released an update since 2012 and before that single change of a few lines, it hasn't seen an update since 2010. Anecdotally, last year, I became part of the Boost Community Maintenance Team and decided to spend some free time fixing issues in dynamic_bitset. I learned how to use trac, got setup and took patches from tickets, added tests and fixed them on both develop and master and got them into 1.56. And all while boost was going through the pain of migrating to git. And since then, I've had less free time, but it seems like dynamic_bitset has gotten some love from other kind folks with free time. I'd consider that a good example of how the CMT has helped boost improve over the last year or so. The amusement I alluded to above is mostly due to the fact that for the last five or more years, I'd consider Boost.Test to be the perfect example of how Boost's maintainer policy breaks down and as a result, provides a disservice to it's users. And I suppose it's only amusing to me since I have a perverse sense of humor and I get to watch it from the outside without much at stake. However, I imagine that while some people (like me) may think that this situation is amusing, there are probably lots of other people reporting bugs and seeing them not get fixed for years, even if they are small issues. So, if it is possible for someone like me to generate good will for both a library like dynamic_bitset and the CMT process all at the same time by resolving a few tickets, why is it that the potential good will towards users of Boost.Test is not worth the relatively small effort required to push at least a single, one line change? If there had been at least one change in the last few releases, I'd be significantly less amused, cause there would be progress. I for one am looking forward to at least one more year of amusement out of the Boost.Test Saga, cause if some users can't get their bug fixes in and the maintainer can't get replaced by someone more effective and if the library can't be maintained by the CMT, then at least I can laugh about the entire thing for another year.

From: rob.stewart@verizon.net Date: Wed, 21 Jan 2015 19:34:59 -0500 To: boost@lists.boost.org Subject: Re: [boost] [test] boost.test owner unresponsive to persistent problems for multiple years

On January 21, 2015 5:26:56 PM EST, legalize+jeeves@mail.xmission.com wrote:

...

That is exactly the sort of attitude that results in the really great book "Modern C++ Programming with Test-Driven Development" by Jeff Langr http://amzn.to/15bvh9C relegating Boost.Test to a bare mention in an appendix and using gtest throughout the book for all the examples.

Boost.Test is not leading mindshare.

That is unfortunate, but Boost.Test was, if I'm not much mistaken, originally for use by Boost libraries. That it has a wider user base is nice, but wasn't part of the original intent.

Sorry for the late reply, but I just started reading the thread. Anecdotally, I've noticed many boost maintainers say they do not use Boost.Test because of the same or similar reasons that external users don't want to use it. So, if your point was to suggest that the state of Boost.Test is ok because it has excellent mindshare with boost libraries, I'm not sure it's obvious.

On 21. jan. 2015 23:26, Richard wrote:

[Please do not mail me a copy of your followup]

=?windows-1252?Q?Bj=F8rn_Roald?= spake the secret code <54B0E109.8060307@4roald.org> thusly:

...

On 10. jan. 2015 02:06, Richard wrote:

...

[Please do not mail me a copy of your followup]

Edward Diener spake the secret code thusly:

...

On 1/8/2015 2:19 PM, Stephen Kelly wrote:

...

Paul A. Bristow wrote:

...

Things that effect *everyone* require consultation and some degree of consensus.

The maintainer is always the decider. Consensus, even loose consensus, doesn't affect Boost at all afaik. I realize you don't see it that way.

I approve the fact that a primary maintainer is the decider. Someone has to be in charge, and surely that someone who did all the work of creating the library in the first place is the best candidate. If you disagree enough with the primary maintainer and feel your ideas/implementation are not being regarded and are better you can always create another library that reflects your own ideas and notify people on this mailing list about your own library.

In this case, that's already been done. It's called google test (gtest).

I am confused, are you responding on behalf of Paul, or yourself Richard?

I always speak on behalf of myself.

Good, thanks.

The idea of "well, if you don't like what's happening, you should fork and go your own route" is not interesting to me, because if I'm going to abandon Boost.Test, I'll just use gtest. There's no need to reinvent my own test framework when there are other options out there.

Good, this is clarifying. What puzzles me then is why you can not work with Gennadiy more actively now as others seems to do, rather than iterating over this "If I was given control - it would have been fixed long time ago" argument.

...

if your intentions are too take over Boost.Test ownership and make it more or less into gtest, possibly breaking compatibility with existing test code.

I offered to take over maintenance ownership of the library a while back (9 months ago? I don't remember exactly when) and the offer was declined. Had I been given that authority, then the docs and simple fixes waiting 5 years to appear in a release would already have shipped with 1.56 and we'd be moving on. Instead, we're still waiting for simple fixes to show up after 5 years of waiting. We're told that we'll have to keep waiting for simple fixes that were prepared 5 years ago to show up. With that sort of progress, I can't fault anyone for using google test.

Very true.

That is exactly the sort of attitude that results in the really great book "Modern C++ Programming with Test-Driven Development" by Jeff Langr http://amzn.to/15bvh9C relegating Boost.Test to a bare mention in an appendix and using gtest throughout the book for all the examples.

Boost.Test is not leading mindshare.

With an attitude that 5 years of waiting for simple fixes is acceptable, why would anyone be surprised?

I don't really get too worried about success of alternatives to Boost.Test. I think it is wonderful that there are excellent alternatives out there as long as they don't kill all competition and we loose benefits of competition and alternatives again. So what we need now is for Boost.Test to wake up and come out from hibernation.

...

Thanks for your effort by the way Richard! I do however think you should moderate your tone, hidden or literate, in some of your postings given the maintainer seems to be responding now and have co-maintainers/helpers.

The time for laughing with puppy dogs and picking daisies in a sunny verdant field is long gone.

After waiting 5 years for the simple issue cited in this thread to be resolved I'm told that I have to keep waiting and to be patient. 5 years is long enough for anyone to wait. My patience has long since been exhausted.

There was, and is, all reasons in the world to poke the maintainer for the state of things. I don't blame you for having used sharper tools too stir up a reaction. But excessive use of sharp tools may just be too much, and hurt forward progress. Please do not underestimate the force and reach of your words. -- Bjørn

Robert Ramey wrote:

Stephen Kelly-2 wrote

...

Paul A. Bristow wrote:

...

a situation where a lone worker was solely controlling a key library used by almost all others.

Isn't that exactly how boost is designed to work?

I'm not sure how was boost was designed - or evolved ( I suppose it depends upon one's religion).

The most stark difference between Boost and KDE is that a KDE contributor can push to all KDE repositories. The same is not true of Boost, and it is designed that way. You write below it is a good thing. I don't agree. I think there's a better middle ground to arrive at. That is also a contributor to why there are so many unmaintained libraries in Boost. Far more libraries than are listed as the responsibility of the CMT are actually unmaintained in reality - the dead pull requests and desperate mails like http://thread.gmane.org/gmane.comp.lib.boost.devel/256063 http://thread.gmane.org/gmane.comp.lib.boost.devel/256571 show that. You might want to make a list of what is actually maintained instead and then decide if you want to do anything about that.

It promotes conceptual integrity and makes for smaller, decoupled libraries.

Decoupled? Erm, WAT? That is definitely, simply, not a true description of Boost for many many reasons. Check your illusions :).

One thing we do is that once a library is accepted, it shuts the door to anyone proposing alternatives.

There is definitely no consensus on this http://thread.gmane.org/gmane.comp.lib.boost.devel/255318/focus=255359 Another instance showing that there isn't generally cohesive opinion in Boost. Maybe another effect of the lone-wolf design.

If we had statistics on library usage, we could drop accepted libraries from the "standard" distribution when they fall out of favor.

There are so many strong opinions opposed to that, you'd have to form something of a community based on consensus before actually doing it. Thanks, Steve.

Stephen Kelly-2 wrote

The most stark difference between Boost and KDE is that a KDE contributor can push to all KDE repositories. The same is not true of Boost, and it is designed that way. You write below it is a good thing. I don't agree. I think there's a better middle ground to arrive at.

I DO believe that this is a good thing. The problem is that many are inclined to push changes that don't consider all the users. I have people suggest changes which would up the requirement for the serialization library to C++11 which would freeze out a lot of current users with no functional benefit. These "drive by" maintainers don't hang around for the consequences of their changes leaving the original author with the task of finding and fixing newly introduced bugs and problems. Just letting anyone check in changes would create a lot of work for current maintainers and discourage them from taking responsibility and pride in their work. The result would be a "dying" library which no one want's to take responsibility for.

That is also a contributor to why there are so many unmaintained libraries in Boost. Far more libraries than are listed as the responsibility of the CMT are actually unmaintained in reality - the dead pull requests and desperate mails like

http://thread.gmane.org/gmane.comp.lib.boost.devel/256063 http://thread.gmane.org/gmane.comp.lib.boost.devel/256571

I'm disputing there is a problem with orphaned libraries. But just letting anyone check in changes is not the solution. Transfering maintenance responsibility to another person is the only real solution

...

It promotes conceptual integrity and makes> for smaller, decoupled libraries.

Decoupled? Erm, WAT?

de-coupled from either. libraries which consist of better factored code rather than a kitchen sink of features.

That is definitely, simply, not a true description of Boost for many many reasons.

Check your illusions :).

...

One thing we do is that once a library is accepted, it shuts the door to anyone proposing alternatives.

There is definitely no consensus on this http://thread.gmane.org/gmane.comp.lib.boost.devel/255318/focus=255359

Well, it's been mostly true. We have limited library overlap. state chart/msm geometry/? also come to mind. But these are exceptions. Mostly we have functionality in only one library. I think we need to loosen up this a bit to promote better evolution.

Another instance showing that there isn't generally cohesive opinion in Boost. Maybe another effect of the lone-wolf design.

Boost does have, doesn't require and doesn't even encourage uniformity of opinion - that's its strength.

...

If we had statistics on library usage, we could drop accepted libraries from the "standard" distribution when they fall out of favor.

There are so many strong opinions opposed to that, you'd have to form something of a community based on consensus before actually doing it.

I'm working on that - it takes a lot of time and effort. But I firmly believe that we have move in this direction to keep from becoming obsolete. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/test-boost-test-owner-unresponsive-to-per... Sent from the Boost - Dev mailing list archive at Nabble.com.

On Thu, Jan 8, 2015 at 9:50 PM, Robert Ramey wrote:

...

http://thread.gmane.org/gmane.comp.lib.boost.devel/256063 http://thread.gmane.org/gmane.comp.lib.boost.devel/256571

I'm disputing there is a problem with orphaned libraries. But just

Are you or are you not? ;)

letting anyone check in changes is not the solution. Transfering maintenance responsibility to another person is the only real solution

I think having multiple maintainers is an even better solution.

Adam Wulkiewicz wrote:

Olaf Van Der Spek wrote:

...

On Thu, Jan 8, 2015 at 9:50 PM, Robert Ramey wrote:

...

...

http://thread.gmane.org/gmane.comp.lib.boost.devel/256063 http://thread.gmane.org/gmane.comp.lib.boost.devel/256571 I'm disputing there is a problem with orphaned libraries. But just Are you or are you not? ;)

...

letting anyone check in changes is not the solution. Transfering maintenance responsibility to another person is the only real solution I think having multiple maintainers is an even better solution.

Furthermore it wouldn't be a problem for the "community" to review pull requests if such additional maintainer needed some help. AFAIU the difference between Boost and many of the other open-source projects is that Boost is not one monolithic library/project but a group or container of libraries. Specific libraries has always been bound tightly with their authors. And with per-submodule access rights on GitHub this is even more noticeable.

This is my impression too. Well said.

We could think about relaxing this bound and go towards slightly more distributed model.

I'd like to see others' feedback on your ideas.

I'm guessing that those hanging pull requests and patches on trac discourages people from the "outside" to get involved in the evelution of a library, find and fix bugs, etc.

Not to mention that some of the code is unmaintainable in its current state, and needs some clean-up/modernization in order to become maintainable. The current way Boost seems to work is to prefer not to modernize in any way and choose the 'not changed means not (newly) broken' model. Thanks, Steve.

Olaf van der Spek-3 wrote

On Thu, Jan 8, 2015 at 9:50 PM, Robert Ramey <

ramey@

> wrote:

...

...

http://thread.gmane.org/gmane.comp.lib.boost.devel/256063 http://thread.gmane.org/gmane.comp.lib.boost.devel/256571

I'm disputing there is a problem with orphaned libraries. But just

Are you or are you not? ;)

LOL - I guess I'm NOT disputing a problem with orphaned libraries Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/test-boost-test-owner-unresponsive-to-per... Sent from the Boost - Dev mailing list archive at Nabble.com.

Paul A. Bristow wrote:

...

The most stark difference between Boost and KDE is that a KDE contributor can push to all KDE repositories.

Boost under SVN used to allow all library authors to update any library - but most people were too polite to do this much, and certainly not without consultation.

Yes, the same is true in KDE. However, culturally, KDE allows progress rather than waiting on an individual for a long time. Thanks, Steve.

Hmmm - I don't seem to get an email when someone makes a pull request. Personally, I've always liked the trac system since most of the stuff in github pull is super trivial. But I've no objection to using the github pull for extensive enhancements -- View this message in context: http://boost.2283326.n4.nabble.com/test-boost-test-owner-unresponsive-to-per... Sent from the Boost - Dev mailing list archive at Nabble.com.

On 2 Jan 2015 at 21:01, Richard wrote:

It's not fixed until it shows up in a released version of boost.

Five years is long enough to wait, any reasonable observer would conclude at this point that there is noone seriously working to fix anything in this library and they'll just use google test which releases fixes promptly.

As with anything open source, either you fork and make improvements yourself or you must accept the pace and quality of improvements by others, including acceptance of any code you donate for the maintainer to merge as and when they decide. For most usage of Boost.Test, it's relatively straightforward to emulate the Boost.Test macros with another test framework like CATCH or Google Test. Forthcoming BindLib provides a lightweight emulation of Boost.Test using CATCH and it works very well for my (limited) use extent of Boost.Test in my libraries. CATCH can output results Jenkins can consume just like Boost.Test as well. I've found it very useful for header only Boost usage, no Boost installation or compilation required. You might consider the effort of porting your libraries over to BindLib if you can make do without C++ 03, then Boost.Test becomes optional for you. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

________________________________________ From: Boost [boost-bounces@lists.boost.org] on behalf of Klaim - Joël Lamotte [mjklaim@gmail.com] Sent: 30 December 2014 10:32 To: Boost Developers List Subject: Re: [boost] [test] boost.test owner unresponsive to persistent problems for multiple years

You don't need to close the ticket to update it by: - stating in the comments that it is fixed in develop branch - changing the "milstone" to the next release version (as develop will be merged at some point)

It is common practice in tickets usage and help users (like me) what should be fixed when or not.

Regular releases of isolated features would be helpful too.

My understanding of how it works since Boost moved to git and submodules is this. (1) Maintainers can have write access to the particular library for which they have responsibility. This includes all the branches and in particular both develop and master. (2) It is up to the maintainer to put patches and tests onto develop and see whether there are any remaining problems. (3) It is then up to the maintainer to move the patches and tests from develop to master. This does not have to wait for a release of Boost. It can be done any time and at some point master will then become the next release. I do not think that develop is moved to master in any other way. It is the maintainer who will know when that is the correct action. I have been doing this as the maintainer of Boost Phoenix for nearly a year now, although I was not a developer of the library myself. I have been using this model adapting it as needed: http://nvie.com/posts/a-successful-git-branching-model/ What I usually do is that when I want to move things from develop to master I first branch from develop a new branch which I give a version number of my own within Phoenix. I can then test that before merging it into master. My experience has been that not all the tools and knowledge to be a maintainer are available in one place to a new maintainer. A lot of things which are well known to experienced maintainers are just not readily available. In some cases they are buried in the detailed manuals of several different tools. I am considering writing up my experience as a maintainer to help others. You are welcome to have a look at what I have been doing. I use gitg to inspect the git branches as it has better support for submodules than some alternative tools. If you think I have got something wrong please let me know. Best wishes John

René Eng writes:

That's great news. Then I look forward to the next release of Boost which will incorporate these changes and fixes, right?

This was my somewhat clumsy English. I meant to say fixes are being made in devel branch. Gennadiy