On Fri, 2007-06-15 at 11:43 +0200, Thorsten Leemhuis wrote: > > On 14.06.2007 19:40, Christopher Blizzard wrote: > > > Primary arch definition: need to make sure that part of the > > responsibility is that individual maintainers are required to make sure > > their stuff builds on all those arches. > > -1 -- Fedora Extras had lots of maintainers that are no programmers > and/or have only access to i386. > > Those maintainers are Fedora maintainers these days. Saying they are > "required to make sure their stuff builds on all primary arches" would > increase the burden on the maintainer drastically. I think that's > totally the wrong way forward. I actually think it's the _right_ way forward. I think it's a really bad thing that we're letting people package and 'maintain' code which they don't even understand, and for which they can't handle bug reports. And we're shipping those packages with the 'Fedora' brand on them. I recently ditched the bluez-gnome package because I can only be a package-monkey for gnome/dbus stuff, and I just don't think it's right for me to be responsible for it in Fedora. But that doesn't seem to be the prevailing opinion, so I suppose we have to deal with the situation we have... You're right -- as things stand, we do need a team of folks who can help out with basic issues where the packager can't cope. It usually isn't arch-specific; very little really is when you get down to it. I actually think the primary responsibility for such a packager should be with his/her sponsor. If you sponsor someone who doesn't even know the language their package is written in, then _you_ should be expected to make sure the package is being looked after in a fashion which makes it acceptable for Fedora. Could the sponsor be listed as the 'QA contact' in bugzilla for these packages? Obviously, a team of people who can help out is also useful, but it's good for the packager to have a single point of contact; someone who's "on the hook" to help them out and/or redirect them to someone who knows best about whatever specific problem they're looking at. > Further: if I would read something like that before becoming a > contributor I'd say "hey, that's hard stuff; I know my knowledge is not > enough to do that should I even run into a situation where something > doesn't build on PPC; well, then I won't become a contributor for > Fedora. Have fun guys, bye". As long as they're willing to learn, and they'll _become_ capable of basic package maintenance in time, I agree that it's best not to turn them away. If they're _never_ going to learn, then we run the risk of sacrificing quality for quantity; I'm very wary of that approach. And it's not just "...should I ever run into a situation where something doesn't build on PPC". It's "...should I ever run into a bug which is hard to find and fix". The 'doesn't build on $ARCH' bugs are generally either arch-specific bugs which such a packager could use ExcludeArch for and call in the ArchTeam, or more often than not they're actually _generic_ bugs which just happen to get tickled on that arch first. And yes, that kind of hard-to-reproduce bug is usually the 'hard' kind, but it doesn't necessarily require much arch-specific knowledge. Just a clue and a lot of coffee. -- dwmw2 ¹ other than new ports and 'IBM made us break it', as I said before. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
