[IronPython] SCons on IronPython 2.0B2

[Jeff Hardy]

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
<dinov at exchange.microsoft.com> 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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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
> <dinov at exchange.microsoft.com> 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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy
> > Sent: Friday, May 02, 2008 11:20 PM
> > To: Discussion of IronPython; dev at scons.tigris.org
> > 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: dev-unsubscribe at scons.tigris.org
> > For additional commands, e-mail: dev-help at scons.tigris.org
> >
> >
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>