Hi Dino, Thanks for all the information! I find it helpful when filing bugs to know how the team prioritizes bugs, what they look for, etc. It makes it easier to game the system :)
WRT negative conditions, these can be the worst to deal with because they often mask the real issue; the app is resilient enough to catch an error, but then fails during the error handling. The first task when testing a new app is usually making sure that the error handling works, even before any features can be tested. I'll keep up my crazy crusade of testing random apps as long as you guys keep fixing the bugs that are filed. The quality of each release is constantly improving, and that's really good news for fans of Python. You guys are doing a fantastic job! Now, about community contributions... :) -Jeff On Mon, May 5, 2008 at 11:57 AM, Dino Viehland <[EMAIL PROTECTED]> wrote: > Generally speaking the more information we have about a bug the better we can > make the call on it. The most important thing I'd suggest adding is what > scenario the bug is blocking. For example if you reported 5 Trac related > bugs and 5 SCons related bugs and we fixed 3 Trac bugs and 2 SCons bugs that > might not be quite as useful as fixing 5 SCons bugs. So just identifying the > scenario will help us drive end-to-end scenarios to completion rather than > fixing a bunch of random bugs which might not end up enabling anything! > > But in general some insight into how we triage bugs might be useful. > Generally speaking we 1st prioritize bugs in the core runtime - that includes > the parser, compiler, and core data types. Basically anything in > IronPython.dll and everything in IronPython.Modules.dll gets a lower > priority. Part of that is that we want to be as true to the core language as > possible and therefore those fixes are viewed as more important. The other > part of that is that we hope to open up IronPython.Modules.dll and allow user > contributions. > > >From there I'd say the next thing we look at is votes and priority. Votes > >are of course easy to understand - I'd suggest sending your bug reports to > >the mailing list as well so that you can get that number bumped up. I'm > >guessing not everyone is subscribed to the RSS feed of IronPython bug > >reports like I am so it's likely that people don't see the issues even if > >they'd be interested in seeing them get fixed. Priority is of course harder > >to understand. I already mentioned modules which we tend to look at as a > >lower priority. We also tend to look at negative scenarios (e.g. exception > >messages, wrong exception, etc...) as having a lower priority - sometimes > >that's the wrong call as certain frameworks have heavy reliance upon the > >negative scenarios working correctly. From there it's largely a gut-call > >based upon what everyone sitting around doing the triage thinks. Usually if > >anyone thinks we should raise the priority we do - so on that point I'd > >suggest indicating what p > riority you think the bug should have as well. If everyone always said high > priority we'd be back to coming up w/ the levels entirely ourselves but if > discretion is used we'd likely respect the proposed priorities. > > Finally I don't know how much being set to 2.1 matters. The real release to > watch out for is Future. Those are bugs we don't think we can get to anytime > soon due to deep architectural issues. If something's been moved to 2.1 then > it's more the case that we think this can wait and that's an easy decision to > reverse. > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Hardy > > Sent: Saturday, May 03, 2008 12:40 AM > To: Discussion of IronPython > Subject: Re: [IronPython] SCons on IronPython 2.0B2 > > Hi Dino, > Yeah, _winreg is what's missing. Good to hear that it will be coming soon! > > Not every bug I've filed is related to SCons (some are Trac-related, > and maybe even a couple from elsewhere). I've just been testing random > apps (primarily WSGI-enabled webapps), seeing what breaks, and filing > bugs. > > What's the best way to push up the priority of a bug? Codeplex > comments? Mailing list? I know of a few that are set for 2.1 that I'd > like to see sooner. > > -Jeff > > > On Sat, May 3, 2008 at 12:49 AM, Dino Viehland > <[EMAIL PROTECTED]> wrote: > > Is "no registry module" _winreg or is it something else? The good news > > here might be that Srivatsn has implemented this for Beta 3 (along w/ > > cmath) but it didn't quite make it into b2. > > > > Let us know if we end up pushing any bugs to statuses you don't like. BTW > > are all the bugs you've opened related to SCons or are some other issues? > > I'd also not mind seeing a bug calling for a dummy signal module :). > > > > And of course thanks for the update! > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Hardy > > Sent: Friday, May 02, 2008 11:20 PM > > To: Discussion of IronPython; [EMAIL PROTECTED] > > Subject: [IronPython] SCons on IronPython 2.0B2 > > > > Hi all, > > SCons now 'works' on IronPython 2.0b2. I can compile a very simple C++ > > project, but there are a few caveats: > > * no registry module, so no tool detection. The SConscript needs to import > > the environment to find any tools. > > * Need a dummy signal module (attached) > > * Need a subprocess module > > (http://www.ironpython.info/index.php/The_subprocess_module) > > * There are a few small oddities, so the attached patch to SCons is > > required. Relevant IronPython bugs have been filed, of course :) > > > > I have opened SCons issue #2043 to track all of this. I hope I've included > > all of the details. The signal and subprocess modules need to be in the > > IronPython\Lib directory (or somewhere in IRONPYTHONPATH). > > Obviously, the Python 2.5 standard library must be available as well. > > > > I don't think the patch should be included in its current condition; I'm > > not 100% sure all the changes work with pure Python. It's pretty simple to > > block stuff off with sys.platform == 'cli', though. > > > > I'm going to try to push it a little harder now, but this is a good first > > start. > > > > -Jeff > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > Users mailing list > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
