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
