[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Google Online document Plugin for KOffice
From:       "Dr. Robert Marmorstein" <robert () narnia ! homeunix ! com>
Date:       2010-07-05 7:38:18
Message-ID: 201007050338.19494.robert () narnia ! homeunix ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


> > I'd much prefer not to split the community at all. It's not as if the
> > KOffice  community is too big -- we need to be open and welcoming to
> > everyone. If there is one thing I have learned from the great
> > community-related presentations this year at akademy it's that dividing
> > the community between "core" and "not- yet-core" developers is a sure way
> > to lose the second category

Okay.  Having read through this a little bit more, here's a few thoughts from 
a "plugin-developer's perspective".  

1.  I personally don't feel insulted by being grouped as a "not-yet-core" 
developer.  Being treated as a "not-yet-core" developer means that there is 
less of an expectation for me to understand the internals of koffice and 
participate in policy discussions on this list (which have been VERY heated 
recently....).  Those of you who ARE core developers have been very courteous 
to me and I really appreciate the time many of you have taken to explain 
things that probably seemed obvious to you.  It may be that others feel 
differently.  Perhaps Mani could speak to that?  

2.  I welcome the opportunity to have other developers review my code and make 
suggestions about code quality, interface consistency, and so forth (as well 
as getting features working right).  Several of you have already been quite 
helpful in helping me with the publish-to plugin.  I think having a staging 
area like the one we are discussing (on git.kde.org) might make it much easier 
to talk about these kinds of changes.

3.  At the same time, I would like to maintain control of my own code.  I 
can't imagine anything more frustrating than to have spent lots of time 
developing a plugin and then find that I can no longer distribute it because of 
some political decision by the rest of the community.  However, one of the 
nice things about git is that it is easy to keep a local copy that the 
developer maintains control over -- forking/branching is cheap.  As long as 
developers can release "unofficial versions" of their plugins, this shouldn't be 
an issue.

4.  Several other projects have "official" plugin packages (Thomas mentioned 
plasma, but Digikam also has the "kipi-plugins" and I think there are several 
others). I think it is perfectly reasonable to set community standards about 
what it takes for a plugin to be "blessed" as an official plugin.  Maintaining 
packages in a staging area and periodically packaging them up as "official 
plugin packages" also makes it easier for distribution maintainers to figure 
out which versions of the various plugins are compatible with the API of a 
particular koffice release.  

5.  Reviewboard stinks.

It's not THAT horrible, but the interface is awkward, buggy, and confusing.  
It also doesn't play very nicely with Konqueror (did posting that diff succeed 
or not?), and it's not easily extensible or scriptable.  I'm sure there are 
many reasons why it seems the review process has been unwieldy, but the 
software's clunky UI is definitely part of the problem.  Until reviewboard can 
be significantly improved, I think it would be much more prudent to use git and 
the mailing list (or possibly, a new mailing list for plugin-developers) for 
managing the staging area.

Just my two cents -- 

Robert

["signature.asc" (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]