----- 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 _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
