Well, Python Bug Day 4 was held yesterday. 12 patches and 10 bugs were closed. Also, there are some bugs that are almost closable on http://python.org/moin/PythonBugDayStatus. These need to be reviewed by a committer. Things I noticed: * One one hand, no regressions were introduced, as far as I can tell. On the other hand, it's pretty hard to fix a lot of bugs if you're trying to keep regressions to a minimum. * Most people just don't know where to start with fixing the bugs. We had a list of 'easy-to-fix' bugs on the second bug day, and it worked out pretty well. We should probably prepare one for the next one as well. * The Python bug list may seem pretty large, but it isn't as bad it looks. Most of the bugs are either a corner case or a design limitation. Both types are hard to fix; there are very few glaringly obvious, easy-to-fix bugs left. * I'm still too much of a newbie developer to run a bug day completely by myself. I can help out people with the process of fixing bugs, but I can't simultaneously learn about new parts of the Python source. Conclusions for the next bug day: * I'm willing to organize another bug day, but I'm not going to do it alone. A combination of a more experienced developer (for the hard technical decisions/discussions) and me (for introducing new developers to the process) would probably work out better. * There should be a way to mark bugs as "easy-to-fix". I'll try to work in this into Roundup somehow, but until we migrate to that, I propose that if anyone (committer or otherwise) sees a bug that seems easy to fix for a new developer, (s)he should add it to the PythonBugDayStatus page. * Right before a release probably isn't the best time to hold a bug day. Cheers, Johannes
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4