Kate App/Part/KWrite => kate.git

[Christoph Cullmann]

On Saturday 29 January 2011 21:19:24 Aaron J. Seigo wrote:
> > 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?
Actually, you can not package the wrong stuff by accident, ktexteditor from 
kate.git not even install or compile at all without extra arguments to the 
cmake call.

> 
> 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?
I have nothing against such an experiment, given that it is clear that it was 
not my plan to disrupt the current dependency chain for compiling. I think 
already this move to kate.git disturbs enough, if you want to add additional 
stress, feel free. Current ktexteditor in kate.git is up-to-date, if you want 
to try the stuff, deactivate it in kdelibs and activate it again in toplevel 
kate.git

Greetings
Christoph