[gNewSense-users] The next highest priorities for gNewSense?

[Bake Timmons]

With linux-ubuntu-modules now in an acceptable state, it is natural to
consider the next *priorities* for gNewSense, such as continuing KFV
and PFV, which will inevitably uncover freedom bugs.

Is it more important to complete a given section or to find the
freedom bugs as soon as possible?  IMO, I like feeling warm and fuzzy
seeing a wiki section completed, but I like much more finding and
handling freedom bugs ASAP, however we do it and wherever they may be.
After all, that is why we *interrupted* our work on KFV on the whole
kernel months ago to go after linux-ubuntu-modules specifically, which
was already *known* to have freedom bugs such as non-free firmware.

Of course, quickly finding bugs is especially important given the
upgrade cycle and scarce manpower.  Thus, I have interrupted my quiet
activity in the arch section and have started to look for freedom bugs
in the Debian BTS by doing this search in Google Groups(*) (and
sorting by date):

(licensing OR licensed OR non-free) group:linux.debian.bugs.dist


Out of hundreds of Debian bugs raised so far *this year*, I have
recorded a few dozen related to freedom.  Each entry I have saved in
Emacs so far is like this:

http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/f3452d4329f6c8f1/0f9e0a1c0de6582d?lnk=st&q=#0f9e0a1c0de6582d
Bug#491354: texlive-fonts-extra: No license statement for wsuipa fonts      
Group: linux.debian.bugs.dist
Frank Küster address@hidden linux debian bugs dist Norbert                 
Preining <address@hidden> wrote: On Fr, 18 Jul 2008, Frank Küster         
wrote: Upstream just notified us that (some or all, not checked) files       
in /usr/share/texmf-texlive/fonts/source/public/wsuipa/ are missing a license
statement. ...                                                               

Before I interact with the gNewSense wiki or BTS, I just wanted to
know if anyone has any preferences about the recording of this
information.  We could just post entries derived from a search on a
wiki page and then people could adopt an entry, examine the
corresponding (source) package in gNewSense, and submit a report to
gNewSense BTS if appropriate.

We could make a freedom bug wiki table like (best viewed with fixed
font):

Freedom | Adopted        | Open / | Date of   | Summary
Bug #   |                | Bug /  | Bug       |
        |                | No Bug |           |
---------------------------------------------------------------------
491354  | NEEDS ADOPTING | Open   | Jul 20 08 | texlive-fonts-extra: No license 
statement for wsuipa fonts

The natural order of rows would seem to be by Bug #.  If any Ubuntu
bugs are found, it is probably best to just put those in a separate
table on the same page or on a separate page.  We also could make the
Bug # and the Summary link to the URL of the original thread on the
mailing list or news group.  A potential bug would start out Open; if
we determined that there is a corresponding bug in gNewSense, we file
the bug, and change Open to Bug (with a link to the gNewSense BTS bug
report); otherwise, we change Open to No Bug.  The Date of Bug could
be *different values*, since the search results might repeat the same
Bug # at another anchor (with a possibly different date) in the thread
for that bug.  However, just as long as there is a link to the correct
thread, it seems good enough to me.

The location of this table could be something like:

http://wiki.gnewsense.org/External-BTS-freedom-bugs

Note that these bugs could be in any package, not just the Linux
kernel.  I suppose there may be older yet still relevant freedom bugs
that we could add from Debian as well as some from the Ubuntu BTS.
All together, we very likely are talking about many dozens of bugs.

Advantages of taking this intermediate step of recording search
results in a table before deciding to directly file a bug on an ad-hoc
basis:

1. It reduces the chance of duplicate work.

2. It might make for a clearer division of labor and indication of
   priorities.  At first I thought the table might be overkill, but it
   is good to realize how hard some of the Debian people work
   sometimes to track down these bugs!  Such a bug might mean a little
   work for us, too.

3. It adds another layer of scrutiny to these bugs and perhaps saves
   those attending to the gNewSense BTS a little work.


Have I missed anything?  Please make suggestions, such as any
improvements to the above table row format.  I want it to be as useful
as possible with a minimum of editing required from the adopter.
(Note that only two fields need to be edited.)

Of course, if this kind of thing ever gets busy enough, I would have
to look at handling it with KFV Mode. :)

Thanks for your attention.

(*): I cannot think of a better way to search for bugs than Google
Groups.  *Direct* searching of BTSes in the past has seemed horribly
clumsy for me.