Re: [boost] [test] boost.test owner unresponsive to persistent problems for multiple years

Subject: Re: [boost] [test] boost.test owner unresponsive to persistent problems for multiple years
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2014-12-30 05:18:12

On December 30, 2014 4:23:38 AM EST, Tim Blechmann <tim_at_[hidden]> wrote:
> >> 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)