Re: Question about jar files in svn.
On 23 December 2013 05:50, David Crossley cross...@apache.org wrote: Marvin Humphrey wrote: Greg Trasuk wrote: Thanks everyone for the input. To summarize, it appears that the consensus argument is: - Jar files are not prohibited by policy in project repositories (svn), although they may not make a lot of sense. - Source distributions must not distribute executable code in binary form. i.e. Don’t ship dependency jars in the source archive. However it may be acceptable to include things like jar files that are processed during testing (sample archives, for instance). - The project repositories are not generally considered “distributions”, but we need to be a little careful to avoid users’ confusion on this point. Regarding that last part, i reckon that is about: only referring the development community to the development resources and not instructing users to do that. However, many projects refer to SCM repos on public pages, some even on the download page. Also, projects that use Maven will have the SCM URLs in the POM. Maven generated sites will have the Source Repo as part of the standard documentation. Such projects should ensure that the SCM has appropriate NL files at the top level. Note also that Roy [1] at least considers that SCM should be classed as a distribution. See also [2] and [3] [1] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200907.mbox/%3C7A0220B7-5DF1-4F4C-8C27-6CA8A175CFCD%40gbiv.com%3E [2] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200907.mbox/%3C1706952606.1247865134823.JavaMail.jira%40brutus%3E [3] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200907.mbox/%3C1809771433.1247865614827.JavaMail.jira%40brutus%3E -David - 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
Re: Question about jar files in svn.
On Fri, Dec 20, 2013 at 8:49 AM, Greg Trasuk tras...@stratuscom.com wrote: Thanks everyone for the input. To summarize, it appears that the consensus argument is: - Jar files are not prohibited by policy in project repositories (svn), although they may not make a lot of sense. - Source distributions must not distribute executable code in binary form. i.e. Don’t ship dependency jars in the source archive. However it may be acceptable to include things like jar files that are processed during testing (sample archives, for instance). - The project repositories are not generally considered “distributions”, but we need to be a little careful to avoid users’ confusion on this point. And just to be clear, I take this as valuable input from from the experts at Incubator, not a ruling. Obviously, the River PMC makes decisions for River, and Incubator bears no responsibility for anything we might get wrong. +1 to your perfect, meticulously composed summary. I'd also like to respond to something you wrote in a post to dev@river: http://s.apache.org/tn First, though I’m going through the archives on legal-discuss@ to see if there’s already been a discussion. As with many things, there seems to be much opinion, but little policy. As someone who became an ASF Member relatively recently (2011), I am often struck by how much collective knowledge from the early years of Apache is missing from our current documentation. Some issues seem to have been considered common sense but have turned out not to be. Other issues have achieved consensus resolutions at one time but the consensus was never captured in policy documentation and distortions have since propagated. I think it's up to us more recent arrivals, not yet afflicted by the curse of knowledge, to identify the weaknesses and take the lead on getting them addressed. It's gratifying that we arrived at a common understanding so quickly in this thread; I hope that we get the chance to work together again. Best, Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about jar files in svn.
Marvin Humphrey wrote: Greg Trasuk wrote: Thanks everyone for the input. To summarize, it appears that the consensus argument is: - Jar files are not prohibited by policy in project repositories (svn), although they may not make a lot of sense. - Source distributions must not distribute executable code in binary form. i.e. Don’t ship dependency jars in the source archive. However it may be acceptable to include things like jar files that are processed during testing (sample archives, for instance). - The project repositories are not generally considered “distributions”, but we need to be a little careful to avoid users’ confusion on this point. Regarding that last part, i reckon that is about: only referring the development community to the development resources and not instructing users to do that. -David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about jar files in svn.
Thanks everyone for the input. To summarize, it appears that the consensus argument is: - Jar files are not prohibited by policy in project repositories (svn), although they may not make a lot of sense. - Source distributions must not distribute executable code in binary form. i.e. Don’t ship dependency jars in the source archive. However it may be acceptable to include things like jar files that are processed during testing (sample archives, for instance). - The project repositories are not generally considered “distributions”, but we need to be a little careful to avoid users’ confusion on this point. And just to be clear, I take this as valuable input from from the experts at Incubator, not a ruling. Obviously, the River PMC makes decisions for River, and Incubator bears no responsibility for anything we might get wrong. Cheers, Greg Trasuk PMC Chair, Apache River. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about jar files in svn.
I am not an expert, we only graduated a year ago. But I think there are two rules in here: 1) Source archive must not contain compiled source code that is part of the product's functionality. There is leeway on compiled source code processed during testing. I think the board may pull your release off the distribution server if they find out you have not followed this rule. 2) Your distribution point for the release must be from the distribution server AND its mirrors (and I think, Maven Repos). I'm pretty sure you will be required to rewrite website and any other public information that tells folks anything else. While I think the rest is just guidance, IIRC from our incubator mentors and various email threads, the goal of managing information in SVN/Git repos is to enable folks who do pull stuff from those repos to understand the IP ownership of the files and also know that the stuff isn't a trojan horse containing viruses. As PMC members we have a responsibility to the ASF to make sure we don't make mistakes there, so common practices like a deps folder help eliminate mistakes. I think for Apache Flex, we don't store any compiled code in the main repos, if anywhere. I've been told that for some projects, making a release is as simple as zipping an svn export, so you might actually save time by not having binaries in the repo. -Alex On 12/20/13 8:49 AM, Greg Trasuk tras...@stratuscom.com wrote: Thanks everyone for the input. To summarize, it appears that the consensus argument is: - Jar files are not prohibited by policy in project repositories (svn), although they may not make a lot of sense. - Source distributions must not distribute executable code in binary form. i.e. Don¹t ship dependency jars in the source archive. However it may be acceptable to include things like jar files that are processed during testing (sample archives, for instance). - The project repositories are not generally considered ³distributions², but we need to be a little careful to avoid users¹ confusion on this point. And just to be clear, I take this as valuable input from from the experts at Incubator, not a ruling. Obviously, the River PMC makes decisions for River, and Incubator bears no responsibility for anything we might get wrong. Cheers, Greg Trasuk PMC Chair, Apache River. - 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
Re: Question about jar files in svn.
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
Re: Question about jar files in svn.
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
Re: Question about jar files in svn.
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
Re: Question about jar files in svn.
Ah I see. So the point of concern is the external jars, but jars that are generated by the project itself (for example for tests) should be fine? - Henry On Thu, Dec 19, 2013 at 10:34 AM, sebb seb...@gmail.com wrote: 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about jar files in svn.
My understanding of the link I posted way back is that the source package cannot contain compiled output that will be executed by the customer. IMO, whether it is external or not doesn't matter. The JAR used by the Compress tests is hopefully just data, not some part of its functionality. On 12/19/13 10:40 AM, Henry Saputra henry.sapu...@gmail.com wrote: Ah I see. So the point of concern is the external jars, but jars that are generated by the project itself (for example for tests) should be fine? - Henry On Thu, Dec 19, 2013 at 10:34 AM, sebb seb...@gmail.com wrote: 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about jar files in svn.
On 19 December 2013 18:57, Alex Harui aha...@adobe.com wrote: My understanding of the link I posted way back is that the source package cannot contain compiled output that will be executed by the customer. IMO, whether it is external or not doesn't matter. The JAR used by the Compress tests is hopefully just data, not some part of its functionality. Yes, the jars are test data. On 12/19/13 10:40 AM, Henry Saputra henry.sapu...@gmail.com wrote: Ah I see. So the point of concern is the external jars, but jars that are generated by the project itself (for example for tests) should be fine? Again, that's ambiguous. I would not expect to find jars of the project source in source releases. Note that the Compress test jars were manually created on various different systems. - Henry On Thu, Dec 19, 2013 at 10:34 AM, sebb seb...@gmail.com wrote: 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:
Re: Question about jar files in svn.
On Thu, Dec 19, 2013 at 10:40 AM, Henry Saputra henry.sapu...@gmail.com wrote: So the point of concern is the external jars, but jars that are generated by the project itself (for example for tests) should be fine? One main concern is oversight for what goes into an an Apache release. It's not realistic to perform a line-by-line review for all source code in a release candidate, but if we trust our version control and our commit notification systems, we can have confidence that the what goes into a release has been reviewed over time by the PMC. Checking that the expanded content of the source archive matches an export from a version control tag is a useful (albeit not universally appropriate) way of verifying that the release is what it says it is. A compiled binary, on the other hand, is an opaque product of source code plus build environment. It can't be reviewed, and the build machine is potentially a target for crackers. Hence, these quotes from Roy: http://s.apache.org/roy-binary-deps-2 I consider them to be trojan horses. I wouldn't hesitate for a second to delete them outright. Actually, what I've done in the past (yes, I have done this before) is move them to a subdir of my homedir and then tell the relevant project to WTFU and do it right. Note, however, I would not delete the ones in archive -- that would be silly. http://s.apache.org/roy-binary-deps-3 People have to understand this. There will always be a role for downstream commercial or non-commercial redistributions of Apache products. Why? Because the ASF is incapable of taking on the enormous liability associated with released binaries that are not produced in a controlled environment with a controlled set of tools. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about jar files in svn.
No policy says anything about binaries in svn, but if you can't have them in your source package it probably doesn't make much sense to keep them in svn. But really that part is up to the project not the IPMC. Sent from my iPhone On Dec 18, 2013, at 10:45 PM, Greg Trasuk tras...@stratuscom.com wrote: Hi all: We’re having a discussion over in d...@river.apache.org that was triggered by the recent discussion here about the Spark podling release. In particular, http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3CCAAS6%3D7iQSKTgNdO-0Qyd3T9--%2B%2BHQFEmhJi7CHoByqvQvp9_bg%40mail.gmail.com%3E has caused me to start asking questions… Since Incubator is a good repository of Apache’s institutional knowledge, I wonder if someone could point me towards resources that clarify the policy on dependency jars in releases and in the svn repository. If I understand it correctly, there shouldn’t (perhaps even must not be) any jar files checked into subversion or included in a source release. Is that correct? 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? Thanks in advance, Greg Trasuk PMC Chair, Apache River. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about jar files in svn.
Some example of projects that have them in both the repo and source dist is Apache Cassandra or Apache OpenOffice -Jake On Wed, Dec 18, 2013 at 11:01 PM, Joseph Schaefer joe_schae...@yahoo.comwrote: No policy says anything about binaries in svn, but if you can't have them in your source package it probably doesn't make much sense to keep them in svn. But really that part is up to the project not the IPMC. Sent from my iPhone On Dec 18, 2013, at 10:45 PM, Greg Trasuk tras...@stratuscom.com wrote: Hi all: We’re having a discussion over in d...@river.apache.org that was triggered by the recent discussion here about the Spark podling release. In particular, http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3CCAAS6%3D7iQSKTgNdO-0Qyd3T9--%2B%2BHQFEmhJi7CHoByqvQvp9_bg%40mail.gmail.com%3E has caused me to start asking questions… Since Incubator is a good repository of Apache’s institutional knowledge, I wonder if someone could point me towards resources that clarify the policy on dependency jars in releases and in the svn repository. If I understand it correctly, there shouldn’t (perhaps even must not be) any jar files checked into subversion or included in a source release. Is that correct? 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? Thanks in advance, Greg Trasuk PMC Chair, Apache River. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
