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

[Kevin Ottens]

On Tuesday 26 August 2014 17:17:43 Kevin Krammer wrote:
> On Tuesday, 2014-08-26, 16:15:56, Aaron J. Seigo wrote:
> > "Stuff" means more than "code". A best practice is shared "stuff"; a
> > community-wide policy is shared "stuff". The difference between having an
> > agreed upon best practice or policy and a code repository is academic; it
> > requires the same people to buy into it and provide input.
> 
> Ok, sure, if everything development related is a frameworks topic, then this
> is also a framework topic.
>
> I used frameworks in the sense of being related to KDE frameworks products
> as in contrast to KDE application products.

Although your dichotomy makes sense, I think I see the point Aaron is trying 
to make (any wrong paraphrasing will be totally my fault):
"Even if that's a KDE application development topic, as long at it spans a 
large enough set of applications, then it is relevant to occur where KDE 
Frameworks discussion occur".

Of course the devil hides in the "large enough" definition. But we can 
probably rely on common sense and a firm list moderator/referee for that. :-)

If understood that correctly it kind of make sense too. It's a good way to fix 
the disconnect between KDE application developers and kdeli^WKF5 developers 
which occurred when 4.0 got released. We made a tiny progress in that regard 
during the transition cycle, but we have to be careful to not get back to the 
starting point now that the transition is well engaged and applications 
started porting.
Also even best practices can lead to finding holes in Qt or KF5... fixing 
those is clearly something in the realm of KDE Frameworks (as a Qt 
contribution or working toward a new framework).

I was leaning toward having k-f-d for people interested in KDE Frameworks 
only... but seeing Aaron's argument, I think I'd be ready to change my 
position provided we have the following guarantees:
 * k-d is really about people asking questions on *using* the frameworks (our 
qt-interest if you will);
 * k-c-d is really about KF5 development and "large enough" cross KDE 
applications discussions.

We did a bad job in the past at ensuring that. If we get a clear definition of 
what's allowed on both list and a couple of people actively monitoring the 
lists to redirect lost souls then I'm fine giving a try to that model again.

BTW, Kevin, to me you look like a very good candidate for such a role. :-)

In the spirit of my previous bullet point list, here is an alternative 
scenario assuming my rambling above is correct (it also takes into account the 
evolution of my thinking about review board):
1) Don't close k-f-d or k-c-d;
2) Restate the purpose of our k-c-d and k-d (probably on wiki) with guidelines 
on what's acceptable there;
3) Appoint moderators/curators/referees to deal with k-c-d and k-d using the 
new guidelines;
3) Move all review board traffic to a kde-reviewboard list (it'd make sense to 
deal with it just like commits in fact, they are proto-commits after all);
4) Wait for the first KDE Frameworks release containing kdepimlibs in full;
5) Close k-f-d in favor of k-c-d.

Regards.
-- 
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/20140826/7af8d704/attachment.sig>