On Wed, Jul 20, 2011 at 04:36:35PM +0000, Uoti Urpala wrote: > I think you're committing exactly the fallacy I described in the part you > snipped. You think that "excluding" people who want a particular kernel is > significant when it's a "big thing" like a kernel. But _any_ case of not > supporting something can be described as "exclusion". Any time a package is > dropped, Debian is "excluding" the people who want to use that package. Every > time a decision is made not to package something people are being "excluded". > When Debian Linux fails to run on a specific submodel X of hardware Y, people > who use that hardware are "excluded". Any of those cases can affect a much > larger number of people than kFreeBSD support.
I think the difference with excluding a package is that nobody is willing or able to do the work. Perhaps the package requires more time than the maintainer has, or it's a very difficult package to maintain and nobody that wants to is able to. In most cases, if a package is buggy on some platform, the porters will either fix it or exclude it from that platform. Nevertheless, we expect Essential packages to work on all of our systems. Since you're interested in changing the status quo (which init is the default), you're obligated to do most of the work to fix whatever breakage occurs. This is true for most FLOSS projects, including the Linux kernel, not just Debian. > If it were possible to support every use case and every piece of hardware then > things would be different. But it is not possible. You have to prioritize > things. And it is exactly the lack of a rational approach to this that I was > criticizing above. When a bug goes unfixed and that prevents a user from > achieving whatever goal he had, that is no better than someone being unable to > achieve what he wanted because kFreeBSD was not available (and in fact I'd say > the latter would typically be less severe, as the typical goal would be just > "play with kFreeBSD for its own sake"). The priority is based on who is willing to do the work. I submit patches to software I use if it is buggy because I want the bug fixed *now*, usually because it's impeding my immediate work. If it's that important to me, I have to take some responsibility for fixing it if that's within my capabilities. Many people find kFreeBSD important to them and have consequently done the work to bring it to fruition. It appears that people have stepped up to do the work to bring it to where it is. It also appears that Debian is keeping the FreeBSD kernel; the only safe assumption is that Debian will continue to do so at least for the immediate future. If having systemd as the default init in Debian is very important to you, you should probably put in the work to make it a viable choice for Essential. Right now, the portability problems make it not so. > Supporting things like kFreeBSD is a lot of effort to benefit few > people. If it's what a volunteer wants to work on then that is his > right. But to insist that others should work on it is wrong; > project-wide priorities should be based on rational decisions instead. > And to compare "support kFreeBSD" and "make Linux work well for a > larger number of people" and claim that kFreeBSD stands more for > "inclusion" is nothing but bullshit rhetoric. But here, the kFreeBSD porters (just like the porters, for say, sparc) have done most of the work. Yes, maintainers need to accept patches in some cases. But the porters do most of the work because that's what interests them or perhaps because their employers need that functionality or just because it's fun. It's not uncommon to see people maintain software or ports that they may already be using at work. The Kerberos maintainers are an excellent example here. Several HP people help maintain the ia64 port. And as long as their work within Debian is for the benefit of Debian, who cares? If a package simply cannot be used on kFreeBSD, then ok, that happens. Would it be nice if systemd were portable? Yes. But if we assume that it's not, then we have to accept that. The question here is whether we're effectively willing to make a non-portable package part of Essential. The question would be the same if systemd pervasively used unaligned accesses or inb/outb or some other non-portable construct. Would we jettison sparc and ia64 in favor of it? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
