On Sat, 13 Dec 2014 00:43:36 +0100 Borislav Petkov <b...@alien8.de> wrote:
> On Sat, Dec 13, 2014 at 12:24:03AM +0100, Thomas Gleixner wrote: > > - Posting of massive patch sets right during or just before the merge > > window > > > > - Reposting of patchsets before the reviewer/maintainer had a chance > > to reply to ALL of N patches > > Absolutely agreed. > > The rule of sending out patches and collecting feedback for a week at > least is not really being respected, from my experience. Shit gets > blasted out at the highest rate possible. Maybe lkml should have a > git-send-email throttle. Every time anyone has tried to deal with Linux scaling problems by throttling the rate it has failed, from the near forking of it when Linus couldn't cope onwards. Today we are already seeing the same occurring with all the vendor trees, and shared downstream trees with a rapidly growing amount of stuff that simply isn't upstream because upstream can't keep up with actual product timescales any more. Leaving aside the small number of people who are just rude, there are always going to be a lot of people who resend because they assume the email was lost (as email is hopelessly unreliable nowdays), people who don't understand, people whose managers don't understand, and people who genuinely think their patch is important. I'd ask two other questions instead 1. Why are they in your mailbox ? Is it the year for a Google summer of code project or similar to turn patchwork into a proper patch management tool (one that collects the patches, provides a good maintainer interface, tells people automatically that their patches are queued, deletes repeats, gives them status urls they can give to managers or check, and also has the right bits maintainer side to actually do stuff like send out "your patch set no longer merges, please update" emails, and tell the maintainer if it merges, the coding style important bits, etc and with buttons for "merge me" It could then be integrated into git (if only so we can have a "git lost" command to block annoying sources) 2. Is X86 moving at a rate which needs some additional maintainers to "maintain" the pending queue during merge windows and the like, and get stuff into order for the maintainers proper ? Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
