Gosh. Well perhaps its me that needs to go back to school then. But i
find this most unexpected. The ASF FAQ on what is a release says "All
releases are in the form of the source materials needed to make
changes to the software being released." if no unit tests are included
in the source release can anyone seriously be expected to be able to
make non-trivial changes to the source? I now wonder what is the point
of the source release at all, other than IDE debugging or reading
APIs, for real development you'd ave to get the SVN tag. And there is
the how to vote on the release artifacts too, other than checking
theres no compile errors how do release reviewers know the release is
good, or with 60 something modules to manually build is there really
any expectation that anyone other than the RM even attempts a build?
...ant
On Mon, Nov 21, 2011 at 4:02 PM, Joe Schaefer <joe_schae...@yahoo.com> wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
