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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
