kde-runtime module master and KDE/4.9 branches

[Aurélien Gâteau]

Le jeudi 11 octobre 2012 20:02:51 Laszlo Papp a écrit :
> > I think the problem is we don't know the commit policy for kde-runtime. Is
> > it:
> > 
> > fix-master-and-backport: fix in master, cherry-pick to KDE/4.x
> > 
> > -- or --
> > 
> > fix-stable-and-merge: fix in KDE/4.x, merge KDE/4.x in master
> 
> 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 less 
tested as you made all your developments on master. In the svn days I even 
remember people telling me they were blind-backporting to stable because it 
was "too much work to test the backported code".

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

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

"Always commit your fixes to the oldest supported branch that require them. 
Then (periodically) merge the integration branches upwards into each other."

> > - 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)
> > 
> > - set up a nag system to send an email/post on irc if there are unmerged
> > commits and last merge-to-master is older than 2 or 3 days.
> 
> I recall we had nagging emails previously about license issues and so
> forth. To be consistent with the handling of those, I would prefer the
> latter personally.

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

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

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

Aurélien

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