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
