[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gNewSense-users] The next highest priorities for gNewSense?
From: |
Karl Goetz |
Subject: |
Re: [gNewSense-users] The next highest priorities for gNewSense? |
Date: |
Wed, 23 Jul 2008 21:25:06 +0930 |
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