On Wed, 2007-05-30 at 19:28 -0400, Christopher Blizzard wrote: > I think that this is the key question that we need to be asking here: > For what is a package maintainer actually responsible? Right now it's > just primary arches. The balance we have at the moment is working very well, and we should be very careful about messing with it -- especially if there isn't anything _specific_ we're trying to achieve. The package maintainer is responsible for bugs and stupidities in the package which _aren't_ arch-specific. Things like forgetting to byteswap where necessary, unconditional i386 inline asm without fallback to C, etc. The arch team pick it up when more arch-specific clue or porting work is required, with assistance and pointers from the package maintainer. More clueful maintainers can handle a little more; the less clueful fall back to filing a bug and calling in the arch team a little sooner -- some may even call in the arch team just to help whittle down a test case for a compiler bug report, But the balance works well. I'm very concerned that if we allow partially-failed packages to make it into the repo, even with an automatic bug filed, that will encourage the less conscientious maintainers to not even bother to _look_ at a failure which may also affect other architectures. And we get into a situation where it's considered 'normal' for some packages to be missing on some architectures without good reason. Also, the automatic bugs will lack the information which the arch team would want from the maintainer about what's going on, anyway. Letting the package maintainer file the bug for herself retrospectively would be OK -- at least they know they need to look into it. And the packages would be available in koji _immediately_; it's just that they don't get into the _repository_ until they're "committed" by being either built or 'excused' on all the architectures they were built for. > Do we want to add a lot of secondary arches right > now and make lives harder for people? What are those two questions doing in the same sentence? Do you think that adding new architectures will make life harder for people? Why do you think that? Adding the arch in the first place should involve _no_ work for the package maintainers -- the arch team would presumably do a full build of all packages in advance, to 'seed' the build system. Any package which doesn't work should already have an ExcludeArch: added before the new architecture is added to the build system. So it's only a potential issue for new packages, or old packages which later develop a bug or start to trip over a compiler bug. It's hardly difficult to get ExcludeArch: or ExclusiveArch: right when introducing a new package -- that effort is _trivial_ in comparison to the other hoops you need to jump through to make a review-worthy package. And in fact is already listed as one of the things to be checked in the review, is it not? So that leaves just the bugs which affect updates to existing packages that used to work... and a competent package maintainer should be looking through the logs and diagnosing the failure there _anyway_, because it might not be something arch-specific; it could be something which just _happens_ to bite more often on a multi-way SMP system, for example. The 'extra' effort of filing a retrospective 'ExcludeArch' bug explaining the failure is minimal, and that's _all_ that would be required to allow the affected package to proceed through into the repository. So where did this nonsense about 'mak[ing] lives harder for people' come from? Do you really have such a low opinion of our package maintainers that you think they'll be scared off by the requirement to file a bug when they encounter a build failure which seems to be arch-specific and is beyond their capabilities? -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
