incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Saputra <>
Subject Re: Question about jar files in svn.
Date Thu, 19 Dec 2013 18:26:08 GMT
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 <> wrote:
> On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk <> wrote:
>> We’re having a discussion over in 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:
>> 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:
>     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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message