Kate App/Part/KWrite => kate.git

[Tom Albers]

----- Original Message -----
> 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?

Worth trying. Some feedback from a packager would be nice though.
-- 
Tom Albers
KDE Sysadmin