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

List:       koffice-devel
Subject:    Re: flake/canvasController
From:       Thomas Zander <zander () kde ! org>
Date:       2010-09-16 20:39:44
Message-ID: 201009162239.44991.zander () kde ! org
[Download RAW message or body]

On Wednesday 15. September 2010 08.11.24 Cyrille Berger wrote:
> On Tuesday 14 September 2010, Thomas Zander wrote:
> > I see 3 options;
> > * we get the graphicsviews based class in flake and all maintainership
> > goes into KOffice proper. In other words, if any community member adds a
> > feature or does a refactor he is allowed to do so without vetos because
> > of the external project. This would likely mean we should have at least
> > a demo of the usage of this class.

> > * we revert the refactor for the canvasController and maemo builds on top
> > of flake to do what it needs to do until the time comes their code is
> > open and then they optionally move to the first option.

> > * We accept that nokia is putting more manpower in koffice than the
> > volunteers are and accept whatever happens to the project even if that
> > means the quality goes down and the end-user-release will be postponed
> > till further notice.
> 
> I just want to attract your attention on the fact that this sentence could
> be read as Nokia's contribution are harming the project by droping its
> overall quality, I am hopeful it was not your intent, but it would show
> that careful wording is needed.

This certainly is a topic for another day. Suffice to say that I'm rejecting a 
lot of patches based on quality from many Nokia subcontractors.

But please don't focus on just that last option, its in there for completeness 
sake.

> Also in the context of this change, and
> only this change, can you explain what was broken in KWord, or any other
> KOffice application ?

What is broken, and I'm sounding like a broken record, is the contribution 
model.
I'm wondering why you are not addressing the actual complaints I wrote and why 
you are *only* attacking the form of the message.
 
> Actually, there are three other options to move forward, which are more or
> less the KDE way:
> * what Boudewijn did for that patch, discuss a design change with a small
> group using any media of your convenience (a.k.a irc, phone, sprint),
> publish a patch for review, make the modifications pointed by the
> reviewer, wait for shipit, commit

Please point to the public archive of this process. You claim thats what 
happened for the review, I claim it did not.
My basis of the claim is that the new feature only makes sense for an invisible 
feature we have to assume everything about.

> * an other possibility is to skip the discussion step alltogether and go
> for review
> * lastly, you can post design suggestion on this list
> 
> All the three alternatives are what we are using on daily basis, I don't
> see why it would not work for this case. 

Ok, did you really miss the part where the vast majority of the new feature is 
not actually in KOffice svn? Not publicly available for review and there is no 
way to post-commit review if the design makes sense?
Its not open development if
a) the design
b) the functional usecases
c) the code
are not available for joe-random to look at and to criticize. 

> And yes, on that problem, we are
> working in the dark, but the point of LGPL is to accept to work with
> proprietary solution (even temporary proprietary), as long as we don't
> work for them.

You are wrong; the point of LGPL is that it can be *used* by proprietary 
products.
Not become entangled with and have code in our lib thats useless without the 
external product.

-- 
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]