On December 30, 2014 4:23:38 AM EST, Tim Blechmann
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.
I agree that "fixed" must be reserved for when the issue hits a Boost release. A "code complete" or "fixed in develop" state would be useful for the developer. In the meantime, Tim's point about there being no comment on issues that are years old which you say have been fixed, via a blanket statement on the _developer's_ list, is not helpful for anyone but those that happened to read that message. Please add comments to each ticket noting that it has been fixed and what currently precludes its inclusion in a release. That will give users a better idea of the status of the work and help them to understand that the library is progressing, however slowly WRT a release. ___ Rob (Sent from my portable computation engine)