[FFmpeg-devel] Please clean up incoming

[The Wanderer]

Aurelien Jacobs wrote:

> Robert Swain wrote:
> 
>> 2008/10/22 The Wanderer <inverseparadox at comcast.net>:

>>> Prompted by compn, I took a stab at starting to test and
>>> potentially organize incoming/ at one point, but ran up against
>>> this basic question: in an ideal world where everything were
>>> organized correctly, how *would* it be organized?
>>> 
>>> The "everything goes under its bugtracker issue directory" is the
>>> only proposition I've seen so far, and it has its downsides - the
>>> first one which springs to mind being that not everything is
>>> associated with a specific tracker issue (if nothing else, some
>>> things should be kept in permanent "sample of this type of file"
>>> storage).
>>> 
>>> I don't know how the samples archive should theoretically be
>>> organized. I don't know how the non-samples files (present only
>>> because they demonstrate an unfixed bug) should be organized. I
>>> don't know whether or not there are potentially any files which
>>> fall into neither category but should be kept anyway, much less
>>> how they should be organized.
>>> 
>>> If answers to these organization questions can be arrived at, I
>>> can spend some of my time on testing incoming/ and pointing to
>>> where specific files should go. Without that, there's not much I
>>> can do but to list whether or not a specific problem seems to
>>> still exist.
>> 
>> Where does one put a file considering each file potentially has:
>> 
>> - a container
>> - a number of audio/video streams using various codecs
>> - other features that may be of interest in a sample (metadata?
>> probably a plethora of other things...)
>> 
>> ?
> 
> One simple obvious suggestion.
> Have the following directory tree:
> 
>   all
>   containers
>     avi
>     nut
>     mkv
>   audio
>     pcm
>     mp3
>     aac
>   video
>     theora
>     vp6
>     h264
>   subtitle
>     dvd
>     ass
>   issues
>     issue510
>     issue511
> 
> Then put *all* the actual samples unsorted in the 'all' directory,
> and add symlinks in other relevant sub-directories pointing to the
> actual sample. More directories/categories can be added at will when
> the need arise.

That doesn't sound like a bad idea to me, though there might be
potentially better ones at some point. It has the downside that it
doesn't (directly) address the "do we need to keep this file?" question,
but that ought to be simple enough to handle by one-at-a-time review,
and then periodically go through the symlink directories and remove any
dead symlinks.

Under this scheme, what would we do about files which correspond to bug
reports and/or unfixed bugs but which have no matching bugtracker issue
(either because people were lazy or because the report was filed before
there was a functioning bug tracker)? Such files certainly exist - at
least a few, and possibly most, of the files I checked before running up
against these questions were in that category.

> It might be a little painful to setup but it could be partly 
> automatized using ffmpeg -i on the actual samples to detect their 
> container/codecs and to generate the symlinks.

Problem: many of the files in incoming/ have accompanying text files
describing what the problem with them is (every bug report should have
such a file, and some non-bug-report files need explanations of what
they're for as well), and these would need to be available in at least
the issues/ directories along with their 'partner's. That can't so
easily be automated the way you describe, I don't think.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.