On Aug 26, 2013, at 2:51 PM, Per Øyvind Karlsen wrote:
> 2013/8/26 Jeffrey Johnson <n3...@me.com>
>
> On Aug 26, 2013, at 2:19 PM, Per Øyvind Karlsen wrote:
>
> > The following patch fixes querying rpmdb with wildcards, whereas without
> > this fix, it'll return all entries and not just those matching.
> >
>
> The issue of wildcard queries is/was discussed years ago when implemented,
> and the behavior
> implemented is/was as decided (for "legacy compatible" and "principle of
> least surprise" reasons)
> at the time.
>
> Discuss the feature, providing explicit usage cases and tests, under the
> existing CI framework
> if you wish the patch applied "upstream" @rpm5.org. I need to see
> "consensus", not "de facto",
> before enabling "wild hacks" (other than my own) in RPM releases.
> We actually discussed this one quite a while a ago, where you acknowledged it
> yourself (the regression were introduced here:
> http://rpm5.org/cvs/chngview?cn=16299 )
>
Everyone's opinions -- including mine -- change with experience.
Expecting me to remember and be consistent with a patch
from 2y ago that you claim is/was related to
rpm -qa \*foo\*
"regression" from a "wildcard" behavior that has never been specified, only de
facto,
when there are other non-feature related behaviors that are often in need of
fixing
is unwise.
The issue that needs consensus is whether
rpm -qa \*foo\*
is useful, particularly when there are other designed/planned/implemented
implicit switches to permit
rpm -qa "^.*foo.*"
i.e. your trivial reproducer is already a malformed *RE pattern, rather
a sloppy/foolish DWIM naive fuzz-busting query.
There already is a means
> I've provided you with a trivial reproducer, but considering the large amount
> of patches I have in queue, I don't really have the time nor that much
> incentive for starting on writing accompanying regression tests, especially
> not when I'm not overly existed about how the current regression tests are
> implemented/maintained, nor is my motivation for writing regression tests for
> (yet a bunch of) bug fix patches I maintain locally for a package.
> If commit access were restored, doing more of that kind maintenance work
> again would be of greater interest, but when not, I'm not very eager to take
> on responsibilities with the resulting tediousness..
>
> I personally have no interest in enabling foolish/sloppy queries on a random
> "feature" walk through
> patch streams of unknown viability, and poorly understood consequences,
> @rpm5.org, particularly
> when I am obligated to do the maintenance work to respond to future flaws and
> objections of other people's
> efforts.
>
> Last I heard you were too discouraged to undertake the reasonably sane
> effort(s) that
> are needed ... YMMV.
> And I'm now trying to, am I not? :)
At the time I replied, there was only a single patch in my mbox.
I am proceeding through your e-mails as rapidly as I can.
> Seriously speaking, a lot of things came up and in the way for things, but I
> will at least sporadically be trying to push all ~fixes for now, then get
> back to ~features etc. with blueprints provided and code cleaned up whenever
> I find the time. :)
>
> Short answer (which I have said many times already):
> A blueprint at http://launchpad.net/rpm is the starting point for new
> "feature" deployment.
> This isn't a feature, but rather a bug fix.
>
We disagree on what is a "bug" and what is a "feature" here. Which is why
I suggested an explicit blueprint rather than willy-nilly application of hacky
patches.
73 de Jeff
73 de Jeff
> --
> Regards,
> Per Øyvind
