[FFmpeg-devel] Samples Collection Reorganisation

[Ivo]

On Sunday 11 January 2009 17:47, Robert Swain wrote:
> 2009/1/11 Michael Niedermayer <michaelni at gmx.at>:
> > On Sun, Jan 11, 2009 at 03:21:25PM +0100, Ivo wrote:
> >> On Sunday 11 January 2009 01:18, Michael Niedermayer wrote:
> >> > On Fri, Jan 09, 2009 at 03:20:35PM +0100, Ivo wrote:
> >> > > A few minor additions:
> >> > >
> >> > > On Friday 09 January 2009 00:32, Ivo wrote:
> >> > > > * Files uploaded in 2006, 2007, 2008 and 2009 are in their
> >> > > > respective directories named after the year itself. Either the
> >> > > > one that's marked ready-for-archive or the other one if it's not
> >> > > > sorted out yet (i.e. a text file accompanying foo.avi has to be
> >> > > > called foo.txt, removing dupes, et cetera).
>
> I don't think the year during which a file was uploaded is a useful
> cataloguing technique in this situation.

Agreed. This is only temporarily. I want all the files sorted out first and 
then run my batch archiving/cataloguing script on them. That won't work if 
the files are all over the place and the accompanying textfiles don't have 
a matching basename minus extension. Basically, I'm just turning utter 
chaos into some order before the cataloguing step.

[..]
> >> > > * Uploaded binary codecs, specs, et cetera, are not in the year
> >> > > directories, but in non-av-files.
>
> I suppose this does no harm unless there are links on the web to the
> files in incoming.

That's not possible because incoming is not exported to the outside world, 
otherwise it would turn into a warez-depot.

[..]
> > Iam not bothered by some transitional period, iam bothered that finding
> > files has become much harder and iam not sure how this would be limited
> > to some period.
> > As long as users upload to incoming and you move files out from there
> > it will be much harder to find the file, this is not theory, it is
> > reality I have MUCH more difficulty finding files since the
> > reorganization, and iam not the only one... Sometimes i catch them in
> > incoming still, someimes they are in <year>/ and sometimes i cannot
> > find them anywhere at all.
> >
> > If you move each directory with all contents unchanged to all/ its
> > still 2 places to search, namely incoming and all. If you rename
> > anything or worse its much harder to find.
> > What is the problem with replacing files in incoming with symlinks to
> > their new resting place?

IMHO incoming will stay a mess that way, but if you really insist, I can do 
that for most files from 2008 and all of 2009. Older files will be somewhat 
problematic, because most of them are sorted out already and files before 
the 26th of april 2006 were copied (without -a) and moved around before me 
already.

> Maybe rather than just being critical of what is being done we should
> consider what the problem is/was and what would help to improve or
> resolve the situation.
>
> The problem(s):
> - The incoming dir contains a lot of files that are disorganised.
> - Files aren't too often moved out of incoming, so merely looking
> through the directory to find files which have unresolved or new
> issues is not simple.
>
> Considerations:
> - When reporting issues to the mailing lists and on roundup, people
> provide links to files or the directory and file name of the file they
> have uploaded.
> - Speed of finding files should not regress.
>
> I think if someone wishes to maintain incoming and the archive and
> look after it, to maximise how helpful their efforts are, how
> uploading files relates to bug reporting needs to be considered.
>
> Thoughts:
> - Files must not be renamed, such that if a file is uploaded and
> referenced, it can be found.
> - Is there an easy way to discover if a file is being linked to by one
> of our web pages or some other web page whom we don't mind linking?
> (We may be happy with videolan, xine, mplayer, ffmpeg and others
> linking to our files...)
>   - Files linked to in incoming either must not be moved or must have
> their links updated so that referring articles can continue to access
> them readily.
> - It is useful to know whether the issue presented by a file has been,
> cannot be or has not been resolved.
>   - It should be safer to move those files whose issues have been
> resolved. - It is useful to have easy access to files that present issues
> that have not been resolved.
> - Fields of interest for archived files
>   - In what area did the issue present? Container? Audio codec? Video
> codec? Something else?
>   - Within those sections, what container/codec was used?
> - All developers should have access to and be aware of how to access
> both the samples archive and problematic files.
> - All users should at least have access to the samples archive. I
> understand the reason for not allowing users to both upload and
> download to/from the incoming dir.
> - It would be useful for files pertaining to issues in bug trackers to
> be easily accessible via some cataloguing method.
>
> Maybe with a little constructive discussion we can come up with some
> good way of managing all this.

I think you missed the previous threads:

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-October/055103.html
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-November/055599.html

--Ivo