On 19 December 2013 18:26, Henry Saputra <henry.sapu...@gmail.com> wrote: > 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?
I think that depends on what the jar files are. For example. Apache Commons Compress includes some jar files in SVN and the source release as part of the test data. But I would not expect to find "external" jar files in the source release. > - 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
