Some very concerning commits to plasma-discover

Mon Nov 21 19:20:19 UTC 2016

Hi,

El domingo, 20 de noviembre de 2016 14:49:16 (CET) Clive Johnston escribió:
> Hi folks,
> 
> I'm concerned about the following packaging for plasma-discover
> 
> https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/discover
> / log/?h=kubuntu_zesty_archive
> 
> 1) Basically a Debian merge was carried out and the VCS fields have somehow
> got changed.  As far as I understand, this should not and could not happen
> using the KA-NG tooling, but yet it is there in black and white?

As you pointed out in your other mail, the Vcs-* fields for discover are correct
(apparently), i.e.

Vcs-Browser: https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/discover
Vcs-Git: git://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/discover

> 2) The automatic nature of the tooling does not seem to be flagging up
> conflicts that need attention.  For example, in the merge the following was
> removed, from the rules file:
> 
> -override_dh_gencontrol:
> -	dh_gencontrol -pmuon-discover -- -v4:$(DEB_VERSION_UPSTREAM_REVISION)
> -	dh_gencontrol -pmuon-updater -- -v4:$(DEB_VERSION_UPSTREAM_REVISION)
> -	dh_gencontrol -pmuon-notifier -- -v4:$(DEB_VERSION_UPSTREAM_REVISION)
> -	dh_gencontrol --remaining-packages
> -
> 
> These packages are transitional "dummy" packages from when discover was part
> of Muon, they therefore have an epoch in the archive.  Without this epoch
> they will fail to upload.

This, indeed, seems an issue in our packaging which has to be handled manually.
I did that in this comit:
https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/discover/commit/?h=kubuntu_zesty_archive&id=5bbb53e6524f702ae324cc9da6e69270e719379f

However, aparently, you still don't understand why this kind of things are 
happening, and you seem to insist in blaming again and again the merge helper
script instead of just understanding what's going on.

Just for the record, the process to merge from debian banches is documented
here:
https://git.launchpad.net/~kubuntu-packagers/+git/kubuntu-automation/tree/README.ng
Section 4 - "Merging from debian branches"

To sum up this is what the KA merge helper does:
1. It creates a temporary branch on top of debian's branch with some changes to
avoid some conflicts in advance
2. Then that temporary branch is merged (with 'git merge') into our kubuntu 
branch

And this is done as a better alternative of doing a plain 'git merge'. The fact 
that you may get some problems even using the KA tooling to handle the merges
doesn't mean that you wouldn't get the same problems (plus some extra problems)
if you do a plain 'git merge'.

You still don't believe me? Allright, let's simulate what would have happened 
without using the 'evil' KA script:

First let's create a couple of branches to get what we had before doing the merge:
git branch debian_merge_sim 1ff8922154542d5b402ec12c211048456ecec865
(this will point to the contents of 'debian/master' before the debian merge)
git branch kubuntu_zesty_archive_sim 7cdd5a5beacc40c3461c63bd966e66bec273bb57
(this will point to the contents of 'kubuntu_zesty_archive' before the debian merge)

Now lets checkout the target branch for the merge with
git checkout kubuntu_zesty_archive_sim

And now let's merge the debian branch with
git merge debian_merge_sim

Output of 'git merge'
Auto-merging debian/plasma-discover.install
CONFLICT (content): Merge conflict in debian/plasma-discover.install
Auto-merging debian/control
CONFLICT (content): Merge conflict in debian/control
Auto-merging debian/changelog
Automatic merge failed; fix conflicts and then commit the result.

Output of 'git status'
$ git status
On branch kubuntu_zesty_archive_sim
You have unmerged paths.
  (fix conflicts and run "git commit")
Changes to be committed:
        modified:   debian/changelog
        new file:   debian/patches/01_new-appstreamqt.patch
        new file:   debian/patches/series
        modified:   debian/plasma-discover-common.install
        modified:   debian/rules
Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   debian/control
        both modified:   debian/plasma-discover.install

So as we can see, 'git merge' did some changes automatically in the debian/rules.
Now inspect the contents of debian/rules. Does debian/rules have the correct
contents with the lines to handle the epochs? Well, no.

So now that we realized that the 'debian/rules' would be broken even if we did 
a plain 'git merge', now it's worth a think why 'git merge' is doing that. 

There is a good article here about the '3-way merge' algorithm (performed by 'git 
merge'):
http://www.drdobbs.com/tools/three-way-merging-a-look-under-the-hood/240164902
TL:DR -> Unlike us, the human beings, 'git merge' doesn't have a brain, it's
just a piece of software applying blindly an algorithm to resolve automatically
some conflicts; that will produce in most cases good results, but in a few
ones bad results, and we will have to fix them. Let's get over it.

> In addition to the above points, I am also concerned about changes/fixes
> others (Ubuntu Developers) have uploaded to the archive but have not been
> sync'ed into our packaging.  The old tooling used to flag these up and move
> them into a manual folder for attention.  The new tooling does not seem to
> pay any regard to this at all.
> 
> If we are doing away with this in the tooling, surely we need another way of
> detecting if bug-fixes have been applied by non-Kubuntu people and
> reflecting those changes in our archive tracking branches?

That's something which we didn't have time to handle yet, there is a trello
card which I created some time ago:
https://trello.com/c/3lWHpWk3/224-add-script-to-report-packages-in-git-out-of-sync-with-the-archive

> 
> Clive