incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Pauls <>
Subject Re: [VOTE] Graduate ACE from the Apache Incubator
Date Mon, 21 Nov 2011 15:38:17 GMT
On Mon, Nov 21, 2011 at 4:31 PM, Joe Schaefer <> wrote:
> I'm confused.  In /dist/incubator/ace/, there appears
> to be an *.incubator-sources.* file for each independent
> module in the release.  Are those not actually what they
> are advertised to be?  What exactly is the problem with
> the previous release?

It has been argued that they are hard to build because they don't
contain the pom files (they are in the dist dir too, but as another
download). We forgot to configure that in the build. Typically, we
make it so that the source artifacts contain the pom as well so all
you have to do is to unzip the source distro of a module, cd into it,
and mvn clean install. In this case, you have to download the pom
first as well.



>> From: Alex Karasulu <>
>>Sent: Monday, November 21, 2011 10:23 AM
>>Subject: Re: [VOTE] Graduate ACE from the Apache Incubator
>>On Mon, Nov 21, 2011 at 5:18 PM, Karl Pauls <> wrote:
>>> On Mon, Nov 21, 2011 at 4:11 PM, ant elder <> wrote:
>>> > On Mon, Nov 21, 2011 at 3:03 PM, Richard S. Hall <>
>>> wrote:
>>> >> On 11/21/11 09:41 , ant elder wrote:
>>> >>>
>>> >>> On Mon, Nov 21, 2011 at 2:18 PM, Karl Pauls<>
>>>  wrote:
>>> >>>>
>>> >>>> On Mon, Nov 21, 2011 at 3:08 PM, ant elder<>
>>>  wrote:
>>> >>>>>
>>> >>>>> Well IMHO i don't think this release demonstrates that the
>>> >>>>> has an understanding of making or reviewing ASF releases
and thats
>>> the
>>> >>>>> point of requiring releases during incubation.
>>> >>>>
>>> >>>> So you want us to do a new release? Fine, whatever, we can just
roll a
>>> >>>> new release which has the source distribution configured. That
was a
>>> >>>> mistake in the first place as it makes the bundles not easily
>>> >>>> individually buildable.
>>> >>>>
>>> >>>> However, we still will not have a combined source release as
we want
>>> >>>> to be able to release our bundles individually. Is that the
>>> >>>> then? All we have to do is a do a micro release with the source
>>> >>>> distribution configured on a per artifact level?
>>> >>>>
>>> >>> I agree the requirement for a single source release doesn't seem
>>> >>> totally clear, I've said I think you should have one and so has
>>> >>> it would be good to hear what other Incubator PMC people think.
>>> >>> think you need one for two main reasons:
>>> >>>
>>> >>> 1) The ASF deals with source and the releases are how users get
>>> >>> of that source. If a user is going to do development with the released
>>> >>> ACE source they likely aren't going to be able to do very much useful
>>> >>> with just single things like org.apache.ace.repository.imp. At the
>>> >>> very least they're probably going to want
>>> >>> org.apache.ace.repository.api too but likely there is a big network
>>> >>> the 60 something ACE modules that anyone doing most non-trivial
>>> >>> development is going to want. One source distribution makes this
>>> >>> making them have to download them all separately isn't particularly
>>> >>> practical. That
>>> >>> is structured so the ASF committers can work with them as one single
>>> >>> buildable checkout i think shows thats true.
>>> >>>
>>> >>> 2) If there is only individually buildable source for each jar how
>>> >>> people really going to verify that the release is actually buildable
>>> >>> and the artifacts match the SVN tag source when reviewing and voting
>>> >>> on release votes? No one reviewing is really likely to download
>>> >>> separate distros and build them all one by one are they?
>>> >>
>>> >> I disagree. There seems to be some misunderstanding that there is one
>>> single
>>> >> product that must be built.
>>> >>
>>> >> When you develop independently evolving modules, "big bang" releases
>>> not
>>> >> make sense. Each module has its own release cycle. Occasionally you
>>> end
>>> >> up creating some sort of "distribution" out of the modules and release
>>> that,
>>> >> but that is just one potential distribution.
>>> >>
>>> >
>>> > I agree thats an approach used and works in many projects but if that
>>> > was really the case _here_  then surely the SVN would be structured so
>>> > that there were separate trunk/branch/tag folders for each module,
>>> > there would have been more releases than just the single 0.8.0
>>> > release, and there would be separate release votes for each module
>>> > being released.
>>> We have a tag per module and that is enough. Furthermore, we do
>>> combine several modules if it makes sense (i.e., we want to release
>>> them at the same time) in one vote as it would otherwise create a lot
>>> of extra traffic. That's all. It is the same set-up some of the other
>>> OSGi projects at the asf have (I did quite a lot of their releases).
>>> The only thing we missed was the source distributions per artifact.
>>And that IMHO is not enough to consider the release a failure. Let it be
>>noted and corrected for future releases. AFAIC there's no reason to hold
>>this podling back because of some minor release inconsistencies which are
>>natural as we shift from monolithic products to component based OSGi

Karl Pauls

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

View raw message