On Fri, 30 Nov 2018 05:11:12 +0100
"Lucas Ramage" <oxr463@gmx.us> 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
> ramage.lucas@protonmail.com / (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" <me@deedubs.com>
> To: "Natanael Copa" <ncopa@alpinelinux.org>
> Cc: alpine-devel@lists.alpinelinux.org
> 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 <ncopa@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@lists.alpinelinux.org
> > Help: alpine-devel+help@lists.alpinelinux.org
> > ---
> >
>
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---