From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 5A61213832E for ; Thu, 18 Aug 2016 07:33:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 27763E09C5; Thu, 18 Aug 2016 07:33:29 +0000 (UTC) Received: from mail-ua0-f180.google.com (mail-ua0-f180.google.com [209.85.217.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5ED07E09C5 for ; Thu, 18 Aug 2016 07:33:27 +0000 (UTC) Received: by mail-ua0-f180.google.com with SMTP id k90so16226529uak.1 for ; Thu, 18 Aug 2016 00:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EA/2Sknfs2mgoPzrjPHONV7k2VmUrLCeXcCOq/h5l5w=; b=JPxtxKyNaDMTYi8tyZbvRzTnYvTNnt3UdZ14yCug5CWlc+P7i/wqvAe6//of/WAVTh F9pDs4KaGnal09Zg653+NnPEP4wzRLZtz0N9xp7Nj5eTRceiZsF5Qb/xtpsveeuqgEge wVtLdsKqyH5ExqjeGnzMHMFQDWNNuGOq+nEOff/PKjrvW+qN/cd8SBMBFeJJJDzm3CEg /NclQbV0NqGKFD8j33HES6nmnhkGcp3j5EUt2ira9qvX78dhJIK1K/6WmJoBFbMwd5sp RCHHyBjCmuGBUqiArmgfKyFI3Y87dYqor9IBjE7eUZT9zRtTzlyKokJLOJRvPLK6XD9r x9Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EA/2Sknfs2mgoPzrjPHONV7k2VmUrLCeXcCOq/h5l5w=; b=TA374E56L9VMDEtcorgnDL5/i73tZQiE9zrMqPfQ8vbzvTshSUHqewRgjm9tCnCF5P NvEN3mpjIU2SObWL43hFPWEG3uWVT2f5Csj1GA+BaORSO9NJ8rCE0v83/nlNk4PWoYZT CsWaFYPijqGauOn+3VtYvcXKh+Yy0kRyoZgco/kW6aXVXo20sGaUQ7uGL0hwXtDg+bWO 4CUKeFAQuadxZBQAz+0QaXhPinuxl54shVNGwXuJKP3qRP2j9ceNNRxZUYD6Bd9IBbsw +thTiyzz5S6S03ajkySocnQVeE3SnZV91PtBkNt0ixwu8ShMScfM5l3NNMNZ7OmnjF2q lYZQ== X-Gm-Message-State: AEkoouvBvAvsqYbBjhpQpr6W8UVBLkbyZGJtQ0SVQL4bwVPfIa5MPRhYb5obIflqbiWQPccqWTXJRDi9rzzqpw== X-Received: by 10.159.40.74 with SMTP id c68mr391986uac.48.1471505606283; Thu, 18 Aug 2016 00:33:26 -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.31.178.71 with HTTP; Thu, 18 Aug 2016 00:32:41 -0700 (PDT) In-Reply-To: <1471423826.31785.52.camel@gentoo.org> References: <6046d13b-1a54-aa5e-ab16-df448b0f8c59@gentoo.org> <1471248012.31785.32.camel@gentoo.org> <20160815141922.GA3878@linux1.gaikai.biz> <1bff7eb3-cc91-bba7-1f7f-9e7f76906df3@gentoo.org> <20160815161241.GA21389@whubbs1.gaikai.biz> <20160815173130.GA21750@whubbs1.gaikai.biz> <20160815191248.GA21981@whubbs1.gaikai.biz> <1471423826.31785.52.camel@gentoo.org> From: Raymond Jennings Date: Thu, 18 Aug 2016 00:32:41 -0700 Message-ID: Subject: Re: [gentoo-dev] New Working Group established to evaluate the stable tree To: gentoo-dev Cc: Richard Freeman Content-Type: multipart/alternative; boundary=94eb2c04486af29aa3053a5398a4 X-Archives-Salt: 0ae58cdc-1488-4a2c-beaa-792a9aa41e93 X-Archives-Hash: 77fc260bfd79c52c9f576bcf94050409 --94eb2c04486af29aa3053a5398a4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Strict compliance with the handbook would seem to forbid having a stable package depend on an unstable package, and if you have to downgrade a dependency and it causes a cascade, I would opine, that, perhaps, the package in question should not have been stabilized to begin with. That said, I as a user have noticed that packages tend to stall in stabilization for awhile. What about a script that can rank ~arch keyworded packages by some sort of priority? Maybe point out which one has the most reverse dependencies? Or which one has been stuck in ~arch the longest? Or some sort of scoring mechanism that can flag the most urgently needed stabilizations? Come to think of it, I think debian has a system that flags the most popular packages. Does gentoo have a way to note what packages are most important? On Wed, Aug 17, 2016 at 1:50 AM, Pacho Ramos wrote: > El lun, 15-08-2016 a las 15:27 -0400, Rich Freeman escribi=C3=B3: > > [...] > > Well, I wasn't suggesting that breaking the depgraph is great. Just > > that I think it is better than calling things stable which aren't. > > > > A better approach is a script that does the keyword cleanup. > > > > So, if you want to reap an ebuild you run "destabilize > > foo-1.2.ebuild". It searches the tree for all reverse deps and > > removes stable keywords from those. Then you commit all of that in > > one commit. > > > > If you want to be extra nice you stick it in a pull request in github > > and point it out to the arch team and ask them if they're sure they > > don't want to stabilize your package... :) > > > > Well, the reason I was suggesting to allow maintainers to stabilize > after the 90 days timeout over *current* policy of allowing the > dekeywording is that the dekeywording is completely unrealistic to do > as some packages have a huge amount of reverse deps. Even with the > script (and, well, I would like to see that script existing... because > we are having this issue for ages, and that is the reason that nobody > is moving things to testing actively), you will find many many cases of > packages having so many reverse dependencies that if you try to move it > to testing it becomes soon a hell. > > The main issue is that, once you start dekeywording one package, you > jump to, for example, dekeywording another 3 reverse deps, then you > need to continue with the reverse deps of that reverse deps... and at > the end, it's completely impossible to manage it (I still remember how > hard was to move to testing most of Gnome... and we even were lucky as > we were able to do that with the jump to Gnome3). > > Then, my point it to allow the maintainer to keep stabilizing it > *after* the 90 days timeout. If after that time, the arch team is > unable to even reply, nobody has reported any build/runtime issues > related with that arch, I would go ahead. Otherwise, it looks pretty > evident to me that that arch is near to be used by nobody and maybe it > should be moved completely to testing (or most of their packages moved > to testing and only the core apps in stable). > > > > --94eb2c04486af29aa3053a5398a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Strict compliance with the handbook would seem to forbid h= aving a stable package depend on an unstable package, and if you have to do= wngrade a dependency and it causes a cascade, I would opine, that, perhaps,= the package in question should not have been stabilized to begin with.
That said, I as a user have noticed that packages tend to s= tall in stabilization for awhile.

What about a scr= ipt that can rank ~arch keyworded packages by some sort of priority?
<= div>
Maybe point out which one has the most reverse dependenc= ies?=C2=A0 Or which one has been stuck in ~arch the longest?=C2=A0 Or some = sort of scoring mechanism that can flag the most urgently needed stabilizat= ions?

Come to think of it, I think debian has a sy= stem that flags the most popular packages.=C2=A0 Does gentoo have a way to = note what packages are most important?

On Wed, Aug 17, 2016 at 1:50 AM, Pacho Ram= os <pacho@gentoo.org> wrote:
> Well, I wasn't suggesting that breaking the depgr= aph is great.=C2=A0=C2=A0Just
> that I think it is better than calling things stable which aren't.=
>
> A better approach is a script that does the keyword cleanup.
>
> So, if you want to reap an ebuild you run "destabilize
> foo-1.2.ebuild".=C2=A0=C2=A0It searches the tree for all reverse = deps and
> removes stable keywords from those.=C2=A0=C2=A0Then you commit all of = that in
> one commit.
>
> If you want to be extra nice you stick it in a pull request in github<= br> > and point it out to the arch team and ask them if they're sure the= y
> don't want to stabilize your package...=C2=A0=C2=A0:)
>

Well, the reason I was suggesting to allow maintainers to stabilize<= br> after the 90 days timeout over *current* policy of allowing the
dekeywording is that the dekeywording is completely unrealistic to do
as some packages have a huge amount of reverse deps. Even with the
script (and, well, I would like to see that script existing... because
we are having this issue for ages, and that is the reason that nobody
is moving things to testing actively), you will find many many cases of
packages having so many reverse dependencies that if you try to move it
to testing it becomes soon a hell.=C2=A0

The main issue is that, once you start dekeywording one package, you
jump to, for example, dekeywording another 3 reverse deps, then you
need to continue with the reverse deps of that reverse deps... and at
the end, it's completely impossible to manage it (I still remember how<= br> hard was to move to testing most of Gnome... and we even were lucky as
we were able to do that with the jump to Gnome3).

Then, my point it to allow the maintainer to keep stabilizing it
*after* the 90 days timeout. If after that time, the arch team is
unable to even reply, nobody has reported any build/runtime issues
related with that arch, I would go ahead. Otherwise, it looks pretty
evident to me that that arch is near to be used by nobody and maybe it
should be moved completely to testing (or most of their packages moved
to testing and only the core apps in stable).




--94eb2c04486af29aa3053a5398a4--