Shipping tests is not a formal requirement of a release.
httpd certainly doesn't offer its test suite as part of
a release- you have to download that (from svn) yourself.
----- Original Message -----
> From: sebb <seb...@gmail.com>
> To: general@incubator.apache.org; Joe Schaefer <joe_schae...@yahoo.com>
> Cc:
> Sent: Monday, November 21, 2011 10:59 AM
> Subject: Re: Fw: [VOTE] Graduate ACE from the Apache Incubator
>
> On 21 November 2011 15:48, Joe Schaefer <joe_schae...@yahoo.com> wrote:
>>
>>
>>
>>
>> ----- Forwarded Message -----
>>> From: Joe Schaefer <joe_schae...@yahoo.com>
>>> To: Karl Pauls <karlpa...@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.)
>
> That is the case for the JUnit tests, which are not included in the
> source jars as far as I can tell.
>
>>>
>>> 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 <karlpa...@gmail.com>
>>>> To: general@incubator.apache.org; Joe Schaefer
> <joe_schae...@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_schae...@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 <akaras...@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
> <karlpa...@gmail.com> wrote:
>>>>>>
>>>>>>> On Mon, Nov 21, 2011 at 4:11 PM, ant elder
> <ant.el...@gmail.com> wrote:
>>>>>>> > On Mon, Nov 21, 2011 at 3:03 PM, Richard S. Hall
> <he...@ungoverned.org>
>>>>>>> wrote:
>>>>>>> >> On 11/21/11 09:41 , ant elder wrote:
>>>>>>> >>>
>>>>>>> >>> On Mon, Nov 21, 2011 at 2:18 PM, Karl
> Pauls<karlpa...@gmail.com>
>>>>>>> wrote:
>>>>>>> >>>>
>>>>>>> >>>> On Mon, Nov 21, 2011 at 3:08 PM, ant
> elder<antel...@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
>>>> karlpa...@gmail.com
>>>> http://twitter.com/karlpauls
>>>> http://www.linkedin.com/in/karlpauls
>>>> https://profiles.google.com/karlpauls
>>>>
>>>>
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
