[Clipart] Change needed for how openclipart is managed

[Christian Fredrik Kalager Schaller]

On Tue, 2005-03-22 at 15:24 -0500, Nathan Eady wrote:
<SNIP>

> Executive summary:
> I agree in principle that we need a repository tool to help us manage
> the collection better -- but I don't think a source-code-oriented
> version-control system like CVS is the tool we need.
> 
> > So why can't we put the clipart collection into CVS or Subversion
> 
> CVS and Subversion don't have the repository features we need.  They
> don't support the metadata we need, among other things.  Fundamentally,
> they were designed for source code, and what we're managing isn't
> source code.  We do use CVS for managing the website and tools, but
> it would not, in my estimation, work well for the collection.
In my opinion there isnt much of a difference between a XML SVG file and
a C file for instance. Our images are not binary blobs, but files with
plaintext source, like code.

> Bryce is working on a document repository system to address this need,
> but it is not ready for use yet, as far as I am aware.
> 
> > build both the release tarball and the website from CVS. If if knew I
> > could update a CVS module by moving/removing/updating images and then do
> > 'make www' to update the website it would be so much quicker for get the
> > clipart fixed. Same for the tarball, wouldn't it make releases quicker
> > if it was just 'make dist'?
> 
> In a word, no, it wouldn't.
> 
> Sure, typing "make dist" is easy, but who wants to maintain the makefile
> that handles our release process?  I'm not even sure that's possible
> (there's quite a bit of human common sense involved, e.g., for
> zipfiles and tarballs deciding whether their metadata.rdf should be
> propagated to all their contents, or whether the extant metadata in
> the included files is better as it stands), and I'm certain it would
> be more work than what we're doing now, and it would not address the
> needs that the document repository will.  Let me just repeat that what
> we are managing is not source code, and the kinds of things we need to
> do are fundamentally dissimilar from the kinds of things you need to do
> with source code.
I am not sure I understand what you are saying here. All our metadata is included in the 
XML source of the SVG images right? After checking out CVS I guess we
should have some kind of script that runs svg_validate to create txt and
png files and then creates the distributable tarballs and zip files.


>  > If we use CVS we could collaborate much better
> 
> I am not convinced of this.
> 
>  > instead of sending lots of mails and upload lots of tarballs and
> > crossing the fingers that the next release will work perfectly. I mean
> > it frustrates me to no end that I have been trying to get the flag
> > collection correct and included for what must be 4-5 months no and we
> > still are not there yet.
> 
> I understand this frustration, but I don't think CVS will solve it.
> Among other things, I'm not sure how the .txt files got lost in the
> first place, but I doubt very much if zip or tar caused this.
I did not imply that it was the 'fault' of zip or tar, my complaint is
that the current system, where I put together a file, send it to the
list or upload it somewhere for someone who do not know exactly what I
did or why, there is a good chance that both me and the person on the
other end makes some wrong assumptions and the update breaks down. Which
I think is what happened in this case.

> There are things a document repository can do for us, that our current
> system does not do, but CVS would not do them either.  For instance,
> any arbitrary author needs to be able to update their own contributions,
> but we cannot require all the artists to have CVS installed on their
> workstations, have CVS acounts on the freedesktop.org server or, for
> that matter, know what CVS is.
Getting a system long term which lets artists maintain their own artwork
might be fine. But such a system is probably quite hard to create in the
sense that there are a lot of considerations that need to be taken into
account. Short term using CVS instead of the current manual setup could
at least make more of us able to work efficiently as people like myself
could accomplish my goal without being dependent on others.


> Worse, CVS is not metadata-aware at *all*, so in some respects it
> would be an actual step backwards for us.
I am guessing I am missing something as you mentioned the metadata issue above too,
please explain.

> I'm also not convinced it scales well enough.  Our release tarballs
> are *already* larger than the Mozilla.org codebase (and are growing
> much more quickly), and the last time I tried to check out the
> Mozilla.org codebase via anonymous CVS, I found it to be utterly
> and completely impossible over a dialup connection with a dynamic IP.
Our release tarballs contain a tons of png files for instance. Also
having the SVG files in a system like CVS will enable us to clean up
stuff as more people can clean. I wouldnt be suprised for instance if
many of our SVG files have huge binary blobs inside put there by Adobe
Illustrator. I had to manually remove these blobs from icons in gnome-
themes-extras.

Christian