I agree with Jeff. The inclusion of binary dependencies to assist developers building from a source release doesn't seem like a deal breaker to me personally as long as these are purely a convenience and not a requirement. That said, the stance of the ASF as recorded in the incubator thread is pretty clear, so I also will not vote to approve future releases containing binary artifacts. However, I don't think that removing any previous releases should even be up for debate. In fact, Roy dismisses this idea himself in the same thread[1]. So it seems that only releases currently being served from dist.apache.org need to be fixed. With the 2.1 and 2.2 lines due for imminent EOL, it seems that once CASSANDRA-16391 lands in 3.0, 3.11 and trunk we could cut new, compliant releases and be done.
As others have mentioned, relying on knowledge of a specific mail thread as the ultimate lsource of truth is somewhat arcane, so I'm glad that the discussion on legal-discuss is happening and that proposals to clarify the policy documentation are afoot. [1] https://lists.apache.org/thread.html/c4b374ccd80f0440746dae343b62c3ba6c73e2531e275ca1e194e335%401332935970%40%3Cgeneral.incubator.apache.org%3E > On 30 Mar 2021, at 03:58, Jeff Jirsa <jji...@gmail.com> wrote: > > On Mon, Mar 29, 2021 at 3:45 PM Justin Mclean <jmcl...@apache.org> wrote: > >> >> It good to see you are taking action, but I think the situation is a >> little more seriously that you may realise, I suggest you look at what >> actions the board has taken in similar situations in the past. I'll update >> the board agenda item to reflect the current situation. >> >> > The thread linked earlier is worth reading for sure. Again, > https://lists.apache.org/thread.html/f8022be5a02c6f020aac635193e729a0f73376164cea7c38474c3dc0%401332948346%40%3Cgeneral.incubator.apache.org%3E > > As an ASF member and a member of the Cassandra PMC, it's pretty clear what > Roy's position was in 2012. > > My personal, emotional response is in line with what Rob Weir said in > 2012: "The issue should be lack of source code, not presence of binary > code." > > If someone asked me what's included in a source release, without reading > ANY doc or policy, I'd expect there to be the complete, unabridged source > of the project, and enough context to build it. That's what Cassandra has > today. The extra binaries are just that - extra. They come with no burden. > They come with no obligation to use. They come with no penalty. The source > for which the PMC is responsible is published, and that feels far more > important to me than the absence of binary code that's trivial to remove. > > Roy's response in the 2012 thread, though, is unambiguous: he strongly > believes, clearly with authority in 2012, that the presence of ANY binary > file violates the spirit of a source release. That feels quite extreme to > me, though this line is probably nuanced enough to inspire a book on trust: > > "One cannot vote to approve a release containing a mix of source and binary > code because the binary is not open source and cannot be verified to be > safe for release (even if it was derived from open source)." > > Based on this point, I personally won't vote to approve a future release > with binary packages, but I also strongly disagree with the assertion in > that same past thread that it's worth nuking a 10+year history of releases. > That's the type of action that would severely diminish trust in the > foundation. > > We SHOULD look at what's required to rebuild PAST releases. We should also > admit that people are human and be reasonable along the way. Community over > code and all that. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
