Le mercredi 10 octobre 2012 11:13:57 Laszlo Papp a écrit : > > Hm, as kde-runtime is not frozen in master, whoever does fixes in 4.9 > > should merge them to master. > > Unfortunately, there may always be changes missing. Unsure how much it > can be automated, but I have the impression we do not exactly know > until a person is responsible for making sure.
If you merge stable into master you cannot miss changes. 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 If I run: git log --pretty=format:'%h %d %s %ad' | grep "Merge branch 'KDE" I get: b552550 Merge branch 'KDE/4.9' Tue Jul 17 21:18:02 2012 +0900 0afc1b1 Merge branch 'KDE/4.8' Thu Jan 26 22:06:22 2012 +0100 c83876b Merge branch 'KDE/4.8' Sat Dec 31 10:51:50 2011 +0100 fbe6cb0 Merge branch 'KDE/4.8' Thu Dec 29 15:13:29 2011 +0100 616aa5e Merge branch 'KDE/4.8' Tue Dec 27 18:29:12 2011 +0100 That is four merges for KDE/4.8, one for KDE/4.9. That sounds like people have tried to practice fix-stable-and-merge but either not everybody has been convinced it is the right way to go, or people believe someone will come up regularly to merge KDE/4.x into master. This is what happens in kdelibs, but it is in a special situation because master is frozen. For other repositories we should not expect someone will do the merge-in-master work for us. I don't think there is a way to enforce this, but here are some ideas: - 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. What do you think? Aurélien