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
