Re: Tags, version numbers and docker
I am fine with it if there is someone pushing the process forward. - Sijie On Thu, Mar 28, 2019 at 4:12 AM Jia Zhai wrote: > +1 for ivan's idea > > Best Regards. > > > Jia Zhai > > Beijing, China > > Mobile: +86 15810491983 > > > > > On Thu, Mar 28, 2019 at 6:55 PM Enrico Olivelli > wrote: > > > Il giorno gio 28 mar 2019 alle ore 09:26 Ivan Kelly > > ha scritto: > > > > > > To clarify, what I intend to do here is. > > > > > > 1. Merge change from [1] to all live branches, so docker image will > > > build directly from the voted on tag. > > > 2. Get infra to add another autobuild rule that matches on > > > release-([0-9.]+)\/docker, so that 4.8.2 and maybe 4.9.1 can be built > > > with this change. This rule would not be used after that point. > > > > > > +1 > > > > > > > > -Ivan > > > > > > [1] > > > https://github.com/ivankelly/bookkeeper/commit/e247ef705f055706604ba2f862c1006a8cf817e9 > > > > > > On Wed, Mar 27, 2019 at 10:52 AM Ivan Kelly wrote: > > > > > > > > > That’s a known issue. The auto build is controlled by ASF. We have > > > > > discussed that before and came up the conclusion of current > > approach. There > > > > > is a BP to move dockerfile to a different repo. It just need > someone > > to > > > > > complete the BP. > > > > > > > > This was a known issue a year ago. Nothing has moved on it, so I'm > > > > trying to make movement now. > > > > > > > > > If you did so, you will not release 4.8.2 image, no? > > > > > > > > The image isn't part of the official release. At most it's a > > > > convenience binary of the official release. However, at present it > > > > isn't even that since it's generated from a tag which has not been > +1d > > > > by 3 PMC members. > > > > > > > > > Instead of doing a different way at the last phase of releasing a > > release, > > > > > I would suggest following the guide that was agreed by the > > community, and > > > > > work on the BP to move the dockerfile to a different repo in next > > release. > > > > > > > > There's a fundamental release issue here. The official release is the > > > > source tarball. The tag should reflect the contents of the source > > > > tarball, and it should be possible to generate all binary convenience > > > > packages from the source tarball. > > > > > > > > Things that do not match this criteria should not be presented as > part > > > > of the release as they have not been approved by 3 members of the > PMC. > > > > > > > > I'm not going to put my signature on a tag which hasn't been voted > on. > > > > Currently whether tags constitute an official release artifact is > > > > unresolved from a legal POV [1], but they are two clicks away from > the > > > > bookkeeper website frontpage so I think we should treat them as such. > > > > > > > > I will however fix the process for subsequent releases. The simplest > > > > fix is to set the BK_VERSION from tag name. This can be done in a > > > > build hook [2] which dockerhub autobuild[3] will pick up. Really > > > > though we should build the tarball in a prehook so that the image can > > > > also be generated for release candidates, so it can be tested and > > > > voted on along with the rest of the convenience binaries. > > > > > > > > -Ivan > > > > > > > > [1] https://issues.apache.org/jira/browse/LEGAL-438 > > > > [2] > > > https://github.com/ivankelly/bookkeeper/commit/e247ef705f055706604ba2f862c1006a8cf817e9 > > > > [3] > > > https://cloud.docker.com/repository/registry-1.docker.io/ivankelly/bookkeeper/builds > > >
Re: Tags, version numbers and docker
+1 for ivan's idea Best Regards. Jia Zhai Beijing, China Mobile: +86 15810491983 On Thu, Mar 28, 2019 at 6:55 PM Enrico Olivelli wrote: > Il giorno gio 28 mar 2019 alle ore 09:26 Ivan Kelly > ha scritto: > > > > To clarify, what I intend to do here is. > > > > 1. Merge change from [1] to all live branches, so docker image will > > build directly from the voted on tag. > > 2. Get infra to add another autobuild rule that matches on > > release-([0-9.]+)\/docker, so that 4.8.2 and maybe 4.9.1 can be built > > with this change. This rule would not be used after that point. > > > +1 > > > > > -Ivan > > > > [1] > https://github.com/ivankelly/bookkeeper/commit/e247ef705f055706604ba2f862c1006a8cf817e9 > > > > On Wed, Mar 27, 2019 at 10:52 AM Ivan Kelly wrote: > > > > > > > That’s a known issue. The auto build is controlled by ASF. We have > > > > discussed that before and came up the conclusion of current > approach. There > > > > is a BP to move dockerfile to a different repo. It just need someone > to > > > > complete the BP. > > > > > > This was a known issue a year ago. Nothing has moved on it, so I'm > > > trying to make movement now. > > > > > > > If you did so, you will not release 4.8.2 image, no? > > > > > > The image isn't part of the official release. At most it's a > > > convenience binary of the official release. However, at present it > > > isn't even that since it's generated from a tag which has not been +1d > > > by 3 PMC members. > > > > > > > Instead of doing a different way at the last phase of releasing a > release, > > > > I would suggest following the guide that was agreed by the > community, and > > > > work on the BP to move the dockerfile to a different repo in next > release. > > > > > > There's a fundamental release issue here. The official release is the > > > source tarball. The tag should reflect the contents of the source > > > tarball, and it should be possible to generate all binary convenience > > > packages from the source tarball. > > > > > > Things that do not match this criteria should not be presented as part > > > of the release as they have not been approved by 3 members of the PMC. > > > > > > I'm not going to put my signature on a tag which hasn't been voted on. > > > Currently whether tags constitute an official release artifact is > > > unresolved from a legal POV [1], but they are two clicks away from the > > > bookkeeper website frontpage so I think we should treat them as such. > > > > > > I will however fix the process for subsequent releases. The simplest > > > fix is to set the BK_VERSION from tag name. This can be done in a > > > build hook [2] which dockerhub autobuild[3] will pick up. Really > > > though we should build the tarball in a prehook so that the image can > > > also be generated for release candidates, so it can be tested and > > > voted on along with the rest of the convenience binaries. > > > > > > -Ivan > > > > > > [1] https://issues.apache.org/jira/browse/LEGAL-438 > > > [2] > https://github.com/ivankelly/bookkeeper/commit/e247ef705f055706604ba2f862c1006a8cf817e9 > > > [3] > https://cloud.docker.com/repository/registry-1.docker.io/ivankelly/bookkeeper/builds >
Re: Tags, version numbers and docker
Il giorno gio 28 mar 2019 alle ore 09:26 Ivan Kelly ha scritto: > > To clarify, what I intend to do here is. > > 1. Merge change from [1] to all live branches, so docker image will > build directly from the voted on tag. > 2. Get infra to add another autobuild rule that matches on > release-([0-9.]+)\/docker, so that 4.8.2 and maybe 4.9.1 can be built > with this change. This rule would not be used after that point. +1 > > -Ivan > > [1] > https://github.com/ivankelly/bookkeeper/commit/e247ef705f055706604ba2f862c1006a8cf817e9 > > On Wed, Mar 27, 2019 at 10:52 AM Ivan Kelly wrote: > > > > > That’s a known issue. The auto build is controlled by ASF. We have > > > discussed that before and came up the conclusion of current approach. > > > There > > > is a BP to move dockerfile to a different repo. It just need someone to > > > complete the BP. > > > > This was a known issue a year ago. Nothing has moved on it, so I'm > > trying to make movement now. > > > > > If you did so, you will not release 4.8.2 image, no? > > > > The image isn't part of the official release. At most it's a > > convenience binary of the official release. However, at present it > > isn't even that since it's generated from a tag which has not been +1d > > by 3 PMC members. > > > > > Instead of doing a different way at the last phase of releasing a release, > > > I would suggest following the guide that was agreed by the community, and > > > work on the BP to move the dockerfile to a different repo in next release. > > > > There's a fundamental release issue here. The official release is the > > source tarball. The tag should reflect the contents of the source > > tarball, and it should be possible to generate all binary convenience > > packages from the source tarball. > > > > Things that do not match this criteria should not be presented as part > > of the release as they have not been approved by 3 members of the PMC. > > > > I'm not going to put my signature on a tag which hasn't been voted on. > > Currently whether tags constitute an official release artifact is > > unresolved from a legal POV [1], but they are two clicks away from the > > bookkeeper website frontpage so I think we should treat them as such. > > > > I will however fix the process for subsequent releases. The simplest > > fix is to set the BK_VERSION from tag name. This can be done in a > > build hook [2] which dockerhub autobuild[3] will pick up. Really > > though we should build the tarball in a prehook so that the image can > > also be generated for release candidates, so it can be tested and > > voted on along with the rest of the convenience binaries. > > > > -Ivan > > > > [1] https://issues.apache.org/jira/browse/LEGAL-438 > > [2] > > https://github.com/ivankelly/bookkeeper/commit/e247ef705f055706604ba2f862c1006a8cf817e9 > > [3] > > https://cloud.docker.com/repository/registry-1.docker.io/ivankelly/bookkeeper/builds
Re: Tags, version numbers and docker
To clarify, what I intend to do here is. 1. Merge change from [1] to all live branches, so docker image will build directly from the voted on tag. 2. Get infra to add another autobuild rule that matches on release-([0-9.]+)\/docker, so that 4.8.2 and maybe 4.9.1 can be built with this change. This rule would not be used after that point. -Ivan [1] https://github.com/ivankelly/bookkeeper/commit/e247ef705f055706604ba2f862c1006a8cf817e9 On Wed, Mar 27, 2019 at 10:52 AM Ivan Kelly wrote: > > > That’s a known issue. The auto build is controlled by ASF. We have > > discussed that before and came up the conclusion of current approach. There > > is a BP to move dockerfile to a different repo. It just need someone to > > complete the BP. > > This was a known issue a year ago. Nothing has moved on it, so I'm > trying to make movement now. > > > If you did so, you will not release 4.8.2 image, no? > > The image isn't part of the official release. At most it's a > convenience binary of the official release. However, at present it > isn't even that since it's generated from a tag which has not been +1d > by 3 PMC members. > > > Instead of doing a different way at the last phase of releasing a release, > > I would suggest following the guide that was agreed by the community, and > > work on the BP to move the dockerfile to a different repo in next release. > > There's a fundamental release issue here. The official release is the > source tarball. The tag should reflect the contents of the source > tarball, and it should be possible to generate all binary convenience > packages from the source tarball. > > Things that do not match this criteria should not be presented as part > of the release as they have not been approved by 3 members of the PMC. > > I'm not going to put my signature on a tag which hasn't been voted on. > Currently whether tags constitute an official release artifact is > unresolved from a legal POV [1], but they are two clicks away from the > bookkeeper website frontpage so I think we should treat them as such. > > I will however fix the process for subsequent releases. The simplest > fix is to set the BK_VERSION from tag name. This can be done in a > build hook [2] which dockerhub autobuild[3] will pick up. Really > though we should build the tarball in a prehook so that the image can > also be generated for release candidates, so it can be tested and > voted on along with the rest of the convenience binaries. > > -Ivan > > [1] https://issues.apache.org/jira/browse/LEGAL-438 > [2] > https://github.com/ivankelly/bookkeeper/commit/e247ef705f055706604ba2f862c1006a8cf817e9 > [3] > https://cloud.docker.com/repository/registry-1.docker.io/ivankelly/bookkeeper/builds
