Summary/Minutes from today's FESCo meeting (2014-10-15 at 17UTC)

Jerry James loganjerry at
Wed Oct 15 19:32:50 UTC 2014

On Wed, Oct 15, 2014 at 12:54 PM, Kevin Fenzi <kevin at> wrote:
> * #1350 Updates Policy should require inter-dependent packages be
>   submitted together  (nirik, 18:15:37)
>   * LINK:   (nirik, 18:15:38)
>   * AGREED: Make policy changes now, defer enforcement until later
>     (+6,0,0)  (nirik, 18:30:03)

That ticket has already been closed, so I will comment here.  Say that
I have a package that I want to update, the update breaks somebody
else's package, and I lack the knowledge to fix that other package.
How much waiting for the other maintainer am I required to undergo?
The discussion on the ticket implies that the answer is "an infinite
amount of time".  Is that really the intent?  Let me present two cases
where I think "an infinite amount of time" is the wrong answer.

The first case is when a non-critpath package depends on a critpath
package.  I've got a concrete example.  I maintain the polymake
package.  It has its hooks buried deeply into the guts of perl, so it
depends on the exact perl version it was built with.  Every major perl
release, without fail, breaks polymake.  Sometimes upstream has
already noticed and I can update to the latest snapshot to fix the
problem.  Sometimes upstream has not noticed and I have to ask them to
produce a fix, which can sometimes take a little while.  If a critical
perl update were needed, say to fix a glaring performance or security
problem, and the update broke the polymake build, I think the right
thing to do would be to push the perl update anyway.  That will break
things for me and both of the other people who use polymake (hi,
guys!), but too bad for us.  We can fix polymake as quickly as we can
and get things back to normal, but we shouldn't block that update from
going out to all of the people who need it.

The second case is hypothetical, although it is loosely based on an
actual situation I encountered a couple of years ago.  Say that I want
to push a non-backwards-compatible update to a library, and that
packages A, B, and C depend on that library.  I rebuild A and B
successfully with the new version of the library, but C fails to
rebuild.  I try to diagnose the problem, but find that C is such a
horrible mass of spaghetti that I can't make heads or tails out of it.
So I file a bug against C and wait for the maintainer to respond.  And
wait.  And wait.  And wait.  At what point am I allowed to push the
new version of the library, along with A and B rebuilds, and write C
off as a loss, since I can't fix it and the maintainer isn't
responding?  Does it depend on the severity of the problem the update
is intended to fix?  If so, who is the judge of degree of severity?
Jerry James

More information about the devel mailing list