That's really a good question. I'm using apache projects a lot but I've
never downloaded a single source release since ages, mostly using svn to
checkout / build, or maven source jars for debugging within the ide as you
said.
I know it's a requirement, but it's not very useful for certain kind of
projects imho..
On Mon, Nov 21, 2011 at 18:11, ant elder <ant.el...@gmail.com> wrote:
> 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
>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
