[FFmpeg-devel] [PATCH 1/3] doc: issue tracking: fix grammar/spelling

Alexander Strasser eclipse7 at gmx.net
Wed Aug 31 19:22:08 CEST 2011


Hi

Michael Niedermayer wrote:
> On Wed, Aug 31, 2011 at 08:46:53AM +0000, Carl Eugen Hoyos wrote:
> > Alexander Strasser <eclipse7 <at> gmx.net> writes:
> > 
> > >      Regressions also should be marked as important, regressions are bugs that
> > > -    dont exist in a past revission or another branch.
> > > +    don't exist in a past revision or another branch.
> > 
> > The former ministry would have requested "do not".

  I _don't_ care :)

  If a developer cares more than me, he is free to change it. I for sure
won't start a commit war :D

> > > -needs_more_info substate.
> > > +needs_more_info substatus.
> > 
> > Unfortunately, both "needs_more_info" and substati do not exist any more...
> 
> needs_more_info is a resolution now, so you can close a ticket and set it
> to needs_more_info
> the reporter can reopen it when he provides the requested info

  Thanks for the information. I was going to look at the current
trac situation more closely but it was already late at night.

> The idea behind was that open tickets are the ones that need
> developer action while closed ones dont

  I like that and think it should stay that way if possible. It is
simple to explain to developers to look at open tickets. Also I think
it is more encouraging for issue submitters to reopen a closed issue
instead of adding more information to a still opened one.

> analyzed & reproduced substati are independant switches now
> a ticket really can have either, none or both
> also a ticket can reach fixed state without ever having been reproduced
> by a developer

  OK

> Speaking of that, i think the 2 flags could be renamed to
> Analyzed by developer and Reproduced by developer
> anyone against? other ideas?

  To avoid the ambiguity between analyzed/reproduced by developer
vs reporter?

  Anyway I would like to commit this patch series as is. IMHO it
still is an improvement. I will try to continue working on that
document to better reflect current practice afterwards.

  Alexander


More information about the ffmpeg-devel mailing list