Re: Split out kupfer plugins to a separate repository



2010/2/16 Marco Asa <aesir ml gmail com>:
> Il giorno Tue, 16 Feb 2010 00:59:26 +0100
> Ulrik Sverdrup <ulrik sverdrup gmail com> ha scritto:
>
>> Hi,
>>
>> I think we should consider the possibility of separating core kupfer
>> from the growing mass of plugins.
>>
>> Core kupfer would take most of the now-default plugins and not so much
>> more, and many of the large other plugins go into a community package.
>>
>> Technically, it would be separate git repositories and separate
>> tarballs, and separate localization work. Localization will be
>> relatively easy since we still have all the "community" plugins
>> collected in one place.
>>
>> For the developers it could mean that we make a maintenence team for
>> the community plugins package, which should make it easier for more
>> people to work on the plugins. I can continue to maintain the core
>> kupfer, as well as being part of community maintenence team (if
>> wanted).
>>
>> For some users, they have to install two tarballs or two distribution
>> packages instead of one, but if you use a package from a repository it
>> is not going to be a big difference. The users that only want some
>> basic functionality can have that if they skip installing community
>> plugins.
>>
>> What do you think?
>>
>> Ulrik
>> _______________________________________________
>> kupfer-list mailing list
>> kupfer-list gnome org
>> http://mail.gnome.org/mailman/listinfo/kupfer-list
>
> It is exactly what I was about to propose for this project; a lot of
> utilities that are plugin-based use the suggested approach.
> Since I'm not a programmer I don't know if there are drawbacks with it,
> but, in every project that comes to my mind, plugins are on their
> own in the development tree. In the same way lesser commonly used
> plugins could be packaged separately in "kupfer-extra-plugins" (TM) :-)

However most distributions can split one source package into many
installable packages if they want, so that's  separate thing.

I want to split out plugins so that they are more independently
developed, and so that people contribute to them. Then we also have to
solve some problems that are interesting anyway, like how 3rd party
plugins should provide translations (it is not so hard).

Ulrik


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]