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

[Aaron J. Seigo]

On Tuesday, August 12, 2014 21.23:54 Kevin Ottens wrote:
> Hello,
> 
> On Monday 04 August 2014 20:36:44 Vishesh Handa wrote:
> > Random Idea:
> Heh, someone with too much time at hand? :-)
> 
> Note that I generally find that fiddling with lists is generally generating
> quite some boring work across the board.
> 
> > How about we close the k-c-d mailing list?
> 
> I think others voiced it but IMO it is a very bad idea...
> 
> > It's main purpose used to be to discuss kdelibs changes, but now since we
> > have kde-frameworks, the mailing list seems less useful. We already have
> > kde-devel for other generic kde stuff.
> 
> ... which is based on wrong assumptions.
> 
> As Albert et al. pointed out, k-c-d is used for community wide technical
> discussions: great plans touching several projects, tooling changes (the
> great scons vs cmake battle for instance), kdereview process tracking,
> reaching the "core" people (hence the name) aka most actives in the
> community (in their project or several projects). I like to define it as
> the "town hall" of the tech people in KDE.

kde-community@ fills some of this now (c.f. this exact thread)

I covered kdereview process tracking in my response to Kevin Krammer in this 
thread earlier today, so I won't re-iterate that here.

To me, frameworks is about "great plans touching several projects". 

My concern is that having discussions like tooling changes "somewhere else 
separate from framework devel" will lead to a mailing list that is both very 
quiet, mostly filled with random topics that are going to be of little direct 
interest to most of the people most of the time (even if they are affected by 
the decisions) ...

Having library devel discussion on one mailing list and "other pan-KDE 
technical topics" on another is quite likely to end up with two relatively 
quiet lists with some on one list and other on the other.

One of the goals of frameworks ought to be to get more people working on the 
shared resources of KDE. Hosting the "shared technical discussions" is a 
pretty effective way of ensuring people remain in touch with the library 
development, even if they don't always contribute to it.

If one removes the patch review email from both lists, it becomes pretty 
evident how quiet both have become. Keeping people purposefully away from 
library development, product of its own or not, while treating all other 
shared technical topics as somehow separate in nature is unlikely to benefit 
future library development recruitment.

Please keep in mind just how difficult it has traditionally been to get 
contributors to kdelibs.

> So to get back to the original question, should be close kde-core-devel? I
> hope it's clear that "bloody hell, no!!!" Don't know how you'd feel about
> it, but for a community like our loosing its "town hall" that would be a
> disaster.

Agreed...

> For instance, Kevin Krammer's example of having a mean of
> contacting largely for gauging the need of a scripting BoF is spot on. I
> hope it won't get to that point, but k-c-d would still have value if it was
> the only kind of traffic on it.

How is a pan-KDE scripting BoF not a frameworks topic?

> If you see its purpose as the mailing list for the "KDE Frameworks
> *product*" then it shouldn't be closed.

This is a false choice; having a place for KDE frameworks as a *product* to be 
discussed does not require a mailing list separate from k-c-d. I agree that 
KDE Frameworks is a product; I agree it needs a well-known place to be 
discussed; I do not agree that it is benefited from its own mailing list 
separate from other KDE-wide technical discussion.

I struggle to come up with really good examples of such technical discussion 
which is not relevant to Frameworks as a product; and I firmly believe that 
those who involved in key positions with KDE project teams (and therefore need 
to be in on those technical discussions) ought to also be aware of Frameworks 
development.

The exception to this is the flood of patch review requests, which I don't 
think is helping the current frameworks devel mailing list as it is .

> I fall in the second category, because the reasoning for opening that list
> was first to avoid generating the noise on k-c-d during the transition

Which was a mistake imho; frameworks development is *not* noise. It is vital 
to all KDE projects. Hiding it under a basket to avoid "noise" is perhaps the 
best way to cut off visibility to developers who might otherwise participate.

> (first reason already mentioned above) but also to have a place for third
> parties interested in KDE Frameworks only to participate and get informed
> (second reason).
>
> Obviously, it is too early to know if it is worth it having k-f-d for people
> interested in KDE Frameworks only as this audience didn't have time to form
> yet.

If it develops and *if* they need to be insulated from technical discussions 
like "what build system to use" or "what to do about scripting" (which I would 
suggest they are quite likely to be very interested in) _then_ perhaps such a 
split can be considered.

> Now, since it has been mentioned in the thread as well, there is the
> question of review board emails... I'm increasingly of the opinion that
> they shouldn't end up on k-f-d and k-c-d. I used to think otherwise, but
> it's becoming increasingly clear to me that it hinders other type of
> discussions. Which means that the third parties audience I was talking
> about won't even get a chance to form if we don't change that somehow. Back

+1

-- 
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/1235cfce/attachment.sig>