X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) by lists.alpinelinux.org (Postfix) with ESMTP id 298295C5C7B for ; Thu, 29 Nov 2018 01:12:04 +0000 (GMT) Received: by mail-vs1-f50.google.com with SMTP id v205so151576vsc.3 for ; Wed, 28 Nov 2018 17:12:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deedubs-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PLDIyfJPJ39ogBKW5EbkLVCmraCTg3jMLfTsRDq1k04=; b=s+u3ljqMWTI44/0EWO5G9Z2vqjvbnGQcYnoJTQcvNDUc7fKYXngnBmvfHCFUHmfMOv zZyjJR3swAX3Cd7TShMmsnd+mzpIDp4NKOp2O9WF47QhrlfE0Xg3EmefVmPZMaq4YUE0 aUXW97QtnWZ5hy40rY4Eagrpsa4qRq4U/7pDELFJsUTgZu1LuyAtRySe4CZBnsMkYNBn 1XEOvx8Nabf3GZi6FUAziaZjbfiZ2dMkV83Q4KlIsAKH0wxhbrTFYpRaOd04+amCFGLV meOsX6deK3r3g1y3k2U+vIpOU70Iyc4x9uGTWI9nIn7bnMaJ21up3f+2USVLq1doMXei 8vsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PLDIyfJPJ39ogBKW5EbkLVCmraCTg3jMLfTsRDq1k04=; b=k0tN1vmq5L/v4vmk9KrLlpXguvOap5oYgvnvWmbf4kWf3sKsNIe1aNHyrQO49BKFgd U5x+vhl9oAcTGDvIVZWVdNKAer9RJlLcLxhJOG9TfvNMSSwstub9pEQ9tPg7RL2m8vC1 tjJ/6Fr652nRLqGT5t3NWodmKg3fgjxpTfvSMO6MWSC/DjcaGDKmiOpNd0bU9e705kvA o6McXjQXzZvGjKRZ55kENW+sEDBpWMAZV8BB3lS3JgpxSS9ep7y4n/mPMzsQrhAINNwu NIo8YsdAbiAE76iyFufyxM3KgQaqJL1mGkWGbtzpjJ0D+3GDfQuyjh+OxKW3ZPvx2ONg 6pSQ== X-Gm-Message-State: AGRZ1gIbh5KGo4KF6gZSO0K29yU8vmT2nnl6VzuVAZKgbPWICM6Po2qA JEv019j/WJb/TE0x+ZAVPLeFX5MKt4OohDNPM74S5A== X-Google-Smtp-Source: AJdET5ewvhruOjgg3M/X9SmWXcnei1wYVd9pgwbAPflCb+L41/kb/gqk0lFmW4/AJM2Gq//VCA7OH3CUurOPzyUs5ck= X-Received: by 2002:a67:8cc2:: with SMTP id o185mr16559700vsd.55.1543453923309; Wed, 28 Nov 2018 17:12:03 -0800 (PST) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 References: <20181127131739.658683ac@ncopa-desktop.copa.dup.pw> In-Reply-To: <20181127131739.658683ac@ncopa-desktop.copa.dup.pw> From: Dan Williams Date: Wed, 28 Nov 2018 20:11:51 -0500 Message-ID: Subject: Re: [alpine-devel] a release engineering team? To: Natanael Copa Cc: alpine-devel@lists.alpinelinux.org Content-Type: multipart/alternative; boundary="000000000000d38c7c057bc35e28" --000000000000d38c7c057bc35e28 Content-Type: text/plain; charset="UTF-8" I'd like to assist with this.. Is there a cost associated with full builds? I have a build server we could utilize I would suggest we use vM.m.p-# Would you consider managing the issues and PRs together on GitHub? If no, we could consider moving to Gerrit to fully isolate ourselves. Also selfishly I'd love to see an official AMI / other cloud images. Full disclosure I'm building a k8s distribution that uses Alpine as a base. Dan Williams On Tue, Nov 27, 2018, 7:18 AM Natanael Copa 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 > --- > > --000000000000d38c7c057bc35e28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd like to assist with this..

<= /div>
Is there a cost associated with full builds? I have = a build server we could utilize=C2=A0

I would suggest we use vM.m.p-#=C2=A0
=
Would you consider managing the issues and PRs = together on GitHub? If no, we could consider moving to Gerrit to fully isol= ate ourselves.=C2=A0

Als= o selfishly I'd love to see an official AMI / other cloud images. Full = disclosure I'm building a k8s distribution that uses Alpine as a base.= =C2=A0



Dan Williams
<= br>
On Tue, Nov 27, 2018, 7:18 A= M Natanael Copa <ncopa@alpineli= nux.org wrote:
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<= br> 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
=C2=A0 =C2=A0- if failure report back and release lock
=C2=A0 =C2=A0- if success:
=C2=A0 =C2=A0 =C2=A0- release lock
=C2=A0 =C2=A0 =C2=A0- create and push release tag in aports repo
=C2=A0 =C2=A0 =C2=A0- upload release images


Ideas? thoughs?

-nc



---
Unsubscribe:=C2=A0 alpine-devel+unsubscribe@l= ists.alpinelinux.org
Help:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alpine-devel+= help@lists.alpinelinux.org
---

--000000000000d38c7c057bc35e28-- --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---