submitted RPMs and awaiting action?

[Michael Schwendt]

On Tue, 1 Dec 2015 22:16:09 -0600, Ranjan Maitra wrote:

> > Have you run the fedora-review tool on your packages and/or bugzilla
> > review tickets yet?  
> 
> I have not run the fedora-review tool, but I did run the koji build tool (some time ago and even now, on f22, f23, rawhide) and it passed for both packages. Is this not adequate?
> 

No. It's not sufficient that something "seems to build". It must be
verified that the source code is configured correctly and compiled with
right options, too, in order to activate security related protections
and to generate a usable -debuginfo package, for example.

Yesterday I ran into a review request that packaged a precompiled
executable, which perhaps did not even match the source files and could
contain a trojan/backdoor/whatever.

> > > It sort of defeats the purpose of Linux.  
> 
> > Please elaborate. What do you have in mind here?  
> Simply that niche packages are going to be in less demand and would hurt those users who have unusual likes. Not every one should have to be a programmer to want stuff that they would like to use. Sylfilter, for instance, is extremely lightweight, and does an extremely good job. I have packaged it for my use, but others may find the hurdle too high to compile from source or to evaluate a package submitted to BZ.
> 

I don't think that users find the very common

  ./configure && make && make install

sequence of commands too difficult.

Everywhere you can meet users of a distribution that ships prebuilt
packages, and still they run their self-compiled software. Even if only to
get the very latest minor version of something.

Packaging that up is a bit more difficult. Sure.
And package maintenance then increases the difficulty even further.

It could be that some of those, who manage to create packages, would
benefit from a playing ground where they could offer their packages and
get feedback from actual users. Based on that they could improve their
skills, their packages, and advance to maintainers of those packages.
I'm just not sure a real dumping ground will shine. It reminds me too
much of Red Hat's old contrib.redhat.com FTP server where people uploaded
the weirdest contents without any peer review. That increases the risks
for users too much, too.

> But the packager is only responsible for the packaging, generally not
> for upstream issues. I tend to think that most of the issues I have
> found are from upstream.

Still upstream needs to be informed about those issues. And it might be
that the software is miscompiled or that it's a dependency that's broken.
Watch all those cases where upstream cannot reproduce the problem.

*Somebody* needs to investigate the problem *and* respond to bug reports,
too. It just doesn't work, if users file bug reports and nobody responds.
That is reason #1 for many a user to leave frustrated and look into
trying out a different product.