Does it help, that I wrote that file and submitted it in a pull request to eliminate the binary jar needed prior to my change? ... Guess that's also an additional reason why there's an Apache header on it :-)
Outlook für Android<https://aka.ms/ghei36> herunterladen ________________________________ From: Mick Semb Wever <m...@apache.org> Sent: Thursday, February 14, 2019 7:05:02 AM To: general@incubator.apache.org Subject: Re: the case of the maven wrapper > As binaries are not allowed in source repos, the maven wrapper > introduces a small java source file which bootstraps the tool. This > has Apache license headers on it. Takari is an Apache licensed codebase. My understanding is that there is a requirement to include it in the NOTICE.txt file. Furthermore, Takari contains no copyright. Is this of concern? http://www.apache.org/dev/licensing-howto.html https://www.apache.org/legal/src-headers.html > As a part of Zipkin's first attempt to vote a release on the general > list … asking for it to be in the NOTICE box. One of the tings I've noticed is that the vetos on a podling's first release can be a bit harsh. I do really love the "community over code" motto, and i would hope to see the incubator being a leader in displaying the warmth and inclusion that leads to a healthy and enjoyable community. On releases I would rather see such vetos replaced with comments that are feedback, while still obvious that they are an issue that is expected to be fixed by the next release (and before graduation). I think this would be warmer feedback, and permit a more incremental approach to getting to the standard of release required for graduation. Momentum and results is an important motivator, and there's a lot to learn about the ASF requirements on the podling's journey to graduation. > It feels we are just > adding things to it and as an end user, I'm not sure how this would > add clarity. An apache release is first aimed at someone who builds the source artefact. Even if this isn't the popular use-case. This also highlights the value in having the takari wrapper in place. > Even if it did, I'm concerned that we are jumping to a > enforcement remediation when no-one seems to be doing it at all. I've seen this unfairness bite a bit already. Feedback that the incubator provides to podlings should be in context of the broader precedence in the ASF. If it's something that's not being strictly adhered to by graduate projects, it would make a world of difference to podlings if they saw everyone was getting pulled up on the violation. Otherwise it comes across as podlings are required to meet a standard well above the graduate projects, and that becomes a real deterrence for many to entering Apache. This would add some burden to the Incubator. Surveys of graduate projects would be required to see such precedence on issues. And resulting feedback to graduate projects can also be tricky, nobody likes to feel that they are being picked on. IDK, but maybe this feedback can go to the board, and the board can pick one issue per quarter and request projects address them by their next board report. regards, Mick --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
