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

From: Natanael Copa <[email-masked]>
Date: Tue, 4 Dec 2018 17:58:41 +0100

On Fri, 30 Nov 2018 05:11:12 +0100
"Lucas Ramage" <[email-masked]> wrote:

> > 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
>  
> I am also interested in helping with this, particularly the documentation
> portion. What was the final descision made regarding the wiki? If I recall
> correctly, there was a thread awhile back about moving the existing documentation
> to somewhere else.

Yes, we want move official documentation to a separate platform. It
seems like we want go for asciidoc. This has been discussed on IRC,
#alpine-docs on Freenode. Feel free to join there.
  
> > - keep release data in separate repository
>  
> Perhaps we could keep the documentation in this repository and
> generate it via static site generator e.g sphinx, mkdocs, etc.

or antora

> > Would you consider managing the issues and PRs together on GitHub? If no,
> > we could consider moving to Gerrit to fully isolate ourselves.
>  
> As a package maintainer who submits patches via the mailing list, I am not in favor of this.

We probably need support both.

> > 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. 
>  
> How would cloud images differ from the virtual or mini rootfs images already provided?
>  
> Lucas Ramage / Software Engineer
> [email-masked] / (941) 404-6794
> 
> PGP Fingerprint
> EAE7 45DF 818D 4948 DDA7 0F44 F52A 5A96 7B9B 6FB7
> 
> Visit online journal
> http://lramage94.gitlab.io
>  
>  
> Sent: Wednesday, November 28, 2018 at 8:11 PM
> From: "Dan Williams" <[email-masked]>
> To: "Natanael Copa" <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [alpine-devel] a release engineering team?
> 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 <[email-masked] 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:  [email-masked]
> > Help:         [email-masked]
> > ---
> >  
> 

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---