Thilo Goetz wrote: > Hi Marshall, > > as usual, my view is pretty much the exact opposite ;-) > > First of all, I don't see the sense in creating yet another > category. To my mind, there's nothing wrong with having > mature components in the sandbox. The only thing I would > consider is to move some sandbox components that are really > important to people into the core. > I think people might feel that the sandbox isn't a place to get production-quality things, and I was hoping that some of these components were production-quality :-) > Also, at least while we're still in the incubator, I really > don't think individual releases for sandbox components are > manageable (unless I hear people volunteer to be release > managers for these things). > You have a point - I think this could also be an issue even outside the incubator. > Also from a user perspective, I prefer a single download > with everything in it. When I look at a new software and > go through the tutorial, I hate it when I have to get > components A, B, and C to do the first chapter, and then > for the next one, I need to get D and E, and so on. A > couple of megabytes of download is insignificant these > days, and then you have everything on disc and can pick > and choose what you need. > I agree if it's small, it's not worth making a fuss. If the components start to have more of a life of their own (consider, for instance, the CLI component of the Commons project - it's used in many things) - people will want to clearly see for each component what the license / notification issues are, so they can re-package them. To me, this tilts a bit toward wanting individual downloads.
But I'm not against bundles for those that want them. And I agree - it's extra work to do all this fancy packaging - so I was thinking idealistically, hoping that we could use computers to do all the heavy lifting of supporting these packagings ;-) -Marshall > Just my 2 cents. If people are willing to do the work and > think that our users are better served by individual > downloads, that's fine with me, too. Personally, I'll > defer to whatever the release manager for the sandbox, > whoever that may be, has to say on this subject :-) > > > --Thilo > > Marshall Schor wrote: > >> How do other projects do this kind of thing? >> >> I'm thinking of the Commons project (was Jakarta Commons) - has lots of >> downloadable subparts; each is separate. >> >> I don't have a strong preference, but I would lean toward the following >> kinds of things: >> >> 1) having a new category of things: Apache UIMA Components & Tools >> >> 2) moving things we think are ready for release from the sandbox to this >> new category. >> >> If things are really not ready for off-the-shelf kinds of users to use, >> I guess I would favor keeping those things in the Sandbox >> >> On the question of "bundling" components versus making them available >> separately - I think in our case, the components that we have - it feels >> more like they would be better consumed as separately available things. >> >> At some point in the future, it may make sense to offer the whole set as >> a "package" - but I guess that seems less useful than having them >> separately available. >> >> It also seems to me that these components would be on independent >> release cycles. >> >> -Marshall >> >> Michael Baessler wrote: >> >>> Hi, >>> >>> I think now it is time to discuss how we should proceed with the >>> Sandbox components and how we will release them. >>> The Sandbox is a place to develop components or tooling and to play >>> with new technologies around UIMA. If some of the components are >>> stable and tested they >>> should be included to a Sandbox release. A Sandbox release has the >>> advantage the users know what are the reliable components and what are >>> the >>> components that are currently under development. I would like to >>> release the selected Sandbox components as bundle with each Apache >>> UIMA release under - "Apache UIMA Add-ons". >>> So the version number is the same for both releases and the effort is >>> minimized. >>> >>> Advantages: >>> - release effort is minimized since only one release for all >>> components must be done >>> - you can download only one package that contains all the components >>> and tools >>> >>> Disadvantages: >>> - the release number for a Sandbox component changes for each Apache >>> UIMA release independent of component changes >>> - the Sandbox components can not be downloaded separately which is >>> maybe an issue (??) for some companies >>> >>> To do the release building I'm going to create a new Sandbox project >>> called "SandboxDistr" which contains all the information to build and >>> package the components. >>> For analysis engine components I have created a PEAR packager maven >>> plugin (plugin will also be added to the Sandbox) that will be used to >>> create a PEAR package automatically >>> during the build. My plan was to ship the PEAR package additionally in >>> the binary distribution for a component. >>> >>> What do others think about this release approach? >>> Suggestions or comments? >>> >>> -- Michael >>> >>> >>> > > > >
