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:18:20 GMT
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 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,
> 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.



>   ...ant
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Karl Pauls

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

View raw message