On Mon, 03 Mar 2008 00:31:47 -0500 Tom Lane <tgl@xxxxxxxxxx> wrote: > Josh Boyer <jwboyer@xxxxxxxxx> writes: > > Tom Lane <tgl@xxxxxxxxxx> wrote: > >> As for the other points, if we can't provide (and document) the > >> ability for developers to test on a secondary arch, that arch > >> needs to be removed from Fedora completely. It's useless to > >> expect developers to magically fix things they can't debug. > > > PPC is not a secondary architecture at this time, so perhaps > > that's where you are confused. > > If it's not a secondary architecture, then the poor state of the > infrastructure for it is even more inexcusable. We should have more > than one test machine available, and how to get at them should be > documented in some more obvious place than the archives of this list It's not in a poor state. I will agree we should document how to get an account on a ppc64 box on the wiki somewhere though. > (which so far as I'm aware we don't even offer search facilities for). > Random people occasionally offering machines by means of the mailing > list is not what I call an organized infrastructure. At minimum there > needs to be easily-findable information on the fedoraproject wiki about > how to obtain access to test machines. Where are the test machines for x86_64 documented at? I don't have one of those and there are no publicly available test machines that I know of. I guess x86_64 should be dropped to. > As for > > > That's horseshit. Complete and utter horseshit. If the primary > > package maintainer doesn't care about a particular secondary > > architecture then it's no skin off their nose to simply ignore it. > > I'm going to call horseshit on you. Portability problems are frequently > deep enough to require the skills of the primary package maintainer, That depends on your definition of "primary package maintainer". We have several in Fedora who are excellent at packaging, and weak in the areas of programming. > or even the key upstream developers. I think that a secondary arch's Yes, upstream should always be involved in these cases. That has little bearing on this conversation. > SIG can probably be expected to detect portability issues, but > asking them to take full responsibility for solving them is a project > design doomed to failure. Even more to the point, portability bugs Why? The arch team is the one with the interest, skills, and machines. They should certainly be able to work with others to come to resolution, even if they can't fix it on their own. And if they can't do it and the primary package maintainer doesn't feel like fixing it, then an ExcludeArch is added and life goes on. As for some examples, David has fixed a large amount of issues despite the fact that he isn't the primary package maintainer. He even has OCaml almost working on ppc64 for some really odd reason. Spot has done Aurora Linux for a while now and is working on making Sparc the first true secondary arch. He certainly doesn't maintain all of the packages in Fedora. There are also s390, ia64, and ARM efforts under way. So I'm very skeptical of your "doomed to failure". > are usually "real" bugs, as was already noted upthread. Any > self-respecting package maintainer *should* be expected to take an > interest in them. But how can she, without access to test machines? > A secondary arch that can't provide developers with test machines > is not worth being taken seriously. You keep saying that, yet you're completely ignoring the fact that this is not specific to any particular machine type. Fedora, as a project, does not have publicly available test machines. We never have. Community members do, and they offer them up regularly. Even with the help of the community, you can't always allow $random_maintainer to test particular types of packages on a publicly available machine that's intended to be used by multiple people. That's why you have the arch team and volunteers. If you don't want to be part of all that, then that's OK. If you do, great. But please don't condemn the efforts of those making secondary architectures work. josh -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
