________________________________________ 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