Re: This is [Re:] How to improve the quality of the kernel[?].

On Tue, Jun 19, 2007 at 04:05:12PM +0200, Oleg Verych wrote:
...
On Tue, Jun 19, 2007 at 02:48:55PM +0200, Adrian Bunk wrote:
On Tue, Jun 19, 2007 at 06:06:47AM +0200, Oleg Verych wrote:
...
When patch in sent to this PTS, your lovely
checkpatch/check-whatever-crap-has-being-sent tools can be set up as
gatekeepers, thus making impossible stupid errors with MIME coding,
line wrapping, whatever style you've came up with now in checking
sent crap.

The -mm kernel already implements what your proposed PTS would do.

Having all-in-one patchset, like -mm is easy thing to provide
interested parties with "you know what you have -- crazy development"

However [P]TS is tracking, recording, organizing tool. {1} Andrew's cron
daemon easily can run script to check status of particular patch (cc,
tested-by, acked-by). If patch have no TS ID, Andrew's watchdog is
barking back to patch originator (with polite asking to send patch as:

* TS as "To:" target
* patch author as "Cc:" target, this is useful to require:
. author can check that copy himself with text-only pager program
(to see any MIME coding crap)
. preventing SPAM
* maybe somebody else in Cc or Bcc.)

Quite a big part of -mm are git trees of maintainers.
Where are they in your tool?

And I still don't think your tool would make sense.
But hey, simply try it - that's the only way for you to prove me wrong.
People said similar things about the 2.6.16 kernel or my regression
tracking, and I simply did it.

Plus it gives testers more or less all patches currently pending
inclusion into Linus' tree in one kernel they can test.

Crazy development{0}. Somebody knows, that comprehensively testing
hibernation is their thing. I don't care about it, i care about foo, bar.
Thus i can apply for example lguest patches and implement and test new
asm-offset replacement, *easily*. Somebody, as you know, likes new fancy
file system, and no-way other. Let them be happy testing that thing
*easily*. Because another fancy NO_MHz will hang their testing bench
right after best ever speed results were recorded.

Patch dependencies and patch conflicts will be the interesting parts
when you will implement this.

E.g. new fancy filesystem patch in -mm might depend on some VFS change
that requires changes to all other filesystems.

I'm really looking forward to see how you will implement this for
something like -mm with > 1000 patches (many of them git trees that
themselves contain many different patches) without offloading all the
additional work to the kernel developers.

The problem are more social problems like patches Andrew has never heard
of before getting into Linus' tree during the merge window.

Linus' watchdog, as well, asking for valid patch id, or just doesn't
care (in similar manner Linus does :).

So far no human is involved in social things. Do you agree?

No.

Forcing people to use some tool (no matter whether it's Bugzilla or
the PTS you want to implement) is 100% a social problem involving humans.

Human power is worth and needed in particular patch discussion and
testing under the participation (by Cc, acking, test-ok *e-mails*) of
tracking system.

For getting people to use your tool, you will have to convince them that
using your tool will bring them real benefits.

...
|-*- Feature Needed -*-
Addition, needed is hardware user tested have/had/used. Currently
``reportbug'' tool includes packed specific and system specific
additions automaticly gathered and inserted to e-mail sent to BTS.
(e.g. <http://permalink.gmane.org/gmane.linux.debian.devel.kernel/29740>)

The problem is that most problems don't occur on one well-defined
kind of hardware - patches often break in exactly the areas the patch
author expected no problems in.

I tried to test that new fancy FS, and couldn't boot because of
yet-another ACPI crap. See theme{0}?

Overall testing, like Andrew does, is doubtless brave thing, but he have
more time after {1}, isn't it?

I doubt the placing of some Acked-By- tags in patches is really what
is killing Andrews time.

How does Andrew check the status of 1500 patches in -mm in your PTS?

And how do you implement the use case that Andrew forwards a batch of
200 patches to Linus? How does the information from your tool come into git?

But hey, write your tool and convince Andrew of it's advantages if you
don't believe me.

And in many cases a patch for a device driver was written due to a bug
report - in such cases a tester with the hardware in question is already
available.

Tracking all possible testers (for next driver update, for example) is
in question.

Spamming people who have some hardware with information about patches
won't bring you anything. You need people willing to test patches that
won't bring them any benefit - and if you have such people they are
usually as well willing to simply regularly test -rc kernels.

...
but in the end, it needs to also be easy and painfree to the people
involved, and also make sure that any added workflow doesn't require
even *more* load and expertise on the already often overworked
maintainers..

Experienced BTS users and developers. Please, correct me if i'm wrong.
At least e-mail part of Debian's BTS and whole idea of it is *exactly*
what is needed. Bugzilla fans, you can still use you useless pet,
because Debian developers have done things, to track and e-mail states
of bugs: <http://permalink.gmane.org/gmane.linux.debian.devel.kernel/29736>
...

"useless pet"?
Be serious.
How many open source projects use Bugzilla and how many use the Debian BTS?
And then start thinking about why the "useless pet" has so many more
user...

I might be stupid, but i faced it. On my amd64 512M laptop i *cannot* run
mozillka any more, for example!

Why not?

And i don't care, because Linus said his
opinion and i fully agree with him.

Did Linus state he would actually actively use a Debian BTS?
If not, then there's no advantage.

The Debian BTS requires you to either write emails with control messages
or generating control messages with external tools.

Awesome!!! Are you wrote this reply to me by

In Bugzilla the same works through a web interface.

web interface? If you did .........</dev/random dd bs=1 count=13.....
Actually you didn't ;)

There's a difference between a discussion email and a control message in
a fixed format.

I know both the Debian BTS and Bugzilla and although they are quite
different they both are reasonable tools for their purpose.

As you just might have seen here, i was talking about organizing,
tracking, hopefully saving and redirecting useful main power. And i don't
bother search e-mails i saw about Bugzilla's BD from many other prominent
developers. I just know that, not from my dream or physical vacuum.

Basic concept of Debian BTS is what i've discovered after many useless
hours i spent in Bugzilla. And this is mainly because of one basic
important thing, that nobody acknowledged (for newbies, like me):

* E-Mail with useful MUAs, after it got reliable delivery MTAs with qmail
(or exim) is the main communication toolset.
...

How do people sell and buy goods at eBay?
eBay has a "do everything through the web interface plus notification
emails" quite similar to Bugzilla.

Or Wikis?
Or Blogs?

cu
Adrian

--

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

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

Relevant Pages

  • Re: [PATCH] new CSA patchset for 2.6.8
    ... Please don't send patches as attachments, and please don't send more than ... one patch per email. ... judging how useful this feature is to Linux implementors and how well this ... > functional kernel. ...
    (Linux-Kernel)
  • Re: Documentation - how to apply patches for various trees
    ... >> explanation of the various kernel trees and how to apply their patches. ... +a patch to the kernel or, more specifically, what base kernel a patch for ... +and what new version the patch will change the source tree into. ...
    (Linux-Kernel)
  • Re: Documentation - how to apply patches for various trees
    ... >> explanation of the various kernel trees and how to apply their patches. ... +a patch to the kernel or, more specifically, what base kernel a patch for ... +kernel source directories it was generated against. ...
    (Linux-Kernel)
  • [PATCH] add EOWNERDEAD and ENOTRECOVERABLE
    ... that uses them yet, I know of two patches in development, ... There is interest in robust mutexes in Linux, ... Even though there are kernel components to the robust mutex ... I know that it is rare for an unused patch to be accepted; ...
    (Linux-Kernel)
  • 9_Recommended error codes (specifically return code 5)
    ... * "return code 2" indicates patches are already installed. ... * "return code 25" means a patches requires another patch that is not yet installed. ... With or without using the save option, the patch installation process ... Installing 114008-01... ...
    (SunManagers)