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]
