From kde-active  Tue Apr 23 07:48:33 2013
From: Kevin Krammer <krammer () kde ! org>
Date: Tue, 23 Apr 2013 07:48:33 +0000
To: kde-active
Subject: Re: [Kde-pim] Kontact Touch GSOC Project - mentor needed
Message-Id: <201304230948.37508.krammer () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-active&m=136670340812527
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============7119898902194058417=="

--===============7119898902194058417==
Content-Type: multipart/signed;
  boundary="nextPart10524171.ycjho5RZFB";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart10524171.ycjho5RZFB
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

> > > On that note, I think it would be best to do the GSoC as small mergab=
le
> > > 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.
> > >=20
> > > 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.
> >=20
> > 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.
> >=20
> > Suggestions welcome though
>=20
> 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=
=20
branches which effectively makes all changes in the branch look like a patc=
h=20
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=20
structure, i.e. not a lot of changes to code shared with the widget based=20
applications.=20

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

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

Cheers,
Kevin
=2D-=20
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

--nextPart10524171.ycjho5RZFB
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iD8DBQBRdjzRnKMhG6pzZJIRApdKAJ0cnJGORXlBTlg0FC+qZgf33KUzgACdH6VJ
6XA36gzsj6LNtyKHZkv27eE=
=pzgf
-----END PGP SIGNATURE-----

--nextPart10524171.ycjho5RZFB--

--===============7119898902194058417==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Active mailing list
Active@kde.org
https://mail.kde.org/mailman/listinfo/active

--===============7119898902194058417==--