Triggers should be merged

Posted Mar 18, 2008 20:17 UTC (Tue) by dskoll (subscriber, #1630)
Parent article: Who maintains dpkg?

I use Ubuntu and Debian and recently noticed the trigger mechanism coming into play on Ubuntu. It's an excellent idea. I hope the Debian maintainers can see beyond their pig-headedness and merge the feature.

Triggers should be merged

Posted Mar 18, 2008 21:11 UTC (Tue) by tzafrir (subscriber, #11501) [Link] (5 responses)

http://article.gmane.org/gmane.linux.debian.devel.dpkg.ge...

Specifically Guillem Jover, main maintainer of dpkg, writes there (partial quotes):

 ...

The branch has never been in an acceptable state, it needs cleanup,
which Ian has refused to do, repeatedly, and wasted probably more time
and everyone's energy starting this (and previous) massive flamefests
than what would have taken to just fix it.

 ...

Anyway, after the freeze was announced it was clear that Ian was not
going to fix the branch, and because having this feature for lenny is
highly desirable I was just going to have to fix it myself and review
during that process, but got quite sick for a week, during which he
started all this mess.

 ...

Triggers should be merged

Posted Mar 18, 2008 21:29 UTC (Tue) by mgb (guest, #3226) [Link] (4 responses)

Those quotes are misleading without also stating why Guillem considers the feature branch to
be unacceptable. Guillem demands that Ian rebase in order to create a prettified history.
Rebasing is not only an inordinate waste of effort in this situation but will also make it
harder to merge other long-pending work.

"Triggers" is not some kind of experimental hack.  This is a well-written and documented
feature which has been working successfully in Ubuntu for half a year.

It's unfortunate that Guillem was sick for a week, but he blocked the merge for six unsick
months before that.  And as soon as Guillem was once again unsick he started work on more
indenting and renaming of unused parameters.

Debian urgently needs to regain control of this critical package so that experienced
developers can get it back on track.

Triggers should be merged

Posted Mar 18, 2008 22:01 UTC (Tue) by tzafrir (subscriber, #11501) [Link]

Read the full message (I quoted only partially) to see why that particular feature branch was
considered unacceptable.

Triggers should be merged

Posted Mar 20, 2008 3:49 UTC (Thu) by akumria (guest, #7773) [Link] (2 responses)

Rebasing is not only an inordinate waste of effort in this situation

Presumably you have some sort of evidence for this?

Having a clean history is a cost. No doubt. But having an unclean history is a higher cost.

Weeks. Months. Years down the track, isolating a problem to "a branch you merged" which has lots of unrelated changes can make debugging significantly harder.

There is plenty of evidence to show that debugging is assisted by having good forensic tools -- such as a clean history.

but will also make it harder to merge other long-pending work.

You mean someone developed a feature dependant on another feature rather than developing the secondary feature against mainline and making it easier to review?

Basically the thrust of your complaint seems to be that it is the reviewer who should do all the work rather than the submitter.

That can certainly work in some contexts (e.g. when the submitter is your boss and they pay you) but in a volunteer project you want to make things as easy as possible for a reviewer to give you the thumbs up.

Each barrier (no I don't have the time to do X, that feature (Y) is dependant on X -- which I won't seperate) makes a reviewers job much harder.

Triggers should be merged

Posted Mar 20, 2008 6:02 UTC (Thu) by jamesh (guest, #1159) [Link] (1 responses)

Rebasing certainly does have a cost.  The act of rebasing effectively states that the old line
of development is now dead, and the rebased version is what everyone should be using.

This is not much of a problem if the old line of development was private or no one else ever
merged that work or based new branches off that tip.  But if others have used the old line of
development, they are now obliged to rebase their work too.  In contrast, if you just merge
the branch you get the history as it was developed and all the dependent branches can continue
on as before.

I'm not sure where Ian's branch fits in on this spectrum, but I wouldn't be surprised if the
Ubuntu distro folks have work based on top of Ian's, given that triggers are in that version
of dpkg.

Triggers should be merged

Posted Mar 20, 2008 11:16 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

I wonder whether anyone has based their work on Ian Jackson's triggers branch, other than...
Ian Jackson, in his later work.

Triggers should be merged

Posted Mar 28, 2008 8:55 UTC (Fri) by muwlgr (guest, #35359) [Link]

In fact, currently triggers do not save as much postinst run time as I (and you) would desire.
In most cases, dpkg is run from under apt-get or aptitude. And these apt tools decide by
themselves when to run dpkg with only one package and when run it with a batch of packages at
once (and the bigger is the package list on dpkg command line, the more useful are triggers).
Often when new critical libraries are coming to your system with updates, they are updated
one-by-one, as is decided by apt, so each dpkg run incurs an ldconfig run by itself. The same
is for updating critical components, like udev, mdadm, lvm2, etc. They are often updated
one-by-one as well, which triggers initramfs regeneration on each single dpkg run. So, not
much saving with triggers so far, until package interdependences are reviewed, or until more
batching is allowed by apt-get/aptitude.