Mail archive
alpine-devel

Re: [alpine-devel] a release engineering team?

From: Dan Williams <me_at_deedubs.com>
Date: Mon, 3 Dec 2018 16:34:19 -0500

Dan Williams

On Mon., Dec. 3, 2018, 4:23 p.m. Natanael Copa <ncopa_at_alpinelinux.org wrote:

> On Wed, 28 Nov 2018 20:11:51 -0500
> Dan Williams <me_at_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
> > 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 <ncopa_at_alpinelinux.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 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_at_lists.alpinelinux.org
> > > Help: alpine-devel+help_at_lists.alpinelinux.org
> > > ---
> > >
> > >
>
>



---
Unsubscribe:  alpine-devel+unsubscribe_at_lists.alpinelinux.org
Help:         alpine-devel+help_at_lists.alpinelinux.org
---
Received on Mon Dec 03 2018 - 16:34:19 UTC