ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Pauls <>
Subject Re: Next release
Date Tue, 29 Nov 2011 16:03:11 GMT
> 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.

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).



>   ...ant

Karl Pauls

View raw message