Mailing List Archive

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

Henrik Krohns <apache@hege.li> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |jidanni@jidanni.org

--- Comment #29 from Henrik Krohns <apache@hege.li> ---
*** Bug 7836 has been marked as a duplicate of this bug. ***

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #30 from Henrik Krohns <apache@hege.li> ---
Sorry guys, I did not want to partake in this bug, but it seems the ball has
been dropped completely.

Being PMC member and probably the most active developer, I use my right to
emergency rollback the painful original commit.

Transmitting file data .......done
Committing transaction...
Committed revision 1879684.

I want to see SA work and prosper, but this is just embarassing. A week since
faulty commit and all that happens is just some mumbling about it.

Now that the slate is clean, PLEASE create a branch for it. Count the votes or
vote again if you want. But do not proceed commiting such individual one by one
changes which make no sense.

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #31 from jidanni@jidanni.org ---
Thanks for making Spamassassin work again.
(Whatever you guys do, remember to do a
https://en.wikipedia.org/wiki/Smoke_testing_(software)
when ever you alter the main tree.

Spamassassin is very frail: there is no simple "revert" SVN button I can
push here downstream once I swallow any changes.
My Spamassassin is "out of business" until someone upstream fixes it
and I can download a new version.)

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #32 from Kevin A. McGrail <kmcgrail@apache.org> ---
Thank you for diving in. I appreciate the attention this matter is getting
because I think it is very important.

Three notes:

Please remember with votes being made on this thread, you should be waiting 72
hours for people to weigh in.

Please leave this ticket for me to work on. I'm working on it and rolling
things back is breaking a lot of work we are doing on two systems in the
background.

Trunk is unreleased and no rules are pending release so masscheck being broken
is a null impact.

-KAM

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #33 from Loren Wilton <lwilton@earthlink.net> ---
Kevin, did you notice bug 7836, linked as a duplicate of this?

Reporter: jidanni@jidanni.org
Target Milestone: Undefined

Updating spamassassin makes it unusable.

sa-update shows several

rules: failed to run __FROM_ADDRLIST_BANKS test, skipping:
(Can't locate object method "_check_whitelist" via package
"Mail::SpamAssassin::Plugin::WLBLEval" at
/home/jidanni/.spamassassin-tree/share/perl/5.30.3/Mail/SpamAssassin/Plugin/WLBLEval.pm
line 119.

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #34 from Henrik Krohns <apache@hege.li> ---
(In reply to Kevin A. McGrail from comment #32)
>
> Please remember with votes being made on this thread, you should be waiting
> 72 hours for people to weigh in.

People have weighted in.

> Please leave this ticket for me to work on. I'm working on it and rolling
> things back is breaking a lot of work we are doing on two systems in the
> background.

Again, who is "we"? Why would _trunk_ have any effect in your "two systems"?
Use a branch as suggested, so no other change in trunk will bother your
testings etc. And people will actually have something to weight in, before
things break!!

> Trunk is unreleased and no rules are pending release so masscheck being
> broken is a null impact.

Uh huh. No.

From the way this bug started, I have little faith in the way you are going on
about it. Is there even a plan?? Where is it? What things are you going to
rename? What things are you going to break? "I'm going to rename WLBL to
ALBL... uhh no it's not necessary to rename it..", how about actually posting
the complete plan and waiting for people to weight in on all the renames? Or do
as suggested and go on implementing the things in trunk so we have review and
test the changes easily, instead of yet again more questions in mailing lists
on why there are errors and why rule updates are not working etc.

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #35 from Henrik Krohns <apache@hege.li> ---
(In reply to Henrik Krohns from comment #34)
> Or do as suggested and go on implementing the things in trunk

... meaning branch of course :-)

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #36 from Kevin A. McGrail <kmcgrail@apache.org> ---
I just committed a second version of the proof of concept for whitelist_to:

svn commit -m 'changing whitelist_to to welcomelist_to including backward
compatibility stubs and add a feature check instead of using a version test for
rules.'
Sending MANIFEST
Sending lib/Mail/SpamAssassin/Conf.pm
Sending lib/Mail/SpamAssassin/Plugin/WLBLEval.pm
Sending rules/30_text_de.cf
Sending rules/30_text_fr.cf
Sending rules/30_text_pl.cf
Sending rules/30_text_pt_br.cf
Sending rules/50_scores.cf
Sending rules/60_whitelist.cf
Sending rules/active.list
Sending rules/v343.pre
Sending t/whitelist_to.t
Transmitting file data ............
Committed revision 1879735.

As noted in the commit log, this uses welcomelist, has stubs for compatibility
and uses if can(Mail::SpamAssassin::Conf::feature_blocklist_welcomelist) for
the rule encapsulation.

Using WelcomeList and BlockList will allow all acronyms like WLBLEval and RBL
to remain the same.

As with before, if this proves to work, we will start on whitelist_from and
move on to more routines until finished.

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #37 from AXB <axb.lists@gmail.com> ---
(In reply to Kevin A. McGrail from comment #36)
> I just committed a second version of the proof of concept for whitelist_to:
>
> svn commit -m 'changing whitelist_to to welcomelist_to including backward
> compatibility stubs and add a feature check instead of using a version test
> for rules.'
> Sending MANIFEST
> Sending lib/Mail/SpamAssassin/Conf.pm
> Sending lib/Mail/SpamAssassin/Plugin/WLBLEval.pm
> Sending rules/30_text_de.cf
> Sending rules/30_text_fr.cf
> Sending rules/30_text_pl.cf
> Sending rules/30_text_pt_br.cf
> Sending rules/50_scores.cf
> Sending rules/60_whitelist.cf
> Sending rules/active.list
> Sending rules/v343.pre
> Sending t/whitelist_to.t
> Transmitting file data ............
> Committed revision 1879735.
>
> As noted in the commit log, this uses welcomelist, has stubs for
> compatibility and uses if
> can(Mail::SpamAssassin::Conf::feature_blocklist_welcomelist) for the rule
> encapsulation.
>
> Using WelcomeList and BlockList will allow all acronyms like WLBLEval and
> RBL to remain the same.
>
> As with before, if this proves to work, we will start on whitelist_from and
> move on to more routines until finished.

why is a POC put in trunk? - PLEASE, PLEASE put the playpen in a branch

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #38 from Kevin A. McGrail <kmcgrail@apache.org> ---
Axb, please see my response on list re: branches but for those only reading the
bug, we have no mechanism for testing ruleqa and masscheck on anything but
trunk.

We will do our best to avoid problems but if you are running trunk, you are
running bleeding edge development code and you should expect issues.

I was talked out of creating a 4.0 branch however and I think now that should
be reconsidered. I am worried that this bug aside, we have a lot of code
planned for 4.0 so I don't want to see people so upset.

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #39 from AXB <axb.lists@gmail.com> ---
(In reply to Kevin A. McGrail from comment #38)

> I was talked out of creating a 4.0 branch however and I think now that
> should be reconsidered. I am worried that this bug aside, we have a lot of
> code planned for 4.0 so I don't want to see people so upset.

Then start a branch for 5.0 or name it Milk&Coffee - just don't play around
with trunk which is what third party developers, integrators, etc work with.

You can't expect the rest of the world to keep track & review what "you and
your staff" does in small batches.

It's not your project... it's not mine...

We owe respect to EVERYBODY and playing around with the code isn't cutting it.

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #40 from Kevin A. McGrail <kmcgrail@apache.org> ---
This is a bug tracker not a mailing list. Please move this onlist where there
is already discussion about creating a 4.0 branch.

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #41 from AXB <axb.lists@gmail.com> ---
(In reply to Kevin A. McGrail from comment #40)
> This is a bug tracker not a mailing list. Please move this onlist where
> there is already discussion about creating a 4.0 branch.

I don't see a problem in having a disussion regarding such drastic changes
being documented in the bug tracker. This is not our daily quota of blah.

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #42 from Kevin A. McGrail <kmcgrail@apache.org> ---
Found two new files that I added to MANIFEST but not to svn add. Committed.

svn commit -m 'Artifacts in MANIFEST but not in SVN for BZ 7826'
Adding rules/v400.pre
Adding t/welcomelist_to.t
Transmitting file data ..
Committed revision 1879755.

Plan to wait the weekend out on this task to make sure things look good before
continuing with whitelist_from.

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #43 from jidanni@jidanni.org ---
> we have no mechanism for testing ruleqa and masscheck on anything but trunk.
All I know is then make a copy of trunk and test on that.

And be sure to always make sure to run an email through a basic spam check to
make sure nothing is broken, and if it is back out (revert changes) within five
minutes. Thanks.

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #44 from Kevin A. McGrail <kmcgrail@apache.org> ---
(In reply to jidanni from comment #43)
> > we have no mechanism for testing ruleqa and masscheck on anything but trunk.
> All I know is then make a copy of trunk and test on that.

Afraid it's not that simple. See
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7837

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #45 from Kevin A. McGrail <kmcgrail@apache.org> ---
Also see bug 7838 for a description on one of the new rules causing a warning.

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #46 from John Hardin <jhardin@impsec.org> ---
(In reply to Kevin A. McGrail from comment #0)
> - Old configuration terms will continue to work for no less than one year
> and will not be dropped until a version change such as 4.0 to 4.1.

We should also emit lint warnings for use of the old option names.

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #47 from Kevin A. McGrail <kmcgrail@apache.org> ---
(In reply to John Hardin from comment #46)
> (In reply to Kevin A. McGrail from comment #0)
> > - Old configuration terms will continue to work for no less than one year
> > and will not be dropped until a version change such as 4.0 to 4.1.
>
> We should also emit lint warnings for use of the old option names.

Good idea. We are using an existing configuration option "aliases" not really
any new configuration parsing. Would need something like a aliases_warn
option, I think.

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #48 from John Hardin <jhardin@impsec.org> ---
(In reply to Kevin A. McGrail from comment #0)

> - Old configuration terms will continue to work for no less than one year
> and will not be dropped until a version change such as 4.0 to 4.1.

I also want to make it clear I *strongly* suggest that the old terms continue
to be supported as aliases *indefinitely*, absent a strong technical reason to
end such support. And I feel "to keep the code clean" isn't sufficiently strong
in this case.

Do we need a PMC vote on this detail?

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #49 from Kevin A. McGrail <kmcgrail@apache.org> ---
(In reply to John Hardin from comment #48)
> Do we need a PMC vote on this detail?

Votes on a bug imply a blocker to this bug which I'm posting here to say I'm
assuming that is NOT your intent. Please post discussion/vote/results threads
on the pmc list.

IMO, yes, we will need a vote on ending the backwards compatibility but it will
be way down the line when we start a 4.1 branch. Voting on it now will just be
lost to the sands of time and should be left for the future PMC at that time to
decide.

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #50 from John Hardin <jhardin@impsec.org> ---
(In reply to Kevin A. McGrail from comment #49)
> (In reply to John Hardin from comment #48)
> > Do we need a PMC vote on this detail?
>
> Votes on a bug imply a blocker to this bug which I'm posting here to say I'm
> assuming that is NOT your intent. Please post discussion/vote/results
> threads on the pmc list.
>
> IMO, yes, we will need a vote on ending the backwards compatibility but it
> will be way down the line when we start a 4.1 branch. Voting on it now will
> just be lost to the sands of time and should be left for the future PMC at
> that time to decide.

OK, that works.(In reply to Kevin A. McGrail from comment #49)
> (In reply to John Hardin from comment #48)
> > Do we need a PMC vote on this detail?
>
> Votes on a bug imply a blocker to this bug which I'm posting here to say I'm
> assuming that is NOT your intent. Please post discussion/vote/results
> threads on the pmc list.
>
> IMO, yes, we will need a vote on ending the backwards compatibility but it
> will be way down the line when we start a 4.1 branch. Voting on it now will
> just be lost to the sands of time and should be left for the future PMC at
> that time to decide.

Not a blocker.

I was more thinking voting now to commit to and publicly declare making the
support for the historical terminology permanent. This is primarily to quell
objections on the list to forcing the change on users, regardless of how far
down the road we kick that can.

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

Manu Zurmühl <m.zurmuehl@heinlein-support.de> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |m.zurmuehl@heinlein-support
| |.de

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

jidanni@jidanni.org changed:

What |Removed |Added
----------------------------------------------------------------------------
CC|jidanni@jidanni.org |

--
You are receiving this mail because:
You are the assignee for the bug.

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #51 from Kevin A. McGrail <kmcgrail@apache.org> ---
Just an update that the rules for whitelist_to are working work for 3.3.1 to
3.4.X . For 4.0, we'll keep updating the has feature function so those rules
don't go active until 4.0 is released. Working on whitelist_from.

--
You are receiving this mail because:
You are the assignee for the bug.