On 21 November 2011 15:38, Karl Pauls <karlpa...@gmail.com> wrote: > 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.
... and rename it. Also the jars also don't include any unit tests. > 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
