[kde-community] Closing the kde-core-devel mailing list

[Aaron J. Seigo]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20140826/c714c525/attachment.sig>