incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Re: Non-final materials in final ASF materials (was: Re: ActiveMQ and ServiceMix reports)
Date Sat, 18 Mar 2006 09:33:04 GMT
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 <james.strachan@gmail.com> 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 <mail@leosimons.com> wrote:
> > On Thu, Mar 16, 2006 at 12:10:50PM +0000, James Strachan wrote:
> > > On 3/16/06, Davanum Srinivas <davanum@gmail.com> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


--
Davanum Srinivas : http://wso2.com/blogs/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message