incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe_schae...@yahoo.com>
Subject Fw: [VOTE] Graduate ACE from the Apache Incubator
Date Mon, 21 Nov 2011 15:48:59 GMT




----- Forwarded Message -----
>From: Joe Schaefer <joe_schaefer@yahoo.com>
>To: Karl Pauls <karlpauls@gmail.com>; "general@incubator.apache.org" <general@incubator.apache.org>

>Sent: Monday, November 21, 2011 10:44 AM
>Subject: Re: [VOTE] Graduate ACE from the Apache Incubator
> 
>
>"Hard to build" isn't a blocking criterion
>for a release; so long as the artifacts can
>be built from the distributed source files
>using a repeatable and documented process you
>are ok in my book.  Downloading a pom from
>an ASF mirror or from maven central doesn't
>appearon the surface to be contradicting
>what Iwrote in the first sentence here.
>
>("Downloading" from svn.a.o would be a problem
>tho.)
>
>In any case, if you can make building from
>source more convenient for end-users, that
>would certainly count as an improvement.
>But holding up graduation until that is 
>
>actually done makes zero sense to me.
>
>
>
>
>
>
>>________________________________
>> From: Karl Pauls <karlpauls@gmail.com>
>>To: general@incubator.apache.org; Joe Schaefer <joe_schaefer@yahoo.com> 
>>Sent: Monday, November 21, 2011 10:38 AM
>>Subject: Re: [VOTE] Graduate ACE from the Apache Incubator
>> 
>>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.
>>
>>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


Mime
View raw message