kde-runtime module master and KDE/4.9 branches

[Aurélien Gâteau]

Le vendredi 12 octobre 2012 02:24:21 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".
> 
> 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. :-)

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.

> > 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.
> 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. "

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.

> > 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."
> 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.

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

> > 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.
> 
> Great. :-)
> 
> > 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.
> 
> 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.

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