[FFmpeg-devel] Please clean up incoming

[The Wanderer]

Aurelien Jacobs wrote:

> The Wanderer wrote:
> 
>> Aurelien Jacobs wrote:

>> 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,
> 
> Could you list any valid reason why we wouldn't want to keep a file ?

Because it was only useful as a way of tracking down a bug which has
since been fixed, and there's no value in keeping it around? Or because
it was uploaded as part of an invalid bug report (i.e. one for something
which isn't actually a bug, or for a bug which had already been fixed in
a version later than the submitter was using)?

Organizing files worth keeping is only one side of any incoming/ cleanup
(in MPlayer or anything else). Identifying which files *are* worth
keeping and thus need organizing, rather than being useless and just
taking up space which could be used for other things.

> The only one I can think about are:
>  - The file never was categorized (left in incoming for more than x
>    days)

That just means we need to categorize it, that's all.

>  - The file is bigger than xMB and we can't afford keeping such huge
>    file (only when free disk space goes under yMB)

That's quite valid, of course.

> In all other situations the files should be kept. They can be useful
> for purpose that we will discover later.

Most files I'd agree about, even possibly most demonstrates-a-bug files,
but there are certainly some which I would say are completely non-useful
and/or unnecessary once the bug is fixed and no longer needs to be
testable.

>>> 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.
> 
> 2 different simple solutions:
>  - put each sample in its own sub-directory in 'all', along with its
>    text file

Cumbersome, but effective.

>  - enforce text file naming (same name as the sample with .txt
>    appended)

This is supposed to already be the case, though there's no code in place
to ensure it as far as I know (and I'm not sure I'd want there to be).

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