Re: [GIT PATCH] final SCSI pieces for the merge window
On Wednesday 24 October 2007 15:27, Matthew Wilcox wrote: On Wed, Oct 24, 2007 at 09:28:10AM -0400, James Bottomley wrote: OK, so it's no secret that I'm the last of the subsystem maintainers whose day job isn't working on the linux kernel. If you want a full time person, who did you have in mind? I'm willing to take on the role of scsi git-monkey. Alternatively, we could split the scsi maintainer role the same way that Dave and Jeff do for net where Dave handles the core and Jeff handles the drivers. Or we can negotiate some other arrangement. That would be great. Maybe my aic7xxx debloating patches which were submitted four times already (IIRC) will be looked at at last. -- vda - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] final SCSI pieces for the merge window
On Wed, Oct 24, 2007 at 09:28:10AM -0400, James Bottomley wrote: OK, so it's no secret that I'm the last of the subsystem maintainers whose day job isn't working on the linux kernel. If you want a full time person, who did you have in mind? I'm willing to take on the role of scsi git-monkey. Alternatively, we could split the scsi maintainer role the same way that Dave and Jeff do for net where Dave handles the core and Jeff handles the drivers. Or we can negotiate some other arrangement. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] final SCSI pieces for the merge window
James Bottomley wrote: On Tue, 2007-10-23 at 18:06 -0400, Jeff Garzik wrote: James Bottomley wrote: On Tue, 2007-10-23 at 17:09 -0400, Jeff Garzik wrote: James Bottomley wrote: This should be the final SCSI updates; it's mainly just a few accessor completion updates and two driver merges (sym2 and qla2xxx) we also secured DaveM's agreement to remove fcal/fc4, which explains the high removal line count. The patch is available here: master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git I guess I have the go-ahead to merge the end-CDROM-polling async notification work you've been repeatedly ignoring? I haven't been ignoring it ... it just needs quite a bit of work; the best way to accelerate it seems to be simply to do it (add the supported/trigger event bitmasks and expand the infrastructure). I just haven't had the time within the merge window. James, things cannot get bottlenecked like this. You have had MONTHS to say something like this. The code was ready BEFORE the merge window. The patch in question is an interface to user space. The problem with those is that you can't put them in and refine them because the user visible interface changes when you do that. Post August, this user space interface patch has received (a) silence or (b) this vague general worry about changing user space interfaces. All the while it is working and was revised according to comment at the time. At some point you gotta stop waiting for perfection or that mythical when I get a round tuit and actually DO something. When I see the new patch to end CD-ROM polling grow moldy for two months while rewrites to ancient SCSI drivers go in, I throw up my hands in wonderment. Poor Andrew is constantly resending -mm patches to you -- some stick, some vanish into the ether without comment. For months. I really think you have the knowledge to be SCSI maintainer, but not the time. The pot is calling the kettle black here, since libata was supposed to have moved out of SCSI about three years ago by helping us move the shared elements up to block. As far as I can tell, the only progress we've made in this area is me adding the odd API shift. You're talking about long term directions, I'm talking about actually getting day-to-day work accomplished. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] final SCSI pieces for the merge window
Douglas Gilbert wrote: Jeff Garzik wrote: James Bottomley wrote: On Tue, 2007-10-23 at 17:09 -0400, Jeff Garzik wrote: James Bottomley wrote: This should be the final SCSI updates; it's mainly just a few accessor completion updates and two driver merges (sym2 and qla2xxx) we also secured DaveM's agreement to remove fcal/fc4, which explains the high removal line count. The patch is available here: master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git I guess I have the go-ahead to merge the end-CDROM-polling async notification work you've been repeatedly ignoring? I haven't been ignoring it ... it just needs quite a bit of work; the best way to accelerate it seems to be simply to do it (add the supported/trigger event bitmasks and expand the infrastructure). I just haven't had the time within the merge window. James, things cannot get bottlenecked like this. You have had MONTHS to say something like this. The code was ready BEFORE the merge window. I really think you have the knowledge to be SCSI maintainer, but not the time. Jeff, If only I had a dollar (Canadian unit please) for each day some of my libata patches were queued up to you before you accepted them. Remember MODE SELECT ... You're darned right, I've screwed up in the past. Sat on stuff until I get time to rewrite it and that sort of thing. My colleagues give me lumps for it too :) We talked about this issue at the Kernel Summit -- collectively we need to stop holding on to useful, working stuff for months on end. It serves nobody. We have to rediscover our roots: release early, release often Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] final SCSI pieces for the merge window
On Wed, 24 Oct 2007 09:28:10 -0400 James Bottomley [EMAIL PROTECTED] wrote: OK, so it's no secret that I'm the last of the subsystem maintainers whose day job isn't working on the linux kernel. For the record, lots of subsystem maintainers are privateers. goes through the git trees I am not aware that these guys: Mauro Chehab, Dmitry Torokhov, Sam Ravnborg, Pierre Ossman, Mark Hoffman, Thomas Gleixner, David Airlie, Richard Purdie, Peter Anvin, Kyle McMartin, Francois Romieu, Artem Bityutskiy, Erez Zadok, Josef Sipek, Anton Altaparmakov, Eric Van Hensbergen, Latchesar Ionkov, Wim Van Sebroeck, Antonino Daplas. do it with any compensation. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] final SCSI pieces for the merge window
On Wed, 24 Oct 2007, James Bottomley wrote: OK, so it's no secret that I'm the last of the subsystem maintainers whose day job isn't working on the linux kernel. If you want a full time person, who did you have in mind? Quite frankly, at least for me personally, what I would rather have (in general: this is really not at all SCSI-specific in any way, shape, or form, and not directed at James!) is a less rigid maintainership structure. Let's face it, we are *all* likely to be overworked at different times, and even when not overworked, it's just the fact that people need to take a breather etc. And there is seldom - if ever - a very strong argument for having one person per subsystem. I think git is excellent for trying to spreading the joy of maintainership, but even without something like that, I think it's much better to try to find people you can trust, rather than strict maintainership boundaries. For example, Andrew certainly seems to be very productive as a kernel maintainer, and it has nothing to do with git, and everything to do with trust. So I'd rather have less recriminations about xyz is holding up abc, and have people more open to just trying to help out even across strict borders. And I don't mean that in a two fighting people kind of way where there are two or more people who maintain things _despite_ each other, but more in a Hey we know each other, and we trust each other, and no, we won't guarantee that we always agree, but we can work on things, and if it turns out that one person merged somethign that the other person _really_ doesn't like, we'll revert it and/or work it out some other way. I've personally always been against _strict_ maintainer lines, so I've always taken stuff past the maintainer anyway (and sometimes maintainers have complained, because they feel like they own their subsystem, and I either tell them to stuff it, or say my bad, depending on whether they had a valid _technical_ complaint or not). So rather than getting into a pissing match of ok, who would be the best maintainer, I'd much *much* prefer to take this as another we really don't need or even _want_ to have strict maintainer rules opportunity. Now, the most important part here is the trust part. I need to be able to trust maintainers, but when you have multiple people in the same box, those people need to trust each other even more than usual, because you *are* going to get disagreements. And the only way it can work is if you acknowledge that disagreements will happen, and that any situation is not a my way or the highway kind of thing - the trust also implies a certain give and take. And this really *is* an issue that cuts across subsystem boundaries. Anybody who thinks that SCSI is unique in this kind of issues is sadly mistaken. We've had the exact same thing come up in every single subsystem over time, and at every single level of maintainership (from individual drivers all the way right up to me) over time. So I *really* don't want to throw any stones in a glass house here. Quite the reverse. I'd like to get rid of some of the glass, and replace it with padding. Because you all know we'd all fit better in a padded room than a glass house.. Are there any such people that think there s a sufficient mutual trust with James that you think a blurring of maintainership lines could work out? Or in any other subsystem, for that matter? Hmm? Linus - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] final SCSI pieces for the merge window
On Wed, 24 Oct 2007 08:35:21 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED] wrote: On Wed, 24 Oct 2007, James Bottomley wrote: OK, so it's no secret that I'm the last of the subsystem maintainers whose day job isn't working on the linux kernel. If you want a full time person, who did you have in mind? Quite frankly, at least for me personally, what I would rather have (in general: this is really not at all SCSI-specific in any way, shape, or form, and not directed at James!) is a less rigid maintainership structure. Let's face it, we are *all* likely to be overworked at different times, and even when not overworked, it's just the fact that people need to take a breather etc. And there is seldom - if ever - a very strong argument for having one person per subsystem. Am OK with all of that, but with a rider. It would make my life even more miserable if there was a (say) git-scsi-tweedledee and a git-scsi-tweedledum. We already have too much out-of-scope code turning up in the git trees and having two trees explicitly modifying the same subsystem would hurt. It's also bad from an engineering POV: there's a decent chance that when combined, they just won't work. So Tweedledee and Tweedledum should both commit to the same tree, please. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCH] final SCSI pieces for the merge window
This should be the final SCSI updates; it's mainly just a few accessor completion updates and two driver merges (sym2 and qla2xxx) we also secured DaveM's agreement to remove fcal/fc4, which explains the high removal line count. The patch is available here: master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git The short changelog is: Adrian Bunk (3): gdth: __init fixes aic7xxx_old: fix accidental logic reversal lpfc: lpfc_debugfs.c: fix typo Alan Cox (1): initio: Fix merge fallout Andrew Morton (1): qla2xxx: printk fixes Andrew Vasquez (8): qla2xxx: Update version number to 8.02.00-k5. qla2xxx: Correct display of ISP serial-number. qla2xxx: Correct residual-count handling discrepancies during UNDERRUN han qla2xxx: Make driver (mostly) legacy I/O port free. qla2xxx: Fix issue where final flash-segment updates were falling into the qla2xxx: Handle unaligned sector writes during NVRAM/VPD updates. qla2xxx: Defer explicit interrupt-polling processing to init-time scenario qla2xxx: Resync with latest HBA SSID specification -- 2.2u. Hannes Reinecke (3): aic7xxx: Fix firmware build aic7xxx: Update Maintainer information aic7xxx: Add suspend/resume support HighPoint Linux Team (1): hptiop: avoid buffer overflow when returning sense data James Bottomley (2): make supported_mode default to initiator. include linux/scatterlist.h in scsi_eh.h Johannes Dickgreber (2): qla1280: eliminate wasted space in request and response ring qla1280: uses wrong failure path after failed pci_set_dma_mask Kai Makisara (1): sym53c8xx: Work around 53c896 erratum Linas Vepstas (1): sym53c8xx: PCI Error Recovery support Matthew Wilcox (16): sym53c8xx: Remove sym_xpt_async_sent_bdr sym53c8xx: Remove pci_dev pointer from sym_shcb sym53c8xx: Make interrupt handler capable of returning IRQ_NONE sym53c8xx: Get rid of IRQ_FMT and IRQ_PRM sym53c8xx: Use scmd_printk where appropriate sym53c8xx: Simplify DAC DMA handling sym53c8xx: Remove tag_ctrl module parameter sym53c8xx: Remove io_ws, mmio_ws and ram_ws elements sym53c8xx: Remove -device_id sym53c8xx: Use pdev-revision sym53c8xx: Stop overriding scsi_done sym53c8xx: Don't disable interrupts in the interrupt handler sym53c8xx: Remove unnecessary check in queuecommand sym53c8xx: Remove data_mapping and data_mapped sym53c8xx: Use pci_dev irq number fc4: remove this and all associated drivers and the diffstat: b/Documentation/scsi/sym53c8xx_2.txt | 21 b/MAINTAINERS |6 b/arch/sparc64/Kconfig|2 b/drivers/Makefile|1 b/drivers/scsi/Makefile |2 b/drivers/scsi/aic7xxx/aic7770.c | 16 b/drivers/scsi/aic7xxx/aic79xx.h | 11 b/drivers/scsi/aic7xxx/aic79xx_core.c |7 b/drivers/scsi/aic7xxx/aic79xx_osm.c |4 b/drivers/scsi/aic7xxx/aic79xx_osm_pci.c | 50 b/drivers/scsi/aic7xxx/aic79xx_pci.c | 27 b/drivers/scsi/aic7xxx/aic7xxx.h | 11 b/drivers/scsi/aic7xxx/aic7xxx_osm.c |4 b/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c | 46 b/drivers/scsi/aic7xxx/aic7xxx_pci.c | 16 b/drivers/scsi/aic7xxx/aicasm/aicasm_macro_scan.l |3 b/drivers/scsi/aic7xxx_old.c |2 b/drivers/scsi/gdth.c |6 b/drivers/scsi/hosts.c|6 b/drivers/scsi/hptiop.c |5 b/drivers/scsi/initio.c |6 b/drivers/scsi/lpfc/lpfc_debugfs.c|2 b/drivers/scsi/qla1280.c |4 b/drivers/scsi/qla1280.h |4 b/drivers/scsi/qla2xxx/qla_attr.c |9 b/drivers/scsi/qla2xxx/qla_def.h |1 b/drivers/scsi/qla2xxx/qla_devtbl.h |7 b/drivers/scsi/qla2xxx/qla_iocb.c |2 b/drivers/scsi/qla2xxx/qla_isr.c |8 b/drivers/scsi/qla2xxx/qla_mbx.c |2 b/drivers/scsi/qla2xxx/qla_os.c | 50 b/drivers/scsi/qla2xxx/qla_sup.c | 30 b/drivers/scsi/qla2xxx/qla_version.h |2 b/drivers/scsi/scsi_error.c |1 b/drivers/scsi/scsi_sysfs.c | 10 b/drivers/scsi/sym53c8xx_2/sym53c8xx.h|1 b/drivers/scsi/sym53c8xx_2/sym_fw.c | 18 b/drivers/scsi/sym53c8xx_2/sym_fw.h |2 b/drivers/scsi/sym53c8xx_2/sym_glue.c | 581 +-- b/drivers/scsi/sym53c8xx_2/sym_glue.h | 16
Re: [GIT PATCH] final SCSI pieces for the merge window
James Bottomley wrote: This should be the final SCSI updates; it's mainly just a few accessor completion updates and two driver merges (sym2 and qla2xxx) we also secured DaveM's agreement to remove fcal/fc4, which explains the high removal line count. The patch is available here: master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git I guess I have the go-ahead to merge the end-CDROM-polling async notification work you've been repeatedly ignoring? Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] final SCSI pieces for the merge window
James Bottomley wrote: On Tue, 2007-10-23 at 17:09 -0400, Jeff Garzik wrote: James Bottomley wrote: This should be the final SCSI updates; it's mainly just a few accessor completion updates and two driver merges (sym2 and qla2xxx) we also secured DaveM's agreement to remove fcal/fc4, which explains the high removal line count. The patch is available here: master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git I guess I have the go-ahead to merge the end-CDROM-polling async notification work you've been repeatedly ignoring? I haven't been ignoring it ... it just needs quite a bit of work; the best way to accelerate it seems to be simply to do it (add the supported/trigger event bitmasks and expand the infrastructure). I just haven't had the time within the merge window. James, things cannot get bottlenecked like this. You have had MONTHS to say something like this. The code was ready BEFORE the merge window. I really think you have the knowledge to be SCSI maintainer, but not the time. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] final SCSI pieces for the merge window
From: Jeff Garzik [EMAIL PROTECTED] Date: Tue, 23 Oct 2007 18:06:51 -0400 James Bottomley wrote: On Tue, 2007-10-23 at 17:09 -0400, Jeff Garzik wrote: James Bottomley wrote: This should be the final SCSI updates; it's mainly just a few accessor completion updates and two driver merges (sym2 and qla2xxx) we also secured DaveM's agreement to remove fcal/fc4, which explains the high removal line count. The patch is available here: master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git I guess I have the go-ahead to merge the end-CDROM-polling async notification work you've been repeatedly ignoring? I haven't been ignoring it ... it just needs quite a bit of work; the best way to accelerate it seems to be simply to do it (add the supported/trigger event bitmasks and expand the infrastructure). I just haven't had the time within the merge window. James, things cannot get bottlenecked like this. You have had MONTHS to say something like this. The code was ready BEFORE the merge window. I really think you have the knowledge to be SCSI maintainer, but not the time. Unfortunately, I think this is an important point. Developers depend strongly upon a subsystem maintainer to make time for these things so that work integration does not get delayed past the merge window if at all possible. Not being able to make time to do these things is a great way to lose contributers. James, whilst there is no doubt in my mind that skill-wise you are probably the most capable scsi maintainer, your lack of time is sounding like a broken record and harming the development process. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
