Colin Walters wrote: > On Wed, Feb 18, 2009 at 9:30 PM, Toshio Kuratomi <a.badger@xxxxxxxxx> wrote: >> Fedora derives its >> contributor base from the fact that there are many people who are each >> willing and enthusiastic about working on different things. As much as >> possible, we should be attempting to get these people to interact and >> work on their projects inside of Fedora even when the goals conflict >> with each other. > > I like this paragraph a lot (and the (snipped) next one which is an > elaboration), and I agree largely. My point is really that I do not > think "all software now in RPM format" is a goal. It's a *means* to > various goals, such as providing developer tools, games, and yes, > multiple desktop environments. > I can agree with this. Fedora should not measure its worth by saying we have more software packaged than Foo Distro but less than Bar Distro. Everybody, package more! OTOH, Fedora contributors can measure the worthwhileness of contributing to Fedora by whether they can get the stack of packages they care about into Fedora. So my picture of this is while we don't want to encourage packaging software purely for the sake of packaging, we also don't want to discourage packaging because it conflicts with other, established subprojects. > But as you go farther down the stack, things get less pluggable, > conflicts increase, impact on the surrounding ecosystem increases. > And I think it's absolutely reasonable to expect (and receive) > pushback. > Somewhat. I think it's reasonable for people to disagree. However, I'm not sure if we agree on the definition of pushback. Let's say that someone wants to replace Xorg with Yorg, a new windowing system that makes users happy by feeding them crack. None of our existing X apps will work on Yorg. However, they can be ported with a bit of coding effort and upstream has patches for a few necessary apps like the mozilla suite, openoffice, and xterm. Do we allow Yorg in? Do we allow rebuilt versions of the apps where an upstreamed compile time flag has switched from --enable-xorg => --enable-yorg? Do we allow patched rebuilds of the apps where the patch is not upstream? I think that this is an area where we have competing interests. One of our goals in Fedora is to push the technological envelope. An actively developed new windowing system that doesn't conflict with Xorg is definitely fulfilling that goal. So keeping Yorg out seems counter to our goals. But making Yorg useful puts a burden on our present maintainers as we need to keep two versions of some apps. Yorg can't prosper without some apps to work with. At the same time, who is going to pay the cost of maintaining the new versions, triaging bugs that may be misfiled against the Xorg or Yorg versions, etc? I think those questions need to be answered. But we can't go around outlawing them. If the new maintainers show up with a triage team ready to help, coders pushing changes upstream, etc, we need to adapt. >> Getting too focused on Fedora, the distribution, means that we might >> have a superior Desktop experience or a superior Server OS but it >> doesn't mean that we'll have a rich base of contributors who are willing >> to build new and imperfect software to replace the old and imperfect >> software that we currently run. > > Building new imperfect software to replace old imperfect software > doesn't sound very compelling to me... > And yet, that's our exactly what we do ;-) There's always bugs, always architectural inadequacies, always something that, in retrospect, should have been designed differently. Our hope is that new imperfections are less painful than the old ones... but they're always there. >> It doesn't mean that we'll continue to >> be innovative or willing to be on the cutting edge. It doesn't mean >> that we'll be able to attract a large and diverse group of active >> contributors. > > I agree we want to be accommodating. Up to a point. We have to draw > a line somewhere between "Let's support Fedora/HURD"[1] and "Here's a > patch to make the kernel panic if gnome-session isn't in the process > list". Where that line is is a matter of debate, and it's useful to > have, which in fact we are. > So if the line is drawn between "Fedora/HURD" and "kernel panic if gnome-session isn't in the process list", which are you saying would be acceptable? ;-) > I forgot to point out in an earlier message that there is precedent > for setting up barriers for low-level software, namely the Fedora 3rd > party kernel driver policy: > https://fedoraproject.org/wiki/KernelDriverPolicy > These are the criteria I remember about the kernel: 1) Loadable kernel modules have the same capabilities as the kernel itself. That means, loading a kernel module can do anything the kernel does. userspace apps, even setuid apps, don't have the same power. 2) If the kernel fails, then nothing works. If firefox fails, then people use epiphany. If gnome fails, people use kde. etc. 3) Kernel modules have a strict dependence on the kernel that is built. So building out of tree kernel modules needs to have infrastructure support to kick off rebuilds immediately when the kernel is rebuilt. Having different display managers has no such requirement. 4) Kernel modules are supposed to live in the kernel tree. They get many benefits from being there. Out of tree kernel modules are possible but not something that the upstream kernel supports. The interface between the kernel and modules is unstable. Different display managers don't have this dependence on each other. 5) Bugs filed against the kernel can't be relied upon when kernel modules are present since the kernel module could affect operation of the kernel in a totally different area. This is not the same as, but similar to bugs that might occur when an application doesn't function due to using a different display manager. So only one of the considerations applies here. > All I'm saying is that there should exist similar barriers for > components between the kernel and the desktop. > Looking at the reason for the kernel ban, I don't think the same justification for barriers exist in the specific case here. There could be other instances with more justification but we'd be better off discussing them when there's hard facts that we can compare and contrast against. It makes the stakes higher :-) > [1] And if you liked my reaction to new login managers... > I agree that Fedora/HURD is probably something I wouldn't support. However, I suspect my concerns are very different from yours. My reasoning is more infrastructural than policy based. Currently we don't have the knowledge-base or hardware to maintain, test, or even build HURD packages. Software would have to be coded and tested and kept running on the infrastructure side to make this a reality. Lots of work that no one's volunteered to do. -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
