Motivation behind recent selections of tickets marked blocks?:8.2.0?

[John Gilmore]

> 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
     for 8.2.0.]

  * 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 -
     http://dev.laptop.org/ticket/6995#comment:19

  *  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
release naming/scheduling.)

> 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.

	John