On Tue, Nov 29, 2011 at 4:03 PM, Karl Pauls <karlpa...@gmail.com> wrote: >> There are two issues here about ASF policy: one is if its required to >> have a source release that is suitable for what has been described in >> this thread as "full development", > > If downloading a bunch of zips, unzipping them, and doing a "mvn -r > clean install" is too much work for "full development" then i don't > know. Granted, it sucks that maven 3 doesn't have the -r option > anymore but at least other IDE's allow to import our artifacts without > problems (as they update their reactor dynamically). Might not be the > case for eclipse, i don't know. > >> and the other is if when voting +1 on a release you should have verify that >> the source artifacts are >> good. What i think people here are suggesting is that you don't need a >> source release for "full development" as anyone wanting to do that >> will get the source from SVN, and that its fine to have 50 or 60 >> artifacts in a single vote because you'll do things like have a script >> to help building them. > > Well, what we can do is to provide this "script" at release build time > i.e., we create a maven project that assembles all source-releases and > provides a pom.xml that builds them all. Not really different IMO but > if that enables people to work on ace - I'm happy to help out. > >> I accept the documented ASF policy is not totally clear about this, >> the release FAQ (http://www.apache.org/dev/release.html) i think >> implies it and the two emails from Roy >> http://apache.markmail.org/message/3odlybipss4wnczl and >> http://apache.markmail.org/message/njray5dbazwcdcts are quite clear >> about what he thinks, > > Yes, and I agree with him. We need high quality releases and that > implies they can be build. As I said, it sucks that we didn't include > the source-release.zips. > >> but he doesn't make policy by himself. > > I agree with him. > > We want to provide our subprojects as independently released modules. > This implies that they get their own tag (that is independent from the > rest of trunk), their own download-able source (that must be > build-able as is), and version number. Nothing in this view conflicts > with what Roy mandates. Requirements along the lines of must work with > my IDE/toolchain, can't be to many artifacts, etc. are not at issue. I > fail to see where Roy worries about the reviewers - he requires review > but not that it is easy. > >> So if you really really don't want to change > > I think we can change a little. As I say above, we will provide an > artifact that contains all other artifacts source-releases and a > reactor pom (inside this artifact) that builds them all. This will be > somewhat similar to what sling provided but doesn't use svn:externals. > The downside is that this adds yet another artifact that requires > review but, if reviewed that it will do its work correctly, one can > use it to build and work with all released modules in one go. > >> then just try to graduate and see >> what happens, the worst that can happen is you'll be sent back to >> change. Be clear thats what you're doing in the graduation vote on >> general@ and then if the graduation succeeds this will have set the >> precedent that clarifies things for everyone else in the future. > > No. I don't think we want to battle this out via a graduation vote. It > sucks already that this pops up during graduation. Personally, I was > under the impression that one of the core values of the incubator is > to teach the Apache Way and that includes that we try to find > consensus. Battling things out in votes I don't like if I can help it. >
This wasn't about battling things out with a vote it was about having the board decision clarify what the policy actually is. > We will call a new vote on a new release which we think is correct and > according to our standards. It'll have the source-releases and one of > the artifacts will be the combined source release I was talking about. > Then we are going to ask the incubator PMC to approve it and that is > the vote where we going to set the precedent. Hopefully, you like the > approach enough to give us your +1 but if not, we'll have to see what > others think. However, I think what we'll have now is a proper Apache > multi-module release (obviously, pending other glitches). > Well terrific, that sounds like it has everything that was being asked for. ...ant
