Bug#614731: Bug#649784: add dh_apparmor for easier AppArmor profile management
On Wed, Nov 23, 2011 at 07:08:04PM -0400, Joey Hess wrote:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=82;bug=614731
I have a new policy: Once Ubuntu applies a patch to software I wrote,
without allowing me to sign off on it[1], I will no longer apply that
patch to the upstream source of the package. By doing this, over and over
again, Ubuntu is implicitly saying that they do not value my work, my
expertese, or the time I would need to spend to deal with fallout of
their changes, and so I simply choose to ignore them in return.
Heya Joey,
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
asked (some people would even say bothered, I suspect) to sign off
changes that derivatives intend to apply.
I understand and respect your desire here, but please understand that
it'd probably not be a reasonable default. Or at least not a flame-free
one.
The closest approximation of it I could imagine is that derivatives
developers will submit to Debian patches they have applied, as merge
requests (which, AFAICT, it's what Kees is doing here). Of course doing
so will open up to the risk of seeing their changes rejected, but that
would be already way better than being ignored all together. I also
think it'd also be better for Debian, but that's probably a subjective
matter.
So, to improve for the future:
- how would you like to be asked to sign-off changes by downstream
developers? mail to the maintainer or wishlist bug report?
I'll be happy to check with derivatives people how they can keep track
of which Debian maintainer wishes this kind of interaction and who
don't want to be bothered (honestly, I see no other sane default for
such a dilemma)
So, if Debian feels it is appropriate for this bug to be fixed,
someone will need to NMU debhelper.
That helps, thanks. I've seen that on #debian-devel people where
interested in picking up your availability for this also for #614731,
maybe a single NMU could do? I suggest that NMU-ers use a reasonably
DELAYED/XX queue, so that you get a chance to review and, if you feel
like, comment on it before it's final.
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
Bug#614731: Bug#649784: add dh_apparmor for easier AppArmor profile management
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) asked (some people would even say bothered, I suspect) to sign off changes that derivatives intend to apply. 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 have pointed out this is a problem before, and have been roundly ignored. I have no interest in supporting distributions who introduce such problems, and no remaining tolerance for divergent changes to debhelper. That helps, thanks. I've seen that on #debian-devel people where interested in picking up your availability for this also for #614731, maybe a single NMU could do? I suggest that NMU-ers use a reasonably DELAYED/XX queue, so that you get a chance to review and, if you feel like, comment on it before it's final. 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. -- see shy jo signature.asc Description: Digital signature
Bug#614731: Bug#649784: add dh_apparmor for easier AppArmor profile management
Stefano Zacchiroli wrote: 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. I appreciate what you're trying to do, but I simply have no interest in trying to deal with these problems further. I hope that whatever Debian decides to do lets me continue to maintain debhelper in Debian. 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. No, because my issue is not with the code but with Ubuntu continally forcing Debian to accede to their changes or risk horrible divergence. As we also saw with dpkg triggers, etc. -- see shy jo signature.asc Description: Digital signature
