KDE Frameworks: Moving toward 5.0 final and Governance

[Kevin Ottens]

Hello,

On Monday 06 January 2014 09:33:38 Martin Graesslin wrote:
> On Monday 06 January 2014 07:52:50 Kevin Ottens wrote:
> > The current list of modules is there:
> > http://community.kde.org/Frameworks/List
> > 
> > As you can see there's quite some holes in the table, and quite a few
> > entries marked unmaintained. KDE Frameworks as a set of technologies will
> > only be taken seriously if we get something more complete there. I urge
> > everyone with an interest in KDE Frameworks to step up, look at that list
> > and volunteer to maintain a framework. If you volunteer, know that the
> > 
> > following will be expected from you:
> >  1) Complete in the table the information regarding your framework;
> >  2) Do an API review and modernization pass in your framework (possibly
> >  with the help of others);
> >  3) Stick around for a long period to act as maintainer (see below for
> >  details);
> >  4) The day you want to move away from your duties, do so responsibly,
> >  don't just disappear, make sure you pass the torch to someone else
> > (probably the most important point in the list!).
> 
> I have a question concerning the platforms: must a maintainer be able to
> support/maintain all platforms or can a maintainer say I only maintain the
> framework for platform foo?

That's a good question.

In my opinion it's fine for a maintainer to delegate the duties to make things 
work on a given platform to someone else, but, he has to be able to answer at 
all time "is this platform supported? is there anything broken there?". I 
think that's important that at the end of the day the maintainer is the point 
of contact for the given framework. 

> This is a very important point given that our community comes from a Linux
> background and testing patches on other platforms requires to buy software
> and/or new hardware.

Of course, for most of the frameworks it shouldn't be an issue (if they're 
"pure Qt"), that's a very valid concern for frameworks which make native 
calls. In that case I think it's very important that we're blunt and honest 
about the situation. I'd rather see a few frameworks where we claim "sorry, we 
don't support platform X yet/at all", than having a list where we claim we 
support all platforms for all frameworks while we're in fact lying for some of 
them.

> To make a very practical example: so far maintainership of KWindowSystem was
> in the KWin team, but obviously we can only maintain the X11 part of it.
> 
> To go with that: can a framework be team maintained? E.g. could I write down
> "KWin team" or just write down "KWin maintainer" to bind the maintainership
> to KWin as it used to be?

I'd rather have a person name to be honest. It's really for the single point 
of contact situation in case of big troubles and to avoid diluting the 
responsibility. How in practice the work is then distributed for a framework 
is to the discretion of the appointed maintainer, if there's a whole team 
helping all the better.

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-core-devel/attachments/20140106/360e1974/attachment.sig>