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

[Karl Goetz]

On Tue, 2008-07-22 at 00:47 -0400, Bake Timmons wrote:
> 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.

> 
> 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):

Searching for policy bugs is a good starter in debian - all non-free
stuff is apolicy violation by defnition.
Looking at the RC bug count for Lenny is another way of finding out
obvious errors - because someone else has already found them ;)

Only thing to bear in mind is that (for example) Debian considers a non
modifable document to be non-free. gNewSense doesnt.

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

Cool. I started doing a similar thing by trawling through the BTS. I
stopped when i ran out of time (this was ~ the time the ubuntu-modules
package became KFV focus).

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

sounds workable. if it has links to revent upstream (debian+ubuntu+linux
bts) even better ;)

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

I dont think "Adopted" would need a seperate box. under "Summary" just
add "i'mw orking on this" and of course a link to the bug report.

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

A perfect example is the Xorg GLX code. Closed in Ubuntu ("we dont use
XFree86"), and ignored in debian (for 4 years).


> 
> (*): 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.

Debians BTS is mail driven. There is a web search, but its only helpful
if your looking for a package/bugnumber/type of bug. not helpful for
general searches.

For ubuntu you can use launchpads web seearch, or the mail interface.
Launchpads mail interfac should be largely debbugs compatible.
kk

-- 
Karl Goetz <address@hidden>

signature.asc
Description: This is a digitally signed message part