You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Greg Trasuk <tr...@stratuscom.com> on 2013/12/19 04:45:03 UTC
Question about jar files in svn.
Hi all:
We’re having a discussion over in dev@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.
Re: Question about jar files in svn.
Posted by Alex Harui <ah...@adobe.com>.
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" <tr...@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-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about jar files in svn.
Posted by sebb <se...@gmail.com>.
On 23 December 2013 05:50, David Crossley <cr...@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 N&L 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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about jar files in svn.
Posted by David Crossley <cr...@apache.org>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about jar files in svn.
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Dec 20, 2013 at 8:49 AM, Greg Trasuk <tr...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about jar files in svn.
Posted by Greg Trasuk <tr...@stratuscom.com>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about jar files in svn.
Posted by sebb <se...@gmail.com>.
On 19 December 2013 18:57, Alex Harui <ah...@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" <he...@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 <se...@gmail.com> wrote:
>>> On 19 December 2013 18:26, Henry Saputra <he...@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
>>>><ma...@rectangular.com> wrote:
>>>>> On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk <tr...@stratuscom.com>
>>>>>wrote:
>>>>>> We¹re having a discussion over in dev@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-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about jar files in svn.
Posted by Alex Harui <ah...@adobe.com>.
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" <he...@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 <se...@gmail.com> wrote:
>> On 19 December 2013 18:26, Henry Saputra <he...@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
>>><ma...@rectangular.com> wrote:
>>>> On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk <tr...@stratuscom.com>
>>>>wrote:
>>>>> We¹re having a discussion over in dev@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-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about jar files in svn.
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, Dec 19, 2013 at 10:40 AM, Henry Saputra <he...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about jar files in svn.
Posted by Henry Saputra <he...@gmail.com>.
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 <se...@gmail.com> wrote:
> On 19 December 2013 18:26, Henry Saputra <he...@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 <ma...@rectangular.com> wrote:
>>> On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>>>> We’re having a discussion over in dev@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-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about jar files in svn.
Posted by sebb <se...@gmail.com>.
On 19 December 2013 18:26, Henry Saputra <he...@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 <ma...@rectangular.com> wrote:
>> On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>>> We’re having a discussion over in dev@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-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about jar files in svn.
Posted by Henry Saputra <he...@gmail.com>.
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 <ma...@rectangular.com> wrote:
> On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>> We’re having a discussion over in dev@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about jar files in svn.
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk <tr...@stratuscom.com> wrote:
> We’re having a discussion over in dev@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Question about jar files in svn.
Posted by Jake Farrell <jf...@apache.org>.
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 <jo...@yahoo.com>wrote:
> 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 <tr...@stratuscom.com>
> wrote:
> >
> >
> > Hi all:
> >
> > We’re having a discussion over in dev@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Question about jar files in svn.
Posted by Joseph Schaefer <jo...@yahoo.com>.
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 <tr...@stratuscom.com> wrote:
>
>
> Hi all:
>
> We’re having a discussion over in dev@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org