On Thu, 3 Dec 2009, Bartlomiej Zolnierkiewicz wrote:
On Thursday 03 December 2009 09:39:39 pm Jeff Garzik wrote:
On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote:
On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote:
On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote:
On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote:
On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote:
On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote:
The merge window is upon us, which by strict rules means that anything
not already in libata-dev.git#upstream needs to wait until 2.6.34.
However, bug fixes and the like should definitely be in 2.6.33.
->init_host is definitely 2.6.34 material. Some of the other stuff
could go either way.
If you would like to apply some of my patches to 2.6.33 you are more than
welcome to do it. I can even prepare separate git tree with specific changes
to make it easier for you once you tell me which changes you would like to
see in it.
OK, great.
Can you prepare a patchset containing only fixes? Comment-only changes
are acceptable too. Trivial changes too, if they are extremely trivial :)
Include nothing that adds features, removes or unifies drivers, etc.
Since this is pretty high-level description and some changes fall into
many categories at once (i.e. addition of proper PCI Power Management
handling could be considered both as a fix and as a feature) I prepared
a rather conservative set of changes (which means that unfortunately
it misses many enhancements available in my tree):
Please do it in standard kernel submit form, which is either
(a) repost the patches (yes, again) being submitted for 2.6.33, or
(b) a standard git pull request, which includes shortlog, diffstat, and
all-in-one diff.
Thank you for the detailed explanation of the standard kernel submit
form (I wonder how would I know this otherwise :) but the thing is that
at the current moment I'm not submitting anything to the upstream.
Ok, that explains my confusion, then. I had thought you intended to get
this stuff upstream, and into users' hands.
Interesting argument but the vast majority of users use distribution kernels
which are not upstream and I doubt that any self-respecting distribution would
miss such amount of fixes.
Interesting argument, but applied across 1000+ developers this is
clearly an unscalable development model for distributions. Thus,
Interesting that you have brought distributions' convenience before
non-distribution developers' one.
and you are leaving those of us who use kernel.org out in the cold
(forcing all non-distribution users to go through all the work that Jeff
described)
I'm not sure who you see as benifiting from this approach.
David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
