| |||||||||||||
Re: Packaging and patchingRe: Packaging and patchingPosted Aug 24, 2009 6:03 UTC (Mon) by nevyn (subscriber, #33129)In reply to: Packaging and patching by rlk Parent article: On properly packaging perl
It's frustrating when distributors change things without discussion with upstream developers, even when it's a bugfix. Packagers don't live in an ivory tower, and the vast majority will happily accept at least co-maintainers from upstream (if not just give them the package). We wound up fixing this issue in a very different way in 5.0.1, and we release noted it extensively. Unfortunately, distributions never bothered removing the patch, so the broken behavior continued. So you go to all the effort of finding the bug, and documenting the correct fix etc. ... but don't bother to spend 5 minutes opening a distro. bug saying "X is the wrong fix, this is the upstream fix".
(Log in to post comments)
Re: Packaging and patching Posted Aug 24, 2009 10:56 UTC (Mon) by rlk (guest, #47505) [Link]
There are far more distributions than there are developers. We release Gutenprint as a source package. We don't know everyone who distributes Gutenprint, nor what patches they apply, until somebody complains. Meanwhile, everyone who doesn't complain thinks Gutenprint is buggy because of things like this.
Re: Packaging and patching Posted Aug 24, 2009 15:26 UTC (Mon) by mcopple (guest, #2920) [Link]
quoth:
So you go to all the effort of finding the bug, and documenting the correct fix etc. ... but don't bother to spend 5 minutes opening a distro. bug saying "X is the wrong fix, this is the upstream fix".
-------
It seems to me that the correct workflow would be for downstream packagers / maintainers to discipline themselves to check for upstream changes on a regular basis, rather than relying on upstream to figure out who is packaging their product and notify.
It is incumbent on the upstream developer to have channels available to get the word out -- a developer's list, a bug tracking system, release notes, etc. But it is not reasonable to expect upstream to check the bug trackers of all of the scores of active distributors out there.
Re: Packaging and patching Posted Aug 29, 2009 19:30 UTC (Sat) by dirtyepic (subscriber, #30178) [Link]
> It seems to me that the correct workflow would be for downstream packagers / maintainers to discipline themselves to check for upstream changes on a regular basis, rather than relying on upstream to figure out who is packaging their product and notify.
At the very least they should find the time to browse the release notes.
Re: Packaging and patching Posted Aug 24, 2009 17:20 UTC (Mon) by jimi (guest, #6655) [Link]
Quote:
So you go to all the effort of finding the bug, and documenting the correct fix etc. ... but don't bother to spend 5 minutes opening a distro. bug saying "X is the wrong fix, this is the upstream fix".
This is absolutely the wrong attitude and workflow pattern. The software developers should have no responsibility at all to file bugs to various distributors' mailing lists. The job of a distributor is to package the original source and optionally patch *and notify the upstream developers* of any bugs. This notification must go from distributor to developer, not the other way around. The article notes that Red Hat would have preferred that the perl guys had filed a bug in the Red Hat bug tracking system. That is completely the wrong expectation. It is Red Hat who should possibly be filing bugs, not the other way around.
There is a possible exception to this rule: when the upstream developers are unreachable. In that case the distributor may choose to become the new maintainers of the software.
Re: Packaging and patching Posted Aug 24, 2009 17:52 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
among other things, you can't expect the upstream developers to run every distro that exists to be able to test them.
Re: Packaging and patching Posted Aug 24, 2009 18:41 UTC (Mon) by nevyn (subscriber, #33129) [Link] So you go to all the effort of finding the bug, and documenting the correct fix etc. ... but don't bother to spend 5 minutes opening a distro. bug saying "X is the wrong fix, this is the upstream fix".This is absolutely the wrong attitude and workflow pattern. The software developers should have no responsibility at all to file bugs to various distributors' mailing lists. The job of a distributor is to package the original source and optionally patch *and notify the upstream developers* of any bugs. This notification must go from distributor to developer, not the other way around. FFS, read what I wrote. Upstream had already seen the patch the distro. did ... and added release notes about how they'd fixed it differently (to stop other problems). But couldn't spend the couple of minutes directly telling the distro? ... and this is the distros. fault for "not doing it's job". I think not. But in the general case ... Yes, in a software developers perfect world they'd release upstream code full of "features". Distros. would then fix everything for them, and spend huge amounts of time rewritting those patches to make the developers happy while they spend their time adding more features. Back in the real world packagers are often only spending a fraction of their time doing packaging, often among a bunch of packages, so that "blah install random-crack" works. They aren't unpaid upstream minions, and they sure as hell aren't paid for their "job". Yes, they are hopefully following development in some way, but they are still unpaid humans and can easily miss things. On the other side upstream developers are often spending a majority of their time on a 1-3 projects. So those upstream developers spending an hour a month or so to make sure the packaging in (at least) the major distros. isn't broken in some way, doesn't seem like too much to ask IMNSO. And, yeh, for larger projects (like perl) you might expect that the distros. have more resources to put towards upstream ... but at the same time upstream will often have lots more resources to look downstream.
Re: Packaging and patching Posted Aug 25, 2009 0:10 UTC (Tue) by rlk (guest, #47505) [Link]
In this particular case (the Gutenprint issue) I did report it to my contact at the particular distribution I use. He ack'ed it, but it still didn't get changed. I only found out much later that this particular hack got propagated to other distributions. It wasn't a packaging problem, by the way. It was a badly conceived patch -- more like the Debian OpenSSL debacle than the Perl issue.
Checking all of the major distributions -- let's say, Fedora, Ubuntu, OpenSUSE, Debian unstable, Mandriva -- is a lot of work. It also means having the disks to do a lot of installations, the time to spend downloading the latest bits, the time to run tests, and so forth. No, this isn't practical.
Our automated test suite wouldn't have caught this in any case, since the problem was that the definition of letter and A4 paper was changed in a way that's legal within Gutenprint (and would therefore not fail functional and regression testing) but which would yield unexpected results.
The interaction I would have preferred is:
* Distributor files a bug/complains on the -devel mailing list that the behavior is unacceptable.
* We reply that it's behaving as designed.
* Distributor says "well, maybe so, but but it's still broken and we need to do something about it."
* Maybe we figure out the ultimate solution and get a fix in time for the next release (in which case everyone's happy) or maybe not, and distributor proposes the particular hack they actually did. More likely the latter, since the ultimate fix needed quite a bit of testing to get right.
* Distributor probably decides, after discussion, to accept that borderless printing won't work to those paper sizes and tells us that they're going to release with it. We suggest that they release note what's going on and keep checking back for a real fix.
* We get the fix out a bit quicker than we ultimately did, since we realize how critical it is in the real world; distributor picks it up and either patches the current release or at least makes sure the next release has the real fix (without applying the bogus patch again).
Re: Packaging and patching Posted Aug 27, 2009 7:42 UTC (Thu) by job (guest, #670) [Link]
I expect a package maintainer to have a clue what changes went into the package they maintain. At least for security reasons, so when upstream gets hacked and/or goes crazy and inserts malware in the code it gets caught.
Otherwise all security that surround distributions is for nothing if they package whatever comes upstream (via unsecured FTP sites and whatever).
Not even reading the release notes is in my opinion very far from having a clue what changes are applied!
|
|||||||||||||