[MPlayer-dev-eng] Cleaning up incoming

[Attila Kinali]

On Sun, 20 Dec 2009 12:45:05 +0000 (UTC)
Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:

> Attila Kinali <attila <at> kinali.ch> writes:
> 
> > > Could you explain your requirements?
> > 
> > Currently, incoming is an 11GB mess of files of which noone knows
> 
> Sorry, but that does not explain your requirements:

Oops, sorry.
My requirement is, that the files should be sorted in a way
that anyone can find a sample according to some arbitrary criteria.
Currently all of them are in one directory. I have no clue whether
a file named XY.avi is actually an avi, whether it contains MPEG1 or
MPEG4 data, whether it triggers a bug in MPlayer or whether it
has some special properties that make it interesting.

Yes, i know that this is not possible with just sorting them into
directories, but it simplifies at least finding a file that
belongs to a certain broad category.

> Do you mean incoming should not exceed a certain size?

incoming becoming so large is only a symptom, not the cause.

> I think this is (and should be) unavoidable.

Why should it be unavoidable?

> Or is it only about sorting? That is simple for FFmpeg
> issues (roundup numbers), but what about issues on mplayer-users?

Sorting by FFmpeg issue number is one way. But some of these
files are interesting for other properties. I don't know 
we could store that information in a good ways.

> About "Are samples still needed?": For example, ffmpeg handles BR/TrueHD+AC3
> samples very well, but mplayer still has big problems; otoh, mplayer handles
> DVB/AAC well, while ffmpeg fails miserably (these are just the most obvious
> examples). So, I'm not sure how easy it is to decide if a sample is still
> needed. 

I'm mostly against deleting samples, unless it's the 1001st sample
with the same parameters.

> Deleting also makes regression testing much more difficult.
> Many samples are very easy to attach to an issue or a mail (Google, gmane).
> Others are worse, but they still might be useful.

Yes.

> > whether they are still needed for an open bugreport, whether
> > they belong to a PEBCAK bug and thus could be deleted, whether
> 
> The issue could be PEBCAK and the sample might still be interesting.

Yes, hence "could" and not "should"-
 
> > they are an important sample and should be retained, etc pp.
> 
> > I'm basically unqualified to sort these samples, as i'm out of
> > touch with development for years. Hence i've asked many times
> > that someone should take a look at those files and sort them
> > accordingly. Not much has happend and those who tried, have
> > been blocked by others with concerns that can be summed up
> > to "i cannot find my files anymore, if you move them"
> 
> I think this is a major concern (or possibly the only one).

Yes, it's a very important concern. But if we just keep
aknowledging this concern without actually doing something,
we'll end up with an unusable collection pretty soon.
Actually, our samples collection is well on the way there.
one forth(!) of our samples are in incoming, unsorted, untagged,
hard to find.


> > > I believe I understand Michael's requirements well, and personally, I think
> > > that all links mentioned on roundup (or the mailing lists) should be either
> > > kept or corrected on roundup/the mailing list.
> > 
> > That would mean that we would have to modify the mailinglist archives
> > and the roundup db. Both are not feasible.
> 
> If you were right, this would mean, we should not touch incoming (except for me
> asking people to upload 2GB samples...).
> But it is obviously trivial to correct file names on roundup (as compn did), and
> I think answers to old threads on the mailing list are also possible (at least
> gmane shows them nicely).

IMHO the best way would be if we had a bug tracking system that integrated
with our samples database. Ie if one could upload a sample to a bugreport
and the system would keep track of where it went, what basic properties
it has (container, codec,...) and what is special about it (triggering
bug XY, unusual way of encoding,...). But seein how well the effort
went to just create a db interface to our currently sorted samples,
i doubt that this is feasible.


> Could we agree on new rules (proposed by you, agreed by the developers) like "no
> sample in incoming stays there longer than two weeks" or "no sample bigger than
> 10M can stay longer than 10 days"

And who enforces them?

> or perhaps "nothing should be deleted without
> sending a message to the mailing list" before we start changing anything in
> incoming?
> I'd like to add that there are samples that correspond to valid issues that just
> have not been looked at by a capable developer.

That's another problem.
 
> Please let's try to find a solution that everybody agrees with, Carl Eugen

That's what i've been trying for well over a year. But but only two(!)
people ever reacted on my emails and tried to find a solution.


				Attila Kinali

-- 
Moslems sind hier nicht erwünscht!
		-- Das Schweizer Volk