On Sat, Mar 18, 2006 at 07:41:04AM +0000, James Strachan wrote: > BTW I CC'd the Geronimo PMC as this is an interesting dilema for the > Geronimo folks too....
I'm not so happy with crossposting between public/private lists (private lists should be unused if possible) so I dropped that again...this is a fine example of something which IMHO should not be private discussion... > 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') Yes I think so. > > 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. Okay...so my comment above is not very relevant (I thought "4.0" as opposed to "3.x" meant big changes and hence less proven-for-production-ness)... > So shipping with the codehaus code in future Geronimo > releases would be a bad thing IMHO I agree. Chances are, some users or repackagers of geronimo stuff (there's a few of those now, right?) would just replace the codehaus stuff with the newest stuff and still try and call it geronimo. Mess would result. > > 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 Nevermind. We found out my concern did not apply :-) > > 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? I think so, but if I were a PMC member for geronimo I would still make sure to double check all this before +1ing a release. There's unfortunately a bit of a history around here for status files to not be up-to-date... > > > 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? Heh. I suspect the geronimo project knows just fine what they should be doing. "The ASF" should keep its mouth shut on those kinds of specifics and trust the Geronimo PMC (and its VP) to make the right decisions. > 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? I think that is silly. It sounds like unneccessary work (all those svn dumps to do, diffs to generate, merging foo and bar, etc). > 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). The roller project. In that case, I think Dave has been publishing releases of incubated software with some of the warnings broohahah removed on another website. I think. This would mean the activemq people publishing an "incubation release" from the Apache SVN, repackaging it, then publishing that release on the codehaus website, then geronimo re-using that release. > 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? That seems stupid doesn't it? Its a tricky thing to get all this right. I definitely think that we have not succeeded so far to codify it all up into "proper" policy that is still understandable. > > 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? I don't know. I seem to remember a press release from December (no idea if that was actually published too) that confused the hell out of me (and I try and keep up!), and then IIUC it took quite some effort to clean up, so at that point I guess the people writing the press release or OK-ing were still confused about this. I don't like the current official policies for releases by incubating projects one bit. Everyone gets confused. I think they need to be different, but I don't really know what they should be. I'm rather certain that no-one has thought up any kind of policy for ASF projects that repackage incubating stuff and ship it. I know apache httpd ships or shipped custom versions of APR before APR reached 1.0 as part of its releases, and all that maked perfect sense to everyone. > 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? Once again, my preference doesn't really matter. Its just an opinion, and the geronimo project needs to make the decisions. That said... I think we have an imperfect situation now that starts with "incubation release" being confusing, and this trickles through into an imperfect situation for geronimo when having to pick between these. Fixing things properly takes time, so I guess in the meantime I would pick (iii), since users get the better code (this is the most important one if you ask me and not an optional thing) and reflects the current situation. In addition to picking (iii) I would probably but some info in a place users will read (release notes? Website?), or can be expected to read (no-one reads stuff do they?) explaining it all. cheers! Leo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
