You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2006/03/16 01:18:19 UTC
RE: ActiveMQ and ServiceMix reports
Ken wrote:
> Noel J. Bergman wrote:
> > Considering that both ActiveMQ and ServiceMix really ought to be
> > targeting TLP status, learning to do this is important.
> That's a bit much, Noel. Where they end up is primarily
> their own concern -- and not determined until graduation
> anyway.
Sorry for conflating two messages. And I'll rephrase.
I would still consider it to be an important issue, unless it is believed
that project members are either not going to become PMC members in the
destination, or are going to learn participating on a PMC means only when
they get there.
Regardless of where the project ends up, I don't believe that it would be
fair to bring communities into the ASF, and then disenfranchise them from
their project by not giving them binding votes. That is required during
incubation, but should not be the case afterwards. So preparing and
empowering the new community by teaching it ASF procedures during the
process of incubation is important to me.
Does that make more sense now?
--- Noel
Re: ActiveMQ and ServiceMix reports
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
James Strachan wrote:
>
> Note that we are apparently not allowed to use the incubating ActiveMQ
> inside Geronimo until it leaves incubation
>
http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/200602.mbox/browser
Due to the way mod_mbox currently works, that's essentially
a useless link. :-( You were looking at a particular message
when you did that, weren't you? Go the message list again,
and do an 'open link in new tab' on the message you want us to
read. You'll get an XML page. Remove '/ajax' from the URL and
you'll get a readable message. Post *that* URL and we'll all be
able to see what you were reading. :-)
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQCVAwUBRBlehJrNPMCpn3XdAQLsLgP/S4dPGNrHTsvMFaxr7Dz0/wZ8siX7c0ee
AnwHQ8U27SVdSRkDTZCId1EyEWJOTwysiAKvNSQmCVkRLgnH5MnuvpCOBCOyCDE1
fMxkWDjjPcdxLqi+CZKd97CJzb3QJCsJZ2vD4WzBx6Qw7kMKuZVWI+WxeZz71hCv
v82IvFFOFww=
=WbG5
-----END PGP SIGNATURE-----
Re: ActiveMQ and ServiceMix reports
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
James Strachan wrote:
>
> Note that we are apparently not allowed to use the incubating ActiveMQ
> inside Geronimo until it leaves incubation
>
http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/200602.mbox/browser
Due to the way mod_mbox currently works, that's essentially
a useless link. :-( You were looking at a particular message
when you did that, weren't you? Go the message list again,
and do an 'open link in new tab' on the message you want us to
read. You'll get an XML page. Remove '/ajax' from the URL and
you'll get a readable message. Post *that* URL and we'll all be
able to see what you were reading. :-)
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQCVAwUBRBlehJrNPMCpn3XdAQLsLgP/S4dPGNrHTsvMFaxr7Dz0/wZ8siX7c0ee
AnwHQ8U27SVdSRkDTZCId1EyEWJOTwysiAKvNSQmCVkRLgnH5MnuvpCOBCOyCDE1
fMxkWDjjPcdxLqi+CZKd97CJzb3QJCsJZ2vD4WzBx6Qw7kMKuZVWI+WxeZz71hCv
v82IvFFOFww=
=WbG5
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by James Strachan <ja...@gmail.com>.
On 3/16/06, Rodent of Unusual Size <Ke...@golux.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Davanum Srinivas wrote:
> > I don't think there is such a restriction. Where did you come across
> > that? in other words, who said that?
> >
> > "we are apparently not allowed to use the incubating ActiveMQ"
>
> I *think* James might have been referring to this:
>
> http://tinyurl.com/p92so
>
> Is that the one, James?
Ah yes thats the one - sorry about that :)
--
James
-------
http://radio.weblogs.com/0112098/
Re: ActiveMQ and ServiceMix reports
Posted by James Strachan <ja...@gmail.com>.
On 3/16/06, Rodent of Unusual Size <Ke...@golux.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Davanum Srinivas wrote:
> > I don't think there is such a restriction. Where did you come across
> > that? in other words, who said that?
> >
> > "we are apparently not allowed to use the incubating ActiveMQ"
>
> I *think* James might have been referring to this:
>
> http://tinyurl.com/p92so
>
> Is that the one, James?
Ah yes thats the one - sorry about that :)
--
James
-------
http://radio.weblogs.com/0112098/
Re: ActiveMQ and ServiceMix reports
Posted by James Strachan <ja...@gmail.com>.
On 3/16/06, Rodent of Unusual Size <Ke...@golux.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Davanum Srinivas wrote:
> > I don't think there is such a restriction. Where did you come across
> > that? in other words, who said that?
> >
> > "we are apparently not allowed to use the incubating ActiveMQ"
>
> I *think* James might have been referring to this:
>
> http://tinyurl.com/p92so
>
> Is that the one, James?
Ah yes thats the one - sorry about that :)
--
James
-------
http://radio.weblogs.com/0112098/
Re: ActiveMQ and ServiceMix reports
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[restoring the CC list since this definitely applies to the
people on those lists]
Davanum Srinivas wrote:
> I don't think there is such a restriction. Where did you come across
> that? in other words, who said that?
>
> "we are apparently not allowed to use the incubating ActiveMQ"
I *think* James might have been referring to this:
http://tinyurl.com/p92so
Is that the one, James?
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQCVAwUBRBlgIZrNPMCpn3XdAQKpWQQA2+RrtH7JijsgmJLUx7A0tiuIiDHNKAqy
pQDkUhki3ltm6sHU0RXO3ih+RTo1PajhsAlWGFW0EzA5a8A0T60XwEOU4xfcJsKO
/1bq1/HgVqAFoZFuY/u9qnyyLsrqEk3N4KziPq+aLbEEmxia7arsul8P2JC/8O4I
+/1pu+8PoSo=
=kCtP
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
This is my understanding as well and what was communicated to me by
Incubator PMC people.
Regards,
Alan
Davanum Srinivas wrote:
> I think he is talking about having/needing a separate download for
> ServiceMix irrespective of whether an incubating jar is in Geronimo or
> not.
>
> Basically if one needs servicemix, they get a whole package that has
> incubating all over it. Same with derby, if someone needed derby they
> won't download Geronimo. They will download Derby. Does not mean that
> derby jar should not be in Geronimo. It could be, but needs to be
> marked properly (incubating sth or other in the jar name)
>
> Anyway that is my understanding...
>
> [1] http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/200602.mbox/%3c1140235319.25299.24.camel@localhost.localdomain%3e
>
> On 3/16/06, James Strachan <ja...@gmail.com> wrote:
>
>> On 3/16/06, Davanum Srinivas <da...@gmail.com> wrote:
>>
>>> I don't think there is such a restriction. Where did you come across
>>> that? in other words, who said that?
>>>
>>> "we are apparently not allowed to use the incubating ActiveMQ"
>>>
>> See this thread...
>>
>> http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/200602.mbox/%3c1140624251.29199.38.camel@localhost.localdomain%3e
>>
>> I confess that this was a suprise - I'd like clarification if this is
>> actually really the case. It seems silly for the incubation process to
>> actually stop other Apache projects using the code.
>>
>> e.g. I remember us using Apache Derby for a very long time during its
>> incubation on Geronimo - which resulted in some Geronimo folks contributing
>> back to Derby; we also considered its releases to be real things we built
>> software from, not just "milestones". Though I guess back then, Geronimo was
>> still in incubation itself which is why it was maybe allowed to use
>> incubating code?
>>
>> --
>>
>> James
>> -------
>> http://radio.weblogs.com/0112098/
>>
>>
>>
>
>
> --
> 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
>
>
Re: Non-final materials in final ASF materials
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 18 March 2006 01:36, Guillaume Nodet wrote:
> I am quite new at Apache, but from my understanding, the incubation
> process as nothing to do with the quality of the releases the
> incubated project produces. It has mainly to do with the ASF
> endorsing the project (though I do not have a clear understanding
> of what it really means...)
Correct. Nothing to do about the technical quality, but that the ASF is
stating "We (ASF) have vetted this codebase to the best of our abillities,
and it should now be unencumbered of copyrights and licensing terms, and we
have an active community around the codebase that will ensure the long-term
viability of this project."
So when Leo say "at your own risk", it is in the context of "our vetting and
community building process is not yet complete, and this *may* never become
an endorsed ASF project".
> Doing only milestones may be good for new projects, but for
> projects that do have a huge user community, not being able to
> do releases can be a problem
> -- what about bugfix releases on previous versions ?
> Such projects may be in need of "real" releases, even if
> incubating (and thus, non endorsed by the ASF).
Such projects are encouraged to do these releases at their "current" home.
Nothing stops ActiveMQ to make a release out of the CodeHaus location,
although it is in ASF incubation.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Non-final materials in final ASF materials
Posted by Guillaume Nodet <gu...@worldonline.fr>.
Leo Simons wrote:
>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.
>
>Without knowing much about it, I suspect that in the ActiveMQ case, there should
>be a bunch of release candidates ASAP (from the incubator following those
>processes) and then the "final" release should not be released from the incubator,
>since otherwise you don't reach the goal of not having end users using incubated
>stuff in production.
>
>LSD
>
>
>
>
I am quite new at Apache, but from my understanding, the incubation process
as nothing to do with the quality of the releases the incubated project
produces.
It has mainly to do with the ASF endorsing the project (though I do not have
a clear understanding of what it really means...)
In the case of ServiceMix (and ActiveMQ), the trunk is much more stable
than
the previous non Apache releases at Codehaus. So I do not see the fact
that
the project is in incubation as a problem to put it in production.
Doing only milestones may be good for new projects, but for projects
that do
have a huge user community, not being able to do releases can be a problem
-- what about bugfix releases on previous versions ? Such projects may
be in
need of "real" releases, even if incubating (and thus, non endorsed by
the ASF).
Back to Geronimo, when I first posted the mail on the ServiceMix dev
list about
re-integrating ServiceMix in Geronimo, it was not meant to be in the
next planned
release (1.1) but rather in the trunk, so that we can start working on
the integration
issues. It seems that this point has been cleared now :)
Cheers,
Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Non-final materials in final ASF materials (was: Re: ActiveMQ and ServiceMix reports)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 19 March 2006 20:46, Leo Simons wrote:
> On Sat, Mar 18, 2006 at 07:41:04AM +0000, James Strachan wrote:
> > (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
> 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.
Nah... do iv) Stick the whole of Geronimo back into Incubation. Problem
solved ;o) ... just kidding.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Non-final materials in final ASF materials (was: Re: ActiveMQ and ServiceMix reports)
Posted by Leo Simons <ma...@leosimons.com>.
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 <ma...@leosimons.com> wrote:
> > On Thu, Mar 16, 2006 at 12:10:50PM +0000, James Strachan wrote:
> > > On 3/16/06, Davanum Srinivas <da...@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')
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Non-final materials in final ASF materials (was: Re: ActiveMQ and ServiceMix reports)
Posted by Davanum Srinivas <da...@gmail.com>.
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 <ja...@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 <ma...@leosimons.com> wrote:
> > On Thu, Mar 16, 2006 at 12:10:50PM +0000, James Strachan wrote:
> > > On 3/16/06, Davanum Srinivas <da...@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
Re: Non-final materials in final ASF materials
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
Henri Yandell wrote:
>
>
> On Sat, 18 Mar 2006, James Strachan wrote:
>
>> 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?
>
> +1 to (iii). I see no reason why a project in the Incubator that has
> been making releases prior to joining the Incubator cannot continue to
> make those releases. It's damaging to the community we are trying to
> incubate to suddenly stop their momentum and leave their users in the
> lurch.
>
> To do that it definitely needs to have passed some of the checks on
> the STATUS page. The one that springs to mind is the legal one - it
> must be legally distributable from the ASF.
>
> It needs to ship with incubator comments (see Roller releases - which
> due to not being legally distributable is doing your (i) option).
> Having a name of incubator-activemq seems fine - with a maven2 groupId
> of org.apache.incubator.
>
> On Leo's suggestion that in the incubator there are RC releases and it
> only goes final when it leaves - I don't think that will help anybody.
> If the mentors and the Incubator PMC believe that the piece of
> software being released is production quality - it should be released.
> Incubation is about the community education and growth - and making
> sure the code is legally distributable; but not the quality of the code.
This reflects my feelings as well.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Non-final materials in final ASF materials (was: Re: ActiveMQ
and ServiceMix reports)
Posted by Henri Yandell <ba...@apache.org>.
On Sat, 18 Mar 2006, James Strachan wrote:
> 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?
+1 to (iii). I see no reason why a project in the Incubator that has been
making releases prior to joining the Incubator cannot continue to make
those releases. It's damaging to the community we are trying to incubate
to suddenly stop their momentum and leave their users in the lurch.
To do that it definitely needs to have passed some of the checks on the
STATUS page. The one that springs to mind is the legal one - it must be
legally distributable from the ASF.
It needs to ship with incubator comments (see Roller releases - which due
to not being legally distributable is doing your (i) option). Having a
name of incubator-activemq seems fine - with a maven2 groupId of
org.apache.incubator.
On Leo's suggestion that in the incubator there are RC releases and it
only goes final when it leaves - I don't think that will help anybody. If
the mentors and the Incubator PMC believe that the piece of software being
released is production quality - it should be released. Incubation is
about the community education and growth - and making sure the code is
legally distributable; but not the quality of the code.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Non-final materials in final ASF materials (was: Re: ActiveMQ and ServiceMix reports)
Posted by James Strachan <ja...@gmail.com>.
BTW I CC'd the Geronimo PMC as this is an interesting dilema for the
Geronimo folks too....
On 3/17/06, Leo Simons <ma...@leosimons.com> wrote:
> On Thu, Mar 16, 2006 at 12:10:50PM +0000, James Strachan wrote:
> > On 3/16/06, Davanum Srinivas <da...@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
Non-final materials in final ASF materials (was: Re: ActiveMQ and ServiceMix reports)
Posted by Leo Simons <ma...@leosimons.com>.
On Thu, Mar 16, 2006 at 12:10:50PM +0000, James Strachan wrote:
> On 3/16/06, Davanum Srinivas <da...@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.
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).
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.
If I had an infrastructure hat on (currently mostly inactive there) I would
have absolutely no problem pulling a release from ASF hardware if, when opening
it up, I saw such a common sense rule not being followed. I know I've been
tempted to do that several times (most of the big ASF projects I know mess
this up, in particular when maven was brand-new projects would ship software
that had SNAPSHOT dependencies...you know, shit happens), but I don't think I
ever did.
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.
> 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.
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.
Without knowing much about it, I suspect that in the ActiveMQ case, there should
be a bunch of release candidates ASAP (from the incubator following those
processes) and then the "final" release should not be released from the incubator,
since otherwise you don't reach the goal of not having end users using incubated
stuff in production.
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by Davanum Srinivas <da...@gmail.com>.
I'll let Noel reply back to this, just to be sure :)
On 3/16/06, James Strachan <ja...@gmail.com> wrote:
>
> On 3/16/06, Davanum Srinivas <da...@gmail.com> wrote:
> > I think he is talking about having/needing a separate download for
> > ServiceMix irrespective of whether an incubating jar is in Geronimo or
> > not.
> > Basically if one needs servicemix, they get a whole package that has
> > incubating all over it. Same with derby, if someone needed derby they
> > won't download Geronimo.
>
> > They will download Derby. Does not mean that
> > derby jar should not be in Geronimo. It could be, but needs to be
> > marked properly (incubating sth or other in the jar name)
>
>
> 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!
>
>
> 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? :)
>
> --
>
>
> James
> -------
> http://radio.weblogs.com/0112098/
--
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
Re: ActiveMQ and ServiceMix reports
Posted by James Strachan <ja...@gmail.com>.
On 3/16/06, Davanum Srinivas <da...@gmail.com> wrote:
>
> I think he is talking about having/needing a separate download for
> ServiceMix irrespective of whether an incubating jar is in Geronimo or
> not.
Basically if one needs servicemix, they get a whole package that has
> incubating all over it. Same with derby, if someone needed derby they
> won't download Geronimo.
They will download Derby. Does not mean that
> derby jar should not be in Geronimo. It could be, but needs to be
> marked properly (incubating sth or other in the jar name)
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!
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? :)
--
James
-------
http://radio.weblogs.com/0112098/
Re: ActiveMQ and ServiceMix reports
Posted by Davanum Srinivas <da...@gmail.com>.
I think he is talking about having/needing a separate download for
ServiceMix irrespective of whether an incubating jar is in Geronimo or
not.
Basically if one needs servicemix, they get a whole package that has
incubating all over it. Same with derby, if someone needed derby they
won't download Geronimo. They will download Derby. Does not mean that
derby jar should not be in Geronimo. It could be, but needs to be
marked properly (incubating sth or other in the jar name)
Anyway that is my understanding...
[1] http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/200602.mbox/%3c1140235319.25299.24.camel@localhost.localdomain%3e
On 3/16/06, James Strachan <ja...@gmail.com> wrote:
> On 3/16/06, Davanum Srinivas <da...@gmail.com> wrote:
> >
> > I don't think there is such a restriction. Where did you come across
> > that? in other words, who said that?
> >
> > "we are apparently not allowed to use the incubating ActiveMQ"
>
>
> See this thread...
>
> http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/200602.mbox/%3c1140624251.29199.38.camel@localhost.localdomain%3e
>
> I confess that this was a suprise - I'd like clarification if this is
> actually really the case. It seems silly for the incubation process to
> actually stop other Apache projects using the code.
>
> e.g. I remember us using Apache Derby for a very long time during its
> incubation on Geronimo - which resulted in some Geronimo folks contributing
> back to Derby; we also considered its releases to be real things we built
> software from, not just "milestones". Though I guess back then, Geronimo was
> still in incubation itself which is why it was maybe allowed to use
> incubating code?
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
--
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
Re: ActiveMQ and ServiceMix reports
Posted by James Strachan <ja...@gmail.com>.
On 3/16/06, Davanum Srinivas <da...@gmail.com> wrote:
>
> I don't think there is such a restriction. Where did you come across
> that? in other words, who said that?
>
> "we are apparently not allowed to use the incubating ActiveMQ"
See this thread...
http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/200602.mbox/%3c1140624251.29199.38.camel@localhost.localdomain%3e
I confess that this was a suprise - I'd like clarification if this is
actually really the case. It seems silly for the incubation process to
actually stop other Apache projects using the code.
e.g. I remember us using Apache Derby for a very long time during its
incubation on Geronimo - which resulted in some Geronimo folks contributing
back to Derby; we also considered its releases to be real things we built
software from, not just "milestones". Though I guess back then, Geronimo was
still in incubation itself which is why it was maybe allowed to use
incubating code?
--
James
-------
http://radio.weblogs.com/0112098/
Re: ActiveMQ and ServiceMix reports
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[restoring the CC list since this definitely applies to the
people on those lists]
Davanum Srinivas wrote:
> I don't think there is such a restriction. Where did you come across
> that? in other words, who said that?
>
> "we are apparently not allowed to use the incubating ActiveMQ"
I *think* James might have been referring to this:
http://tinyurl.com/p92so
Is that the one, James?
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQCVAwUBRBlgIZrNPMCpn3XdAQKpWQQA2+RrtH7JijsgmJLUx7A0tiuIiDHNKAqy
pQDkUhki3ltm6sHU0RXO3ih+RTo1PajhsAlWGFW0EzA5a8A0T60XwEOU4xfcJsKO
/1bq1/HgVqAFoZFuY/u9qnyyLsrqEk3N4KziPq+aLbEEmxia7arsul8P2JC/8O4I
+/1pu+8PoSo=
=kCtP
-----END PGP SIGNATURE-----
Re: ActiveMQ and ServiceMix reports
Posted by Davanum Srinivas <da...@gmail.com>.
I don't think there is such a restriction. Where did you come across
that? in other words, who said that?
"we are apparently not allowed to use the incubating ActiveMQ"
thanks,
dims
On 3/16/06, James Strachan <ja...@gmail.com> wrote:
> On 3/16/06, Noel J. Bergman <no...@devtech.com> wrote:
> >
> > Hiram Chirino wrote:
> >
> > > I believe that merging ActiveMQ and Servicemix into Geronimo
> > > community and PMC is easier than most cases since there are
> > > all ready several active ActiveMQ/ServiceMix commiters thar
> > > are Geronimo PMC members.
> >
> > At this moment, Geronimo has 19 PMC members and 7 commmiters who are not
> > on
> > the PMC. That does, of course, change over time.
> >
> > The overlap of ActiveMQ and ServiceMix with the Geronimo PMC has 10 PMC
> > members. ActiveMQ has 13 additional people who are not on the Geronimo
> > PMC.
> > Adding ServiceMix is just another 4 (17 total), as there is a huge overlap
> > between ActiveMQ and ServiceMix.
> >
> > I have no idea how active any of these people are on any of the projects
> > in
> > any capacity. Dims appears to feel that there is a large number of
> > committers in name only, but I haven't looked at all so for the sake of
> > discussion, let's assume that they are all active.
>
>
> To give some concrete numbers; ActiveMQ currently has 20 committers; 15 have
> been active so far during incubation. Though most of those 5 (apart from
> Brian :) are Geronimo committers who tend to work on ActiveMQ as part of its
> integration into Geronimo (e.g. David Jencks, Dain, Aaron etc). i.e. they
> tend to work on integration issues with Geronimo as their primary
> involvement.
>
> Note that we are apparently not allowed to use the incubating ActiveMQ
> inside Geronimo until it leaves incubation
> http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/200602.mbox/browser
>
> which is why some of the Geronimo folks haven't been active hacking on
> ActiveMQ to fix it (as we don't yet know whats broke :). As soon as we start
> integrating the Apache ActiveMQ codebase into Geronimo I'm sure those guys
> will get active fast; though if this restriction is true, then they can only
> really contribute after incubation is over which is very unfortunate.
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
--
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
Re: ActiveMQ and ServiceMix reports
Posted by James Strachan <ja...@gmail.com>.
On 3/16/06, Noel J. Bergman <no...@devtech.com> wrote:
>
> Hiram Chirino wrote:
>
> > I believe that merging ActiveMQ and Servicemix into Geronimo
> > community and PMC is easier than most cases since there are
> > all ready several active ActiveMQ/ServiceMix commiters thar
> > are Geronimo PMC members.
>
> At this moment, Geronimo has 19 PMC members and 7 commmiters who are not
> on
> the PMC. That does, of course, change over time.
>
> The overlap of ActiveMQ and ServiceMix with the Geronimo PMC has 10 PMC
> members. ActiveMQ has 13 additional people who are not on the Geronimo
> PMC.
> Adding ServiceMix is just another 4 (17 total), as there is a huge overlap
> between ActiveMQ and ServiceMix.
>
> I have no idea how active any of these people are on any of the projects
> in
> any capacity. Dims appears to feel that there is a large number of
> committers in name only, but I haven't looked at all so for the sake of
> discussion, let's assume that they are all active.
To give some concrete numbers; ActiveMQ currently has 20 committers; 15 have
been active so far during incubation. Though most of those 5 (apart from
Brian :) are Geronimo committers who tend to work on ActiveMQ as part of its
integration into Geronimo (e.g. David Jencks, Dain, Aaron etc). i.e. they
tend to work on integration issues with Geronimo as their primary
involvement.
Note that we are apparently not allowed to use the incubating ActiveMQ
inside Geronimo until it leaves incubation
http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/200602.mbox/browser
which is why some of the Geronimo folks haven't been active hacking on
ActiveMQ to fix it (as we don't yet know whats broke :). As soon as we start
integrating the Apache ActiveMQ codebase into Geronimo I'm sure those guys
will get active fast; though if this restriction is true, then they can only
really contribute after incubation is over which is very unfortunate.
--
James
-------
http://radio.weblogs.com/0112098/
Re: ActiveMQ and ServiceMix reports
Posted by James Strachan <ja...@gmail.com>.
On 3/16/06, Noel J. Bergman <no...@devtech.com> wrote:
>
> Hiram Chirino wrote:
>
> > I believe that merging ActiveMQ and Servicemix into Geronimo
> > community and PMC is easier than most cases since there are
> > all ready several active ActiveMQ/ServiceMix commiters thar
> > are Geronimo PMC members.
>
> At this moment, Geronimo has 19 PMC members and 7 commmiters who are not
> on
> the PMC. That does, of course, change over time.
>
> The overlap of ActiveMQ and ServiceMix with the Geronimo PMC has 10 PMC
> members. ActiveMQ has 13 additional people who are not on the Geronimo
> PMC.
> Adding ServiceMix is just another 4 (17 total), as there is a huge overlap
> between ActiveMQ and ServiceMix.
>
> I have no idea how active any of these people are on any of the projects
> in
> any capacity. Dims appears to feel that there is a large number of
> committers in name only, but I haven't looked at all so for the sake of
> discussion, let's assume that they are all active.
To give some concrete numbers; ActiveMQ currently has 20 committers; 15 have
been active so far during incubation. Though most of those 5 (apart from
Brian :) are Geronimo committers who tend to work on ActiveMQ as part of its
integration into Geronimo (e.g. David Jencks, Dain, Aaron etc). i.e. they
tend to work on integration issues with Geronimo as their primary
involvement.
Note that we are apparently not allowed to use the incubating ActiveMQ
inside Geronimo until it leaves incubation
http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/200602.mbox/browser
which is why some of the Geronimo folks haven't been active hacking on
ActiveMQ to fix it (as we don't yet know whats broke :). As soon as we start
integrating the Apache ActiveMQ codebase into Geronimo I'm sure those guys
will get active fast; though if this restriction is true, then they can only
really contribute after incubation is over which is very unfortunate.
--
James
-------
http://radio.weblogs.com/0112098/
Re: ActiveMQ and ServiceMix reports
Posted by Hiram Chirino <hi...@hiramchirino.com>.
I'll re-iterate what I said:
When the ServiceMix and ActiveMQ Apache committer list was created, it included
all previous committers to the project. But 100% of committers may not
have been active during the period of the incubation.
All though the projects trusted those individuals enough in the past
to give them
commit privileges, perhaps the TLP (Geronimo for sake of argument) PMC
may want to see more recent activity to evaluate if they truly 'get'
the Apache way.
As a Geronimo PMC member, I would +1 a motion to give all the
Geronimo/Servicemix folks Geronimo commit karma. Then, I would work
to introduce active contributors into the Geronimo PMC. I don't see a
big down side to this for any of the communities involved.
Regards,
Hiram
On 3/15/06, Noel J. Bergman <no...@devtech.com> wrote:
> Hiram Chirino wrote:
>
> > If the ActiveMQ / ServiceMix community do decide to go under some
> > other TLP, I'm sure it would not take long for the active
> > participants of the community to asked to Join the TLP's PMC.
>
> I would certainly hope that they would want to be, yes. Hence ...
>
> > I believe that merging ActiveMQ and Servicemix into Geronimo
> > community and PMC is easier than most cases since there are
> > all ready several active ActiveMQ/ServiceMix commiters thar
> > are Geronimo PMC members.
>
> At this moment, Geronimo has 19 PMC members and 7 commmiters who are not on
> the PMC. That does, of course, change over time.
>
> The overlap of ActiveMQ and ServiceMix with the Geronimo PMC has 10 PMC
> members. ActiveMQ has 13 additional people who are not on the Geronimo PMC.
> Adding ServiceMix is just another 4 (17 total), as there is a huge overlap
> between ActiveMQ and ServiceMix.
>
> I have no idea how active any of these people are on any of the projects in
> any capacity. Dims appears to feel that there is a large number of
> committers in name only, but I haven't looked at all so for the sake of
> discussion, let's assume that they are all active. Adding ActiveMQ and
> ServiceMix to Geronimo could increase the size of Geronimo's community from
> 26 to ~40, and assuming a comparable ratio, the PMC from 19 to 30+.
>
> So is Geronimo prepared to take such actions? Should it be, at this time?
> And what would that do for diversity, since a lot of people appear to work
> for the same company?
>
> --- Noel
>
>
--
Regards,
Hiram
Re: ActiveMQ and ServiceMix reports
Posted by James Strachan <ja...@gmail.com>.
On 3/16/06, Noel J. Bergman <no...@devtech.com> wrote:
>
> Hiram Chirino wrote:
>
> > I believe that merging ActiveMQ and Servicemix into Geronimo
> > community and PMC is easier than most cases since there are
> > all ready several active ActiveMQ/ServiceMix commiters thar
> > are Geronimo PMC members.
>
> At this moment, Geronimo has 19 PMC members and 7 commmiters who are not
> on
> the PMC. That does, of course, change over time.
>
> The overlap of ActiveMQ and ServiceMix with the Geronimo PMC has 10 PMC
> members. ActiveMQ has 13 additional people who are not on the Geronimo
> PMC.
> Adding ServiceMix is just another 4 (17 total), as there is a huge overlap
> between ActiveMQ and ServiceMix.
>
> I have no idea how active any of these people are on any of the projects
> in
> any capacity. Dims appears to feel that there is a large number of
> committers in name only, but I haven't looked at all so for the sake of
> discussion, let's assume that they are all active.
To give some concrete numbers; ActiveMQ currently has 20 committers; 15 have
been active so far during incubation. Though most of those 5 (apart from
Brian :) are Geronimo committers who tend to work on ActiveMQ as part of its
integration into Geronimo (e.g. David Jencks, Dain, Aaron etc). i.e. they
tend to work on integration issues with Geronimo as their primary
involvement.
Note that we are apparently not allowed to use the incubating ActiveMQ
inside Geronimo until it leaves incubation
http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/200602.mbox/browser
which is why some of the Geronimo folks haven't been active hacking on
ActiveMQ to fix it (as we don't yet know whats broke :). As soon as we start
integrating the Apache ActiveMQ codebase into Geronimo I'm sure those guys
will get active fast; though if this restriction is true, then they can only
really contribute after incubation is over which is very unfortunate.
--
James
-------
http://radio.weblogs.com/0112098/
Re: ActiveMQ and ServiceMix reports
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 3/16/06, Henri Yandell <fl...@gmail.com> wrote:
> I'm convinced - this definitely seems like a very good reason to have
> inactive committers following an incubated project through to either
> TLP stage, or into another TLP, but not being on the PMC. I'd be less
> convinced on a project that wasn't previously open so that there was
> no way to know if committers had previously contributed; but for open
> source projects who join the incubator this is a great point.
Jackrabbit is a fairly good and recent example. A bunch of people
dropped off the Jackrabbit PMC roster submitted to the Board because
they themselves stated that they weren't active and should be
emeritus. Note that a critical difference perhaps from what you're
stating, I believe, was that the Jackrabbit folks were given the
choice to go emeritus and explicitly took up that offer - with the
understanding that they can re-join the PMC at any time.
The key may have been stressing that choosing to go emeritus is a very
very reversible action later on. (Not making that a reversible action
was the fracas that Ant ran into.) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jochen Wiedmann wrote:
>
> I have another question: If that guy finds some time for working on
> the project again and asks for Karma: Do you indeed believe the
> project wouldn't be ready to vote him in as a committer?
But turn it around as well. Consider someone who was a
committer but went inactive before the package came to
Apache. Now it's at the ASF, and he becomes active
again, but doing so in a problematic way -- say, ignoring
vetos or raising them excessively. (Pathological case.)
Do you believe the project would be ready to revoke his
commit access until he learned to behave and work with
the community?
Cases in the past in which commit access was revoked have
turned out to be universally very, very unpleasant. It's
like laying someone off. And as a rule, people on both
sides hate a layoff, and will put up with enormous crap
to avoid it and the bad feeling it engenders all round.
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQCVAwUBRBlcPJrNPMCpn3XdAQJ85gQAm4Rnae8o1+zMChG6oFIpkCFePji/Zspw
CXot8woUBVJdAl1T5ybZ4eyokShfPYfoVU/eZjnq0wPZc0ppUgxRLogoczkeVlTa
R3v/8DoTAF+FxRc8bs2wdH/Xvs5KX9Hvnb9B8XYTo2tv2q8epyjObADzoktF8+br
JCO5lLEQF1w=
=SS23
-----END PGP SIGNATURE-----
Re: ActiveMQ and ServiceMix reports
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jochen Wiedmann wrote:
>
> I have another question: If that guy finds some time for working on
> the project again and asks for Karma: Do you indeed believe the
> project wouldn't be ready to vote him in as a committer?
But turn it around as well. Consider someone who was a
committer but went inactive before the package came to
Apache. Now it's at the ASF, and he becomes active
again, but doing so in a problematic way -- say, ignoring
vetos or raising them excessively. (Pathological case.)
Do you believe the project would be ready to revoke his
commit access until he learned to behave and work with
the community?
Cases in the past in which commit access was revoked have
turned out to be universally very, very unpleasant. It's
like laying someone off. And as a rule, people on both
sides hate a layoff, and will put up with enormous crap
to avoid it and the bad feeling it engenders all round.
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQCVAwUBRBlcPJrNPMCpn3XdAQJ85gQAm4Rnae8o1+zMChG6oFIpkCFePji/Zspw
CXot8woUBVJdAl1T5ybZ4eyokShfPYfoVU/eZjnq0wPZc0ppUgxRLogoczkeVlTa
R3v/8DoTAF+FxRc8bs2wdH/Xvs5KX9Hvnb9B8XYTo2tv2q8epyjObADzoktF8+br
JCO5lLEQF1w=
=SS23
-----END PGP SIGNATURE-----
Re: ActiveMQ and ServiceMix reports
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jochen Wiedmann wrote:
>
> I have another question: If that guy finds some time for working on
> the project again and asks for Karma: Do you indeed believe the
> project wouldn't be ready to vote him in as a committer?
But turn it around as well. Consider someone who was a
committer but went inactive before the package came to
Apache. Now it's at the ASF, and he becomes active
again, but doing so in a problematic way -- say, ignoring
vetos or raising them excessively. (Pathological case.)
Do you believe the project would be ready to revoke his
commit access until he learned to behave and work with
the community?
Cases in the past in which commit access was revoked have
turned out to be universally very, very unpleasant. It's
like laying someone off. And as a rule, people on both
sides hate a layoff, and will put up with enormous crap
to avoid it and the bad feeling it engenders all round.
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQCVAwUBRBlcPJrNPMCpn3XdAQJ85gQAm4Rnae8o1+zMChG6oFIpkCFePji/Zspw
CXot8woUBVJdAl1T5ybZ4eyokShfPYfoVU/eZjnq0wPZc0ppUgxRLogoczkeVlTa
R3v/8DoTAF+FxRc8bs2wdH/Xvs5KX9Hvnb9B8XYTo2tv2q8epyjObADzoktF8+br
JCO5lLEQF1w=
=SS23
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 3/15/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Do these really have to be "Apache" credits accumulated? Let's do a
> hypothetical situation. Let's say that some guy puts in a few years of
> his life into a CodeHaus project. Then, he has a kid. At that time the
> project moves to ASF and he's MIA. Is it fair that he doesn't get
> commit karma when it graduates? IMO, no, it is not fair.
I have another question: If that guy finds some time for working on
the project again and asks for Karma: Do you indeed believe the
project wouldn't be ready to vote him in as a committer?
Jochen
--
Whenever you find yourself on the side of the
majority, it is time to pause and reflect.
(Mark Twain)
Re: ActiveMQ and ServiceMix reports
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 3/16/06, Henri Yandell <fl...@gmail.com> wrote:
> I'm convinced - this definitely seems like a very good reason to have
> inactive committers following an incubated project through to either
> TLP stage, or into another TLP, but not being on the PMC. I'd be less
> convinced on a project that wasn't previously open so that there was
> no way to know if committers had previously contributed; but for open
> source projects who join the incubator this is a great point.
Jackrabbit is a fairly good and recent example. A bunch of people
dropped off the Jackrabbit PMC roster submitted to the Board because
they themselves stated that they weren't active and should be
emeritus. Note that a critical difference perhaps from what you're
stating, I believe, was that the Jackrabbit folks were given the
choice to go emeritus and explicitly took up that offer - with the
understanding that they can re-join the PMC at any time.
The key may have been stressing that choosing to go emeritus is a very
very reversible action later on. (Not making that a reversible action
was the fracas that Ant ran into.) -- justin
Re: ActiveMQ and ServiceMix reports
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 3/15/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Do these really have to be "Apache" credits accumulated? Let's do a
> hypothetical situation. Let's say that some guy puts in a few years of
> his life into a CodeHaus project. Then, he has a kid. At that time the
> project moves to ASF and he's MIA. Is it fair that he doesn't get
> commit karma when it graduates? IMO, no, it is not fair.
I have another question: If that guy finds some time for working on
the project again and asks for Karma: Do you indeed believe the
project wouldn't be ready to vote him in as a committer?
Jochen
--
Whenever you find yourself on the side of the
majority, it is time to pause and reflect.
(Mark Twain)
PMC composition, inactivity, policy (was: Re: ActiveMQ and ServiceMix reports)
Posted by Leo Simons <ma...@leosimons.com>.
Can people *please* get into the habit of changing subject lines to
match subject matter around here? Thanks!
On Thu, Mar 16, 2006 at 12:03:27AM -0800, Henri Yandell wrote:
Alan wrote:
> > Not providing commit karma seems to be a bit like forced retirement
> > because of inactivity. Something that ASF frowns upon.
We do have this concept of "emeritus". In some projects emeritus status is
supposed to be about automatic after 6 months of inactivity. If someone is
MIA then a good reason not to provide commit access (not neccessarily the
abstract privilege, but the actual access with login and password) is
security -- we don't want people not managing their passwords and/or SSH
keys.
> > Let's do another scenario. Someone works very long and hard on one
> > component of the project. That component becomes very mature and rock
> > solid so, we really don't hear from him very often. Is it fair that he
> > doesn't get commit karma when it graduates? IMO, no, it is not fair.
> > Is it fair that he does not make it into the project PMC? Yes, it is
> > fair, IMO.
What if there is suddenly a problem with this component (perhaps a patent
claim) and the PMC has to act? What if he is the only person on the PMC
who really knows about prior art for this component? Would it be "fair" to
have him be inactive yet on the PMC mailing list for say, 3 years, prior
to that happening, if it means that the PMC as a whole is able to deal with
the patent claim within a week instead of within two months?
What is not fair is someone making decisions while not doing any of the
work (eg we think "meritocracy" is "fair"), but you can be on a PMC yet
not make any of the decisions (you just don't vote), and this is not really
a very bad thing, as long as you live up to your PMC responsibilities when
you have to.
Its not black and white. Every PMC is unique, as is ever project, and every
individual. In the end we're talking about individuals working together and
they do that in many different ways.
> I'm convinced - this definitely seems like a very good reason to have
> inactive committers following an incubated project through to either
> TLP stage, or into another TLP, but not being on the PMC. I'd be less
> convinced on a project that wasn't previously open so that there was
> no way to know if committers had previously contributed; but for open
> source projects who join the incubator this is a great point.
*shrug*. This neatly ties into the whole "open source" vs "open development"
discussions. Some projects are more "open" than others.
> In fact you've helped me resolve a direction on my general problem in
> this area at Jakarta where we have a huge number of inactive
> committers (300) and PMC members (40) - inactive committers good,
> inactive PMC members bad.
Oversimplification.
As an example of inactive PMC members, consider excalibur. The excalibur
PMC hasn't had to do much over the last few months except help the chair
submit a board report or two and vote on a few releases. The entire PMC
(as a PMC) is inactive and this is not a bad thing. If there is something
needing PMC attention, all of a sudden enough of those people would jump
right back into active gear to deal with it.
I don't really understand where all the talking about what the right and
wrong policies are is coming from. The right policy is a PMC deciding by
consensus (or some other voting scheme, sometimes) what its composition
should be. It seems we're looking to policy as a way to "scale" our
processes, and I think that won't work.
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 3/15/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Do these really have to be "Apache" credits accumulated? Let's do a
> hypothetical situation. Let's say that some guy puts in a few years of
> his life into a CodeHaus project. Then, he has a kid. At that time the
> project moves to ASF and he's MIA. Is it fair that he doesn't get
> commit karma when it graduates? IMO, no, it is not fair.
I have another question: If that guy finds some time for working on
the project again and asks for Karma: Do you indeed believe the
project wouldn't be ready to vote him in as a committer?
Jochen
--
Whenever you find yourself on the side of the
majority, it is time to pause and reflect.
(Mark Twain)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by Henri Yandell <fl...@gmail.com>.
On 3/15/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Rodent of Unusual Size wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Henri Yandell wrote:
> >
> >> Interesting reply - I'd been assuming that when an incubatee graduates
> >> into an existing project, it's PPMC automatically get added to the
> >> PMC. So I was a bit confused as to why Noel was even asking the
> >> question.
> >>
> >
> > Case-by-case basis. Personally I think it's a good idea,
> > but there are lots of opinions. When Derby graduated,
> > some of the PPMC was invited to the DB PMC, and more over
> > time.
> >
> > And it's not just the PPMC/PMC issue; there's commit access,
> > too. And I think that's thornier.
> >
> > If a podling graduates and joins an existing TLP, is it
> > equitable for the people listed as committers on its
> > proposal, with no accumulated Apache merit, to automatically
> > keep commit access? While people who get involved directly
> > with the parent TLP have to earn merit over months?
> >
> > That's the sort of scenario I was envisioning when I
> > referred to 'fast-tracking' commit access.
> >
> > The answer is clearly, 'Maybe, maybe not,' and possibly relates
> > to the amount of merit accumulated while in the podling.
> >
>
> Do these really have to be "Apache" credits accumulated? Let's do a
> hypothetical situation. Let's say that some guy puts in a few years of
> his life into a CodeHaus project. Then, he has a kid. At that time the
> project moves to ASF and he's MIA. Is it fair that he doesn't get
> commit karma when it graduates? IMO, no, it is not fair. Is it fair
> that he does not make it into the project PMC? Yes, it is fair, IMO.
>
> Not providing commit karma seems to be a bit like forced retirement
> because of inactivity. Something that ASF frowns upon.
>
> Let's do another scenario. Someone works very long and hard on one
> component of the project. That component becomes very mature and rock
> solid so, we really don't hear from him very often. Is it fair that he
> doesn't get commit karma when it graduates? IMO, no, it is not fair.
> Is it fair that he does not make it into the project PMC? Yes, it is
> fair, IMO.
>
> Not providing commit karma seems to be a bit like forced retirement
> because he completed the task that he set out to do.
>
> So, what about the receiving community? If they voted to sponsor the
> project, then they knew what the probable outcome would be, that the
> group could become committers of their project. If no one inside that
> community complained about it, would it be a fair assumption that the
> group on a whole thought that the arrangement was equitable? Should we
> care if both parties are happy?
Nicely put.
I'm convinced - this definitely seems like a very good reason to have
inactive committers following an incubated project through to either
TLP stage, or into another TLP, but not being on the PMC. I'd be less
convinced on a project that wasn't previously open so that there was
no way to know if committers had previously contributed; but for open
source projects who join the incubator this is a great point.
In fact you've helped me resolve a direction on my general problem in
this area at Jakarta where we have a huge number of inactive
committers (300) and PMC members (40) - inactive committers good,
inactive PMC members bad.
Thanks,
Hen
Re: ActiveMQ and ServiceMix reports
Posted by Henri Yandell <fl...@gmail.com>.
On 3/15/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Rodent of Unusual Size wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Henri Yandell wrote:
> >
> >> Interesting reply - I'd been assuming that when an incubatee graduates
> >> into an existing project, it's PPMC automatically get added to the
> >> PMC. So I was a bit confused as to why Noel was even asking the
> >> question.
> >>
> >
> > Case-by-case basis. Personally I think it's a good idea,
> > but there are lots of opinions. When Derby graduated,
> > some of the PPMC was invited to the DB PMC, and more over
> > time.
> >
> > And it's not just the PPMC/PMC issue; there's commit access,
> > too. And I think that's thornier.
> >
> > If a podling graduates and joins an existing TLP, is it
> > equitable for the people listed as committers on its
> > proposal, with no accumulated Apache merit, to automatically
> > keep commit access? While people who get involved directly
> > with the parent TLP have to earn merit over months?
> >
> > That's the sort of scenario I was envisioning when I
> > referred to 'fast-tracking' commit access.
> >
> > The answer is clearly, 'Maybe, maybe not,' and possibly relates
> > to the amount of merit accumulated while in the podling.
> >
>
> Do these really have to be "Apache" credits accumulated? Let's do a
> hypothetical situation. Let's say that some guy puts in a few years of
> his life into a CodeHaus project. Then, he has a kid. At that time the
> project moves to ASF and he's MIA. Is it fair that he doesn't get
> commit karma when it graduates? IMO, no, it is not fair. Is it fair
> that he does not make it into the project PMC? Yes, it is fair, IMO.
>
> Not providing commit karma seems to be a bit like forced retirement
> because of inactivity. Something that ASF frowns upon.
>
> Let's do another scenario. Someone works very long and hard on one
> component of the project. That component becomes very mature and rock
> solid so, we really don't hear from him very often. Is it fair that he
> doesn't get commit karma when it graduates? IMO, no, it is not fair.
> Is it fair that he does not make it into the project PMC? Yes, it is
> fair, IMO.
>
> Not providing commit karma seems to be a bit like forced retirement
> because he completed the task that he set out to do.
>
> So, what about the receiving community? If they voted to sponsor the
> project, then they knew what the probable outcome would be, that the
> group could become committers of their project. If no one inside that
> community complained about it, would it be a fair assumption that the
> group on a whole thought that the arrangement was equitable? Should we
> care if both parties are happy?
Nicely put.
I'm convinced - this definitely seems like a very good reason to have
inactive committers following an incubated project through to either
TLP stage, or into another TLP, but not being on the PMC. I'd be less
convinced on a project that wasn't previously open so that there was
no way to know if committers had previously contributed; but for open
source projects who join the incubator this is a great point.
In fact you've helped me resolve a direction on my general problem in
this area at Jakarta where we have a huge number of inactive
committers (300) and PMC members (40) - inactive committers good,
inactive PMC members bad.
Thanks,
Hen
RE: ActiveMQ and ServiceMix reports
Posted by "Noel J. Bergman" <no...@devtech.com>.
Yoav Shapira wrote:
> I actually tend to agree with Ken on these things
> Meritocracy *at the ASF* is a significant point.
And so staying in the Incubator long enough for people to have a sense of
confidence regarding the community makes sense to me. As I see it, moving a
project before having that sense of confidence would be irresponsible, and
moving a project into a PMC and excluding the people who brung it would not
be fair.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by Yoav Shapira <yo...@apache.org>.
Hola,
I actually tend to agree with Ken on these things, and so my answer to
both of Alan's scenarios would be that yes, it's fair for the old
committer to not automatically get commit privileges or be on the PMC.
A healthy community would instantly welcome back the hypothetical
person who spent years on the project at CodeHaus... Meritocracy *at
the ASF* is a significant point. Remember we're just talking about
those cases who don't lift a finger during incubation, not even to
send one email saying "hey I'm busy right now but do plan on
committing again in a month or two when my project is over."
Yoav
On 3/16/06, Rodent of Unusual Size <Ke...@golux.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Alan D. Cabrera wrote:
> >
> > Do these really have to be "Apache" credits accumulated?
>
> How do the people at Apache get to see it otherwise?
>
> I've pointed out what I think may be a problem. Having
> done so, I'm content to have the legacy commit inheritance
> you describe. The first time I see it abused, though,
> I'm going to bring the hammer down.
>
> But remember, I was one of the people who thought Y2K
> would be a problem. I'm *good* at envisioning bad-case
> scenarios. :-) Sort of a sideways Cassandra: predict
> terrible things, nobody believes, and they don't happen
> anyway. :-D
> - --
> #ken P-)}
>
> Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
> Author, developer, opinionist http://Apache-Server.Com/
>
> "Millennium hand and shrimp!"
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iQCVAwUBRBlhjJrNPMCpn3XdAQJ+XAP+OUHQw7YVKZztkWC1rt5nLo66pHbCTxvY
> b4DPJCniy45qKqt3Yaca75SJZMNKOEjO/gkwS/dtAjTQvsaS0p16RVMqaq6pUUOs
> pBzxEkyaVgTmNmBm5wQ/rmsN00ZyOC+vJ4bA/p8oIdAwjyrXfO7bSgF4oZaxKDxE
> J0ubHHguBeg=
> =Oy2H
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Yoav Shapira
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alan D. Cabrera wrote:
>
> Do these really have to be "Apache" credits accumulated?
How do the people at Apache get to see it otherwise?
I've pointed out what I think may be a problem. Having
done so, I'm content to have the legacy commit inheritance
you describe. The first time I see it abused, though,
I'm going to bring the hammer down.
But remember, I was one of the people who thought Y2K
would be a problem. I'm *good* at envisioning bad-case
scenarios. :-) Sort of a sideways Cassandra: predict
terrible things, nobody believes, and they don't happen
anyway. :-D
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQCVAwUBRBlhjJrNPMCpn3XdAQJ+XAP+OUHQw7YVKZztkWC1rt5nLo66pHbCTxvY
b4DPJCniy45qKqt3Yaca75SJZMNKOEjO/gkwS/dtAjTQvsaS0p16RVMqaq6pUUOs
pBzxEkyaVgTmNmBm5wQ/rmsN00ZyOC+vJ4bA/p8oIdAwjyrXfO7bSgF4oZaxKDxE
J0ubHHguBeg=
=Oy2H
-----END PGP SIGNATURE-----
Re: ActiveMQ and ServiceMix reports
Posted by John Sisson <jr...@gmail.com>.
Garrett Rooney wrote:
> On 3/15/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>
>> Do these really have to be "Apache" credits accumulated? Let's do a
>> hypothetical situation. Let's say that some guy puts in a few years of
>> his life into a CodeHaus project. Then, he has a kid. At that time the
>> project moves to ASF and he's MIA. Is it fair that he doesn't get
>> commit karma when it graduates? IMO, no, it is not fair. Is it fair
>> that he does not make it into the project PMC? Yes, it is fair, IMO.
>>
>> Not providing commit karma seems to be a bit like forced retirement
>> because of inactivity. Something that ASF frowns upon.
>>
>> Let's do another scenario. Someone works very long and hard on one
>> component of the project. That component becomes very mature and rock
>> solid so, we really don't hear from him very often. Is it fair that he
>> doesn't get commit karma when it graduates? IMO, no, it is not fair.
>> Is it fair that he does not make it into the project PMC? Yes, it is
>> fair, IMO.
>>
>> Not providing commit karma seems to be a bit like forced retirement
>> because he completed the task that he set out to do.
>>
I agree with Alan that it is only fair that significant contributions
prior to incubation should be recognized.
IMO, only active participants during incubation should be invited to an
existing project's PMC when graduating.
For those that are offered commit access it should be explained that
commit access is a privilege, not a right and they should be pointed to
the community rules.
I like Ken's words on the "commit access is a privilege, not a right"
topic in the last two paragraphs of the following mail in 2002:
http://marc2.theaimsgroup.com/?l=incubator-general&m=104217311311925&w=4
What do we have to lose giving past contributors commit access
considering the ability to veto commits or as a last resort have their
commit access suspended or revoked if they don't respect the
community/rules?
I agree that keeping the barrier low to past contributors as Garrett
says below is beneficial to the project.
John
> This isn't from an ASF project, but I think it's relevant. In the
> subversion project we've got a number of people who have full commit
> access, something around 30 at this point. Not all of them are active
> at any given time (heck, most of them aren't active at any given time
> for that matter), but having them out there with commit rights is
> still valuable, because it means the barrier is lowered for that day
> somewhere down the road when they find some bug, dig into the code and
> fix it, and want to commit the patch. Making it more difficult for
> experienced developers to come back to the project and contribute
> seems like a bad thing to me.
>
> Now on the other hand there's the argument that if they come back some
> day and express interest in committing something we could set them up
> with commit access then, but let's be fair, getting all the paperwork
> settled takes time, and if they want to do that now and make it that
> much easier when they do find the time for the project, what's the
> real harm? If the community around the project has truly learned how
> to work in the way apache projects tend to work, I'm sure they'll be
> able to teach these dormant committers what they need to know on the
> fly as they come back.
>
> -garrett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by John Sisson <jr...@gmail.com>.
Garrett Rooney wrote:
> On 3/15/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>
>> Do these really have to be "Apache" credits accumulated? Let's do a
>> hypothetical situation. Let's say that some guy puts in a few years of
>> his life into a CodeHaus project. Then, he has a kid. At that time the
>> project moves to ASF and he's MIA. Is it fair that he doesn't get
>> commit karma when it graduates? IMO, no, it is not fair. Is it fair
>> that he does not make it into the project PMC? Yes, it is fair, IMO.
>>
>> Not providing commit karma seems to be a bit like forced retirement
>> because of inactivity. Something that ASF frowns upon.
>>
>> Let's do another scenario. Someone works very long and hard on one
>> component of the project. That component becomes very mature and rock
>> solid so, we really don't hear from him very often. Is it fair that he
>> doesn't get commit karma when it graduates? IMO, no, it is not fair.
>> Is it fair that he does not make it into the project PMC? Yes, it is
>> fair, IMO.
>>
>> Not providing commit karma seems to be a bit like forced retirement
>> because he completed the task that he set out to do.
>>
I agree with Alan that it is only fair that significant contributions
prior to incubation should be recognized.
IMO, only active participants during incubation should be invited to an
existing project's PMC when graduating.
For those that are offered commit access it should be explained that
commit access is a privilege, not a right and they should be pointed to
the community rules.
I like Ken's words on the "commit access is a privilege, not a right"
topic in the last two paragraphs of the following mail in 2002:
http://marc2.theaimsgroup.com/?l=incubator-general&m=104217311311925&w=4
What do we have to lose giving past contributors commit access
considering the ability to veto commits or as a last resort have their
commit access suspended or revoked if they don't respect the
community/rules?
I agree that keeping the barrier low to past contributors as Garrett
says below is beneficial to the project.
John
> This isn't from an ASF project, but I think it's relevant. In the
> subversion project we've got a number of people who have full commit
> access, something around 30 at this point. Not all of them are active
> at any given time (heck, most of them aren't active at any given time
> for that matter), but having them out there with commit rights is
> still valuable, because it means the barrier is lowered for that day
> somewhere down the road when they find some bug, dig into the code and
> fix it, and want to commit the patch. Making it more difficult for
> experienced developers to come back to the project and contribute
> seems like a bad thing to me.
>
> Now on the other hand there's the argument that if they come back some
> day and express interest in committing something we could set them up
> with commit access then, but let's be fair, getting all the paperwork
> settled takes time, and if they want to do that now and make it that
> much easier when they do find the time for the project, what's the
> real harm? If the community around the project has truly learned how
> to work in the way apache projects tend to work, I'm sure they'll be
> able to teach these dormant committers what they need to know on the
> fly as they come back.
>
> -garrett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
Re: ActiveMQ and ServiceMix reports
Posted by John Sisson <jr...@gmail.com>.
Garrett Rooney wrote:
> On 3/15/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>
>> Do these really have to be "Apache" credits accumulated? Let's do a
>> hypothetical situation. Let's say that some guy puts in a few years of
>> his life into a CodeHaus project. Then, he has a kid. At that time the
>> project moves to ASF and he's MIA. Is it fair that he doesn't get
>> commit karma when it graduates? IMO, no, it is not fair. Is it fair
>> that he does not make it into the project PMC? Yes, it is fair, IMO.
>>
>> Not providing commit karma seems to be a bit like forced retirement
>> because of inactivity. Something that ASF frowns upon.
>>
>> Let's do another scenario. Someone works very long and hard on one
>> component of the project. That component becomes very mature and rock
>> solid so, we really don't hear from him very often. Is it fair that he
>> doesn't get commit karma when it graduates? IMO, no, it is not fair.
>> Is it fair that he does not make it into the project PMC? Yes, it is
>> fair, IMO.
>>
>> Not providing commit karma seems to be a bit like forced retirement
>> because he completed the task that he set out to do.
>>
I agree with Alan that it is only fair that significant contributions
prior to incubation should be recognized.
IMO, only active participants during incubation should be invited to an
existing project's PMC when graduating.
For those that are offered commit access it should be explained that
commit access is a privilege, not a right and they should be pointed to
the community rules.
I like Ken's words on the "commit access is a privilege, not a right"
topic in the last two paragraphs of the following mail in 2002:
http://marc2.theaimsgroup.com/?l=incubator-general&m=104217311311925&w=4
What do we have to lose giving past contributors commit access
considering the ability to veto commits or as a last resort have their
commit access suspended or revoked if they don't respect the
community/rules?
I agree that keeping the barrier low to past contributors as Garrett
says below is beneficial to the project.
John
> This isn't from an ASF project, but I think it's relevant. In the
> subversion project we've got a number of people who have full commit
> access, something around 30 at this point. Not all of them are active
> at any given time (heck, most of them aren't active at any given time
> for that matter), but having them out there with commit rights is
> still valuable, because it means the barrier is lowered for that day
> somewhere down the road when they find some bug, dig into the code and
> fix it, and want to commit the patch. Making it more difficult for
> experienced developers to come back to the project and contribute
> seems like a bad thing to me.
>
> Now on the other hand there's the argument that if they come back some
> day and express interest in committing something we could set them up
> with commit access then, but let's be fair, getting all the paperwork
> settled takes time, and if they want to do that now and make it that
> much easier when they do find the time for the project, what's the
> real harm? If the community around the project has truly learned how
> to work in the way apache projects tend to work, I'm sure they'll be
> able to teach these dormant committers what they need to know on the
> fly as they come back.
>
> -garrett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
Re: ActiveMQ and ServiceMix reports
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 3/15/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Do these really have to be "Apache" credits accumulated? Let's do a
> hypothetical situation. Let's say that some guy puts in a few years of
> his life into a CodeHaus project. Then, he has a kid. At that time the
> project moves to ASF and he's MIA. Is it fair that he doesn't get
> commit karma when it graduates? IMO, no, it is not fair. Is it fair
> that he does not make it into the project PMC? Yes, it is fair, IMO.
>
> Not providing commit karma seems to be a bit like forced retirement
> because of inactivity. Something that ASF frowns upon.
>
> Let's do another scenario. Someone works very long and hard on one
> component of the project. That component becomes very mature and rock
> solid so, we really don't hear from him very often. Is it fair that he
> doesn't get commit karma when it graduates? IMO, no, it is not fair.
> Is it fair that he does not make it into the project PMC? Yes, it is
> fair, IMO.
>
> Not providing commit karma seems to be a bit like forced retirement
> because he completed the task that he set out to do.
This isn't from an ASF project, but I think it's relevant. In the
subversion project we've got a number of people who have full commit
access, something around 30 at this point. Not all of them are active
at any given time (heck, most of them aren't active at any given time
for that matter), but having them out there with commit rights is
still valuable, because it means the barrier is lowered for that day
somewhere down the road when they find some bug, dig into the code and
fix it, and want to commit the patch. Making it more difficult for
experienced developers to come back to the project and contribute
seems like a bad thing to me.
Now on the other hand there's the argument that if they come back some
day and express interest in committing something we could set them up
with commit access then, but let's be fair, getting all the paperwork
settled takes time, and if they want to do that now and make it that
much easier when they do find the time for the project, what's the
real harm? If the community around the project has truly learned how
to work in the way apache projects tend to work, I'm sure they'll be
able to teach these dormant committers what they need to know on the
fly as they come back.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 3/15/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Do these really have to be "Apache" credits accumulated? Let's do a
> hypothetical situation. Let's say that some guy puts in a few years of
> his life into a CodeHaus project. Then, he has a kid. At that time the
> project moves to ASF and he's MIA. Is it fair that he doesn't get
> commit karma when it graduates? IMO, no, it is not fair. Is it fair
> that he does not make it into the project PMC? Yes, it is fair, IMO.
>
> Not providing commit karma seems to be a bit like forced retirement
> because of inactivity. Something that ASF frowns upon.
>
> Let's do another scenario. Someone works very long and hard on one
> component of the project. That component becomes very mature and rock
> solid so, we really don't hear from him very often. Is it fair that he
> doesn't get commit karma when it graduates? IMO, no, it is not fair.
> Is it fair that he does not make it into the project PMC? Yes, it is
> fair, IMO.
>
> Not providing commit karma seems to be a bit like forced retirement
> because he completed the task that he set out to do.
This isn't from an ASF project, but I think it's relevant. In the
subversion project we've got a number of people who have full commit
access, something around 30 at this point. Not all of them are active
at any given time (heck, most of them aren't active at any given time
for that matter), but having them out there with commit rights is
still valuable, because it means the barrier is lowered for that day
somewhere down the road when they find some bug, dig into the code and
fix it, and want to commit the patch. Making it more difficult for
experienced developers to come back to the project and contribute
seems like a bad thing to me.
Now on the other hand there's the argument that if they come back some
day and express interest in committing something we could set them up
with commit access then, but let's be fair, getting all the paperwork
settled takes time, and if they want to do that now and make it that
much easier when they do find the time for the project, what's the
real harm? If the community around the project has truly learned how
to work in the way apache projects tend to work, I'm sure they'll be
able to teach these dormant committers what they need to know on the
fly as they come back.
-garrett
Re: ActiveMQ and ServiceMix reports
Posted by Henri Yandell <fl...@gmail.com>.
On 3/15/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Rodent of Unusual Size wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Henri Yandell wrote:
> >
> >> Interesting reply - I'd been assuming that when an incubatee graduates
> >> into an existing project, it's PPMC automatically get added to the
> >> PMC. So I was a bit confused as to why Noel was even asking the
> >> question.
> >>
> >
> > Case-by-case basis. Personally I think it's a good idea,
> > but there are lots of opinions. When Derby graduated,
> > some of the PPMC was invited to the DB PMC, and more over
> > time.
> >
> > And it's not just the PPMC/PMC issue; there's commit access,
> > too. And I think that's thornier.
> >
> > If a podling graduates and joins an existing TLP, is it
> > equitable for the people listed as committers on its
> > proposal, with no accumulated Apache merit, to automatically
> > keep commit access? While people who get involved directly
> > with the parent TLP have to earn merit over months?
> >
> > That's the sort of scenario I was envisioning when I
> > referred to 'fast-tracking' commit access.
> >
> > The answer is clearly, 'Maybe, maybe not,' and possibly relates
> > to the amount of merit accumulated while in the podling.
> >
>
> Do these really have to be "Apache" credits accumulated? Let's do a
> hypothetical situation. Let's say that some guy puts in a few years of
> his life into a CodeHaus project. Then, he has a kid. At that time the
> project moves to ASF and he's MIA. Is it fair that he doesn't get
> commit karma when it graduates? IMO, no, it is not fair. Is it fair
> that he does not make it into the project PMC? Yes, it is fair, IMO.
>
> Not providing commit karma seems to be a bit like forced retirement
> because of inactivity. Something that ASF frowns upon.
>
> Let's do another scenario. Someone works very long and hard on one
> component of the project. That component becomes very mature and rock
> solid so, we really don't hear from him very often. Is it fair that he
> doesn't get commit karma when it graduates? IMO, no, it is not fair.
> Is it fair that he does not make it into the project PMC? Yes, it is
> fair, IMO.
>
> Not providing commit karma seems to be a bit like forced retirement
> because he completed the task that he set out to do.
>
> So, what about the receiving community? If they voted to sponsor the
> project, then they knew what the probable outcome would be, that the
> group could become committers of their project. If no one inside that
> community complained about it, would it be a fair assumption that the
> group on a whole thought that the arrangement was equitable? Should we
> care if both parties are happy?
Nicely put.
I'm convinced - this definitely seems like a very good reason to have
inactive committers following an incubated project through to either
TLP stage, or into another TLP, but not being on the PMC. I'd be less
convinced on a project that wasn't previously open so that there was
no way to know if committers had previously contributed; but for open
source projects who join the incubator this is a great point.
In fact you've helped me resolve a direction on my general problem in
this area at Jakarta where we have a huge number of inactive
committers (300) and PMC members (40) - inactive committers good,
inactive PMC members bad.
Thanks,
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alan D. Cabrera wrote:
>
> Do these really have to be "Apache" credits accumulated?
How do the people at Apache get to see it otherwise?
I've pointed out what I think may be a problem. Having
done so, I'm content to have the legacy commit inheritance
you describe. The first time I see it abused, though,
I'm going to bring the hammer down.
But remember, I was one of the people who thought Y2K
would be a problem. I'm *good* at envisioning bad-case
scenarios. :-) Sort of a sideways Cassandra: predict
terrible things, nobody believes, and they don't happen
anyway. :-D
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQCVAwUBRBlhjJrNPMCpn3XdAQJ+XAP+OUHQw7YVKZztkWC1rt5nLo66pHbCTxvY
b4DPJCniy45qKqt3Yaca75SJZMNKOEjO/gkwS/dtAjTQvsaS0p16RVMqaq6pUUOs
pBzxEkyaVgTmNmBm5wQ/rmsN00ZyOC+vJ4bA/p8oIdAwjyrXfO7bSgF4oZaxKDxE
J0ubHHguBeg=
=Oy2H
-----END PGP SIGNATURE-----
Re: ActiveMQ and ServiceMix reports
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alan D. Cabrera wrote:
>
> Do these really have to be "Apache" credits accumulated?
How do the people at Apache get to see it otherwise?
I've pointed out what I think may be a problem. Having
done so, I'm content to have the legacy commit inheritance
you describe. The first time I see it abused, though,
I'm going to bring the hammer down.
But remember, I was one of the people who thought Y2K
would be a problem. I'm *good* at envisioning bad-case
scenarios. :-) Sort of a sideways Cassandra: predict
terrible things, nobody believes, and they don't happen
anyway. :-D
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQCVAwUBRBlhjJrNPMCpn3XdAQJ+XAP+OUHQw7YVKZztkWC1rt5nLo66pHbCTxvY
b4DPJCniy45qKqt3Yaca75SJZMNKOEjO/gkwS/dtAjTQvsaS0p16RVMqaq6pUUOs
pBzxEkyaVgTmNmBm5wQ/rmsN00ZyOC+vJ4bA/p8oIdAwjyrXfO7bSgF4oZaxKDxE
J0ubHHguBeg=
=Oy2H
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 3/15/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Do these really have to be "Apache" credits accumulated? Let's do a
> hypothetical situation. Let's say that some guy puts in a few years of
> his life into a CodeHaus project. Then, he has a kid. At that time the
> project moves to ASF and he's MIA. Is it fair that he doesn't get
> commit karma when it graduates? IMO, no, it is not fair. Is it fair
> that he does not make it into the project PMC? Yes, it is fair, IMO.
>
> Not providing commit karma seems to be a bit like forced retirement
> because of inactivity. Something that ASF frowns upon.
>
> Let's do another scenario. Someone works very long and hard on one
> component of the project. That component becomes very mature and rock
> solid so, we really don't hear from him very often. Is it fair that he
> doesn't get commit karma when it graduates? IMO, no, it is not fair.
> Is it fair that he does not make it into the project PMC? Yes, it is
> fair, IMO.
>
> Not providing commit karma seems to be a bit like forced retirement
> because he completed the task that he set out to do.
This isn't from an ASF project, but I think it's relevant. In the
subversion project we've got a number of people who have full commit
access, something around 30 at this point. Not all of them are active
at any given time (heck, most of them aren't active at any given time
for that matter), but having them out there with commit rights is
still valuable, because it means the barrier is lowered for that day
somewhere down the road when they find some bug, dig into the code and
fix it, and want to commit the patch. Making it more difficult for
experienced developers to come back to the project and contribute
seems like a bad thing to me.
Now on the other hand there's the argument that if they come back some
day and express interest in committing something we could set them up
with commit access then, but let's be fair, getting all the paperwork
settled takes time, and if they want to do that now and make it that
much easier when they do find the time for the project, what's the
real harm? If the community around the project has truly learned how
to work in the way apache projects tend to work, I'm sure they'll be
able to teach these dormant committers what they need to know on the
fly as they come back.
-garrett
Re: ActiveMQ and ServiceMix reports
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Rodent of Unusual Size wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Henri Yandell wrote:
>
>> Interesting reply - I'd been assuming that when an incubatee graduates
>> into an existing project, it's PPMC automatically get added to the
>> PMC. So I was a bit confused as to why Noel was even asking the
>> question.
>>
>
> Case-by-case basis. Personally I think it's a good idea,
> but there are lots of opinions. When Derby graduated,
> some of the PPMC was invited to the DB PMC, and more over
> time.
>
> And it's not just the PPMC/PMC issue; there's commit access,
> too. And I think that's thornier.
>
> If a podling graduates and joins an existing TLP, is it
> equitable for the people listed as committers on its
> proposal, with no accumulated Apache merit, to automatically
> keep commit access? While people who get involved directly
> with the parent TLP have to earn merit over months?
>
> That's the sort of scenario I was envisioning when I
> referred to 'fast-tracking' commit access.
>
> The answer is clearly, 'Maybe, maybe not,' and possibly relates
> to the amount of merit accumulated while in the podling.
>
Do these really have to be "Apache" credits accumulated? Let's do a
hypothetical situation. Let's say that some guy puts in a few years of
his life into a CodeHaus project. Then, he has a kid. At that time the
project moves to ASF and he's MIA. Is it fair that he doesn't get
commit karma when it graduates? IMO, no, it is not fair. Is it fair
that he does not make it into the project PMC? Yes, it is fair, IMO.
Not providing commit karma seems to be a bit like forced retirement
because of inactivity. Something that ASF frowns upon.
Let's do another scenario. Someone works very long and hard on one
component of the project. That component becomes very mature and rock
solid so, we really don't hear from him very often. Is it fair that he
doesn't get commit karma when it graduates? IMO, no, it is not fair.
Is it fair that he does not make it into the project PMC? Yes, it is
fair, IMO.
Not providing commit karma seems to be a bit like forced retirement
because he completed the task that he set out to do.
So, what about the receiving community? If they voted to sponsor the
project, then they knew what the probable outcome would be, that the
group could become committers of their project. If no one inside that
community complained about it, would it be a fair assumption that the
group on a whole thought that the arrangement was equitable? Should we
care if both parties are happy?
Regards,
Alan
Re: ActiveMQ and ServiceMix reports
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Rodent of Unusual Size wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Henri Yandell wrote:
>
>> Interesting reply - I'd been assuming that when an incubatee graduates
>> into an existing project, it's PPMC automatically get added to the
>> PMC. So I was a bit confused as to why Noel was even asking the
>> question.
>>
>
> Case-by-case basis. Personally I think it's a good idea,
> but there are lots of opinions. When Derby graduated,
> some of the PPMC was invited to the DB PMC, and more over
> time.
>
> And it's not just the PPMC/PMC issue; there's commit access,
> too. And I think that's thornier.
>
> If a podling graduates and joins an existing TLP, is it
> equitable for the people listed as committers on its
> proposal, with no accumulated Apache merit, to automatically
> keep commit access? While people who get involved directly
> with the parent TLP have to earn merit over months?
>
> That's the sort of scenario I was envisioning when I
> referred to 'fast-tracking' commit access.
>
> The answer is clearly, 'Maybe, maybe not,' and possibly relates
> to the amount of merit accumulated while in the podling.
>
Do these really have to be "Apache" credits accumulated? Let's do a
hypothetical situation. Let's say that some guy puts in a few years of
his life into a CodeHaus project. Then, he has a kid. At that time the
project moves to ASF and he's MIA. Is it fair that he doesn't get
commit karma when it graduates? IMO, no, it is not fair. Is it fair
that he does not make it into the project PMC? Yes, it is fair, IMO.
Not providing commit karma seems to be a bit like forced retirement
because of inactivity. Something that ASF frowns upon.
Let's do another scenario. Someone works very long and hard on one
component of the project. That component becomes very mature and rock
solid so, we really don't hear from him very often. Is it fair that he
doesn't get commit karma when it graduates? IMO, no, it is not fair.
Is it fair that he does not make it into the project PMC? Yes, it is
fair, IMO.
Not providing commit karma seems to be a bit like forced retirement
because he completed the task that he set out to do.
So, what about the receiving community? If they voted to sponsor the
project, then they knew what the probable outcome would be, that the
group could become committers of their project. If no one inside that
community complained about it, would it be a fair assumption that the
group on a whole thought that the arrangement was equitable? Should we
care if both parties are happy?
Regards,
Alan
Re: ActiveMQ and ServiceMix reports
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Rodent of Unusual Size wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Henri Yandell wrote:
>
>> Interesting reply - I'd been assuming that when an incubatee graduates
>> into an existing project, it's PPMC automatically get added to the
>> PMC. So I was a bit confused as to why Noel was even asking the
>> question.
>>
>
> Case-by-case basis. Personally I think it's a good idea,
> but there are lots of opinions. When Derby graduated,
> some of the PPMC was invited to the DB PMC, and more over
> time.
>
> And it's not just the PPMC/PMC issue; there's commit access,
> too. And I think that's thornier.
>
> If a podling graduates and joins an existing TLP, is it
> equitable for the people listed as committers on its
> proposal, with no accumulated Apache merit, to automatically
> keep commit access? While people who get involved directly
> with the parent TLP have to earn merit over months?
>
> That's the sort of scenario I was envisioning when I
> referred to 'fast-tracking' commit access.
>
> The answer is clearly, 'Maybe, maybe not,' and possibly relates
> to the amount of merit accumulated while in the podling.
>
Do these really have to be "Apache" credits accumulated? Let's do a
hypothetical situation. Let's say that some guy puts in a few years of
his life into a CodeHaus project. Then, he has a kid. At that time the
project moves to ASF and he's MIA. Is it fair that he doesn't get
commit karma when it graduates? IMO, no, it is not fair. Is it fair
that he does not make it into the project PMC? Yes, it is fair, IMO.
Not providing commit karma seems to be a bit like forced retirement
because of inactivity. Something that ASF frowns upon.
Let's do another scenario. Someone works very long and hard on one
component of the project. That component becomes very mature and rock
solid so, we really don't hear from him very often. Is it fair that he
doesn't get commit karma when it graduates? IMO, no, it is not fair.
Is it fair that he does not make it into the project PMC? Yes, it is
fair, IMO.
Not providing commit karma seems to be a bit like forced retirement
because he completed the task that he set out to do.
So, what about the receiving community? If they voted to sponsor the
project, then they knew what the probable outcome would be, that the
group could become committers of their project. If no one inside that
community complained about it, would it be a fair assumption that the
group on a whole thought that the arrangement was equitable? Should we
care if both parties are happy?
Regards,
Alan
Re: ActiveMQ and ServiceMix reports
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Henri Yandell wrote:
>
> Interesting reply - I'd been assuming that when an incubatee graduates
> into an existing project, it's PPMC automatically get added to the
> PMC. So I was a bit confused as to why Noel was even asking the
> question.
Case-by-case basis. Personally I think it's a good idea,
but there are lots of opinions. When Derby graduated,
some of the PPMC was invited to the DB PMC, and more over
time.
And it's not just the PPMC/PMC issue; there's commit access,
too. And I think that's thornier.
If a podling graduates and joins an existing TLP, is it
equitable for the people listed as committers on its
proposal, with no accumulated Apache merit, to automatically
keep commit access? While people who get involved directly
with the parent TLP have to earn merit over months?
That's the sort of scenario I was envisioning when I
referred to 'fast-tracking' commit access.
The answer is clearly, 'Maybe, maybe not,' and possibly relates
to the amount of merit accumulated while in the podling.
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQCVAwUBRBjmZJrNPMCpn3XdAQK/AgQAvkQEbRrnTJw3nxWEoK0yaHxBEDnuZGD7
eTUhjc+R6tWuuTnHFkZUwvTkRzFdN6gYeHWAkKC1tVqe67wBsJv+kcB2m6JtmHk+
cntnqnN1/hQtZ/DXt7VZi1Dm9N4dTJ+ug6EPm4NGPtxCDbRVL5dIc0aEsuEBIslG
QjKHuS0aCsQ=
=Wpxf
-----END PGP SIGNATURE-----
Re: ActiveMQ and ServiceMix reports
Posted by Henri Yandell <fl...@gmail.com>.
Modifying the workflow slightly from my shoe-in assumption:
1) Remove all committers who have not contributed to the project while
it was under Incubation.If they were new committers, remove their
Apache accounts etc (well, freeze them - whatever).
2) Graduate into target, with PPMC members becoming PMC members.
I can see that there is a thin grey line in which you might have
someone who is not yet a trusted committer (recently added to the
project), but "getting the ASF" isn't usually somthing that is
required to be on a PMC, that's something I hear used much more when
discussing ASF membership.
If, after N months/years in incubation, someone has not shown that
they are a trusted committer - then they shouldn't be committers going
forward.
[which I think covers my reply to Ken's email on the subject too]
Hen
On 3/15/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> Hi Henri,
>
> I think a good example of why not just a shoe in is because when the
> ServiceMix and ActiveMQ apache commiter list was created, it included
> all previous commiters to the project. But 100% of committers may not
> have been active during the period of the incubation. All though the
> projects trusted those individuals enough in the past to give them
> commit privileges, perhaps the TLP PMC may want to see more recent
> activity to evaluate if they truly 'get' the Apache way.
>
> Regards,
> Hiram
>
> On 3/15/06, Henri Yandell <fl...@gmail.com> wrote:
> > On 3/15/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > Hi Noel,
> > >
> > > If the ActiveMQ / ServiceMix community do decide to go under some
> > > other TLP, I'm sure it would not take long for the active
> > > participants of the community to asked to Join the TLP's PMC. It
> > > would behoove that PMC to include such active community participants
> > > in the decision making proccess.
> >
> > Interesting reply - I'd been assuming that when an incubatee graduates
> > into an existing project, it's PPMC automatically get added to the
> > PMC. So I was a bit confused as to why Noel was even asking the
> > question.
> >
> > > Furthermore, I believe that merging ActiveMQ and Servicemix into
> > > Geronimo community and PMC is easier than most cases since there are
> > > all ready several active ActiveMQ/ServiceMix commiters thar are
> > > Geronimo PMC members. Those PMC memebers can help propose and vouch
> > > for additional commiters to join the PMC.
> >
> > Yeah, overlap would help. Still surprised that it's not just a shoe-in.
> >
> > Hen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
> --
> Regards,
> Hiram
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: ActiveMQ and ServiceMix reports
Posted by Henri Yandell <fl...@gmail.com>.
Modifying the workflow slightly from my shoe-in assumption:
1) Remove all committers who have not contributed to the project while
it was under Incubation.If they were new committers, remove their
Apache accounts etc (well, freeze them - whatever).
2) Graduate into target, with PPMC members becoming PMC members.
I can see that there is a thin grey line in which you might have
someone who is not yet a trusted committer (recently added to the
project), but "getting the ASF" isn't usually somthing that is
required to be on a PMC, that's something I hear used much more when
discussing ASF membership.
If, after N months/years in incubation, someone has not shown that
they are a trusted committer - then they shouldn't be committers going
forward.
[which I think covers my reply to Ken's email on the subject too]
Hen
On 3/15/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> Hi Henri,
>
> I think a good example of why not just a shoe in is because when the
> ServiceMix and ActiveMQ apache commiter list was created, it included
> all previous commiters to the project. But 100% of committers may not
> have been active during the period of the incubation. All though the
> projects trusted those individuals enough in the past to give them
> commit privileges, perhaps the TLP PMC may want to see more recent
> activity to evaluate if they truly 'get' the Apache way.
>
> Regards,
> Hiram
>
> On 3/15/06, Henri Yandell <fl...@gmail.com> wrote:
> > On 3/15/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > Hi Noel,
> > >
> > > If the ActiveMQ / ServiceMix community do decide to go under some
> > > other TLP, I'm sure it would not take long for the active
> > > participants of the community to asked to Join the TLP's PMC. It
> > > would behoove that PMC to include such active community participants
> > > in the decision making proccess.
> >
> > Interesting reply - I'd been assuming that when an incubatee graduates
> > into an existing project, it's PPMC automatically get added to the
> > PMC. So I was a bit confused as to why Noel was even asking the
> > question.
> >
> > > Furthermore, I believe that merging ActiveMQ and Servicemix into
> > > Geronimo community and PMC is easier than most cases since there are
> > > all ready several active ActiveMQ/ServiceMix commiters thar are
> > > Geronimo PMC members. Those PMC memebers can help propose and vouch
> > > for additional commiters to join the PMC.
> >
> > Yeah, overlap would help. Still surprised that it's not just a shoe-in.
> >
> > Hen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
> --
> Regards,
> Hiram
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by Henri Yandell <fl...@gmail.com>.
Modifying the workflow slightly from my shoe-in assumption:
1) Remove all committers who have not contributed to the project while
it was under Incubation.If they were new committers, remove their
Apache accounts etc (well, freeze them - whatever).
2) Graduate into target, with PPMC members becoming PMC members.
I can see that there is a thin grey line in which you might have
someone who is not yet a trusted committer (recently added to the
project), but "getting the ASF" isn't usually somthing that is
required to be on a PMC, that's something I hear used much more when
discussing ASF membership.
If, after N months/years in incubation, someone has not shown that
they are a trusted committer - then they shouldn't be committers going
forward.
[which I think covers my reply to Ken's email on the subject too]
Hen
On 3/15/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> Hi Henri,
>
> I think a good example of why not just a shoe in is because when the
> ServiceMix and ActiveMQ apache commiter list was created, it included
> all previous commiters to the project. But 100% of committers may not
> have been active during the period of the incubation. All though the
> projects trusted those individuals enough in the past to give them
> commit privileges, perhaps the TLP PMC may want to see more recent
> activity to evaluate if they truly 'get' the Apache way.
>
> Regards,
> Hiram
>
> On 3/15/06, Henri Yandell <fl...@gmail.com> wrote:
> > On 3/15/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > Hi Noel,
> > >
> > > If the ActiveMQ / ServiceMix community do decide to go under some
> > > other TLP, I'm sure it would not take long for the active
> > > participants of the community to asked to Join the TLP's PMC. It
> > > would behoove that PMC to include such active community participants
> > > in the decision making proccess.
> >
> > Interesting reply - I'd been assuming that when an incubatee graduates
> > into an existing project, it's PPMC automatically get added to the
> > PMC. So I was a bit confused as to why Noel was even asking the
> > question.
> >
> > > Furthermore, I believe that merging ActiveMQ and Servicemix into
> > > Geronimo community and PMC is easier than most cases since there are
> > > all ready several active ActiveMQ/ServiceMix commiters thar are
> > > Geronimo PMC members. Those PMC memebers can help propose and vouch
> > > for additional commiters to join the PMC.
> >
> > Yeah, overlap would help. Still surprised that it's not just a shoe-in.
> >
> > Hen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
> --
> Regards,
> Hiram
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: ActiveMQ and ServiceMix reports
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hi Henri,
I think a good example of why not just a shoe in is because when the
ServiceMix and ActiveMQ apache commiter list was created, it included
all previous commiters to the project. But 100% of committers may not
have been active during the period of the incubation. All though the
projects trusted those individuals enough in the past to give them
commit privileges, perhaps the TLP PMC may want to see more recent
activity to evaluate if they truly 'get' the Apache way.
Regards,
Hiram
On 3/15/06, Henri Yandell <fl...@gmail.com> wrote:
> On 3/15/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > Hi Noel,
> >
> > If the ActiveMQ / ServiceMix community do decide to go under some
> > other TLP, I'm sure it would not take long for the active
> > participants of the community to asked to Join the TLP's PMC. It
> > would behoove that PMC to include such active community participants
> > in the decision making proccess.
>
> Interesting reply - I'd been assuming that when an incubatee graduates
> into an existing project, it's PPMC automatically get added to the
> PMC. So I was a bit confused as to why Noel was even asking the
> question.
>
> > Furthermore, I believe that merging ActiveMQ and Servicemix into
> > Geronimo community and PMC is easier than most cases since there are
> > all ready several active ActiveMQ/ServiceMix commiters thar are
> > Geronimo PMC members. Those PMC memebers can help propose and vouch
> > for additional commiters to join the PMC.
>
> Yeah, overlap would help. Still surprised that it's not just a shoe-in.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Regards,
Hiram
Re: ActiveMQ and ServiceMix reports
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Henri Yandell wrote:
>
> Interesting reply - I'd been assuming that when an incubatee graduates
> into an existing project, it's PPMC automatically get added to the
> PMC. So I was a bit confused as to why Noel was even asking the
> question.
Case-by-case basis. Personally I think it's a good idea,
but there are lots of opinions. When Derby graduated,
some of the PPMC was invited to the DB PMC, and more over
time.
And it's not just the PPMC/PMC issue; there's commit access,
too. And I think that's thornier.
If a podling graduates and joins an existing TLP, is it
equitable for the people listed as committers on its
proposal, with no accumulated Apache merit, to automatically
keep commit access? While people who get involved directly
with the parent TLP have to earn merit over months?
That's the sort of scenario I was envisioning when I
referred to 'fast-tracking' commit access.
The answer is clearly, 'Maybe, maybe not,' and possibly relates
to the amount of merit accumulated while in the podling.
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQCVAwUBRBjmZJrNPMCpn3XdAQK/AgQAvkQEbRrnTJw3nxWEoK0yaHxBEDnuZGD7
eTUhjc+R6tWuuTnHFkZUwvTkRzFdN6gYeHWAkKC1tVqe67wBsJv+kcB2m6JtmHk+
cntnqnN1/hQtZ/DXt7VZi1Dm9N4dTJ+ug6EPm4NGPtxCDbRVL5dIc0aEsuEBIslG
QjKHuS0aCsQ=
=Wpxf
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hi Henri,
I think a good example of why not just a shoe in is because when the
ServiceMix and ActiveMQ apache commiter list was created, it included
all previous commiters to the project. But 100% of committers may not
have been active during the period of the incubation. All though the
projects trusted those individuals enough in the past to give them
commit privileges, perhaps the TLP PMC may want to see more recent
activity to evaluate if they truly 'get' the Apache way.
Regards,
Hiram
On 3/15/06, Henri Yandell <fl...@gmail.com> wrote:
> On 3/15/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > Hi Noel,
> >
> > If the ActiveMQ / ServiceMix community do decide to go under some
> > other TLP, I'm sure it would not take long for the active
> > participants of the community to asked to Join the TLP's PMC. It
> > would behoove that PMC to include such active community participants
> > in the decision making proccess.
>
> Interesting reply - I'd been assuming that when an incubatee graduates
> into an existing project, it's PPMC automatically get added to the
> PMC. So I was a bit confused as to why Noel was even asking the
> question.
>
> > Furthermore, I believe that merging ActiveMQ and Servicemix into
> > Geronimo community and PMC is easier than most cases since there are
> > all ready several active ActiveMQ/ServiceMix commiters thar are
> > Geronimo PMC members. Those PMC memebers can help propose and vouch
> > for additional commiters to join the PMC.
>
> Yeah, overlap would help. Still surprised that it's not just a shoe-in.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Regards,
Hiram
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hi Henri,
I think a good example of why not just a shoe in is because when the
ServiceMix and ActiveMQ apache commiter list was created, it included
all previous commiters to the project. But 100% of committers may not
have been active during the period of the incubation. All though the
projects trusted those individuals enough in the past to give them
commit privileges, perhaps the TLP PMC may want to see more recent
activity to evaluate if they truly 'get' the Apache way.
Regards,
Hiram
On 3/15/06, Henri Yandell <fl...@gmail.com> wrote:
> On 3/15/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > Hi Noel,
> >
> > If the ActiveMQ / ServiceMix community do decide to go under some
> > other TLP, I'm sure it would not take long for the active
> > participants of the community to asked to Join the TLP's PMC. It
> > would behoove that PMC to include such active community participants
> > in the decision making proccess.
>
> Interesting reply - I'd been assuming that when an incubatee graduates
> into an existing project, it's PPMC automatically get added to the
> PMC. So I was a bit confused as to why Noel was even asking the
> question.
>
> > Furthermore, I believe that merging ActiveMQ and Servicemix into
> > Geronimo community and PMC is easier than most cases since there are
> > all ready several active ActiveMQ/ServiceMix commiters thar are
> > Geronimo PMC members. Those PMC memebers can help propose and vouch
> > for additional commiters to join the PMC.
>
> Yeah, overlap would help. Still surprised that it's not just a shoe-in.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Regards,
Hiram
Re: ActiveMQ and ServiceMix reports
Posted by Henri Yandell <fl...@gmail.com>.
On 3/15/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> Hi Noel,
>
> If the ActiveMQ / ServiceMix community do decide to go under some
> other TLP, I'm sure it would not take long for the active
> participants of the community to asked to Join the TLP's PMC. It
> would behoove that PMC to include such active community participants
> in the decision making proccess.
Interesting reply - I'd been assuming that when an incubatee graduates
into an existing project, it's PPMC automatically get added to the
PMC. So I was a bit confused as to why Noel was even asking the
question.
> Furthermore, I believe that merging ActiveMQ and Servicemix into
> Geronimo community and PMC is easier than most cases since there are
> all ready several active ActiveMQ/ServiceMix commiters thar are
> Geronimo PMC members. Those PMC memebers can help propose and vouch
> for additional commiters to join the PMC.
Yeah, overlap would help. Still surprised that it's not just a shoe-in.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by Henri Yandell <fl...@gmail.com>.
On 3/15/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> Hi Noel,
>
> If the ActiveMQ / ServiceMix community do decide to go under some
> other TLP, I'm sure it would not take long for the active
> participants of the community to asked to Join the TLP's PMC. It
> would behoove that PMC to include such active community participants
> in the decision making proccess.
Interesting reply - I'd been assuming that when an incubatee graduates
into an existing project, it's PPMC automatically get added to the
PMC. So I was a bit confused as to why Noel was even asking the
question.
> Furthermore, I believe that merging ActiveMQ and Servicemix into
> Geronimo community and PMC is easier than most cases since there are
> all ready several active ActiveMQ/ServiceMix commiters thar are
> Geronimo PMC members. Those PMC memebers can help propose and vouch
> for additional commiters to join the PMC.
Yeah, overlap would help. Still surprised that it's not just a shoe-in.
Hen
Re: ActiveMQ and ServiceMix reports
Posted by Dain Sundstrom <da...@iq80.com>.
On Mar 15, 2006, at 7:04 PM, Noel J. Bergman wrote:
> Hiram Chirino wrote:
>
>> If the ActiveMQ / ServiceMix community do decide to go under some
>> other TLP, I'm sure it would not take long for the active
>> participants of the community to asked to Join the TLP's PMC.
>
> I would certainly hope that they would want to be, yes. Hence ...
>
>> I believe that merging ActiveMQ and Servicemix into Geronimo
>> community and PMC is easier than most cases since there are
>> all ready several active ActiveMQ/ServiceMix commiters thar
>> are Geronimo PMC members.
>
> At this moment, Geronimo has 19 PMC members and 7 commmiters who
> are not on
> the PMC. That does, of course, change over time.
>
> The overlap of ActiveMQ and ServiceMix with the Geronimo PMC has 10
> PMC
> members. ActiveMQ has 13 additional people who are not on the
> Geronimo PMC.
> Adding ServiceMix is just another 4 (17 total), as there is a huge
> overlap
> between ActiveMQ and ServiceMix.
>
> I have no idea how active any of these people are on any of the
> projects in
> any capacity. Dims appears to feel that there is a large number of
> committers in name only, but I haven't looked at all so for the
> sake of
> discussion, let's assume that they are all active. Adding ActiveMQ
> and
> ServiceMix to Geronimo could increase the size of Geronimo's
> community from
> 26 to ~40, and assuming a comparable ratio, the PMC from 19 to 30+.
>
> So is Geronimo prepared to take such actions? Should it be, at
> this time?
> And what would that do for diversity, since a lot of people appear
> to work
> for the same company?
As a Geronimo PMC member, my current feelings on granting commit and
pmc membership fall into three categories: existing G committers,
active committers and inactive committers. Existing G committers are
a non issue. Active committers should absolutely get commit access
to G and assuming they remain active during the incubation period
(several committs) they should be added to the G pmc. Inactive
committers should not get added to the PMC. As for commit, I think
this is a case by case basis. If the person committed major work in
the past, I give them commit, on the other hand if they only
committed one file, I wouldn't give them commit. The difficult
decisions will be in the middle, and I will look for guidance from
AMQ and SM on these people.
As we begin to discuss the final graduation of these projects into
Geronimo, I may be convinced of another set of guidelines.
-dain
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by Dain Sundstrom <da...@iq80.com>.
On Mar 15, 2006, at 7:04 PM, Noel J. Bergman wrote:
> Hiram Chirino wrote:
>
>> If the ActiveMQ / ServiceMix community do decide to go under some
>> other TLP, I'm sure it would not take long for the active
>> participants of the community to asked to Join the TLP's PMC.
>
> I would certainly hope that they would want to be, yes. Hence ...
>
>> I believe that merging ActiveMQ and Servicemix into Geronimo
>> community and PMC is easier than most cases since there are
>> all ready several active ActiveMQ/ServiceMix commiters thar
>> are Geronimo PMC members.
>
> At this moment, Geronimo has 19 PMC members and 7 commmiters who
> are not on
> the PMC. That does, of course, change over time.
>
> The overlap of ActiveMQ and ServiceMix with the Geronimo PMC has 10
> PMC
> members. ActiveMQ has 13 additional people who are not on the
> Geronimo PMC.
> Adding ServiceMix is just another 4 (17 total), as there is a huge
> overlap
> between ActiveMQ and ServiceMix.
>
> I have no idea how active any of these people are on any of the
> projects in
> any capacity. Dims appears to feel that there is a large number of
> committers in name only, but I haven't looked at all so for the
> sake of
> discussion, let's assume that they are all active. Adding ActiveMQ
> and
> ServiceMix to Geronimo could increase the size of Geronimo's
> community from
> 26 to ~40, and assuming a comparable ratio, the PMC from 19 to 30+.
>
> So is Geronimo prepared to take such actions? Should it be, at
> this time?
> And what would that do for diversity, since a lot of people appear
> to work
> for the same company?
As a Geronimo PMC member, my current feelings on granting commit and
pmc membership fall into three categories: existing G committers,
active committers and inactive committers. Existing G committers are
a non issue. Active committers should absolutely get commit access
to G and assuming they remain active during the incubation period
(several committs) they should be added to the G pmc. Inactive
committers should not get added to the PMC. As for commit, I think
this is a case by case basis. If the person committed major work in
the past, I give them commit, on the other hand if they only
committed one file, I wouldn't give them commit. The difficult
decisions will be in the middle, and I will look for guidance from
AMQ and SM on these people.
As we begin to discuss the final graduation of these projects into
Geronimo, I may be convinced of another set of guidelines.
-dain
Re: ActiveMQ and ServiceMix reports
Posted by Dain Sundstrom <da...@iq80.com>.
On Mar 15, 2006, at 7:04 PM, Noel J. Bergman wrote:
> Hiram Chirino wrote:
>
>> If the ActiveMQ / ServiceMix community do decide to go under some
>> other TLP, I'm sure it would not take long for the active
>> participants of the community to asked to Join the TLP's PMC.
>
> I would certainly hope that they would want to be, yes. Hence ...
>
>> I believe that merging ActiveMQ and Servicemix into Geronimo
>> community and PMC is easier than most cases since there are
>> all ready several active ActiveMQ/ServiceMix commiters thar
>> are Geronimo PMC members.
>
> At this moment, Geronimo has 19 PMC members and 7 commmiters who
> are not on
> the PMC. That does, of course, change over time.
>
> The overlap of ActiveMQ and ServiceMix with the Geronimo PMC has 10
> PMC
> members. ActiveMQ has 13 additional people who are not on the
> Geronimo PMC.
> Adding ServiceMix is just another 4 (17 total), as there is a huge
> overlap
> between ActiveMQ and ServiceMix.
>
> I have no idea how active any of these people are on any of the
> projects in
> any capacity. Dims appears to feel that there is a large number of
> committers in name only, but I haven't looked at all so for the
> sake of
> discussion, let's assume that they are all active. Adding ActiveMQ
> and
> ServiceMix to Geronimo could increase the size of Geronimo's
> community from
> 26 to ~40, and assuming a comparable ratio, the PMC from 19 to 30+.
>
> So is Geronimo prepared to take such actions? Should it be, at
> this time?
> And what would that do for diversity, since a lot of people appear
> to work
> for the same company?
As a Geronimo PMC member, my current feelings on granting commit and
pmc membership fall into three categories: existing G committers,
active committers and inactive committers. Existing G committers are
a non issue. Active committers should absolutely get commit access
to G and assuming they remain active during the incubation period
(several committs) they should be added to the G pmc. Inactive
committers should not get added to the PMC. As for commit, I think
this is a case by case basis. If the person committed major work in
the past, I give them commit, on the other hand if they only
committed one file, I wouldn't give them commit. The difficult
decisions will be in the middle, and I will look for guidance from
AMQ and SM on these people.
As we begin to discuss the final graduation of these projects into
Geronimo, I may be convinced of another set of guidelines.
-dain
RE: ActiveMQ and ServiceMix reports
Posted by "Noel J. Bergman" <no...@devtech.com>.
Hiram Chirino wrote:
> If the ActiveMQ / ServiceMix community do decide to go under some
> other TLP, I'm sure it would not take long for the active
> participants of the community to asked to Join the TLP's PMC.
I would certainly hope that they would want to be, yes. Hence ...
> I believe that merging ActiveMQ and Servicemix into Geronimo
> community and PMC is easier than most cases since there are
> all ready several active ActiveMQ/ServiceMix commiters thar
> are Geronimo PMC members.
At this moment, Geronimo has 19 PMC members and 7 commmiters who are not on
the PMC. That does, of course, change over time.
The overlap of ActiveMQ and ServiceMix with the Geronimo PMC has 10 PMC
members. ActiveMQ has 13 additional people who are not on the Geronimo PMC.
Adding ServiceMix is just another 4 (17 total), as there is a huge overlap
between ActiveMQ and ServiceMix.
I have no idea how active any of these people are on any of the projects in
any capacity. Dims appears to feel that there is a large number of
committers in name only, but I haven't looked at all so for the sake of
discussion, let's assume that they are all active. Adding ActiveMQ and
ServiceMix to Geronimo could increase the size of Geronimo's community from
26 to ~40, and assuming a comparable ratio, the PMC from 19 to 30+.
So is Geronimo prepared to take such actions? Should it be, at this time?
And what would that do for diversity, since a lot of people appear to work
for the same company?
--- Noel
RE: ActiveMQ and ServiceMix reports
Posted by "Noel J. Bergman" <no...@devtech.com>.
Hiram Chirino wrote:
> If the ActiveMQ / ServiceMix community do decide to go under some
> other TLP, I'm sure it would not take long for the active
> participants of the community to asked to Join the TLP's PMC.
I would certainly hope that they would want to be, yes. Hence ...
> I believe that merging ActiveMQ and Servicemix into Geronimo
> community and PMC is easier than most cases since there are
> all ready several active ActiveMQ/ServiceMix commiters thar
> are Geronimo PMC members.
At this moment, Geronimo has 19 PMC members and 7 commmiters who are not on
the PMC. That does, of course, change over time.
The overlap of ActiveMQ and ServiceMix with the Geronimo PMC has 10 PMC
members. ActiveMQ has 13 additional people who are not on the Geronimo PMC.
Adding ServiceMix is just another 4 (17 total), as there is a huge overlap
between ActiveMQ and ServiceMix.
I have no idea how active any of these people are on any of the projects in
any capacity. Dims appears to feel that there is a large number of
committers in name only, but I haven't looked at all so for the sake of
discussion, let's assume that they are all active. Adding ActiveMQ and
ServiceMix to Geronimo could increase the size of Geronimo's community from
26 to ~40, and assuming a comparable ratio, the PMC from 19 to 30+.
So is Geronimo prepared to take such actions? Should it be, at this time?
And what would that do for diversity, since a lot of people appear to work
for the same company?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: ActiveMQ and ServiceMix reports
Posted by "Noel J. Bergman" <no...@devtech.com>.
Hiram Chirino wrote:
> If the ActiveMQ / ServiceMix community do decide to go under some
> other TLP, I'm sure it would not take long for the active
> participants of the community to asked to Join the TLP's PMC.
I would certainly hope that they would want to be, yes. Hence ...
> I believe that merging ActiveMQ and Servicemix into Geronimo
> community and PMC is easier than most cases since there are
> all ready several active ActiveMQ/ServiceMix commiters thar
> are Geronimo PMC members.
At this moment, Geronimo has 19 PMC members and 7 commmiters who are not on
the PMC. That does, of course, change over time.
The overlap of ActiveMQ and ServiceMix with the Geronimo PMC has 10 PMC
members. ActiveMQ has 13 additional people who are not on the Geronimo PMC.
Adding ServiceMix is just another 4 (17 total), as there is a huge overlap
between ActiveMQ and ServiceMix.
I have no idea how active any of these people are on any of the projects in
any capacity. Dims appears to feel that there is a large number of
committers in name only, but I haven't looked at all so for the sake of
discussion, let's assume that they are all active. Adding ActiveMQ and
ServiceMix to Geronimo could increase the size of Geronimo's community from
26 to ~40, and assuming a comparable ratio, the PMC from 19 to 30+.
So is Geronimo prepared to take such actions? Should it be, at this time?
And what would that do for diversity, since a lot of people appear to work
for the same company?
--- Noel
Re: ActiveMQ and ServiceMix reports
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hi Noel,
If the ActiveMQ / ServiceMix community do decide to go under some
other TLP, I'm sure it would not take long for the active
participants of the community to asked to Join the TLP's PMC. It
would behoove that PMC to include such active community participants
in the decision making proccess.
Furthermore, I believe that merging ActiveMQ and Servicemix into
Geronimo community and PMC is easier than most cases since there are
all ready several active ActiveMQ/ServiceMix commiters thar are
Geronimo PMC members. Those PMC memebers can help propose and vouch
for additional commiters to join the PMC.
Regards,
Hiram
On 3/15/06, Noel J. Bergman <no...@devtech.com> wrote:
> Ken wrote:
> > Noel J. Bergman wrote:
> > > Considering that both ActiveMQ and ServiceMix really ought to be
> > > targeting TLP status, learning to do this is important.
>
> > That's a bit much, Noel. Where they end up is primarily
> > their own concern -- and not determined until graduation
> > anyway.
>
> Sorry for conflating two messages. And I'll rephrase.
>
> I would still consider it to be an important issue, unless it is believed
> that project members are either not going to become PMC members in the
> destination, or are going to learn participating on a PMC means only when
> they get there.
>
> Regardless of where the project ends up, I don't believe that it would be
> fair to bring communities into the ASF, and then disenfranchise them from
> their project by not giving them binding votes. That is required during
> incubation, but should not be the case afterwards. So preparing and
> empowering the new community by teaching it ASF procedures during the
> process of incubation is important to me.
>
> Does that make more sense now?
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Regards,
Hiram
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: ActiveMQ and ServiceMix reports
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hi Noel,
If the ActiveMQ / ServiceMix community do decide to go under some
other TLP, I'm sure it would not take long for the active
participants of the community to asked to Join the TLP's PMC. It
would behoove that PMC to include such active community participants
in the decision making proccess.
Furthermore, I believe that merging ActiveMQ and Servicemix into
Geronimo community and PMC is easier than most cases since there are
all ready several active ActiveMQ/ServiceMix commiters thar are
Geronimo PMC members. Those PMC memebers can help propose and vouch
for additional commiters to join the PMC.
Regards,
Hiram
On 3/15/06, Noel J. Bergman <no...@devtech.com> wrote:
> Ken wrote:
> > Noel J. Bergman wrote:
> > > Considering that both ActiveMQ and ServiceMix really ought to be
> > > targeting TLP status, learning to do this is important.
>
> > That's a bit much, Noel. Where they end up is primarily
> > their own concern -- and not determined until graduation
> > anyway.
>
> Sorry for conflating two messages. And I'll rephrase.
>
> I would still consider it to be an important issue, unless it is believed
> that project members are either not going to become PMC members in the
> destination, or are going to learn participating on a PMC means only when
> they get there.
>
> Regardless of where the project ends up, I don't believe that it would be
> fair to bring communities into the ASF, and then disenfranchise them from
> their project by not giving them binding votes. That is required during
> incubation, but should not be the case afterwards. So preparing and
> empowering the new community by teaching it ASF procedures during the
> process of incubation is important to me.
>
> Does that make more sense now?
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Regards,
Hiram