3.3.0 plans

[Karsten Bräckelmann-2]

On Thu, 2009-06-25 at 09:51 +0100, Justin Mason wrote:
> 2009/6/25 Karsten Bräckelmann <guenther@...>:

> > I believe re-thinking the minimum supported Perl version and related
> > stuff like screwing MakeMaker would be a *really* good target for a new
> > $minor release.
> >
> > How much longer do we want to support Perl 5.6.x? [...]

> my guess is it'll be doable.

BTW, since you're about to push an alpha release...

Did we decide about that yet? :)  Is the priority bumping of the
MakeMaker bug an implicit death sentence for Perl 5.6 support, or do we
want a separate bug to track bumping requirements in two places?

See my concerns about carrying around old baggage and a need to support
Perl 5.6 for important back-ports until the end of the 3.4 live-time, if
we miss this opportunity.


--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

[Mark Martinec]

On Tuesday 30 June 2009 01:32:16 Karsten Bräckelmann wrote:
> BTW, since you're about to push an alpha release...
>
> Did we decide about that yet? :)

Not really, but it seems to be a moment of a sparkling desire
among devels, perhaps too good to be missed, before everybody
leaves for vacation (or babysitting)  ;)

> Is the priority bumping of the
> MakeMaker bug an implicit death sentence for Perl 5.6 support, or do we
> want a separate bug to track bumping requirements in two places?
>
> See my concerns about carrying around old baggage and a need to support
> Perl 5.6 for important back-ports until the end of the 3.4 live-time, if
> we miss this opportunity.

I'm all for abandoning perl 5.6 with 3.3, although I can accept it one way
or another. For those in need of perl 5.6 there will still be a 3.2.*.

  Mark

[Kevin A. McGrail]

I would easily vote to require a MakeMaker version if that is the only
requirement to keep 5.6.X support to move this release forward.  Anyone
supporting a 5.6.x install should be capable of installing requirements that
don't necessarily require an entirely new version.

However, I don't support an age-range for supporting perl because even 5.8
is already nearly 7 years old having been release in July 2002.

Regards,
KAM


----- Original Message -----
From: "Karsten Bräckelmann" <guenther@...>
To: <dev@...>
Sent: Monday, June 29, 2009 7:32 PM
Subject: Re: 3.3.0 plans

> On Thu, 2009-06-25 at 09:51 +0100, Justin Mason wrote:
>> 2009/6/25 Karsten Bräckelmann <guenther@...>:
>
>> > I believe re-thinking the minimum supported Perl version and related
>> > stuff like screwing MakeMaker would be a *really* good target for a new
>> > $minor release.
>> >
>> > How much longer do we want to support Perl 5.6.x? [...]
>
>> my guess is it'll be doable.
>
> BTW, since you're about to push an alpha release...
>
> Did we decide about that yet? :)  Is the priority bumping of the
> MakeMaker bug an implicit death sentence for Perl 5.6 support, or do we
> want a separate bug to track bumping requirements in two places?
>
> See my concerns about carrying around old baggage and a need to support
> Perl 5.6 for important back-ports until the end of the 3.4 live-time, if
> we miss this opportunity.
>
>
> --
> char
> *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
> main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8?
> c<<=1:
> (c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){
> putchar(t[s]);h=m;s=0; }}}
>

[Kevin A. McGrail]

> I'm all for abandoning perl 5.6 with 3.3, although I can accept it one way
> or another. For those in need of perl 5.6 there will still be a 3.2.*.

Please don't say that.  I think we'd like to envision the death of old
versions and the support of the new tree only as soon as feasible!  I'd
prefer to write documentation on workarounds such as installing an alternate
and newer perl alongside the distributions release, using cpan to install
any necessary modules, and making sure that their install of SA runs with
/usr/local/perl5.8/bin/perl.  I've never tried this but the theory seems
more than sound to me.

Regards,
KAM

[Karsten Bräckelmann-2]

On Mon, 2009-06-29 at 20:01 -0400, Kevin A. McGrail wrote:
> I would easily vote to require a MakeMaker version if that is the only
> requirement to keep 5.6.X support to move this release forward.  Anyone
> supporting a 5.6.x install should be capable of installing requirements that
> don't necessarily require an entirely new version.

As I've said before (and IIRC Mark implied with his comment 2 years ago
in bugzilla), I'm not about dropping the torch for 5.6. But instead, do
not *claim* we'll always support 5.6.

If it works with 5.6 and some updated Perl modules like MakeMaker, good.
If we can fix an issue for 5.6, good. But do not promise we'll fix and
workaround Perl 5.6 issues, maintaining SA 3.3 until the end of 3.4 --
whenever that'll be. Keep the door open to not back-port critical issues
with Perl 5.6 in 2012, when there's no chance to test it with 5.6 on all
platforms without major headaches.

Essentially we would promise actively supporting any issues with Perl
5.8, but not necessarily fix it for 5.6, too.


> However, I don't support an age-range for supporting perl because even 5.8
> is already nearly 7 years old having been release in July 2002.

It's not about an age-range of obsolete versions being introduced, but
superseded. Don't think "Perl 5.8 is 7 years old", but "5.6 went old 7
years ago". How long is that for 5.8?


> > Did we decide about that yet? :)  Is the priority bumping of the
> > MakeMaker bug an implicit death sentence for Perl 5.6 support, or do we
> > want a separate bug to track bumping requirements in two places?
> >
> > See my concerns about carrying around old baggage and a need to support
> > Perl 5.6 for important back-ports until the end of the 3.4 live-time, if
> > we miss this opportunity.

--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

[Kevin A. McGrail]

> Essentially we would promise actively supporting any issues with Perl
> 5.8, but not necessarily fix it for 5.6, too.

I agree fully with your statements on this!

> It's not about an age-range of obsolete versions being introduced, but
> superseded. Don't think "Perl 5.8 is 7 years old", but "5.6 went old 7
> years ago". How long is that for 5.8?

You make a good point but arbitrary rules are hard with Perl.  Perl in
practice is just too good in that modules have made it easier to keep
running for existing installations and security issues that necessitate an
outright upgrade have been minimal.  Code-forks are a reason to consider
supporting the next version, though.  Code-forks are evil personified.

Regards,
KAM

[Sidney Markowitz]

Karsten Bräckelmann wrote, On 30/6/09 12:27 PM:
> Essentially we would promise actively supporting any issues with Perl
> 5.8, but not necessarily fix it for 5.6, too.

That sounds to me very much like declaring 5.6 as deprecated.

Would that have the right connotations for what both of you have been
talking about?

  -- sidney

[Justin Mason]

2009/6/30 Karsten Bräckelmann <guenther@...>:

> On Thu, 2009-06-25 at 09:51 +0100, Justin Mason wrote:
>> 2009/6/25 Karsten Bräckelmann <guenther@...>:
>
>> > I believe re-thinking the minimum supported Perl version and related
>> > stuff like screwing MakeMaker would be a *really* good target for a new
>> > $minor release.
>> >
>> > How much longer do we want to support Perl 5.6.x? [...]
>
>> my guess is it'll be doable.
>
> BTW, since you're about to push an alpha release...
>
> Did we decide about that yet? :)  Is the priority bumping of the
> MakeMaker bug an implicit death sentence for Perl 5.6 support, or do we
> want a separate bug to track bumping requirements in two places?

We should have a separate bug for that.

note that again, this issue isn't a blocker for the alpha release. we
can do an alpha before deciding that.
(we may have to add a min-version requirement to Makefile.PL for
ExtUtils::MakeMaker though.)

--j.

[Warren Togami]

On 06/29/2009 11:59 AM, Justin Mason wrote:

> On Mon, Jun 29, 2009 at 16:27, Warren Togami<wtogami@...>  wrote:
>> On 06/29/2009 07:44 AM, Justin Mason wrote:
>>> How's about I cut an alpha at the end of this week?
>>>
>> Why end of the week if nothing on the list is blockers?
>
> ok ok.  good point ;)
>
> Let's give it 3 days to garner some comments and possibly close out a
> few of those P1s and P2s.  Wednesday evening...
>
> --j.

How is this going?

Warren

[Matt Kettler-3]

Warren Togami wrote:

> On 06/29/2009 11:59 AM, Justin Mason wrote:
>> On Mon, Jun 29, 2009 at 16:27, Warren Togami<wtogami@...>  wrote:
>>> On 06/29/2009 07:44 AM, Justin Mason wrote:
>>>> How's about I cut an alpha at the end of this week?
>>>>
>>> Why end of the week if nothing on the list is blockers?
>>
>> ok ok.  good point ;)
>>
>> Let's give it 3 days to garner some comments and possibly close out a
>> few of those P1s and P2s.  Wednesday evening...
>>
>> --j.
>
> How is this going?
>
> Warren
>
>

The public alpha release was announced yesterday on the users mailing list:

http://mail-archives.apache.org/mod_mbox/spamassassin-users/200907.mbox/%3C6c399e450907021522k1678f0ffn454a1e670f064b40@...%3E

[Warren Togami]

On 07/03/2009 10:37 PM, Matt Kettler wrote:
> The public alpha release was announced yesterday on the users mailing list:
>
> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200907.mbox/%3C6c399e450907021522k1678f0ffn454a1e670f064b40@...%3E

I'm having trouble getting it to run on Fedora 11.

[root@newcaprica spamassassin]# sa-update
config: no configuration text or files found! do you need to run
'sa-update'?
check: no loaded plugin implements 'check_main': cannot scan!
Check the necessary '.pre' files are in the config directory.

*** spamassassin-3.2.5 ***

[root@newcaprica ~]# cd /etc/mail/spamassassin/
[root@newcaprica spamassassin]# ls
init.pre  local.cf  sa-update-keys  spamassassin-default.rc
spamassassin-helper.sh  spamassassin-spamc.rc  v310.pre  v312.pre  v320.pre

*** spamassassin-3.3.0-alpha1 ***

[root@newcaprica ~]# cd /etc/mail/spamassassin/
[root@newcaprica spamassassin]# ls
local.cf  sa-update-keys  spamassassin-default.rc
spamassassin-helper.sh  spamassassin-spamc.rc

All of the *.pre files are no longer being installed into our RPM.  It
seems to pass the test suite though.

All tests successful.
Files=151, Tests=1938, 173 wallclock secs ( 1.05 usr  0.39 sys + 67.07
cusr 13.81 csys = 82.32 CPU)
Result: PASS

Still looking...

Warren Togami
wtogami@...

[Warren Togami]

On 07/06/2009 03:13 PM, Warren Togami wrote:

> On 07/03/2009 10:37 PM, Matt Kettler wrote:
>> The public alpha release was announced yesterday on the users mailing
>> list:
>>
>> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200907.mbox/%3C6c399e450907021522k1678f0ffn454a1e670f064b40@...%3E
>>
>
> I'm having trouble getting it to run on Fedora 11.
>
> [root@newcaprica spamassassin]# sa-update
> config: no configuration text or files found! do you need to run
> 'sa-update'?
> check: no loaded plugin implements 'check_main': cannot scan!
> Check the necessary '.pre' files are in the config directory.
>
> *** spamassassin-3.2.5 ***
>
> [root@newcaprica ~]# cd /etc/mail/spamassassin/
> [root@newcaprica spamassassin]# ls
> init.pre local.cf sa-update-keys spamassassin-default.rc
> spamassassin-helper.sh spamassassin-spamc.rc v310.pre v312.pre v320.pre
>
> *** spamassassin-3.3.0-alpha1 ***
>
> [root@newcaprica ~]# cd /etc/mail/spamassassin/
> [root@newcaprica spamassassin]# ls
> local.cf sa-update-keys spamassassin-default.rc spamassassin-helper.sh
> spamassassin-spamc.rc
>
> All of the *.pre files are no longer being installed into our RPM. It
> seems to pass the test suite though.
>

spamassassin-3.2.5 rules/ contains the *.pre files.
spamassassin-3.3.0-alpha1 rules/ is missing *.pre files.

Was this intentional?

Is 3.3.0-alpha1 working for anybody?

Possibly a separate issue this is the %build section from our
spamassassin.spec file.

%build
CFLAGS="$RPM_OPT_FLAGS"; export CFLAGS
%{__perl} Makefile.PL PREFIX=%{_prefix} SYSCONFDIR=%{_sysconfdir}
DESTDIR=$RPM_BUILD_ROOT < /dev/null
%{__make}

Checking if your kit is complete...
Looks good
'ENABLE_SSL' is not a known MakeMaker parameter name.
'SYSCONFDIR' is not a known MakeMaker parameter name.
Writing Makefile for Mail::SpamAssassin
Makefile written by ExtUtils::MakeMaker 6.42
+ /usr/bin/make 'OPTIMIZE=-O2 -g' -j3

spamassassin-3.2.5 does not complain about ENABLE_SSL or SYSCONFDIR in
MakeMaker.  What changed?  Do we need to adapt?

Warren Togami
wtogami@...

[Michael Parker]

On Jul 6, 2009, at 2:52 PM, Warren Togami wrote:

> On 07/06/2009 03:13 PM, Warren Togami wrote:
>> On 07/03/2009 10:37 PM, Matt Kettler wrote:
>>> The public alpha release was announced yesterday on the users  
>>> mailing
>>> list:
>>>
>>> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200907.mbox/%3C6c399e450907021522k1678f0ffn454a1e670f064b40@...%3E
>>>
>>
>> I'm having trouble getting it to run on Fedora 11.
>>
>> [root@newcaprica spamassassin]# sa-update
>> config: no configuration text or files found! do you need to run
>> 'sa-update'?
>> check: no loaded plugin implements 'check_main': cannot scan!
>> Check the necessary '.pre' files are in the config directory.
>>
>> *** spamassassin-3.2.5 ***
>>
>> [root@newcaprica ~]# cd /etc/mail/spamassassin/
>> [root@newcaprica spamassassin]# ls
>> init.pre local.cf sa-update-keys spamassassin-default.rc
>> spamassassin-helper.sh spamassassin-spamc.rc v310.pre v312.pre  
>> v320.pre
>>
>> *** spamassassin-3.3.0-alpha1 ***
>>
>> [root@newcaprica ~]# cd /etc/mail/spamassassin/
>> [root@newcaprica spamassassin]# ls
>> local.cf sa-update-keys spamassassin-default.rc spamassassin-
>> helper.sh
>> spamassassin-spamc.rc
>>
>> All of the *.pre files are no longer being installed into our RPM. It
>> seems to pass the test suite though.
>>
>
> spamassassin-3.2.5 rules/ contains the *.pre files.
> spamassassin-3.3.0-alpha1 rules/ is missing *.pre files.
>
> Was this intentional?

Yes.  3.3 requires that you run sa-update after installation to pick  
up the latest rules release.  I believe this is documented.

For packagers such as yourself, you'll probably want to have a  
separate rules package for that initial install.

Michael

>
>
> Is 3.3.0-alpha1 working for anybody?
>
> Possibly a separate issue this is the %build section from our  
> spamassassin.spec file.
>
> %build
> CFLAGS="$RPM_OPT_FLAGS"; export CFLAGS
> %{__perl} Makefile.PL PREFIX=%{_prefix} SYSCONFDIR=%{_sysconfdir}  
> DESTDIR=$RPM_BUILD_ROOT < /dev/null
> %{__make}
>
> Checking if your kit is complete...
> Looks good
> 'ENABLE_SSL' is not a known MakeMaker parameter name.
> 'SYSCONFDIR' is not a known MakeMaker parameter name.
> Writing Makefile for Mail::SpamAssassin
> Makefile written by ExtUtils::MakeMaker 6.42
> + /usr/bin/make 'OPTIMIZE=-O2 -g' -j3
>
> spamassassin-3.2.5 does not complain about ENABLE_SSL or SYSCONFDIR  
> in MakeMaker.  What changed?  Do we need to adapt?
>
> Warren Togami
> wtogami@...

[Mark Martinec]

Warren,

> On 07/03/2009 10:37 PM, Matt Kettler wrote:
> > The public alpha release was announced yesterday on the users mailing
> > list:
> >
> > http://mail-archives.apache.org/mod_mbox/spamassassin-users/200907.mbox/%
> >3C6c399e450907021522k1678f0ffn454a1e670f064b40@...%3E
>
> I'm having trouble getting it to run on Fedora 11.
>
> [root@newcaprica spamassassin]#
>   sa-update config: no configuration text or files found!
>   do you need to run 'sa-update'?
> check: no loaded plugin implements 'check_main': cannot scan!
> Check the necessary '.pre' files are in the config directory.

Yes, and?  Did you run sa-update???

The 3.3 no longer comes with rules in the same package.
These must be installed separately with 'sa-update',
which either fetches them from the net, or can install
them from a tar - which is in the same directory
as 3.3.0-alpha1 is.

  Mark

[Warren Togami]

On 07/06/2009 03:59 PM, Michael Parker wrote:

>>
>> spamassassin-3.2.5 rules/ contains the *.pre files.
>> spamassassin-3.3.0-alpha1 rules/ is missing *.pre files.
>>
>> Was this intentional?
>
> Yes. 3.3 requires that you run sa-update after installation to pick up
> the latest rules release. I believe this is documented.
>
> For packagers such as yourself, you'll probably want to have a separate
> rules package for that initial install.
>

[root@newcaprica spamassassin]# sa-update
config: no configuration text or files found! do you need to run
'sa-update'?
check: no loaded plugin implements 'check_main': cannot scan!
Check the necessary '.pre' files are in the config directory.

Isn't this a chicken and egg problem then?

Warren

[Warren Togami]

On 07/06/2009 04:00 PM, Mark Martinec wrote:

> Warren,
>
>> On 07/03/2009 10:37 PM, Matt Kettler wrote:
>>> The public alpha release was announced yesterday on the users mailing
>>> list:
>>>
>>> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200907.mbox/%
>>> 3C6c399e450907021522k1678f0ffn454a1e670f064b40@...%3E
>> I'm having trouble getting it to run on Fedora 11.
>>
>> [root@newcaprica spamassassin]#
>>    sa-update config: no configuration text or files found!
>>    do you need to run 'sa-update'?
>> check: no loaded plugin implements 'check_main': cannot scan!
>> Check the necessary '.pre' files are in the config directory.
>
> Yes, and?  Did you run sa-update???
>
> The 3.3 no longer comes with rules in the same package.
> These must be installed separately with 'sa-update',
> which either fetches them from the net, or can install
> them from a tar - which is in the same directory
> as 3.3.0-alpha1 is.
>
>    Mark

sa-update is failing due to the lack of the /etc/mail/spamassassin/*.pre
files.

Warren Togami
wtogami@...

[Warren Togami]

On 07/06/2009 03:59 PM, Michael Parker wrote:
> Yes. 3.3 requires that you run sa-update after installation to pick up
> the latest rules release. I believe this is documented.
>
> For packagers such as yourself, you'll probably want to have a separate
> rules package for that initial install.
>
> Michael

It appears that we were overzealous in removing the the rules from the
tarball?  sa-update does not work all without the *.pre files.
Furthermore package upgrades expect the *.pre files to be installed in
the newer version of the package as they need to exist as config files.
  They are gone from the alpha1 tarball.

Shouldn't the *.pre files be re-added to the tarball rules/ directory,
without the accompanying rules?  I added them to my tarball and after
you install the resulting RPM binary package, sa-update works.

Warren Togami
wtogami@...

[Michael Parker]

On Jul 6, 2009, at 3:46 PM, Warren Togami wrote:

> On 07/06/2009 03:59 PM, Michael Parker wrote:
>> Yes. 3.3 requires that you run sa-update after installation to pick  
>> up
>> the latest rules release. I believe this is documented.
>>
>> For packagers such as yourself, you'll probably want to have a  
>> separate
>> rules package for that initial install.
>>
>> Michael
>
> It appears that we were overzealous in removing the the rules from  
> the tarball?  sa-update does not work all without the *.pre files.  
> Furthermore package upgrades expect the *.pre files to be installed  
> in the newer version of the package as they need to exist as config  
> files.  They are gone from the alpha1 tarball.
>
> Shouldn't the *.pre files be re-added to the tarball rules/  
> directory, without the accompanying rules?  I added them to my  
> tarball and after you install the resulting RPM binary package, sa-
> update works.
>
>

Perhaps.  Sounds like a bug, can you please file one.

Thanks
Michael

[Justin Mason]

On Mon, Jul 6, 2009 at 21:05, Warren Togami<wtogami@...> wrote:

> On 07/06/2009 04:00 PM, Mark Martinec wrote:
>>
>> Warren,
>>
>>> On 07/03/2009 10:37 PM, Matt Kettler wrote:
>>>>
>>>> The public alpha release was announced yesterday on the users mailing
>>>> list:
>>>>
>>>>
>>>> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200907.mbox/%
>>>> 3C6c399e450907021522k1678f0ffn454a1e670f064b40@...%3E
>>>
>>> I'm having trouble getting it to run on Fedora 11.
>>>
>>> [root@newcaprica spamassassin]#
>>>   sa-update config: no configuration text or files found!
>>>   do you need to run 'sa-update'?
>>> check: no loaded plugin implements 'check_main': cannot scan!
>>> Check the necessary '.pre' files are in the config directory.
>>
>> Yes, and?  Did you run sa-update???
>>
>> The 3.3 no longer comes with rules in the same package.
>> These must be installed separately with 'sa-update',
>> which either fetches them from the net, or can install
>> them from a tar - which is in the same directory
>> as 3.3.0-alpha1 is.
>>
>>   Mark
>
> sa-update is failing due to the lack of the /etc/mail/spamassassin/*.pre
> files.
>

this sounds like our RPM spec file is buggy -- does it work if
installed from the tgz?

--j.

[Warren Togami]

On 07/06/2009 05:32 PM, Justin Mason wrote:

> On Mon, Jul 6, 2009 at 21:05, Warren Togami<wtogami@...>  wrote:
>> On 07/06/2009 04:00 PM, Mark Martinec wrote:
>>> Warren,
>>>
>>>> On 07/03/2009 10:37 PM, Matt Kettler wrote:
>>>>> The public alpha release was announced yesterday on the users mailing
>>>>> list:
>>>>>
>>>>>
>>>>> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200907.mbox/%
>>>>> 3C6c399e450907021522k1678f0ffn454a1e670f064b40@...%3E
>>>> I'm having trouble getting it to run on Fedora 11.
>>>>
>>>> [root@newcaprica spamassassin]#
>>>>    sa-update config: no configuration text or files found!
>>>>    do you need to run 'sa-update'?
>>>> check: no loaded plugin implements 'check_main': cannot scan!
>>>> Check the necessary '.pre' files are in the config directory.
>>> Yes, and?  Did you run sa-update???
>>>
>>> The 3.3 no longer comes with rules in the same package.
>>> These must be installed separately with 'sa-update',
>>> which either fetches them from the net, or can install
>>> them from a tar - which is in the same directory
>>> as 3.3.0-alpha1 is.
>>>
>>>    Mark
>> sa-update is failing due to the lack of the /etc/mail/spamassassin/*.pre
>> files.
>>
>
> this sounds like our RPM spec file is buggy -- does it work if
> installed from the tgz?
>
> --j.

This isn't the upstream RPM spec file.  This is Fedora's spec file.

How can it copy the *.pre files into the RPM if the *.pre files do not
exist in the tarball's rules/ directory?

Warren