Date: Thu, 29 Apr 2010 15:41:48 +0200 (CEST)
Subject: Re: (ITS#6540) test022-ppolicy is flawed,
masks serious stability issue
From: masarati(a)aero.polimi.it
To: ryans(a)aweber.com
Cc: openldap-its(a)openldap.org
Let me first explain one thing. If you have one problem and you don't
have time to rebuild from source, then it's very likely you'll have to
live with your problem.
Yeah, I don't have a problem with rebuilding from source. Even with a patch, that
would have to be done. I was just
trying to, in the interest of urgency, avoid having to rebuild from 100% brand new source,
instead of being able to
patch the relevant code and tests and rebuild from that codebase. This would preclude
having to worry about
distinguishing new problems from the existing problem, or diagnosing and fixing additional
and unrelated problems along
the way, making it potentially easier isolate the issue.
The only difference between you and me is that if I find a solution,
I
can commit the fix. For the rest, your time is valuable exactly as
mine, and I probably get paid less than you get paid, but to fix my
problems, not yours.
Sure, but in this kind of scenario, aren't they one and the same? The burden of
identifying and fixing bugs in the code
is (in spirit, at least, unless there is a contract or legally binding agreement involved)
shared by both developers and
community users as we strive towards a common goal, although the nature of the
responsibility varies to some degree. I
agree, however, that in most circumstances the contributions made by community members and
developers are of their own
volition and centric to, if not completely predicated upon, their needs and interests.
Because commits do necessitate developer involvement and thus ultimately depend on the
allocation of their limited and
valuable time, it is my belief that community users bear some responsibility in this
process to help reduce the load on
the developers, and should exercise due diligence when submitting ITS's and
contributing to their solutions. Up to this
point, I have tried to adhere to this self-subscribed policy as best as I can for this
ITS, and am more than happy to
contribute wherever possible, especially on things for which a seasoned OpenLDAP
developer's experience and knowledge
are a less important pre-requisite (like patching test022-ppolicy, or documentation, for
example). So, please let me
know if there's anything I can do to help facilitate this process. I know that nobody
here is obligated, nor are their
services free, so all time and effort expended is very valuable and highly appreciated - I
can't stress any of those
points enough!
Also, completely OT but with respect to the 'salary' comment, if you're not
getting paid at least as well or more than I
am to teach aerospace engineering, it is a shame, but not all that surprising. Nobody in
academia (at least in the
United States) seems to get paid nearly what they're worth, regardless of the position
(grade school teacher like my
wife, or university professor such as yourself) or the degree of difficulty of the
subject. We grumble about it every
so often in our household - but I digress...
It just happened that tracking someone's issue, upgrading just
solved
it (ITS#6537, which ended up being a duplicate of another, already
solved issue). In order to save the very scarce, unpaid manpower we
can dedicate to fixing others' issues, our policy is to avoid tracking
issues in old releases, because we don't backport fixes so, in the best
case, the issue will be solved in the next one, and you'll have to
upgrade anyway.
Sure, and that's why I did my very best to review the source, and verify that the
changelogs, diffs, and source relevant
to the behavior had remained unchanged. But I submit that even with the most painstaking
and diligent scrutiny of the
code, it still holds true that "the proof is in the pudding", and few test are
more ironclad than actually building the
newest source and comparing the behavior. I did actually rebuild slapd this morning as
requested, though, and still had
the same issue (2.4.22), but when I went to update the ticket, I saw that you had already
confirmed what I suspected
prior to doing so.
After this lengthy preamble, thanks to your prompt response I
already
figured out myself how to reproduce the issue you're having, so you don't
need to rebuild yet. You'll have to as soon as the issue is fixed.
Great, many thanks for your efforts in confirming. Just out of curiosity, when the fix is
actually committed, will the
commit number or source code file be present in the ITS, so that one can easily
cross-reference the ITS with a
particular file or set of files from CVS HEAD? And again, please let me know if
there's anything I can do to help
facilitate the process, or make it easier for you and/or the other developers. I'm
happy to test, patch the test
scripts, et cetera.
-Ryan
p.
> It is also bears mentioning that test022-ppolicy has not changed at all
> since 2.4.18, and so would never detect this
> problem, even using the most recent stable version. As I mentioned,
> ldapsearch does not trigger any errors - only
> slapcat does (and of course, starting slapd, which fails as is detailed
> above).
>
>
> If you really want to test this, you must restart the server on which the
> chaining configuration from test022-ppolicy
> has been added, and then run slapcat. I am not the only one to run in to
> this; for example, this individual has the
> exact same issue, with no resolution:
>
http://www.openldap.org/lists/openldap-software/200907/msg00118.html
>
>
> I'd be more than happy to patch the source, if such a patch existed. But
> since nothing seems to have changed in the
> relevant bits of code that would affect this behavior, and no
> corresponding ITS exists, that would lead me to believe it
> is thusly undocumented, except for similar on-list complaints. If you can
> show me where in the back-ldap code you
> believe I've missed said patch or refactoring, I've got no problem
> admitting I missed it, but I don't see any such
> modification(s).
>
>
> I'm sure not everybody has the time to build from completely new source
> every time a bug is unearthed, and while I do
> not object to doing that as soon as I can, right now I have a slapd server
> that is down because of this, so top priority
> is to evaluate the code to figure out where this bug is stemming from and
> fix it so I can restart slapd. Next priority
> is building and testing new packages. I mean no disrespect by this, but
> dropping everything to do this and work out any
> new issues, bugs, and compatibility problems and separate those from this
> pre-existing buggy behavior, seems hasty at
> best, especially when there's no concretely identified reason for doing so
> (i.e., this revision had change X, which
> fixes problem Y).
>
>
> I'm still reviewing the relevant code (which AFAICT hasn't changed) to
> figure out what's going on here and put out the
> immediate fire so that I can at least restore services, at which point I
> will obviously have to make the time to
> completely upgrade it all.
>
> Thanks
>