You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by da...@chaosreigns.com on 2011/09/13 21:39:10 UTC
September 30th release candidate Re: [Bug 6658] Version 3.2.5
looks like it would be reasonable to install according to web site
On 09/13, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6658
> The Apache SpamAssassin project goal is to produce three major or minor
> release per year with release candidates proposed on or closely to January
> 30th, April 30th, & September 30th of each year.
Woo. September 30th will be a 3.4.0 release candidate, right? Who gets to
be release manager this time?
I think the general consensus was *not* to branch 3.4.0 off of trunk, but
to leave it in trunk, and just do releases from trunk for a while?
Time to wrap up some last minute bugs. Which ones actually need to get
closed for a release?
--
"If you want to make an apple pie from scratch, you must first create
the universe." - Carl Sagan
http://www.ChaosReigns.com
Re: September 30th release candidate Re: [Bug 6658] Version 3.2.5 looks like it would be reasonable to install according to web site
Posted by Mark Martinec <Ma...@ijs.si>.
> On 2011-09-13 22:23, darxus@chaosreigns.com wrote:
> > We waste so much time backporting to the last branch. And trunk has been
> > incredibly stable. I hate to see releases that aren't taken from trunk,
> > seems like a waste of time and effort.
>
> for once I agree with Darxus :)
> There are a few usefull additions/fixes in 3.4 trunk which won't ever
> get backported and it would be a pity to have to wait
Yes, no need to waste effort on 3.3.3, there are no critical problems
with 3.3.2.
Axb wrote:
> I'd +1 to cut a "beta1" out of trunk.
Kevin wrote:
> I'd like to make a goal to get sa-update a lot cleaner and ipv6 native
> release which I'm working on infrastructure for and call it 3.4.x.
I agree, fixing the sa-update's problem of repeated downloads when
some intermediate stage fails should be considered a blocker for 3.4.0.
Making sa-update IPv6 capable would be highly desirable, now that Kevin
has provided a dual-stack mirror (thanks Kevin!). A major release
is a good opportunity for both of these changes.
I still need to fix one issue with AskDNS plugin...
Mark
Re: September 30th release candidate
Posted by Mark Martinec <Ma...@ijs.si>.
Mark wrote:
> > To me it makes most sense to create a 3.4 branch at the time of a release
> > or shortly before it. So I'm closer to Kevin on this than with Daryl.
Daryl wrote:
> Perhaps I'm not following what has been said here. I thought it was
> being suggested we use trunk "forever" as the 3.4 development tree,
> rather than branching it at some point.
>
> I'm all for RTC'ing trunk sometime just before an RC is cut and then
> branching once the final release is cut. That's what we've always done
> -- so no change there. I think it's even in the release procedures.
Apperently I haven't been paying attention too. I agree with
what Daryl says here.
darxus wrote:
> Because trunk works as well as 3.3, it's stable, and there's no reason to
> put off releasing it, and no reason to do another 3.3 release.
> Why not do a release from trunk?
Agreed.
> I appreciate your concern for quality releases. It's part of the reason I
> run trunk, regularly updated, on my mail server. SpamAssassin's bigger
> problem right now is stagnation, and backports are a problem not a
> solution.
Right. We run trunk too, as well as some of our friends.
It's the current trunk code that gets exercised most under scrutiny,
and any problems there were being fixed quickly.
Mark
Re: September 30th release candidate Re: [Bug 6658] Version 3.2.5
looks like it would be reasonable to install according to web site
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 13/09/2011 8:29 PM, Mark Martinec wrote:
>>> Alex, what are your thoughts on NOT creating a 3.4 branch and continuing
>>> with trunk for development? You seem to be pro the concept above and it
>>> makes sense that if we switch to rtc on trunk say 1 week or so before a
>>> release date as defined in the ReleaseGoals, everyone is happy.
> Daryl writes:
>> I'm quite uncomfortable with that myself, however I haven't written a
>> lot of code for SA in the past couple of years myself. I do think
>> efforts should be placed on regular review of patches against stable
>> branches instead.
>
> To me it makes most sense to create a 3.4 branch at the time of a release
> or shortly before it. So I'm closer to Kevin on this than with Daryl.
Perhaps I'm not following what has been said here. I thought it was
being suggested we use trunk "forever" as the 3.4 development tree,
rather than branching it at some point.
I'm all for RTC'ing trunk sometime just before an RC is cut and then
branching once the final release is cut. That's what we've always done
-- so no change there. I think it's even in the release procedures.
Daryl
Re: September 30th release candidate Re: [Bug 6658] Version 3.2.5 looks like it would be reasonable to install according to web site
Posted by Mark Martinec <Ma...@ijs.si>.
> >> There are a few usefull additions/fixes in 3.4 trunk which won't ever
> >> get backported and it would be a pity to have to wait
>
> Why not back port the few features/fixes?
diff -U2 sa-3.3 sa-3.4 | (cd sa-3.3; patch)
:)
Seems to me the 3.4 (trunk) is being much better tested by
active developers than a backport-patched 3.3.x would ever be.
The only need for 3.3.3 would arise if some important security
fix or large breakage like the Y2010 bug would pop up.
> If there are no (or few) major changes, why not do the backports. They
> should be trivial. Has the branch really drifted that far out of sync
> with trunk?
There are lots of small changes all over the place.
We probably already lost track of all that has changed.
> > Alex, what are your thoughts on NOT creating a 3.4 branch and continuing
> > with trunk for development? You seem to be pro the concept above and it
> > makes sense that if we switch to rtc on trunk say 1 week or so before a
> > release date as defined in the ReleaseGoals, everyone is happy.
Daryl writes:
> I'm quite uncomfortable with that myself, however I haven't written a
> lot of code for SA in the past couple of years myself. I do think
> efforts should be placed on regular review of patches against stable
> branches instead.
To me it makes most sense to create a 3.4 branch at the time of a release
or shortly before it. So I'm closer to Kevin on this than with Daryl.
Mark
Re: September 30th release candidate
Posted by da...@chaosreigns.com.
On 09/13, Daryl C. W. O'Shea wrote:
> Why not back port the few features/fixes?
Because trunk works as well as 3.3, it's stable, and there's no reason to
put off releasing it, and no reason to do another 3.3 release.
Why not do a release from trunk?
> I'm quite uncomfortable with that myself, however I haven't written
> a lot of code for SA in the past couple of years myself. I do think
> efforts should be placed on regular review of patches against stable
> branches instead.
I suppose that might be nice if it happened, but it doesn't. It's mostly a
huge bottleneck. There haven't been enough changes to justify the
overhead of maintaining two releases - trunk and the latest branch (3.3).
I appreciate your concern for quality releases. It's part of the reason I
run trunk, regularly updated, on my mail server. SpamAssassin's bigger
problem right now is stagnation, and backports are a problem not a
solution.
--
"The most merciful thing in the world, I think, is the inability of the
human mind to correlate all its contents."
http://www.ChaosReigns.com
Re: September 30th release candidate Re: [Bug 6658] Version 3.2.5
looks like it would be reasonable to install according to web site
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 13/09/2011 5:35 PM, Kevin A. McGrail wrote:
> On 9/13/2011 4:29 PM, Axb wrote:
>> On 2011-09-13 22:23, darxus@chaosreigns.com wrote:
>>
>>> We waste so much time backporting to the last branch. And trunk has been
>>> incredibly stable. I hate to see releases that aren't taken from trunk,
>>> seems like a waste of time and effort.
I don't think there's really a lot of effort to the backport. The
effort is going into the peer review that promotes the quality releases
that Apache is known for.
>> for once I agree with Darxus :)
>> There are a few usefull additions/fixes in 3.4 trunk which won't ever
>> get backported and it would be a pity to have to wait
Why not back port the few features/fixes?
>> +1
> +1. You two have convinced me that 3.3 can be abandoned and we release
> 3.4.0 out of trunk but I would want to see something that makes this
> major. That might be the ipv6 support for sa-update natively or
> something else completely. And it could delay it but these release date
> will hopefully get a fire under people.
If there are no (or few) major changes, why not do the backports. They
should be trivial. Has the branch really drifted that far out of sync
with trunk?
>>> http://wiki.apache.org/spamassassin/DevelopmentMode
>>> What that actually *says* is entirely compatible with not branching.
>>> It says trunk is *usually* commit-then-review, but temporarily switches
>>> to review-then-commit shortly before release.
>>>
>>> It looks like the method doesn't come down as a rule from Apache, so we
>>> could just say, since we're so damn good at keeping trunk stable,
>>> we'll do
>>> all our releases from trunk, and keep it commit-then-review.
>>
>> I'd +1 to cut a "beta1" out of trunk.
> My opinion is to wait on beta and go through bugzilla to make a list of
> bugs to get finalized so we have a list of "goals" for the 3.4.X
> release. Then people can start the commit frenzy.
The last thing I want to see is a C-T-R commit frenzy shortly before a
release.
> Alex, what are your thoughts on NOT creating a 3.4 branch and continuing
> with trunk for development? You seem to be pro the concept above and it
> makes sense that if we switch to rtc on trunk say 1 week or so before a
> release date as defined in the ReleaseGoals, everyone is happy.
I'm quite uncomfortable with that myself, however I haven't written a
lot of code for SA in the past couple of years myself. I do think
efforts should be placed on regular review of patches against stable
branches instead.
Daryl
Re: September 30th release candidate Re: [Bug 6658] Version 3.2.5
looks like it would be reasonable to install according to web site
Posted by Axb <ax...@gmail.com>.
On 2011-09-13 23:35, Kevin A. McGrail wrote:
> On 9/13/2011 4:29 PM, Axb wrote:
>> On 2011-09-13 22:23, darxus@chaosreigns.com wrote:
>>
>>> We waste so much time backporting to the last branch. And trunk has
been
>>> incredibly stable. I hate to see releases that aren't taken from trunk,
>>> seems like a waste of time and effort.
>>
>> for once I agree with Darxus :)
>> There are a few usefull additions/fixes in 3.4 trunk which won't ever
>> get backported and it would be a pity to have to wait
>>
>> +1
> +1. You two have convinced me that 3.3 can be abandoned and we release
> 3.4.0 out of trunk but I would want to see something that makes this
> major. That might be the ipv6 support for sa-update natively or
> something else completely. And it could delay it but these release date
> will hopefully get a fire under people.
>
>>
>>> http://wiki.apache.org/spamassassin/DevelopmentMode
>>> What that actually *says* is entirely compatible with not branching.
>>> It says trunk is *usually* commit-then-review, but temporarily switches
>>> to review-then-commit shortly before release.
>>>
>>> It looks like the method doesn't come down as a rule from Apache, so we
>>> could just say, since we're so damn good at keeping trunk stable,
>>> we'll do
>>> all our releases from trunk, and keep it commit-then-review.
>>
>> I'd +1 to cut a "beta1" out of trunk.
> My opinion is to wait on beta and go through bugzilla to make a list of
> bugs to get finalized so we have a list of "goals" for the 3.4.X
> release. Then people can start the commit frenzy.
>
> Alex, what are your thoughts on NOT creating a 3.4 branch and continuing
> with trunk for development? You seem to be pro the concept above and it
> makes sense that if we switch to rtc on trunk say 1 week or so before a
> release date as defined in the ReleaseGoals, everyone is happy.
Indeed, I am +1 for not creating branches.
Years ago when there was much more dev work going on, I feel it made
sense. There was developers on steroids so freezes were necessary, but
as slow as new features are added now, I don't really see then need for
branches.
As atm, most users are interested in frequent rules /sa-updates,so IMO,
autopromoted rules should be try to be downward compatible, and if not,
be enclosed with if version tags.
Frequent SA releases may not as be as important for the average as long
as there are some rule updates available.
This is where I feel we should put emphasis.
comments?
Axb
Re: September 30th release candidate Re: [Bug 6658] Version 3.2.5
looks like it would be reasonable to install according to web site
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 9/13/2011 4:29 PM, Axb wrote:
> On 2011-09-13 22:23, darxus@chaosreigns.com wrote:
>
>> We waste so much time backporting to the last branch. And trunk has
>> been
>> incredibly stable. I hate to see releases that aren't taken from trunk,
>> seems like a waste of time and effort.
>
> for once I agree with Darxus :)
> There are a few usefull additions/fixes in 3.4 trunk which won't ever
> get backported and it would be a pity to have to wait
>
> +1
+1. You two have convinced me that 3.3 can be abandoned and we release
3.4.0 out of trunk but I would want to see something that makes this
major. That might be the ipv6 support for sa-update natively or
something else completely. And it could delay it but these release date
will hopefully get a fire under people.
>
>> http://wiki.apache.org/spamassassin/DevelopmentMode
>> What that actually *says* is entirely compatible with not branching.
>> It says trunk is *usually* commit-then-review, but temporarily switches
>> to review-then-commit shortly before release.
>>
>> It looks like the method doesn't come down as a rule from Apache, so we
>> could just say, since we're so damn good at keeping trunk stable,
>> we'll do
>> all our releases from trunk, and keep it commit-then-review.
>
> I'd +1 to cut a "beta1" out of trunk.
My opinion is to wait on beta and go through bugzilla to make a list of
bugs to get finalized so we have a list of "goals" for the 3.4.X
release. Then people can start the commit frenzy.
Alex, what are your thoughts on NOT creating a 3.4 branch and continuing
with trunk for development? You seem to be pro the concept above and it
makes sense that if we switch to rtc on trunk say 1 week or so before a
release date as defined in the ReleaseGoals, everyone is happy.
regards,
KAM
regards,
KlAM
Re: September 30th release candidate Re: [Bug 6658] Version 3.2.5
looks like it would be reasonable to install according to web site
Posted by Axb <ax...@gmail.com>.
On 2011-09-13 22:23, darxus@chaosreigns.com wrote:
> We waste so much time backporting to the last branch. And trunk has been
> incredibly stable. I hate to see releases that aren't taken from trunk,
> seems like a waste of time and effort.
for once I agree with Darxus :)
There are a few usefull additions/fixes in 3.4 trunk which won't ever
get backported and it would be a pity to have to wait
+1
> http://wiki.apache.org/spamassassin/DevelopmentMode
> What that actually *says* is entirely compatible with not branching.
> It says trunk is *usually* commit-then-review, but temporarily switches
> to review-then-commit shortly before release.
>
> It looks like the method doesn't come down as a rule from Apache, so we
> could just say, since we're so damn good at keeping trunk stable, we'll do
> all our releases from trunk, and keep it commit-then-review.
I'd +1 to cut a "beta1" out of trunk.
Re: September 30th release candidate Re: [Bug 6658] Version 3.2.5
looks like it would be reasonable to install according to web site
Posted by da...@chaosreigns.com.
On 09/13, Kevin A. McGrail wrote:
> re: 3.4.0RC. Hard to say if it's 3.3.X or a 3.4.X. We have the
> minor API change with one variable is about the only reason to call
> it 3.4 because that API change needs to wait for a major release.
> I'm not sure ANYTHING else classifies as a major change.
>
> I'd like to make a goal to get sa-update a lot cleaner and ipv6
> native release which I'm working on infrastructure for and call it
> 3.4.x.
Are you suggesting doing a release of what is now in trunk and calling it
3.3.3? That seems confusing, as far as managing branches. Would you
overwrite the existing 3.3 branch with it? I guess trunk is stable
enough, I don't have a good idea of the significance of changes, I
just like the idea of the major version staying the same meaning only
carefully selected backports of patches have been applied.
Or are you actually talking about doing another release of what's currently
in the 3.3 branch? That seems like a complete waste of time to me.
I'd be comfortable with releasing what's in trunk as 3.4.0 now and then
doing the next release in January as 3.5.0 with your IPv6 stuff.
> re: Release manager. We still have a cart before the horse issue on
> release manager due to the key signature. The number of people who
> can sign a release is dramatically too low. I might step up as the
> manager so I can document more of the process and so we have more
> hands making light work
Sounds fine. Documentation is nice.
> re: leaving 3.4 as trunk to me makes sense. We have nothing major
> enough in the works to justify otherwise EXCEPT our r-t-c rules for
> branches vs trunk. I could argue it either way which probably means
> I'd vote to maintain status quo (i.e. to move trunk to a branch and
> create a new trunk).
We waste so much time backporting to the last branch. And trunk has been
incredibly stable. I hate to see releases that aren't taken from trunk,
seems like a waste of time and effort.
http://wiki.apache.org/spamassassin/DevelopmentMode
What that actually *says* is entirely compatible with not branching.
It says trunk is *usually* commit-then-review, but temporarily switches
to review-then-commit shortly before release.
It looks like the method doesn't come down as a rule from Apache, so we
could just say, since we're so damn good at keeping trunk stable, we'll do
all our releases from trunk, and keep it commit-then-review.
--
"It's a dangerous business, Frodo, going out your front door. You step
into the Road, and if you don't keep your feet, there is no knowing
where you might be swept off to." - Bilbo Baggins
http://www.ChaosReigns.com
Re: September 30th release candidate Re: [Bug 6658] Version 3.2.5
looks like it would be reasonable to install according to web site
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
> Woo. September 30th will be a 3.4.0 release candidate, right? Who gets to
> be release manager this time?
>
> I think the general consensus was *not* to branch 3.4.0 off of trunk, but
> to leave it in trunk, and just do releases from trunk for a while?
>
> Time to wrap up some last minute bugs. Which ones actually need to get
> closed for a release?
>
My $0.02:
re: 3.4.0RC. Hard to say if it's 3.3.X or a 3.4.X. We have the minor
API change with one variable is about the only reason to call it 3.4
because that API change needs to wait for a major release. I'm not sure
ANYTHING else classifies as a major change.
I'd like to make a goal to get sa-update a lot cleaner and ipv6 native
release which I'm working on infrastructure for and call it 3.4.x.
re: Release manager. We still have a cart before the horse issue on
release manager due to the key signature. The number of people who can
sign a release is dramatically too low. I might step up as the manager
so I can document more of the process and so we have more hands making
light work
re: leaving 3.4 as trunk to me makes sense. We have nothing major
enough in the works to justify otherwise EXCEPT our r-t-c rules for
branches vs trunk. I could argue it either way which probably means I'd
vote to maintain status quo (i.e. to move trunk to a branch and create a
new trunk).
Regards,
KAM