Received: from magnesium.8pit.net (magnesium.8pit.net [45.76.88.171]) by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id 9F071782BAC for <~alpine/devel@lists.alpinelinux.org>; Sat, 30 May 2020 09:11:45 +0000 (UTC) Received: from magnesium.8pit.net (localhost [127.0.0.1]) by magnesium.8pit.net (OpenSMTPD) with ESMTP id 965bd2ba for <~alpine/devel@lists.alpinelinux.org>; Sat, 30 May 2020 11:11:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=soeren-tempel.net; h=date :to:subject:from:references:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=opensmtpd; bh=1bH3tHs 2G+weqblxoSHTcrLr2Ao=; b=VEVcT4sT+TM+0FSV9IG4azjgn099EY7rMA+RmW5 UXw46RcICsn/nzhOy7hp31daJyRXDygg4CPbUTXAv2D1JouCeUgxmiiI0cI2lS8L taK46Ugq5sCYKiZcbMYdv2WsQ4ASfEdrqQcpNMW8LT/RBqhfLxdv7McfZBsIKyS+ fDWY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=soeren-tempel.net; h=date:to :subject:from:references:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; q=dns; s=opensmtpd; b=C dGQfmrMcSXaopHvfJpfYu6zuEGrRE+b5cuk+DCUnmSDjqDry60aPjyzReApADjMO 5fBd1oLxoOS0Px8fQD7EKSdEe+bcKq+j+E1FnxU0T4P7stvx4re2ky5zMmNC1Non VssircnI+rhK7b/u1iPwGRVkAqUX45Q+dj3j29nOEc= Received: from localhost (ip4d17229f.dynamic.kabel-deutschland.de [77.23.34.159]) by magnesium.8pit.net (OpenSMTPD) with ESMTPSA id 8eaf286a (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:YES) for <~alpine/devel@lists.alpinelinux.org>; Sat, 30 May 2020 11:11:43 +0200 (CEST) Date: Sat, 30 May 2020 11:11:42 +0200 To: ~alpine/devel@lists.alpinelinux.org Subject: Re: release qualification process From: =?UTF-8?Q?S=C3=B6ren?= Tempel References: <15782174.Tt3s28fcIf@localhost> In-Reply-To: <15782174.Tt3s28fcIf@localhost> Message-Id: <3ICP52XPGB00H.3TPAWIW7GLV4P@8pit.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Thunderbird/55.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ariadne Conill wrote: > Hello, Hi, > I would like to propose an update to our release qualification process th= at=20 > should resolve this problem: each architecture has a designated release=20= > manager, and each release manager gives a go/no-go before the release pro= cess=20 > is initiated with a git tag. In the event that a release manager gives a= no- > go for an architecture, the release may either be delayed or the architec= ture=20 > not included in the release, depending on the situation. The core team (= or=20 > its designated replacement) may also issue a no-go for a specific archite= cture. In general, it would be convenient to have an individual or a group of individuals "responsible" for a specific architecture. For instance, if tests for an aport fail on a specific architecture one can contact the individual(s) responsible for this architecture for further investigation. Given the amount of architectures we currently support, I occasionally run into issues on architecture I do not have direct access to (e.g. s390x) without any means of debugging the issue. The individual(s) could also be responsible for overseeing the release process on this architecture. Greetings, S=C3=B6ren