From nobody Thu Mar 28 12:40:12 2024 Received: from out1.migadu.com (out1.migadu.com [91.121.223.63]) by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id 0D59B782B1E for <~alpine/devel@lists.alpinelinux.org>; Fri, 29 May 2020 17:31:39 +0000 (UTC) X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dereferenced.org; s=default; t=1590773498; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=57u4b/PYWeI5YHfokkXQlqZUUXuc+hy0gTxteazuczo=; b=shuOGSNnqqo5NqH6jjSMAabh0EBVxRjf1QDI2m5966aUqb4Z3a7vYUZayxWrruZcFxkzcN he0rf6iCMMqTJ/PJhxX48M6byPy13gHi71kzq+RhlcvppaPWvm71KGItlwibqD8j5aYFJR KzTzsFcLXC6ojRfB15jqlaYMcNRoIq0= From: Ariadne Conill To: ~alpine/devel@lists.alpinelinux.org Subject: release qualification process Date: Fri, 29 May 2020 11:31:33 -0600 Message-ID: <15782174.Tt3s28fcIf@localhost> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.90 Hello, In the process of releasing Alpine 3.12, it was observed that the s390x machines had not built any of the RCs and were in fact behind by 22 days. This has caused some turbulence in releasing Alpine 3.12, as we are now waiting on the s390x builder to catch up. I would like to propose an update to our release qualification process that should resolve this problem: each architecture has a designated release manager, and each release manager gives a go/no-go before the release process 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 architecture not included in the release, depending on the situation. The core team (or its designated replacement) may also issue a no-go for a specific architecture. Thoughts? Ariadne From nobody Thu Mar 28 12:40:12 2024 Received: from vps892.directvps.nl (ikke.info [178.21.113.177]) by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id 4615B781F30 for <~alpine/devel@lists.alpinelinux.org>; Fri, 29 May 2020 19:33:42 +0000 (UTC) Received: by vps892.directvps.nl (Postfix, from userid 1008) id 6128A4400E1; Fri, 29 May 2020 21:33:41 +0200 (CEST) Date: Fri, 29 May 2020 21:33:41 +0200 From: Kevin Daudt To: Ariadne Conill Cc: ~alpine/devel@lists.alpinelinux.org Subject: Re: release qualification process Message-ID: <20200529193341.GA2120621@alpha> References: <15782174.Tt3s28fcIf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15782174.Tt3s28fcIf@localhost> On Fri, May 29, 2020 at 11:31:33AM -0600, Ariadne Conill wrote: > Hello, > > In the process of releasing Alpine 3.12, it was observed that the s390x > machines had not built any of the RCs and were in fact behind by 22 days. > This has caused some turbulence in releasing Alpine 3.12, as we are now > waiting on the s390x builder to catch up. > > I would like to propose an update to our release qualification process that > should resolve this problem: each architecture has a designated release > manager, and each release manager gives a go/no-go before the release process > 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 architecture > not included in the release, depending on the situation. The core team (or > its designated replacement) may also issue a no-go for a specific architecture. > > Thoughts? > > Ariadne > Hi, I think something needs to improve, but I wonder how this will work in practice. The release manager would need to be someone involved with that specific platform and also sufficiently involved in the project (I guess having access to main would probably necessary). Otherwise it would only be an administrative role without any real benefit, that turns up just twice per year when we do a release. I feel that for most platforms, this person would end up being ncopa anyway, so not a lot would change. But we have to start somewhere, otherwise we will be stuck in the same situation forever. Kevin From nobody Thu Mar 28 12:40:12 2024 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