Re: RFC: Linux Bug Tracking & Feature Tracking DB

David Ford
2002-01-02T02:30:36Z

>
>
>>Starting a browser is equivalent to starting a mail client. In some
>>instances it's the same program.
>>
>
>keeping a terminal with ssh open all day is feasible (and is what I
>and a lot of others probably do). Keeping mozilla open all day is
>not practical. (and no, w3m/lynx etc are not practical for using
>bugzilla imo).
>

Eh? Why isn't it? I keep it open for weeks if it doesn't crash.

>>Hitting 2-3 keypresses to archive an email...how do you manage that
>>archive v.s. it being managed for you w/ bugzilla?
>>
>
>both mua's I use have comprehensive indexing/searching abilities.
>s25<enter> saves a patch for applying later.
>
>cat ~/25 | patch -p1 is all I need to do, plus I have an archive
>of patches applied on what date, along with the descriptive mails
>that went with them.
>
>Effortless.
>
>If a patch needs reversing, I load the mua, move the mail to another
>folder, and do the same with patch -R
>
>Dave.
>

Then your system works for you, but it doesn't make anything available
for anyone else nor does it allow for anything other than the simple
collection of emails/patches. That's the point of an accessible
database. Over years of development, trying to maintain a comprehensive
system would require you to index what "25" relates to.

The point of this DB in discussion is to make it easier for everyone,
from developer to the random person who only reads lkml when he needs to
find an answer. Make it easier to research, catalog, reference,
explain, and derive all the parts of a given bug.

For example, the ECN issue. Anyone from developer to Joe Admin could
look up "connection failed" and get back a group of results with a high
"ECN" hit rate. A few seconds to type it in and a minute later he has
probably put 0 in tcp_ecn and happily wanders away.

David