[ home | blog home | recent activity | guestbook | plugins i'm using (19) ]
Page 1 of 73 >> (less recent)
Miro 3.5 status (roadmap)
Miro Community 1.1.1 status (roadmap)
Miro Community 1.2 status (roadmap)
Paul:
Janet:
Luc:
Ben:
Will:
Order of business
Bugzilla stats for Miro:
We've had a few servers are a hosting facility in Marlboro, MA, USA for a long time now. Over the last year, we've been moving applications, sites, systems and all that from the servers in Marlboro to the Amazon cloud system. We're in the process of moving the last set of things to Amazon.
We're working on making the transition go smoothly, but there are a lot of pieces and it's possible we'll miss something along the way. If you notice PCF/Miro-related sites being down, let me know.
Miro 3.5 status (roadmap)
Miro Community 1.1.1 status (roadmap)
Paul:
Ben:
Will:
Janet:
Order of business
Bugzilla stats for Miro:
Lot's of bug churn this week in part because of focus on regression testing and because of the creation (and heavy usage of) the PCF bug triage Firefox addon.
Miro 3.5 status (roadmap)
Miro Community 1.1 status (roadmap)
Paul:
Ben:
Will:
Order of business
Bugzilla stats for Miro:
I spent a good amount of time over the last few months migrating Miro on Windows to a new Windows build environment that uses Python 2.6.5 and Visual C++ 9.0 (part of Visual Studio 2008).
I landed the changes two weeks ago. Janet, Ben and I identified a couple of problems and sorted those out. Last week I got the Windows build box to produce nightlies without requiring any babysitting.
Yay!
Features of the new Windows build environment:
get_requirements.sh script that downloads
the versions of Python and libraries that you need automatically.
This also means that we can require Python 2.6 or later on all platforms for Miro. Therefore we can:
The one thing we still want to do is upgrade from gtk 2.16 to gtk 2.20. Bug 14037 covers the problems here. We're blocked by Bug 625972 in gtk.
I've written up instructions on setting up the new Windows build environment. It takes me about 30 minutes to do--mostly because it takes a while to install Visual C++ 9.0 Express. It's much easier to set up the new environment than the previous environment. When I first started at PCF a few years ago, it took me a couple of days to get the Windows build environment working.
For more details on the new Windows build environment, see the wiki page on WindowsBuildDocs.
Rick kindly pointed out that comments on my blog were broken. Totally my fault--I've been working on PyBlosxom on and off and a couple of weeks ago I updated my blog to use the latest version of PyBlosxom in git master and didn't grab the latest comments plugin.
Comments were getting into the moderator queue (I moderate all comments), but when the comments plugin went to send me a notification email, it'd die.
They're working again.
Last night, I spent a few hours going through all the videos from PyOhio 2010, added metadata from the PyOhio site, added notes about video issues, and approved all of the videos except one which I'm talking with Carl about.
It looks like PyOhio 2010 was a really great conference: the talks are really great, you can feel the energy in the rooms from the people who attended, the questions are interesting, and the videos from the conference are fantastic. Also, I'm a huge +1 on using the headset mics--they absolutely make a difference in being able to hear the presenter throughout the video.
Here are three sessions I watched all the way through:
Sessions from PyOhio 2010 are in the PyOhio 2010 category. Take some time today to browse the sessions and watch the ones that interest you.
Also, I'm sitting on videos for two other conferences: DjangoConf EU and Kiwi PyCon. I'm hoping to get to them in the next couple of weeks. I did PyOhio 2010 videos last night because Carl needed someone to spot-check them to make sure the uploads were good.
Miro 3.5 status (roadmap)
Miro Community 1.1 status (roadmap)
Janet:
Ben:
Will:
Paul:
Order of business
Bugzilla stats for Miro:
There are two big hurdles to get through when starting on a bug before I'm in a position where I can fix it. I think the bulk of the time spent on most bugs is in getting through these two hurdles. If we could somehow reduce the amount of time and energy I spend on getting through the two hurdles, we can increase the speed that I can fix bugs.
Copyright 2008 Flickr user foxtongue
The first hurdle: what is the problem?
I think most people confuse the question "what is the problem" with "what's causing the problem". These are two distinct questions. The first one can only be answered by whoever reported the problem and this hurdle is a communication hurdle. I spend a lot of time trying to coach people into explaining the problem they have in a way that's coherent and complete.
It's not uncommon to get bug reports along the lines of "something's wrong and Miro doesn't work". I'm psyched someone has taken the time to report the issue, but there isn't enough detail here for me to do anything. In order for me to do something with this bug, I spend time walking the reporter through giving me enough details such that I have a good idea as to what the problem is. Because this requires communicating back and forth, this can take anywhere from a few hours to a few weeks to transpire.
Because it takes so long and requires me to ask 20 questions, I'm pretty sure most bug reporters find this phase very frustrating. Some question and answer volleys are really frustrating for me, too. I want to help--I just don't know what the problem is.
Assuming we get past that hurdle, then the second hurdle comes into play....
The second hurdle: what is the cause of the problem?
This hurdle is sometimes difficult because I can't reproduce the problem. I may not have the right context (e.g. "Problem XYZ happens to all people in Ecuador") or the right equipment (e.g. "Problem XYZ happens to people using Windows XP SP2 with video card Foo"). I'll read through code and work with the reporter to try to figure out the cause. Sometimes it works and sometimes it doesn't. When it doesn't it's really frustrating.
Most bugs aren't like that, though. I'm able to either reproduce the context and equipment or I'm able to use a reasonable facsimile. Then figuring out the cause is entirely on my shoulders and I can work through it like I do most things: code spelunking, research, Google searches, talking with co-workers, talking with upstream developers, ....
How can you help?
The following helps a lot:
Guess what....
This isn't specific to me or Miro! This is true of all FLOSS applications that you use: we're all working hard to build the best applications ever. Doing the above helps everyone.
Miro 3.5 status (roadmap)
Miro Community 1.1 status (roadmap)
Janet:
Ben:
Will:
Luc:
Paul:
Order of business
Bugzilla stats for Miro:
Page 1 of 73 >> (less recent)
All contents Copyright 1996 to 2010 Will Guaraldi Kahn-Greene.
This work is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.