ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ant elder <>
Subject Re: Next release
Date Wed, 30 Nov 2011 09:02:07 GMT
On Tue, Nov 29, 2011 at 4:03 PM, Karl Pauls <> 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 ( i think
>> implies it and the two emails from Roy
>> and
>> 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.


View raw message