incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [VOTE] Graduate ACE from the Apache Incubator
Date Mon, 21 Nov 2011 15:59:21 GMT
On 21 November 2011 15:38, Karl Pauls <karlpauls@gmail.com> wrote:
> On Mon, Nov 21, 2011 at 4:31 PM, Joe Schaefer <joe_schaefer@yahoo.com> 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.

... and rename it.

Also the jars also don't include any unit tests.

> regards,
>
> Karl
>
>>
>>>________________________________
>>> From: Alex Karasulu <akarasulu@apache.org>
>>>To: general@incubator.apache.org
>>>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 <karlpauls@gmail.com> wrote:
>>>
>>>> On Mon, Nov 21, 2011 at 4:11 PM, ant elder <ant.elder@gmail.com> wrote:
>>>> > On Mon, Nov 21, 2011 at 3:03 PM, Richard S. Hall <heavy@ungoverned.org>
>>>> wrote:
>>>> >> On 11/21/11 09:41 , ant elder wrote:
>>>> >>>
>>>> >>> On Mon, Nov 21, 2011 at 2:18 PM, Karl Pauls<karlpauls@gmail.com>
>>>>  wrote:
>>>> >>>>
>>>> >>>> On Mon, Nov 21, 2011 at 3:08 PM, ant elder<antelder@apache.org>
>>>>  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 https://svn.apache.org/repos/asf/incubator/ace/trunk/
>>>> >>> 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.
>>>>
>>>>
>>>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
>>>products.
>>>
>>>Best,
>>>Alex
>>>
>>>
>>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message