[FFmpeg-cvslog] r9415 - trunk/doc/issue_tracker.txt
Mon Jun 25 11:18:45 CEST 2007
> Author: michael
> Date: Sun Jun 24 23:01:30 2007
> New Revision: 9415
> ffmpegs bug/patch/feature request tracker manual
> Added: trunk/doc/issue_tracker.txt
> --- (empty file)
> +++ trunk/doc/issue_tracker.txt Sun Jun 24 23:01:30 2007
> @@ -0,0 +1,156 @@
> +ffmpegs bug/patch/feature request tracker manual
> +NOTE, this is a draft, its not yet recommanded to send real bugrepors to the
> +tracker but rather use the mailinglists
> +though if you are brave and dont mind that your bugreport might disapear or
> +that you might be mailbombed due to a missconiguration you can surely try
> +to enter a real bugreport
> +FFmpeg uses roundup for tracking issues, new issues and changes to
> +existing issues can be done through a web interface and through email.
> +Its possible to subscribe to individual issues by adding yourself to the
> +nosy list or to subscribe to the ffmpeg_issues mailinglist which receives
ffmpeg-issues -> the mailing list
ffmpeg_issues -> the roundup mail
Maybe I should use tracker for one of those two...
Something that is desiderable to have but that there is no urgency at
all to fix/implement/add, e.g.: something completely cosmetic like the
website restyle or a personalized doxy template or the ffmpeg logo
proposals. this priority isn't valid for bugs.
> + initial state
> + intermediate states
> + Final state
> + Initial state of new bugs, patches and feature requests submitted by
> + users
> + Issues which have been briefly looked at and which didnt look outright
> + invalid
> + This implicates that no real more detailed state applies yet. And the
> + more detailed states below implicate that the issue has been briefly
> + looked at.
> + Bugs, patches or feature requests which are duplicate of some other.
> + Note patches dealing with the same thing but differently are not duplicate.
> + Bugs caused by user errors, random ineligible or otherwise nonsense stuff
> + Bugs which have been reproduced
> + Bugs which have been analyzed and where it is understood what causes them
> + and which exact chain of events triggers them. This analyzis should be
> + available as a message in the bugreport
> + Note, do not change the status to analyzed without also providing a clear
> + and understandable analysis.
> + This state implicates that the bug either has been reproduced or that
> + reproduction is not needed as the bug is understood already anyway.
> + Bugreports which are incomplete and or where more information is needed
> + from the submitter or another person who can provide the info.
> + This state implicates that the bug has not been analyzed or reproduced
> + Bugs which have to the best of our knowledge been fixed.
> + Bugs which we will not fix, the reasons here could be legal, philosophical
> + or others
> + Bugs for which sufficient information was provided to reproduce but
> + reproduction failed that is the code seems to work correctly to the
> + best of our knowledgde.
> + Patches which have been reviewed and approved by a developer.
> + Such patches can be applied anytime by any other developer after some
> + reasonable testing (compile + regression tests + does the patch do
> + what the author claimed)
> + Patches which have been reviewed and need changes to be accepted
> + Patches which have been applied
> + Patches which have been rejected
> + Feature requests where its not clear what exactly is wanted
> + (these also could be closed as invalid ...)
> + Feature requests which have been implemented.
> + Feature reuests which will not be implemented. The reasons here could
> + be legal, philosophical or others.
> +Note, please do not use type-status-substatus combinations other than the
> +above without asking on ffmpeg-dev first!
I'll try to write a reactor to error out if the combination doesn't make
More information about the ffmpeg-cvslog