[Clipart] Change needed for how openclipart is managed

[Nathan Eady]

Christian Fredrik Kalager Schaller wrote:
> Hi guys,
> So with some help from Bryce yesterday I looked a bit into why most of
> the flags doesn't have metadata displayed on the website. I turned out
> to be due to missing .txt files for most flags. So I downloaded the
> latest tarball and generated the metadata anew from it. I discovered
> that there where are still some flags not passing svg_validate. 
> I don't understand how that could be as I am pretty sure I got
> everything to validate, but maybe I managed to leave some screwed up.

Yes, this is related to the way we dropped your replacement flags
hierarchy into the release as it stood, instead of running it through
the usual process.  Theoretically, your flags hierarchy was based on
images that had already been through the usual process once, or such
was my understanding.

> Anyway trying to fix this I felt once again a bit frustrated with the
> way the package is developed. Fixing these issues by making new tarballs
> and emails is rather unproductive and slow.

It is an interim solution.  However...

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.

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.

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

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.

Worse, CVS is not metadata-aware at *all*, so in some respects it
would be an actual step backwards for us.

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.