On Sat, 19 Jun 2004, bulia byak wrote:

...

By the way, Alan has produced a collection of stock gradients, that we're going to try to package as part of openclipart (as opposed to bulking up the Inkscape tarball.) These will get installed to a directory somewhere in the /usr/share/. Is it possible to inform Inkscape of the location and identity of these gradients?

Yes but not in a short term. The plan is:

• switch marker menus to a new table-like widget that is updated on the fly

and more responsive

• add the same widget and the ability to use stock items to patterns,

gradients, symbols etc.

Okay. Will this eventual capability be able to recursively read a tree? Alan has divided his gradients up into categorized subdirectories. If it will not be able to read recursively, would some form of an index file need to be generated for it?

...

I spent some time testing it and playing with it. It works very well when compared with the usual RPM issues of finding/downloading various dependencies. I think it will help us a lot, especially given the new dependencies we've introduced recently, since it takes care of that for the user fairly seemlessly.

Good, then could you please publish a short version of my plea for help with Pango testing on the site, adding a link to the daily autopackage.

I'll put together an item for the news page tomorrow on this (just now heading out to Dad's for the day).

...

An issue is that we can publish a beta release for testing, get lots of testing input, but meanwhile developers will be adding bug fixes or even new code to the release branch. Ideally, betatesters would update frequently and re-test, but realistically I think we'll get at most one or two cycles of testing out of people.

Branching out a separate beta branch before the release is something we'll definitely need to do for 1.0, but for 0.39 it's perhaps more trouble than it's worth. It only makes sense for really long testing periods.

Actually, we always make a release branch (see the release docs), and it actually is not that much trouble to create (just an extra flag more than doing a cvs tag). Typically we have not needed to do much in this branch, though, so the value may not be high.

But what I think we can and should do is to allow several days of testing of a final release candidate with TOTAL freeze on CVS, and requiring a certain nunder of people to OK it before it is released.

Sounds good. When the time comes to make the total freeze, do you want me to restrict down CVS commit access to the change control person for the last few days, or just trust that nobody will commit without authorization?

Bryce