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

[Laszlo Papp]

On Tue, Aug 12, 2014 at 8:23 PM, Kevin Ottens <ervin at kde.org> 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.
>
> 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.
>

Thank you for your long explanation.

I tend to agree that what "core" means in KDE has changed, IMHO
fortunately. To me, frameworks is just one of the KDE products, but not
necessarily the core of the technology anymore. I personally think the
overall technical infrastructure KDE uses is "more core" which applies also
to non-frameworks based software in KDE. There is even software in KDE
beyond Qt and C++. So, what I am trying to say is that frameworks deserves
its own mailing list IMHO as a separate product and not just an in-between
transition.

To recap it, I think maintaining the status quo is good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20140812/b5ede56c/attachment.htm>