Re: regression tracking (Re: Linux 2.6.21)

On Sat, Jun 16, 2007 at 07:03:44AM +0200, Oleg Verych wrote:
...
On Sat, Jun 16, 2007 at 04:55:16AM +0200, Adrian Bunk wrote:
On Sat, Jun 16, 2007 at 03:32:36AM +0200, Oleg Verych wrote:
On Sat, Jun 16, 2007 at 01:42:02AM +0200, Adrian Bunk wrote:
...
For example you feel, that you've wasted time. But after all, if you've
came up with some kind of tool, everybody else could take it. No
problems, useful ideas must and will evolve. But _ideally_ this must not be
from ground zero every time. _Ideally_ from technical, not personal
point of view ;).

As I expected, someone else has picked up regression tracking.
And other from what you claim, this did not require any kind of tool.

So you expected good, doing bad. ``Bad'' means bringing pointless flame
about what everybody should do, without constructive approach like: "OK,
i can't do it due to my POV{0}, useless manual work. Everybody willing to
bring another way of dealing with it is welcome."

Your first reply:

"And it's not that Linus started developing the Linux kernel with writing
git, the first 10 years of Linux development were without any SCM." {3}

to my note about, that you are not hurry anywhere, that after all that
years of Open Source and Free Software development you are not trying
to deal with such important thing like regression/bug tracking in
***organized way***, is rather pointless.

I am dealing with bug tracking in the kernel Bugzilla.
I did regression tracking for the kernel.
Michal is currently tracking regressions.
Andrew is doing an enormous amount of work in these areas.

You might not see it because you are not active in this area, but it is
working in an organized way.

What is not working is getting all tracked bugs properly debugged.

That's why people in Debian have started *team* maintenance with alioth.

The problem for the Linux kernel is that for a better bug handling you'd
need people willing to learn other people's code and to do the hard work
of debugging bug reports.

... {0}++

Do you know, for example, why i'm not making my "hacker's career"
doing that?

1. because i ended up with lynx, slrn, mutt, emacs-nox. Including
"zarro bogs found" kind of thing and other "userspace suck" problems.
2. i have no way to know if something *really* broken, unless it right
on my hardware

This all unlike Debian BTS using reportbug, where you have basic
information, mbox format messages for easy "mutt -f", and other funny
things, real maintainers aware of (i'm trying to know, learn about).

Thus organized, non brain-damaged way of reporting and tracking is the
key issue.

Bugzilla is a usable tool for bug and regression reporting and tracking
tracking.

I am using the Debian BTS since 8 years and I've used many Bugzillas.

Both are usable, and the real problem in kernel development is not
really related to the question which tool to use for bug tracking.

...
Talking about "team maintenance" sounds nice, but the problem in the
kernel starts with code that has zero maintainers.

Floppy went pretty fine, before it was started to be maintained, and
you know that. But you also told that unmaintained and not-working are
different things.

unmaintained != unused
user != developer
worked != went pretty fine

Stuff can easily get broken and noone looks after bugs if there's no
maintainer both knowing the code and willing to debug bugs.

The floppy driver is actually an example of code that has been broken
quite often by patches simply because noone who completely understands
this driver reviewed patches.

It somehow works and it might work for some years, but there is a
problem.

...
I see (this repetition). Maybe i've managed to express my POV, that it
can be seeing more cleanly.

IMHO your point of view is simply not related to the real current
quality problems in kernel development.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: This is [Re:] How to improve the quality of the kernel[?].
    ... believed by somebody to have positive efficiency in bug tracking. ... If you ever tried to report bug with reportbug tool in Debian, ... That depends on whether such a system attracts testers and helps ... hardware/application area but *not* in kernel internals and kernel ...
    (Linux-Kernel)
  • Re: ftruncate-mmap: pages are lost after writing to mmaped file.
    ... about Peter's exact dirty page tracking. ... So if 2.6.18 shows the same problem, then it's a _really_ old bug, and not ... on multiple kernels, can you try it on a few more kernel versions? ...
    (Linux-Kernel)
  • Re: ftruncate-mmap: pages are lost after writing to mmaped file.
    ... about Peter's exact dirty page tracking. ... So if 2.6.18 shows the same problem, then it's a _really_ old bug, and not ... on multiple kernels, can you try it on a few more kernel versions? ...
    (Linux-Kernel)
  • Re: ftruncate-mmap: pages are lost after writing to mmaped file.
    ... about Peter's exact dirty page tracking. ... So if 2.6.18 shows the same problem, then it's a _really_ old bug, and not ... on multiple kernels, can you try it on a few more kernel versions? ...
    (Linux-Kernel)
  • Re: [PATCH 1/2] LogFS proper
    ... Please comment the structure with kernel doc comments and avoid the tail ... Do enums have a significant ... Also the BUG itself will give you enough clue where it happened, ... which leaves only the prepared filesystem image to worry about. ...
    (Linux-Kernel)