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

List:       koffice-devel
Subject:    Re: Google Online document Plugin for KOffice
From:       Thomas Zander <zander () kde ! org>
Date:       2010-07-14 16:39:40
Message-ID: 201007141839.42126.zander () kde ! org
[Download RAW message or body]

On Tuesday 13. July 2010 17.46.56 Inge Wallin wrote:
> But you are also right that a choice of location is not
> permanent.  Anything  in plugins/staging could be moved up to plugins/ if
> it's "ready" in some sense.  Just as well could anything outside the main
> repository be moved into koffice when it's ready (or before, if it goes to
> the staging area).
> 
> My suggestion would be that if the intention is to eventually be part of
> the  KOffice release, then add the new plugin to plugins/staging/.  If
> it's meant to be an add-on, then start out in the external repository.

I disagree with that suggestion; the goal is to have code committed early even 
while its immature. I think many will want their code to be released inside 
of KOffice and thats fine. Making a decision if someones new code is going to 
eventually be good enough at the first commit when the code is meant to be 
immature (since its very new) just makes people postpone the commit and this 
goes against the whole concept of getting people to develop in the open.

I'm also quite curious what your objections are to people starting in the 
kofficeplugins repo that exists in kde svn and moving the code into koffice when 
they feel its mature enough.
Which is a strategy that most projects follow, so I'd like to know why you 
suggest differently. 
Right now I'm thinking we should just follow the already known working route of 
an external staging area with no constraints. I don't see any added value in 
your proposal; but please feel free to explain your ideas more.

> It is not misrepresenting, it is true: there are no objections.  And as I 
> suggested above, if the intention is to eventually be a part of KOffice 
> proper, then by all means put the plugin into plugins/staging. This is the 
> case for the code in question, or am I wrong, Mani?

As I wrote various times before; the decision where *this* plugin goes is not 
really that important to me. This code has been under development for quite a 
while outside of svn. This is what caused the suggestion.
There is no discussion going on over what Mani can or can not do.

> Well...  I would argue that code that is still in staging/ would not have
> to  abide by freezes.  They are not going to be released, after all.

That is a nice suggestion, but that would add an exception to translation 
policies which can only lead to confused translators and testers. 
Also, if a new plugins is allowed 2 days before the RC and that plugin crashes 
on startup this exception on freeze makes little sense to me.
It brings me back to the initial question of what is gained by shoe-horning new 
plugin development into a much more stable tree.

Being a friendly inclusive KOffice community includes creating a place to play 
with no consequences to others and a place to develop plugins without *having* 
to compile KOffice.
I'd like to avoid that effort and openness being suppressed by both Boudewijn 
and you objecting to it. So please be more inviting to new potential community 
members and open to this effort called "kofficeplugins".

-- 
Thomas Zander
_______________________________________________
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]