incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <>
Subject Re: [VOTE] Graduate ACE from the Apache Incubator
Date Mon, 21 Nov 2011 15:17:52 GMT
On 11/21/11 10:11 , 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<>   
>>>>> Well IMHO i don't think this release demonstrates that the poddling
>>>>> 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 resolution
>>>> 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 sebb,
>>> it would be good to hear what other Incubator PMC people think. I
>>> think you need one for two main reasons:
>>> 1) The ASF deals with source and the releases are how users get hold
>>> 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 of
>>> the 60 something ACE modules that anyone doing most non-trivial ACE
>>> development is going to want. One source distribution makes this easy,
>>> 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 are
>>> 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 60
>>> 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 do not
>> make sense. Each module has its own release cycle. Occasionally you may 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,

Why do we need separate trunk/branch/tag folders for each module? We 
don't do it that way in Felix either. I don't see anything magical about 
having separate folders for each. Are you purely worried about the 
overhead of looking through a long directory listing?

-> richard

> 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.
>     ...ant
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message