But at the end, when a podling prepare a release there should not include jar files as part of the source release artifacts to be VOTED on, is this correct?
- Henry On Thu, Dec 19, 2013 at 9:21 AM, Marvin Humphrey <mar...@rectangular.com> wrote: > On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk <tras...@stratuscom.com> wrote: >> We’re having a discussion over in d...@river.apache.org that was triggered by >> the recent discussion here about the Spark podling release. > > The River discussions seem to be playing out productively. Here are links for > other people who may be interested: > > https://issues.apache.org/jira/browse/RIVER-432 > http://markmail.org/thread/abppti56ipnhnnfy > >> To be more specific, there doesn’t seem to be any doubt that jars shouldn’t >> be included in source release packages, but would it be fair to say that >> they should also not be in the svn? > > My understanding is that it is fine to store jars in version control outside > of the main source tree, analogous to providing a separate "-deps" download. > Between that and technical solutions which download deps on the fly such as > Ivy and Maven, I think that renders the question about whether binaries can > reside in the main source tree within version control moot. > > But there's no strictly enforced policy AFAIK because we discourage people > from considering our source control repositories distribution points. (Note > to podlings: this is why we make links to source control only available > through the developer portions of our websites, etc.) That way we don't have > to be rigid about enforcing the policies which apply to releases at every > single commit point, even as we make best efforts to keep our trees clean. > > FWIW, the same principles which give us a measure of flexibility about LICENSE > and NOTICE in version control could arguably apply to jar files as well. > Here's Board member Doug Cutting back in September on legal-discuss@apache: > > http://s.apache.org/GNP > > I think perhaps you're looking for clear lines where things are > actually a bit fuzzy. Certainly releases are official distributions > and need LICENSE and NOTICE files. That line is clear. On the other > hand, we try to discourage folks from thinking that source control is > a distribution. Rather we wish it to be considered our shared > workspace, containing works in progress, not yet always ready for > distribution to folks outside the foundation. But, since we work in > public, folks from outside the foundation can see our shared workspace > and might occasionally mistake it for an official distribution. We'd > like them to still see a LICENSE and NOTICE file. So it's not a > hard-and-fast requirement that every tree that can possibly be checked > out have a LICENSE and NOTICE file at its root, but it's a good > practice for those trees that are likely to be checked out have them, > so that folks who might consume them are well informed. > > Again, policy flexibility with respect to version control becomes academic if > you can restructure the build. Nevertheless, I hope that this additional > background is helpful for River's ongoing discussions. > > Cheers, > > Marvin Humphrey > > --------------------------------------------------------------------- > 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
