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 6538D198005 for ; Sun, 10 Mar 2013 21:08:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EC143E07B4; Sun, 10 Mar 2013 21:07:46 +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 C25D0E07A5 for ; Sun, 10 Mar 2013 21:07:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id D1DCA33BF48 for ; Sun, 10 Mar 2013 21:07:44 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5.5 tests=[AWL=-0.994, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.626, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hACR1VbHwEh for ; Sun, 10 Mar 2013 21:07:39 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id BAFF933C878 for ; Sun, 10 Mar 2013 21:07:36 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UEnTF-0004cG-Df for gentoo-dev@gentoo.org; Sun, 10 Mar 2013 22:07:53 +0100 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Mar 2013 22:07:53 +0100 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Mar 2013 22:07:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog Date: Sun, 10 Mar 2013 21:07:14 +0000 (UTC) Message-ID: References: <20130301081602.D1F5D2171D@flycatcher.gentoo.org> <201303022057.29177.vapier@gentoo.org> <201303022144.36781.vapier@gentoo.org> <20130310190418.40e7c3aa@marga.jer-c2.orkz.net> <513CCCE8.9040909@gentoo.org> 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=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 34d5f94 /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: 7ecb66c0-0d18-45ff-8a83-c69f58894def X-Archives-Hash: a89ce4fdaaba99659ad6271f4ad51ed3 hasufell posted on Sun, 10 Mar 2013 19:11:52 +0100 as excerpted: > I was told a while back (I might still have it in irc logs), that 30 > days is NOT a rule. It's common sense, but in the end the maintainer > decides when to request stabilization, no one else. I can confirm the 30-day-guideline policy was just that, a maintainer- discretion guideline, back in 2005/2006 or so when I first became aware of the concept via discussion. It was explained as maintainer knows their packages best, with the caveat that arch-teams also knew their archs best and could choose not to stabilize right away if they decided the request wasn't appropriate for their arch. I've seen no council, etc. decision changing that, over the years. Sometime a bit thereafter, various understaffed archs began to yield stabilizing authority to non-arch-team maintainers on a package-by- package basis, generally with at least the requirement that said maintainer actually had access to and had tested on that arch. AFAIK, before that maintainers weren't to stabilize at all on archs they weren't team members of, but they could still do so if they were a member of the arch-team, provided of course that they were following arch-team policy in the process. Meanwhile, jer's explanation, that on an arch where the package was not previously stable, there could be no stable users of the app to see regressions, so straight to stable makes a bit more sense, makes perfect sense to me. =:^) If I'm arguably too verbose, vapier's arguably not verbose enough. Had he just said something like either of these instead of simply punting with his replies... I guess it would have stopped there. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman