On Tue, Nov 17, 2009 at 13:36, Mark Martinec <[email protected]> wrote: > On Tuesday 17 November 2009 07:23:33 Warren Togami wrote: >> Time for 3.3.0 beta? Anything else we should do first? > > [Warren, elsewhere]: >> I propose we release 3.3.0 beta ASAP, after the scoring commits I just made >> in Bug #6155. >> Prior to 3.3.0 final release we should attempt to fix this bug properly. >> If we cannot, then we should minimally make Bug #6232 not dangerous. > > I have some possible solutions for Bug #6232, just haven't decided yet > which one is closest to the intentions of the Net::DNS writers. The > docs about a supposed internal representation is sketchy, the intention > has to be deduced from source code. Docs on the underlying Net::DNS::RR > is much more explicit.
IMO we could release a beta with this unfixed, jsut to get rules tested. WDYT? > Before the beta I think the problem reports with implications to > compatibility should be resolved, at least to the point where > no further incompatible changes after a beta will be necessary. > In particular I have Bug 6187 and Bug 6203 in mind. 6187: ok. let's fix it. 6203: I don't particularly care either way; if someone wishes to fix it before release, great. > About the 6203, I have some stats collected. Also the AWL race condition: > https://issues.apache.org/SpamAssassin/show_bug.cgi?id=4642#c1 > is worrying me. I'm using a workaround (attempt INSERT first, and > if that fails do the UPDATE), but the change is nontrivial, and depends > on a unique key constraint failing to work properly. If you like, > I can submit it for consideration - can be reverted later if not approved. > An alternative is to use ON DUPLICATE KEY UPDATE, but that seems not > to be liked according to Bug 5998. If you can provoke Michael into a response ;) and get agreement, then whatever you guys decide is good. However I don't think it is safe to delay beta release for this, as it's a pretty thorny problem AFAICT. > The suggestion in Bug 4508 (the patch in Comment 3) seems quite useful > and not too intrusive on the current/default usage. Any thoughts on that? > Do we need a CLA from its author? It does look pretty good, but code-volume-wise I think we would need a CLA. > Btw, there are like two or three small documentation-change requests > there. If someone has some spare cycles, it would be nice to get rid of > these problem reports. I suggest we ensure that tickets use these priorities: P1 = must be fixed before 3.3.0 beta release P2 = must be fixed before 3.3.0 GA release P3 = nice to fix before GA, but should not impede things P4, P5 = not really that important once we get through all the P1s, we're ready to go ;) -- --j.
