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 scri...@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