DevHeads.net

kde-runtime module master and KDE/4.9 branches

Hi,
I'm sending this e-mail because I was experiencing some bug with the
ScrollBar and I thought about fixing it. Then I decided to commit it
in KDE/4.9 because it's a bugfix and I realised it's already in 4.9,
it's just not in master.

My natural reaction was to see if we could merge KDE/4.9 to master,
that was the git output [1]. Besides the normal .desktop files
conflicts there were a lot of .cpp and .qml changes that conflicted
(mostly Plasma Components and some Nepomuk).

So, should I look into merging those? Maybe there are more things
fixed in 4.9 that aren't in master...
Should we make sure this won't happen again? If so, how?

Aleix

[1] <a href="http://paste.kde.org/565196/" title="http://paste.kde.org/565196/">http://paste.kde.org/565196/</a>

Comments

Re: kde-runtime module master and KDE/4.9 branches

By Laszlo Papp at 10/09/2012 - 13:54

I think David took the responsibility for the merge:
<a href="http://lists.kde.org/?l=kde-release-team&amp;m=134510779413123&amp;w=4" title="http://lists.kde.org/?l=kde-release-team&amp;m=134510779413123&amp;w=4">http://lists.kde.org/?l=kde-release-team&amp;m=134510779413123&amp;w=4</a>

Laszlo

On Tue, Oct 9, 2012 at 3:36 PM, Aleix Pol < ... at kde dot org> wrote:

Re: kde-runtime module master and KDE/4.9 branches

By Laszlo Papp at 10/09/2012 - 13:56

On Tue, Oct 9, 2012 at 7:54 PM, Laszlo Papp < ... at kde dot org> wrote:
Oh, that was mentioned for kdelibs, and not kde-runtime. Can someone
do that for kde-runtime as well?

Laszlo

Re: kde-runtime module master and KDE/4.9 branches

By Andras Mantia at 10/10/2012 - 04:17

On Tuesday, October 09, 2012 07:56:48 PM Laszlo Papp wrote:
Hm, as kde-runtime is not frozen in master, whoever does fixes in 4.9 should
merge them to master.

Andras

Re: kde-runtime module master and KDE/4.9 branches

By Laszlo Papp at 10/10/2012 - 05:13

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.

Laszlo

Re: kde-runtime module master and KDE/4.9 branches

By =?UTF-8?B?QXVyw... at 10/11/2012 - 10:56

Le mercredi 10 octobre 2012 11:13:57 Laszlo Papp a écrit :
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

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

Re: kde-runtime module master and KDE/4.9 branches

By Laszlo Papp at 10/11/2012 - 14:02

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.

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.

Laszlo

Re: kde-runtime module master and KDE/4.9 branches

By =?UTF-8?B?QXVyw... at 10/11/2012 - 16:14

Le jeudi 11 octobre 2012 20:02:51 Laszlo Papp a écrit :
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."

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 <a href="mailto: ... at kde dot org"> ... at kde dot org</a> | 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] <a href="http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html" title="http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html">http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html</a>

Re: kde-runtime module master and KDE/4.9 branches

By =?UTF-8?Q?Aur=C... at 10/11/2012 - 16:10

Le jeudi 11 octobre 2012 20:02:51 Laszlo Papp a écrit :
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."

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 <a href="mailto: ... at kde dot org"> ... at kde dot org</a> | 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] <a href="http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html" title="http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html">http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html</a>

Re: kde-runtime module master and KDE/4.9 branches

By Laszlo Papp at 10/11/2012 - 20:24

One could say the opposite as well for the upcoming versions from
master, so it depends on the point of view what you focus for. :-)

The commit id is not the only one to match. You can also match commits this way:

" Backport bugfixes

If you commit bugfixes, consider porting the fixes to other branches.
Use the same comment for both the original fix and the backport, that
way it is easy to see which fixes have been backported already. "

So as for cherry-pick, this would be a clear identifier as far as I can tell.

The problem I see with that approach is if a bugfix is forgotten to be
cherry-picked, it may be hard later to recognize which commits need to
be cherry-picked from master if someone would like to volunteer with
that if there are no clear identifiers for that in the commit message.
For instance a bugfix which is not made for a bugzilla entry.

Okay for me if it is demanded by our policy it has to happen, and
someone volunteers for making sure it does happen. Otherwise, the
upcoming releases from master may lack the bugfixes potentially.

Great. :-)

Why not? I think even if the commit message is poor like "build fix"
and it is the same for more commits, you still have the chance to make
sure they are the same in master and the given release branch
according to further information like the diff for instance. In case
of no ambiguous commit messages, it is less problematic.

Laszlo

Re: kde-runtime module master and KDE/4.9 branches

By =?UTF-8?B?QXVyw... at 10/12/2012 - 02:23

Le vendredi 12 octobre 2012 02:24:21 Laszlo Papp a écrit :
True, the reality is that developers should really test both branches.

Fixing bugs on stable has the advantage that you are doing more testing with
the stable branch, which means there are less opportunity to miss integration
problems. It is actually quite frightnening that we have alpha, beta, and rc
for the next 4.x.0 version, but then 4.x.y versions are released with very
little tests. The KDE QA team was investigating doing more testing for minor
releases, which could help.

That works, but it's much more manual than running:

git branch --contains <commit-id>

and getting a list of all branches which have this commit.

It sure needs a shift in developer practices. A nagging system could help
there.

Sure, I was just saying that right now running "git log
origin/master..origin/KDE/4.9" also returns some commits whose change are
already in master with a different commit id. Those are the false positives.

Aurélien

Re: kde-runtime module master and KDE/4.9 branches

By Laszlo Papp at 10/11/2012 - 12:13

Sure, but what I was referring to, is more than that. People should do
that for their changes, but you cannot expect there will be no
mistakes at all in the procedure. Someone making sure about this on
top of the utilities that can just be introduced, would be a great
addition as well. Currently David is similar contribution in kdelibs,
and I am happy about that. I do not think it is only tightened to
freeze. Perhaps if a few people get involved into this for separate
subcomponents, then it is not that a big job for each.

There were also people trying to make sure relevant changes ended up
in Qt 4.8 and Qt5 as well. These were mostly maintainers and approvers
I found, but basically anybody could have said. Although that is
somewhat a simpler situation because each patch is reviewed, so more
eyes have to miss this procedure not to happen.

That said, I support any mechanism that helps with missing those for
the authors as well.

Laszlo