[FFmpeg-cvslog] r9415 - trunk/doc/issue_tracker.txt

[Michael Niedermayer]

Hi

On Mon, Jun 25, 2007 at 11:18:45AM +0200, Luca Barbato wrote:
> michael wrote:
> > Author: michael
> > Date: Sun Jun 24 23:01:30 2007
> > New Revision: 9415
> > 
> > Log:
> > ffmpegs bug/patch/feature request tracker manual
> > 
> > 
> > Added:
> >    trunk/doc/issue_tracker.txt
> > 
> > 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
> > +
> > +Overview:
> > +---------
> > +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

use `svn ci` instead of telling me :)


> 
> Maybe I should use tracker for one of those two...

maybe ...


> 
> > +wish
> 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.

agree, commit


> 
> 
> > +Status:
> > +-------
> > +new
> > +    initial state
> > +
> > +open
> > +    intermediate states
> > +
> > +closed
> > +    Final state
> > +
> > +
> > +Type/Status/Substatus:
> > +----------
> > +*/new/new
> > +    Initial state of new bugs, patches and feature requests submitted by
> > +    users
> > +
> > +*/open/open
> > +    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.
> > +
> > +*/closed/duplicate
> > +    Bugs, patches or feature requests which are duplicate of some other.
> > +    Note patches dealing with the same thing but differently are not duplicate.
> > +
> > +*/closed/invalid
> > +    Bugs caused by user errors, random ineligible or otherwise nonsense stuff
> > +
> > +bug/open/reproduced
> > +    Bugs which have been reproduced
> > +
> > +bug/open/analyzed
> > +    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.
> > +
> > +bug/open/needs_more_info
> > +    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
> > +
> > +bug/closed/fixed
> > +    Bugs which have to the best of our knowledge been fixed.
> > +
> > +bug/closed/wont_fix
> > +    Bugs which we will not fix, the reasons here could be legal, philosophical
> > +    or others
> > +
> > +bug/closed/works_for_me
> > +    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.
> > +
> > +patch/open/approved
> > +    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)
> > +
> > +patch/open/needs_changes
> > +    Patches which have been reviewed and need changes to be accepted
> > +
> > +patch/closed/applied
> > +    Patches which have been applied
> > +
> > +patch/closed/rejected
> > +    Patches which have been rejected
> > +
> > +feature_request/open/needs_more_info
> > +    Feature requests where its not clear what exactly is wanted
> > +    (these also could be closed as invalid ...)
> > +
> > +feature_request/closed/implemented
> > +    Feature requests which have been implemented.
> > +
> > +feature_request/closed/wont_implement
> > +    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
> sense...

thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20070625/1f878f4b/attachment.pgp>