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

List:       koffice-devel
Subject:    Re: flake/canvasController
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2010-09-15 8:22:04
Message-ID: 201009151022.04909.boud () valdyas ! org
[Download RAW message or body]

On Tuesday 14 September 2010, zander@kde.org wrote:
> On Tuesday 14. September 2010 10.37.47 Boudewijn Rempt wrote:
> > By the way, the KOffice community has decided that libraries do not have
> > explicit maintainers,right? So talking about "The flake maintainers" is a
> > bit weird -- and I am unsure here, but did you mean to imply that if such
> > a group would exist, I wouldn't be part of it?
> 
> First a quick note; please try to avoid reading more into what I write.
> Assume pure intentions, everything will go much easier that way.

That is why I asked. And I am sorry, but I am still unsure about what you meant with \
that paragraph.

> In KDE we don't work that way; 

Isn't the KDE way most often quoted as "He who does the work, decides"? (see for \
instance, http://osdir.com/ml/kde-scm-interest/2010-02/msg00042.html).

> things happen in the open 

And apart from doing the work, before starting the work I discussed the ideas at a \
sprint, on irc, at Akademy. I put the patches on the mailing list within days of \
writing the first cut implementation, discussed those, incorparated fixes and \
suggestions, posted the updated version, discussed those again.

> and get developed in the open

Sorry, I simply don't understand why you think this patch was not developed in the \
open.

> with much more input from people that have previously been hacking on 
> the same code than was shown here.

I am definitely one of the people who hacked previously on this code. Of the other \
people who have done a important work on this code, Jan, Peter and Adrian all \
unfortunately have left KOffice, so they couldn't comment. I discussed my patches \
with Casper and Thorsten (and Marijn, but he didn't work on KoCanvasController \
before). Only you did not comment so I assumed that you did not have input for me.

> We now are at a position where we can't change things in Flake because some 
> code that I can't even see, let alone commit to, has the only existing 
> graphicsview based subclass. I mean, seriously?

If you do not want code to exist that you don't have access to then the KOffice \
libraries should not have been LGPL'ed. And you might have be able to get access, you \
can ask your employer.

And it's a bit extreme to say that "we cannot change things in Flake" -- all you have \
to do is post a patch on reviewboard or on the mailing list and be cooperative when \
that patch is discussed.

> My point is that this is not maintainable and not sustainable. 

I don't understand why you think this code is not maintainable. I think this code is \
pretty maintainable and I will be around for the foreseeable future to see to that, \
just like I have been around for the past seven or so years. 

> This segments 
> the community (again) 

How so? I don't understand what you mean here. In what way is the community \
segmented, and how has that happened before? I'm afraid you have lost me here.

> and makes the effort to integrate with graphicsview 
> better something that community members can't really work on.
> 
> I suggest we think about an alternative way to get to this goal, what would 
> work for you?

This code and design works perfectly well, it's flexible and neatly separates design \
from underlying implementation assumptions. How about if you have concrete technical \
problems that cause actual bugs you bring those forward? 

-- 
Boudewijn Rempt | http://www.valdyas.org
Ceterum censeo lapsum particulorum probae delendum esse
_______________________________________________
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]