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 E113413877A for ; Tue, 17 Jun 2014 12:49:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BCB74E0B12; Tue, 17 Jun 2014 12:49:28 +0000 (UTC) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D1B9DE0AF5 for ; Tue, 17 Jun 2014 12:49:27 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id ij19so6460131vcb.9 for ; Tue, 17 Jun 2014 05:49:26 -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:date:message-id:subject :from:to:content-type; bh=XidskzbxC7AKa+jrL4HIspN+y2NxEJJc77/1FT98p50=; b=lCvya1TtAkZdOXvjii4NnhQqs0CvpfFWUU94DjzQ2W73erKKzNWEgYU52bz8uCkTgM MoPrArpC8HJ1Nq6EpMyxql1h3tvjJt6l0J4gj1a1vudE5X8voT7vIi1ooxkk36MKAe/t tsCLDPmpONmx8+6d84zPGO0hb+UZJc90YMVokg+cGyjF5tg9LFepwW5NcEd8Lkaj3xhv p/lCOvsCFqtp7Fmdljtu2NCIfU0vmmr0oVJ728g1fVR26zdHcgssOZjgunfrkz3qhfW6 xUCMGBzROuJByHgdMBhnGz90y7groPVppxq5zDBfvLC4UohHQ9fTCtMcYQvybicxvo15 Rlaw== 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 X-Received: by 10.58.195.172 with SMTP id if12mr21609834vec.12.1403009366791; Tue, 17 Jun 2014 05:49:26 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.30.227 with HTTP; Tue, 17 Jun 2014 05:49:26 -0700 (PDT) In-Reply-To: <53A034F4.2000900@gentoo.org> References: <53208139.2040509@gentoo.org> <1660834.UE1ARX9orZ@vapier> <20140327084108.GA3654@rathaus.eclipse.co.uk> <31757180.gTPZtqku3h@vapier> <20140330095348.GA18419@rathaus.eclipse.co.uk> <539E03A9.3010109@gentoo.org> <539E0563.3080302@gentoo.org> <539EF323.7020208@gentoo.org> <1402944163.8309.2.camel@oswin.hackershack.net> <539F462E.6050905@gentoo.org> <20140616214257.096c93fc@marga.jer-c2.orkz.net> <539F49C2.6090008@gentoo.org> <539F4DFA.7020706@gentoo.org> <539F5288.1000000@gentoo.org> <539F5AB5.7000006@gentoo.org> <539F6B3C.7030807@gentoo.org> <539F8000.5080804@gentoo.org> <539F9E41.9050505@gentoo.org> <539FA536.3010401@gentoo.org> <53A034F4.2000900@gentoo.org> Date: Tue, 17 Jun 2014 08:49:26 -0400 X-Google-Sender-Auth: 0XcU5L9g33iSCSMoNMaW3v8edBU Message-ID: Subject: Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 14d62617-c465-4ec5-85cc-ed8eb43cbe49 X-Archives-Hash: 75582160d16b182ba1e7061f98e1557b On Tue, Jun 17, 2014 at 8:30 AM, hasufell wrote: > No, that's not how opensource works. You don't work on things after > "upstream" said "not interested". That is hardly true though - which is why we have 47 different implementations of everything to debate the merits of. :) Besides, if this were truly an "upstream" issue the Council could hardly do anything about it. The solution to this problem isn't annoying crossdev users in the hope that they will pester the crossdev maintainers. In theory they're the main ones impacted by the bug in the first place. Is there a list/etc for crossdev? I'd think that the users and maintainers of crossdev collectively have the biggest vested interest in addressing these issues. They're also the ones who can vouch for how big of a problem this is. Is this having some kind of adverse impact on anybody outside of the crossdev community? If the crossdev maintainers were pushing hundreds of packages to change to accommodate dubious design on their part I could see this being a distro-wide issue. On the other hand, if this is an issue that only impacts crossdev users and maintainers, then I'd think the simplest solution would be let them sort it out. If somebody in the crossdev community does want to sort it out and the problem is package squatting, then that might be a valid reason to escalate. In that case the cleanest solution is to have a crossdev project, have the interested devs step up, hold a vote for the lead, and then respect the lead's role in resolving the issue. Nobody "owns" a package, but in general we should be careful about stepping in and overriding maintainers, especially if nobody is interested in stepping in to take the reins long-term. Rich