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 8754D13877A for ; Fri, 8 Aug 2014 17:29:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E5E31E0990; Fri, 8 Aug 2014 17:29:55 +0000 (UTC) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 16AA4E07FC for ; Fri, 8 Aug 2014 17:29:54 +0000 (UTC) Received: by mail-qg0-f43.google.com with SMTP id a108so6315939qge.2 for ; Fri, 08 Aug 2014 10:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zTUAO4r2T9f+ytOrxzzdExCAwQ2U1IVYDUUu/eJun18=; b=MDY9waQVdXGrLL2pQyiBILFmZvhWem1VugNfMbyMZPoLlEwF+CuicdgHK4CZYqZynX MgUgBrKK3kyG9I52RB5iPtjEs4h1r647vrgrU/S6Tjt8lDi6QdPSxH7ADBYJF5704C61 ttLOwliKtaKXS3nWHbqz4k/IY2erNjaSV7o236fSeWd0P9wj3DHRnt1EIomNvAitVpA0 Bxjh29D9Qnt6882OsrD4VW9tgENRZRA7oZTw+n/zYqRmJvXZ55iblfQM4402evgIuVlW NVRJZ5kTIb7nAuG10U6/TfLABbH38zEjWUdcxRIx4adD323tp/6NEDAYJ7IGCDPHa/pP Mn2A== 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.140.43.70 with SMTP id d64mr20440729qga.74.1407518994255; Fri, 08 Aug 2014 10:29:54 -0700 (PDT) Received: by 10.140.44.34 with HTTP; Fri, 8 Aug 2014 10:29:54 -0700 (PDT) In-Reply-To: <53e501be.845f700a.598f.2ad0@mx.google.com> References: <53e4ccbd.c2b4700a.3bec.2414@mx.google.com> <53e501be.845f700a.598f.2ad0@mx.google.com> Date: Sat, 9 Aug 2014 05:29:54 +1200 Message-ID: Subject: Re: [gentoo-dev] minimalistic emerge From: Kent Fredric To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary=001a113a9e6caad61c0500218de8 X-Archives-Salt: 28bf79c2-da11-4c29-a88e-345493229d7f X-Archives-Hash: 81407839ee5fa69d717b7a1f34808820 --001a113a9e6caad61c0500218de8 Content-Type: text/plain; charset=UTF-8 On 9 August 2014 04:58, Igor wrote: > Maintainers have no feedback from their ebuilds, they all do their best > but there are no tools > to formalize their work. No compass. They have no access to user > space where the packages are installed, unaware how users are using their > ebuilds. It's the design > failure that hunts Gentoo from the start - no global intellectual bug > tracking system. Doing not mistakes > - not possible, the automated tracking sub-systems should be there but... > we are where we are. Some of that is doable, ie: we could have installation metrics systems like CPAN has a testers network with a matrix showing where a given thing is failing : http://matrix.cpantesters.org/?dist=CPAN-Meta-Requirements%202.126 But its a lot of work investment to support. And beyond "it installs" and "its tests pass", its piratically infeasible to track software failing beyond there. And some of the reasons we have dependency declarations are to avoid problems that will ONLY be seen at runtime and WONT be seen during installation or testing. ( Usually because the problem was found before there were tests for it ) For that, only manual feedback systems, such as our present bugzilla, are adequate. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL --001a113a9e6caad61c0500218de8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 9 August 2014 04:58, Igor <lanthruster@gmail.com> wro= te:
Maintain= ers have no feedback from their ebuilds, they all do their best but there a= re no tools=C2=A0
to formalize their work. No compass. They have no access to user=C2=A0
space where the packages are installed, unaware how users are using their e= builds. It's the design=C2=A0
failure that hunts Gentoo from the start - no global intellectual bug track= ing system. Doing not mistakes
- not possible, the automated tracking sub-systems should be there but... w= e are where we are.=C2=A0

Some of that is doable, ie: we could have installation metrics= systems like CPAN has a testers network with a matrix showing where a give= n thing is failing : http://matrix.cpantesters.org/?dist=3DCPAN-Meta-= Requirements%202.126

But its a lot of work investment to su= pport.

And beyond "it installs= " and "its tests pass", its piratically infeasible to track = software failing beyond there.

And some of the reasons we have depend= ency declarations are to avoid problems that will ONLY be seen at runtime a= nd WONT be seen during installation or testing. ( Usually because the probl= em was found before there were tests for it )

For that, only manual feedback systems= , such as our present bugzilla, are adequate.


--
--001a113a9e6caad61c0500218de8--