Brazil
unread,Jun 30, 2008, 11:58:52 AM6/30/08Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to tinymux
I'm here this week, gone for the next two. Get your bugs on the list
(particularly ones which would hold up a release of 2.7) because when
I return, I may have enough fixes in hand to do the release.
Issues at the top of the pile:
498 2.6 Interaction between @flag and flag_alias unclear
503 2.6 Corruption of user attribute (vattr) table
447 2.7B03 merge() doesn't allow a UTF-8 third argument
449 2.7B03 Merge is not able to compare and replace UTF-8 sequences.
479 2.7B03 Wrap() leaves a leading space on the second line.
496 2.7B03 @mail/purge deletes folder aliases of empty folders
499 2.7B03 The way @pemit handles duplicate matches has changed
#498 is not a blocking issue. The configuration options work as
advertised, but they don't always interact as expected. When it's been
fixed, the fix will go into TinyMUX 2.6.
#503 is still a mystery. Firan normally uses a lot of memory, and at
the time, it had grown to 1.2GB of memory (the the box has only 1.5GB
installed). The evidence points to a failed memory allocation which
should have dropped the server, but we can't find in the code where
they could have happened. Definitely a stress case. I don't think this
should block a release.
#447 and #449 are related to merge(). Merger() and the support
mux_string class just don't cover UTF-8 behavior properly. There are
still ASCII assumptions there. This will hold up a release.
#479 is a regression in wrap() from 2.6. It needs to be fixed before
release.
#496 is behavior from 2.0, and was really necessary to clean up and
validate the A_FOLDERS attribute, however, now, we need a way to
delete a folder name separate from whether the folder contains mail
items. This is probably not a release blocking issue as this isn't a
regression.
#499 needs some investigation. It might not be a release blocking
issue, but it does represent different behavior from 2.6.
Brazil