calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Haisheng Yuan <hy...@apache.org>
Subject Re: [VOTE] Release apache-calcite-1.23.0 (release candidate 1)
Date Sat, 23 May 2020 15:52:11 GMT
Hi,

I had the following error when executing the command:
./gradlew publishDist -Prc=1 -Pasf

> Task :releaseRepository
Initialized stagingRepositoryId orgapachecalcite-1089 for repository nexus
<======-------> 50% EXECUTING [1m 17s]
GET request failed. 404: Not Found, body: [errors:[[id:*, msg:No such repository: orgapachecalcite-1089]]]
Requested operation was executed successfully in attempt 117 (maximum allowed 601)

> Task :createReleaseTag
Created tag calcite-1.23.0 -> Ref[refs/tags/calcite-1.23.0=7c3001d97497ca60b8e2039e8f3c96ca8672fae8(-1)]

> Task :pushReleaseTag
Pushing tag to Git remote release-origin: https://github.com/apache/calcite.git
Message from release-origin:
  refs/tags/calcite-1.23.0: OK, 7c3001d97497ca60b8e2039e8f3c96ca8672fae8 (fastForward)

BUILD SUCCESSFUL in 5m 0s
4 actionable tasks: 4 executed

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

But it said build successful. Is there anything I can do for the 404 Not Found error?

Thanks,
Haisheng


On 2020/05/22 20:37:35, Laurent Goujon <laurent@dremio.com> wrote: 
> My intent was not to cause sadness, sorry about that.
> 
> I should have elaborated a bit more why I don't think Github is that much
> of an issue:
> - LICENSE file at the root of the project is the source of truth, not
> Github mention. It is a nice to have the correct license for Github for
> sure, but it seems more important to me to have LICENSE includes the 3rd
> party dependencies present in our source tree than having the license
> displayed at the top of the github UI.
> 
> - As for the embox project you mentioned, it's probably because the license
> is short and BSD licenses have very similar texts. Here's what license says
> about the project:
> 
> $ licensee detect https://github.com/embox/embox
> License:        NOASSERTION
> Matched files:  COPYRIGHT
> COPYRIGHT:
>   Content hash:  77dc7c8c10d1ed9bc1546f2d6bba18a809e235c7
>   License:       NOASSERTION
>   Closest non-matching licenses:
>     BSD-2-Clause similarity:  89.59%
>     BSD-3-Clause similarity:  83.54%
>     BSD-4-Clause similarity:  77.82%
> 
> $ licensee license-path https://github.com/embox/embox
> COPYRIGHT
> 
> Here's now what licensee says the LICENSE file from the source distribution
> tarball:
> 
> $ licensee detect ./apache-calcite-1.23.0-src
> License:        Apache-2.0
> Matched files:  LICENSE
> LICENSE:
>   Content hash:  ab3901051663cb8ee5dea9ebdff406ad136910e3
>   Confidence:    100.00%
>   Matcher:       Licensee::Matchers::Exact
>   License:       Apache-2.0
> 
> $ licensee license-path ./apache-calcite-1.23.0-src
> /xxx/apache-calcite-1.23.0-src/LICENSE
> 
> It seems that adding several mentions at the bottom, licensee has no
> trouble identifying the apache license because the text is so large and so
> distinctive. It is corroborated by my own personal experience of checking
> license for many many dependencies and comparing between Maven pom.xml,
> github mention, and actual LICENSE/source file headers than when people are
> using ASL 2.0, even with copyright mention + extra stuff after the main
> text, Github gets it right.
> 
> On Fri, May 22, 2020 at 12:32 PM Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
> 
> > Laurent>As for Github, I think this is a non-issue
> >
> > I have provided an example: https://github.com/embox/embox
> > It is an example when GitHub fails to detect the license.
> >
> > It is really sad to hear that "you think it is a non-issue" even in case
> > you have seen the failure case.
> >
> > Laurent>on the source distribution and it has no issue identifying the
> > license.
> >
> > The license might vary over time, and it would be very bad to end up with
> > improperly detected license in GitHub.
> >
> > Vladimir
> >
> 

Mime
View raw message