Some very concerning commits to plasma-discover

Tue Nov 22 21:24:10 UTC 2016

Santa,

Thank you very much for your careful elaboration. It's clear that
regardless of whether or not we used the tooling, we would have ended up
with the same problem. Therefore, the tooling is not the problem. Thank
you, as well, for fixing the problem that inspired Clive's original email.

For that matter, if anyone is having a problem with the tooling, at least
in relation to Debian merges, it's fairly hard to imagine what that problem
would be. The [code][1] is commented sufficiently to explain exactly what
it does, which is little more than a little cleanup before otherwise doing
a normal git merge. I would suggest if someone has a legitimate concern, a
bug report would be a more reasonable way to solve it. And, of course,
patches welcome. ☺

[1]: https://bugs.kde.org/show_bug.cgi?id=357895#c3

On Mon, Nov 21, 2016 at 11:20 AM, José Manuel Santamaría Lema <
panfaust at gmail.com> wrote:

> 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 7cdd5a5beacc40c3461c63bd966e66
> bec273bb57
> (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
>
>
>
> --
> kubuntu-devel mailing list
> kubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/kubuntu-devel
>

-- 
       @wxl | polka.bike
C563 CAC5 8BE1 2F22 A49D
68F6 8B57 A48B C4F2 051A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20161122/c99f0460/attachment-0001.html>