Kate App/Part/KWrite => kate.git

[Aaron J. Seigo]

On Saturday, January 29, 2011, Christoph Cullmann wrote:
> On Saturday 29 January 2011 18:36:17 Aaron J. Seigo wrote:
> > On Saturday, January 29, 2011, Christoph Cullmann wrote:
> > > - keep ktexteditor where it is (to have BC+SC kept) and have a small
> > > copy in kate.git to allow easier development (which I will keep in
> > > sync with the REAL on in kdelibs
> > 
> > i can't imagine ever allowing a project that isn't in kdelibs today to do
> > this. as such, i cringe at reading this. it seems extremely fragile and
> > is going to be amazingly confusing to people who may wish to contribute,
> > particularly casually (as i did in a small way last year when i used the
> > KTextEditor interface in plasma-desktop)
> > 
> > since you wish to stay with the SC releases, so we don't need to worry
> > about API drift between components due to being outside of a shared
> > release cycle, is there _any_ reason why KTextEditor has to stay in
> > kdelibs? can we just make KTextEditor a dependency for apps that require
> > it and provide a CMake module to find it?
> 
> I have no problem to move ktexteditor, too. I only found it more easy for
> the packagers to do it that way, as all compile time dependencies stay the
> same.

.. until you get to packaging the kate repository and have to figure out which 
KTextEditor to package?

it just seems extremely sloppy. what do the packagers and release team think 
about having this code dupliated in two places in the SC?

> Beside, I did the syncing of ktexteditor since more than one year now and
> really, there is nearly no change.

yes, it's doable. the question is if it is desirable :)

> But yes, I would be more happy with one
> place too, I only not like the idea to enforce people to have kdelibs.git
> just to test new extensions.

this is an issue where we are mostly guessing at cause and effect based on 
intuition and occasional anecdote. there is just no point, imho, to trying to 
figure it out with discussion.

what we can do is employ the good old scientific method: we have a hypothesis, 
it makes predications, let's run an experiment and see what the actual effects 
are. which to me means getting KTextEditor out of kdelibs so we can see what 
the real effects of more aggressive modularization of KDE Platform are.

this kind of experimentation leaves me feeling a bit uncomfortable, but 
lacking resources and expertise to imperically gather the required data and 
make an informed decision, it's probably the best we can do. if we start it 
now, we have an entire release cycle to determine early effects, and we can 
always reverse course later on if needed.

the results of this experiment, whose effects would be fairly limited (not 
everything uses the KTextEditor interface :) but broad enough to be 
meaningful, should give us very useful data to use in deciding what to do 
withe other similar cases. this would require that the kate team would need to 
pay more than the usual attention to development process effects and be 
wiling/able to report them back to the rest of us at intervals (2-3 times over 
the next year?). 

what do others thinks? too crazy? reasonable idea? worth trying? not worth the 
hassle for packagers and developers?

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20110129/d1a8a1ff/attachment.sig