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 8DF011380DC for ; Wed, 5 Feb 2014 00:10:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3E483E0A84; Wed, 5 Feb 2014 00:10:08 +0000 (UTC) Received: from baptiste.telenet-ops.be (baptiste.telenet-ops.be [195.130.132.51]) by pigeon.gentoo.org (Postfix) with ESMTP id 27058E0A80 for ; Wed, 5 Feb 2014 00:10:06 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by baptiste.telenet-ops.be with bizsmtp id NQA51n00L2khLEN01QA6et; Wed, 05 Feb 2014 01:10:06 +0100 Date: Wed, 5 Feb 2014 01:08:33 +0100 From: Tom Wijsman To: slong@rathaus.eclipse.co.uk Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Re: dropping redundant stable keywords Message-ID: <20140205010833.1bcf8dca@TOMWIJ-GENTOO> In-Reply-To: <20140204210319.GA1935@rathaus.eclipse.co.uk> References: <52E7DBC1.5020102@gentoo.org> <20140128182304.7d458a17@marga.jer-c2.orkz.net> <20140203062524.GA7467@rathaus.eclipse.co.uk> <20140203104341.2add2760@TOMWIJ-GENTOO> <20140204210319.GA1935@rathaus.eclipse.co.uk> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.22; 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: d1429c5a-583c-4b6a-a3a5-6a7a5b0f962d X-Archives-Hash: 4dca039d173fef72a4e1917c3fa6317a On Tue, 4 Feb 2014 21:03:20 +0000 "Steven J. Long" wrote: > Tom Wijsman wrote: > > > They are less work; since it lets the slower arches move their work > > to bugs of important packages that need their attention, instead of > > bugs of non-important packages were the stabilization isn't really > > necessary. > > Huh? The slower arch is not keeping up with stabilisation. How can the > stabilisation suddenly be unnecessary? If it is not needed, there is > no problem, and we wouldn't be having this discussion. It is still necessary, as clear from the difference in importance. > Much better for the arch in question to field the bug, than tell the > user there is no problem, and we don't care. That way you can get the > user involved in stabilisation and AT via that bug, instead of turning > them away with priggishness. Problems should be visible instead of hidden, as well as resolved. A move in work means a move in work, further implications are yours... > > > The arguments and headaches at the user, bug > > > and AT sides are causing more work (or detracting from real work) > > > too. > > > > Yes, the less work that we can do, the more work the user has to do > > as a natural consequence; discussions like these are there to > > prevent those headaches way in advance, as we can proper adapt > > and/or respond to the situation. And if needed, bring out news such > > that the user is well informed. Not sure which argumentation this > > is about though. > > Perfectly simple: instead of having this row repeatedly, or borking > archs, let's use the solution proposed by the ARM AT: provide a > technical reason why it won't work, rather than a conceptual problem > with the "hack". Searching for such technical reasoning is a leeway for hacking & hoping. Solutions were provided, a policy has been made; we are exactly avoiding to row repeatedly, and this is yet another solution I propose: Provide a technical reason why it will work? You further demonstrate this solution that I propose we should use: > The history of computing is littered with hacks that turned out to > shed new light on a problem: it's called exploring the problem > domain. It's only when you have idiomatic knowledge of the > language/tools *and* the specific domain, that you can envision > oddball solutions and more importantly _know_ that they will work > (perhaps with a bit of tweaking.) It is called prototyping. > > > [1] Quality Assurance / Policies / Dropping Stable KEYWORDs > > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Dropping_Stable_KEYWORDs > > That's not a policy: it's a two-line statement of intent. It is policy, as it permits implementation of that intent; at the very least, it is a policy change that allows you something you were disallowed. > Further, the solution steev brought up is much much better than > simply dropping the ebuild. > > > > Just keep the old ebuilds as useful metadata, subject to the usual > > > version-control cycle, but iff it's causing you problems and you > > > want to drop it, mark it with: "-* slowe rarch" so we can script > > > off it and automate bug-handling etc. so your life is easier, as > > > well as the archs in question (and their users.) > > > > As stated before, -* means something way different; it is a > > suggestion that does not fit this thread. Like before, did you mean > > "slower arch"? > > No, it's an example, like foo bar, but indicating that we're talking > about slower archs, and likely more than one in some instances. As > before did you mean to raise a technical objection with clear > explanation of what and why it would break? > > > And even if you did, we have then already been using this practice > > for a long while; it is different from the problem that was brought > > up here. > > Yes, yes, you can keep going on about the "conceptual difficulty", but > the simple fact is the solution works, or it wouldn't have been > raised. steev's idiomatic knowledge and solution wins, IMNSHO. "The -* keyword is special. It is used to indicate package versions which are not worth trying to test on unlisted archs." [1] You can keep rehashing about "winning", but all it does is break policy. [1]: http://devmanual.gentoo.org/keywording -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D