From: Andrew Morton <akpm@linux-foundation.org>
To: Jeff Garzik <jeff@garzik.org>
Cc: Mark Lord <liml@rtr.ca>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Tejun Heo <htejun@gmail.com>,
linux-ide@vger.kernel.org
Subject: Re: Polling (was Re: [PATCHSET 2/2] implement PMP support, take 6)
Date: Fri, 28 Sep 2007 21:58:54 -0700 [thread overview]
Message-ID: <20070928215854.da085fa3.akpm@linux-foundation.org> (raw)
In-Reply-To: <46FDC6A8.3000306@garzik.org>
On Fri, 28 Sep 2007 23:29:44 -0400 Jeff Garzik <jeff@garzik.org> wrote:
> (my last response only addressed -mm)
>
> Mark Lord wrote:
> > I believe the point was that getting things into libata is glacial
>
> IMHO would say that there are two causes of that:
> 1) I am sometimes slow in merging, part of which is my own fault, and I
> can only promise to try and do better there. Part of which is a result
> of stuff being dependent on -mm (which requires plenty of time
> hand-merging) rather than libata-dev.git#upstream.
>
> 2) I have been intentionally staging major libata behavior changes
> between Linux releases. Luckily most of these are behind us, but, in
> several cases with things like ACPI on/off (hopefully 'on' in 2.6.24),
> probing changes (switchover to new EH for probing via hotplug, etc.),
> interrupt handling changes.
>
> I dislike getting "too much" into a single release, because of the
> difficulty of getting large scale feedback without a major kernel release.
>
> So far I think the kernel releases have been pretty darn successful in
> "not breaking everybody" but that clearly conflicts with desired
> development speed, given the glacial pace of each kernel release. If
> each kernel release were 1-2 months apart, we would have many more
> testing points, and I think you guys and I would both be happy. But
> that's not the reality today, with 3+ month kernel release cycles (ugh!!).
>
> I'm very much interested in hearing suggestions and comments.
>
There's an easy fix...
The releases are slow because a) there's so much stuff in them and b) it
takes so long to stabilise it all.
If all developers were to be more careful in their work, and take more time
to review and test others' work, both problems get fixed: less code, higher
quality.
We don't know how to make this happen. We haven't even tried.
next prev parent reply other threads:[~2007-09-29 4:59 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-23 4:19 [PATCHSET 2/2] implement PMP support, take 6 Tejun Heo
2007-09-23 4:19 ` [PATCH 01/10] libata-pmp: update ata_eh_reset() for PMP Tejun Heo
2007-09-23 4:19 ` [PATCH 04/10] libata-pmp: extend ACPI support to cover PMP Tejun Heo
2007-09-23 4:19 ` [PATCH 03/10] libata-pmp: hook PMP support and enable it Tejun Heo
2007-09-23 4:19 ` [PATCH 02/10] libata-pmp: implement Port Multiplier support Tejun Heo
2007-09-23 4:19 ` [PATCH 07/10] sata_sil24: implement PORT_RST Tejun Heo
2007-09-23 4:19 ` [PATCH 06/10] sata_sil24: implement PMP support Tejun Heo
2007-09-23 4:19 ` [PATCH 05/10] libata-pmp: implement qc_defer for command switching " Tejun Heo
2007-09-23 4:19 ` [PATCH 08/10] ahci: implement " Tejun Heo
2007-09-23 4:19 ` [PATCH 09/10] ahci: move host flags over to pi.private_data Tejun Heo
2007-09-23 4:19 ` [PATCH 10/10] ahci: implement AHCI_HFLAG_NO_PMP Tejun Heo
2007-09-26 2:09 ` Polling (was Re: [PATCHSET 2/2] implement PMP support, take 6) Jeff Garzik
2007-09-26 2:12 ` Jeff Garzik
2007-09-26 8:41 ` Tejun Heo
2007-09-28 12:10 ` Tejun Heo
2007-09-28 13:54 ` Jeff Garzik
2007-09-28 14:18 ` Tejun Heo
2007-09-28 14:57 ` Alan Cox
2007-09-28 15:20 ` Jeff Garzik
2007-09-28 15:43 ` Alan Cox
2007-09-28 15:40 ` Jeff Garzik
2007-09-28 20:00 ` Mark Lord
2007-09-29 1:49 ` Jeff Garzik
2007-09-29 3:29 ` Jeff Garzik
2007-09-29 4:58 ` Andrew Morton [this message]
2007-09-29 5:09 ` Jeff Garzik
2007-09-29 16:51 ` Greg Freemyer
2007-09-29 20:56 ` Alan Cox
2007-10-01 12:28 ` Jeff Garzik
2007-09-28 15:22 ` Jeff Garzik
2007-09-28 16:48 ` Tejun Heo
2007-09-28 20:02 ` Mark Lord
2007-09-28 20:25 ` Bartlomiej Zolnierkiewicz
2007-09-28 21:03 ` Alan Cox
2007-09-29 1:43 ` Jeff Garzik
2007-09-29 5:24 ` Tejun Heo
2007-10-01 13:31 ` Jeff Garzik
2007-10-02 0:11 ` Tejun Heo
2007-10-02 14:25 ` Alan Cox
2007-10-02 14:30 ` Jeff Garzik
2007-09-29 12:32 ` Mark Lord
2007-10-01 12:38 ` Jeff Garzik
2007-10-02 0:12 ` Tejun Heo
2007-10-02 12:56 ` Jeff Garzik
2007-10-02 13:06 ` Mark Lord
2007-10-02 13:30 ` Jeff Garzik
2007-10-06 22:02 ` Tejun Heo
2007-10-09 2:09 ` Jeff Garzik
2007-10-09 6:54 ` Tejun Heo
2007-09-28 14:20 ` Mark Lord
2007-09-28 15:36 ` Jeff Garzik
2007-09-28 15:55 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070928215854.da085fa3.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=htejun@gmail.com \
--cc=jeff@garzik.org \
--cc=liml@rtr.ca \
--cc=linux-ide@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).