[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1412151211520.16494@nanos>
Date: Mon, 15 Dec 2014 12:15:35 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
cc: Borislav Petkov <bp@...en8.de>,
LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Maintainer abuse
On Sat, 13 Dec 2014, One Thousand Gnomes wrote:
> 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"
If that works with command line tools which nicely integrate into
e-mail, that might be something useful. If it involves browser clicky
interfaces, then at least for me not so much.
> 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 ?
It usually works quite well. Just getting large patchsets sent in the
merge window or just right before it is a pain.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists