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

List:       koffice-devel
Subject:    Re: Fine-grain KOffice source tree
From:       "LukasT.dev () gmail ! com" <lukast ! dev () gmail ! com>
Date:       2010-08-26 12:14:46
Message-ID: 201008261414.47036.LukasT.dev () gmail ! com
[Download RAW message or body]

On Tuesday 24 August 2010 23:01:24 Aaron J. Seigo wrote:
> 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 agree with this truth.
 
> 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. :)

Marketing is only small motivation. The real motivation is to improve
the developing workflow for Krita. I should be more clear. Sorry.
 
> > 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?

Yes. I think so. Maybe it could be just Athelier without K.
 
> > 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.

I use git svn. The problem is that it touches too much code (KOffice libs)
and e.g. git bisect is a problem -- too much recompilation.
 

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

Other packaging system means linux distros, right? The situation is different 
for Windows - it is more complicated process to deliver package from my point 
of view (thought I have small experiences with that yet)

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

Have you got any wider implications in mind?
 

What about other KOffice community members? 
How do you see the issue? You don't care?
_______________________________________________
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]