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?
>________________________________ > 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 > > >
