Okay, from both Bryce's and Bulia's e-mail I don't think that I was entirely clear. I was only thinking about extensions that are distributed from inkscpae.org, I could definitely see others providing extension packages or collections of their own. (I expect KPT to start shipping Inkscape extensions any time now)

I understand Bulia's argument of this being a little too early, I think that if we take that approach we should definitely decided when is mature enough. Release 0.43? When there are 100 extensions? Though, I could definitely see waiting until we have more.

So, I guess that's the approach that I'm going to suggest, put everything we have in the Inkscape package today, and we'll split them out at a prespecified time.

--Ted

On Wed, 2005-04-20 at 14:59 -0300, bulia byak wrote:

(Note that gmail is currently spamblocked by sf lists, so this message likely won't make it to the list, but Ted and Bryce will see it)

On 4/20/05, Ted Gould <ted@...11...> wrote:

...

We've talked about before, and Aaron and I have recently talked about it, should we package extensions? I'd like put some ideas and questions forward so that people can rip them apart and we'll end up with something good :)

I'm strongly of the opinion that we must include the extensions we have so far into Inkscape. Maybe later when there are too many of them, or when there are some complex or large ones, we may consider breaking them out. Right now they are just starting to appear, so including them with the program itself is the only way we can let them survive. Separating them would pretty much kill them, as few people will bother downloading them separately.

...

-- Dependencies. The dependency checking in Inkscape will always be a toy when compared to dpkg and rpm. And, we don't want to require every package in Debian just to install Inkscape.

This is all irrelevant on Windows which has no dependency checking at all. It's already difficult to make them work on Windows, by separating them we'll pretty much make this impossible for an average user.

...

-- Versioning. It might be more reasonable to have effects on a different release schedule if there were a larger collection of authors. Something more like OpenClipart's monthly release.

Few people care about versioning. Most just use whatever version came with the program. If nothing came with it, well, they will use nothing. If they DO care, they can always download the freshest version of the extension they are interested in.

...

-- Modularity. If we ever expect for people to be able to ship extensions for Inkscape from outside the project umbrella the tools to do so need to be good, and packing some of our own extensions externally would force use to make them reasonable.

It's possible to make these tools good without this. And, as I said, _right now_ extensions are just too weak and immature to let them go on their own.

...

-- Simple. Releases are a pain, more releases need to be justified.

A very important reason - simplicity _for the user_ is a priority.

...

-- Complete Solution. Have you ever seen a public forum where someone posts a new program, and then 90% of the questions are "What theme did you use in the screenshots?" Multiple places to get extensions means that everyone won't have the same set.

Yes.

Another reason to package extensions is the Effects menu. If there are no extensions in the default package, it will either be empty or will have to be disabled. Both options are bad.

So as a very minimum, I think we must ship everything we have in the Windows package (also with Python). But I think the same reasoning applies to all platforms.