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 1A00B1381FA for ; Mon, 5 May 2014 17:19:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 90C15E0AE0; Mon, 5 May 2014 17:19:32 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 12DDEE0AE0 for ; Mon, 5 May 2014 17:19:32 +0000 (UTC) Received: from [192.168.1.2] (0545b819.skybroadband.com [5.69.184.25]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: hwoarang) by smtp.gentoo.org (Postfix) with ESMTPSA id 6382034006F; Mon, 5 May 2014 17:19:30 +0000 (UTC) Message-ID: <5367C7C2.1070608@gentoo.org> Date: Mon, 05 May 2014 18:17:54 +0100 From: Markos Chandras User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-mips@lists.gentoo.org Reply-to: gentoo-mips@lists.gentoo.org MIME-Version: 1.0 To: Panagiotis Christopoulos , gentoo-mips@lists.gentoo.org CC: releng@gentoo.org Subject: Re: [gentoo-mips] Reducing the number of the MIPS supported stages References: <53679ACC.3000809@gentoo.org> <20140505170432.GA22867@earth.members.linode.com> In-Reply-To: <20140505170432.GA22867@earth.members.linode.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 51a280cb-0302-470a-9e1c-7234ac7eab45 X-Archives-Hash: 1c0f9a24213ff8649c5bb5673f318830 On 05/05/2014 06:04 PM, Panagiotis Christopoulos wrote: > On 15:06 Mon 05 May , Markos Chandras wrote: >> Hi all, > Hi, > >> ... >> This takes quite a bit of time for all stages to be built (by the time >> everything is built, we are one month passed the time the snapshot was >> taken). How about stop building stages for mips1, mips3 and mips4? We >> keep the existing stages on the mirrors but we will no longer update >> them (or maybe we do on per user or per case basis). I understand there >> is hardware for these ISAs but how often do people actually use the new >> stages? >> >> Just to be clear, I am not suggesting for the team to stop supporting >> these ISAs but to stop building new stages and let the users of such >> ISAs, grab an old stage3 and do the update themselves if needed. >> >> This will free up some hardware resources for building different stages >> for the newer ISAs (maybe more non-multilib n32 and n64 variants etc) >> >> What does everyone think? > > I agree. If we don't have the resources to build everything for everyone, Resources is not a huge problem at the moment. Like I explained on the other email, I am mainly interested in discussing whether doing so is desired or not. lets > just build what is mainstream at the moment. I don't know catalyst's internals > or how painful it would be to update the whole set once per year or a bit longer, but it could > be nice, because I'm not sure how possible would be to update a stage3 after > > 1-2 years. Reducing the frequency of such stages can also be an option. I didn't quite rule that out yet -- Regards, Markos Chandras