From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 858891381F3 for ; Fri, 21 Jun 2013 19:04:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BB8F1E0B21; Fri, 21 Jun 2013 19:04:21 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CB768E0B17 for ; Fri, 21 Jun 2013 19:04:20 +0000 (UTC) Received: from localhost (unknown [146.83.2.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id EE5AA33E6A0 for ; Fri, 21 Jun 2013 19:04:18 +0000 (UTC) Date: Fri, 21 Jun 2013 15:04:11 -0400 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP Message-ID: <20130621150411.6e951202@gentoo.org> In-Reply-To: References: Organization: Gentoo X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; x86_64-pc-linux-gnu) 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=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 4ccf2091-16bd-48ff-adbd-72a31b36c440 X-Archives-Hash: bfdf2bb37c73bce7a05562fe80df6bc4 Hi, > I'm open to all input, but here's some initial questions I'd like to > hear your answers to: > - How should developers, herds & teams communicate how welcome they > are to NMU changes on their packages? The way I've been doing this is: - packages I maintain through herd -> go ahead and be responsible. - if I add myself explicitly in metadata.xml this means I prefer at least reviewing every change that gets in (with some exceptions for trivial changes, like e.g. qt moving category) [...] > - How do we encourage responsible ownership of changes that cause > breakage? [1] That's something I'd like to get enlightened on. The, probably too emotional, algorithm that doesn't scale I've been applying has been: 1. ask the committer to fix the problem 2. wait 3. if no fix comes in a timely manner, fix it myself, be clear that I've not liked it at all. Be a bit less polite in future steps 1. with said developer. Alexis.