Let’s not have a discussion on the vote thread. Feel free to start a new thread, or continue an existing discussion thread.
To re-state the rules. Every PMC member has a binding vote. The vote passes if the number of +1 votes exceeds the number of -1 votes by 3 or more. Vladimir is entitled to his vote. Julian > On May 13, 2021, at 5:19 AM, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> > wrote: > >> I can definitely see the utility of the gradle wrapper and was pretty >> disappointed that it had to be removed > > It would be great if you add a comment to 570 on how the wrapper was useful > for you. > So far the case sounds like "compiled code is forbidden no matter what" and > "Vladimir is the only one who needs gradle-wrapper.jar". > I do not want to go in circles there, however, having more voices would > help. > >> I feel it's more >> productive to be pragmatic and pick our battles. > > Exactly. The case is closed, the compiled code is forbidden, > so let us just remove compiled code from source releases and move on. > >> the discussion in LEGAL-570 [1], suggests that images, PDFs and >> minified javascript is allowed > > AFAIK, the LEGAL team is Justin Mclean and Roman Shaposhnik. > I do not see where they suggest that minified javascript is allowed in > source releases. > >> Was the licenses folder >> introduced when we moved to gradle? > > Exactly. License cleanup was one of the key improvements when I reworked > the build to Gradle. > For instance, the current build generates the proper license for **shaded** > artifacts, and > it bundles the relevant licensees inside the combined jar. > >> How does the community feel about >> committing the license folder into git? > > I would be -0.99 for updating the licenses manually. > They would go out of date as soon as the first dependency update is made. > > It would be nice if someone comes up with an automatic update of the files. > For example, the generated license files might be stored under the > relevant folders (e.g. /src/test/resources/license/..., > /shaded/core/test/resources/license/...), > then the build would fail if the expected license outcome does not match > the actual one. > > What I do not like with putting "license with all the details to the root > folder" the most is that > Calcite release consists of **multiple** artifacts, and they might have > different license files, > so I do not understand which of them is supposed to be "the right one for > putting in git root". > > Vladimir
