Some very concerning commits to plasma-discover

Mon Nov 21 22:37:10 UTC 2016

ARGH! Can we please keep technical discussions technical, and not
personal! This is very discouraging.

I am asking you, Santa, and you, Clive, to back off on each another.

If we can't be friendly, at least let us be professional.

Valorie

On Mon, Nov 21, 2016 at 12:15 PM, Clive Johnston <clivejo at gmail.com> wrote:
> You are correct, I don't understand why this is happening.  All I know is that
> I was asked to upload packages to the archive and took a quick look over some
> packages to verify if I believed they were ready to upload, and my conclusion
> is that I don't.  I therefore decline the invitation to sponsor this upload.
> Please find another kubuntu-devel or MOTU to sponsor these packages.
>
> I will in future, keep my opinions to myself, and let someone else take on the
> responsibility of uploads to zesty. As they say on Dragon's Den, "I'm out".
>
> Regards,
> Clive
>
> On Monday, 21 November 2016 20:20:19 GMT José Manuel Santamaría Lema 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/discov
>> > er / 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/discov
>> er 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/RE
>> ADME.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/2401649
>> 02 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-o
>> f-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

-- 
http://about.me/valoriez