Motivation behind recent selections of tickets marked blocks?:8.2.0?
gnu at toad.com
Mon Aug 11 03:53:26 EDT 2008
> I've noticed you tagging lots of tickets over the last few days for
> consideration as 8.2.0 blockers. Some of your selections make good sense
> to me, like the GPL tickets (#4265), but others make less sense to me,
> like the debuginfo packages issue (#4264), the TurtleArt naming issue
> (#5941), the boot-lock/pretty-boot coupling issue (#7896), and the
> grab-bag of quality issues (#7413). Could you say a few words about the
> vision underlying your choices so that I can compare it to my own
> understanding of what the 8.2.0 release needs to accomplish?
Four categories, really:
* Longstanding major issues, like GPL compliance (#4265), failing to
listen for arp or multicast packets while suspended (#4616),
Python programs polling all the time (#4677). These often have
unusual follow-on effects, like flakey collaboration, ohm's
inability to tell an idle machine from one that's doing work, or
legal or reputational liability. Often, significant work has
been done since the last release, but not quite enough to close
the ticket. The last nits in these never seem to get closed out
except toward the end of a release cycle. [The Python one, when
run to ground, ended up still needing more work than can be done
* Trivial fixes that will be visible in the field. The sort of
thing that somebody adept at patching packages in your release
system can knock off five or six of in a day. Like the debuginfo
packages (#4264), or TurteArt (#5941), or the addition of ten
lines of copyright notice that would let Record go into the Sugar
packages in Ubuntu (#6891), or a visible GPL notice in the Sugar
"About" box (#6929). It took me an extra two hours to debug the
Python polling thing because it took that long to find debug
symbols. How many people who find a bug in 8.2.0 in the field
will run out of time and give up, rather than run it to ground,
if that small issue remains unaddressed? How many kids won't
know they are free to, and encouraged to, modify Sugar?
* Major opportunities with minor coding impact. If the user can
merely tell the machine to turn off Mesh, a small Ohm change can
save huge amounts of power (autosuspended laptop goes from 1.9W
to about 1.0W, and a closed-lid laptop goes from 1.1W to 0.25W,
letting it survive for days instead of 8 hours) - #7879. Most of
our deployments don't use mesh, but it burns most of a watt for
every laptop uselessly. Usually there's some odd bottleneck that
prevented anyone from noticing the opportunity; in this case,
Eben's off-the-cuff UI choice that eliminated the "Turn Off"
action on the Mesh icon -
* Collector tickets that have been targeted for 8.2.0 for months,
but which might not have been looked at recently. E.g. "high
quality release" #7413.
Every developer was encouraged in email to devel to mark tickets as
potential ("?") blockers. I didn't expect that the ones I marked
would all become blockers; I just expected someone responsible for
release quality would look at them and make their own decision.
The boot-lock/pretty-boot issue is not marked for blocking 8.2.0 --
it's marked as a question of whether it should block 8.3.0. (Oops,
maybe you're calling the next release 9.1.0 -- I'm unclear on the
> P.S. - Thanks very much for all the time you've spent combing Trac for
> tickets that matter to you...
You're welcome. Lots of stuff falls through the cracks, by necessity.
So it's useful for me to go back through and try to get closure on
things that I've already put significant time into diagnosing or fixing.
More information about the Devel