my 2 cents. (i) don't use the incubator code, but fork it elsewhere (say to codehaus) and make releases there if Geronimo needs bug fixes
-1 (ii) Geronimo use incubator release candidate releases +1 (iii) ActiveMQ performs actual releases that Geronimo can depend on and use but put sufficient warnings in the jars that these are still in the incubator +1 On 3/18/06, James Strachan <[EMAIL PROTECTED]> wrote: > BTW I CC'd the Geronimo PMC as this is an interesting dilema for the > Geronimo folks too.... > > On 3/17/06, Leo Simons <[EMAIL PROTECTED]> wrote: > > On Thu, Mar 16, 2006 at 12:10:50PM +0000, James Strachan wrote: > > > On 3/16/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > > > So we could include the incubating ActiveMQ code inside an actual > > > production > > > Geronimo release - provided the ActiveMQ jars keep (their current name) of > > > incubator-activemq.jar? If so thats great, we can start integrating the > > > Apache ActiveMQ code into Geronimo ASAP - yay! > > > > I don't think the incubator is supposed to be telling the geronimo PMC what > > it > > can and cannot put into its releases. I think the incubator is supposed to > > be > > talking about the releases of incubating projects (like indeed, ActiveMQ) > > only. > > So the Geronimo PMC should decide - whether to stick with the old > codehaus-activemq or the new incubator-activemq. (Maybe its a 'when' > rather than 'whether') > > > > Now, without my incubator PMC hat on (but as a user of and contributor to > > ASF > > software and part of its community) I think it totally sucks ass if > > production > > releases contain non-production stuff, unless it is *very* clear which parts > > are non-production stuff, they are not "enabled" or "run" by default, and > > all > > the appropriate warning signs (*use this at your own risk*) are added (Re: > > experimental modules in HTTPD, or experimental modules in the linux kernel). > > Geronimo 1.0 shipped with the codehaus version of ActiveMQ. Since then > the code has moved into the incubator and its had heaps of bug fixes > made to it (along with some nifty cool new features). > > So from a production standpoint; the incubator code is now better > code, not worse. So shipping with the codehaus code in future Geronimo > releases would be a bad thing IMHO > > > > Your quote above (for people reading along: this is probably out of context > > at > > least a little, go read the entire thread) scares me a whole lot since it > > seems > > to mean you don't necessarily think the same way. > > Sorry, I'm not sure I follow > > > > In the case of incubating projects, it may sometimes also be the case that > > IP > > vetting is not (properly) done yet, and that is stuff you really shouldn't > > ship > > at all (I don't know about ActiveMQ, I suspect it is all fine IP-rights-wise > > since it has been open source for so long). But validating the IP is all in > > order for a release is not something the incubator PMC is responsible for > > when > > it comes to software not under its review, that is something the PMC > > publishing > > the release is responsible for. > > Agreed - though I thought the IP/software grant stuff had to be sorted > for any release from the incubator? > > > > > One more question then... ActiveMQ 4.0 is long overdue - I get asked when > > > its gonna be released everyday by someone somewhere :). We were originally > > > hoping to release it last year when most of the development was done but > > > then the incubation process started and we've been treading water a little > > > waiting until we thought we could actually ship some release candidates > > > then > > > the full 4.0 GA. (Which is why there's not been as much developer > > > discussion > > > as last year; we've mostly been in bug fix mode for months waiting until > > > we > > > can release 4.0). > > > > > > Up to now I'd thought we could only do a 4.0 release after leaving the > > > incubator. I remember last time I looked the incubator policy talked in > > > terms that podlings could only do "milestone" releases. Though I just > > > reread > > > the policy document > > > http://incubator.apache.org/incubation/Incubation_Policy.html > > > > > > and it doesn't seem to even mention that world any more. So I guess that > > > means we could go ahead and start trying to do the 4.0-RC-* releases and > > > try > > > get the full 4.0 release out - provided the Incubator PMC approves the > > > release and we release the code as "incubator-activemq" with all the > > > necessary disclaimers to avoid any confusion & to ensure users are aware > > > the > > > code is still in the incubator. > > > > > > Is this correct or have I got the wrong end of the stick again? :) > > > > The real answer to that is not about the policy, its about why it is there > > and > > what it tries to accomplish. > > > > I don't know the policy details, but as a general rule, we (as in the > > incubator, > > the geronimo PMC, the apache community, all the other communities, the ASF > > as > > a legal institute) should be actively discouraging users (eg the people that > > ask you about those releases and don't know what "incubation" means nor how > > to > > get stuff from our SVN) from /using/ software that is in the incubator. > > So - say - should the ASF be actively discouraging the Geronimo > project from using incubator-activemq? Geronimo is one of the biggest > users of ActiveMQ afterall. This seems strange; e.g. if we need to fix > bugs for the next production release of Geronimo, do we have to fork > the code back to codehaus and release it there so that Geronimo can > use the new bug fixed code? > > Maybe this complication is because its kind of a special case we've > not seen before on the incubator? (I could be wrong here but off the > top of my head I can't think of a similar scenario). i.e. code > developed outside of Apache used extensively on a project inside the > ASF, then when the code moves to the incubator, should the ASF project > use the incubator code or stick on the old code until incubation is > complete? > > > > The policy is (supposed to be) a codification of that general rule. Using > > keywords > > such as "alpha", "beta", "milestone", "release candidate" and the like is > > another > > way that we tend to use to accomplish the same thing -- get people to test > > drive > > our stuff but only deploy in production at their own risk. > > > > At least IMNSHO. > > FWIW we've just started the ball rolling on a 4.0 release candidate. > > BTW we are currently calling all the artifacts incubator-activemq-*, > the jars are all called incubator-activemq*.jar, we include > disclaimers in the distro highlighting the incubator status and also > include these inside the manifests of the jars. So its very clear I > think to any would-be-user that the code is in the incubator - unless > you can think of something else we can do? > > So it seems our options for working with Geronimo while ActiveMQ is > under incubation are > > (i) don't use the incubator code, but fork it elsewhere (say to > codehaus) and make releases there if Geronimo needs bug fixes > (ii) Geronimo use incubator release candidate releases > (iii) ActiveMQ performs actual releases that Geronimo can depend on > and use but put sufficient warnings in the jars that these are still > in the incubator > > Would you prefer us to follow option (i)? I guess (ii) might be a good > compromise given the circumstances? > > -- > > James > ------- > http://radio.weblogs.com/0112098/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas : http://wso2.com/blogs/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
