random comments about secondary arch proposal

[David Woodhouse]

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.