[MPlayer-dev-eng] Cleaning up incoming

[Erik Auerswald]

Hi,

a view from the outside:

On Sun, Dec 20, 2009 at 05:07:02PM +0200, Uoti Urpala wrote:
> On Sun, 2009-12-20 at 15:11 +0100, Reimar Döffinger wrote:
> > On Sun, Dec 20, 2009 at 02:38:43PM +0200, Uoti Urpala wrote:
> > > 
> > > I'm against that. Making the partition smaller to intentionally cause
> > > out-of-space problems is just that - intentionally and unnecessarily
> > > causing problems where none existed before.
> > 
> > No, it solves the problems of people leaving (possibly important) samples
> > in incoming until nobody knows anymore what they were there for and why.
> 
> You're claiming it would "solve" the problems, but the only thing it'd
> directly do is cause _much worse_ problems.
>
> Ability to upload new samples is much higher priority than keeping
> years-old samples, so endangering the former for the sake of the latter
> is a bad idea.

IMHO this is correct. While it would be nice to keep a history, it is
obviously not feasible to keep _every_ sample. Thus removing the oldest
samples (that obviously were not important enough to sort into a
permanent directory) from incoming is the simplest solution for the
space problem.

> You're obviously hoping that incoming running out of space would
> motivate people to sort the samples.

In my personal experience such attempts always fail. I can only strongly
discourage you from trying this out.

> [...snip...]
> Second, even if it did make someone work on sorting samples, you'd
> have to justify why this was a good thing. A sorted samples collection
> would no doubt be beneficial, but is it _the_ most important thing that
> someone could work on?

This totally misses the point. Sorting the samples is an important task
that should be encouraged. If someone wants to go ahead and do it, then
this is great.

> [...snip...]
> To me this looks like a case of a fairly common fallacy: after you
> recognize a flaw in something it bothers you and you feel you have to
> somehow fix it, failing to recognize that equivalent effort would bring
> greater benefits elsewhere.

Uoti, here you have stepped into a common trap: Just because someone
would like to fix a problem, you have no reason at all to expect him to
fix a different problem instead. This is even more true in open-source
projects.

Erik
-- 
When in doubt, use brute force.
                        -- Ken Thompson