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 A88121391DB for ; Sun, 23 Mar 2014 21:47:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BEC9EE0B91; Sun, 23 Mar 2014 21:47:49 +0000 (UTC) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A4FCDE0ACA for ; Sun, 23 Mar 2014 21:47:48 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id t60so2961871wes.33 for ; Sun, 23 Mar 2014 14:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Z+BfnkXdIjofhT4fKEj12lR7ifqttyvtv6py+dmMxAI=; b=Ko2dCMv7OmyMxN2CyYiPQxvwvGnffX5Wv7nXv2bgVeDdvcYV8r6KgcCPQ076aVZtIf +CwtA5SCmesR/DAT7DBLiIMECN/Ns5wBkLwqg5+/gf+5Hs7KOHKQA4FGRFaN55ajxYbz iCQEiLKbF7+c3FnK5BW65Cp93i0C2vbTu8OEAunxAOEf6u3kbpUmpu+wDX4VYya3ddV1 97M+N176XFAlxJ8BLp4Q782xCT/rFMsKZTIFY7CQaWiJcQHbci1TL/E9o+oQkvpO8Iob bvUdJIMy0UQ5KOLTbX59cND19f2QOFQX4y6KUnXOivY2o3yx6U4hC0TSZ4lYmBMfZx7c AD0A== X-Received: by 10.181.13.15 with SMTP id eu15mr10905139wid.38.1395611267294; Sun, 23 Mar 2014 14:47:47 -0700 (PDT) Received: from [172.20.0.40] (196-210-126-50.dynamic.isadsl.co.za. [196.210.126.50]) by mx.google.com with ESMTPSA id rx9sm22586742wjb.20.2014.03.23.14.47.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 23 Mar 2014 14:47:46 -0700 (PDT) Message-ID: <532F566A.1080903@gmail.com> Date: Sun, 23 Mar 2014 23:47:22 +0200 From: Alan McKinnon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC GLEP 1005: Package Tags References: <20140323204428.58216f16@pomiot.lan> <532F3F31.9020404@gentoo.org> In-Reply-To: <532F3F31.9020404@gentoo.org> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit X-Archives-Salt: 3e4a51f1-da93-4ba9-9d7f-54366af6baa1 X-Archives-Hash: b669432160ffd57efa670464c0c075b1 On 23/03/2014 22:08, hasufell wrote: > Michał Górny: >> Dnia 2014-03-22, o godz. 15:33:27 Alec Warner >> napisał(a): > >>> https://wiki.gentoo.org/wiki/Package_Tags >>> >>> Object or forever hold your peace. > > >> I'd honestly prefer that -- if we should really keep tags in the >> tree -- to do that with a single 'metadata/tags' file or some kind >> of hierarchy there. Keep them outside the package directory -- >> bind packages to tags, rather than tags to packages. Keep all the >> commits in a single place without altering the ebuild work flow. > > > That sounds better. That way it is also easier to get some > consistency. E.g. tags can be discussed... but adding packages to tags > is up to the maintainers. > > The GLEP should maybe cover a basic set of tags. Then projects like > games, science etc could add their sets as well which may be a bit > more specific... instead of random maintainers adding random tags. Regular user/sysadmin chipping in: This topic seems a lot like a solution seeking a problem to solve, or alternatively a dev is looking for an easy way to describe stuff. Not that there's anything wrong with that, but the proposal as written is way too vague to be useful. Tags work best when they describe narrow, clearly defined attributes, and the thing they are applied to can have one, two or more of these attributes or sometimes even none. Music and movie genres are an excellent example - there are only so many of them and for the most part one can tell whether a tag really is a genre or not. Nothing resembling such limits are proposed in this GLEP, there's not even a recommendation of what the tags will describe or how everything will be tagged equally. What happens if someone zealously over-tags all of gnome and the same thing doesn't happen for kde? Does kde just not show up in tag searches anymore? So this just seems like a nice-to-have that hasn't been properly thought through. The main stated use of it is for packages that logically belong to more than one category. So instead of a general catch all, do whatever you want mechanism, let's rather solve that exact problem by for example adding a specific field to metadata eg "supplementary categories". Pick those that apply from a clearly defined list and store the data in a clearly defined place. Such a thing can be made more generic, by making it a clear mechanism to describe extra metadata and the things to be described go through a defined process first before making it into the list. this concept is not present in the GLEP as currently written. -- Alan McKinnon alan.mckinnon@gmail.com