kde-runtime module master and KDE/4.9 branches
agateau at kde.org
Thu Oct 11 22:14:23 BST 2012
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
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 ):
"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
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.
More information about the kde-core-devel