X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) by lists.alpinelinux.org (Postfix) with ESMTP id 30CF25C6715 for ; Mon, 3 Dec 2018 21:34:32 +0000 (GMT) Received: by mail-vs1-f43.google.com with SMTP id r14so8474372vsc.13 for ; Mon, 03 Dec 2018 13:34:32 -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=3zTwKyE2avNckrgWXgCbPZCM/n8mD9bBnmbpuxYtGNc=; b=aJ//YSMVj5NHeStBYNcL72RZYP52liIGwbUcCL1BwTYXzdZXFOLAlgIgN2VlqPXCuH mjnQPNB2L3fsZDkuk/namFGqEZx4HGXEOmGxUGgdN9wS12PG+3yQfNGSZXduOZes3Pk2 p9Oy0123yDmSeuXlA1whmdxGzyXtXidj0iExOT4NQ8n3P3nA9qXqsUGVTy20sDSuJATE Mqy9JisMFD09OThD+/cbxZ6YzOszYMQena3cpzg/ko/urGst3OBbvpqoPaTfRVV/uU7R xdfsyv+iBINvmf1qu9MtA72ahkSugJZmDblaVJS4He1bi2HRjL85/v8nzvtJ/cm01N/+ yDZw== 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=3zTwKyE2avNckrgWXgCbPZCM/n8mD9bBnmbpuxYtGNc=; b=AvgDRHas94s79cVZ6WOsHeE2Qdoy6YI1KVNBt5oTJjuIc0v4/PNtRAoGExl/ib+c0V eMtZsUJxs7ZOAfIuU1TckCC7dW1VjQ1w6vKanxNGkSb6+c6ylPprVt87i79ZYjKoBQpP s65lFXZpZsvukQMf2Cv/hVebuX5Pbwec6hqMnmx3j/PXsBGpajb43770FLP3qtTZ/DmM UVn+efNYiytNGNEOkZH56vxYtncWgI2aosp/f8/hGrttDzGHKDhe4VWvgknXcMUvpP9c Rha1jiP1Dpjwzz1M5AfMN4F2nOGHO4+JmDud4MV2SEHPsLelYrpsm+XxqmM1Fdh4mRDZ HYbQ== X-Gm-Message-State: AA+aEWaxXAIRNtazO11Mx06H2olQbddtEBirlacEPxrX+xKJ8G31PaeC 7CFHdrDQSxfBoHv5UjaoLAZmy6MPbPXjlBZ7qQLDyA== X-Google-Smtp-Source: AFSGD/UwMOmF06LgEhZ66A/nSoNedKsaXQFn17JQuCHN4PrFyMSnk4gr+QAw+Qhz13ERHqjYyDZPOLG9zp1O/2ri7h0= X-Received: by 2002:a67:8150:: with SMTP id c77mr7663105vsd.233.1543872871212; Mon, 03 Dec 2018 13:34:31 -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> <20181203222343.28e1b6fc@ncopa-desktop.copa.dup.pw> In-Reply-To: <20181203222343.28e1b6fc@ncopa-desktop.copa.dup.pw> From: Dan Williams Date: Mon, 3 Dec 2018 16:34:19 -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="000000000000114100057c24eacf" --000000000000114100057c24eacf Content-Type: text/plain; charset="UTF-8" Dan Williams On Mon., Dec. 3, 2018, 4:23 p.m. Natanael Copa On Wed, 28 Nov 2018 20:11:51 -0500 > Dan Williams wrote: > > > I'd like to assist with this.. > > > > Is there a cost associated with full builds? I have a build server we > could > > utilize > > We currently have enough build servers. Most of them are awesome > machines from packet.net. > > We do full (re)build for ever new stable branch, so v3.9 is on the way > currently. > > > I would suggest we use vM.m.p-# > > That is sort of what we currently do. Major, minor and patch release. > We went from v1.x to v2.x when uclibc broke ABI compat at one point. We > went from v2.x to v3.x when we switched to musl libc. > > This reminds me. After v3.9 we should do v3.10 and not v4.0. > > > Would you consider managing the issues and PRs together on GitHub? If > > no, we could consider moving to Gerrit to fully isolate ourselves. > > Not sure we want fully isolate ourselves. We currently track alpine > issues on redmine (https://bugs.alpinelinux.org). There have been talk > of moving to gitlab. There was some strong opinions on going full > github. I think releng should use the same platform as the rest of > alpine, whatever we end up with. > Yeah my comment on isolation was assuming there was a reason NOT to go full a GitHub. I think as a relteam we are going to want a single path for code to flow through. I have had great experiences with Gitlab. > > > 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. > > Hum, yeah. I think that would be nice. > > We currently have: > > - standard (default, minimal boot media for netinstall) > - extended (for offline install and tmpfs/diskless) > - virt (for virtual machine guests) > - xen (for Xen dom0 host) > - rpi (for raspberry pi) > - netboot (for ipxe boot + netinstall) > - minirootfs (for docker images) > > And then we have alpine for WSL. > > I am a bit worried for who will test each flavor when we do release > candidates? Or, lets say there is a security fix needed for docker > images. (in busybox, apk-tools or musl) and we want push a new release > ASAP. Do we need to test all flavors? If so, how do we prevent slow > down the release? > > Adding images for cloud providers will not make it easier to get > releases out quick. So how do we solve that? > > Maybe we should try keep a small focused official release images and > let others do specialized derivatives? I don't know what we prefer. We should definitely keep it simple to start and see where we feel we'd get the most value. I personally will be supporting the AWS AMIs once I get them building that is haha. shou > > > -nc > > > > > Dan Williams > > > > On Tue, Nov 27, 2018, 7:18 AM Natanael Copa > 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 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 > > > --- > > > > > > > > --000000000000114100057c24eacf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Dan = Williams

On Mon., Dec.= 3, 2018, 4:23 p.m. Natanael Copa <ncopa@alpinelinux.org wrote:
me@deedubs.com> wrote:

> I'd like to assist with this..
>
> Is there a cost associated with full builds? I have a build server we = could
> utilize

We currently have enough build servers. Most of them are awesome
machines from packet.net.

We do full (re)build for ever new stable branch, so v3.9 is on the way
currently.

> I would suggest we use vM.m.p-#

That is sort of what we currently do. Major, minor and patch release.
We went from v1.x to v2.x when uclibc broke ABI compat at one point. We
went from v2.x to v3.x when we switched to musl libc.

This reminds me. After v3.9 we should do v3.10 and not v4.0.

> Would you consider managing the issues and PRs together on GitHub? If<= br> > no, we could consider moving to Gerrit to fully isolate ourselves.

Not sure we want fully isolate ourselves. We currently track alpine
issues on redmine (https://bugs.alpinelinux.org). There h= ave been talk
of moving to gitlab. There was some strong opinions on going full
github. I think releng should use the same platform as the rest of
alpine, whatever we end up with.

Yeah my comment on isolation was assuming t= here was a reason NOT to go full a GitHub. I think as a relteam we are goin= g to want a single path for code to flow through. I have had great experien= ces with Gitlab.=C2=A0

> Also selfishly I'd love to see an official AMI / other cloud image= s.
> Full disclosure I'm building a k8s distribution that uses Alpine a= s a
> base.

Hum, yeah. I think that would be nice.

We currently have:

- standard (default, minimal boot media for netinstall)
- extended (for offline install and tmpfs/diskless)
- virt (for virtual machine guests)
- xen (for Xen dom0 host)
- rpi (for raspberry pi)
- netboot (for ipxe boot + netinstall)
- minirootfs (for docker images)

And then we have alpine for WSL.

I am a bit worried for who will test each flavor when we do release
candidates? Or, lets say there is a security fix needed for docker
images. (in busybox, apk-tools or musl) and we want push a new release
ASAP. Do we need to test all flavors? If so, how do we prevent slow
down the release?

Adding images for cloud providers will not make it easier to get
releases out quick. So how do we solve that?

Maybe we should try keep a small focused official release images and
let others do specialized derivatives? I don't know what we prefer.

We shoul= d definitely keep it simple to start and see where we feel we'd get the= most value. I personally will be supporting the AWS AMIs once I get them b= uilding that is haha.=C2=A0

=C2=A0shou

-nc

>
> Dan Williams
>
> On Tue, Nov 27, 2018, 7:18 AM Natanael Copa <ncopa@alpinelinux.o= rg
> wrote:
>
> > Hi,
> >
> > I would like to form a release engineering (releng) team, who get= s
> > 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 tha= t?
> > what name of the tag? I have previously done tags like vYYMMDD (e= g.
> > v150306 and v160223). I think v2018.11.0 is clearer though.
> >
> > I don't think we need full release, with all iso image flavor= s. 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 netboo= t.
> > I was thinking of add a version digit for this (eg v3.8.1.1), so<= br> > > 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<= br> > > the edge releases. For example, v2018.11 could be a big release,<= br> > > with all iso images generated, while v2018.11.1 is a small releas= e,
> > 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 creat= e 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. Th= e
> > reality is a bit more complicated. We need make sure they have > > built all packages, no build failures, close the target version i= n
> > bugtracker, create new target version etc. If the build of releas= e
> > images fails for some reason, we cannot fix that and redo the bui= ld
> > 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<= br> > >=C2=A0 =C2=A0 =C2=A0 - upload release images
> >
> >
> > Ideas? thoughs?
> >
> > -nc
> >
> >
> >
> > ---
> > Unsubscribe:=C2=A0 alpine-devel+uns= ubscribe@lists.alpinelinux.org
> > Help:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alp= ine-devel+help@lists.alpinelinux.org
> > ---
> >
> >=C2=A0

--000000000000114100057c24eacf-- --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---