QA process was Re: RPM submission procedure

[Michael Schwendt]

On Fri, 09 Jan 2004 16:57:34 -0500, Karl DeBisschop wrote:

> > 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. 

I've killed some quotes deliberately because they haven't help in avoiding
a misunderstanding. In my original comment on "generic packages" I refer
to spec files which attempt at getting it right for more than a specific
distribution. With "spec file mess" I refer to them using lots of %define
constants or macros to be set manually, lots of conditional code to do
some things differently for different distributions and an additional
multitude of conditional %_with/%_without checks to build the package in a
variety of configurations. While the latter may be useful for some users,
the rest is just bloat, a "mess" that is not fun to review, especially not
when patches are bzipped or if conditional code is also in %post scriplets
[and calls distribution-specific helper tools] and if it takes extra
effort to see *how* the software is built.

> > 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.

Patches, patches, patches, but also packaging style. Distributors apply
some customizations, improvements, tweaks and integration work which an
upstream maintainer would reject to include by default. With regard to
spec files, some upstream maintainers would also insist on modifying
contributed spec files in a way they find "smart" or elegant, but which
would obfuscate the packaging (e.g. generated %files lists, overuse of
macros, heavy inline creation of extra files within spec files, ...).

> > > 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.

That would not solve the problem of the "packager freak" who loves to turn
his spec file into a little uncommented program and who does enough
lobbying to get his spec file included as the upstream default.
 
> 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.

But that means that you may need to spend additional time on tweaking your
"configure" scripts and aclocal code to deal with possible detection of
differences between distributions. Something developers with a "works for
me" mentality would rather avoid, in particular if they don't like other
distributions. It ends with them accepting contributed patches
reluctantly, if at all.

--