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 09804138D29 for ; Fri, 14 Feb 2014 19:00:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1A896E0A44; Fri, 14 Feb 2014 19:00:11 +0000 (UTC) Received: from albert.telenet-ops.be (albert.telenet-ops.be [195.130.137.90]) by pigeon.gentoo.org (Postfix) with ESMTP id 0DE0DE09F3 for ; Fri, 14 Feb 2014 19:00:09 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by albert.telenet-ops.be with bizsmtp id SK081n0112khLEN06K08Ys; Fri, 14 Feb 2014 20:00:09 +0100 Date: Fri, 14 Feb 2014 19:59:58 +0100 From: Tom Wijsman To: slong@rathaus.eclipse.co.uk Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Re: Re: dropping redundant stable keywords Message-ID: <20140214195958.5aea85f0@TOMWIJ-GENTOO> In-Reply-To: <20140213212818.GA2199@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> <20140205010833.1bcf8dca@TOMWIJ-GENTOO> <20140213212818.GA2199@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: af121b85-cfc0-4e49-8e9f-8a1085499ea7 X-Archives-Hash: 9e1c04f71becdcdd543636afbd5f777e On Thu, 13 Feb 2014 21:28:18 +0000 "Steven J. Long" wrote: > > > 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... > > Very gnomic: nothing's being hidden in the above approach. Filing a bug but not telling the user about it is hiding the problem. > I can't make sense of the rest so I'll move on, noting only that it's > up to the arch team, as to what _they_ decide to kick back to > unstable. They need manpower to decide it, which they don't have. > And that can work without a problem if we have a mechanism > in place to relieve maintainers of those bugs. Such mechanism could be to assign those bug to the arch team, this idea came up at FOSDEM; it won't solve the lack of manpower, but it will at least relieve the maintainers and make the problem more visible. > Personally I'd do it after 45 days to speed things up, and let the > ATs concerned, take the bug as and when (eg turn the stabilisation > into a tracker for the slow archs concerned, if there are multiple.) Since this is a soft measure I've seen a lot of people want the time to be longer; if it still continues to be a problem, then shortening it might be a solution but I think we'll want to avoid a too hard approach for now. 45 days are over before you know it... The part about ATs taking the bug sounds like what came up at FOSDEM. +1 > > > > > 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. > > Er what? > > > 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? > > Kinda sums up your discussion for me. And your answer to "tell us > what it breaks" is "tell us why it works?" Pfft. We are searching for solutions that 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. > > That's just another word: "exploring the problem domain" is much more > useful to keep in mind. We already know the problem, thus it is rather just called prototyping. > > > Further, the solution steev brought up is much much better than > > > simply dropping the ebuild. > > > "The -* keyword is special. It is used to indicate package versions > > which are not worth trying to test on unlisted archs." [1] > > Finally: some actual content. It works. > > You can keep rehashing about "winning", but all it does is break > > policy. > > *sigh* > The wonderful thing about policy is that it reflects (or is supposed > to) consensus opinion with light to contemporaneous circumstance. > Since circumstances change, so too must policy be open to change or > adaptation, in line with basic principles. In this case -* works fine for what it intends to work; changing the policy to redefine it to fit another purpose, while no longer reflecting its original purpose is what we should avoid at all cost. > So let's look at extending it, since there is *no* technical problem: You have colons after the above quoted sentence with nothing after it. (An eye for an eye... :D) > 'The redundant -* keyword is a metadata marker. The keyword has a meaning, therefore it is not redundant. > It is used to indicate, in line with the semantic of "strip all", > that the ebuild in question can only be used for the specific archs > noted for one of two reasons: > > 1) The package-maintainer has stabilised a newer version on at least > one arch personally, the ATs for the archs listed have taken longer > than XX days to test and stabilise, and the maintainer would > otherwise drop the ebuild altogether. > > 2) The package version is not worth trying to test on unlisted archs.' (1) changes its meaning in a way that you can no longer interpret the keyword solely as (2). The whole purpose of (2) is that you can interpret it that you should not test it as it was found not to work; (1) is different from that, as it means that there was no manpower to test it. (1) would move ebuilds to -* and be misinterpreted as (2). > The policy which flows from that is: > > 'In the first case, it is QA policy that a comment of the form: > # STABLEREQ: https://bugs.gentoo.org/show_bug.cgi?id=NNNNNN > is required on the line immediately above the KEYWORDS declaration. > > This is to aid both automated identification, and human > collaboration.' > > (The latter explains why a URL, not a bug id, is required. We're > trying to get end-users to help us, so let's make it easy for them.) > > I'd personally add: > 'It is envisaged that the line will be added by an automated tool at > some point.' > > ..as well as a requirement for a bug id in the second case, but I > don't know it well enough; I'd certainly want some sort of tracking. This yields extra commits; comments in ebuilds are directed towards maintainers, for users we should use another approach to contact them. > It's hardly an onerous requirement, and a small price to pay: if > we have a policy for how a maintainer drops an ebuild from his > queue due to it being stabilised, which we can trigger scripts > from, we avoid the arguments every year or so, and stop archs from > being borked. We can also speed it up, since we have a mechanism > in-place to support it, as opposed to ad-hoc, flawed decision-making. > > The thing I think that's missing from this debate, is an > acknowledgement, or an understanding, that arch-teams are all > effectively working on their own variant of the shared Gentoo tree. > (This includes the concept of upgrades working as smoothly as they > do on other archs, at the PM level.) Similar to other portability > efforts, the tree must support them in that, not make it harder. > > Especially not because another developer doesn't care about the arch > in question. That's *natural*, but _cannot_ be cause for dropping > stable ebuilds. The only issue is to take the bugs off their hands, > and we can do that with a simple tweak in metadata, so ffs let's > get on and do it. +1 on this thought. -- 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