July Bug Day Roundup
Hi All, A pretty frenetic bug day saw a LOT of cruft ejected from the collector. It also saw a good few bugs resolved, and a lot more marked as resolved that had been fixed along the way. Also, there's now documentation of what the various collector states mean at: http://dev.zope.org/CVS/CollectorStatuses Some points of it are still up for discussion, so please join in at zope-coders@zope.org if you have a view! All in all, a massive 64 issues were dealt with! Many thanks to all who helped out, look forward to seeing as many of you as possible for the next one at the end of August... cheers, Chris Here's what got dealt with (there are "player stats" at the bottom ;-) Resolved: #13 - Undo with multiple ZEO´s mounted #248 - refresh does not work for products initialized in the old style #290 - Usage of trry: except: in Zope source #515 - Collecor.__init__ stores new brains class in volatile attribute #552 - Import obj w/ Proxy roles into Zope w/o role fails #578 - ImplicitAcquisitionWrapper claim to be callable() #691 - KeywordIndex and callable #692 - DateTime fails to pass european dates #740 - _tzoffset returns wrong offset #891 - Enable locking of RESPONSE.setStatus and RESPONSE.setBody #1156 - getObject fails to return objects which redefine __len__ #1233 - ZOPE_CONFIG environment var for app=Zope.app() #1252 - VIRTUAL_URL #1279 - --config-file support for test.py #1295 - 2.7.0 tutorial Lesson 6 #1370 - customDefaultZPTReport.dtml Creates Invalid HTML #1416 - DateTime class doesn't initialize off DateTime instance #1421 - DateTime doesn't always raise a SyntaxError for bad dates #1439 - Zope 2.7.2 for Windows uses Python 2.3.3 #1440 - Zope 2.7.2 lists as "unreleased version" #1441 - Silly Borg Headers tempt MS Office #1442 - Example cache sizes in zope.conf, using MB or kB #1445 - test.py problems with -p and -v(v) Rejected: #18 - sequence-last inducts error when used in nested dtml-in #37 - Z ODBC Database with DB2 TIMESTAMP# #50 - DCO2 based ZOracle Adapter does not use bind variables #154 - Zope crashes on external method loading dll #229 - Paste object without view permission on management screen #237 - Version editing via FTP/WebDAV #247 - permission strings in ZMI aren't consistently capitalized #418 - DTML anonymizes exceptions #522 - "Owned" assumes access to the ObjectManagerItem Interface #717 - support selection:{type} in manage_propertiesForm #746 - dtml-sendmail expected string, unicode found #775 - manage_changeProperties can't set boolean properties to false #1223 - Problem with meta_type #1308 - (duplicate) Need "actual URL" method #1361 - (duplicate) etag header obliterated no matter what #1378 - ExtensionClass Bug: unbound C method... #1391 - tal: namspace attributes dropped before i18n processing #1404 - envirnoment and cgi_environment don't appear to work #1419 - Transience should return True|False, not 1|0 #1424 - Zope returns 400 to report an internal error #1427 - Accept config file from stdin #1444 - (duplicate) ZODB Error from Historical Compare #1446 - TAL parse error on tags inside script #1449 - DateTime wrong when 12:00:00AM #1448 - "cache picture and css mixing" Wontfix: #15 - sqlgroup.py enhancements - set, noparens, and comma tags #127 - css files defines absolut sizes #136 - FTP Upload raises Unauthorized after file upload #371 - DTML and Python security function APIs are different #553 - ZMI "find" doesnt find in File with text #564 - Content-length of HEAD responses should be based on *parsed* #729 - Edit page title tag should show the object title or id #872 - Numbers in STX Tables #1277 - manage_FTPget of Image is sad. #1428 - Serve xml as application/xml instead of text/xml Deferred: (meaning act on these or they get rejected next month) #428 - FTP and large file uploads #526 - anonymous users can sometimes view historical revisions #804 - "make clean" doesn't run #1398 - BTree raise SystemError on FreeBSD #1401 - SystemError in SessionDataManager And here's the "player stats" ;-) Resolved Rejected Wontfixed Deferred Assists chrisw 16 19 7 2 ajung 6 6 2 2 ctheune 1 1 2 arnarl 5 shh 2 casey 2 jim 1 evan 1 mcdonc 1 stevea 1 brian 1 -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Sat, 31 Jul 2004, Chris Withers wrote:
Also, there's now documentation of what the various collector states mean at:
http://dev.zope.org/CVS/CollectorStatuses
Some points of it are still up for discussion, so please join in at zope-coders@zope.org if you have a view!
I have a pretty different conception of the states. I've created another page, linked into chris', with my alternate framing, at: http://dev.zope.org/CVS/CollectorStatusesAlt Obviously, we need to resolve the differences so all the supporters use the states the same way. I hardly participate in the zope collector (though i do use collectors all the time for a lot of projects), so i'll defer to the people who actually use it - but want to suggest this framing because i think it'll help reduce the chaos.
All in all, a massive 64 issues were dealt with! Many thanks to all who helped out, look forward to seeing as many of you as possible for the next one at the end of August...
Thanks to all for making zope better, and particularly to chris for shepherding the effort! Ken klm@zope.com
Ken Manheimer wrote:
I have a pretty different conception of the states. I've created another page, linked into chris', with my alternate framing, at:
http://dev.zope.org/CVS/CollectorStatusesAlt
Obviously, we need to resolve the differences so all the supporters use the states the same way. I hardly participate in the zope collector (though i do use collectors all the time for a lot of projects), so i'll defer to the people who actually use it - but want to suggest this framing because i think it'll help reduce the chaos.
I'm not sure how muddying the waters deceases the chaos. *grumps* Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Mon, 9 Aug 2004, Chris Withers wrote:
Ken Manheimer wrote:
I have a pretty different conception of the states. I've created another page, linked into chris', with my alternate framing, at:
http://dev.zope.org/CVS/CollectorStatusesAlt
Obviously, we need to resolve the differences so all the supporters use the states the same way. I hardly participate in the zope collector (though i do use collectors all the time for a lot of projects), so i'll defer to the people who actually use it - but want to suggest this framing because i think it'll help reduce the chaos.
I'm not sure how muddying the waters deceases the chaos.
Then why were you asking for feedback in the first place? A few supporters (chris, andreas, and dieter, at least) have indicated that they had different interpretations than you did, more similar to what i am suggesting. So at the least, the waters were already at least this muddy. The question, then, is how to settle on one set of states. I think given a reasonable simple set of states we can all agree on, someone should be able to find time to adjust the collector. So i'd just like to get at the set of states. At this point there's more than the two alternative sets (CollectorStatuses and CollectorStatusesAlt) on the table. Items i can recall off-the-top-of-my-head: - Lennert has proposed a "Submitted" state (which i interpret as being for issues that are pending disposition), instead of pending (i think "Submitted" is an improvement on "Pending") - and "Pending" would be for items awaiting more info (i think that should instead be either "Accepted", if someone is taking responsibility, if only to "Reject" the thing if no more info is forthcoming, else "Deferred" if nobody is taking responsibility - it can go back to "Submitted" if more info comes... - sidnei mentioned that roundup calls the initial state "unread" (but i don't think that really applies to our initial state, because things may be read but not assigned any handling - and i don't think we need a state for truly "unread") There may be others. I guess i think we could make progress talking each state through. Ken klm@zope.com
On Mon, Aug 09, 2004 at 05:46:41PM -0400, Ken Manheimer wrote:
- Lennert has proposed a "Submitted" state (which i interpret as being for issues that are pending disposition), instead of pending (i think "Submitted" is an improvement on "Pending")
+1.
- and "Pending" would be for items awaiting more info (i think that should instead be either "Accepted", if someone is taking responsibility, if only to "Reject" the thing if no more info is forthcoming, else "Deferred" if nobody is taking responsibility - it can go back to "Submitted" if more info comes...
fwiw I've never liked "pending" - it begs the question "Pending what?". -- Paul Winkler http://www.slinkp.com
participants (3)
-
Chris Withers -
Ken Manheimer -
Paul Winkler