On Tuesday, August 12, 2014 17.31:11 Kevin Krammer wrote: > On Tuesday, 2014-08-12, 16:40:36, Aaron J. Seigo wrote: > > On Tuesday, August 5, 2014 21.28:14 Kevin Krammer wrote: > > > k-c-d is the list to for things that happen in development, like > > > kde-review > > > requests, inter-module coordination, etc. > > > It is more like a "kde-community-technical" list. > > > > review requests probably should be going elsewhere; they make following > > actual discussion not about specific patches more difficult. > > I didn't mean review request as in reviewboard notifications. I meant > request for review of things moving into kde-review.
Ok :) So, kde-review requests ... There are two broad categories: * module-specific * lone projects An example of a module-specific category woudl be a new Calligra application. Does that benefit more from being announced on k-c-d, or on the Calligra devel ml? Similarly for a new framework / library: that probably makes most sense to request review from the Frameworks team since it needs to follow a rather specific and highly prescribed set of standards. I don't think it makes any more sense to announce a new framework is available for review on the Calligra list than it does to announce a new Calligra application on k-c-d. This pattern repeats with kdepim, plasma, edu, games, etc.. "Lone projects", ones that don't fit into any particularly active existing community, need a place to announce, of course. Also, i18n/l10n probably wants to be able to track such things. If kde-devel@ is the mailing list for discussing use of KDE frameworks/libraries (as opposed to the development of them), then this would be a natural place for that to occur. It would also bring some additional focus and energy to kde-devel@ that is quite on-topic for that list. My suggestion therefore is to move kde-review announcements to kde-devel@, allowing k-c-d to focus on frameworks development and coordination. > > inter-module coordination ... should that not happen on the relevant > > module > > lists? > > You mean multiposting to several lists, potentially ones one is not > subscribed to? Ah, we have a terminology issue. When I hear "inter-module" I hear "something that affects 2-3 specific modules at the application level"; you seem to be using it as a loose synonym for "frameworks". Example: If it involves, say, KDE Edu and KDE Games considering adopting a common QML UI strategy (random, but potentially realistic, example) then cross-posting to those lists seems quite sane. In such cases, k-c-d is not the best possible venue, though I see it being used for that from time to time. Another example, this time yours: > Lets take for example my inquiry on interest for a scripting BoF. > I could have posted that to all module development lists, I am sure posting > to kde-core-devel was the better choice. Yes, k-c-d is perfect for that kind of thing; pan-KDE-software scripting is a frameworks issue. I don't see that as "inter-module" discussion any more than kcoreaddons, threadweaver, or any other frameworks level technology is. > > the reason kde-devel exists separately from kde-core-devel is to provide a > > place for developers working with KDE libraries and applications that > > doesn't also carry discussion related to work ongoing in kdelibs. > > Sure, but asking questions about how to use frameworks will end up on the > frameworks list, because that's the most obvious name for people looking for > help on frameworks. agreed; my suggestion is that we already have these lists: kde-core-devel and kde-devel. frameworks-devel ought to be closed and merged back into k-c-d from whence it was forked with the r-b traffic going to a new list. > If we feel that this will be a problem we'll need "frameworks users". we already have that: kde-devel@ -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community