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

[Kevin Ottens]

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.

For some reason, the kdelibs related discussion still lingered there although 
it was becoming its own thing. Since KDE Frameworks started the noise level of 
that particular project would raise risking to drown the other useful 
communications of k-c-d, hence the creation of k-f-d to avoid that risk 
(there's another reason, see below).

kde-devel is for people discussing general development. It's more the seeking 
general help area.

(I think the above paragraphs should cover the "recall the purpose of each 
list" that Aaron was calling for, at least that's my version of it, I'd like 
to believe I've been around enough to not be too far off)

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. 
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.

Some then argued that maybe we should close kde-frameworks-devel. That at 
least makes more sense to me. That said, I'm of the opinion we should keep it 
open. Remember above I mentioned there was another reason for its creation? I 
will get to it soon. ;-)

Choosing to close k-f-d depends how you see its purpose...

If you see its purpose as the mailing list for the "kdelibs to KDE Frameworks 
transition *project*", then yes it can be closed once this transition is over 
(probably not now though, as kdepimlibs still didn't transition yet, so I'd 
expect the traffic to raise again).
If you see its purpose as the mailing list for the "KDE Frameworks *product*" 
then it shouldn't be closed.

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 (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.

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 in the days we had 
bugzilla traffic on devel mailing lists, then it got moved away in specialized 
lists, it looks like the review board traffic should have the same fate.

OK, it's longer than I wanted to so I will stop soon. Sorry for the length, 
but I thought that just coming with a bullet point of actions without the 
reasoning behind it would be disrespectful.

Here is the bullet point list just in case it could be useful:
1) Don't close k-f-d or k-c-d;
2) Restate the purpose of our lists, maybe on wiki;
3) Move current review board traffic to some other list (kde-frameworks-
reviews and kde-core-reviews perhaps? no strong opinion there);
4) Wait for the full kdepimlibs transition into KDE Frameworks;
5) Wait a few more months after that (something like six months, maybe longer, 
depends how fast we reroute reviews in fact);
6) If a third parties and new KF5 specific contributors audience formed on k-
f-d then keep it, otherwise close it in favor of k-c-d[*].

Thanks for reading all the way down if you reached that line. ;-)

Cheers.

[*] Note that if that audience never forms we probably failed at something as 
the reason for modularizing aggressively was also to attract such new blood.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- 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/20140812/acdf58f1/attachment.sig>