Procedure for very large changes?

[Theo Van Dinter <fe...@kluge.net>]

I'm wondering what our general procedure should be towards making very
large changes to the code?  For instance, I'm currently working on ripping
out Mail::Audit-related code and making things use the new MIME parser
data instead of NoMailAudit's stuff (note: this doesn't include making
PerMsgStatus use the MIME parser data instead of it's internal stuff --
that's another fun large change...)

Summary of changes made so far:

- Remove all documentation and such about Mail::Audit
- Stop trying to encapsulate NoMailAudit objects
- Deleted: AuditMessage.pm, PhraseFreqs.pm, Message.pm, EncappedMessage.pm, EncappedMIME.pm
- At check() time, all X-Spam-* headers are removed, not just the ones the local installation may have
  added
- rewrite_as_spam and rewrite_headers now return a _new_ NoMailAudit object instead of mucking around with
  the current one.
- rewrite_headers() uses the pristine headers not the ones in the NoMailAudit object.
- due to the last two, rewrite_headers() will now leave all original headers in the message (it'll still
  rewrite subject, from, and to, as necessary) and just add new ones (x-spam-*).  this means that scanning
  a message twice will cause multiple x-spam-* headers of the same type to be in the header.  it's
  definitely not as clean as before, but it will stop people asking "why do the headers say one thing and
  the body say something else?"  the question will now be "why do I have 2 X-Spam-Status headers?", but
  hopefully that'll be more obvious.
- NoMailAudit is essentially passing stuff onto MIME.pm now.  I'm debating about merging any NMA code into
  MIME.pm, and getting rid of NMA.
- removed a bunch of NMA code
- MIME parser now keeps pristine body, doesn't do header decoding (lets MIME.pm do that), and stores raw
  headers with CRLF and such.
- stripped out "metadata" code, which wasn't used anyway.

Thoughts?

-- 
Randomly Generated Tagline:
It could be one of these chemicals here that makes him so smart.  Lisa,
 maybe you should try some of this.
 
 		-- Homer Simpson
 		   Bart the Genius

Re: Procedure for very large changes?

[Duncan Findlay <du...@debian.org>]

On Sun, Jan 18, 2004 at 07:23:23PM -0500, Theo Van Dinter wrote:
> I'm wondering what our general procedure should be towards making very
> large changes to the code?  For instance, I'm currently working on ripping
> out Mail::Audit-related code and making things use the new MIME parser
> data instead of NoMailAudit's stuff (note: this doesn't include making
> PerMsgStatus use the MIME parser data instead of it's internal stuff --
> that's another fun large change...)

I suspect with this kind of a change, we should probably vote on its
worthiness before committing, and you should probably file a bug and
attach a patch. (I think that's what I've done before if I wasn't sure
something was ready to commit or needed discussion.) I'd probably +1 this change once I saw a patch :-)

-- 
Duncan Findlay

Re: Procedure for very large changes?

[Sander Striker <st...@apache.org>]

On Mon, 2004-01-19 at 01:23, Theo Van Dinter wrote:
> I'm wondering what our general procedure should be towards making very
> large changes to the code?

Suggestion: create a branch, commit it there.  Then the rest can review
the changes and test the code.  If it gets general approvement, merge it
to trunk and delete the branch.  Otherwise simply delete the branch.


Sander