X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mx1.tetrasec.net (mx1.tetrasec.net [74.117.190.25]) by lists.alpinelinux.org (Postfix) with ESMTP id D51B55C5C81 for ; Tue, 27 Nov 2018 12:17:44 +0000 (GMT) Received: from mx1.tetrasec.net (mail.local [127.0.0.1]) by mx1.tetrasec.net (Postfix) with ESMTP id D0E5B9E20A7 for ; Tue, 27 Nov 2018 12:17:43 +0000 (GMT) Received: from ncopa-desktop.copa.dup.pw (67.63.200.37.customer.cdi.no [37.200.63.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: alpine@tanael.org) by mx1.tetrasec.net (Postfix) with ESMTPSA id 544409E1D24 for ; Tue, 27 Nov 2018 12:17:43 +0000 (GMT) Date: Tue, 27 Nov 2018 13:17:39 +0100 From: Natanael Copa To: alpine-devel@lists.alpinelinux.org Subject: [alpine-devel] a release engineering team? Message-ID: <20181127131739.658683ac@ncopa-desktop.copa.dup.pw> X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-alpine-linux-musl) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, I would like to form a release engineering (releng) team, who gets the responsibility to figure out how and when to do releases, and to document this process. This team will also get the responsibility to go over issues and PRs and decide which we should try fix/include for a given release and which should be postponed. Who would be interested in joining me with this? The current issues I'd like to discuss are: - regular edge releases/snapshots We need to do edge snapshot releases more often. How do we do that? what name of the tag? I have previously done tags like vYYMMDD (eg. v150306 and v160223). I think v2018.11.0 is clearer though. I don't think we need full release, with all iso image flavors. It may be enough with minirootfs tarball and maybe netboot and alpine-standard.iso. - small releases It maybe good to be able to create smaller releases of the stable branches, which only include minirootfs image and possibly netboot. I was thinking of add a version digit for this (eg v3.8.1.1), so when there are 4 digits in the release tag in stable branch, it will only generate a minirootfs image. We could also do this for the edge releases. For example, v2018.11 could be a big release, with all iso images generated, while v2018.11.1 is a small release, with only minirootfs generated. Alternatively we could have a different name of the git tag. for example: v3.8.1-mini2, to indicate that it should only generate minirootfs. - keep release data in separate repository Our release scripts will currently generate release when we create a tag in aports repository. The idea was to make it very easy to create releases, you just git push --tags and you're done. The reality is a bit more complicated. We need make sure they have built all packages, no build failures, close the target version in bugtracker, create new target version etc. If the build of release images fails for some reason, we cannot fix that and redo the build without first delete the git tag (which is very complicated since tag needs to be deleted from git mirrors as well), so in practice it means we need to fix the problem and create new version tag. I think it would be better if we could do something like: 1) lock git repo so noone can push new commits 2) send message to builder to try build release - if failure report back and release lock - if success: - release lock - create and push release tag in aports repo - upload release images Ideas? thoughs? -nc --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---