From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Li2gq-00041d-7g for garchives@archives.gentoo.org; Fri, 13 Mar 2009 08:24:24 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 19C5DE01E8; Fri, 13 Mar 2009 08:24:23 +0000 (UTC) Received: from wp165.webpack.hosteurope.de (wp165.webpack.hosteurope.de [80.237.132.172]) by pigeon.gentoo.org (Postfix) with ESMTP id E3F6EE01E8 for ; Fri, 13 Mar 2009 08:24:22 +0000 (UTC) Received: from 79.142.224.149.nat.router2.bolignet.dk ([79.142.224.149] helo=marsupilami.localnet); authenticated by wp165.webpack.hosteurope.de running ExIM using esmtpsa (TLSv1:DES-CBC3-SHA:168) id 1Li2gn-0003qe-Ti; Fri, 13 Mar 2009 09:24:22 +0100 From: Thilo Bangert To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] How to speed up maintenance and other Gentoo work? Date: Fri, 13 Mar 2009 09:24:00 +0100 User-Agent: KMail/1.11.1 (Linux/2.6.28-gentoo-r2; KDE/4.2.1; i686; ; ) References: <1236132096.2522.4.camel@localhost> In-Reply-To: <1236132096.2522.4.camel@localhost> Organization: Gentoo Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903130924.03143.bangert@gentoo.org> X-bounce-key: webpack.hosteurope.de;bangert@gentoo.org;1236932663;5f62900f; X-Archives-Salt: 68a08b66-7846-4b2b-a073-40b9d98cddce X-Archives-Hash: db145eafafc959bb17d3c1c88b6f7593 one thing that could perhaps speed up gentoo is specifying at what point or what steps are required before it is ok to "step on others toes". we have the QAcanfix keyword, for bugs where QA "threatens" to just fix the bug if the maintainer doesn't react timely... but it appears to be the tree could generally move faster, if there was an agreement as to when somebody is allowed to fix another maintainers stuff. if we had a formal process in place, one could always execute on that and fix the issue oneself, instead of having the cheap excuse of "well, hasnt fixed bug xxx yet, so i cant move". this process should ideally be very lean and short - as to not discourage these type of changes. kind regards Thilo