https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7982
--- Comment #18 from Henrik Krohns ---
(In reply to Sidney Markowitz from comment #17)
> Along those lines, I would really like it if someone could look at
> sql_based_welcomelist.t and figure out how to make it dependent on much
> fewer
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7982
--- Comment #17 from Sidney Markowitz ---
Answering in reverse order:
(In reply to Henrik Krohns from comment #16)
> we should stop SATest.pm from copying any cf from trunk/rules at all
That's something I was already considering while
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7982
--- Comment #16 from Henrik Krohns ---
And if you/we want to go with the 01_test_rules.cf route, when we should stop
SATest.pm from copying any cf from trunk/rules at all. Then is it's 100% clear
that tests only use something from
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7982
--- Comment #15 from Henrik Krohns ---
(In reply to Sidney Markowitz from comment #14)
> Ok, the real problem seems to be frustratingly simple.
>
> t/SATest.pm uses t/data/01_test_rules.cf for its rules so it does not have
> to depend on
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7982
--- Comment #14 from Sidney Markowitz ---
Ok, the real problem seems to be frustratingly simple.
t/SATest.pm uses t/data/01_test_rules.cf for its rules so it does not have to
depend on the ever changing contents of rules. When running in a
On 2022-05-01 at 16:33:13 UTC-0400 (Sun, 1 May 2022 16:33:13 -0400)
Kevin A. McGrail
is rumored to have said:
On 5/1/2022 4:12 PM, Michael Storz wrote:
Kevin, the change from 'return undef' to "return" is correct because
return returns undef in the scalar context. "return undef" should
only
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7982
--- Comment #13 from Sidney Markowitz ---
(In reply to Kevin A. McGrail from comment #12)
> Primarily, I would likely look at what changed between 3.4.6 and 4.0
I can do that. I do think it would be much simpler all around if the tests did
On 5/1/2022 4:12 PM, Michael Storz wrote:
Kevin, the change from 'return undef' to "return" is correct because
return returns undef in the scalar context. "return undef" should only
be used when evaluated in the array context and the value undef is
needed instead of ().
I only looked at the
Am 2022-05-01 20:02, schrieb Kevin A. McGrail:
On 5/1/2022 1:28 PM, Michael Storz wrote:
Am 2022-05-01 18:22, schrieb Kevin A. McGrail:
Morning Hege,
This change worries me. What does the comment "let per figure it out
from the BOM" mean and does the change on the return undef change
that?
On 5/1/2022 1:28 PM, Michael Storz wrote:
Am 2022-05-01 18:22, schrieb Kevin A. McGrail:
Morning Hege,
This change worries me. What does the comment "let per figure it out
from the BOM" mean and does the change on the return undef change
that?
Worried that Perl Critic is complaining about
Am 2022-05-01 18:22, schrieb Kevin A. McGrail:
Morning Hege,
This change worries me. What does the comment "let per figure it out
from the BOM" mean and does the change on the return undef change
that?
Worried that Perl Critic is complaining about something that was done
on purpose.
Do we
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7982
--- Comment #12 from Kevin A. McGrail ---
Sidney,
Primarily, I would likely look at what changed between 3.4.6 and 4.0 since
those don't look like new tests to see why they now fail. I would double
confirm that 3.4.6 passes a make test
Morning Hege,
This change worries me. What does the comment "let per figure it out
from the BOM" mean and does the change on the return undef change that?
Worried that Perl Critic is complaining about something that was done on
purpose.
Do we have a good test case for this change? if not
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7982
--- Comment #11 from Sidney Markowitz ---
I identified 12 tests that require a total of 20 rules/*.cf files.
That does not count tests that I didn't run, including network and root tests
and any others that got skipped in my configuration.
On 5/1/22 07:47, Sidney Markowitz wrote:
> Kevin A. McGrail wrote on 1/05/22 3:47 pm:
>> A) When was that MANIFEST change because I do believe there are a couple
>> of items that should be included. I think it's used with ruleqa or
>> something.
>
> r1880742 | gbechis | 2020-08-11 02:29:41 +1200
WLBL code currently committed in trunk seems fully functional to me and I
cannot spot any issues.
I am currently running trunk r1900387 on a server and r1899446 on all other
servers.
Just updated to rc1 most servers without issues so far.
kb@ told me that he has better code for
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7982
--- Comment #10 from Sidney Markowitz ---
Now I tried it without the link to t.rules and it still passed. I guess more of
the failures had to do with the too long path than I had recognized.
Next step, I'll binary search through the files
Kevin A. McGrail wrote on 1/05/22 6:58 pm:
I'd recommend the next build is a prerelease build instead of an RC
build until a few people report they are running it in production. I'm
working hard to get it into production at PCCC.
+1, will do. It's just a name, and a more accurate one in this
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7983
--- Comment #22 from Henrik Krohns ---
(In reply to Kevin A. McGrail from comment #21)
>
> Hege, there is no need to patronize. I've been a release manager for several
> SA releases. I have asked several times: Does allmodules.t fail or
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7982
--- Comment #9 from Sidney Markowitz ---
(In reply to Kevin A. McGrail from comment #8)
> What's the behavior of a 3.4.6 tar ball and make test? What's in that
> MANIFEST?
3.4.6 just works. The only .cf file it has in it's MANIFEST that
I'd recommend the next build is a prerelease build instead of an RC
build until a few people report they are running it in production. I'm
working hard to get it into production at PCCC.
On 5/1/2022 2:54 AM, Sidney Markowitz wrote:
Ok, back to CTR we go!
--
Kevin A. McGrail
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7983
--- Comment #21 from Kevin A. McGrail ---
(In reply to Henrik Krohns from comment #19)
> I'll give you one more hint for your RC question.
>
> Usually when RC is released, it's supposed to be tested on as many systems
> as possible. So how
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7983
Henrik Krohns changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Ok, back to CTR we go!
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7983
--- Comment #19 from Henrik Krohns ---
I'll give you one more hint for your RC question.
Usually when RC is released, it's supposed to be tested on as many systems as
possible. So how is it a surprise that on some systems with less or
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7982
--- Comment #8 from Kevin A. McGrail ---
What's the behavior of a 3.4.6 tar ball and make test? What's in that
MANIFEST?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7982
--- Comment #7 from Sidney Markowitz ---
Are the files in t.rules used by make test? If that's the case then why not
include them in MANIFEST just like the files in the t directory?
I deleted the rulesrc symlink and that seems not to be
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7983
--- Comment #18 from Kevin A. McGrail ---
Apologies if it's upsetting you. We'll figure it out.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7983
--- Comment #17 from Henrik Krohns ---
(In reply to Kevin A. McGrail from comment #16)
> Hege, I have peeked at the patch and I apologize if I am confused but it is
> not clear to me
Why do you keep going on then? Sorry but I feel like I'm
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7983
--- Comment #16 from Kevin A. McGrail ---
Hege, I have peeked at the patch and I apologize if I am confused but it is not
clear to me: Does the test fail with OLEVBMacro with the warning about missing
modules OR is it just a noisy test and
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7983
--- Comment #15 from Henrik Krohns ---
(In reply to Kevin A. McGrail from comment #14)
> the question is what is the purpose of allmodules.t if we are going to
> remove modules that fail that test. Is it "all" or is it "some".
Let me me
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7983
--- Comment #14 from Kevin A. McGrail ---
the question is what is the purpose of allmodules.t if we are going to remove
modules that fail that test. Is it "all" or is it "some".
Also, did the code pass test before RC1 was released? I'm
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7983
--- Comment #13 from Henrik Krohns ---
(In reply to Kevin A. McGrail from comment #12)
> Removing a plugin from being tested doesn't seem like a good way to pass a
> test either.
- olevbmacro already has it's own t/olevbmacro.t test
-
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7983
--- Comment #12 from Kevin A. McGrail ---
Removing a plugin from being tested doesn't seem like a good way to pass a test
either.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7982
Kevin A. McGrail changed:
What|Removed |Added
CC||kmcgr...@apache.org
--- Comment
I would say the R-T-C falls to the release manager and you've stepped up
for that role with 4.0. So I defer to you, Sidney.
NOTE: I usually do R-T-C when i think an RC has a chance of being the
real release and an RC1 on a major release really doesn't have a hope
usually.
On 5/1/2022 2:09
On Sun, May 01, 2022 at 06:07:12PM +1200, Sidney Markowitz wrote:
> Do I get to just declare that we are back since I declared the switch
> to R-T-C? Does anyone disagree?
+1
I'm sorry to jump back and forth on this, but the reasons for being in
R-T-C seem to have disappeared. That is something to do when there are
no more open bugs before a release and we don't want to make any new bugs.
Now it seems that there are bugs for 4.0.0, we expect to find more, and
it
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7982
--- Comment #5 from Henrik Krohns ---
Basically the tests have went too far in the "test that my trunk/rules commit
works", instead of being self-sufficient tests for testing internal functions.
Like for example now many tests assume to
39 matches
Mail list logo
