KF5 Volunteer day 1: Done

Kevin Ottens ervin at kde.org
Mon Feb 27 21:12:18 UTC 2012


On Friday 24 February 2012 10:48:04 Stephen Kelly wrote:
> Kevin Ottens wrote:
> >> If you have a list of people a newbie can ping for help and a list of
> >> tasks those people can understand and guide a newbie on, you could say
> >> that it's every weekend. Most people in #kde-devel would be able to help
> >> a newbie with, eg, 'should I replace this Q_WS_WIN with Q_OS_WIN?'.
> > 
> > That's a possibility. But having such a list doesn't ensure that at least
> > one person of that list is available every week-end.
> 
> Yes. What I think I mean is that there needs to be a migration path from 'I
> should only do work on volunteer days because that's the only time I can get
> help' to 'I can always ask for guidance in #kde-devel'. There are lots of
> helpful people in #kde-devel. One issue I'd see though is that once they
> see 'frameworks', they'll say (or think) they can't help because they're
> not involved in the frameworks effort, even if the core issue is something
> simple they can answer.

Makes sense indeed. The list of cleanup jobs we started is likely a good first 
step for that, it's easier to handle already for someone with previous kdelibs 
knowledge even if not involved in kde-core-devel.

So in any case, we should complete this cleanup jobs page. It takes time, but 
it's a very good investment seeing the first experience gathered with it.

Armed with it, we can probably change the communication to: come whenever you 
want on #kde-devel, and once a month we have a special get together saturday. 
Making it "special" seems to attract people so I'd keep that aspect. Opinions?

I think that once a month should be easy enough to make sure we always have a 
couple of people around.

> > Also we should
> > probably detail the tasks a bit more I guess, I'm not sure I'd be able to
> > easily answer the example question you proposed. :-)
> 
> stephen at hal:~/dev/src/kf5/tier1/solid{frameworks}$ git grep Q_WS_WIN
> solid/managerbase.cpp:#if !defined (Q_WS_WIN) && !defined (Q_OS_MAC)
> solid/managerbase.cpp:#elif defined (Q_WS_WIN) && defined(HAVE_WBEM) &&
> !defined(_WIN32_WCE)
> solid/managerbase.cpp:#        elif defined(Q_WS_WIN) && defined(HAVE_WBEM)
> && !defined(_WIN32_WCE)
> 
> Taking the first one:
> 
> * It is part of a conditional that also tests for Q_*OS*_MAC. So it should
> probably be Q_*OS*_WIN.
> * It guards a include of a file which does not relate to window systems, but
> does relate to operating systems. So it should probably be Q_OS_WIN. * It
> would surprise me if solid had ifdefs for different window systems, because
> of it's scope.
> 
> So this one at least should probably be changed to Q_OS_WIN.
> 
> Now you also know some of the thought process to deciding so you can help
> others too.

Definitely wiki material I'd say.

> This is marked as hard on the wiki page, but I don't think it
> is. Most of the uses of it are easy to decide. It's only the ones that are
> actually rightly (in Qt4) Q_WS_WIN and that need to be ported to QPA (in
> Qt5) that are hard.

Makes sense now, feel free to adjust it on the wiki. :-)

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron 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-frameworks-devel/attachments/20120227/9aa5f67b/attachment.sig>


More information about the Kde-frameworks-devel mailing list