Re: Podlings not following ASF release policy
Quoting from the document - Unique Enough Names The name needs be unique enough to avoid confusion with software that already exists. For the community to be able to protect its reputation for quality and openness, its name needs to unique enough to have potential as a trademark. But this isn’t only about being able to register trademark protection. Ethics also plays a role. Even where a name may offer enough protection, existing adoption of the name by an active community may mean that the choice needs to be eliminated on ethical grounds. There is some judgment involved in this decision. So, involve the wider Incubator community if a name is already used. On Tue, Feb 19, 2019 at 6:47 AM Moaz Reyad wrote: > Hi Justin, > > The download page of SINGA is ( > https://singa.incubator.apache.org/en/downloads.html ). The page that you > mentioned is the index page. The official ASF releases are in the downloads > page. > > The index page is the landing page of the website and it contains all the > different ways to get started with SINGA. The index page encourages new > users to start using the system on pre-installed environment such as AWS or > Docker. > > We will create a ticket to move the docker image under Apache and add > missing files to it. > > Thank you, > Moaz > > On Tue, Feb 19, 2019 at 9:03 AM Justin Mclean > wrote: > > > Hi, > > > > > Can you please elaborate on release policy issues with Singa ? > > > I checked a few things but couldn't find the issue. > > > > > > Nothing too major. If you look at the download page [1] it’s encouraging > > people to use docker [2] and AWS [3]. Both pages probably has some minor > > branding/trademark issues but I’m more concerned about the docker one as > > it’s not under the apache docker username and the download page points > > directly to it without any indication it’s 3rd party. It’s seems to be > > encouraging people to use the develop /latest version rather the the > > offical releases, although I’m not a 100% sure, I had a quick look at > the > > docker content but it wasn’t clear and it also seemed to be missing > > important files like LICENSE, NOTICE etc etc > > > > Thanks, > > Justin > > > > 1. https://singa.incubator.apache.org/en/index.html > > 2. https://hub.docker.com/r/nusdbsystem/singa/ > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > >
Re: Podlings not following ASF release policy
Hi Justin, The download page of SINGA is ( https://singa.incubator.apache.org/en/downloads.html ). The page that you mentioned is the index page. The official ASF releases are in the downloads page. The index page is the landing page of the website and it contains all the different ways to get started with SINGA. The index page encourages new users to start using the system on pre-installed environment such as AWS or Docker. We will create a ticket to move the docker image under Apache and add missing files to it. Thank you, Moaz On Tue, Feb 19, 2019 at 9:03 AM Justin Mclean wrote: > Hi, > > > Can you please elaborate on release policy issues with Singa ? > > I checked a few things but couldn't find the issue. > > > Nothing too major. If you look at the download page [1] it’s encouraging > people to use docker [2] and AWS [3]. Both pages probably has some minor > branding/trademark issues but I’m more concerned about the docker one as > it’s not under the apache docker username and the download page points > directly to it without any indication it’s 3rd party. It’s seems to be > encouraging people to use the develop /latest version rather the the > offical releases, although I’m not a 100% sure, I had a quick look at the > docker content but it wasn’t clear and it also seemed to be missing > important files like LICENSE, NOTICE etc etc > > Thanks, > Justin > > 1. https://singa.incubator.apache.org/en/index.html > 2. https://hub.docker.com/r/nusdbsystem/singa/ > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Podlings not following ASF release policy
Noted. Thanks, Justin! Regards, Wei On Tue, Feb 19, 2019 at 4:04 PM Justin Mclean wrote: > Hi, > > > Can you please elaborate on release policy issues with Singa ? > > I checked a few things but couldn't find the issue. > > > Nothing too major. If you look at the download page [1] it’s encouraging > people to use docker [2] and AWS [3]. Both pages probably has some minor > branding/trademark issues but I’m more concerned about the docker one as > it’s not under the apache docker username and the download page points > directly to it without any indication it’s 3rd party. It’s seems to be > encouraging people to use the develop /latest version rather the the > offical releases, although I’m not a 100% sure, I had a quick look at the > docker content but it wasn’t clear and it also seemed to be missing > important files like LICENSE, NOTICE etc etc > > Thanks, > Justin > > 1. https://singa.incubator.apache.org/en/index.html > 2. https://hub.docker.com/r/nusdbsystem/singa/ > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Podlings not following ASF release policy
Hi, > Can you please elaborate on release policy issues with Singa ? > I checked a few things but couldn't find the issue. Nothing too major. If you look at the download page [1] it’s encouraging people to use docker [2] and AWS [3]. Both pages probably has some minor branding/trademark issues but I’m more concerned about the docker one as it’s not under the apache docker username and the download page points directly to it without any indication it’s 3rd party. It’s seems to be encouraging people to use the develop /latest version rather the the offical releases, although I’m not a 100% sure, I had a quick look at the docker content but it wasn’t clear and it also seemed to be missing important files like LICENSE, NOTICE etc etc Thanks, Justin 1. https://singa.incubator.apache.org/en/index.html 2. https://hub.docker.com/r/nusdbsystem/singa/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings not following ASF release policy
Hi Justin, Can you please elaborate on release policy issues with Singa ? I checked a few things but couldn't find the issue. Thanks, Thejas On Fri, Feb 8, 2019 at 5:51 PM Justin Mclean wrote: > Hi, > > So I just checked the next bunch of podlings to report to see if we have > any other issues with ASF releases policy and sadly we do and again it > larger than I expected. Some of these are minor issues and easily fixed, > some are not. In a couple of cases I may not of looked deeply enough into > the issue and it may actually be fine, if so apologies in advance for > listing you here. In a couple of cases (e.g. Zipkin) I can see it’s been > discussed on the list but there’s more to do. > > Podlings having one or more issues with ASF release policy include: > - Crail > - Daffodil > - Dlab > - Druid > - Dubbo > - Hivemall > - Marvin-ai > - Memo > - Omid > - Openwhisk > - Pinot > - Ponymail > - Singa > - Skywalking > - Zipkin > > Projects that I will be following up with include Dlab, Druid, Dubbo, > Openwhisk, Singa, Skywalking and Zipkin. > > If you are the mentors of these projects please take a look and see what > you can do to improve the situation and educate your podling on proper > release policy. If you can’t find the issue ping me and I’ll send an email > with what I think it is to your private list. There is probably things I’ve > missed as well, often were there’s one issue there’s others. > > Please include something in the next podling report on this. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Podlings not following ASF release policy
Thx Justin, I was assuming the community just simply creating tag in the github and have not published them as releases. Will need to review what had been create there - Henry On Fri, Feb 15, 2019, 2:02 PM Justin Mclean Hi, > > > Will be following up with the community of DLab to make sure they follow > > the ASF release policy. > > Thanks Henry I assume you saw the different GitHub repos and noted the > dates of “releases" there? > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Podlings not following ASF release policy
Hi, > Will be following up with the community of DLab to make sure they follow > the ASF release policy. Thanks Henry I assume you saw the different GitHub repos and noted the dates of “releases" there? Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings not following ASF release policy
Hi Justin, Will be following up with the community of DLab to make sure they follow the ASF release policy. Thanks, - Henry On Fri, Feb 8, 2019 at 4:51 PM Justin Mclean wrote: > Hi, > > So I just checked the next bunch of podlings to report to see if we have > any other issues with ASF releases policy and sadly we do and again it > larger than I expected. Some of these are minor issues and easily fixed, > some are not. In a couple of cases I may not of looked deeply enough into > the issue and it may actually be fine, if so apologies in advance for > listing you here. In a couple of cases (e.g. Zipkin) I can see it’s been > discussed on the list but there’s more to do. > > Podlings having one or more issues with ASF release policy include: > - Crail > - Daffodil > - Dlab > - Druid > - Dubbo > - Hivemall > - Marvin-ai > - Memo > - Omid > - Openwhisk > - Pinot > - Ponymail > - Singa > - Skywalking > - Zipkin > > Projects that I will be following up with include Dlab, Druid, Dubbo, > Openwhisk, Singa, Skywalking and Zipkin. > > If you are the mentors of these projects please take a look and see what > you can do to improve the situation and educate your podling on proper > release policy. If you can’t find the issue ping me and I’ll send an email > with what I think it is to your private list. There is probably things I’ve > missed as well, often were there’s one issue there’s others. > > Please include something in the next podling report on this. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Podlings not following ASF release policy
Hello Justin, Could you please tell us about issues with ASF release policy in Marvin? Thanks! Yifei Zhang Em seg, 11 de fev de 2019 às 02:27, Kenneth Knowles escreveu: > [1] https://issues.apache.org/jira/browse/LEGAL-438 > > :-) > > Kenn > > On Sun, Feb 10, 2019 at 1:06 PM Justin Mclean > wrote: > > > Hi, > > > > > It sounds like httpd has the same problem since some of these listed > > > “releases” are failed vote attempts (and so not official releases) > > > > Yep it is and to try and sort it out I’ve raised a ticket with legal. [1] > > Until that is resolved just carry on the best you can. > > > > > What are our options? > > > a) do not push git tag for RC - it’s possible to vote on a git commit > id > > > > VOTEs shod include the hash anyway as tags are mutable in git. > > > > > b) ok with RC git tag so long as they are pre-release on Github (and > > > annotated tag clearly stating not a release) and remove as soon as > > possible > > > (eg new RC, vote pass) > > > > This seem a good way of dealing with it, and they may not need to be > > removed afterwards. > > > > > c) get GitHub to fix this > > > > Other have had the same issue and asked GitHub to fit it, but they have > > not done so yet. Being the ASF we could ask nicely and they might be more > > interested in doing something about it. > > > > Thanks, > > Justin > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > -- -- Zhang Yifei
Re: Podlings not following ASF release policy
[1] https://issues.apache.org/jira/browse/LEGAL-438 :-) Kenn On Sun, Feb 10, 2019 at 1:06 PM Justin Mclean wrote: > Hi, > > > It sounds like httpd has the same problem since some of these listed > > “releases” are failed vote attempts (and so not official releases) > > Yep it is and to try and sort it out I’ve raised a ticket with legal. [1] > Until that is resolved just carry on the best you can. > > > What are our options? > > a) do not push git tag for RC - it’s possible to vote on a git commit id > > VOTEs shod include the hash anyway as tags are mutable in git. > > > b) ok with RC git tag so long as they are pre-release on Github (and > > annotated tag clearly stating not a release) and remove as soon as > possible > > (eg new RC, vote pass) > > This seem a good way of dealing with it, and they may not need to be > removed afterwards. > > > c) get GitHub to fix this > > Other have had the same issue and asked GitHub to fit it, but they have > not done so yet. Being the ASF we could ask nicely and they might be more > interested in doing something about it. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Podlings not following ASF release policy
Hi, > It sounds like httpd has the same problem since some of these listed > “releases” are failed vote attempts (and so not official releases) Yep it is and to try and sort it out I’ve raised a ticket with legal. [1] Until that is resolved just carry on the best you can. > What are our options? > a) do not push git tag for RC - it’s possible to vote on a git commit id VOTEs shod include the hash anyway as tags are mutable in git. > b) ok with RC git tag so long as they are pre-release on Github (and > annotated tag clearly stating not a release) and remove as soon as possible > (eg new RC, vote pass) This seem a good way of dealing with it, and they may not need to be removed afterwards. > c) get GitHub to fix this Other have had the same issue and asked GitHub to fit it, but they have not done so yet. Being the ASF we could ask nicely and they might be more interested in doing something about it. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings not following ASF release policy
... so I think we need to provide an option here. No question that any unauthorized release is not allowed. But what about while voting for a release? It sounds like httpd has the same problem since some of these listed “releases” are failed vote attempts (and so not official releases) >From a casual check this seems like a very common problem for many projects under github.com/apache/ as all git tags of RC show up as “release” on GitHub automatically, and there isn’t a documented way to turn off this behavior. What are our options? a) do not push git tag for RC - it’s possible to vote on a git commit id b) ok with RC git tag so long as they are pre-release on Github (and annotated tag clearly stating not a release) and remove as soon as possible (eg new RC, vote pass) c) get GitHub to fix this On Fri, Feb 8, 2019 at 11:59 PM Daniel Gruno wrote: > On 2/9/19 8:50 AM, Justin Mclean wrote: > > HI, > > > >> From what I can see with httpd, the issue is the same(?) > > > > Not quite as I not see any release candidates listed. > > ah, well, httpd doesn't do release candidates :p we tag a release, vote > on it, if it fails, you burn the version number and use a new one. so > you'll see release "candidates" but just not recognize them unless you > know which versions failed to get the proper votes. > > > > > Thanks, > > Justin > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Podlings not following ASF release policy
On 2/9/19 9:38 AM, Makoto Yui wrote: Justin, Could you please tell us what issues exist in Hivemall? I'd also be interested in knowing (you may use dev@ or private@ as you see fit) what issues exist with pony mail and release policies :) Thanks, Makoto 2019年2月9日(土) 9:51 Justin Mclean : Hi, So I just checked the next bunch of podlings to report to see if we have any other issues with ASF releases policy and sadly we do and again it larger than I expected. Some of these are minor issues and easily fixed, some are not. In a couple of cases I may not of looked deeply enough into the issue and it may actually be fine, if so apologies in advance for listing you here. In a couple of cases (e.g. Zipkin) I can see it’s been discussed on the list but there’s more to do. Podlings having one or more issues with ASF release policy include: - Crail - Daffodil - Dlab - Druid - Dubbo - Hivemall - Marvin-ai - Memo - Omid - Openwhisk - Pinot - Ponymail - Singa - Skywalking - Zipkin Projects that I will be following up with include Dlab, Druid, Dubbo, Openwhisk, Singa, Skywalking and Zipkin. If you are the mentors of these projects please take a look and see what you can do to improve the situation and educate your podling on proper release policy. If you can’t find the issue ping me and I’ll send an email with what I think it is to your private list. There is probably things I’ve missed as well, often were there’s one issue there’s others. Please include something in the next podling report on this. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings not following ASF release policy
Justin, Could you please tell us what issues exist in Hivemall? Thanks, Makoto 2019年2月9日(土) 9:51 Justin Mclean : > > Hi, > > So I just checked the next bunch of podlings to report to see if we have any > other issues with ASF releases policy and sadly we do and again it larger > than I expected. Some of these are minor issues and easily fixed, some are > not. In a couple of cases I may not of looked deeply enough into the issue > and it may actually be fine, if so apologies in advance for listing you here. > In a couple of cases (e.g. Zipkin) I can see it’s been discussed on the list > but there’s more to do. > > Podlings having one or more issues with ASF release policy include: > - Crail > - Daffodil > - Dlab > - Druid > - Dubbo > - Hivemall > - Marvin-ai > - Memo > - Omid > - Openwhisk > - Pinot > - Ponymail > - Singa > - Skywalking > - Zipkin > > Projects that I will be following up with include Dlab, Druid, Dubbo, > Openwhisk, Singa, Skywalking and Zipkin. > > If you are the mentors of these projects please take a look and see what you > can do to improve the situation and educate your podling on proper release > policy. If you can’t find the issue ping me and I’ll send an email with what > I think it is to your private list. There is probably things I’ve missed as > well, often were there’s one issue there’s others. > > Please include something in the next podling report on this. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Makoto YUI Principal Engineer, Arm Treasure Data. http://myui.github.io/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings not following ASF release policy
On 2/9/19 8:50 AM, Justin Mclean wrote: HI, From what I can see with httpd, the issue is the same(?) Not quite as I not see any release candidates listed. ah, well, httpd doesn't do release candidates :p we tag a release, vote on it, if it fails, you burn the version number and use a new one. so you'll see release "candidates" but just not recognize them unless you know which versions failed to get the proper votes. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings not following ASF release policy
HI, > From what I can see with httpd, the issue is the same(?) Not quite as I not see any release candidates listed. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings not following ASF release policy
On 2/9/19 8:37 AM, Justin Mclean wrote: Hi, IMO either way it should be ok because It’s not OK as it doesn’t agree with ASF release policy. You can’t provide release candidates to the general public and call them releases. I do see that several ASF projects seem to avoid this issue but I’m not sure how they do it. (See for instance the httpd project) [1] From what I can see with httpd, the issue is the same(?) - GitHub interprets a tag as a release at the time of tagging, not the time of releasing (github "released" 2.4.38 21 days ago, ASF released it 19 days ago). Short of going in and removing the tag, there's little we can do, it's just a bad hardcoded feature that GitHub has. Thanks, Justin 1. https://github.com/apache/httpd/releases - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings not following ASF release policy
Hi, > IMO either way it should be ok because It’s not OK as it doesn’t agree with ASF release policy. You can’t provide release candidates to the general public and call them releases. I do see that several ASF projects seem to avoid this issue but I’m not sure how they do it. (See for instance the httpd project) [1] Thanks, Justin 1. https://github.com/apache/httpd/releases - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings not following ASF release policy
Hi, > When I played around with maven-release-plugin today, I found out that > Github would automatically generate the release at " > github.com/apache/incubator-xxx/release" when we update the tag. I think > that some projects may inadvertently create a release on Github for their > release candidates. That seems problematic and may not be in line with ASF release policy. Anyone else have any suggestions? Perhaps you may mark it as a “prerelease”, that of course means actually releasing it on GitHub. :-( Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings not following ASF release policy
I’d agree- it’s a “feature” of GitHub and I didn’t see a way to turn off “turning a git tag into a release” I see that there is a API to edit a release to say it is “pre-release” https://developer.github.com/v3/repos/releases/#edit-a-release IMO either way it should be ok because a) the tag is clearly indicating *-rc0 *-rc1 and so on (if not ok, it can be set as a prerelease) b) when a new RC is being rolled, the last RC git tag can be removed (which should also eliminate the github “release”) c) when the RC becomes the official release, the git tag can be replaced and the final git tag is the release On Fri, Feb 8, 2019 at 11:14 PM Seunghyun Lee wrote: > Hi all, > > I'm Seunghyun who's working on the first Apache release for Pinot project. > > When I played around with maven-release-plugin today, I found out that > Github would automatically generate the release at " > github.com/apache/incubator-xxx/release" when we update the tag. I think > that some projects may inadvertently create a release on Github for their > release candidates. > > I'm a bit confused because we need to provide the tag as part of release > process while tagging a release candidate creates a release on Github. > > If you refer to the Gobblin's release page [1], you can observe that > release candidate was added to the release page before the official release > got updated. I have looked into Github configurations, I haven't find one > that prevents this yet. > > Best, > Seunghyun > > [1] https://github.com/apache/incubator-gobblin/releases > > > On Fri, Feb 8, 2019 at 7:57 PM Dave Fisher wrote: > > > Hi Julian, > > > > A perfect example! > > > > I think we should add a checkbox to the podling report where the podling > > indicates when they are fully in compliance with release policy. Until > that > > is done we don’t worry. > > > > Additionally, Infra could tag and “release” with appropriate description > > when they move a GitHub repository into the foundation. > > > > Regards, > > Dave > > > > Sent from my iPhone > > > > > On Feb 8, 2019, at 5:41 PM, Julian Hyde wrote: > > > > > > I’m a mentor of Druid. > > > > > > We allowed Druid to continue making releases outside of Apache during > > incubation because ASF releases were not possible. There were various > > reasons - they could not release from main line because IP transfer had > not > > been completed (if I recall correctly), and they also needed to make > > bug-fix releases of existing releases. Druid is an active project with > > large installations in production, some of them at major companies; > pausing > > releases for 6 - 9 months while transitioning into ASF would have been > > hugely damaging to the project and its community. > > > > > > The project tried to do everything by the book: they sought permission > > for releases outside of ASF, disclosed the non-ASF releases in its > reports, > > and made an official Apache release as soon as they could. If there is > > anything they could/should have done differently, let’s discuss, and > write > > down guidelines for future podlings that are in a similar situation. > > > > > > Julian > > > > > > > > > > > >> On Feb 8, 2019, at 5:16 PM, Justin Mclean > > wrote: > > >> > > >> Hi, > > >> > > >> One of the issues I’ve seen is that project continues to make releases > > in GitHub after being accepted into the incubator, in some case is this > > because the repo hasn’t been moved over yet, in other cases it’s because > > they believe that the code base is not Apache ready. What should we do in > > this situations? From what I seen it usually just delays transfer of the > > repo and encourages unapproved releases. I would would push for mentors > > speeding up that transfer rather than allowing unapproved releases. What > do > > others think? > > >> > > >> Thanks, > > >> Justin > > >> - > > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > >> For additional commands, e-mail: general-h...@incubator.apache.org > > >> > > > > > > > > > - > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > >
Re: Podlings not following ASF release policy
Hi all, I'm Seunghyun who's working on the first Apache release for Pinot project. When I played around with maven-release-plugin today, I found out that Github would automatically generate the release at " github.com/apache/incubator-xxx/release" when we update the tag. I think that some projects may inadvertently create a release on Github for their release candidates. I'm a bit confused because we need to provide the tag as part of release process while tagging a release candidate creates a release on Github. If you refer to the Gobblin's release page [1], you can observe that release candidate was added to the release page before the official release got updated. I have looked into Github configurations, I haven't find one that prevents this yet. Best, Seunghyun [1] https://github.com/apache/incubator-gobblin/releases On Fri, Feb 8, 2019 at 7:57 PM Dave Fisher wrote: > Hi Julian, > > A perfect example! > > I think we should add a checkbox to the podling report where the podling > indicates when they are fully in compliance with release policy. Until that > is done we don’t worry. > > Additionally, Infra could tag and “release” with appropriate description > when they move a GitHub repository into the foundation. > > Regards, > Dave > > Sent from my iPhone > > > On Feb 8, 2019, at 5:41 PM, Julian Hyde wrote: > > > > I’m a mentor of Druid. > > > > We allowed Druid to continue making releases outside of Apache during > incubation because ASF releases were not possible. There were various > reasons - they could not release from main line because IP transfer had not > been completed (if I recall correctly), and they also needed to make > bug-fix releases of existing releases. Druid is an active project with > large installations in production, some of them at major companies; pausing > releases for 6 - 9 months while transitioning into ASF would have been > hugely damaging to the project and its community. > > > > The project tried to do everything by the book: they sought permission > for releases outside of ASF, disclosed the non-ASF releases in its reports, > and made an official Apache release as soon as they could. If there is > anything they could/should have done differently, let’s discuss, and write > down guidelines for future podlings that are in a similar situation. > > > > Julian > > > > > > > >> On Feb 8, 2019, at 5:16 PM, Justin Mclean > wrote: > >> > >> Hi, > >> > >> One of the issues I’ve seen is that project continues to make releases > in GitHub after being accepted into the incubator, in some case is this > because the repo hasn’t been moved over yet, in other cases it’s because > they believe that the code base is not Apache ready. What should we do in > this situations? From what I seen it usually just delays transfer of the > repo and encourages unapproved releases. I would would push for mentors > speeding up that transfer rather than allowing unapproved releases. What do > others think? > >> > >> Thanks, > >> Justin > >> - > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >> For additional commands, e-mail: general-h...@incubator.apache.org > >> > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Podlings not following ASF release policy
Hi Julian, A perfect example! I think we should add a checkbox to the podling report where the podling indicates when they are fully in compliance with release policy. Until that is done we don’t worry. Additionally, Infra could tag and “release” with appropriate description when they move a GitHub repository into the foundation. Regards, Dave Sent from my iPhone > On Feb 8, 2019, at 5:41 PM, Julian Hyde wrote: > > I’m a mentor of Druid. > > We allowed Druid to continue making releases outside of Apache during > incubation because ASF releases were not possible. There were various reasons > - they could not release from main line because IP transfer had not been > completed (if I recall correctly), and they also needed to make bug-fix > releases of existing releases. Druid is an active project with large > installations in production, some of them at major companies; pausing > releases for 6 - 9 months while transitioning into ASF would have been hugely > damaging to the project and its community. > > The project tried to do everything by the book: they sought permission for > releases outside of ASF, disclosed the non-ASF releases in its reports, and > made an official Apache release as soon as they could. If there is anything > they could/should have done differently, let’s discuss, and write down > guidelines for future podlings that are in a similar situation. > > Julian > > > >> On Feb 8, 2019, at 5:16 PM, Justin Mclean wrote: >> >> Hi, >> >> One of the issues I’ve seen is that project continues to make releases in >> GitHub after being accepted into the incubator, in some case is this because >> the repo hasn’t been moved over yet, in other cases it’s because they >> believe that the code base is not Apache ready. What should we do in this >> situations? From what I seen it usually just delays transfer of the repo and >> encourages unapproved releases. I would would push for mentors speeding up >> that transfer rather than allowing unapproved releases. What do others think? >> >> Thanks, >> Justin >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings not following ASF release policy
HI, > We allowed Druid to continue making releases outside of Apache during > incubation because ASF releases were not possible. There were various reasons > - they could not release from main line because IP transfer had not been > completed (if I recall correctly), and they also needed to make bug-fix > releases of existing releases. Druid is an active project with large > installations in production, some of them at major companies; pausing > releases for 6 - 9 months while transitioning into ASF would have been hugely > damaging to the project and its community. I sympathise but it does seem it took them far too long to get out their first release, that is also damaging to the community. It's true the releases and difficulties were noted in the reports but I’m wondering this this could of been handled in another way without so many unapproved releases. There is some room for improvement for instance it’s impossible to tell what is an official release and what is not here [1], there are also release candidates listed as releases. The druid website points to directly to that page for past releases (from the versioning page). It seems release are being listed on the druid.io website [2] and the main site links to that one which seem well a bit odd. Thanks, Justin 1. https://github.com/apache/incubator-druid/releases 2. http://druid.io/downloads.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings not following ASF release policy
If we don't want the unapproved release happens in this case, I think we should asked them to give an exact date of joining the incubator. The new incubator project community should know, after the proposal accepted and with the date deadline, we don't allow to do unapproved release. And we keep this in our proposal guide document and template, also ask the new proposal make clear in their proposal. Sheng Wu Apache SkyWalking, ShardingSphere, Zipkin From Wu Sheng 's phone. -- Original -- From: Justin Mclean Date: Sat,Feb 9,2019 9:16 AM To: general Subject: Re: Podlings not following ASF release policy Hi, One of the issues I??ve seen is that project continues to make releases in GitHub after being accepted into the incubator, in some case is this because the repo hasn??t been moved over yet, in other cases it??s because they believe that the code base is not Apache ready. What should we do in this situations? From what I seen it usually just delays transfer of the repo and encourages unapproved releases. I would would push for mentors speeding up that transfer rather than allowing unapproved releases. What do others think? Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings not following ASF release policy
I’m a mentor of Druid. We allowed Druid to continue making releases outside of Apache during incubation because ASF releases were not possible. There were various reasons - they could not release from main line because IP transfer had not been completed (if I recall correctly), and they also needed to make bug-fix releases of existing releases. Druid is an active project with large installations in production, some of them at major companies; pausing releases for 6 - 9 months while transitioning into ASF would have been hugely damaging to the project and its community. The project tried to do everything by the book: they sought permission for releases outside of ASF, disclosed the non-ASF releases in its reports, and made an official Apache release as soon as they could. If there is anything they could/should have done differently, let’s discuss, and write down guidelines for future podlings that are in a similar situation. Julian > On Feb 8, 2019, at 5:16 PM, Justin Mclean wrote: > > Hi, > > One of the issues I’ve seen is that project continues to make releases in > GitHub after being accepted into the incubator, in some case is this because > the repo hasn’t been moved over yet, in other cases it’s because they believe > that the code base is not Apache ready. What should we do in this situations? > From what I seen it usually just delays transfer of the repo and encourages > unapproved releases. I would would push for mentors speeding up that transfer > rather than allowing unapproved releases. What do others think? > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings not following ASF release policy
Hi, One of the issues I’ve seen is that project continues to make releases in GitHub after being accepted into the incubator, in some case is this because the repo hasn’t been moved over yet, in other cases it’s because they believe that the code base is not Apache ready. What should we do in this situations? From what I seen it usually just delays transfer of the repo and encourages unapproved releases. I would would push for mentors speeding up that transfer rather than allowing unapproved releases. What do others think? Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
