[Kde-pim] Kontact Touch GSOC Project - mentor needed

[Kevin Krammer]

On Monday, 2013-04-22, Sebastian Kügler wrote:
> On Monday, April 22, 2013 16:34:44 Kevin Krammer wrote:
> > On Monday, 2013-04-22, Sebastian Kügler wrote:

> > > On that note, I think it would be best to do the GSoC as small mergable
> > > steps, that can go in one for one. As most of the code is already done
> > > in QML, a ton of small patches that go into master one for one would
> > > probably be nicer than to create one big branch that has to be merged
> > > at some scary point in time.
> > > 
> > > This is of course mostly up to Kevin, I guess, as he'll likely be
> > > reviewing
> > > most of the code, I just wanted to chime in in case it hasn't been
> > > thought of.
> > 
> > The problem with that approach usually is that master gets frozen during
> > the  GSoC period.
> > While we could probably make an exception for code that goes into
> > kdepim/mobile (I don't think we official release that), some changes
> > could affect even kdepimlibs and we certainly don't want to risk master
> > branch there.
> > 
> > Suggestions welcome though
> 
> Idea: The "go in" doesn't have to be master, while master is frozen, the
> patches could get "reviewed into" another branch, which gets merged
> whenever master is unfrozen.

Yeah, it is unfortunate that remote branches can not be rebased like local 
branches which effectively makes all changes in the branch look like a patch 
set on top of master.

I'll need to check if there is a git workflow that gets close to that.

> The reason why I propose this is because I think it could become quite the
> monster project, that will take very long to stabilize and achieve feature
> parity again. A "kernel style" development process usually prevents that
> from happening quite effectively.

My expectation is that most of the work will be separated by directory 
structure, i.e. not a lot of changes to code shared with the widget based 
applications. 

The mobile UI is currently not part of the standard build of kdepim, so any 
changes there, even in master, would not affect SC release parts.
So changes there could potentially be pushed to master directly and then 
merged into a development branch that only needs to be created if there are 
actually changes to somewhere else in kdepim.

Expected changes in kdepimlibs are more likely to be of the kind of adding 
Q_PROPERTY for existing setter/getter/signal tuples, which I think we can do 
even after feature hardfreeze if properly reviewed.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/active/attachments/20130423/35513812/attachment.sig>