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

List:       koffice-devel
Subject:    Re: Fine-grain KOffice source tree
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2010-08-24 21:01:24
Message-ID: 201008241401.24949.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


as a relative outsider with one hand on marketing related issues ...

On Tuesday, August 24, 2010, LukasT.dev@gmail.com wrote:
> My motivation:
> Krita is not Office suite application, we aim for digital painters and
> Office marketing would be wrong for us. We like to say that we are based on
> KOffice technology and that we are not part of the Office suite.
> This would be one small step to make it clearer.

branding is not defined or driven by the layout of the source code on a 
server. it is defined by presentation to the public.

i think you may have some good reasons to make the proposed split, but 
branding really isn't one of them. if splitting the repository makes it easier 
for whomever is doing KOffice marketing to wrap their head around the messages 
they need to be creating and spreading, then perhaps it does have value there. 
but really, there is no actual connection. witness how the workspaces are 
marketed these days even though they are still in kdebase. :)

> I started some discussion on IRC with Krita devs and
> Cyrille suggested some nice idea to fine grain like this:
> 
> o kofficelibs
> o koffice (-krita -karbon +braindump)
> o kathelier (+krita +karbon)

is "Kathelier" intended to be another brand to promote to the public as a 
suite of visual creativity apps?

> Benefits:
> o disk space, network traffic:
> 1. I have small laptop harddrive and I would like to have 3-4 checkouts
> around (external disk is not solution, I want to hack on train), but this
> is here just to have more benefits

this is why there are branches and `svn switch`; git makes this much more 
palatable.

> 2. some countries have slow internet connection which makes harder to
> contribute for people from indonesia, china etc.

the real solution there is to not use a centralized revision control system 
and to make initial checkouts available on physical media. making smaller 
modules helps only a little, and really only on first checkout, when a network 
connection is required for each commit and the initial checkout requires 
continuous access to the network for an extended period of time.

> o packagers
> Windows KDE packagers asked for kofficelibs/ as they want to allow users
> to install single application and not whole office suite and it is not
> possible now

this is an artifact of their delivery system. other packaging systems manage 
just fine to split out these source packages into multiple binaries for the 
user.

i'm sure you will consider all the wider implications of such a change with 
regards to what it means for the future development of kofficelibs, etc. once 
a decision is made, however, it may be best to wait until the git transition 
starts.

svn2git makes it pretty easy to break up modules into separate git 
repositiories, while tracking things like moves can be harder fwiu.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks

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