[Clipart] Change needed for how openclipart is managed

Wed Mar 23 23:47:02 PST 2005

On Wed, 2005-03-23 at 18:02 +0100, Christian Fredrik Kalager Schaller
wrote:
> 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.

Right, well, we have not really considered this as interfaces to CVS are
not that great. It would be better for us to put work into Bryce's
Document Management System (DMS). Unfortunately, we have all been so
tied up with other work and jobs that it has been hard to do. I could do
some serious damage to it if I could have like a solid 3-4 day weekend
of work hacking on it -- unfortunately the project I'm working on,
gopetslive.com is going beta APRIL 1....sooo...I'm kinda swamped till
after then (and I need the money).

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

Well, DMS is a general document management system that stores metadata
exteranal from the document. SVG is diff. in  that it allows metadata
internally. We want to support some other formats that will require
metadata to be stored externally. Also, by storing a files metadata
independent, it will allow other manipulations. I'm not the most fluent
in the reasonings, but they are good. ;)

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

Yes, you are right. There is so much cleaning that needs to happen and
we right now are getting primarily first wave clip art. We really need
to do cleaning, but this all waits on an easy way to do this.

If you are serious about this, then we need to really push getting DMS
ready for the primetime:
http://openclipart.org/cgi-bin/wiki.pl?DocumentManagementSystem

I don't think CVS is a good option anymore for the reasons stated, but I
do think we need to start connecting our process with DMS.

Christian, I'm sorry that you are frustrated with the process. I really
want to streamline this out because the flags are important for us. I
will set aside 2-3 solid days after the 1st to work on getting DMS
integrated. I really want to see this happen, as so much is waiting on
this advanced infrastructure. 

Christian, might you have any other good suggestions?

Jon

-- 
Jon Phillips

USA PH 510.499.0894
jon at rejon.org
http://www.rejon.org

Inkscape (http://inkscape.org)
Open Clip Art Library (www.openclipart.org)
CVS Book (http://cvsbook.ucsd.edu)
Scale Journal (http://scale.ucsd.edu)