On Sun, Nov 27, 2011 at 12:01:53PM -0400, Joey Hess wrote: > Stefano Zacchiroli wrote: > > having worked quite a bit on "mediating" the wishes of Debian (as > > upstream) developers with those of downstream derivatives, I feel > > confident stating that many people in Debian would now welcome being > (I assume you made a significant typo --------> not)
I did indeed. s/not/now/ is a recurrent typo for me, but that doesn't make it less embarrassing (especially in this context). > Divergence in debhelper between debian derivatives results in packages > that will build in distro A but not in distro B, with no indication why > beyond a dh_ command being missing or not working as expected. This is > severely bad for the greater Debian ecosystem, to borrow a term. I agree with this. > I have pointed out this is a problem before, and have been roundly > ignored. I was not aware of this. Not that I should have been informed but, with your permission, I'd like to help now. My motivation to do that is that I believe having you ignore the two bugs we're discussing is bad for Debian, and not only for the so called ecosystem. Mind sharing with whom you pointed out the problem in the past? (even in private mail / IRC query, if you prefer) Still, I'd like to understand how we can avoid the problem in the future. The two bug logs we are discussing concerns apparmor and multi-arch. Both cases concern technologies that have been available first in a downstream distro and only then, and recently, in Debian. Would you have accepted to sign-off, and maybe even integrate, patches about stuff not in Debian yet? We have examples of that happening with Ubuntu, but the problem is more general that that; the higher the number of derivatives we have the higher the potential occurrence of these issues in the future. I think it's reasonable for you to ask to sign-off on debhelper changes, but we need: (1) your willingness to accept changes that are potentially not useful for Debian (yet), and (2) a way to inform derivatives of that. Recent work on the Derivatives Front Desk about a "Debian branding how to" can help with (2), but not with (1). > Note that if debhelper is NMUed, I will be stuck trying to maintain a > package that contains code that I have decided not to have anything to > do with. That could well end up being an impossible position for me to > continue maintaining debhelper in Debian. That would be very bad. It's a sort of catch 22. I'm sure nobody would want to lose you as debhelper maintainer. At the same time you're applying your right to ignore specific patches due to their *past* history. When the *present* of those patches is that they are useful and needed in Debian, for Debian needs, not for the need of a derivative who happened to ship them in the past. If you welcome an NMU, we have a way out of it. If you don't, I honestly don't see which way out Debian has, to get features we currently lack. Would a clean re-implementation do? It seems silly to even think of this as a way out when working code already exists, but it'd be better than nothing. Thanks for your feedback, Cheers. -- Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o . Maître de conférences ...... http://upsilon.cc/zack ...... . . o Debian Project Leader ....... @zack on identi.ca ....... o o o « the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature