Re: regression tracking (Re: Linux 2.6.21)

[Martin J. Bligh]

Yes, good work, thanks a lot for it!  The new interface is much better and more
useful.

Greetings,
Rafael


PS
BTW, would that be possible to create the "Hibernation/Suspend" subcategory
of "Power Management" that I asked for some time ago, please? :-)
  


Oops. Sorry. Done.

M.

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

Re: regression tracking (Re: Linux 2.6.21)

[Rafael J. Wysocki]

On Tuesday, 19 June 2007 02:28, Martin Bligh wrote:
> Linus Torvalds wrote:
> > 
> > On Thu, 14 Jun 2007, Oleg Verych wrote:
> >> I'm seeing this long (198) thread and just have no idea how it has
> >> ended (wiki? hand-mailing?).
> > 
> > I'm hoping it's not "ended".
> > 
> > IOW, I really don't think we _resolved_ anything, although the work that 
> > Adrian started is continuing through the wiki and other people trying to 
> > track regressions, and that was obviously something good.
> > 
> > But I don't think we really know where we want to take this thing in the 
> > long run. I think everybody wants a better bug-tracking system, but 
> > whether something that makes people satisfied can even be built is open. 
> > It sure doesn't seem to exist right now ;)
> 
> I know you hate bugzilla ... but at least I can try to make that bit
> of the process work better.
> 
> The new version just rolled out does have a simple "regression" checkbox
> (and you can search on it), which will hopefully help people keep track
> of the ones already in bugzilla more easily.
> 
> Thanks to Jon T, Dave J et al. for helping to figure out methods and
> implement them.

Yes, good work, thanks a lot for it!  The new interface is much better and more
useful.

Greetings,
Rafael


PS
BTW, would that be possible to create the "Hibernation/Suspend" subcategory
of "Power Management" that I asked for some time ago, please? :-)

-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Rafael J. Wysocki]

On Tuesday, 19 June 2007 02:28, Martin Bligh wrote:
 Linus Torvalds wrote:
  
  On Thu, 14 Jun 2007, Oleg Verych wrote:
  I'm seeing this long (198) thread and just have no idea how it has
  ended (wiki? hand-mailing?).
  
  I'm hoping it's not ended.
  
  IOW, I really don't think we _resolved_ anything, although the work that 
  Adrian started is continuing through the wiki and other people trying to 
  track regressions, and that was obviously something good.
  
  But I don't think we really know where we want to take this thing in the 
  long run. I think everybody wants a better bug-tracking system, but 
  whether something that makes people satisfied can even be built is open. 
  It sure doesn't seem to exist right now ;)
 
 I know you hate bugzilla ... but at least I can try to make that bit
 of the process work better.
 
 The new version just rolled out does have a simple regression checkbox
 (and you can search on it), which will hopefully help people keep track
 of the ones already in bugzilla more easily.
 
 Thanks to Jon T, Dave J et al. for helping to figure out methods and
 implement them.

Yes, good work, thanks a lot for it!  The new interface is much better and more
useful.

Greetings,
Rafael


PS
BTW, would that be possible to create the Hibernation/Suspend subcategory
of Power Management that I asked for some time ago, please? :-)

-- 
Premature optimization is the root of all evil. - Donald Knuth
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Martin J. Bligh]

Yes, good work, thanks a lot for it!  The new interface is much better and more
useful.

Greetings,
Rafael


PS
BTW, would that be possible to create the Hibernation/Suspend subcategory
of Power Management that I asked for some time ago, please? :-)
  


Oops. Sorry. Done.

M.

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

Re: regression tracking (Re: Linux 2.6.21)

[Martin Bligh]

Linus Torvalds wrote:


On Thu, 14 Jun 2007, Oleg Verych wrote:

I'm seeing this long (198) thread and just have no idea how it has
ended (wiki? hand-mailing?).


I'm hoping it's not "ended".

IOW, I really don't think we _resolved_ anything, although the work that 
Adrian started is continuing through the wiki and other people trying to 
track regressions, and that was obviously something good.


But I don't think we really know where we want to take this thing in the 
long run. I think everybody wants a better bug-tracking system, but 
whether something that makes people satisfied can even be built is open. 
It sure doesn't seem to exist right now ;)


I know you hate bugzilla ... but at least I can try to make that bit
of the process work better.

The new version just rolled out does have a simple "regression" checkbox
(and you can search on it), which will hopefully help people keep track
of the ones already in bugzilla more easily.

Thanks to Jon T, Dave J et al. for helping to figure out methods and
implement them.

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

Re: regression tracking (Re: Linux 2.6.21)

[Martin Bligh]

Linus Torvalds wrote:


On Thu, 14 Jun 2007, Oleg Verych wrote:

I'm seeing this long (198) thread and just have no idea how it has
ended (wiki? hand-mailing?).


I'm hoping it's not ended.

IOW, I really don't think we _resolved_ anything, although the work that 
Adrian started is continuing through the wiki and other people trying to 
track regressions, and that was obviously something good.


But I don't think we really know where we want to take this thing in the 
long run. I think everybody wants a better bug-tracking system, but 
whether something that makes people satisfied can even be built is open. 
It sure doesn't seem to exist right now ;)


I know you hate bugzilla ... but at least I can try to make that bit
of the process work better.

The new version just rolled out does have a simple regression checkbox
(and you can search on it), which will hopefully help people keep track
of the ones already in bugzilla more easily.

Thanks to Jon T, Dave J et al. for helping to figure out methods and
implement them.

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

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Oleg Verych]

On Sun, Jun 17, 2007 at 10:44:39AM -0700, [EMAIL PROTECTED] wrote:
> On Sun, 17 Jun 2007, Oleg Verych wrote:
[]
> >That's wrong if developers are tending to reply only one thing --
> >git-bisect.
> >
> >If things are going to be that bad, then better to start dealing with the
> >cause, not consequences. In this situation requesting test-cases is a
> >better way, as it's going to influence developer as cause of potential
> >problems. If tests will show *hardware* side of problem, then, well some
> >parts may be not obvious, thus bisecting is a way to continue.
> 
> most people who report bugs don't know enough about what's actually going 
> wrong to be able to write a test case (those that do can probably just 
> write a patch to fix it). Along similar lines a debugger wouldn't be of 
> much use either.

Sorry for my English. Requesting test cases from the developers of
course. Or at least results of some kind of testing, so people may run
and check them as well, if something is suspected. And this from my POV
leads again to organized way of filtering noise and collecting structured
information easily (yea, i think it's BTS with reportbug in Debian).{0}

> the fact that git-bisect doesn't require any knowledge other then 
> knowledge the reporter has demonstrated that they already have (the 
> ability to compile and install their own kernel) puts it within the reach 
> of testers.
> 
> unfortunantly, as good as it is it can take a lot of effort, especially if 
> the bug takes time to show up. it's not perfect, but it's a huge help.

I think, positive feedback from {0} to the LTP may improve that.
Especially, if things are in parts and easy to choose for testing.

> and developers aren't always responding with 'do a bisect', sometimes they 
> respond with 'yes, we know about that'

> or 'that sounds like X',

That two are _exactly_ what reportbug tool is doing. That's why i'm
talking about it. And i'm *no* wonder why developers are boring -- at
some points they might not handle the *noise*.

> so it's still worthwhile for people to report the problem first before
> going to the ffort of doing a bisect.
> 
> David Lang
__

Bits for Adrian.

*ML*

I *use* Gmane. I'm not subscribed (receiving e-mail to my mbox) to any ML,
except <[EMAIL PROTECTED]>.

Nearly every my e-mail here is with Gmane links. You seem ignored all of
them. As for me it's result of *your personal*, rather than technical
activity.

*offense*

I'm not talking about personal offense, you are seem thinking about, but
technical one. I.e. when possible benefit might be even more, than NOHZ
on x86 and a like[0], with much less effort. I still think, unless i will
develop or fail, that reducing traffic on one or two order of magnitude
is possible as well as improving kbuild/kconfig to reduce of the noise of
mis-configurations/tester's .config length. Discouraging that effort is
my source of offense.

(FYI Until Linus checked in my _RFT_ kbuild patches, i realized how
*many* people are willing to understand and try to test kbuild stuff.)

[0] I bet VGA, DRAM, HDD are far more power hungry room-heaters. Unless
you can substantially lower frequency, you might have no benefit at
all. Whana know how it's done in perfectly designed embedded
MCU/CPU? Please, see for instance MSP430 from TI (i know, it uses
SRAM, but i've asked to look on processor core design).

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

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[david]

On Sun, 17 Jun 2007, Oleg Verych wrote:


On Sun, Jun 17, 2007 at 12:22:26PM +0200, Michal Piotrowski wrote:

On 17/06/07, Andrew Morton <[EMAIL PROTECTED]> wrote:

On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski
<[EMAIL PROTECTED]> wrote:


+If the patch introduces a new regression and this regression was not

fixed

+in seven days, then the patch will be reverted.


Those regressions where we know which patch caused them are the easy ones.
Often we don't know which patch (or even which subsystem merge) is at
fault.

I think.  How many of the present 2.6.22-rc regressions which you're
presently tracking have such a well-identified cause?



Here lays the problem.

git-bisect is a killer app, people should start using it.


It's OK _only_ in case of unknown, hard to find *hardware* bugs.

If you think it's "a good thing" for bad, untested by developer
code, then something is completely wrong.

And if there's no debugger in the mainline kernel, which is developer's
tool, then why do you think testers must stick with git-bisect, as their
debugger-like tool (bandwidth in most and time consuming in some cases)?

That's wrong if developers are tending to reply only one thing --
git-bisect.

If things are going to be that bad, then better to start dealing with the
cause, not consequences. In this situation requesting test-cases is a
better way, as it's going to influence developer as cause of potential
problems. If tests will show *hardware* side of problem, then, well some
parts may be not obvious, thus bisecting is a way to continue.


most people who report bugs don't know enough about what's actually going 
wrong to be able to write a test case (those that do can probably just 
write a patch to fix it). Along similar lines a debugger wouldn't be of 
much use either.


the fact that git-bisect doesn't require any knowledge other then 
knowledge the reporter has demonstrated that they already have (the 
ability to compile and install their own kernel) puts it within the reach 
of testers.


unfortunantly, as good as it is it can take a lot of effort, especially if 
the bug takes time to show up. it's not perfect, but it's a huge help.


and developers aren't always responding with 'do a bisect', sometimes they 
respond with 'yes, we know about that' or 'that sounds like X', so it's 
still worthwhile for people to report the problem first before going to 
the ffort of doing a bisect.


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

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Adrian Bunk]

On Sun, Jun 17, 2007 at 04:24:30PM +0200, Oleg Verych wrote:
> On Sun, Jun 17, 2007 at 02:13:39PM +0200, Rafael J. Wysocki wrote:
> > On Sunday, 17 June 2007 13:47, Oleg Verych wrote:
> []
> > > It's OK _only_ in case of unknown, hard to find *hardware* bugs.
> > > 
> > > If you think it's "a good thing" for bad, untested by developer
> > > code, then something is completely wrong.
> > 
> > Oh, I've just fixed two purely software bugs pointed out by binary searching
> > in the code that I'm sure has been tested, not only by its developers, but 
> > the
> > bugs only showed up in my configuration (on one out of four test boxes).
> > 
> > There are so many different kernel configurations possible that there's no 
> > way
> > a developer can test them all.
> 
> With current state of affairs it's not only hard for developers, but
> and for users: <[EMAIL PROTECTED]>,
>   <[EMAIL PROTECTED]>

Uwe has an attitude that made many people (including Linus himself) 
set their mail filters to deliver his emails directly to /dev/null.

Parts of the contents of his emails were usable including usable 
regression reports - but the way he treats people simply disqualified 
him.

> I'm trying to re-do some kbuild stuff, but i'm getting rather offensive
> answers :( <[EMAIL PROTECTED]>
>...

I'm not seeing anything in Thomas' email that could be considered 
offensive. He told you in a technical way why he disagrees with you.

If you call this email "rather offensive", you should _really_ 
unsubscribe from lkml (or even any Debian mailing lists). And this is 
not meant against you, it's simply that for the standards of lkml there 
is nothing offensive in this email.

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Oleg Verych]

On Sun, Jun 17, 2007 at 02:13:39PM +0200, Rafael J. Wysocki wrote:
> On Sunday, 17 June 2007 13:47, Oleg Verych wrote:
[]
> > It's OK _only_ in case of unknown, hard to find *hardware* bugs.
> > 
> > If you think it's "a good thing" for bad, untested by developer
> > code, then something is completely wrong.
> 
> Oh, I've just fixed two purely software bugs pointed out by binary searching
> in the code that I'm sure has been tested, not only by its developers, but the
> bugs only showed up in my configuration (on one out of four test boxes).
> 
> There are so many different kernel configurations possible that there's no way
> a developer can test them all.

With current state of affairs it's not only hard for developers, but
and for users: <[EMAIL PROTECTED]>,
  <[EMAIL PROTECTED]>

I'm trying to re-do some kbuild stuff, but i'm getting rather offensive
answers :( <[EMAIL PROTECTED]>

(Even if i'm academic with free Internet, i doubt i even tried to
think to improve something, if i didn't have one, because i wouldn't knew
huge lkml traffic, problems, etc.)

Maybe i'm wrong. But reducing amount of traffic/files and ease of
(re-)configuration are not last things to be done for better testing.
All for speed of getting and compiling kernel. Latter for avoiding
bugs and noise due to inconsistent build configuration.

Finally again, bug-reporting and tracking tools, i've tried to discuss
are major problems out there I think it's plain easy and deal with. One
more example:

<[EMAIL PROTECTED]>
Xref: news.gmane.org gmane.linux.debian.devel.kernel:28095


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

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Stefan Richter]

Michal Piotrowski wrote:
> "choose minor evil to prevent a greater one"

The measurement of "evil" is subjective.  That's why there are releases
with known regressions.
-- 
Stefan Richter
-=-=-=== -==- =---=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Michal Piotrowski]

On 17/06/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:

On Sun, Jun 17, 2007 at 11:41:36AM +0200, Michal Piotrowski wrote:
> Hi all,
>
> Adrian Bunk pisze:
>> On Sat, Jun 16, 2007 at 02:23:25PM +0200, Stefan Richter wrote:
>>> ...
>>> [Adrian, I'm not saying "too few users run -rc kernels", I'm saying "too
>>> few FireWire driver users run -rc kernels".]
>> Getting more people testing -rc kernels might be possible, and I don't
>> think it would be too hard. And not only FireWire would benefit from this,
>> remember e.g. that at least 2 out of the last 5 kernels Linus released
>> contained filesystem corruption regressions.
>> The problem is that we aren't able to handle the many regression reports
>> we get today, so asking for more testing and regression reports today
>> would attack it at the wrong part of the chain.
>> Additionally, every reported and unhandled regression will frustrate the
>> reporter - never forget that we have _many_ unhandled bug reports
>> (including but not limited to regression reports) where the submitter
>> spent much time and energy in writing a good bug report.
>> If we somehow gain the missing manpower for debugging regressions we can
>> actively ask for more testing. Missing manpower (of people knowing some
>> part of the kernel well) for debugging bug reports is IMHO the one big
>> source of quality problems in the Linux kernel. If we get this solved,
>> things like getting more testers for -rc kernels will become low hanging
>> fruits.
>
> Adrian, I agree with _all_ your points.
>
> I bet that developers will hate me for this.
>
> Please consider for 2.6.23

Fine with me, but:

There are not so simple cases like big infrastructure patches with
20 other patches in the tree depending on it causing a regression, or
even worse, a big infrastructure patch exposing a latent old bug in some
completely different area of the kernel.


It is different case.

"If the patch introduces a new regression"

introduces != exposes an old bug

Removal of 20 patches will be painful, but sometimes you need to
"choose minor evil to prevent a greater one" [1].


And we should be aware that reverting is only a workaround for the real
problem which lies in our bug handling.

> Regards,
> Michal
>...

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




Regards,
Michal

[1] the quote from "The Last Wish/Minor Evil" by Andrzej Sapkowski :)

--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Adrian Bunk]

On Sun, Jun 17, 2007 at 11:41:36AM +0200, Michal Piotrowski wrote:
> Hi all,
>
> Adrian Bunk pisze:
>> On Sat, Jun 16, 2007 at 02:23:25PM +0200, Stefan Richter wrote:
>>> ...
>>> [Adrian, I'm not saying "too few users run -rc kernels", I'm saying "too
>>> few FireWire driver users run -rc kernels".]
>> Getting more people testing -rc kernels might be possible, and I don't 
>> think it would be too hard. And not only FireWire would benefit from this, 
>> remember e.g. that at least 2 out of the last 5 kernels Linus released 
>> contained filesystem corruption regressions.
>> The problem is that we aren't able to handle the many regression reports 
>> we get today, so asking for more testing and regression reports today 
>> would attack it at the wrong part of the chain.
>> Additionally, every reported and unhandled regression will frustrate the 
>> reporter - never forget that we have _many_ unhandled bug reports 
>> (including but not limited to regression reports) where the submitter 
>> spent much time and energy in writing a good bug report.
>> If we somehow gain the missing manpower for debugging regressions we can 
>> actively ask for more testing. Missing manpower (of people knowing some 
>> part of the kernel well) for debugging bug reports is IMHO the one big 
>> source of quality problems in the Linux kernel. If we get this solved, 
>> things like getting more testers for -rc kernels will become low hanging 
>> fruits.
>
> Adrian, I agree with _all_ your points.
>
> I bet that developers will hate me for this.
>
> Please consider for 2.6.23

Fine with me, but:

There are not so simple cases like big infrastructure patches with
20 other patches in the tree depending on it causing a regression, or 
even worse, a big infrastructure patch exposing a latent old bug in some 
completely different area of the kernel.

And we should be aware that reverting is only a workaround for the real 
problem which lies in our bug handling.

> Regards,
> Michal
>...

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Rafael J. Wysocki]

On Sunday, 17 June 2007 13:47, Oleg Verych wrote:
> On Sun, Jun 17, 2007 at 12:22:26PM +0200, Michal Piotrowski wrote:
> > On 17/06/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski 
> > ><[EMAIL PROTECTED]> wrote:
> > >
> > >> +If the patch introduces a new regression and this regression was not 
> > >fixed
> > >> +in seven days, then the patch will be reverted.
> > >
> > >Those regressions where we know which patch caused them are the easy ones.
> > >Often we don't know which patch (or even which subsystem merge) is at
> > >fault.
> > >
> > >I think.  How many of the present 2.6.22-rc regressions which you're
> > >presently tracking have such a well-identified cause?
> > >
> > 
> > Here lays the problem.
> > 
> > git-bisect is a killer app, people should start using it.
> 
> It's OK _only_ in case of unknown, hard to find *hardware* bugs.
> 
> If you think it's "a good thing" for bad, untested by developer
> code, then something is completely wrong.

Oh, I've just fixed two purely software bugs pointed out by binary searching
in the code that I'm sure has been tested, not only by its developers, but the
bugs only showed up in my configuration (on one out of four test boxes).

There are so many different kernel configurations possible that there's no way
a developer can test them all.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Rafael J. Wysocki]

On Sunday, 17 June 2007 12:22, Michal Piotrowski wrote:
> On 17/06/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski <[EMAIL PROTECTED]> 
> > wrote:
> >
> > > +If the patch introduces a new regression and this regression was not 
> > > fixed
> > > +in seven days, then the patch will be reverted.
> >
> > Those regressions where we know which patch caused them are the easy ones.

Except when the bisection points us to a patch exposing a bug that is present
regardless (see http://lkml.org/lkml/2007/6/13/273 for example).

Besides, if a patch is merged before -rc1 as a bugfix, there are several
patches depending on it and only after -rc5 has been released we find out
that it breaks someone's system, then reverting it is not a solution, IMO.

> > Often we don't know which patch (or even which subsystem merge) is at
> > fault.
> >
> > I think.  How many of the present 2.6.22-rc regressions which you're
> > presently tracking have such a well-identified cause?
> >
> 
> Here lays the problem.
> 
> git-bisect is a killer app, people should start using it.

People should test _all_ of the -rc kernels and report problems.  Otherwise, we
may assume that there are no problems and go on.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Oleg Verych]

On Sun, Jun 17, 2007 at 12:22:26PM +0200, Michal Piotrowski wrote:
> On 17/06/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski 
> ><[EMAIL PROTECTED]> wrote:
> >
> >> +If the patch introduces a new regression and this regression was not 
> >fixed
> >> +in seven days, then the patch will be reverted.
> >
> >Those regressions where we know which patch caused them are the easy ones.
> >Often we don't know which patch (or even which subsystem merge) is at
> >fault.
> >
> >I think.  How many of the present 2.6.22-rc regressions which you're
> >presently tracking have such a well-identified cause?
> >
> 
> Here lays the problem.
> 
> git-bisect is a killer app, people should start using it.

It's OK _only_ in case of unknown, hard to find *hardware* bugs.

If you think it's "a good thing" for bad, untested by developer
code, then something is completely wrong.

And if there's no debugger in the mainline kernel, which is developer's
tool, then why do you think testers must stick with git-bisect, as their
debugger-like tool (bandwidth in most and time consuming in some cases)?

That's wrong if developers are tending to reply only one thing --
git-bisect.

If things are going to be that bad, then better to start dealing with the
cause, not consequences. In this situation requesting test-cases is a
better way, as it's going to influence developer as cause of potential
problems. If tests will show *hardware* side of problem, then, well some
parts may be not obvious, thus bisecting is a way to continue.

Sorry if i'm from the abnormally different side yet one more time.

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

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Michal Piotrowski]

On 17/06/07, Andrew Morton <[EMAIL PROTECTED]> wrote:

On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski <[EMAIL PROTECTED]> wrote:

> +If the patch introduces a new regression and this regression was not fixed
> +in seven days, then the patch will be reverted.

Those regressions where we know which patch caused them are the easy ones.
Often we don't know which patch (or even which subsystem merge) is at
fault.

I think.  How many of the present 2.6.22-rc regressions which you're
presently tracking have such a well-identified cause?



Here lays the problem.

git-bisect is a killer app, people should start using it.

Regards,
Michal

--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Andrew Morton]

On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski <[EMAIL PROTECTED]> wrote:

> +If the patch introduces a new regression and this regression was not fixed
> +in seven days, then the patch will be reverted.

Those regressions where we know which patch caused them are the easy ones.
Often we don't know which patch (or even which subsystem merge) is at
fault.

I think.  How many of the present 2.6.22-rc regressions which you're
presently tracking have such a well-identified cause?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Michal Piotrowski]

Hi all,

Adrian Bunk pisze:

On Sat, Jun 16, 2007 at 02:23:25PM +0200, Stefan Richter wrote:

...
[Adrian, I'm not saying "too few users run -rc kernels", I'm saying "too
few FireWire driver users run -rc kernels".]


Getting more people testing -rc kernels might be possible, and I don't 
think it would be too hard. And not only FireWire would benefit from 
this, remember e.g. that at least 2 out of the last 5 kernels Linus 
released contained filesystem corruption regressions.


The problem is that we aren't able to handle the many regression reports 
we get today, so asking for more testing and regression reports today 
would attack it at the wrong part of the chain.


Additionally, every reported and unhandled regression will frustrate the 
reporter - never forget that we have _many_ unhandled bug reports 
(including but not limited to regression reports) where the submitter 
spent much time and energy in writing a good bug report.


If we somehow gain the missing manpower for debugging regressions we can 
actively ask for more testing. Missing manpower (of people knowing some 
part of the kernel well) for debugging bug reports is IMHO the one big 
source of quality problems in the Linux kernel. If we get this solved, 
things like getting more testers for -rc kernels will become low hanging 
fruits.


Adrian, I agree with _all_ your points.

I bet that developers will hate me for this.

Please consider for 2.6.23

Regards,
Michal

--
LOG
http://www.stardust.webpages.pl/log/

Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>

--- linux-work-clean/Documentation/SubmitChecklist  2007-06-17 
11:18:37.0 +0200
+++ linux-work/Documentation/SubmitChecklist2007-06-17 11:29:26.0 
+0200
@@ -90,3 +90,8 @@ kernel patches.
patch style checker prior to submission (scripts/checkpatch.pl).
You should be able to justify all violations that remain in
your patch.
+
+
+
+If the patch introduces a new regression and this regression was not fixed
+in seven days, then the patch will be reverted.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Michal Piotrowski]

Hi all,

Adrian Bunk pisze:

On Sat, Jun 16, 2007 at 02:23:25PM +0200, Stefan Richter wrote:

...
[Adrian, I'm not saying too few users run -rc kernels, I'm saying too
few FireWire driver users run -rc kernels.]


Getting more people testing -rc kernels might be possible, and I don't 
think it would be too hard. And not only FireWire would benefit from 
this, remember e.g. that at least 2 out of the last 5 kernels Linus 
released contained filesystem corruption regressions.


The problem is that we aren't able to handle the many regression reports 
we get today, so asking for more testing and regression reports today 
would attack it at the wrong part of the chain.


Additionally, every reported and unhandled regression will frustrate the 
reporter - never forget that we have _many_ unhandled bug reports 
(including but not limited to regression reports) where the submitter 
spent much time and energy in writing a good bug report.


If we somehow gain the missing manpower for debugging regressions we can 
actively ask for more testing. Missing manpower (of people knowing some 
part of the kernel well) for debugging bug reports is IMHO the one big 
source of quality problems in the Linux kernel. If we get this solved, 
things like getting more testers for -rc kernels will become low hanging 
fruits.


Adrian, I agree with _all_ your points.

I bet that developers will hate me for this.

Please consider for 2.6.23

Regards,
Michal

--
LOG
http://www.stardust.webpages.pl/log/

Signed-off-by: Michal Piotrowski [EMAIL PROTECTED]

--- linux-work-clean/Documentation/SubmitChecklist  2007-06-17 
11:18:37.0 +0200
+++ linux-work/Documentation/SubmitChecklist2007-06-17 11:29:26.0 
+0200
@@ -90,3 +90,8 @@ kernel patches.
patch style checker prior to submission (scripts/checkpatch.pl).
You should be able to justify all violations that remain in
your patch.
+
+
+
+If the patch introduces a new regression and this regression was not fixed
+in seven days, then the patch will be reverted.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Andrew Morton]

On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski [EMAIL PROTECTED] wrote:

 +If the patch introduces a new regression and this regression was not fixed
 +in seven days, then the patch will be reverted.

Those regressions where we know which patch caused them are the easy ones.
Often we don't know which patch (or even which subsystem merge) is at
fault.

I think.  How many of the present 2.6.22-rc regressions which you're
presently tracking have such a well-identified cause?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Michal Piotrowski]

On 17/06/07, Andrew Morton [EMAIL PROTECTED] wrote:

On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski [EMAIL PROTECTED] wrote:

 +If the patch introduces a new regression and this regression was not fixed
 +in seven days, then the patch will be reverted.

Those regressions where we know which patch caused them are the easy ones.
Often we don't know which patch (or even which subsystem merge) is at
fault.

I think.  How many of the present 2.6.22-rc regressions which you're
presently tracking have such a well-identified cause?



Here lays the problem.

git-bisect is a killer app, people should start using it.

Regards,
Michal

--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Oleg Verych]

On Sun, Jun 17, 2007 at 12:22:26PM +0200, Michal Piotrowski wrote:
 On 17/06/07, Andrew Morton [EMAIL PROTECTED] wrote:
 On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski 
 [EMAIL PROTECTED] wrote:
 
  +If the patch introduces a new regression and this regression was not 
 fixed
  +in seven days, then the patch will be reverted.
 
 Those regressions where we know which patch caused them are the easy ones.
 Often we don't know which patch (or even which subsystem merge) is at
 fault.
 
 I think.  How many of the present 2.6.22-rc regressions which you're
 presently tracking have such a well-identified cause?
 
 
 Here lays the problem.
 
 git-bisect is a killer app, people should start using it.

It's OK _only_ in case of unknown, hard to find *hardware* bugs.

If you think it's a good thing for bad, untested by developer
code, then something is completely wrong.

And if there's no debugger in the mainline kernel, which is developer's
tool, then why do you think testers must stick with git-bisect, as their
debugger-like tool (bandwidth in most and time consuming in some cases)?

That's wrong if developers are tending to reply only one thing --
git-bisect.

If things are going to be that bad, then better to start dealing with the
cause, not consequences. In this situation requesting test-cases is a
better way, as it's going to influence developer as cause of potential
problems. If tests will show *hardware* side of problem, then, well some
parts may be not obvious, thus bisecting is a way to continue.

Sorry if i'm from the abnormally different side yet one more time.

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

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Rafael J. Wysocki]

On Sunday, 17 June 2007 12:22, Michal Piotrowski wrote:
 On 17/06/07, Andrew Morton [EMAIL PROTECTED] wrote:
  On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski [EMAIL PROTECTED] 
  wrote:
 
   +If the patch introduces a new regression and this regression was not 
   fixed
   +in seven days, then the patch will be reverted.
 
  Those regressions where we know which patch caused them are the easy ones.

Except when the bisection points us to a patch exposing a bug that is present
regardless (see http://lkml.org/lkml/2007/6/13/273 for example).

Besides, if a patch is merged before -rc1 as a bugfix, there are several
patches depending on it and only after -rc5 has been released we find out
that it breaks someone's system, then reverting it is not a solution, IMO.

  Often we don't know which patch (or even which subsystem merge) is at
  fault.
 
  I think.  How many of the present 2.6.22-rc regressions which you're
  presently tracking have such a well-identified cause?
 
 
 Here lays the problem.
 
 git-bisect is a killer app, people should start using it.

People should test _all_ of the -rc kernels and report problems.  Otherwise, we
may assume that there are no problems and go on.

Greetings,
Rafael


-- 
Premature optimization is the root of all evil. - Donald Knuth
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Rafael J. Wysocki]

On Sunday, 17 June 2007 13:47, Oleg Verych wrote:
 On Sun, Jun 17, 2007 at 12:22:26PM +0200, Michal Piotrowski wrote:
  On 17/06/07, Andrew Morton [EMAIL PROTECTED] wrote:
  On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski 
  [EMAIL PROTECTED] wrote:
  
   +If the patch introduces a new regression and this regression was not 
  fixed
   +in seven days, then the patch will be reverted.
  
  Those regressions where we know which patch caused them are the easy ones.
  Often we don't know which patch (or even which subsystem merge) is at
  fault.
  
  I think.  How many of the present 2.6.22-rc regressions which you're
  presently tracking have such a well-identified cause?
  
  
  Here lays the problem.
  
  git-bisect is a killer app, people should start using it.
 
 It's OK _only_ in case of unknown, hard to find *hardware* bugs.
 
 If you think it's a good thing for bad, untested by developer
 code, then something is completely wrong.

Oh, I've just fixed two purely software bugs pointed out by binary searching
in the code that I'm sure has been tested, not only by its developers, but the
bugs only showed up in my configuration (on one out of four test boxes).

There are so many different kernel configurations possible that there's no way
a developer can test them all.

Greetings,
Rafael


-- 
Premature optimization is the root of all evil. - Donald Knuth
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Adrian Bunk]

On Sun, Jun 17, 2007 at 11:41:36AM +0200, Michal Piotrowski wrote:
 Hi all,

 Adrian Bunk pisze:
 On Sat, Jun 16, 2007 at 02:23:25PM +0200, Stefan Richter wrote:
 ...
 [Adrian, I'm not saying too few users run -rc kernels, I'm saying too
 few FireWire driver users run -rc kernels.]
 Getting more people testing -rc kernels might be possible, and I don't 
 think it would be too hard. And not only FireWire would benefit from this, 
 remember e.g. that at least 2 out of the last 5 kernels Linus released 
 contained filesystem corruption regressions.
 The problem is that we aren't able to handle the many regression reports 
 we get today, so asking for more testing and regression reports today 
 would attack it at the wrong part of the chain.
 Additionally, every reported and unhandled regression will frustrate the 
 reporter - never forget that we have _many_ unhandled bug reports 
 (including but not limited to regression reports) where the submitter 
 spent much time and energy in writing a good bug report.
 If we somehow gain the missing manpower for debugging regressions we can 
 actively ask for more testing. Missing manpower (of people knowing some 
 part of the kernel well) for debugging bug reports is IMHO the one big 
 source of quality problems in the Linux kernel. If we get this solved, 
 things like getting more testers for -rc kernels will become low hanging 
 fruits.

 Adrian, I agree with _all_ your points.

 I bet that developers will hate me for this.

 Please consider for 2.6.23

Fine with me, but:

There are not so simple cases like big infrastructure patches with
20 other patches in the tree depending on it causing a regression, or 
even worse, a big infrastructure patch exposing a latent old bug in some 
completely different area of the kernel.

And we should be aware that reverting is only a workaround for the real 
problem which lies in our bug handling.

 Regards,
 Michal
...

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Michal Piotrowski]

On 17/06/07, Adrian Bunk [EMAIL PROTECTED] wrote:

On Sun, Jun 17, 2007 at 11:41:36AM +0200, Michal Piotrowski wrote:
 Hi all,

 Adrian Bunk pisze:
 On Sat, Jun 16, 2007 at 02:23:25PM +0200, Stefan Richter wrote:
 ...
 [Adrian, I'm not saying too few users run -rc kernels, I'm saying too
 few FireWire driver users run -rc kernels.]
 Getting more people testing -rc kernels might be possible, and I don't
 think it would be too hard. And not only FireWire would benefit from this,
 remember e.g. that at least 2 out of the last 5 kernels Linus released
 contained filesystem corruption regressions.
 The problem is that we aren't able to handle the many regression reports
 we get today, so asking for more testing and regression reports today
 would attack it at the wrong part of the chain.
 Additionally, every reported and unhandled regression will frustrate the
 reporter - never forget that we have _many_ unhandled bug reports
 (including but not limited to regression reports) where the submitter
 spent much time and energy in writing a good bug report.
 If we somehow gain the missing manpower for debugging regressions we can
 actively ask for more testing. Missing manpower (of people knowing some
 part of the kernel well) for debugging bug reports is IMHO the one big
 source of quality problems in the Linux kernel. If we get this solved,
 things like getting more testers for -rc kernels will become low hanging
 fruits.

 Adrian, I agree with _all_ your points.

 I bet that developers will hate me for this.

 Please consider for 2.6.23

Fine with me, but:

There are not so simple cases like big infrastructure patches with
20 other patches in the tree depending on it causing a regression, or
even worse, a big infrastructure patch exposing a latent old bug in some
completely different area of the kernel.


It is different case.

If the patch introduces a new regression

introduces != exposes an old bug

Removal of 20 patches will be painful, but sometimes you need to
choose minor evil to prevent a greater one [1].


And we should be aware that reverting is only a workaround for the real
problem which lies in our bug handling.

 Regards,
 Michal
...

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




Regards,
Michal

[1] the quote from The Last Wish/Minor Evil by Andrzej Sapkowski :)

--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Stefan Richter]

Michal Piotrowski wrote:
 choose minor evil to prevent a greater one

The measurement of evil is subjective.  That's why there are releases
with known regressions.
-- 
Stefan Richter
-=-=-=== -==- =---=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Oleg Verych]

On Sun, Jun 17, 2007 at 02:13:39PM +0200, Rafael J. Wysocki wrote:
 On Sunday, 17 June 2007 13:47, Oleg Verych wrote:
[]
  It's OK _only_ in case of unknown, hard to find *hardware* bugs.
  
  If you think it's a good thing for bad, untested by developer
  code, then something is completely wrong.
 
 Oh, I've just fixed two purely software bugs pointed out by binary searching
 in the code that I'm sure has been tested, not only by its developers, but the
 bugs only showed up in my configuration (on one out of four test boxes).
 
 There are so many different kernel configurations possible that there's no way
 a developer can test them all.

With current state of affairs it's not only hard for developers, but
and for users: [EMAIL PROTECTED],
  [EMAIL PROTECTED]

I'm trying to re-do some kbuild stuff, but i'm getting rather offensive
answers :( [EMAIL PROTECTED]

(Even if i'm academic with free Internet, i doubt i even tried to
think to improve something, if i didn't have one, because i wouldn't knew
huge lkml traffic, problems, etc.)

Maybe i'm wrong. But reducing amount of traffic/files and ease of
(re-)configuration are not last things to be done for better testing.
All for speed of getting and compiling kernel. Latter for avoiding
bugs and noise due to inconsistent build configuration.

Finally again, bug-reporting and tracking tools, i've tried to discuss
are major problems out there I think it's plain easy and deal with. One
more example:

[EMAIL PROTECTED]
Xref: news.gmane.org gmane.linux.debian.devel.kernel:28095
http://permalink.gmane.org/gmane.linux.debian.devel.kernel/28095

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

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Adrian Bunk]

On Sun, Jun 17, 2007 at 04:24:30PM +0200, Oleg Verych wrote:
 On Sun, Jun 17, 2007 at 02:13:39PM +0200, Rafael J. Wysocki wrote:
  On Sunday, 17 June 2007 13:47, Oleg Verych wrote:
 []
   It's OK _only_ in case of unknown, hard to find *hardware* bugs.
   
   If you think it's a good thing for bad, untested by developer
   code, then something is completely wrong.
  
  Oh, I've just fixed two purely software bugs pointed out by binary searching
  in the code that I'm sure has been tested, not only by its developers, but 
  the
  bugs only showed up in my configuration (on one out of four test boxes).
  
  There are so many different kernel configurations possible that there's no 
  way
  a developer can test them all.
 
 With current state of affairs it's not only hard for developers, but
 and for users: [EMAIL PROTECTED],
   [EMAIL PROTECTED]

Uwe has an attitude that made many people (including Linus himself) 
set their mail filters to deliver his emails directly to /dev/null.

Parts of the contents of his emails were usable including usable 
regression reports - but the way he treats people simply disqualified 
him.

 I'm trying to re-do some kbuild stuff, but i'm getting rather offensive
 answers :( [EMAIL PROTECTED]
...

I'm not seeing anything in Thomas' email that could be considered 
offensive. He told you in a technical way why he disagrees with you.

If you call this email rather offensive, you should _really_ 
unsubscribe from lkml (or even any Debian mailing lists). And this is 
not meant against you, it's simply that for the standards of lkml there 
is nothing offensive in this email.

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[david]

On Sun, 17 Jun 2007, Oleg Verych wrote:


On Sun, Jun 17, 2007 at 12:22:26PM +0200, Michal Piotrowski wrote:

On 17/06/07, Andrew Morton [EMAIL PROTECTED] wrote:

On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski
[EMAIL PROTECTED] wrote:


+If the patch introduces a new regression and this regression was not

fixed

+in seven days, then the patch will be reverted.


Those regressions where we know which patch caused them are the easy ones.
Often we don't know which patch (or even which subsystem merge) is at
fault.

I think.  How many of the present 2.6.22-rc regressions which you're
presently tracking have such a well-identified cause?



Here lays the problem.

git-bisect is a killer app, people should start using it.


It's OK _only_ in case of unknown, hard to find *hardware* bugs.

If you think it's a good thing for bad, untested by developer
code, then something is completely wrong.

And if there's no debugger in the mainline kernel, which is developer's
tool, then why do you think testers must stick with git-bisect, as their
debugger-like tool (bandwidth in most and time consuming in some cases)?

That's wrong if developers are tending to reply only one thing --
git-bisect.

If things are going to be that bad, then better to start dealing with the
cause, not consequences. In this situation requesting test-cases is a
better way, as it's going to influence developer as cause of potential
problems. If tests will show *hardware* side of problem, then, well some
parts may be not obvious, thus bisecting is a way to continue.


most people who report bugs don't know enough about what's actually going 
wrong to be able to write a test case (those that do can probably just 
write a patch to fix it). Along similar lines a debugger wouldn't be of 
much use either.


the fact that git-bisect doesn't require any knowledge other then 
knowledge the reporter has demonstrated that they already have (the 
ability to compile and install their own kernel) puts it within the reach 
of testers.


unfortunantly, as good as it is it can take a lot of effort, especially if 
the bug takes time to show up. it's not perfect, but it's a huge help.


and developers aren't always responding with 'do a bisect', sometimes they 
respond with 'yes, we know about that' or 'that sounds like X', so it's 
still worthwhile for people to report the problem first before going to 
the ffort of doing a bisect.


David Lang
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

[Oleg Verych]

On Sun, Jun 17, 2007 at 10:44:39AM -0700, [EMAIL PROTECTED] wrote:
 On Sun, 17 Jun 2007, Oleg Verych wrote:
[]
 That's wrong if developers are tending to reply only one thing --
 git-bisect.
 
 If things are going to be that bad, then better to start dealing with the
 cause, not consequences. In this situation requesting test-cases is a
 better way, as it's going to influence developer as cause of potential
 problems. If tests will show *hardware* side of problem, then, well some
 parts may be not obvious, thus bisecting is a way to continue.
 
 most people who report bugs don't know enough about what's actually going 
 wrong to be able to write a test case (those that do can probably just 
 write a patch to fix it). Along similar lines a debugger wouldn't be of 
 much use either.

Sorry for my English. Requesting test cases from the developers of
course. Or at least results of some kind of testing, so people may run
and check them as well, if something is suspected. And this from my POV
leads again to organized way of filtering noise and collecting structured
information easily (yea, i think it's BTS with reportbug in Debian).{0}

 the fact that git-bisect doesn't require any knowledge other then 
 knowledge the reporter has demonstrated that they already have (the 
 ability to compile and install their own kernel) puts it within the reach 
 of testers.
 
 unfortunantly, as good as it is it can take a lot of effort, especially if 
 the bug takes time to show up. it's not perfect, but it's a huge help.

I think, positive feedback from {0} to the LTP may improve that.
Especially, if things are in parts and easy to choose for testing.

 and developers aren't always responding with 'do a bisect', sometimes they 
 respond with 'yes, we know about that'

 or 'that sounds like X',

That two are _exactly_ what reportbug tool is doing. That's why i'm
talking about it. And i'm *no* wonder why developers are boring -- at
some points they might not handle the *noise*.

 so it's still worthwhile for people to report the problem first before
 going to the ffort of doing a bisect.
 
 David Lang
__

Bits for Adrian.

*ML*

I *use* Gmane. I'm not subscribed (receiving e-mail to my mbox) to any ML,
except [EMAIL PROTECTED].

Nearly every my e-mail here is with Gmane links. You seem ignored all of
them. As for me it's result of *your personal*, rather than technical
activity.

*offense*

I'm not talking about personal offense, you are seem thinking about, but
technical one. I.e. when possible benefit might be even more, than NOHZ
on x86 and a like[0], with much less effort. I still think, unless i will
develop or fail, that reducing traffic on one or two order of magnitude
is possible as well as improving kbuild/kconfig to reduce of the noise of
mis-configurations/tester's .config length. Discouraging that effort is
my source of offense.

(FYI Until Linus checked in my _RFT_ kbuild patches, i realized how
*many* people are willing to understand and try to test kbuild stuff.)

[0] I bet VGA, DRAM, HDD are far more power hungry room-heaters. Unless
you can substantially lower frequency, you might have no benefit at
all. Whana know how it's done in perfectly designed embedded
MCU/CPU? Please, see for instance MSP430 from TI (i know, it uses
SRAM, but i've asked to look on processor core design).

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

Re: regression tracking (Re: Linux 2.6.21)

[Adrian Bunk]

On Sat, Jun 16, 2007 at 02:23:25PM +0200, Stefan Richter wrote:
>...
> [Adrian, I'm not saying "too few users run -rc kernels", I'm saying "too
> few FireWire driver users run -rc kernels".]

Getting more people testing -rc kernels might be possible, and I don't 
think it would be too hard. And not only FireWire would benefit from 
this, remember e.g. that at least 2 out of the last 5 kernels Linus 
released contained filesystem corruption regressions.

The problem is that we aren't able to handle the many regression reports 
we get today, so asking for more testing and regression reports today 
would attack it at the wrong part of the chain.

Additionally, every reported and unhandled regression will frustrate the 
reporter - never forget that we have _many_ unhandled bug reports 
(including but not limited to regression reports) where the submitter 
spent much time and energy in writing a good bug report.

If we somehow gain the missing manpower for debugging regressions we can 
actively ask for more testing. Missing manpower (of people knowing some 
part of the kernel well) for debugging bug reports is IMHO the one big 
source of quality problems in the Linux kernel. If we get this solved, 
things like getting more testers for -rc kernels will become low hanging 
fruits.

> Stefan Richter

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Adrian Bunk]

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Michal Piotrowski]

Hi Stefan,

On 16/06/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
[..]

Well, if _other_ subsystems would get regressions in Linus' tree fixed
quicker, there might perhaps be more people who would consider to run
-rc kernels and would catch and report "my" regressions.

[..]


[Adrian, I'm not saying "too few users run -rc kernels", I'm saying "too
few FireWire driver users run -rc kernels".]


Rafael is working on translation of "Linux Kernel Tester's Guide"
(it's almost finished). I hope you will get more -rc testers.

Regards,
Michal

--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Stefan Richter]

Oleg Verych wrote:
> On Sat, Jun 16, 2007 at 01:42:02AM +0200, Adrian Bunk wrote:
[...]
>> This means going through every single point in the regression list 
>> asking "Have we tried everything possible to solve this regression?". 
[...]
>> And a low hanging fruit to improve the release would be if you could 
>> release one last -rc, wait for 48 hours, and then release either this 
>> -rc unchanged as -final or another -rc (and wait another 48 hours).
>> There were at least two different regressions people ran into in 2.6.21 
>> who successfully tested -rc7.
> 
> What about Linus' tree is a development tree, Andrew's one is a "crazy
> development one" (quoting Linus)?
[...]

Linus also said that Andrew's tree is abused too often for broken stuff.

My goal for the little driver subsystem I'm maintaining is
  - everything that Andrew pulls from me builds and runs and doesn't
introduce regressions to my and the submitters' knowledge.  I am
slowly expanding my test procedures to catch things that fail that
goal.
  - Everything that Linus pulls from me fulfills the above criteria
and, in addition, had reasonable time and publication for test and
review, depending on the kind of patch.

I had a few regressions in Linus' releases.  None of them were known
before release.  All of them were debugged and fixed rather soon after
report, AFAIR.

So what _I_ need is neither better regression tracking nor more manpower
for debugging of regression reports.  What I need is more own spare time
and equipment for tests, more own knowledge and experience, and more
people who run-time test -rc kernels or at least my subsystem updates on
top of older kernels.

(Note, I'm talking only about regressions here, not old bugs.
There my requirements are different; the by far most important
one is more manpower for debugging and fixing.)

Well, if _other_ subsystems would get regressions in Linus' tree fixed
quicker, there might perhaps be more people who would consider to run
-rc kernels and would catch and report "my" regressions.

[Oleg, sorry that I too digressed from the subject of your thread, but
your remark about "[crazy] development tree"s caught my eye.  IMO people
should care for quality already in Andrew's tree --- more so than at the
moment.]

[Adrian, I'm not saying "too few users run -rc kernels", I'm saying "too
few FireWire driver users run -rc kernels".]
-- 
Stefan Richter
-=-=-=== -==- =
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Stefan Richter]

Oleg Verych wrote:
 On Sat, Jun 16, 2007 at 01:42:02AM +0200, Adrian Bunk wrote:
[...]
 This means going through every single point in the regression list 
 asking Have we tried everything possible to solve this regression?. 
[...]
 And a low hanging fruit to improve the release would be if you could 
 release one last -rc, wait for 48 hours, and then release either this 
 -rc unchanged as -final or another -rc (and wait another 48 hours).
 There were at least two different regressions people ran into in 2.6.21 
 who successfully tested -rc7.
 
 What about Linus' tree is a development tree, Andrew's one is a crazy
 development one (quoting Linus)?
[...]

Linus also said that Andrew's tree is abused too often for broken stuff.

My goal for the little driver subsystem I'm maintaining is
  - everything that Andrew pulls from me builds and runs and doesn't
introduce regressions to my and the submitters' knowledge.  I am
slowly expanding my test procedures to catch things that fail that
goal.
  - Everything that Linus pulls from me fulfills the above criteria
and, in addition, had reasonable time and publication for test and
review, depending on the kind of patch.

I had a few regressions in Linus' releases.  None of them were known
before release.  All of them were debugged and fixed rather soon after
report, AFAIR.

So what _I_ need is neither better regression tracking nor more manpower
for debugging of regression reports.  What I need is more own spare time
and equipment for tests, more own knowledge and experience, and more
people who run-time test -rc kernels or at least my subsystem updates on
top of older kernels.

(Note, I'm talking only about regressions here, not old bugs.
There my requirements are different; the by far most important
one is more manpower for debugging and fixing.)

Well, if _other_ subsystems would get regressions in Linus' tree fixed
quicker, there might perhaps be more people who would consider to run
-rc kernels and would catch and report my regressions.

[Oleg, sorry that I too digressed from the subject of your thread, but
your remark about [crazy] development trees caught my eye.  IMO people
should care for quality already in Andrew's tree --- more so than at the
moment.]

[Adrian, I'm not saying too few users run -rc kernels, I'm saying too
few FireWire driver users run -rc kernels.]
-- 
Stefan Richter
-=-=-=== -==- =
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Michal Piotrowski]

Hi Stefan,

On 16/06/07, Stefan Richter [EMAIL PROTECTED] wrote:
[..]

Well, if _other_ subsystems would get regressions in Linus' tree fixed
quicker, there might perhaps be more people who would consider to run
-rc kernels and would catch and report my regressions.

[..]


[Adrian, I'm not saying too few users run -rc kernels, I'm saying too
few FireWire driver users run -rc kernels.]


Rafael is working on translation of Linux Kernel Tester's Guide
(it's almost finished). I hope you will get more -rc testers.

Regards,
Michal

--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Adrian Bunk]

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Adrian Bunk]

On Sat, Jun 16, 2007 at 02:23:25PM +0200, Stefan Richter wrote:
...
 [Adrian, I'm not saying too few users run -rc kernels, I'm saying too
 few FireWire driver users run -rc kernels.]

Getting more people testing -rc kernels might be possible, and I don't 
think it would be too hard. And not only FireWire would benefit from 
this, remember e.g. that at least 2 out of the last 5 kernels Linus 
released contained filesystem corruption regressions.

The problem is that we aren't able to handle the many regression reports 
we get today, so asking for more testing and regression reports today 
would attack it at the wrong part of the chain.

Additionally, every reported and unhandled regression will frustrate the 
reporter - never forget that we have _many_ unhandled bug reports 
(including but not limited to regression reports) where the submitter 
spent much time and energy in writing a good bug report.

If we somehow gain the missing manpower for debugging regressions we can 
actively ask for more testing. Missing manpower (of people knowing some 
part of the kernel well) for debugging bug reports is IMHO the one big 
source of quality problems in the Linux kernel. If we get this solved, 
things like getting more testers for -rc kernels will become low hanging 
fruits.

 Stefan Richter

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Oleg Verych]

[I've added Herbert as former kernel team member in the debian(AFAIK),
 sorry, if i'm wrong and you have no opinion on that, Herbert.]

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:
> > > On Fri, Jun 15, 2007 at 04:20:57PM -0700, Linus Torvalds wrote:
> > > > 
> > > > 
> > > > On Thu, 14 Jun 2007, Oleg Verych wrote:
> > > > > 
> > > > > I'm seeing this long (198) thread and just have no idea how it has
> > > > > ended (wiki? hand-mailing?).
> > > > 
> > > > I'm hoping it's not "ended".
> > > > 
> > > > IOW, I really don't think we _resolved_ anything, although the work 
> > > > that 
> > > > Adrian started is continuing through the wiki and other people trying 
> > > > to 
> > > > track regressions, and that was obviously something good.
> > > > 
> > > > But I don't think we really know where we want to take this thing in 
> > > > the 
> > > > long run. I think everybody wants a better bug-tracking system, but 
> > > > whether something that makes people satisfied can even be built is 
> > > > open. 
> > > > It sure doesn't seem to exist right now ;)
> > > 
> > > The problem is not the bug tracking system, be it manual tracking in a 
> > > text file or a Wiki or be it in Bugzilla or any other bug tracking 
> > > system.
> > > 
> > > One problem is the lack of experienced developers willing to debug bug 
> > > reports.
> > 
> > *debug*
> > 
> > I hope you saw what subject i've chosen to bring this discussion back.
> > Yes, "tracking", as the first brick for big wall.
> 
> Tracking regressions is not a real problem.
> Especially since it doesn't require much technical knowledge.

I've tried to express different point of view. We have different ones {0}.
Thus, no comments.
 
> > Your arguments about developers and users, you've said already, but i've
> > asked different questions, have i?
> > 
> > Lets look on regular automatic report, like this one:
> > 
> > Message-ID: <[EMAIL PROTECTED]>
> > Xref: news.gmane.org gmane.linux.debian.devel.general:116248
> > Archived-At: 
> >  > 
> > And what we see? Basic packages, like ``dpkg'', ``grub'', ``mc'' are
> > in the list, requesting help. And as you can see for quite some time.
> > And it's *OK*, because distribution is working, development is going on.
> > Sometimes slowly, sometimes with delays.
> 
> I sent weekly regression reports.
> Not automatically generated but manually - but that doesn't matter.
> 
> The problem is that sending reports itself does not fix anything.

...{1}

> > > But what really annoyed me was the missing integration of regression 
> > > tracking into the release process, IOW how _you_ handled the regression 
> > > lists.
> > 
> > So, _tracking_ or _debugging_?
> 
> _debugging_ (can be indirectly by poking other people to do debugging)
> 
> > > If we want to offer something less of a disaster than 2.6.21, and if we 
> > > want to encourage people to start and continue testing -rc kernels, we 
> > > must try to fix as many reported regressions as reasonably possible.
> > 
> > *tracking*
> 
> no, *debugging*
> 
> I tracked regressions for the 2.6.21 disaster, and the not debugged 
> regressions that I had tracked are exactly where we should be better.

...{2}

> >...
> > > This means going through every single point in the regression list 
> > > asking "Have we tried everything possible to solve this regression?". 
> > > There are very mysterious regressions and there are regressions that 
> > > might simply be reported too late. But if at the time of the final 
> > > release 3 week old regressions hadn't been debugged at all there's 
> > > definitely room for improvement. And mere mortals like me reminding 
> > > people is often not enough, sometimes an email by Linus Torvalds himself 
> > > asking a patch author or maintainer to look after a regression might be 
> > > required.
> > 
> > *social* (first approximation)
> 
> Yes.
> 
> > That's a social problem, just like Debian loosing good kernel team members.
> 
> Different social problem.

The term ``like'' here means people are not able/willing to do work, they
might/can do. And cause of it is *social*, not technical. {1},{2} are
results of that problem/behavior. But according to {0}, you think,
differently.

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

Re: regression tracking (Re: Linux 2.6.21)

[Adrian Bunk]

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:
> > On Fri, Jun 15, 2007 at 04:20:57PM -0700, Linus Torvalds wrote:
> > > 
> > > 
> > > On Thu, 14 Jun 2007, Oleg Verych wrote:
> > > > 
> > > > I'm seeing this long (198) thread and just have no idea how it has
> > > > ended (wiki? hand-mailing?).
> > > 
> > > I'm hoping it's not "ended".
> > > 
> > > IOW, I really don't think we _resolved_ anything, although the work that 
> > > Adrian started is continuing through the wiki and other people trying to 
> > > track regressions, and that was obviously something good.
> > > 
> > > But I don't think we really know where we want to take this thing in the 
> > > long run. I think everybody wants a better bug-tracking system, but 
> > > whether something that makes people satisfied can even be built is open. 
> > > It sure doesn't seem to exist right now ;)
> > 
> > The problem is not the bug tracking system, be it manual tracking in a 
> > text file or a Wiki or be it in Bugzilla or any other bug tracking 
> > system.
> > 
> > One problem is the lack of experienced developers willing to debug bug 
> > reports.
> 
> *debug*
> 
> I hope you saw what subject i've chosen to bring this discussion back.
> Yes, "tracking", as the first brick for big wall.

Tracking regressions is not a real problem.
Especially since it doesn't require much technical knowledge.

> Your arguments about developers and users, you've said already, but i've
> asked different questions, have i?
> 
> Lets look on regular automatic report, like this one:
> 
> Message-ID: <[EMAIL PROTECTED]>
> Xref: news.gmane.org gmane.linux.debian.devel.general:116248
> Archived-At: 
>  
> And what we see? Basic packages, like ``dpkg'', ``grub'', ``mc'' are
> in the list, requesting help. And as you can see for quite some time.
> And it's *OK*, because distribution is working, development is going on.
> Sometimes slowly, sometimes with delays.

I sent weekly regression reports.
Not automatically generated but manually - but that doesn't matter.

The problem is that sending reports itself does not fix anything.

> > But what really annoyed me was the missing integration of regression 
> > tracking into the release process, IOW how _you_ handled the regression 
> > lists.
> 
> So, _tracking_ or _debugging_?

_debugging_ (can be indirectly by poking other people to do debugging)

> > If we want to offer something less of a disaster than 2.6.21, and if we 
> > want to encourage people to start and continue testing -rc kernels, we 
> > must try to fix as many reported regressions as reasonably possible.
> 
> *tracking*

no, *debugging*

I tracked regressions for the 2.6.21 disaster, and the not debugged 
regressions that I had tracked are exactly where we should be better.

>...
> > This means going through every single point in the regression list 
> > asking "Have we tried everything possible to solve this regression?". 
> > There are very mysterious regressions and there are regressions that 
> > might simply be reported too late. But if at the time of the final 
> > release 3 week old regressions hadn't been debugged at all there's 
> > definitely room for improvement. And mere mortals like me reminding 
> > people is often not enough, sometimes an email by Linus Torvalds himself 
> > asking a patch author or maintainer to look after a regression might be 
> > required.
> 
> *social* (first approximation)

Yes.

> That's a social problem, just like Debian loosing good kernel team members.

Different social problem.

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

> 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. E.g. writing a new filesystem is simply much 
more fun than learning and debugging other people's code in some old 
filesystem.

Talking about "team maintenance" sounds nice, but the problem in the 
kernel starts with code that has zero maintainers. And if there's 
already a maintainer, it's unlikely that he'll not accept patches from 
some new person debugging bug reports. But how to find people who will 
become good maintainers?

> Unfortunately problems with individuals in big machine with bad people,
> got randomly elected, can't be solved (IMHO). Even LKML's rule "patches
> are welcome", that is very technical, thus good, 

Re: regression tracking (Re: Linux 2.6.21)

[Oleg Verych]

On Sat, Jun 16, 2007 at 01:42:02AM +0200, Adrian Bunk wrote:
> On Fri, Jun 15, 2007 at 04:20:57PM -0700, Linus Torvalds wrote:
> > 
> > 
> > On Thu, 14 Jun 2007, Oleg Verych wrote:
> > > 
> > > I'm seeing this long (198) thread and just have no idea how it has
> > > ended (wiki? hand-mailing?).
> > 
> > I'm hoping it's not "ended".
> > 
> > IOW, I really don't think we _resolved_ anything, although the work that 
> > Adrian started is continuing through the wiki and other people trying to 
> > track regressions, and that was obviously something good.
> > 
> > But I don't think we really know where we want to take this thing in the 
> > long run. I think everybody wants a better bug-tracking system, but 
> > whether something that makes people satisfied can even be built is open. 
> > It sure doesn't seem to exist right now ;)
> 
> The problem is not the bug tracking system, be it manual tracking in a 
> text file or a Wiki or be it in Bugzilla or any other bug tracking 
> system.
> 
> One problem is the lack of experienced developers willing to debug bug 
> reports.

*debug*

I hope you saw what subject i've chosen to bring this discussion back.
Yes, "tracking", as the first brick for big wall.

Your arguments about developers and users, you've said already, but i've
asked different questions, have i?

Lets look on regular automatic report, like this one:

Message-ID: <[EMAIL PROTECTED]>
Xref: news.gmane.org gmane.linux.debian.devel.general:116248
Archived-At:  But what really annoyed me was the missing integration of regression 
> tracking into the release process, IOW how _you_ handled the regression 
> lists.

So, _tracking_ or _debugging_?

> If we want to offer something less of a disaster than 2.6.21, and if we 
> want to encourage people to start and continue testing -rc kernels, we 
> must try to fix as many reported regressions as reasonably possible.

*tracking*

Despite of tools, Debian have such thing as long release cycles, so
called ``Debian sickness''. And reason, i see, is what you've just
pointed out: less disaster, zer0 RC bugs. Plus everybody is volunteer,
big chunk of bureaucracy-based decisions. And all this for about
15000 packages.

* + reporting*

One side Linux is facing is hardware, and that kind of thing is very-very
diverse. LKML traffic is huge, yet there's no suitable tracking and
reporting *tool*.

> This means going through every single point in the regression list 
> asking "Have we tried everything possible to solve this regression?". 
> There are very mysterious regressions and there are regressions that 
> might simply be reported too late. But if at the time of the final 
> release 3 week old regressions hadn't been debugged at all there's 
> definitely room for improvement. And mere mortals like me reminding 
> people is often not enough, sometimes an email by Linus Torvalds himself 
> asking a patch author or maintainer to look after a regression might be 
> required.

*social* (first approximation)

That's a social problem, just like Debian loosing good kernel team members.

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

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

Unfortunately problems with individuals in big machine with bad people,
got randomly elected, can't be solved (IMHO). Even LKML's rule "patches
are welcome", that is very technical, thus good, doesn't work there.

Finally, read the end of 2.6.21 release message ;)

> And a low hanging fruit to improve the release would be if you could 
> release one last -rc, wait for 48 hours, and then release either this 
> -rc unchanged as -final or another -rc (and wait another 48 hours).
> There were at least two different regressions people ran into in 2.6.21 
> who successfully tested -rc7.

What about Linus' tree is a development tree, Andrew's one is a "crazy
development one" (quoting Linus)?

What about open (web page still exists) position on bug manager in
Google?

What about *volunteers* working from both developer's and user's
sides? What about "release is a reward" for everybody?

Balanced eco-system will oscillate. Be it .19(---++), .20(-),
.21(+) *relese*. That's natural, unless pushed to extremes.

I think, i can trust Linus in it, and you are welcome too.

*tools*

That's why i'm talking about tools, and started to discuss them.

My last try: reportbug (there's "-ng" one also), Debian BTS.

Adrian, 

Re: regression tracking (Re: Linux 2.6.21)

[Adrian Bunk]

On Fri, Jun 15, 2007 at 04:20:57PM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 14 Jun 2007, Oleg Verych wrote:
> > 
> > I'm seeing this long (198) thread and just have no idea how it has
> > ended (wiki? hand-mailing?).
> 
> I'm hoping it's not "ended".
> 
> IOW, I really don't think we _resolved_ anything, although the work that 
> Adrian started is continuing through the wiki and other people trying to 
> track regressions, and that was obviously something good.
> 
> But I don't think we really know where we want to take this thing in the 
> long run. I think everybody wants a better bug-tracking system, but 
> whether something that makes people satisfied can even be built is open. 
> It sure doesn't seem to exist right now ;)

The problem is not the bug tracking system, be it manual tracking in a 
text file or a Wiki or be it in Bugzilla or any other bug tracking 
system.

One problem is the lack of experienced developers willing to debug bug 
reports.

But what really annoyed me was the missing integration of regression 
tracking into the release process, IOW how _you_ handled the regression 
lists.

If we want to offer something less of a disaster than 2.6.21, and if we 
want to encourage people to start and continue testing -rc kernels, we 
must try to fix as many reported regressions as reasonably possible.

This means going through every single point in the regression list 
asking "Have we tried everything possible to solve this regression?". 
There are very mysterious regressions and there are regressions that 
might simply be reported too late. But if at the time of the final 
release 3 week old regressions hadn't been debugged at all there's 
definitely room for improvement. And mere mortals like me reminding 
people is often not enough, sometimes an email by Linus Torvalds himself 
asking a patch author or maintainer to look after a regression might be 
required.

And a low hanging fruit to improve the release would be if you could 
release one last -rc, wait for 48 hours, and then release either this 
-rc unchanged as -final or another -rc (and wait another 48 hours).
There were at least two different regressions people ran into in 2.6.21 
who successfully tested -rc7.

>   Linus

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Linus Torvalds]

On Thu, 14 Jun 2007, Oleg Verych wrote:
> 
> I'm seeing this long (198) thread and just have no idea how it has
> ended (wiki? hand-mailing?).

I'm hoping it's not "ended".

IOW, I really don't think we _resolved_ anything, although the work that 
Adrian started is continuing through the wiki and other people trying to 
track regressions, and that was obviously something good.

But I don't think we really know where we want to take this thing in the 
long run. I think everybody wants a better bug-tracking system, but 
whether something that makes people satisfied can even be built is open. 
It sure doesn't seem to exist right now ;)

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

Re: regression tracking (Re: Linux 2.6.21)

[Linus Torvalds]

On Thu, 14 Jun 2007, Oleg Verych wrote:
 
 I'm seeing this long (198) thread and just have no idea how it has
 ended (wiki? hand-mailing?).

I'm hoping it's not ended.

IOW, I really don't think we _resolved_ anything, although the work that 
Adrian started is continuing through the wiki and other people trying to 
track regressions, and that was obviously something good.

But I don't think we really know where we want to take this thing in the 
long run. I think everybody wants a better bug-tracking system, but 
whether something that makes people satisfied can even be built is open. 
It sure doesn't seem to exist right now ;)

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

Re: regression tracking (Re: Linux 2.6.21)

[Adrian Bunk]

On Fri, Jun 15, 2007 at 04:20:57PM -0700, Linus Torvalds wrote:
 
 
 On Thu, 14 Jun 2007, Oleg Verych wrote:
  
  I'm seeing this long (198) thread and just have no idea how it has
  ended (wiki? hand-mailing?).
 
 I'm hoping it's not ended.
 
 IOW, I really don't think we _resolved_ anything, although the work that 
 Adrian started is continuing through the wiki and other people trying to 
 track regressions, and that was obviously something good.
 
 But I don't think we really know where we want to take this thing in the 
 long run. I think everybody wants a better bug-tracking system, but 
 whether something that makes people satisfied can even be built is open. 
 It sure doesn't seem to exist right now ;)

The problem is not the bug tracking system, be it manual tracking in a 
text file or a Wiki or be it in Bugzilla or any other bug tracking 
system.

One problem is the lack of experienced developers willing to debug bug 
reports.

But what really annoyed me was the missing integration of regression 
tracking into the release process, IOW how _you_ handled the regression 
lists.

If we want to offer something less of a disaster than 2.6.21, and if we 
want to encourage people to start and continue testing -rc kernels, we 
must try to fix as many reported regressions as reasonably possible.

This means going through every single point in the regression list 
asking Have we tried everything possible to solve this regression?. 
There are very mysterious regressions and there are regressions that 
might simply be reported too late. But if at the time of the final 
release 3 week old regressions hadn't been debugged at all there's 
definitely room for improvement. And mere mortals like me reminding 
people is often not enough, sometimes an email by Linus Torvalds himself 
asking a patch author or maintainer to look after a regression might be 
required.

And a low hanging fruit to improve the release would be if you could 
release one last -rc, wait for 48 hours, and then release either this 
-rc unchanged as -final or another -rc (and wait another 48 hours).
There were at least two different regressions people ran into in 2.6.21 
who successfully tested -rc7.

   Linus

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Oleg Verych]

On Sat, Jun 16, 2007 at 01:42:02AM +0200, Adrian Bunk wrote:
 On Fri, Jun 15, 2007 at 04:20:57PM -0700, Linus Torvalds wrote:
  
  
  On Thu, 14 Jun 2007, Oleg Verych wrote:
   
   I'm seeing this long (198) thread and just have no idea how it has
   ended (wiki? hand-mailing?).
  
  I'm hoping it's not ended.
  
  IOW, I really don't think we _resolved_ anything, although the work that 
  Adrian started is continuing through the wiki and other people trying to 
  track regressions, and that was obviously something good.
  
  But I don't think we really know where we want to take this thing in the 
  long run. I think everybody wants a better bug-tracking system, but 
  whether something that makes people satisfied can even be built is open. 
  It sure doesn't seem to exist right now ;)
 
 The problem is not the bug tracking system, be it manual tracking in a 
 text file or a Wiki or be it in Bugzilla or any other bug tracking 
 system.
 
 One problem is the lack of experienced developers willing to debug bug 
 reports.

*debug*

I hope you saw what subject i've chosen to bring this discussion back.
Yes, tracking, as the first brick for big wall.

Your arguments about developers and users, you've said already, but i've
asked different questions, have i?

Lets look on regular automatic report, like this one:

Message-ID: [EMAIL PROTECTED]
Xref: news.gmane.org gmane.linux.debian.devel.general:116248
Archived-At: http://permalink.gmane.org/gmane.linux.debian.devel.general/116248

And what we see? Basic packages, like ``dpkg'', ``grub'', ``mc'' are
in the list, requesting help. And as you can see for quite some time.
And it's *OK*, because distribution is working, development is going on.
Sometimes slowly, sometimes with delays.

 But what really annoyed me was the missing integration of regression 
 tracking into the release process, IOW how _you_ handled the regression 
 lists.

So, _tracking_ or _debugging_?

 If we want to offer something less of a disaster than 2.6.21, and if we 
 want to encourage people to start and continue testing -rc kernels, we 
 must try to fix as many reported regressions as reasonably possible.

*tracking*

Despite of tools, Debian have such thing as long release cycles, so
called ``Debian sickness''. And reason, i see, is what you've just
pointed out: less disaster, zer0 RC bugs. Plus everybody is volunteer,
big chunk of bureaucracy-based decisions. And all this for about
15000 packages.

* + reporting*

One side Linux is facing is hardware, and that kind of thing is very-very
diverse. LKML traffic is huge, yet there's no suitable tracking and
reporting *tool*.

 This means going through every single point in the regression list 
 asking Have we tried everything possible to solve this regression?. 
 There are very mysterious regressions and there are regressions that 
 might simply be reported too late. But if at the time of the final 
 release 3 week old regressions hadn't been debugged at all there's 
 definitely room for improvement. And mere mortals like me reminding 
 people is often not enough, sometimes an email by Linus Torvalds himself 
 asking a patch author or maintainer to look after a regression might be 
 required.

*social* (first approximation)

That's a social problem, just like Debian loosing good kernel team members.

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

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

Unfortunately problems with individuals in big machine with bad people,
got randomly elected, can't be solved (IMHO). Even LKML's rule patches
are welcome, that is very technical, thus good, doesn't work there.

Finally, read the end of 2.6.21 release message ;)

 And a low hanging fruit to improve the release would be if you could 
 release one last -rc, wait for 48 hours, and then release either this 
 -rc unchanged as -final or another -rc (and wait another 48 hours).
 There were at least two different regressions people ran into in 2.6.21 
 who successfully tested -rc7.

What about Linus' tree is a development tree, Andrew's one is a crazy
development one (quoting Linus)?

What about open (web page still exists) position on bug manager in
Google?

What about *volunteers* working from both developer's and user's
sides? What about release is a reward for everybody?

Balanced eco-system will oscillate. Be it .19(---++), .20(-),
.21(+) *relese*. That's natural, unless pushed to extremes.

I think, i can trust Linus in it, and you are welcome too.

*tools*

That's why i'm talking about tools, and started to discuss them.

My last try: reportbug (there's -ng one also), Debian BTS.

Adrian, what can/must be done to adopt them? If not, your experience may
provide 

Re: regression tracking (Re: Linux 2.6.21)

[Adrian Bunk]

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:
  On Fri, Jun 15, 2007 at 04:20:57PM -0700, Linus Torvalds wrote:
   
   
   On Thu, 14 Jun 2007, Oleg Verych wrote:

I'm seeing this long (198) thread and just have no idea how it has
ended (wiki? hand-mailing?).
   
   I'm hoping it's not ended.
   
   IOW, I really don't think we _resolved_ anything, although the work that 
   Adrian started is continuing through the wiki and other people trying to 
   track regressions, and that was obviously something good.
   
   But I don't think we really know where we want to take this thing in the 
   long run. I think everybody wants a better bug-tracking system, but 
   whether something that makes people satisfied can even be built is open. 
   It sure doesn't seem to exist right now ;)
  
  The problem is not the bug tracking system, be it manual tracking in a 
  text file or a Wiki or be it in Bugzilla or any other bug tracking 
  system.
  
  One problem is the lack of experienced developers willing to debug bug 
  reports.
 
 *debug*
 
 I hope you saw what subject i've chosen to bring this discussion back.
 Yes, tracking, as the first brick for big wall.

Tracking regressions is not a real problem.
Especially since it doesn't require much technical knowledge.

 Your arguments about developers and users, you've said already, but i've
 asked different questions, have i?
 
 Lets look on regular automatic report, like this one:
 
 Message-ID: [EMAIL PROTECTED]
 Xref: news.gmane.org gmane.linux.debian.devel.general:116248
 Archived-At: 
 http://permalink.gmane.org/gmane.linux.debian.devel.general/116248
 
 And what we see? Basic packages, like ``dpkg'', ``grub'', ``mc'' are
 in the list, requesting help. And as you can see for quite some time.
 And it's *OK*, because distribution is working, development is going on.
 Sometimes slowly, sometimes with delays.

I sent weekly regression reports.
Not automatically generated but manually - but that doesn't matter.

The problem is that sending reports itself does not fix anything.

  But what really annoyed me was the missing integration of regression 
  tracking into the release process, IOW how _you_ handled the regression 
  lists.
 
 So, _tracking_ or _debugging_?

_debugging_ (can be indirectly by poking other people to do debugging)

  If we want to offer something less of a disaster than 2.6.21, and if we 
  want to encourage people to start and continue testing -rc kernels, we 
  must try to fix as many reported regressions as reasonably possible.
 
 *tracking*

no, *debugging*

I tracked regressions for the 2.6.21 disaster, and the not debugged 
regressions that I had tracked are exactly where we should be better.

...
  This means going through every single point in the regression list 
  asking Have we tried everything possible to solve this regression?. 
  There are very mysterious regressions and there are regressions that 
  might simply be reported too late. But if at the time of the final 
  release 3 week old regressions hadn't been debugged at all there's 
  definitely room for improvement. And mere mortals like me reminding 
  people is often not enough, sometimes an email by Linus Torvalds himself 
  asking a patch author or maintainer to look after a regression might be 
  required.
 
 *social* (first approximation)

Yes.

 That's a social problem, just like Debian loosing good kernel team members.

Different social problem.

 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.

 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. E.g. writing a new filesystem is simply much 
more fun than learning and debugging other people's code in some old 
filesystem.

Talking about team maintenance sounds nice, but the problem in the 
kernel starts with code that has zero maintainers. And if there's 
already a maintainer, it's unlikely that he'll not accept patches from 
some new person debugging bug reports. But how to find people who will 
become good maintainers?

 Unfortunately problems with individuals in big machine with bad people,
 got randomly elected, can't be solved (IMHO). Even LKML's rule patches
 are welcome, that is very technical, thus good, doesn't work there.

Debian has it's own problems, Linux kernel development at least has a 
working structure for getting decisions and regular 

Re: regression tracking (Re: Linux 2.6.21)

[Oleg Verych]

[I've added Herbert as former kernel team member in the debian(AFAIK),
 sorry, if i'm wrong and you have no opinion on that, Herbert.]

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:
   On Fri, Jun 15, 2007 at 04:20:57PM -0700, Linus Torvalds wrote:


On Thu, 14 Jun 2007, Oleg Verych wrote:
 
 I'm seeing this long (198) thread and just have no idea how it has
 ended (wiki? hand-mailing?).

I'm hoping it's not ended.

IOW, I really don't think we _resolved_ anything, although the work 
that 
Adrian started is continuing through the wiki and other people trying 
to 
track regressions, and that was obviously something good.

But I don't think we really know where we want to take this thing in 
the 
long run. I think everybody wants a better bug-tracking system, but 
whether something that makes people satisfied can even be built is 
open. 
It sure doesn't seem to exist right now ;)
   
   The problem is not the bug tracking system, be it manual tracking in a 
   text file or a Wiki or be it in Bugzilla or any other bug tracking 
   system.
   
   One problem is the lack of experienced developers willing to debug bug 
   reports.
  
  *debug*
  
  I hope you saw what subject i've chosen to bring this discussion back.
  Yes, tracking, as the first brick for big wall.
 
 Tracking regressions is not a real problem.
 Especially since it doesn't require much technical knowledge.

I've tried to express different point of view. We have different ones {0}.
Thus, no comments.
 
  Your arguments about developers and users, you've said already, but i've
  asked different questions, have i?
  
  Lets look on regular automatic report, like this one:
  
  Message-ID: [EMAIL PROTECTED]
  Xref: news.gmane.org gmane.linux.debian.devel.general:116248
  Archived-At: 
  http://permalink.gmane.org/gmane.linux.debian.devel.general/116248
  
  And what we see? Basic packages, like ``dpkg'', ``grub'', ``mc'' are
  in the list, requesting help. And as you can see for quite some time.
  And it's *OK*, because distribution is working, development is going on.
  Sometimes slowly, sometimes with delays.
 
 I sent weekly regression reports.
 Not automatically generated but manually - but that doesn't matter.
 
 The problem is that sending reports itself does not fix anything.

...{1}

   But what really annoyed me was the missing integration of regression 
   tracking into the release process, IOW how _you_ handled the regression 
   lists.
  
  So, _tracking_ or _debugging_?
 
 _debugging_ (can be indirectly by poking other people to do debugging)
 
   If we want to offer something less of a disaster than 2.6.21, and if we 
   want to encourage people to start and continue testing -rc kernels, we 
   must try to fix as many reported regressions as reasonably possible.
  
  *tracking*
 
 no, *debugging*
 
 I tracked regressions for the 2.6.21 disaster, and the not debugged 
 regressions that I had tracked are exactly where we should be better.

...{2}

 ...
   This means going through every single point in the regression list 
   asking Have we tried everything possible to solve this regression?. 
   There are very mysterious regressions and there are regressions that 
   might simply be reported too late. But if at the time of the final 
   release 3 week old regressions hadn't been debugged at all there's 
   definitely room for improvement. And mere mortals like me reminding 
   people is often not enough, sometimes an email by Linus Torvalds himself 
   asking a patch author or maintainer to look after a regression might be 
   required.
  
  *social* (first approximation)
 
 Yes.
 
  That's a social problem, just like Debian loosing good kernel team members.
 
 Different social problem.

The term ``like'' here means people are not able/willing to do work, they
might/can do. And cause of it is *social*, not technical. {1},{2} are
results of that problem/behavior. But according to {0}, you think,
differently.

  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 

Re: regression tracking (Re: Linux 2.6.21)

[Adrian Bunk]

On Thu, Jun 14, 2007 at 10:33:38PM +0200, Oleg Verych wrote:
>...
> Also, after i saw Linus' message about doing mostly tools last couple of
> years, i wonder why you, Adrian, didn't think about your tools first,
> before you've started regression tracking? You are not running in front
> of a train, unlike you know who does, plus bugzilla issues are known for
> years. Luckily Fedora kernel guys also upstream developers, thus lkml and
> other MLs under their view.

My tool was a textfile with a text editor.
For a smaller amount of regressions that works fine.

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.

> After having read all that, i've asked you, my question, as the person
> who supposedly used BTS as a maintainer.
> 
> Yes, in current form it might not be in suitable configuration, i.e.
> kernel sub-systems instead of packages etc, anyway main thing is the way
> BTS is handled. While i was looking and replying for bug reports in the
> Debian kernel, that i saw in lkml, i've noticed, just how guys work with
> it there. Now they even came up with tracking upstream bugzilla, it
> seems [0]. I left that activity due to RL some months ago, but now trying
> to catch up things again.
>...

Both the Debian BTS and Bugzilla are usable programs with their own
advantages and disadvantages.

I don't believe switching to the Debian BTS would solve any problem.

> > And we need a release process that makes debugging, and if possible 
> > fixing, all regressions prior to the release mandatory. You might never 
> > come down to zero regressions and might not be able to handle all 
> > last-minute reported regressions, but the 2.6.21 situation with 3 week 
> > old known regressions not ever being debugged by a kernel developer 
> > before the release has much room for improvements.
> > 
> > Changing the BTS would make sense if some core developers would state 
> > that they would start using the BTS after this change. But otherwise it 
> > doesn't matter which BTS to use.
> 
> So, as i've wrote before: one must give them pretty-shiny tool, kindly
> barking in their inboxes, instead of for example
> 
> "Guilty:  * <[EMAIL PROTECTED]>",
> 
> as it was on the very beginning.

A pretty-shiny tools wouldn't change anything.

What you need are humans debugging the regresssions and humans remining 
other humans that they should debug the regressions.

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Oleg Verych]

On Thu, Jun 14, 2007 at 07:30:49PM +0200, Adrian Bunk wrote:
> On Thu, Jun 14, 2007 at 06:39:23PM +0200, Oleg Verych wrote:
[]
> > I know, that most developers here are not working/familiar with what
> > Debian has as its bug shooting weapon ``The system is mainly controlled
> > by  e-mail, but the bug reports can be viewed using the WWW.''[0].
> > 
> > I thought somebody, who familiar with that, might propose to setup/tune
> > it, but not doing yet another NIH thing, especially from e-mail
> > integration POV. I doubt mozilla guys can think about it without
> > javascript and/or java servlets :)
> >...
> 
> The problem isn't Bugzilla, and the Debian BTS wouldn't solve any 
> problem.
> 
> What is missing?
> 
> We need people who know one or more subsystems and who are willing to 
> regularly handle bug reports in their area.

I think if somebody, by example will show how it can be handled in more
convenient way, that will eventually become mainstream. As we know,
nothing gets from vacuum just like that, without taking energy and time.
And my question was not about this social problem of acceptance, support
etc.

Linus had spent some time in this thread trying to explain what problems
are: as from that (social, think scheduler :) POV, as also from
"zarro bogs found" one.

Also, after i saw Linus' message about doing mostly tools last couple of
years, i wonder why you, Adrian, didn't think about your tools first,
before you've started regression tracking? You are not running in front
of a train, unlike you know who does, plus bugzilla issues are known for
years. Luckily Fedora kernel guys also upstream developers, thus lkml and
other MLs under their view.

After having read all that, i've asked you, my question, as the person
who supposedly used BTS as a maintainer.

Yes, in current form it might not be in suitable configuration, i.e.
kernel sub-systems instead of packages etc, anyway main thing is the way
BTS is handled. While i was looking and replying for bug reports in the
Debian kernel, that i saw in lkml, i've noticed, just how guys work with
it there. Now they even came up with tracking upstream bugzilla, it
seems [0]. I left that activity due to RL some months ago, but now trying
to catch up things again.

Thus it's just my curiosity about all this. And BTS is like, you know,
why not, if it fits by mostly all parameters?

[0] Message-ID: <[EMAIL PROTECTED]>
Xref: news.gmane.org gmane.linux.debian.devel.kernel:29426
Archived-At: 



> And we need a release process that makes debugging, and if possible 
> fixing, all regressions prior to the release mandatory. You might never 
> come down to zero regressions and might not be able to handle all 
> last-minute reported regressions, but the 2.6.21 situation with 3 week 
> old known regressions not ever being debugged by a kernel developer 
> before the release has much room for improvements.
> 
> Changing the BTS would make sense if some core developers would state 
> that they would start using the BTS after this change. But otherwise it 
> doesn't matter which BTS to use.

So, as i've wrote before: one must give them pretty-shiny tool, kindly
barking in their inboxes, instead of for example

"Guilty:  * <[EMAIL PROTECTED]>",

as it was on the very beginning.

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

Re: regression tracking (Re: Linux 2.6.21)

[Adrian Bunk]

On Thu, Jun 14, 2007 at 06:39:23PM +0200, Oleg Verych wrote:
> On Thu, Jun 14, 2007 at 05:33:40PM +0200, Stefan Richter wrote:
> []
> > [...]
> > > Why you didn't proposed (used) Debian's BTS as alternative to bugzilla,
> > [...]
> > 
> > BTS has been mentioned in that thread in a few posts; mostly positively
> > as I recall.
> 
> I know, that most developers here are not working/familiar with what
> Debian has as its bug shooting weapon ``The system is mainly controlled
> by  e-mail, but the bug reports can be viewed using the WWW.''[0].
> 
> I thought somebody, who familiar with that, might propose to setup/tune
> it, but not doing yet another NIH thing, especially from e-mail
> integration POV. I doubt mozilla guys can think about it without
> javascript and/or java servlets :)
>...

The problem isn't Bugzilla, and the Debian BTS wouldn't solve any 
problem.

What is missing?

We need people who know one or more subsystems and who are willing to 
regularly handle bug reports in their area.

And we need a release process that makes debugging, and if possible 
fixing, all regressions prior to the release mandatory. You might never 
come down to zero regressions and might not be able to handle all 
last-minute reported regressions, but the 2.6.21 situation with 3 week 
old known regressions not ever being debugged by a kernel developer 
before the release has much room for improvements.

Changing the BTS would make sense if some core developers would state 
that they would start using the BTS after this change. But otherwise it 
doesn't matter which BTS to use.

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Stefan Richter]

Oleg Verych wrote:
> I thought somebody, who familiar with that, might propose to setup/tune
> it, but not doing yet another NIH thing,

I may have missed something, but I recall that Adrian's bugtracking,
while it lasted, and now Michal's continuing it mostly came into being
because Adrian just started doing it and others soon found it very useful.
-- 
Stefan Richter
-=-=-=== -==- -===-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Oleg Verych]

On Thu, Jun 14, 2007 at 05:33:40PM +0200, Stefan Richter wrote:
[]
> [...]
> > Why you didn't proposed (used) Debian's BTS as alternative to bugzilla,
> [...]
> 
> BTS has been mentioned in that thread in a few posts; mostly positively
> as I recall.

I know, that most developers here are not working/familiar with what
Debian has as its bug shooting weapon ``The system is mainly controlled
by  e-mail, but the bug reports can be viewed using the WWW.''[0].

I thought somebody, who familiar with that, might propose to setup/tune
it, but not doing yet another NIH thing, especially from e-mail
integration POV. I doubt mozilla guys can think about it without
javascript and/or java servlets :)

[0] 

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

Re: regression tracking (Re: Linux 2.6.21)

[Stefan Richter]

Oleg Verych wrote:
> I'm seeing this long (198) thread and just have no idea how it has
> ended (wiki? hand-mailing?).

Direct or indirect results:

  - See Michal Piotrowski's periodic posts and
http://kernelnewbies.org/known_regressions .

  - Meanwhile, the people who maintain bugzilla.kernel.org seem to work
on improvements.  I noticed that (a) each page now has a backlink to
the bugzilla.kernel.org start page, (b) the show_bug.cgi=... page
layout is now an unreadable mess, (c) e-mail integration is still
the same (it's impossible at least for me to send e-mails to bugs).

[...]
> Why you didn't proposed (used) Debian's BTS as alternative to bugzilla,
[...]

BTS has been mentioned in that thread in a few posts; mostly positively
as I recall.
-- 
Stefan Richter
-=-=-=== -==- -===-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Stefan Richter]

Oleg Verych wrote:
 I'm seeing this long (198) thread and just have no idea how it has
 ended (wiki? hand-mailing?).

Direct or indirect results:

  - See Michal Piotrowski's periodic posts and
http://kernelnewbies.org/known_regressions .

  - Meanwhile, the people who maintain bugzilla.kernel.org seem to work
on improvements.  I noticed that (a) each page now has a backlink to
the bugzilla.kernel.org start page, (b) the show_bug.cgi=... page
layout is now an unreadable mess, (c) e-mail integration is still
the same (it's impossible at least for me to send e-mails to bugs).

[...]
 Why you didn't proposed (used) Debian's BTS as alternative to bugzilla,
[...]

BTS has been mentioned in that thread in a few posts; mostly positively
as I recall.
-- 
Stefan Richter
-=-=-=== -==- -===-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Oleg Verych]

On Thu, Jun 14, 2007 at 05:33:40PM +0200, Stefan Richter wrote:
[]
 [...]
  Why you didn't proposed (used) Debian's BTS as alternative to bugzilla,
 [...]
 
 BTS has been mentioned in that thread in a few posts; mostly positively
 as I recall.

I know, that most developers here are not working/familiar with what
Debian has as its bug shooting weapon ``The system is mainly controlled
by  e-mail, but the bug reports can be viewed using the WWW.''[0].

I thought somebody, who familiar with that, might propose to setup/tune
it, but not doing yet another NIH thing, especially from e-mail
integration POV. I doubt mozilla guys can think about it without
javascript and/or java servlets :)

[0] http://www.debian.org/Bugs/

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

Re: regression tracking (Re: Linux 2.6.21)

[Stefan Richter]

Oleg Verych wrote:
 I thought somebody, who familiar with that, might propose to setup/tune
 it, but not doing yet another NIH thing,

I may have missed something, but I recall that Adrian's bugtracking,
while it lasted, and now Michal's continuing it mostly came into being
because Adrian just started doing it and others soon found it very useful.
-- 
Stefan Richter
-=-=-=== -==- -===-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Adrian Bunk]

On Thu, Jun 14, 2007 at 06:39:23PM +0200, Oleg Verych wrote:
 On Thu, Jun 14, 2007 at 05:33:40PM +0200, Stefan Richter wrote:
 []
  [...]
   Why you didn't proposed (used) Debian's BTS as alternative to bugzilla,
  [...]
  
  BTS has been mentioned in that thread in a few posts; mostly positively
  as I recall.
 
 I know, that most developers here are not working/familiar with what
 Debian has as its bug shooting weapon ``The system is mainly controlled
 by  e-mail, but the bug reports can be viewed using the WWW.''[0].
 
 I thought somebody, who familiar with that, might propose to setup/tune
 it, but not doing yet another NIH thing, especially from e-mail
 integration POV. I doubt mozilla guys can think about it without
 javascript and/or java servlets :)
...

The problem isn't Bugzilla, and the Debian BTS wouldn't solve any 
problem.

What is missing?

We need people who know one or more subsystems and who are willing to 
regularly handle bug reports in their area.

And we need a release process that makes debugging, and if possible 
fixing, all regressions prior to the release mandatory. You might never 
come down to zero regressions and might not be able to handle all 
last-minute reported regressions, but the 2.6.21 situation with 3 week 
old known regressions not ever being debugged by a kernel developer 
before the release has much room for improvements.

Changing the BTS would make sense if some core developers would state 
that they would start using the BTS after this change. But otherwise it 
doesn't matter which BTS to use.

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression tracking (Re: Linux 2.6.21)

[Oleg Verych]

On Thu, Jun 14, 2007 at 07:30:49PM +0200, Adrian Bunk wrote:
 On Thu, Jun 14, 2007 at 06:39:23PM +0200, Oleg Verych wrote:
[]
  I know, that most developers here are not working/familiar with what
  Debian has as its bug shooting weapon ``The system is mainly controlled
  by  e-mail, but the bug reports can be viewed using the WWW.''[0].
  
  I thought somebody, who familiar with that, might propose to setup/tune
  it, but not doing yet another NIH thing, especially from e-mail
  integration POV. I doubt mozilla guys can think about it without
  javascript and/or java servlets :)
 ...
 
 The problem isn't Bugzilla, and the Debian BTS wouldn't solve any 
 problem.
 
 What is missing?
 
 We need people who know one or more subsystems and who are willing to 
 regularly handle bug reports in their area.

I think if somebody, by example will show how it can be handled in more
convenient way, that will eventually become mainstream. As we know,
nothing gets from vacuum just like that, without taking energy and time.
And my question was not about this social problem of acceptance, support
etc.

Linus had spent some time in this thread trying to explain what problems
are: as from that (social, think scheduler :) POV, as also from
zarro bogs found one.

Also, after i saw Linus' message about doing mostly tools last couple of
years, i wonder why you, Adrian, didn't think about your tools first,
before you've started regression tracking? You are not running in front
of a train, unlike you know who does, plus bugzilla issues are known for
years. Luckily Fedora kernel guys also upstream developers, thus lkml and
other MLs under their view.

After having read all that, i've asked you, my question, as the person
who supposedly used BTS as a maintainer.

Yes, in current form it might not be in suitable configuration, i.e.
kernel sub-systems instead of packages etc, anyway main thing is the way
BTS is handled. While i was looking and replying for bug reports in the
Debian kernel, that i saw in lkml, i've noticed, just how guys work with
it there. Now they even came up with tracking upstream bugzilla, it
seems [0]. I left that activity due to RL some months ago, but now trying
to catch up things again.

Thus it's just my curiosity about all this. And BTS is like, you know,
why not, if it fits by mostly all parameters?

[0] Message-ID: [EMAIL PROTECTED]
Xref: news.gmane.org gmane.linux.debian.devel.kernel:29426
Archived-At: 
http://permalink.gmane.org/gmane.linux.debian.devel.kernel/29426


 And we need a release process that makes debugging, and if possible 
 fixing, all regressions prior to the release mandatory. You might never 
 come down to zero regressions and might not be able to handle all 
 last-minute reported regressions, but the 2.6.21 situation with 3 week 
 old known regressions not ever being debugged by a kernel developer 
 before the release has much room for improvements.
 
 Changing the BTS would make sense if some core developers would state 
 that they would start using the BTS after this change. But otherwise it 
 doesn't matter which BTS to use.

So, as i've wrote before: one must give them pretty-shiny tool, kindly
barking in their inboxes, instead of for example

Guilty:  * [EMAIL PROTECTED],

as it was on the very beginning.

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

Re: regression tracking (Re: Linux 2.6.21)

[Adrian Bunk]

On Thu, Jun 14, 2007 at 10:33:38PM +0200, Oleg Verych wrote:
...
 Also, after i saw Linus' message about doing mostly tools last couple of
 years, i wonder why you, Adrian, didn't think about your tools first,
 before you've started regression tracking? You are not running in front
 of a train, unlike you know who does, plus bugzilla issues are known for
 years. Luckily Fedora kernel guys also upstream developers, thus lkml and
 other MLs under their view.

My tool was a textfile with a text editor.
For a smaller amount of regressions that works fine.

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.

 After having read all that, i've asked you, my question, as the person
 who supposedly used BTS as a maintainer.
 
 Yes, in current form it might not be in suitable configuration, i.e.
 kernel sub-systems instead of packages etc, anyway main thing is the way
 BTS is handled. While i was looking and replying for bug reports in the
 Debian kernel, that i saw in lkml, i've noticed, just how guys work with
 it there. Now they even came up with tracking upstream bugzilla, it
 seems [0]. I left that activity due to RL some months ago, but now trying
 to catch up things again.
...

Both the Debian BTS and Bugzilla are usable programs with their own
advantages and disadvantages.

I don't believe switching to the Debian BTS would solve any problem.

  And we need a release process that makes debugging, and if possible 
  fixing, all regressions prior to the release mandatory. You might never 
  come down to zero regressions and might not be able to handle all 
  last-minute reported regressions, but the 2.6.21 situation with 3 week 
  old known regressions not ever being debugged by a kernel developer 
  before the release has much room for improvements.
  
  Changing the BTS would make sense if some core developers would state 
  that they would start using the BTS after this change. But otherwise it 
  doesn't matter which BTS to use.
 
 So, as i've wrote before: one must give them pretty-shiny tool, kindly
 barking in their inboxes, instead of for example
 
 Guilty:  * [EMAIL PROTECTED],
 
 as it was on the very beginning.

A pretty-shiny tools wouldn't change anything.

What you need are humans debugging the regresssions and humans remining 
other humans that they should debug the regressions.

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/