incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: Non-final materials in final ASF materials (was: Re: ActiveMQ and ServiceMix reports)
Date Sun, 19 Mar 2006 12:46:16 GMT
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 <> wrote:
> > On Thu, Mar 16, 2006 at 12:10:50PM +0000, James Strachan wrote:
> > > On 3/16/06, Davanum Srinivas <> 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. 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
> > >
> > >
> > > 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
> > > 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.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message