Packaging quality, assistance.

[David Woodhouse]

On Wed, 2007-05-09 at 07:05 +0200, Thorsten Leemhuis wrote:
> Sorry, but if FESCo decides to kick a package from the repo against the
> will of the packager then it's IMHO FESCos responsibility to make sure
> that fact gets documented properly.

I hate to bring it up again, because I'm sure it'll make someone cry...
but I feel sure that if Zope had been an actively maintained Core
package, we wouldn't be having this discussion. It's been almost a year
since python 2.5b1 was first committed to CVS, and the maintainer
_would_ have made it work with python 2.5 in that time.

I am increasingly concerned by the discrepancy between 'Core' and
'Extras' in such matters -- and now that they're merged, we don't seem
to have the convenient distinction which has always before told me 'this
package should be taken with a pinch of salt'.

I filed bugs only a few days ago for another Extras package which just
dumps its files on the filesystem and doesn't bother to set up its own
dæmon with an xinet.d file, set up its web interface with files
in /etc/httpd/conf.d, etc. It's just a dump of the upstream package
without proper _Fedora_ maintenance.

We need some way to help out with this kind of thing. Obviously I do it
for anything related to ppc (and now ppc64)¹, and I'll poke at other
things I care about or that people ask me to help with. If think we need
much more of that².

Perhaps we just need a way to encourage and help packagers in need of
assistance to get in touch with others who can help them? A kind of
'packaging SWAT team'? :)

I'm not sure how it would work best -- perhaps an 'assistance required'
tracker bug which the 'hard' bug can be made to block? Or just a mailing
list where assistance can be solicited?

We need to strike a balance between quality and quantity -- I appreciate
it's nice if every man and his dog can submit any package for they can
manage to cobble together a specfile, but what if they can't actually
understand any of the code, can't deal with any of the bugs, and can't
make it work as a coherent part of the Fedora distribution?

As well as making it easier to find help, perhaps there's something to
be said for expecting the sponsors to co-own packages and help keep
track of bugs in the cases where the owner needs a little extra
assistance? I've seen basic 32/64-bit compatibility bugs closed with a
comment about not understanding the code and just waiting for upstream
-- that _really_ needs to be avoided.

-- 
dwmw2

¹ Actually that's only necessarily true for bugs which end up on the
  FE-ExcludeArch-ppc{64,} tracker. If a package just has certain
  functionality disabled, it might not come to my attention unless the
  packager is conscientious enough to seek assistance.

² To make sure I don't accidentally make anyone cry, I should point out
  the blindingly obvious fact that I'm not the only one -- there are
  plenty of other people who _are_ very capable and willing to help with
  packages belonging to others, and who also help out when problems come
  to their attention.