[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-14 21:20:14
Message-ID: 201009142320.14917.zander () kde ! org
[Download RAW message or body]

On Tuesday 14. September 2010 20.06.50 Cyrille Berger wrote:
> On Tuesday 14 September 2010, zander@kde.org wrote:
> Well the code was posted for review here, the design was discussed at a
> meeting you were invited. It was mentioned in the minutes, I think it is
> quiet open for something not that big.

I'm not sure we are talking about the same thing then. The minutes contain no 
design details; just very high level goals. Anyway, I don't want to digress.

> Could it be better, maybe. But remember that the KDE way is also a lot of
> trust and openess in commits.

It can have that because whatever hits svn can be replaced by something better 
as soon as that becomes available.
Its an open development environment. I showed that we are moving away from that 
and this is not the first instance, just a pretty bad one. I already got 
objections when I fixed things in KWord as I saw fit with the argument that I 
broke some external but not available app.

> > I'm sorry, I didn't mean to give the impression I'm against having a
> > graphicsview based canvas controller.
> > I'm not. I'm saying its unhelpful to have it outside of KOffice svn in an
> > application that we can't see and have technical decisions based on
> > usecases I can't see.  It cuts everyone not 'in the loop' out of the
> > design process.
> 
> I think, we all agree with that it is suboptimal, but we have to live with
> that.

Only when there are extremely good reasons to do so. Otherwise it limits your 
ability to hack on the code you and I started to write in our spare time.

> Yes but is a temporary solution. As Boudewijn said, the code is going to be
> available at some point. In the mean time, we have the choice in telling
> Nokia and other companies that we don't want to work with them unless they
> show us their code (raising the question of why kofficelibs is LGPL), or
> accept that some members of the community act as proxy and have access to
> privilege information.
> 
> And soon, we will get their code and everybody will be able to be involved.
> In the meantime, we have to work with the proxies or tell Nokia to work on
> of fork of KOffice.

This is going to extremes again; I think you should try to avoid that a bit 
harder. I want to try to get to a conclusion that works for everyone. Going to 
extremes doesn't help to come to a mutual satisfactory agreement.

Even while my points have been stated before I'll repeat them one more time
* Refactors have been done for Maemo where the usecases are unknown, half the 
resulting code is unkown and essentially we have to trust that a company on a 
deadline is making the right design.
* There is now code in KOffice that I'd like to fix but am not allowed to. The 
assumption that after it goes public everything will be easy is not really 
satisfying, I've worked with that company for a bit longer.
* There is no code to test, to use or to explain the graphicsview based 
canvascontroller while we still have to maintain the refactorings for it in 
koffice.

I asked several times for options and suggestions to fix the issues I put on the 
table (and repeated above), but I didn't see any options yet. So, I'd like to 
move things forward and present options as I see them;  please feel free to add 
your own.

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.

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