From kde-core-devel  Thu Oct 11 21:10:06 2012
From: =?ISO-8859-1?Q?Aur=E9lien_G=E2teau?= <aurelien.gateau () free ! fr>
Date: Thu, 11 Oct 2012 21:10:06 +0000
To: kde-core-devel
Subject: Re: kde-runtime module master and KDE/4.9 branches
Message-Id: <1385888.aZOP2VZZPN () trinity>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=134998983828055

Le jeudi 11 octobre 2012 20:02:51 Laszlo Papp a =E9crit :
> > I think the problem is we don't know the commit policy for kde-runt=
ime. Is
> > it:
> >=20
> > fix-master-and-backport: fix in master, cherry-pick to KDE/4.x
> >=20
> > -- or --
> >=20
> > fix-stable-and-merge: fix in KDE/4.x, merge KDE/4.x in master
>=20
> I personally prefer the former as in contributors should make sure if=

> it is fixed in master, and if not, fix there, otherwise cherry-pick.
> That way the preference would be to focus on having the bug fixes in
> the upcoming releases rather than in stable releases. Having those
> fixes in stable releases may mean that they are not available for a
> (sometimes long) while in the upcoming releases in case of missed
> merges.

Problem with this approach is the code you backport is usually a lot le=
ss=20
tested as you made all your developments on master. In the svn days I e=
ven=20
remember people telling me they were blind-backporting to stable becaus=
e it=20
was "too much work to test the backported code".

It also makes it difficult to know if a fix has already been backported=
 because=20
it has different commit-ids depending on the branch it has been committ=
ed to.

I lke this rule from gitworklows (man gitworklows or [1]):

"Always commit your fixes to the oldest supported branch that require t=
hem.=20
Then (periodically) merge the integration branches upwards into each ot=
her."

> > - modify the commit-hook for KDE/4.x branches to show a message
> > recommending merging changes to master (optionally pointing to
> > instructions on the wiki for more info)
> >=20
> > - set up a nag system to send an email/post on irc if there are unm=
erged
> > commits and last merge-to-master is older than 2 or 3 days.
>=20
> I recall we had nagging emails previously about license issues and so=

> forth. To be consistent with the handling of those, I would prefer th=
e
> latter personally.

If we have an agreement to use fix-stable-and-merge, I'd be happy to ge=
t=20
started on writing a script to check for missing merges. Actually somet=
hing=20
like that:

git log --pretty=3D"%an <%ae>" origin/master..origin/KDE/4.9 \
   | grep -v scripty@kde.org  | sort | uniq

Could be a good start. It lists all authors of commits which are in KDE=
/4.9=20
but not in master (and, there is my name in there :/). Of course it can=
not=20
tell if a commit is actually a cherry-picked version of another commit =
in=20
master, so there are a few false positives.

Aur=E9lien

[1] http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html