Harald Sitter apachelogger at
Thu Jul 31 08:18:06 UTC 2014

On Wed, Jul 30, 2014 at 4:17 PM, Philip Muskovac <yofel at> wrote:
> On Tuesday 29 July 2014 21:09:58 Harald Sitter wrote:
>> On Wed, Jul 23, 2014 at 3:21 PM, Jonathan Riddell <jr at> wrote:
>> > On Wed, Jul 23, 2014 at 11:03:34AM +0200, Harald Sitter wrote:
>> >> so, this new sort-and-wrap stuff we are using... it's making me
>> >> incredibly pissed off for three reasons
>> >
>> > I quite like it, I find it makes things much more readable and
>> > predictable.
>> >
>> > Many of the plasma 5 packages were packaged before I added lots of
>> > extra deps to the kf5 -dev packages.  Now all KF5 -dev packages should
>> > themselves depend on any frameworks their cmake files say they
>> > require.  So many of the build-deps from plasma 5 can probably be
>> > removed.
>> Fair enough, but what's the use in this sort of diff:
>> 79+ oxygen-sounds,
>> 80 plasma-nm,
>> 81 powerdevil,
>> 82- oxygen-sounds,
> Being predictable? If I see a sorted list of packages I will look for oxygen-
> icons before plasma-nm, not maybe somewhere at the bottom of the list.
> Also, maxy uses wrap-and-sort at debian so using it too would make merging
> easier.
> I'm seriously tired of merging packages where I have to review huge install
> file diffs because we simply appended new files and debian sorted the files
> alphabetically which makes actual file moves really hard to spot.
> (Which I guess is the reason I'm the only one that actually checks for that?)

I totally dig the debian merge reason, but that does not justify
history pollution. So I guess what I am saying is if we want to
wrapsort then it needs to be done in such a way that one can not
(repeatedly) forget to run it (e.g. server-side repo hook and/or local
hook you can set up in ~/.bzr or some such nonense). Otherwise what is
going to happen is that every 5 commits in a repo someone is going to
forget to wrapsort and then after two cycles every other line's
annotation will not point to its last actually change or introduction
but to a pointless wrapsort diff because someone previously forgot to
How do I know that is going to happen? Because already people
sometimes use the wrong dch or don't use debcommit (consequently don't
tag) or don't use quilt to dep3 document patches but do it manually.
And unlike wrapsort those tools actually help you do something you
need to do anyway, outlook is not so good really.

tldr: if we wrapsort ultimately the server side repo should reject
pushes that either weren't wrapped and sorted and quite possibly bzr
ci should automatically try to wrapsort


More information about the kubuntu-devel mailing list