X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by lists.alpinelinux.org (Postfix) with ESMTP id C9BCC5C420C for ; Wed, 17 Aug 2016 10:47:45 +0000 (GMT) Received: by mail-wm0-f44.google.com with SMTP id o80so224077006wme.1 for ; Wed, 17 Aug 2016 03:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=OCw1QlcDeN8Gsl3R/A/I8V2pCN2EX1t+quaj414XMXE=; b=q/k0w+uUDFsJnlwjh9YpZepAF9lIjgKEmcOnE2+Yl/oBebTTgyLigene0rGPQ6n/Qh R+RkDDNlfl6t30F62qPkPSfBTk6kiQzYEygVkx4I1Tv0K4RUnWKPQesy1Lg3mcw4g0Ip 60UIzuDwmG0h0Bi5oGhLbRQhmN9Uw0ceqQBTkfP4U3IB6Akbsw67m+O7suMfC3BMkvgR WZHLeAJunlh6/eEJLPHL+27iVliZS0A2jZiux5Otd6Oc/CnL3fYbelEvv7dtUGmjbs4S 6TzZQgGIta4ZxwrMDP+hGX9DYWFGv59GPiiY+GlTrqbJJP1y5XinlR0TPSsBulFtVS33 MSLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OCw1QlcDeN8Gsl3R/A/I8V2pCN2EX1t+quaj414XMXE=; b=mE0uT7hR/mKjoI65Erh3+3bZJSPQGgOtb66S3mBQ9rNpJ2ot9VSK4dH5FX6GKDpQhj Hg6EgHgGoqOBeHiRjOyyAuLFajObZUAvI8eThlOi9nDVXkg0/9BEZ5sb98nI5CupGHyU p3eHq5H1ChUKH+E5kYpKfmjHSqRso4ToDN8CLM0Dov67WU9BilTVQZvJ1XBQb7IqUALi NWAcUpXMC8jrvJHi3dzHi114wVFkhmb5jM+3JtyVFt16sDDI3Xzi6fUprrK9Nm/za3vd 13iKmr53SUQ2fUbzeTK68/MRu51gK5sowZcaWxnNhBVg3u+OEW8zhDaZBl4z6RXIWMV6 Q5gg== X-Gm-Message-State: AEkoouvVILLq/3A0abHRNaLtaWf3356oKV40UCnyjSlVSAPtnOGdx3YEgic1nLCxvkJmeLkPbq1G4kTXGiZWHA== X-Received: by 10.194.122.170 with SMTP id lt10mr10105749wjb.195.1471430864557; Wed, 17 Aug 2016 03:47:44 -0700 (PDT) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Received: by 10.28.163.197 with HTTP; Wed, 17 Aug 2016 03:47:43 -0700 (PDT) From: Carlo Landmeter Date: Wed, 17 Aug 2016 12:47:43 +0200 Message-ID: Subject: [alpine-devel] Cleanup of testing repository To: Alpine-devel Content-Type: multipart/alternative; boundary=089e011767effe5b44053a42314a --089e011767effe5b44053a42314a Content-Type: text/plain; charset=UTF-8 Hi, I have been rebuilding world for our new aarch64 architecture. While main and community repositories are in good shape, testing really is not. We currently have 1832 aports in testing of which 437 fail to build: http://tpaste.us/GVV8 I would like to purge packages from testing that have not had any update since x days, this will reduce the list of failed packages, and will make it easier to get testing in building shape again. As an example you can find a list of not updated packages since 1 jan 2016 here: http://tpaste.us/36aa We should determine what the best possible TTL is for packages in testing. It should be long enough so developers get a chance to get their packages fixed upstream and short enough to prevent the mess we currently have. My suggestion would be something between 6 and 12 months, but i'm open to ideas. And please remember testing is not a copy of AUR, our developers should no be responsible for other peoples mess in testing. To keep testing healthy we can purge them every time we create a new release branch, this is also a good time for developers to check testing and get things moved to community if they want to keep it. -carlo --089e011767effe5b44053a42314a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have been rebuilding world for ou= r new aarch64 architecture. While main and community repositories are in go= od shape, testing really is not.
We currently have 1832=C2=A0apor= ts in testing of which 437 fail to build: http://tpaste.us/GVV8

I would like to purge p= ackages from testing that have not had any update since x days, this will r= educe the list of failed packages, and will make it easier to get testing i= n building shape again.
As an example you can find a list of not = updated packages since 1 jan 2016 here:=C2=A0http://tpaste.us/36aa

We should determine = what the best possible TTL is for packages in testing. It should be long en= ough so developers get a chance to get their packages fixed upstream and sh= ort enough to prevent the mess we currently have.
My suggestion w= ould be something between 6 and 12 months, but i'm open to ideas. And p= lease remember testing is not a copy of AUR, our developers should no be re= sponsible for other peoples mess in testing.=C2=A0

To keep testing healthy we can purge them every time we create a new relea= se branch, this is also a good time for developers to check testing and get= things moved to community if they want to keep it.

-carlo
--089e011767effe5b44053a42314a-- --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---