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 9200513832E for ; Thu, 4 Aug 2016 23:25:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3BF45E08E9; Thu, 4 Aug 2016 23:25:55 +0000 (UTC) Received: from mail-qt0-f181.google.com (mail-qt0-f181.google.com [209.85.216.181]) (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 98F6CE08E6 for ; Thu, 4 Aug 2016 23:25:54 +0000 (UTC) Received: by mail-qt0-f181.google.com with SMTP id 52so166714934qtq.3 for ; Thu, 04 Aug 2016 16:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=Su8l/NSnGK7CzQ8ExaySeTr/JZaDDz722Ii8KJmgwsY=; b=fXZtZyzPWiAIL0D18j7T9GbmEAnR0X8VLBze6NTA48zDnKEhpHCOfQNFgijLMpWYvu dkxdORmzy+KvSYDENERusKYOThS+ctNoI/oRLETA1nCo31agWZvWdrmysFOVXW6orGi9 eMXG98a//BlQARiR9bm0rgYdapx2ob8TtVf5hZYRMcduPyx33iL3JmXNzpJAURdPnkdr lJ2M8SR+tBz5YzqmdiTIu2dY9LvFS6+6eK93+LAzf4auKzQF1cBqRjXC/r9ifJIEIqlf 6zBDEFrKpyfMUfGIc07zfSCg+uZkQqYv9f6I82XyJpVkSYX7KI0uJ4icUa/FBRgRineT N25Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=Su8l/NSnGK7CzQ8ExaySeTr/JZaDDz722Ii8KJmgwsY=; b=PY3ejTq+QaBB3OXNvr4OSLeMgsUDyOKRQ5mtYVOnTTNk+jJM9AnQ/iH26oE+TiZh8V ctYtVA3JGfGGFW3b/Vb7Tr0ZHxOIcQVsj/VYZAOF9s9PV/0UsonoyVty8y1AT+Inn+jn rS6fWnbJWokAHPzE0lQ4Dqe5j3Y3LQnXJb2TixmJzPNKZO9g9aXgKemCiRLrwZARaUHj g15yFeestyYSWOXRiwtZL5Vi8xVgolc49rSQgeT+37JwTr5D5v9xkjnzUW7QHjC5loT3 mu70yB5i5YK5PLZcTlgJvely1jXOEYDUANwVXFHPXTU8rZyj4jSX3z2UOpUXdOc9NCQ4 ifWg== X-Gm-Message-State: AEkoouv51v2s8pllTjBnCzdO3rN/1Fd5SQHMYCdqzYxP02VML3A+S1NYmloKl+Vt7U8p4citYDlCFEhyE2k4dg== X-Received: by 10.200.38.131 with SMTP id 3mr9612789qto.123.1470353153289; Thu, 04 Aug 2016 16:25:53 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 Sender: freemanrich@gmail.com Received: by 10.140.40.36 with HTTP; Thu, 4 Aug 2016 16:25:52 -0700 (PDT) In-Reply-To: <20160804222234.GA8357@whubbs1.gaikai.biz> References: <2e11e445-c25b-b7f2-def1-99aed92308b6@gentoo.org> <20160804162443.GA7048@whubbs1.gaikai.biz> <20160804231224.7b7462168f1d23e88fe4135c@gentoo.org> <20160804222234.GA8357@whubbs1.gaikai.biz> From: Rich Freeman Date: Thu, 4 Aug 2016 19:25:52 -0400 X-Google-Sender-Auth: TgmeSJx_3Vi2dwK1cr7Hrm70xnk Message-ID: Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14 To: gentoo-project@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 00da817a-0e0c-49ec-b510-af5eaa6f7a29 X-Archives-Hash: 5dbb415b5559aa93bda8893e5ffb88fa On Thu, Aug 4, 2016 at 6:22 PM, William Hubbs wrote: > On Thu, Aug 04, 2016 at 11:12:24PM +0300, Andrew Savchenko wrote: >> >> Thank you for caring about this issue. I had similar thoughts >> myself, but was too slow on writing e-mail :) IMO stable tree has >> three problems: >> 1) too old packages >> 2) too few packages >> 3) stabilization often takes too long, such stable packages are >> broken or buggy, while their unstable versions are fixed and work >> fine. (It is not possible to fix all bugs without version or >> revision bump, thus stabilization is needed to fix many bugs.) > > "too few packages" doesn't really affect things much, I'm more > concerned about 1 and 3. If packages are not stable in the first place, > that is because the maintainer hasn't requested stabilization, and that > is a separate issue. I'm less concerned with old (within reason) and few. I think the primary criteria has to always be that the packages are reliable. If somebody wants to make the tradeoff less reliability and fresher packages they can just install testing. > > My proposal is saying that if you have a version of a package in ~, > testing is being done, and at the end of the testing period (30 days at > most), that new version in ~ should move to stable if there are no > blockers. It would be up to you, the maintainer, or any users running > the ~ version, to test and file bugs that block stabilization. These > bugs could be detected automatically. > I'm mostly fine with that, but I'd add just a requirement that somebody does a quick sanity check on an otherwise-stable system. The 30 days of testing is really only testing against dependencies that are in ~arch. Granted, that will become less of a concern if all those dependencies are also making their way to stable. I'm not suggesting anything rigorous. However, it would be a bit embarrassing to stabilize a package and find that it doesn't even build, or which has some glaring issue. Build testing at least could be automated, but I'm not sure if we need more than that. I'm not entirely opposed to loosening things up on a trial basis and seeing how it goes. However, if we're going to do that I wouldn't go nuts with automation in case we decide to back off. > > We basically do. I don't have a link in front of me, but the council > did make a decision allowing the removal of packages from the stable > tree. It hasn't played out well though, because stable users expect > that once a package is in the stable tree it will stay there until a > newer version comes to the stable tree. I'd have to look up the exact decision, but it was basically left to maintainer discretion after some time lag. I think it is a useful safety valve. If the maintainer feels that the stable version is de-facto unmaintained and is causing problems, then we're not doing stable users any favors by just leaving it on their systems. Just go ahead and drop it and stable users can stick it in an overlay if they know what they're doing, but they won't just live with some unknown issue. However, this shouldn't be done lightly. This isn't for that package that is 60 days old. And it really should be the last resort when the maintainer can't just stabilize it on their own (it is a bigger issue for minor archs where hardware is less available and arch teams don't have time to touch it). > > 2. if the package is all data files, or if it is written in an > interpreted language e.g. python, perl, etc., Once the testing period > has passed, the maintainer will be allowed to stabilize it on all arches > that have a stable version without a stable request. I believe there is already widespread agreement on this point. We've talked about mechanisms to designate these packages but if we just want to go with maintainer discretion we might be fine. -- Rich