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 1R686u-0002L6-JU for garchives@archives.gentoo.org; Tue, 20 Sep 2011 21:44:12 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5FE8021C12D; Tue, 20 Sep 2011 21:44:03 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id CF5E921C059 for ; Tue, 20 Sep 2011 21:43:37 +0000 (UTC) Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: scarabeus) by smtp.gentoo.org (Postfix) with ESMTPSA id 17E491B4019 for ; Tue, 20 Sep 2011 21:43:36 +0000 (UTC) Received: by bkbzt12 with SMTP id zt12so1155806bkb.40 for ; Tue, 20 Sep 2011 14:43:34 -0700 (PDT) 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 Received: by 10.204.151.17 with SMTP id a17mr962928bkw.366.1316555013960; Tue, 20 Sep 2011 14:43:33 -0700 (PDT) Received: by 10.204.188.66 with HTTP; Tue, 20 Sep 2011 14:43:33 -0700 (PDT) In-Reply-To: <1316554425.16937.4.camel@localhost> References: <1316554425.16937.4.camel@localhost> Date: Tue, 20 Sep 2011 23:43:33 +0200 Message-ID: Subject: Re: [gentoo-dev] [RFC] How do we handle stabilisations of not-exactly-maintained packages From: =?UTF-8?B?VG9tw6HFoSBDaHbDoXRhbA==?= To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 9cfe1122b793ff42b916f251ebfafd3c 2011/9/20 Tony "Chainsaw" Vroon : > On Tue, 2011-09-20 at 23:18 +0200, Tom=C3=A1=C5=A1 Chv=C3=A1tal wrote: >> Well it would be something like priority based queue with maximum 60 >> points value. >> Each update after the month in main tree would get 0 points for >> stabilisation, any-developer / maintainer would be able to add up to >> 40 points to any package and security team members would be able to >> add all 60 points. Security team/any developer would also have >> possibility to add new packages to queue manualy. > > This sounds to me like you are trying to automate common sense. If you > see packages that have good ~arch ebuilds that appear to be fermenting, > please file a bug. Rumours of unresponsive arch teams have been greatly > exaggerated! > > The worst that could happen is that a more exotic arch sees your bug and > decides "sorry, we would rather unkeyword it" rather than "okay, we will > stable that". Either way seems a valid outcome though? > > I can't speak for other arches than AMD64, but we are happy to receive > more than the current influx of bugs, particularly if you are willing to > take suggestions to heart (a lot of QA niggles get shaken out in AT > reports lately). > > Regards, > Tony V. > I am not saying that Archs are unresponsive (well they are on ppc for example sometimes) but I try to solve other problem about finding what packages CAN go stable and nobody ever bothered to do a bugreport. Yeah we can do it by hand like robot and open bugs for zilions of packages just to get all the spell packages stable etc etc, but look on the euscan, it is quite usefull to have automatically generated report of what can you bump and what did you miss to update. Instead of waiting on maintainer/anyone to notice that you can stable something this would give you nice report itself. And usually when i update and qa clean some package in 30 days I don't even really remember which one it was :) Tom