QA process was Re: RPM submission procedure

[Karl DeBisschop]

On Fri, 2004-01-09 at 16:21, Michael Schwendt wrote:
> On Fri, 09 Jan 2004 14:20:16 -0500, Karl DeBisschop wrote:
> 
> > On Fri, 2004-01-09 at 13:59, Michael Schwendt wrote:
> > > On Fri, 9 Jan 2004 20:05:06 +0200 (EET), Panu Matilainen wrote:
> > > 
> > > > The amount of nitpicking trusted developers produce 
> > > > (among themselves) is enough to scare off anybody starting in packaging 
> > > > I'm willing to bet :)
> > > 
> > > This must change, although often it is separated between suggestions and
> > > blocker criteria. But at the same time, new packagers should not come
> > > with slightly modified packages from e.g. Mandrake Cooker which bzip2 even
> > > the smallest patch, or generic packages which contain dozens of lines of
> > > conditional code which tries to adapt to a build environment.
> > 
> > Is this rejection of generic packages official policy?
> 
> There is nothing like "rejection". Unless it's software which cannot be
> included due to patenting or licencing issues. 
> 
> But back to generic packages as described by me roughly, find someone
> who's willing to review them on a low level. It really is no fun to spend
> time on something which looks unnecessary. We build for Fedora Core (and
> Red Hat Linux) only, not for Distribution ABC which requires different
> packaging and which uses additional helper tools.
> 
> > Somehow it seems to me contrary to the idea that Fedora stresses
> > upstream bugfixes.
> 
> I fail to see the connection between a spec file mess and integrating
> bug-fixes upstream.

The connection is that I see an application that requires a mess to
package as broken. That brokenness should ideally be communicated
upstream so the developer can address if for the benefit of all distros.
When a packager's first choice is to create that spec file mess, rather
than work the developer to avoid it, the community as a whole is being
shortchanged. 

> Apart from that, not everything you ship upstream is included.

I don't see what you're getting at here. But I think we're more in
agreement than I thought at first, so it may not be worth dragging out.

> > I think of it this way: as a developer, I cannot possibly package well
> > for all distros, but I may be able to package well for the one or ones I
> > use heavily. Nonetheless, as a developer, I have to maintain the code in
> > single units that is readily packaged by many distros, not just the one
> > I happen to use.
> 
> Then -- as a developer -- make your software be trivial to package.

I agree fully with this.

And what I was trying to say is that feedback from the packagers should
help the developers do that. If the process of generating a package is
hard, then I want to know how to make it easier, so that the spec can be
trivial.

But if the packager viewpoint is completely ignorant of the fact that
the developer caters to many distros, then the developer gets at best
"do x for me, even if some other distro wants conflicting y"

As a developer, I want to make packaging as easy as possible across the
board. Which means I need to be able to support not only Fedora, even
that that is my distro of choice.

I was probably just picking up on a different emphasis. Where you said
'new packagers should not come with ... generic packages' I read that to
mean all distros should have very unique packages, and inferred that
would be at the expense of communication with the developer so that
unique distributions goals can be met with minimal added work at the
packaging end. But that doesn't seem to be what you're saying.

-- 
Karl DeBisschop <kdebisschop at alert.infoplease.com>
Pearson Education/Information Please