> It sounds strange, but I will already get problems with the needed changes > for Hurd support without such conflicts. It may sound strange, but for some > developers, porters seem to be second class citiziens. I am a bit afraid > that Hurd people will be considered third class citizens, if we try too > strongly to move Linux in direction of the Hurd.
I don't think there is any need for there to be conflict or great apprehension. We have no desire to make life harder for anyone in the Debian project. > For example, I am already getting snipping comments about the fact that I > submitted a bug report with patches to add better cross compilation support. > (#31795), and this although the patches are completely backward compatible, > and cross compilation is very reliable on the Hurd (in fact, what we do can > hardly be called cross compilation). Well, I won't try to comment on specific details I don't know about. But I'm sure there is a way these issues can be raised that will not be offensive to at least the majority of the debian community. Broadening the technical flexibility of debian and its tools should certainly not be a generically inflammatory issue! One can naturally understand many developers' trepidation at making any fundamental changes to things that work. I see no need for we debian-hurd folks to press in any way for such changes to be rolled in to a mainline debian package in the short term if its maintainer's conservatism balks at the prospect. It should not be difficult to have simple hurd-specific diffs to apply to mainline packages to produce the hurd packages for these cases. Likewise, I would not press including changes in the mainline debian tools if people in the debian community are uncomfortable with it. We can continue to make separate patched packages available to be used for debian-hurd and to demonstrate our ideas about changing the tools or package structures. This experimentation and engineering in the interests of generalized future utility, and of practical use for debian-hurd, need not be a contentious thing. We don't attempt to impose it on anyone; we offer it as solutions we have tried for problems we have encountered. If debian is the open and well-spirited community I believe it to be, then I'm sure that discussions about ideas for future changes in debian and its tools, and experimental implementations of those ideas, will not be offensive to the community! The hurd team and the debian-hurd volunteers are certainly more than open to discussion and other views on these issues. I think Gordon has been diligently deferential and noninflammatory hitherto and will be very open to all voices in the debian community responding to the ideas he wants to represent. Myself, I don't have the time or the inclination (or probably the temperament) to figure out a lot of these issues about debian-hurd, and while I have occasional opinions to offer, mostly choose to defer to the consensus of the other volunteers to hash these things out. I don't think any of us want to press against resistance to have changes in tools or packages, or changes in debian policy, made before the next major revision, or force our decisions on anyone. We are just floating ideas for the future, and discussing the problems we are encountering and the ones we foresee.
