You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Klavon <dk...@gmail.com> on 2005/07/11 16:10:13 UTC
Donation of Admin Console- request for help
One of the components that IBM acquired with the purchase of the
Gluecode company was the portlet based administrative console. We are
in the final stages of obtaining the legal clearance to donate this
component to the Geronimo project and we wanted to give everyone a
heads up about this offering and to solicit feedback on the best
approach to bring this component into Geronimo. Can someone please
provide guidance with the correct procedure to make the code available
to Geronimo? We are anticipating final legal clearance for
contribution this week so I wanted to provide the heads up now and
make sure that all barriers to contribution were out of the way so
once its cleared we can make it available as quickly as possible to
the community.
Thanks for your help and guidance.
Dave
Re: Donation of Admin Console- request for help
Posted by Dain Sundstrom <da...@iq80.com>.
On Jul 11, 2005, at 7:39 AM, Aaron Mulder wrote:
> I'm excited to see this.
>
> I believe the question is essentially the same as the question
> around the TriFork CORBA donation. I'm not sure where that discussion
> stands -- last time I checked in we were debating the meaning of
> "subproject". Guess we better wrap that up!
Do you think this should be a subproject? If we decide not to make
it a subproject, we don't need to discuss subprojects first :)
-dain
Re: Donation of Admin Console- request for help
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 10:57 AM, Dain Sundstrom wrote:
> On Jul 11, 2005, at 7:48 AM, Geir Magnusson Jr. wrote:
>
>
>> On Jul 11, 2005, at 10:39 AM, Aaron Mulder wrote:
>>
>> 1) We must decide on where we bring the software and how we handle
>> interested contributors :
>>
>> a) Bring to Apache Geronimo SVN (w/ or w/o separate ACL) and
>>
>> i) Grant committer status to any offered individuals that
>> wish to continue working on the respective contribution
>> ii) Ask that work continues via submitted patches for some
>> period of time
>>
>> b) Bring to the Apache Incubator and work with the code and
>> people there
>>
>
> +1 a.ii
>
> I came to this by process of elimination. I don't think we can
> consider a.i since we have had no interaction with the respective
> contributors, and I don't think the project is big enough to
> justify b.
Fair enough - do you have any other options to propose?
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Donation of Admin Console- request for help
Posted by Dain Sundstrom <da...@iq80.com>.
On Jul 11, 2005, at 7:48 AM, Geir Magnusson Jr. wrote:
> On Jul 11, 2005, at 10:39 AM, Aaron Mulder wrote:
>
> 1) We must decide on where we bring the software and how we handle
> interested contributors :
>
> a) Bring to Apache Geronimo SVN (w/ or w/o separate ACL) and
>
> i) Grant committer status to any offered individuals that
> wish to continue working on the respective contribution
> ii) Ask that work continues via submitted patches for some
> period of time
>
> b) Bring to the Apache Incubator and work with the code and
> people there
+1 a.ii
I came to this by process of elimination. I don't think we can
consider a.i since we have had no interaction with the respective
contributors, and I don't think the project is big enough to justify b.
-dain
Re: Donation of Admin Console- request for help
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 8:34 PM, Alan D. Cabrera wrote:
> Aaron Mulder wrote, On 7/11/2005 8:03 AM:
>>> 1) We must decide on where we bring the software and how we
>>> handle interested contributors : a) Bring to Apache Geronimo SVN
>>> (w/ or w/o separate ACL) and i) Grant committer status to any
>>> offered individuals that wish to continue working on the
>>> respective contribution ii) Ask that work continues via submitted
>>> patches for some period of time b) Bring to the Apache Incubator
>>> and work with the code and people there
>> I would like to look at the code before deciding whether and how
>> to incorporate either of these donations into Geronimo "for real".
>> But my preference on the implementation of that would be to set up
>> some temporary space in the project SVN, put the code there, let
>> people fuss with it, and then (if all goes well) when it's
>> massaged into shape vote to fold it into the SVN tree proper
>> (though I'm not yet sure whether it should be part of the current
>> "geronimo" tree or in a "related projects" / "sub project" area --
>> that probably depends to some extent on the code and how entangled
>> it is). So, in order to move forward, I would prefer: - set up a
>> separate area of SVN for donations (currently 2 on the table) -
>> pick one of: - add separate ACL for each donation in there - have
>> people from contributing company operate via patches I would
>> personally lean slightly toward patches, though I anticipate the
>> donators may prefer ACLs. In any case, if and when the code
>> becomes part of Geronimo proper, I think the donators will need to
>> qualify for Geronimo commit status as normal. Thanks, Aaron
>
> I think that we should have a single simple process. All code
> donations go into
>
> /geronimo/incubator/donationx/*
>
> The contributors would get restricted committer access to their
> project; granting committer access gives us better visibility how
> well the person works in a community setting. They and, hopefully
> Geronimo committers, would whip it into shape. The community would
> provide guidance and, hopefully, vote it into Geronimo once its
> provenance has been cleared.
>
> The "probationary" committers would, hopefully, get voted into
> Geronimo, regardless of their projects status. I have never heard
> of a motivated developer not getting committer access.
>
> I think that if the contribution was wildy popular it would
> graduate, as would any Geronimo module, to be a sub-project where
> it would have its own release cycles.
>
Works for me. The only thing I'd note that there is no provenance
question - the code will come under the Apache license with a CCLA
for the code, so there's no "provenance" issue in the sense of IP
provenance.
geir
>
> Regards,
> Alan
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Donation of Admin Console- request for help
Posted by si...@insession.com.
"Alan D. Cabrera" <li...@toolazydogs.com> wrote on 12/07/2005 10:34:19 AM:
>
>
> I think that we should have a single simple process. All code
> donations go into
>
> /geronimo/incubator/donationx/*
>
> The contributors would get restricted committer access to their
> project; granting committer access gives us better visibility how
> well the person works in a community setting. They and, hopefully
> Geronimo committers, would whip it into shape. The community would
> provide guidance and, hopefully, vote it into Geronimo once its
> provenance has been cleared.
>
> The "probationary" committers would, hopefully, get voted into
> Geronimo, regardless of their projects status. I have never heard
> of a motivated developer not getting committer access.
>
> I think that if the contribution was wildy popular it would
> graduate, as would any Geronimo module, to be a sub-project where it
> would have its own release cycles.
>
>
> Regards,
> Alan
>
Sounds reasonable to me.
John
This e-mail message and any attachments may contain confidential,
proprietary or non-public information. This information is intended
solely for the designated recipient(s). If an addressing or transmission
error has misdirected this e-mail, please notify the sender immediately
and destroy this e-mail. Any review, dissemination, use or reliance upon
this information by unintended recipients is prohibited. Any opinions
expressed in this e-mail are those of the author personally.
Re: Donation of Admin Console- request for help
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Aaron Mulder wrote, On 7/11/2005 8:03 AM:
>>1) We must decide on where we bring the software and how we handle
>>interested contributors :
>>
>> a) Bring to Apache Geronimo SVN (w/ or w/o separate ACL) and
>>
>> i) Grant committer status to any offered individuals that wish
>>to continue working on the respective contribution
>> ii) Ask that work continues via submitted patches for some
>>period of time
>>
>> b) Bring to the Apache Incubator and work with the code and people
>>there
>>
>>
>
> I would like to look at the code before deciding whether and how
>to incorporate either of these donations into Geronimo "for real". But my
>preference on the implementation of that would be to set up some temporary
>space in the project SVN, put the code there, let people fuss with it, and
>then (if all goes well) when it's massaged into shape vote to fold it into
>the SVN tree proper (though I'm not yet sure whether it should be part of
>the current "geronimo" tree or in a "related projects" / "sub project"
>area -- that probably depends to some extent on the code and how
>entangled it is).
>
> So, in order to move forward, I would prefer:
>
> - set up a separate area of SVN for donations (currently 2 on the table)
> - pick one of:
> - add separate ACL for each donation in there
> - have people from contributing company operate via patches
>
> I would personally lean slightly toward patches, though I
>anticipate the donators may prefer ACLs. In any case, if and when the
>code becomes part of Geronimo proper, I think the donators will need to
>qualify for Geronimo commit status as normal.
>
>Thanks,
> Aaron
>
>
I think that we should have a single simple process. All code donations
go into
/geronimo/incubator/donationx/*
The contributors would get restricted committer access to their project;
granting committer access gives us better visibility how well the person
works in a community setting. They and, hopefully Geronimo committers,
would whip it into shape. The community would provide guidance and,
hopefully, vote it into Geronimo once its provenance has been cleared.
The "probationary" committers would, hopefully, get voted into Geronimo,
regardless of their projects status. I have never heard of a motivated
developer not getting committer access.
I think that if the contribution was wildy popular it would graduate, as
would any Geronimo module, to be a sub-project where it would have its
own release cycles.
Regards,
Alan
Re: Donation of Admin Console- request for help
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 12:52 PM, Aaron Mulder wrote:
> On Mon, 11 Jul 2005, Geir Magnusson Jr. wrote:
>
>> Yep - I would suggest then we keep it simple and have
>>
>> /geronimmo/sandbox
>>
>
> Fine with me
>
>
>> /geronimo/sandbox/misc/SoC
>>
>
> I think we agreed this one is going to operate through patches.
Wasn't sure what we agreed on. If patches, great. If working as
"regular" committer, great.
>
>
>> /geronimo/sandbox/donations/trifork
>> /geronimo/sandbox/donations/ibm
>>
>
> I would prefer a mixed name or feature name rather than a company
> name -- so perhaps trifork-corba or corba, and web-console or
> ibm-web-console, or something like that.
Fine by me. I figured that TriFork *and* IBM might be contributing
more than one thing, so was a neat bucketing. But i don't care.
>
>
>> I'd be happy w/ separate ACLs to let people work as fast and
>> "normally" as possible, w/o having to wait for patches to be
>> accepted. There's no danger with SVN. That said, I'd go w/ patches
>> if that was the consensus.
>>
>
> Well, I don't want to offend anyone, but I can envision a scenario
> where we don't see eye to eye with a submitter on architecture or
> features
> or whatever.
Heresy! Has it EVER been the case where we don't all harmoniously
agree? I'm shocked! SHOCKED!
:D
LOL
> If the submitter charges ahead with their own changes in
> their own style and that turns out to be unacceptable to us, then the
> whole module is wasted.
The rules of technical consensus apply as for all our code - any one
of us can veto for technical reasons. This isn't "Geroni-forge" :)
> If they submit patches instead, we are free to
> accept them or hold off and massage the code into something more
> appropriate to us. I am not saying this is the expected case,
> which is
> why I only have a minor preference for patches, but it would be
> nice to
> account for.
Right - all I'm saying is that anyone can veto a change and roll it
back out of SVN, so the end result is identical - community oversight
and control of the technical nature and changes to our codebase.
geir
>
> Aaron
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Donation of Admin Console- request for help
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Mon, 11 Jul 2005, Geir Magnusson Jr. wrote:
> Yep - I would suggest then we keep it simple and have
>
> /geronimmo/sandbox
Fine with me
> /geronimo/sandbox/misc/SoC
I think we agreed this one is going to operate through patches.
> /geronimo/sandbox/donations/trifork
> /geronimo/sandbox/donations/ibm
I would prefer a mixed name or feature name rather than a company
name -- so perhaps trifork-corba or corba, and web-console or
ibm-web-console, or something like that.
> I'd be happy w/ separate ACLs to let people work as fast and
> "normally" as possible, w/o having to wait for patches to be
> accepted. There's no danger with SVN. That said, I'd go w/ patches
> if that was the consensus.
Well, I don't want to offend anyone, but I can envision a scenario
where we don't see eye to eye with a submitter on architecture or features
or whatever. If the submitter charges ahead with their own changes in
their own style and that turns out to be unacceptable to us, then the
whole module is wasted. If they submit patches instead, we are free to
accept them or hold off and massage the code into something more
appropriate to us. I am not saying this is the expected case, which is
why I only have a minor preference for patches, but it would be nice to
account for.
Aaron
Re: Donation of Admin Console- request for help
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 12:48 PM, Bruce Snyder wrote:
> On 7/11/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> ...
>
>> Fine : I'm going to suggest
>>
>> /geronimo/sandbox/misc/SoC
>> /geronimo/sandbox/donations/trifork
>> /geronimo/sandbox/donations/ibm
>>
>
> Location within the Geronimo SVN repo is not a big concern to me. What
> is a big concern is how we decide to accept it.
Yep. That's why I threw something out there....
>
>
>> as our pattern
>>
>>
>>> - pick one of:
>>> - add separate ACL for each donation in there
>>> - have people from contributing company operate via patches
>>>
>>> I would personally lean slightly toward patches, though I
>>> anticipate the donators may prefer ACLs. In any case, if and
>>> when the
>>> code becomes part of Geronimo proper, I think the donators will
>>> need to
>>> qualify for Geronimo commit status as normal.
>>>
>>
>> Right, and that's up to us. "Qualify" is currently subjective.
>>
>> I'd be happy w/ separate ACLs to let people work as fast and
>> "normally" as possible, w/o having to wait for patches to be
>> accepted. There's no danger with SVN. That said, I'd go w/ patches
>> if that was the consensus.
>>
>
> I lean toward the idea of patches as well. This is the console that
> was created by Gluecode so I believe the creators are already
> committers. If this assumption is incorrect, can someone please
> elaborate further on the state of the code since Gluecode was
> swallowed by IBM.
Well.. :) that would only work if we as individuals were
contributing the code, individually or as a group.
Since the code was a work-for-hire produced by us and other people
who aren't Geronimo committers while working at Gluecode and then
IBM, the ownership is clearly IBMs, and I think that it would be too
murky if we did anything other than whatever policy we decide on.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Donation of Admin Console- request for help
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Mon, 11 Jul 2005, Bruce Snyder wrote:
> I lean toward the idea of patches as well. This is the console that
> was created by Gluecode so I believe the creators are already
> committers. If this assumption is incorrect, can someone please
> elaborate further on the state of the code since Gluecode was
> swallowed by IBM.
IANA-IBM-er, but... From what I've heard, most of the development
work on the console was done by a group of (subcontract?) developers at
Gluecode that did not go to IBM -- and there are now people at IBM
(including the person who started this thread?) who did not come from
Gluecode yet have been or are interested in working on the console.
Aaron
Re: Donation of Admin Console- request for help
Posted by Bruce Snyder <br...@gmail.com>.
On 7/11/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
...
> Fine : I'm going to suggest
>
> /geronimo/sandbox/misc/SoC
> /geronimo/sandbox/donations/trifork
> /geronimo/sandbox/donations/ibm
Location within the Geronimo SVN repo is not a big concern to me. What
is a big concern is how we decide to accept it.
> as our pattern
>
> > - pick one of:
> > - add separate ACL for each donation in there
> > - have people from contributing company operate via patches
> >
> > I would personally lean slightly toward patches, though I
> > anticipate the donators may prefer ACLs. In any case, if and when the
> > code becomes part of Geronimo proper, I think the donators will
> > need to
> > qualify for Geronimo commit status as normal.
>
> Right, and that's up to us. "Qualify" is currently subjective.
>
> I'd be happy w/ separate ACLs to let people work as fast and
> "normally" as possible, w/o having to wait for patches to be
> accepted. There's no danger with SVN. That said, I'd go w/ patches
> if that was the consensus.
I lean toward the idea of patches as well. This is the console that
was created by Gluecode so I believe the creators are already
committers. If this assumption is incorrect, can someone please
elaborate further on the state of the code since Gluecode was
swallowed by IBM.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
RE: Is it a mountain? (Re: Donation of Admin Console- request for help)
Posted by Jeff Genender <jg...@savoirtech.com>.
Alan,
This is a great idea. I like the geronimo incubation ACL. +1 for this.
Jeff
________________________________
From: Alan D. Cabrera [mailto:list@toolazydogs.com]
Sent: Tuesday, July 12, 2005 6:06 PM
To: dev@geronimo.apache.org
Subject: Re: Is it a mountain? (Re: Donation of Admin Console- request for
help)
Aaron Mulder wrote, On 7/12/2005 4:50 PM:
Well, I was going to start a new thread, but it seems Alan
doesn't
like that, so...
Would it be accurate to say that the options on the table
for
donated code are:
1) Bring (project X) to geronimo, grant full commit status to (some
number
of people) who have worked with the code before
2) Bring project X to geronimo, put in a clearly separate SVN area,
grant restricted commit status (via ACL or explicit direction) to
some
number of people who have worked with the code before
3) Bring project X to the incubator, mix outside people and
potentially
Geronimo people to form a new project team
It's clear that there's a variety of opinions as to which of
these
is preferable, and potentially which is most preferable for the web
console vs the ORB.
Aaron
I like #2. To put a finer point to it, I think that we should have a single
simple process.
All vendors must propose the code donation to the community. Embarrassing
denials can be averted by creating a gmail account and asking if people are
interested in technology X going into Geronimo.
All code donations go into
/geronimo/incubator/donationx/*
The contributors would get restricted committer access to their project;
granting committer access gives us better visibility how well the person
works in a community setting. They and, hopefully Geronimo committers,
would whip it into shape. The community would provide guidance and,
hopefully, vote it into Geronimo once its ready and all the appropriate
paper work was obtained.
The "probationary" committers would, hopefully, get voted into Geronimo,
regardless of their projects status. I have never heard of a motivated
developer not getting committer access.
If the contribution was wildly popular it would graduate, as would any
Geronimo module, to be a sub-project where it would have its own release
cycles. If it became obscenely popular, it would become a TLP.
Regards,
Alan
Re: Is it a mountain? (Re: Donation of Admin Console- request for
help)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Aaron Mulder wrote, On 7/12/2005 4:50 PM:
> Well, I was going to start a new thread, but it seems Alan doesn't
>like that, so...
>
> Would it be accurate to say that the options on the table for
>donated code are:
>
>1) Bring (project X) to geronimo, grant full commit status to (some number
>of people) who have worked with the code before
>
>2) Bring project X to geronimo, put in a clearly separate SVN area,
>grant restricted commit status (via ACL or explicit direction) to some
>number of people who have worked with the code before
>
>3) Bring project X to the incubator, mix outside people and potentially
>Geronimo people to form a new project team
>
> It's clear that there's a variety of opinions as to which of these
>is preferable, and potentially which is most preferable for the web
>console vs the ORB.
>
>Aaron
>
I like #2. To put a finer point to it, I think that we should have a
single simple process.
All vendors must propose the code donation to the community.
Embarrassing denials can be averted by creating a gmail account and
asking if people are interested in technology X going into Geronimo.
All code donations go into
/geronimo/incubator/donationx/*
The contributors would get restricted committer access to their project;
granting committer access gives us better visibility how well the person
works in a community setting. They and, hopefully Geronimo committers,
would whip it into shape. The community would provide guidance and,
hopefully, vote it into Geronimo once its ready and all the appropriate
paper work was obtained.
The "probationary" committers would, hopefully, get voted into Geronimo,
regardless of their projects status. I have never heard of a motivated
developer not getting committer access.
If the contribution was wildly popular it would graduate, as would any
Geronimo module, to be a sub-project where it would have its own release
cycles. If it became obscenely popular, it would become a TLP.
Regards,
Alan
Re: Close to completion? (acl policy questions)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
I'll be a good little fishy, as I think this is important. I'm
keeping the following in mind from a recent post by David Jencks as I
go through the list :
"I'd like to reemphasize that bringing in new committers with their
code is going to be a lot of work for the existing community. If we
fail to integrate a donation a very large part of the responsibility
rests with us for not having good enough community skills to work
with the newcomers. It seems to me that discussions about limited
commit access/ acls/ etc are fundamentally discussions about what
happens if we fail. I wonder what would happen if we instead
discussed how we will provide superb support and mentoring for our
new members and left the questions of what to do if we fail to such
time as it might be needed."
On Jul 13, 2005, at 2:37 PM, David Blevins wrote:
> If you vote for this, no complaining later -- you eat your own dog
> food.
If you vote for anything, and we don't like it, we change it. We
aren't bending re-bar and pouring cement...
>
>
> ----------------------------------------------------------
> NOTE: I apologize in advance for using the words
> "incubation", "incubating", "incubated", and finally
> "incubator".
Why didn't you just avoid using it then? We're not creating an
incubator. We're trying to bring in code, add committers and build
*our* community.
[SNIP]
>
> Do ACLs extend to things like:
> - websites
> - documentation (possibly donated as well)
> - QA
> - project management
>
If we want them to, and I think we want them to. The goal here is
Geronimo project participation, not "off in the corner" participation.
>
> What is the policy on how this affects voting?
> - Can a restricted committer -1 a change made by a non-restricted
> committer
In the code they are working on? Yes because the "non-restricted
committer" will have karma to the "restricted" svn repo.
> - Does a restricted committer get a binding vote on the code to
> which they have access?
yes
> - Does a restricted committer have a binding vote to code to which
> they do not have access?
No
> - Does a restricted committer have a binding vote on non-technical
> issues?
That's an interesting question to think about, and I think my answer
is yes, again because it's about growing project participation.
To explain, I want to object to the lingo of "restricted committer"
vs "non-restricted committer". I think of as "committer to Geronimo
main SVN" vs "committer to Geronimo $foo SVN"
So yes. And I think that for code being brought into Geronimo
project (even in a $foo SVN) would mean that all committers to
Geronimo main SVN have commit to $foo SVN so that
a) we have PMC oversight
b) we have full interaction and participation
>
>
For the following, I'll assume "incubating" means "code in Geronimo
$foo repository" where $foo != main
> New committers:
> - Does an existing ASF committer contributing to the incubating
> code get restricted commit?
Like someone from httpd? No.
> - Does an existing ASF committer contributing to the incubating
> code and some to other code get full commit?
No - I assume you mean some arbitrary committer from Jakarta or -ish?
> - Does an employee of the donor contributing to the incubating
> code get restricted commit?
Any arbitrary employee? of course not. I would assume we'd craft
some guideline asking the donor to list the humans that worked on the
code and wish to continue.
Note that "donor" isn't necessarily an entity with employees - for
example, if hypothetically something like MX4J decided to come to
Geronimo...
> - Does an employee of the donor contributing to the incubating
> code and some to other code get full commit?
do you mean "if a person that is working on the code in the Geronimo
$foo repository starts contributing to the Geronimo main repository,
do we offer them commit"? yes, at some point, which I assume is
going to be *way* accelerated because they've been working right in
the community all long on stuff that's part of the community.
> - Does an unknown community member contributing to the incubating
> code get restricted commit?
> - Does an unknown community member contributing to the incubating
> code and some to other code get full commit?
If someone starts posting patches to the Geronimo $foo repo, and we
feel that they meet our criterion for offered commit access,yes, lets
offer them commit access to the Geronimo $foo repository.
> - Will there be an advantage to *not* contributing to the
> incubating code as to avoid getting voted in as a restricted
> committer.
I don't get it.
When I think of "restricted ACL" I think of simply setting up another
repository with a different group of committers, that includes all
the committers from the main [current] repository, along with the
people that want to keep working on their donation with us.
If a "restricted ACL" repo is a place where someone wants to
contribute, lets let them earn commit status there if they didn't
come with the code...
>
>
> Releasing:
> - Can code being Geronimo incubated be distributed in our unstable
> builds?
> - Can code being Geronimo incubated be distributed in official
> releases?
> - Can code being Geronimo incubated be certified and distributed
> in a certified release?
Being there is no incubation, I'd say "yes" to all of these questions
- at all times the main repository committers are committers on the
$foo respoitory, the PMC has full responsibility and oversight, etc.
If there is no one but the donor committers working on the codebase
here, it shouldn't be here. Either this is stuff we work on with
them, or they can be elswhere. We're not an incubator.
>
>
> Management and dynamics:
> - Can we handle having 2 or 3 more donations in addition to the
> two we plan?
It certainly will be easier with more people. it's up to us to gauge
who and what we bring in. You have a good point here - we must
always consider the load on the existing committers for anything like
this that we do. Making commitments means making commitments - doing
it elsewhere just leaves less time for here.
> - Is is possible that the number of active restricted committers
> outnumbers the active fully privileged committers?
Anything is possible, and I think that would mean we weren't paying
attention to what you pointed out above. If we do this, it's our error.
And I think that it's not the end of the world if it happens, as if G
is the set of all committers in the main geronimo repo and C is the
new people that want to come and work on console then
C' is the set of commiters in the console repo
C' = G + C
assume the same for Trifork (see, got the case of the "F" right...
sorry about my previous errors...)
T' = G + T
> - How much time are you willing to dedicate in a week to managing
> issues, documenting guidelines and general Apache Way mentoring?
meaning, working with others in the community? I seem to put in a
bit of time now. I know if I didn't have to spend the time on this
subject, I'd have oodles of free hours :)
> - Will we be open to assistance from experienced ASF people
> willing to assist in managing issues, documenting guidelines and
> general Apache Way mentoring?
We always are. But we're not doing an incubator.
> - Would they get a binding vote?
No.
> - Would they get and be welcome to use commit privileges?
Interesting question :) In some places at the ASF, being an existing
ASF committer is a huge step towards commit if you are known, but
lets not go there in this thread.
>
>
> PMC:
> - Can a restricted committer join the Geronimo PMC?
I'd like to avoid this. If a person has been around such that we
believe they deserve to be on the PMC, we trust them with commit to
main repo, and if peeps like that have been around, we should be just
integrating the pile of people into the main tree anyway?
> - Can a person under a documentation ACL join the PMC?
> - Can a person under a management ACL join the PMC?
I don't know what a "management ACL" is, but for the same reasons as
above...
The model I'm worried about is the Jakarta model, which was having
committers from the various subprojects (a reasonable analogy -
different CVS roots with separate ACLs for each root) be on the PMC
in a limited way. That gave PMC oversight officially, as if there
were 3 committers from Jakarta Wombat that voted +1 on a release,
because they were on the PMC, that provided the necessary minimum
legal requirement.
We *may* be able to do this if we start from scratch with the goal
that *every* committer should be on the PMC, and that the "restricted
ACL" is just an internal management feature of code access.
I could easily talk myself into this, but we'd have to be very clear
from the get-go that we will work to have everyone on the PMC (which
is our goal now, btw) and people should have the good manners and
common sense to abstain from voting on things they aren't a part of.
>
>
> Moving Up:
> - What is the criteria for leaving the Geronimo incubator?
There is no Geronimo incubator.
I see it as the question of "when can and how do we combine these
repos"?
> - Is it acceptable to take half or less of the code?
Sure
> - How is this consensus reached, public vote or private vote?
public
> - How do restricted committers become full committers?
"How does someone w/o commit access to the main Geronimo repository
get commit access?" ? I don't see us having special rules - if we
believe the person does good work, is committed, etc, then we vote
that person in as committer.
Our guidelines for committer access apply to any repo. There are no
special "Geronimo incubator" rules.
> - If a donation moves to full status, are the restrictions of all
> committers working on that code removed?
Again, in my mental model, it's not about restriction but commit in
other parts of our multi-repo SVN.
> - Are these people free to vote on matters of other donated code?
I don't grok
>
>
> Moving Out:
> - Is it possible to remove a project from incubation and not
> accept it as a part of Geronimo?
There is no Geronimo incubation.
But yes, we've had sandbox code that we never used, and just threw it
out. Not a new issue.
> - How long will donors have to wait to get this answer?
Huh?
> - On what basis will the PMC vote on removing a project?
I assume that there's all sorts of factors that will come up.
>
> - Is that a public or private vote?
if it's technology, public. if there's people issues involved, private.
> - Is it possible to remove all commit access for a restricted
> committer.
of course. it's possible to remove all commit access for any committer
> - On what basis will the PMC vote on removing all commit access?
For the same reasons that I would now - gross breach of trust,
prolonged inactivity, etc
> - Is that a public or private vote?
Private. It's a person.
>
>
> Potential fairness issues:
> - Donor X gets in the incubator in March, donor Y gets in the
> incubator two months later. Sometime later, the PMC votes to
> graduate donor Y's code. Do we graduate X as well? If not, do we
> owe X and explanation of why they aren't being graduated?
Oh, I see. Because there is no Geronimo incubator... Let me rephrase :
Donor X gets a contribution accepted into repoX in March and begins
working. Donor Y gets a contribution accepted into repoY and begins
working. At some point, the community votes to combine the code from
repoY into repoMain. X and repoX keep doing their thing. They are
all independent.
Because there is no Geronimo incubator, there is nothing to
"graduate" from. If it makes technological or other sense to move
things around, we do it.
> - Adam and Jack are restricted committers from donor ABC. Jack is
> voted in as a full committer. Do we vote in Adam as well? If not,
> do we owe Adam an explanation of why?
I assume that Jack was contributing to mainRepo and it was time to
give him access? Or do you mean that repoABC is combined with
repoMain? In the latter case, I think that not taking all the people
would be an extreme corner case and would have to deal with
individually.
(Note - there's a similar problem if we went and sponsored something
in the Apache Incubator to incorporate into Geronimo - at that point,
each committer would have to earn commit status independently, so you
could have the situation where we fractured that community ... :/ )
> - Bill and Ben are restricted committers from donor QRS. Bill and
> Ben are having a hard time getting really involved. Eric is an
> Apache committer from another project who started working with the
> donated code and was made a restricted committer. The PMC decides
> to vote Eric in as a full Geronimo committer. Do we make Bill and
> Ben full committers as well? If no, how do we handle Bill and
> Ben's expectations?
Be honest and up front with them? I think that this is a corner
case, and self-solving. If they aren't involved, why would they care?
Whew! Happy to get through that before my meeting starts.
Just to recap the model I'm thinking of is a set of additional repos
besides the "main" Geronimo repo that has the committer set denoted
as G. Each non-main repo has a committer set that is G + additions
that either came with a donation (if that's how it started) or people
that wanted to participate in that part of our world and earned commit.
There is no "graduation" - there is combining technology when and if
it makes sense, and granting further commit when and if it makes
sense for a person.
The key is that all would be part of the same community, working
together. I expect that if we did something like this, a trusted
person X with commit rights to repoX that wanted to work on repoY
would be subject to a quick vote and given access.
My only concern is how to really ensure that we have no balkanization
of the community. I think we saw it happen in Jakarta as it really
grew, and the things to avoid are partitioned dev lists, for one, and
not working as hard as possible to get all committers on the PMC from
day 0. (I'm not criticizing Jakarta - I think it has been
phenomenally successful in many ways, and we just need to learn from
their groundbreaking efforts.)
Thanks for the thought-provoking questions.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Close to completion? (acl policy questions)
Posted by David Blevins <da...@visi.com>.
If you vote for this, no complaining later -- you eat your own dog food.
----------------------------------------------------------
NOTE: I apologize in advance for using the words
"incubation", "incubating", "incubated", and finally
"incubator". The word "sandbox" is not a verb and really
hard to use as one, nor could I think of another verb.
Sorry, sorry, sorry. Please, please, please try and focus
on the content in the questions.
----------------------------------------------------------
Do ACLs extend to things like:
- websites
- documentation (possibly donated as well)
- QA
- project management
What is the policy on how this affects voting?
- Can a restricted committer -1 a change made by a non-restricted committer
- Does a restricted committer get a binding vote on the code to which they have access?
- Does a restricted committer have a binding vote to code to which they do not have access?
- Does a restricted committer have a binding vote on non-technical issues?
New committers:
- Does an existing ASF committer contributing to the incubating code get restricted commit?
- Does an existing ASF committer contributing to the incubating code and some to other code get full commit?
- Does an employee of the donor contributing to the incubating code get restricted commit?
- Does an employee of the donor contributing to the incubating code and some to other code get full commit?
- Does an unknown community member contributing to the incubating code get restricted commit?
- Does an unknown community member contributing to the incubating code and some to other code get full commit?
- Will there be an advantage to *not* contributing to the incubating code as to avoid getting voted in as a restricted committer.
Releasing:
- Can code being Geronimo incubated be distributed in our unstable builds?
- Can code being Geronimo incubated be distributed in official releases?
- Can code being Geronimo incubated be certified and distributed in a certified release?
Management and dynamics:
- Can we handle having 2 or 3 more donations in addition to the two we plan?
- Is is possible that the number of active restricted committers outnumbers the active fully privileged committers?
- How much time are you willing to dedicate in a week to managing issues, documenting guidelines and general Apache Way mentoring?
- Will we be open to assistance from experienced ASF people willing to assist in managing issues, documenting guidelines and general Apache Way mentoring?
- Would they get a binding vote?
- Would they get and be welcome to use commit privileges?
PMC:
- Can a restricted committer join the Geronimo PMC?
- Can a person under a documentation ACL join the PMC?
- Can a person under a management ACL join the PMC?
Moving Up:
- What is the criteria for leaving the Geronimo incubator?
- Is it acceptable to take half or less of the code?
- How is this consensus reached, public vote or private vote?
- How do restricted committers become full committers?
- If a donation moves to full status, are the restrictions of all committers working on that code removed?
- Are these people free to vote on matters of other donated code?
Moving Out:
- Is it possible to remove a project from incubation and not accept it as a part of Geronimo?
- How long will donors have to wait to get this answer?
- On what basis will the PMC vote on removing a project?
- Is that a public or private vote?
- Is it possible to remove all commit access for a restricted committer.
- On what basis will the PMC vote on removing all commit access?
- Is that a public or private vote?
Potential fairness issues:
- Donor X gets in the incubator in March, donor Y gets in the incubator two months later. Sometime later, the PMC votes to graduate donor Y's code. Do we graduate X as well? If not, do we owe X and explanation of why they aren't being graduated?
- Adam and Jack are restricted committers from donor ABC. Jack is voted in as a full committer. Do we vote in Adam as well? If not, do we owe Adam an explanation of why?
- Bill and Ben are restricted committers from donor QRS. Bill and Ben are having a hard time getting really involved. Eric is an Apache committer from another project who started working with the donated code and was made a restricted committer. The PMC decides to vote Eric in as a full Geronimo committer. Do we make Bill and Ben full committers as well? If no, how do we handle Bill and Ben's expectations?
Re: Close to completion? (Re: Is it a mountain? (Re: Donation of Admin Console- request for help))
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 12, 2005, at 10:58 PM, Aaron Mulder wrote:
> Well, can we have a separate vote for what to do with the web
> console? I thought it was ready (or nearly so) and I don't want to
> hold
> up the contribution for some of the unrelated items on your list.
I was hoping that we could just define the guidelines first, and then
apply it to the web console as our first use.
>
> (break)
>
> As for your list, are you saying that a vote for new code going to
> the incubator must necessarily be cast as a "we don't need a
> policy" vote
> for 1 (since "it's a tool we already have now - we can always do
> that")?
> I don't think that's entirely reasonable. A policy of sending
> donations
> to the incubator is still a policy. Whatever, I guess I'm OK voting
> against policy.
Ok - I see. I think of it as something we have always had the
ability to do, so it's not a decision on what we do *here*. So if we
choose to always send to the incubator, we haven't actually done
anything, and leave open the question of what to do when it comes out
of incubator :)
>
> Also, I thought we were going to try to avoid votes on things that
> haven't been discussed. Where did the metrics for accepting a
> committer
> topic come from?
That's why I left it open and didn't call for a vote, and I thought
posed them as suggestions - starters for a conversation. I think we
need a good rule of thumb "guideline" for potential committers so
they know what to expect.
No worries.
geir
>
> Aaron
>
> On Tue, 12 Jul 2005, Geir Magnusson Jr. wrote:
>
>> Lets start a new thread tomorrow, finish discussion since I suspect
>> that all that will say their peace have done so, and work out a vote?
>>
>> I suspect we need to decide :
>>
>> 1) do we need to have any policy?
>>
>> 2) If so, decide the
>>
>> a) general committer acceptance policy/guidelines to define some
>> sensible, fair, transparent metrics for accepting a committer
>> such as
>> - how long a person must commit patches
>> - how long participate on the mailing lists
>>
>> b) general code acceptance policy (what we have been discussing
>> here)
>> where the options include
>> - bring into SVN, grant committer status to some # of people
>> - bring into SVN, grant restricted status to some # of people
>> - bring into SVN, follow a) above for people
>> - none of the above
>>
>> I think that "bring to incubator" is not in scope for this vote, as
>> it's a tool we already have now - we can always do that and decide to
>> sponsor or just participate, but at the end of that process, then the
>> code contribution b) rules should apply.
>>
>> geir
>>
>>
>> On Jul 12, 2005, at 7:50 PM, Aaron Mulder wrote:
>>
>>
>>> Well, I was going to start a new thread, but it seems Alan
>>> doesn't
>>> like that, so...
>>>
>>> Would it be accurate to say that the options on the table for
>>> donated code are:
>>>
>>> 1) Bring (project X) to geronimo, grant full commit status to (some
>>> number
>>> of people) who have worked with the code before
>>>
>>> 2) Bring project X to geronimo, put in a clearly separate SVN area,
>>> grant restricted commit status (via ACL or explicit direction) to
>>> some
>>> number of people who have worked with the code before
>>>
>>> 3) Bring project X to the incubator, mix outside people and
>>> potentially
>>> Geronimo people to form a new project team
>>>
>>> It's clear that there's a variety of opinions as to which of
>>> these
>>> is preferable, and potentially which is most preferable for the web
>>> console vs the ORB.
>>>
>>> Aaron
>>>
>>> On Tue, 12 Jul 2005, David Blevins wrote:
>>>
>>>
>>>> On Tue, Jul 12, 2005 at 07:17:44PM -0400, Davanum Srinivas wrote:
>>>>
>>>>
>>>>> It's a judgement call i guess. i have not been on the calls. If
>>>>> you
>>>>> guys feel that it can support its own eco-system. then thats fine.
>>>>>
>>>>>
>>>>>
>>>>
>>>> I don't know yet, myself. But certainly one cannot deny there are
>>>> more CORBA specs than Web Services specs (for a while anyway); not
>>>> exactly the same deal as a web console.
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>>> On 7/12/05, David Blevins <da...@visi.com> wrote:
>>>>>
>>>>>
>>>>>> On Tue, Jul 12, 2005 at 06:58:20PM -0400, Davanum Srinivas wrote:
>>>>>>
>>>>>>
>>>>>>> It's just that the piece of code we are talking about in both
>>>>>>> cases,
>>>>>>> seem un-usable w/o geronimo.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Is that really true? We are talking about a compliant ORB
>>>>>> aren't we?
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geirm@apache.org
>>
>>
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Close to completion? (Re: Is it a mountain? (Re: Donation of
Admin Console- request for help))
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Well, can we have a separate vote for what to do with the web
console? I thought it was ready (or nearly so) and I don't want to hold
up the contribution for some of the unrelated items on your list.
(break)
As for your list, are you saying that a vote for new code going to
the incubator must necessarily be cast as a "we don't need a policy" vote
for 1 (since "it's a tool we already have now - we can always do that")?
I don't think that's entirely reasonable. A policy of sending donations
to the incubator is still a policy. Whatever, I guess I'm OK voting
against policy.
Also, I thought we were going to try to avoid votes on things that
haven't been discussed. Where did the metrics for accepting a committer
topic come from?
Aaron
On Tue, 12 Jul 2005, Geir Magnusson Jr. wrote:
> Lets start a new thread tomorrow, finish discussion since I suspect
> that all that will say their peace have done so, and work out a vote?
>
> I suspect we need to decide :
>
> 1) do we need to have any policy?
>
> 2) If so, decide the
>
> a) general committer acceptance policy/guidelines to define some
> sensible, fair, transparent metrics for accepting a committer
> such as
> - how long a person must commit patches
> - how long participate on the mailing lists
>
> b) general code acceptance policy (what we have been discussing here)
> where the options include
> - bring into SVN, grant committer status to some # of people
> - bring into SVN, grant restricted status to some # of people
> - bring into SVN, follow a) above for people
> - none of the above
>
> I think that "bring to incubator" is not in scope for this vote, as
> it's a tool we already have now - we can always do that and decide to
> sponsor or just participate, but at the end of that process, then the
> code contribution b) rules should apply.
>
> geir
>
>
> On Jul 12, 2005, at 7:50 PM, Aaron Mulder wrote:
>
> > Well, I was going to start a new thread, but it seems Alan doesn't
> > like that, so...
> >
> > Would it be accurate to say that the options on the table for
> > donated code are:
> >
> > 1) Bring (project X) to geronimo, grant full commit status to (some
> > number
> > of people) who have worked with the code before
> >
> > 2) Bring project X to geronimo, put in a clearly separate SVN area,
> > grant restricted commit status (via ACL or explicit direction) to some
> > number of people who have worked with the code before
> >
> > 3) Bring project X to the incubator, mix outside people and
> > potentially
> > Geronimo people to form a new project team
> >
> > It's clear that there's a variety of opinions as to which of these
> > is preferable, and potentially which is most preferable for the web
> > console vs the ORB.
> >
> > Aaron
> >
> > On Tue, 12 Jul 2005, David Blevins wrote:
> >
> >> On Tue, Jul 12, 2005 at 07:17:44PM -0400, Davanum Srinivas wrote:
> >>
> >>> It's a judgement call i guess. i have not been on the calls. If you
> >>> guys feel that it can support its own eco-system. then thats fine.
> >>>
> >>>
> >>
> >> I don't know yet, myself. But certainly one cannot deny there are
> >> more CORBA specs than Web Services specs (for a while anyway); not
> >> exactly the same deal as a web console.
> >>
> >> -David
> >>
> >>
> >>> On 7/12/05, David Blevins <da...@visi.com> wrote:
> >>>
> >>>> On Tue, Jul 12, 2005 at 06:58:20PM -0400, Davanum Srinivas wrote:
> >>>>
> >>>>> It's just that the piece of code we are talking about in both
> >>>>> cases,
> >>>>> seem un-usable w/o geronimo.
> >>>>>
> >>>>
> >>>> Is that really true? We are talking about a compliant ORB
> >>>> aren't we?
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Davanum Srinivas -http://blogs.cocoondev.org/dims/
> >>>
> >>
> >>
> >
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
Re: Close to completion? (Re: Is it a mountain? (Re: Donation of Admin Console- request for help))
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 12, 2005, at 10:52 PM, Jeff Genender wrote:
> 1) -1. Guidelines are good, policy can be bad.
yes - guidelines captures what I meant. (I think of policy being the
same, but I can see how others don't...)
> 2a) IMHO...This will be hard to guage and form metrics. This is
> subjective...since I think quality of participation plays to a certain
> degree. Is this necessary? Can't we continue as we have (or has this
> proven to be negative)?
I'd prefer to have a set of guidelines to make it clear to everyone
how we operate, and limit the chance that either we play favorites,
or are accused of doing so.
>
> 2b) +1 for "bring into SVN, grant restricted status to some # of
> people"
> because obviously it needs to be worked on by the authors to a certain
> degree.
>
> Jeff
>
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@apache.org]
> Sent: Tuesday, July 12, 2005 8:42 PM
> To: dev@geronimo.apache.org
> Subject: Close to completion? (Re: Is it a mountain? (Re: Donation
> of Admin
> Console- request for help))
>
> Lets start a new thread tomorrow, finish discussion since I suspect
> that all
> that will say their peace have done so, and work out a vote?
>
> I suspect we need to decide :
>
> 1) do we need to have any policy?
>
> 2) If so, decide the
>
> a) general committer acceptance policy/guidelines to define some
> sensible, fair, transparent metrics for accepting a committer
> such as
> - how long a person must commit patches
> - how long participate on the mailing lists
>
> b) general code acceptance policy (what we have been discussing
> here)
> where the options include
> - bring into SVN, grant committer status to some # of people
> - bring into SVN, grant restricted status to some # of people
> - bring into SVN, follow a) above for people
> - none of the above
>
> I think that "bring to incubator" is not in scope for this vote, as
> it's a
> tool we already have now - we can always do that and decide to
> sponsor or
> just participate, but at the end of that process, then the code
> contribution
> b) rules should apply.
>
> geir
>
>
> On Jul 12, 2005, at 7:50 PM, Aaron Mulder wrote:
>
>
>> Well, I was going to start a new thread, but it seems Alan
>> doesn't
>> like that, so...
>>
>> Would it be accurate to say that the options on the table for
>> donated code are:
>>
>> 1) Bring (project X) to geronimo, grant full commit status to (some
>> number of people) who have worked with the code before
>>
>> 2) Bring project X to geronimo, put in a clearly separate SVN area,
>> grant restricted commit status (via ACL or explicit direction) to
>> some
>> number of people who have worked with the code before
>>
>> 3) Bring project X to the incubator, mix outside people and
>> potentially Geronimo people to form a new project team
>>
>> It's clear that there's a variety of opinions as to which of
>> these
>> is preferable, and potentially which is most preferable for the web
>> console vs the ORB.
>>
>> Aaron
>>
>> On Tue, 12 Jul 2005, David Blevins wrote:
>>
>>
>>> On Tue, Jul 12, 2005 at 07:17:44PM -0400, Davanum Srinivas wrote:
>>>
>>>
>>>> It's a judgement call i guess. i have not been on the calls. If you
>>>> guys feel that it can support its own eco-system. then thats fine.
>>>>
>>>>
>>>>
>>>
>>> I don't know yet, myself. But certainly one cannot deny there are
>>> more CORBA specs than Web Services specs (for a while anyway); not
>>> exactly the same deal as a web console.
>>>
>>> -David
>>>
>>>
>>>
>>>> On 7/12/05, David Blevins <da...@visi.com> wrote:
>>>>
>>>>
>>>>> On Tue, Jul 12, 2005 at 06:58:20PM -0400, Davanum Srinivas wrote:
>>>>>
>>>>>
>>>>>> It's just that the piece of code we are talking about in both
>>>>>> cases, seem un-usable w/o geronimo.
>>>>>>
>>>>>>
>>>>>
>>>>> Is that really true? We are talking about a compliant ORB aren't
>>>>> we?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
RE: Close to completion? (Re: Is it a mountain? (Re: Donation of Admin Console- request for help))
Posted by Jeff Genender <jg...@savoirtech.com>.
1) -1. Guidelines are good, policy can be bad.
2a) IMHO...This will be hard to guage and form metrics. This is
subjective...since I think quality of participation plays to a certain
degree. Is this necessary? Can't we continue as we have (or has this
proven to be negative)?
2b) +1 for "bring into SVN, grant restricted status to some # of people"
because obviously it needs to be worked on by the authors to a certain
degree.
Jeff
-----Original Message-----
From: Geir Magnusson Jr. [mailto:geirm@apache.org]
Sent: Tuesday, July 12, 2005 8:42 PM
To: dev@geronimo.apache.org
Subject: Close to completion? (Re: Is it a mountain? (Re: Donation of Admin
Console- request for help))
Lets start a new thread tomorrow, finish discussion since I suspect that all
that will say their peace have done so, and work out a vote?
I suspect we need to decide :
1) do we need to have any policy?
2) If so, decide the
a) general committer acceptance policy/guidelines to define some
sensible, fair, transparent metrics for accepting a committer
such as
- how long a person must commit patches
- how long participate on the mailing lists
b) general code acceptance policy (what we have been discussing here)
where the options include
- bring into SVN, grant committer status to some # of people
- bring into SVN, grant restricted status to some # of people
- bring into SVN, follow a) above for people
- none of the above
I think that "bring to incubator" is not in scope for this vote, as it's a
tool we already have now - we can always do that and decide to sponsor or
just participate, but at the end of that process, then the code contribution
b) rules should apply.
geir
On Jul 12, 2005, at 7:50 PM, Aaron Mulder wrote:
> Well, I was going to start a new thread, but it seems Alan doesn't
> like that, so...
>
> Would it be accurate to say that the options on the table for
> donated code are:
>
> 1) Bring (project X) to geronimo, grant full commit status to (some
> number of people) who have worked with the code before
>
> 2) Bring project X to geronimo, put in a clearly separate SVN area,
> grant restricted commit status (via ACL or explicit direction) to some
> number of people who have worked with the code before
>
> 3) Bring project X to the incubator, mix outside people and
> potentially Geronimo people to form a new project team
>
> It's clear that there's a variety of opinions as to which of these
> is preferable, and potentially which is most preferable for the web
> console vs the ORB.
>
> Aaron
>
> On Tue, 12 Jul 2005, David Blevins wrote:
>
>> On Tue, Jul 12, 2005 at 07:17:44PM -0400, Davanum Srinivas wrote:
>>
>>> It's a judgement call i guess. i have not been on the calls. If you
>>> guys feel that it can support its own eco-system. then thats fine.
>>>
>>>
>>
>> I don't know yet, myself. But certainly one cannot deny there are
>> more CORBA specs than Web Services specs (for a while anyway); not
>> exactly the same deal as a web console.
>>
>> -David
>>
>>
>>> On 7/12/05, David Blevins <da...@visi.com> wrote:
>>>
>>>> On Tue, Jul 12, 2005 at 06:58:20PM -0400, Davanum Srinivas wrote:
>>>>
>>>>> It's just that the piece of code we are talking about in both
>>>>> cases, seem un-usable w/o geronimo.
>>>>>
>>>>
>>>> Is that really true? We are talking about a compliant ORB aren't
>>>> we?
>>>>
>>>> -David
>>>>
>>>>
>>>
>>>
>>> --
>>> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>>>
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Close to completion? (Re: Is it a mountain? (Re: Donation of Admin Console- request for help))
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Lets start a new thread tomorrow, finish discussion since I suspect
that all that will say their peace have done so, and work out a vote?
I suspect we need to decide :
1) do we need to have any policy?
2) If so, decide the
a) general committer acceptance policy/guidelines to define some
sensible, fair, transparent metrics for accepting a committer
such as
- how long a person must commit patches
- how long participate on the mailing lists
b) general code acceptance policy (what we have been discussing here)
where the options include
- bring into SVN, grant committer status to some # of people
- bring into SVN, grant restricted status to some # of people
- bring into SVN, follow a) above for people
- none of the above
I think that "bring to incubator" is not in scope for this vote, as
it's a tool we already have now - we can always do that and decide to
sponsor or just participate, but at the end of that process, then the
code contribution b) rules should apply.
geir
On Jul 12, 2005, at 7:50 PM, Aaron Mulder wrote:
> Well, I was going to start a new thread, but it seems Alan doesn't
> like that, so...
>
> Would it be accurate to say that the options on the table for
> donated code are:
>
> 1) Bring (project X) to geronimo, grant full commit status to (some
> number
> of people) who have worked with the code before
>
> 2) Bring project X to geronimo, put in a clearly separate SVN area,
> grant restricted commit status (via ACL or explicit direction) to some
> number of people who have worked with the code before
>
> 3) Bring project X to the incubator, mix outside people and
> potentially
> Geronimo people to form a new project team
>
> It's clear that there's a variety of opinions as to which of these
> is preferable, and potentially which is most preferable for the web
> console vs the ORB.
>
> Aaron
>
> On Tue, 12 Jul 2005, David Blevins wrote:
>
>> On Tue, Jul 12, 2005 at 07:17:44PM -0400, Davanum Srinivas wrote:
>>
>>> It's a judgement call i guess. i have not been on the calls. If you
>>> guys feel that it can support its own eco-system. then thats fine.
>>>
>>>
>>
>> I don't know yet, myself. But certainly one cannot deny there are
>> more CORBA specs than Web Services specs (for a while anyway); not
>> exactly the same deal as a web console.
>>
>> -David
>>
>>
>>> On 7/12/05, David Blevins <da...@visi.com> wrote:
>>>
>>>> On Tue, Jul 12, 2005 at 06:58:20PM -0400, Davanum Srinivas wrote:
>>>>
>>>>> It's just that the piece of code we are talking about in both
>>>>> cases,
>>>>> seem un-usable w/o geronimo.
>>>>>
>>>>
>>>> Is that really true? We are talking about a compliant ORB
>>>> aren't we?
>>>>
>>>> -David
>>>>
>>>>
>>>
>>>
>>> --
>>> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>>>
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Is it a mountain? (Re: Donation of Admin Console- request for
help)
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Well, I was going to start a new thread, but it seems Alan doesn't
like that, so...
Would it be accurate to say that the options on the table for
donated code are:
1) Bring (project X) to geronimo, grant full commit status to (some number
of people) who have worked with the code before
2) Bring project X to geronimo, put in a clearly separate SVN area,
grant restricted commit status (via ACL or explicit direction) to some
number of people who have worked with the code before
3) Bring project X to the incubator, mix outside people and potentially
Geronimo people to form a new project team
It's clear that there's a variety of opinions as to which of these
is preferable, and potentially which is most preferable for the web
console vs the ORB.
Aaron
On Tue, 12 Jul 2005, David Blevins wrote:
> On Tue, Jul 12, 2005 at 07:17:44PM -0400, Davanum Srinivas wrote:
> > It's a judgement call i guess. i have not been on the calls. If you
> > guys feel that it can support its own eco-system. then thats fine.
> >
>
> I don't know yet, myself. But certainly one cannot deny there are
> more CORBA specs than Web Services specs (for a while anyway); not
> exactly the same deal as a web console.
>
> -David
>
> > On 7/12/05, David Blevins <da...@visi.com> wrote:
> > > On Tue, Jul 12, 2005 at 06:58:20PM -0400, Davanum Srinivas wrote:
> > > > It's just that the piece of code we are talking about in both cases,
> > > > seem un-usable w/o geronimo.
> > >
> > > Is that really true? We are talking about a compliant ORB aren't we?
> > >
> > > -David
> > >
> >
> >
> > --
> > Davanum Srinivas -http://blogs.cocoondev.org/dims/
>
Re: Is it a mountain? (Re: Donation of Admin Console- request for help)
Posted by si...@insession.com.
David Blevins <da...@visi.com> wrote on 13/07/2005 09:38:36 AM:
> On Tue, Jul 12, 2005 at 07:17:44PM -0400, Davanum Srinivas wrote:
> > It's a judgement call i guess. i have not been on the calls. If you
> > guys feel that it can support its own eco-system. then thats fine.
> >
>
> I don't know yet, myself. But certainly one cannot deny there are
> more CORBA specs than Web Services specs (for a while anyway); not
> exactly the same deal as a web console.
My concern is that if we start out with its own eco-system then the
project may try to do more than what is initially needed by Geronimo and
therefore take longer to satisfy Geronimo's needs. Should we be trying to
ensure that we start out with the most productive project setup to get it
integrated with Geronimo as quick as possible and later consider moving he
ORB to its own eco-system.
John
>
> -David
>
> > On 7/12/05, David Blevins <da...@visi.com> wrote:
> > > On Tue, Jul 12, 2005 at 06:58:20PM -0400, Davanum Srinivas wrote:
> > > > It's just that the piece of code we are talking about in both
cases,
> > > > seem un-usable w/o geronimo.
> > >
> > > Is that really true? We are talking about a compliant ORB aren't
we?
> > >
> > > -David
> > >
> >
> >
> > --
> > Davanum Srinivas -http://blogs.cocoondev.org/dims/
This e-mail message and any attachments may contain confidential,
proprietary or non-public information. This information is intended
solely for the designated recipient(s). If an addressing or transmission
error has misdirected this e-mail, please notify the sender immediately
and destroy this e-mail. Any review, dissemination, use or reliance upon
this information by unintended recipients is prohibited. Any opinions
expressed in this e-mail are those of the author personally.
Re: Is it a mountain? (Re: Donation of Admin Console- request for help)
Posted by David Blevins <da...@visi.com>.
On Tue, Jul 12, 2005 at 07:17:44PM -0400, Davanum Srinivas wrote:
> It's a judgement call i guess. i have not been on the calls. If you
> guys feel that it can support its own eco-system. then thats fine.
>
I don't know yet, myself. But certainly one cannot deny there are
more CORBA specs than Web Services specs (for a while anyway); not
exactly the same deal as a web console.
-David
> On 7/12/05, David Blevins <da...@visi.com> wrote:
> > On Tue, Jul 12, 2005 at 06:58:20PM -0400, Davanum Srinivas wrote:
> > > It's just that the piece of code we are talking about in both cases,
> > > seem un-usable w/o geronimo.
> >
> > Is that really true? We are talking about a compliant ORB aren't we?
> >
> > -David
> >
>
>
> --
> Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: Is it a mountain? (Re: Donation of Admin Console- request for help)
Posted by Davanum Srinivas <da...@gmail.com>.
It's a judgement call i guess. i have not been on the calls. If you
guys feel that it can support its own eco-system. then thats fine.
-- dims
On 7/12/05, David Blevins <da...@visi.com> wrote:
> On Tue, Jul 12, 2005 at 06:58:20PM -0400, Davanum Srinivas wrote:
> > It's just that the piece of code we are talking about in both cases,
> > seem un-usable w/o geronimo.
>
> Is that really true? We are talking about a compliant ORB aren't we?
>
> -David
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: Is it a mountain? (Re: Donation of Admin Console- request for help)
Posted by David Blevins <da...@visi.com>.
On Tue, Jul 12, 2005 at 06:58:20PM -0400, Davanum Srinivas wrote:
> It's just that the piece of code we are talking about in both cases,
> seem un-usable w/o geronimo.
Is that really true? We are talking about a compliant ORB aren't we?
-David
Re: Is it a mountain? (Re: Donation of Admin Console- request for help)
Posted by Davanum Srinivas <da...@gmail.com>.
Dain,
No, i did not say we should avoid the incubator. It's just that the
piece of code we are talking about in both cases, seem un-usable w/o
geronimo. so a standalone project with its own infrastructure
(svn/committers/wiki/mailinglists etc) seems unnecessary. since most
of the work in those 2 will impact geronimo and changes to geronimo
will impact those 2. it just seems natural to share the mailing list
and svn notifications and not have a separate infrastructure. so that
leaves us with just the ACL.....
-- dims
On 7/12/05, Dain Sundstrom <da...@iq80.com> wrote:
> Dims,
>
> Can you be more specific? I don't want to put words in your mouth,
> but it seems like you are suggesting we should avoid the incubator.
> Is that what you are saying? If so, why? I am under the impression
> that this is exactly what the incubator is designed to do.
>
> I'm really interested in everyone's opinion, which is why I'm trying
> to stay out of the discussion for a while. I have seen a few
> comments like this in this discussion, but no one is being specific.
>
> TIA
>
> -dain
>
> On Jul 12, 2005, at 2:10 PM, Davanum Srinivas wrote:
>
> > Aaron,
> >
> > I have gotten quite a few projects processed thru incubator...so
> > please follow my advice :)
> >
> > -- dims
> >
> > On 7/12/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> >
> >> On Tue, 12 Jul 2005, Davanum Srinivas wrote:
> >>
> >>> PMC's can maintain separate ACL's for each svn thingy. Get them to
> >>> become Apache committers, setup a separate svn area for them to
> >>> work.
> >>> Then VOTE them into regular geronimo project when you think they are
> >>> ready (each person on their merit).
> >>>
> >>
> >> Sorry, I must have misunderstood your previous line '+1 to
> >> accept
> >> new folks from these contrib as "regular" committers' -- I thought by
> >> "regular" you meant "completely unrestricted".
> >>
> >> I am OK with what you state above, though I still prefer the
> >> incubator.
> >>
> >> Aaroon
> >>
> >>
> >>> On 7/12/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> >>>
> >>>> I'm sorry, I don't agree that donating code should
> >>>> entitle a
> >>>> company to nominate committers. Even separating the issue of
> >>>> donating
> >>>> code, I don't like adding committers when we don't know them,
> >>>> aren't
> >>>> familiar with their work, etc. I think it will be hard to
> >>>> convince me
> >>>> otherwise, but I am known to be conservative in this regard. :)
> >>>>
> >>>> Given the above, I prefer the incubator because we can
> >>>> all get to
> >>>> know each other there, the people who know the code can have
> >>>> immediate
> >>>> commit on the code (as can interested Geronimo folks), we can start
> >>>> working and evaluate the donation before deciding where it belongs
> >>>> long-term, etc. It would be slightly more difficult to
> >>>> integrate with
> >>>> Geronimo for testing purposes, but we face similar issues with
> >>>> OpenEJB and
> >>>> TranQL already. On this, I am willing to be convinced that some
> >>>> kind of
> >>>> Geronimo sub-area is best, but I think the incubator is better as a
> >>>> general rule.
> >>>>
> >>>> As for why we need general rules, I don't fancy having this
> >>>> extended dialogue every time there's a donation on the table. I
> >>>> used to
> >>>> think we wouldn't have that many donations, but after 2 in the
> >>>> last month,
> >>>> I'm not so sure.
> >>>>
> >>>> And, of course, I support David J's statement of mentoring
> >>>> principles and so on.
> >>>>
> >>>> Aaron
> >>>>
> >>>> On Tue, 12 Jul 2005, Davanum Srinivas wrote:
> >>>>
> >>>>> +1 to accept both the console and trifork code. Let Geir worry
> >>>>> about
> >>>>> paperwork. (Ask for a software grant from both companies such
> >>>>> that we
> >>>>> can place the code in our SVN.)
> >>>>> +1 to accept new folks from these contrib as "regular"
> >>>>> committers (we
> >>>>> can have a public vote once we get list of people from these 2
> >>>>> companies)
> >>>>>
> >>>>> Why is this so difficult?
> >>>>>
> >>>>> -- dims
> >>>>>
> >>>>> On 7/12/05, Bruce Snyder <br...@gmail.com> wrote:
> >>>>>
> >>>>>> After rereading this entire discussion, I'm still not sure
> >>>>>> that we've
> >>>>>> provided the requested guidance to the original reqeust that
> >>>>>> started
> >>>>>> this thread. What's more, given the debate that has taken
> >>>>>> place, I'm
> >>>>>> not sure that there's a consensus in any one direction. So
> >>>>>> I've got a
> >>>>>> couple of questions:
> >>>>>>
> >>>>>> 1) Is this the same management console that I downloaded from
> >>>>>> Gluecode
> >>>>>> as the Joe evaluation licensed product?
> >>>>>>
> >>>>>> 2) Will the management console come straight to Geronimo or go
> >>>>>> through
> >>>>>> the Incubator?
> >>>>>>
> >>>>>> One additional suggestion on the table seemed to surround the
> >>>>>> establishment of policies surrounding code donation. I'm not
> >>>>>> clear on
> >>>>>> why some people feel that policies need to be established. Why
> >>>>>> are
> >>>>>> people so hung up on establishing policies for so many things?
> >>>>>> IMO,
> >>>>>> rules for rules sake is just silly. I think we need to test
> >>>>>> the waters
> >>>>>> with some code donations before we go so far as to establish
> >>>>>> policies
> >>>>>> and precedents. Let's please crawl before we walk.
> >>>>>>
> >>>>>> Bruce
> >>>>>> --
> >>>>>> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-
> >>>>>> N>61E<D\!G;6%I;\"YC;VT*"
> >>>>>> );'
> >>>>>>
> >>>>>> The Castor Project
> >>>>>> http://www.castor.org/
> >>>>>>
> >>>>>> Apache Geronimo
> >>>>>> http://geronimo.apache.org/
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Davanum Srinivas -http://blogs.cocoondev.org/dims/
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Davanum Srinivas -http://blogs.cocoondev.org/dims/
> >>>
> >>>
> >>
> >>
> >
> >
> > --
> > Davanum Srinivas -http://blogs.cocoondev.org/dims/
> >
>
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: Is it a mountain? (Re: Donation of Admin Console- request for help)
Posted by Dain Sundstrom <da...@iq80.com>.
Dims,
Can you be more specific? I don't want to put words in your mouth,
but it seems like you are suggesting we should avoid the incubator.
Is that what you are saying? If so, why? I am under the impression
that this is exactly what the incubator is designed to do.
I'm really interested in everyone's opinion, which is why I'm trying
to stay out of the discussion for a while. I have seen a few
comments like this in this discussion, but no one is being specific.
TIA
-dain
On Jul 12, 2005, at 2:10 PM, Davanum Srinivas wrote:
> Aaron,
>
> I have gotten quite a few projects processed thru incubator...so
> please follow my advice :)
>
> -- dims
>
> On 7/12/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
>
>> On Tue, 12 Jul 2005, Davanum Srinivas wrote:
>>
>>> PMC's can maintain separate ACL's for each svn thingy. Get them to
>>> become Apache committers, setup a separate svn area for them to
>>> work.
>>> Then VOTE them into regular geronimo project when you think they are
>>> ready (each person on their merit).
>>>
>>
>> Sorry, I must have misunderstood your previous line '+1 to
>> accept
>> new folks from these contrib as "regular" committers' -- I thought by
>> "regular" you meant "completely unrestricted".
>>
>> I am OK with what you state above, though I still prefer the
>> incubator.
>>
>> Aaroon
>>
>>
>>> On 7/12/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
>>>
>>>> I'm sorry, I don't agree that donating code should
>>>> entitle a
>>>> company to nominate committers. Even separating the issue of
>>>> donating
>>>> code, I don't like adding committers when we don't know them,
>>>> aren't
>>>> familiar with their work, etc. I think it will be hard to
>>>> convince me
>>>> otherwise, but I am known to be conservative in this regard. :)
>>>>
>>>> Given the above, I prefer the incubator because we can
>>>> all get to
>>>> know each other there, the people who know the code can have
>>>> immediate
>>>> commit on the code (as can interested Geronimo folks), we can start
>>>> working and evaluate the donation before deciding where it belongs
>>>> long-term, etc. It would be slightly more difficult to
>>>> integrate with
>>>> Geronimo for testing purposes, but we face similar issues with
>>>> OpenEJB and
>>>> TranQL already. On this, I am willing to be convinced that some
>>>> kind of
>>>> Geronimo sub-area is best, but I think the incubator is better as a
>>>> general rule.
>>>>
>>>> As for why we need general rules, I don't fancy having this
>>>> extended dialogue every time there's a donation on the table. I
>>>> used to
>>>> think we wouldn't have that many donations, but after 2 in the
>>>> last month,
>>>> I'm not so sure.
>>>>
>>>> And, of course, I support David J's statement of mentoring
>>>> principles and so on.
>>>>
>>>> Aaron
>>>>
>>>> On Tue, 12 Jul 2005, Davanum Srinivas wrote:
>>>>
>>>>> +1 to accept both the console and trifork code. Let Geir worry
>>>>> about
>>>>> paperwork. (Ask for a software grant from both companies such
>>>>> that we
>>>>> can place the code in our SVN.)
>>>>> +1 to accept new folks from these contrib as "regular"
>>>>> committers (we
>>>>> can have a public vote once we get list of people from these 2
>>>>> companies)
>>>>>
>>>>> Why is this so difficult?
>>>>>
>>>>> -- dims
>>>>>
>>>>> On 7/12/05, Bruce Snyder <br...@gmail.com> wrote:
>>>>>
>>>>>> After rereading this entire discussion, I'm still not sure
>>>>>> that we've
>>>>>> provided the requested guidance to the original reqeust that
>>>>>> started
>>>>>> this thread. What's more, given the debate that has taken
>>>>>> place, I'm
>>>>>> not sure that there's a consensus in any one direction. So
>>>>>> I've got a
>>>>>> couple of questions:
>>>>>>
>>>>>> 1) Is this the same management console that I downloaded from
>>>>>> Gluecode
>>>>>> as the Joe evaluation licensed product?
>>>>>>
>>>>>> 2) Will the management console come straight to Geronimo or go
>>>>>> through
>>>>>> the Incubator?
>>>>>>
>>>>>> One additional suggestion on the table seemed to surround the
>>>>>> establishment of policies surrounding code donation. I'm not
>>>>>> clear on
>>>>>> why some people feel that policies need to be established. Why
>>>>>> are
>>>>>> people so hung up on establishing policies for so many things?
>>>>>> IMO,
>>>>>> rules for rules sake is just silly. I think we need to test
>>>>>> the waters
>>>>>> with some code donations before we go so far as to establish
>>>>>> policies
>>>>>> and precedents. Let's please crawl before we walk.
>>>>>>
>>>>>> Bruce
>>>>>> --
>>>>>> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-
>>>>>> N>61E<D\!G;6%I;\"YC;VT*"
>>>>>> );'
>>>>>>
>>>>>> The Castor Project
>>>>>> http://www.castor.org/
>>>>>>
>>>>>> Apache Geronimo
>>>>>> http://geronimo.apache.org/
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>>>
>>>
>>
>>
>
>
> --
> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>
Re: Is it a mountain? (Re: Donation of Admin Console- request for help)
Posted by Davanum Srinivas <da...@gmail.com>.
Aaron,
I have gotten quite a few projects processed thru incubator...so
please follow my advice :)
-- dims
On 7/12/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> On Tue, 12 Jul 2005, Davanum Srinivas wrote:
> > PMC's can maintain separate ACL's for each svn thingy. Get them to
> > become Apache committers, setup a separate svn area for them to work.
> > Then VOTE them into regular geronimo project when you think they are
> > ready (each person on their merit).
>
> Sorry, I must have misunderstood your previous line '+1 to accept
> new folks from these contrib as "regular" committers' -- I thought by
> "regular" you meant "completely unrestricted".
>
> I am OK with what you state above, though I still prefer the
> incubator.
>
> Aaroon
>
> > On 7/12/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> > > I'm sorry, I don't agree that donating code should entitle a
> > > company to nominate committers. Even separating the issue of donating
> > > code, I don't like adding committers when we don't know them, aren't
> > > familiar with their work, etc. I think it will be hard to convince me
> > > otherwise, but I am known to be conservative in this regard. :)
> > >
> > > Given the above, I prefer the incubator because we can all get to
> > > know each other there, the people who know the code can have immediate
> > > commit on the code (as can interested Geronimo folks), we can start
> > > working and evaluate the donation before deciding where it belongs
> > > long-term, etc. It would be slightly more difficult to integrate with
> > > Geronimo for testing purposes, but we face similar issues with OpenEJB and
> > > TranQL already. On this, I am willing to be convinced that some kind of
> > > Geronimo sub-area is best, but I think the incubator is better as a
> > > general rule.
> > >
> > > As for why we need general rules, I don't fancy having this
> > > extended dialogue every time there's a donation on the table. I used to
> > > think we wouldn't have that many donations, but after 2 in the last month,
> > > I'm not so sure.
> > >
> > > And, of course, I support David J's statement of mentoring
> > > principles and so on.
> > >
> > > Aaron
> > >
> > > On Tue, 12 Jul 2005, Davanum Srinivas wrote:
> > > > +1 to accept both the console and trifork code. Let Geir worry about
> > > > paperwork. (Ask for a software grant from both companies such that we
> > > > can place the code in our SVN.)
> > > > +1 to accept new folks from these contrib as "regular" committers (we
> > > > can have a public vote once we get list of people from these 2
> > > > companies)
> > > >
> > > > Why is this so difficult?
> > > >
> > > > -- dims
> > > >
> > > > On 7/12/05, Bruce Snyder <br...@gmail.com> wrote:
> > > > > After rereading this entire discussion, I'm still not sure that we've
> > > > > provided the requested guidance to the original reqeust that started
> > > > > this thread. What's more, given the debate that has taken place, I'm
> > > > > not sure that there's a consensus in any one direction. So I've got a
> > > > > couple of questions:
> > > > >
> > > > > 1) Is this the same management console that I downloaded from Gluecode
> > > > > as the Joe evaluation licensed product?
> > > > >
> > > > > 2) Will the management console come straight to Geronimo or go through
> > > > > the Incubator?
> > > > >
> > > > > One additional suggestion on the table seemed to surround the
> > > > > establishment of policies surrounding code donation. I'm not clear on
> > > > > why some people feel that policies need to be established. Why are
> > > > > people so hung up on establishing policies for so many things? IMO,
> > > > > rules for rules sake is just silly. I think we need to test the waters
> > > > > with some code donations before we go so far as to establish policies
> > > > > and precedents. Let's please crawl before we walk.
> > > > >
> > > > > Bruce
> > > > > --
> > > > > perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> > > > > );'
> > > > >
> > > > > The Castor Project
> > > > > http://www.castor.org/
> > > > >
> > > > > Apache Geronimo
> > > > > http://geronimo.apache.org/
> > > > >
> > > >
> > > >
> > > > --
> > > > Davanum Srinivas -http://blogs.cocoondev.org/dims/
> > > >
> > >
> >
> >
> > --
> > Davanum Srinivas -http://blogs.cocoondev.org/dims/
> >
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: Is it a mountain? (Re: Donation of Admin Console- request for
help)
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Tue, 12 Jul 2005, Davanum Srinivas wrote:
> PMC's can maintain separate ACL's for each svn thingy. Get them to
> become Apache committers, setup a separate svn area for them to work.
> Then VOTE them into regular geronimo project when you think they are
> ready (each person on their merit).
Sorry, I must have misunderstood your previous line '+1 to accept
new folks from these contrib as "regular" committers' -- I thought by
"regular" you meant "completely unrestricted".
I am OK with what you state above, though I still prefer the
incubator.
Aaroon
> On 7/12/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> > I'm sorry, I don't agree that donating code should entitle a
> > company to nominate committers. Even separating the issue of donating
> > code, I don't like adding committers when we don't know them, aren't
> > familiar with their work, etc. I think it will be hard to convince me
> > otherwise, but I am known to be conservative in this regard. :)
> >
> > Given the above, I prefer the incubator because we can all get to
> > know each other there, the people who know the code can have immediate
> > commit on the code (as can interested Geronimo folks), we can start
> > working and evaluate the donation before deciding where it belongs
> > long-term, etc. It would be slightly more difficult to integrate with
> > Geronimo for testing purposes, but we face similar issues with OpenEJB and
> > TranQL already. On this, I am willing to be convinced that some kind of
> > Geronimo sub-area is best, but I think the incubator is better as a
> > general rule.
> >
> > As for why we need general rules, I don't fancy having this
> > extended dialogue every time there's a donation on the table. I used to
> > think we wouldn't have that many donations, but after 2 in the last month,
> > I'm not so sure.
> >
> > And, of course, I support David J's statement of mentoring
> > principles and so on.
> >
> > Aaron
> >
> > On Tue, 12 Jul 2005, Davanum Srinivas wrote:
> > > +1 to accept both the console and trifork code. Let Geir worry about
> > > paperwork. (Ask for a software grant from both companies such that we
> > > can place the code in our SVN.)
> > > +1 to accept new folks from these contrib as "regular" committers (we
> > > can have a public vote once we get list of people from these 2
> > > companies)
> > >
> > > Why is this so difficult?
> > >
> > > -- dims
> > >
> > > On 7/12/05, Bruce Snyder <br...@gmail.com> wrote:
> > > > After rereading this entire discussion, I'm still not sure that we've
> > > > provided the requested guidance to the original reqeust that started
> > > > this thread. What's more, given the debate that has taken place, I'm
> > > > not sure that there's a consensus in any one direction. So I've got a
> > > > couple of questions:
> > > >
> > > > 1) Is this the same management console that I downloaded from Gluecode
> > > > as the Joe evaluation licensed product?
> > > >
> > > > 2) Will the management console come straight to Geronimo or go through
> > > > the Incubator?
> > > >
> > > > One additional suggestion on the table seemed to surround the
> > > > establishment of policies surrounding code donation. I'm not clear on
> > > > why some people feel that policies need to be established. Why are
> > > > people so hung up on establishing policies for so many things? IMO,
> > > > rules for rules sake is just silly. I think we need to test the waters
> > > > with some code donations before we go so far as to establish policies
> > > > and precedents. Let's please crawl before we walk.
> > > >
> > > > Bruce
> > > > --
> > > > perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> > > > );'
> > > >
> > > > The Castor Project
> > > > http://www.castor.org/
> > > >
> > > > Apache Geronimo
> > > > http://geronimo.apache.org/
> > > >
> > >
> > >
> > > --
> > > Davanum Srinivas -http://blogs.cocoondev.org/dims/
> > >
> >
>
>
> --
> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>
Re: Is it a mountain? (Re: Donation of Admin Console- request for
help)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Yes, that was already discussed. But, given your previous statement, I
can see how he misunderstood.
Davanum Srinivas wrote, On 7/12/2005 1:59 PM:
>PMC's can maintain separate ACL's for each svn thingy. Get them to
>become Apache committers, setup a separate svn area for them to work.
>Then VOTE them into regular geronimo project when you think they are
>ready (each person on their merit).
>
>-- dims
>
>On 7/12/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
>
>
>> I'm sorry, I don't agree that donating code should entitle a
>>company to nominate committers. Even separating the issue of donating
>>code, I don't like adding committers when we don't know them, aren't
>>familiar with their work, etc. I think it will be hard to convince me
>>otherwise, but I am known to be conservative in this regard. :)
>>
>> Given the above, I prefer the incubator because we can all get to
>>know each other there, the people who know the code can have immediate
>>commit on the code (as can interested Geronimo folks), we can start
>>working and evaluate the donation before deciding where it belongs
>>long-term, etc. It would be slightly more difficult to integrate with
>>Geronimo for testing purposes, but we face similar issues with OpenEJB and
>>TranQL already. On this, I am willing to be convinced that some kind of
>>Geronimo sub-area is best, but I think the incubator is better as a
>>general rule.
>>
>> As for why we need general rules, I don't fancy having this
>>extended dialogue every time there's a donation on the table. I used to
>>think we wouldn't have that many donations, but after 2 in the last month,
>>I'm not so sure.
>>
>> And, of course, I support David J's statement of mentoring
>>principles and so on.
>>
>>Aaron
>>
>>On Tue, 12 Jul 2005, Davanum Srinivas wrote:
>>
>>
>>>+1 to accept both the console and trifork code. Let Geir worry about
>>>paperwork. (Ask for a software grant from both companies such that we
>>>can place the code in our SVN.)
>>>+1 to accept new folks from these contrib as "regular" committers (we
>>>can have a public vote once we get list of people from these 2
>>>companies)
>>>
>>>Why is this so difficult?
>>>
>>>-- dims
>>>
>>>On 7/12/05, Bruce Snyder <br...@gmail.com> wrote:
>>>
>>>
>>>>After rereading this entire discussion, I'm still not sure that we've
>>>>provided the requested guidance to the original reqeust that started
>>>>this thread. What's more, given the debate that has taken place, I'm
>>>>not sure that there's a consensus in any one direction. So I've got a
>>>>couple of questions:
>>>>
>>>>1) Is this the same management console that I downloaded from Gluecode
>>>>as the Joe evaluation licensed product?
>>>>
>>>>2) Will the management console come straight to Geronimo or go through
>>>>the Incubator?
>>>>
>>>>One additional suggestion on the table seemed to surround the
>>>>establishment of policies surrounding code donation. I'm not clear on
>>>>why some people feel that policies need to be established. Why are
>>>>people so hung up on establishing policies for so many things? IMO,
>>>>rules for rules sake is just silly. I think we need to test the waters
>>>>with some code donations before we go so far as to establish policies
>>>>and precedents. Let's please crawl before we walk.
>>>>
>>>>Bruce
>>>>--
>>>>perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>>>>);'
>>>>
>>>>The Castor Project
>>>>http://www.castor.org/
>>>>
>>>>Apache Geronimo
>>>>http://geronimo.apache.org/
>>>>
>>>>
>>>>
>>>--
>>>Davanum Srinivas -http://blogs.cocoondev.org/dims/
>>>
>>>
>>>
>
>
>
>
Re: Is it a mountain? (Re: Donation of Admin Console- request for help)
Posted by Davanum Srinivas <da...@gmail.com>.
PMC's can maintain separate ACL's for each svn thingy. Get them to
become Apache committers, setup a separate svn area for them to work.
Then VOTE them into regular geronimo project when you think they are
ready (each person on their merit).
-- dims
On 7/12/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> I'm sorry, I don't agree that donating code should entitle a
> company to nominate committers. Even separating the issue of donating
> code, I don't like adding committers when we don't know them, aren't
> familiar with their work, etc. I think it will be hard to convince me
> otherwise, but I am known to be conservative in this regard. :)
>
> Given the above, I prefer the incubator because we can all get to
> know each other there, the people who know the code can have immediate
> commit on the code (as can interested Geronimo folks), we can start
> working and evaluate the donation before deciding where it belongs
> long-term, etc. It would be slightly more difficult to integrate with
> Geronimo for testing purposes, but we face similar issues with OpenEJB and
> TranQL already. On this, I am willing to be convinced that some kind of
> Geronimo sub-area is best, but I think the incubator is better as a
> general rule.
>
> As for why we need general rules, I don't fancy having this
> extended dialogue every time there's a donation on the table. I used to
> think we wouldn't have that many donations, but after 2 in the last month,
> I'm not so sure.
>
> And, of course, I support David J's statement of mentoring
> principles and so on.
>
> Aaron
>
> On Tue, 12 Jul 2005, Davanum Srinivas wrote:
> > +1 to accept both the console and trifork code. Let Geir worry about
> > paperwork. (Ask for a software grant from both companies such that we
> > can place the code in our SVN.)
> > +1 to accept new folks from these contrib as "regular" committers (we
> > can have a public vote once we get list of people from these 2
> > companies)
> >
> > Why is this so difficult?
> >
> > -- dims
> >
> > On 7/12/05, Bruce Snyder <br...@gmail.com> wrote:
> > > After rereading this entire discussion, I'm still not sure that we've
> > > provided the requested guidance to the original reqeust that started
> > > this thread. What's more, given the debate that has taken place, I'm
> > > not sure that there's a consensus in any one direction. So I've got a
> > > couple of questions:
> > >
> > > 1) Is this the same management console that I downloaded from Gluecode
> > > as the Joe evaluation licensed product?
> > >
> > > 2) Will the management console come straight to Geronimo or go through
> > > the Incubator?
> > >
> > > One additional suggestion on the table seemed to surround the
> > > establishment of policies surrounding code donation. I'm not clear on
> > > why some people feel that policies need to be established. Why are
> > > people so hung up on establishing policies for so many things? IMO,
> > > rules for rules sake is just silly. I think we need to test the waters
> > > with some code donations before we go so far as to establish policies
> > > and precedents. Let's please crawl before we walk.
> > >
> > > Bruce
> > > --
> > > perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> > > );'
> > >
> > > The Castor Project
> > > http://www.castor.org/
> > >
> > > Apache Geronimo
> > > http://geronimo.apache.org/
> > >
> >
> >
> > --
> > Davanum Srinivas -http://blogs.cocoondev.org/dims/
> >
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: Is it a mountain? (Re: Donation of Admin Console- request for
help)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On 7/12/2005 7:28 PM, Jeff Genender wrote:
>Its not fear....
>
>Its fairness to the community...we have a lot of people who have contributed
>in one way or another and would like to be a committer, but are not. I
>think there is something to say not only for the contributions, but the
>commitment to the project. IMHO the "commit" of committer also means
>commitment. The last thing we want to do is offer full commitership to a
>couple of commercial entities out-of-the-box. I think that would give the
>wrong impressions to the community.
>
>In addition, I think its fair to say that we should get to know the team
>players before giving them the keys to the house.
>
>Given that this is an open source project, it should follow the unwritten
>rules of acquiring committership. IMHO, donating code does not guarantee
>commitment to the project.
>
>I really don't see an issue with ACLing off an area, be it the sandbox,
>sub-project, or incubation, with the aspect of stating that if they show the
>commitment, they will be granted karma. It's the way its mostly been done,
>and I see no reason this should change now.
>
>
This reflects my sentiments as well.
Regards,
Alan
RE: Is it a mountain? (Re: Donation of Admin Console- request for help)
Posted by Jeff Genender <jg...@savoirtech.com>.
Its not fear....
Its fairness to the community...we have a lot of people who have contributed
in one way or another and would like to be a committer, but are not. I
think there is something to say not only for the contributions, but the
commitment to the project. IMHO the "commit" of committer also means
commitment. The last thing we want to do is offer full commitership to a
couple of commercial entities out-of-the-box. I think that would give the
wrong impressions to the community.
In addition, I think its fair to say that we should get to know the team
players before giving them the keys to the house.
Given that this is an open source project, it should follow the unwritten
rules of acquiring committership. IMHO, donating code does not guarantee
commitment to the project.
I really don't see an issue with ACLing off an area, be it the sandbox,
sub-project, or incubation, with the aspect of stating that if they show the
commitment, they will be granted karma. It's the way its mostly been done,
and I see no reason this should change now.
Jeff
-----Original Message-----
From: Davanum Srinivas [mailto:davanum@gmail.com]
Sent: Tuesday, July 12, 2005 7:46 PM
To: dev@geronimo.apache.org
Subject: Re: Is it a mountain? (Re: Donation of Admin Console- request for
help)
I hardly knew any of you...yet i supported as much as i could even during
the early stages. same thing am doing with beehive/wsrp4j/muse (anything
that as a ws component whether they are destined for ws pmc or not).
remember, this is an open-source project!!!!!!!
what is it that you are afraid of? (that a few technical -1's on code
checkin would not handle?)
-- dims
On 7/12/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
> On Jul 12, 2005, at 5:47 PM, Jeff Genender wrote:
> >
> > Davanum Srinivas wrote:
> >
> >> +1 to accept both the console and trifork code. Let Geir worry
> >> +about
> >> paperwork. (Ask for a software grant from both companies such that
> >> we can place the code in our SVN.)
> >>
> >
> > +1
> >
> >> +1 to accept new folks from these contrib as "regular" committers
> >> +(we
> >> can have a public vote once we get list of people from these 2
> >> companies)
> >>
> >
> > -1. Thats not fair to the community. I would ACL it...let them
> > prove themselves individually before being given the keys to the
> > car. This is only fair to all the other folks who had to prove
> > their commitment to community.
>
> Let me ask a question - how do you define and measure commitment?
>
> Clearly, we have traditionally used "demonstrated interest in the
> project" as a yardstick, as well as "demonstrated contribution to the
> project"? That's really what we're concerned about, right?
>
> I think that people can do this in different ways. David Jencks
> throws tons of time at code. I throw tons of time at less technical,
> and more at community, administrative and legal issues.
>
> Would it be sufficient for someone to take software that they created,
> maybe even built a business on, and not only offered to donate with no
> strings attached to the project for us to do with as we wish, but also
> offered an even more precious commodity, interested and dedicated
> people to work on it, to ask for a place at the table?
>
> geir
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: Is it a mountain? (Re: Donation of Admin Console- request for help)
Posted by Davanum Srinivas <da...@gmail.com>.
that was i think meant for Jeff and Aaron (too many email to
remember!!!. we sure are burning more cycles on this than it's worth.)
-- dims
On 7/12/05, Davanum Srinivas <da...@gmail.com> wrote:
> I hardly knew any of you...yet i supported as much as i could even
> during the early stages. same thing am doing with beehive/wsrp4j/muse
> (anything that as a ws component whether they are destined for ws pmc
> or not). remember, this is an open-source project!!!!!!!
>
> what is it that you are afraid of? (that a few technical -1's on code
> checkin would not handle?)
>
> -- dims
>
> On 7/12/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> >
> > On Jul 12, 2005, at 5:47 PM, Jeff Genender wrote:
> > >
> > > Davanum Srinivas wrote:
> > >
> > >> +1 to accept both the console and trifork code. Let Geir worry about
> > >> paperwork. (Ask for a software grant from both companies such that we
> > >> can place the code in our SVN.)
> > >>
> > >
> > > +1
> > >
> > >> +1 to accept new folks from these contrib as "regular" committers (we
> > >> can have a public vote once we get list of people from these 2
> > >> companies)
> > >>
> > >
> > > -1. Thats not fair to the community. I would ACL it...let them
> > > prove themselves individually before being given the keys to the
> > > car. This is only fair to all the other folks who had to prove
> > > their commitment to community.
> >
> > Let me ask a question - how do you define and measure commitment?
> >
> > Clearly, we have traditionally used "demonstrated interest in the
> > project" as a yardstick, as well as "demonstrated contribution to
> > the project"? That's really what we're concerned about, right?
> >
> > I think that people can do this in different ways. David Jencks
> > throws tons of time at code. I throw tons of time at less technical,
> > and more at community, administrative and legal issues.
> >
> > Would it be sufficient for someone to take software that they
> > created, maybe even built a business on, and not only offered to
> > donate with no strings attached to the project for us to do with as
> > we wish, but also offered an even more precious commodity, interested
> > and dedicated people to work on it, to ask for a place at the table?
> >
> > geir
> >
> > --
> > Geir Magnusson Jr +1-203-665-6437
> > geirm@apache.org
> >
> >
> >
>
>
> --
> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
RE: Is it a mountain? (Re: Donation of Admin Console- request for help)
Posted by Jeff Genender <jg...@savoirtech.com>.
Whoops I hit send too fast as I wanted to address one more issue in this...
This is truly not an issue of support. All of this donated code has not
only my full support, but I would like the opportunity to help out as
well...so support from my perspective is there at 150%.
Jeff
-----Original Message-----
From: Davanum Srinivas [mailto:davanum@gmail.com]
Sent: Tuesday, July 12, 2005 7:46 PM
To: dev@geronimo.apache.org
Subject: Re: Is it a mountain? (Re: Donation of Admin Console- request for
help)
I hardly knew any of you...yet i supported as much as i could even during
the early stages. same thing am doing with beehive/wsrp4j/muse (anything
that as a ws component whether they are destined for ws pmc or not).
remember, this is an open-source project!!!!!!!
what is it that you are afraid of? (that a few technical -1's on code
checkin would not handle?)
-- dims
On 7/12/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
> On Jul 12, 2005, at 5:47 PM, Jeff Genender wrote:
> >
> > Davanum Srinivas wrote:
> >
> >> +1 to accept both the console and trifork code. Let Geir worry
> >> +about
> >> paperwork. (Ask for a software grant from both companies such that
> >> we can place the code in our SVN.)
> >>
> >
> > +1
> >
> >> +1 to accept new folks from these contrib as "regular" committers
> >> +(we
> >> can have a public vote once we get list of people from these 2
> >> companies)
> >>
> >
> > -1. Thats not fair to the community. I would ACL it...let them
> > prove themselves individually before being given the keys to the
> > car. This is only fair to all the other folks who had to prove
> > their commitment to community.
>
> Let me ask a question - how do you define and measure commitment?
>
> Clearly, we have traditionally used "demonstrated interest in the
> project" as a yardstick, as well as "demonstrated contribution to the
> project"? That's really what we're concerned about, right?
>
> I think that people can do this in different ways. David Jencks
> throws tons of time at code. I throw tons of time at less technical,
> and more at community, administrative and legal issues.
>
> Would it be sufficient for someone to take software that they created,
> maybe even built a business on, and not only offered to donate with no
> strings attached to the project for us to do with as we wish, but also
> offered an even more precious commodity, interested and dedicated
> people to work on it, to ask for a place at the table?
>
> geir
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: Is it a mountain? (Re: Donation of Admin Console- request for
help)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On 7/12/2005 6:45 PM, Davanum Srinivas wrote:
>I hardly knew any of you...yet i supported as much as i could even
>during the early stages. same thing am doing with beehive/wsrp4j/muse
>(anything that as a ws component whether they are destined for ws pmc
>or not). remember, this is an open-source project!!!!!!!
>
>what is it that you are afraid of? (that a few technical -1's on code
>checkin would not handle?)
>
>
So if I came in with a donation and an offer to work on webservices,
would you grant me immediate commit privs?
Regards,
Alan
Re: Is it a mountain? (Re: Donation of Admin Console- request for help)
Posted by Davanum Srinivas <da...@gmail.com>.
I hardly knew any of you...yet i supported as much as i could even
during the early stages. same thing am doing with beehive/wsrp4j/muse
(anything that as a ws component whether they are destined for ws pmc
or not). remember, this is an open-source project!!!!!!!
what is it that you are afraid of? (that a few technical -1's on code
checkin would not handle?)
-- dims
On 7/12/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
> On Jul 12, 2005, at 5:47 PM, Jeff Genender wrote:
> >
> > Davanum Srinivas wrote:
> >
> >> +1 to accept both the console and trifork code. Let Geir worry about
> >> paperwork. (Ask for a software grant from both companies such that we
> >> can place the code in our SVN.)
> >>
> >
> > +1
> >
> >> +1 to accept new folks from these contrib as "regular" committers (we
> >> can have a public vote once we get list of people from these 2
> >> companies)
> >>
> >
> > -1. Thats not fair to the community. I would ACL it...let them
> > prove themselves individually before being given the keys to the
> > car. This is only fair to all the other folks who had to prove
> > their commitment to community.
>
> Let me ask a question - how do you define and measure commitment?
>
> Clearly, we have traditionally used "demonstrated interest in the
> project" as a yardstick, as well as "demonstrated contribution to
> the project"? That's really what we're concerned about, right?
>
> I think that people can do this in different ways. David Jencks
> throws tons of time at code. I throw tons of time at less technical,
> and more at community, administrative and legal issues.
>
> Would it be sufficient for someone to take software that they
> created, maybe even built a business on, and not only offered to
> donate with no strings attached to the project for us to do with as
> we wish, but also offered an even more precious commodity, interested
> and dedicated people to work on it, to ask for a place at the table?
>
> geir
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: Is it a mountain? (Re: Donation of Admin Console- request for
help)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Davanum Srinivas wrote, On 7/12/2005 1:01 PM:
>+1 to accept both the console and trifork code. Let Geir worry about
>paperwork. (Ask for a software grant from both companies such that we
>can place the code in our SVN.)
>
>
Yes, that is the high-level plan.
>+1 to accept new folks from these contrib as "regular" committers (we
>can have a public vote once we get list of people from these 2
>companies)
>
>
-1 Being a regular committer is based on a proven track record.
>Why is this so difficult?
>
>
It's not but, starting a new thread on this doesn't help.
Regards,
Alan
Re: Is it a mountain? (Re: Donation of Admin Console- request for
help)
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I'm sorry, I don't agree that donating code should entitle a
company to nominate committers. Even separating the issue of donating
code, I don't like adding committers when we don't know them, aren't
familiar with their work, etc. I think it will be hard to convince me
otherwise, but I am known to be conservative in this regard. :)
Given the above, I prefer the incubator because we can all get to
know each other there, the people who know the code can have immediate
commit on the code (as can interested Geronimo folks), we can start
working and evaluate the donation before deciding where it belongs
long-term, etc. It would be slightly more difficult to integrate with
Geronimo for testing purposes, but we face similar issues with OpenEJB and
TranQL already. On this, I am willing to be convinced that some kind of
Geronimo sub-area is best, but I think the incubator is better as a
general rule.
As for why we need general rules, I don't fancy having this
extended dialogue every time there's a donation on the table. I used to
think we wouldn't have that many donations, but after 2 in the last month,
I'm not so sure.
And, of course, I support David J's statement of mentoring
principles and so on.
Aaron
On Tue, 12 Jul 2005, Davanum Srinivas wrote:
> +1 to accept both the console and trifork code. Let Geir worry about
> paperwork. (Ask for a software grant from both companies such that we
> can place the code in our SVN.)
> +1 to accept new folks from these contrib as "regular" committers (we
> can have a public vote once we get list of people from these 2
> companies)
>
> Why is this so difficult?
>
> -- dims
>
> On 7/12/05, Bruce Snyder <br...@gmail.com> wrote:
> > After rereading this entire discussion, I'm still not sure that we've
> > provided the requested guidance to the original reqeust that started
> > this thread. What's more, given the debate that has taken place, I'm
> > not sure that there's a consensus in any one direction. So I've got a
> > couple of questions:
> >
> > 1) Is this the same management console that I downloaded from Gluecode
> > as the Joe evaluation licensed product?
> >
> > 2) Will the management console come straight to Geronimo or go through
> > the Incubator?
> >
> > One additional suggestion on the table seemed to surround the
> > establishment of policies surrounding code donation. I'm not clear on
> > why some people feel that policies need to be established. Why are
> > people so hung up on establishing policies for so many things? IMO,
> > rules for rules sake is just silly. I think we need to test the waters
> > with some code donations before we go so far as to establish policies
> > and precedents. Let's please crawl before we walk.
> >
> > Bruce
> > --
> > perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> > );'
> >
> > The Castor Project
> > http://www.castor.org/
> >
> > Apache Geronimo
> > http://geronimo.apache.org/
> >
>
>
> --
> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>
Re: Is it a mountain? (Re: Donation of Admin Console- request for help)
Posted by si...@insession.com.
Davanum Srinivas <da...@gmail.com> wrote on 13/07/2005 06:01:25 AM:
> +1 to accept both the console and trifork code. Let Geir worry about
> paperwork. (Ask for a software grant from both companies such that we
> can place the code in our SVN.)
+1
I feel we should be focusing on getting the Trifork code integrated with
Geronimo initially and worry about a standalone ORB project later. My
concern is if it goes to incubator is that it will introduce more
management overhead (setting up svn, mailing lists, committers, more build
complexities) and if it has separate mailing lists the Geronimo community
may not get as involved, which sounds important in the first year or two
of the project. Does going to incubator imply it will be developed as a
standalone project? Once the trifork code is integrated with Geronimo and
has stabilised then we could look at moving it to a standalone project
(with its own mailing lists etc).
> +1 to accept new folks from these contrib as "regular" committers (we
> can have a public vote once we get list of people from these 2
> companies)
-1
Have an ACL to give the donors commit access to just the area the donation
has been placed. Full commit access should only be granted by following
the normal procedures.
John
This e-mail message and any attachments may contain confidential,
proprietary or non-public information. This information is intended
solely for the designated recipient(s). If an addressing or transmission
error has misdirected this e-mail, please notify the sender immediately
and destroy this e-mail. Any review, dissemination, use or reliance upon
this information by unintended recipients is prohibited. Any opinions
expressed in this e-mail are those of the author personally.
Re: Is it a mountain? (Re: Donation of Admin Console- request for
help)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On 7/12/2005 6:38 PM, Geir Magnusson Jr. wrote:
>
> On Jul 12, 2005, at 5:47 PM, Jeff Genender wrote:
>
>>
>> Davanum Srinivas wrote:
>>
>>> +1 to accept new folks from these contrib as "regular" committers (we
>>> can have a public vote once we get list of people from these 2
>>> companies)
>>>
>>
>> -1. Thats not fair to the community. I would ACL it...let them
>> prove themselves individually before being given the keys to the
>> car. This is only fair to all the other folks who had to prove
>> their commitment to community.
>
>
> Let me ask a question - how do you define and measure commitment?
>
> Clearly, we have traditionally used "demonstrated interest in the
> project" as a yardstick, as well as "demonstrated contribution to
> the project"? That's really what we're concerned about, right?
>
> I think that people can do this in different ways. David Jencks
> throws tons of time at code. I throw tons of time at less technical,
> and more at community, administrative and legal issues.
>
> Would it be sufficient for someone to take software that they
> created, maybe even built a business on, and not only offered to
> donate with no strings attached to the project for us to do with as
> we wish, but also offered an even more precious commodity, interested
> and dedicated people to work on it, to ask for a place at the table?
No, they need to follow through and show that they will be active and
can work well within the community. Showing up to the door with a
donation and good intentions is not enough.
Regards,
Alan
Re: Is it a mountain? (Re: Donation of Admin Console- request for help)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 12, 2005, at 5:47 PM, Jeff Genender wrote:
>
> Davanum Srinivas wrote:
>
>> +1 to accept both the console and trifork code. Let Geir worry about
>> paperwork. (Ask for a software grant from both companies such that we
>> can place the code in our SVN.)
>>
>
> +1
>
>> +1 to accept new folks from these contrib as "regular" committers (we
>> can have a public vote once we get list of people from these 2
>> companies)
>>
>
> -1. Thats not fair to the community. I would ACL it...let them
> prove themselves individually before being given the keys to the
> car. This is only fair to all the other folks who had to prove
> their commitment to community.
Let me ask a question - how do you define and measure commitment?
Clearly, we have traditionally used "demonstrated interest in the
project" as a yardstick, as well as "demonstrated contribution to
the project"? That's really what we're concerned about, right?
I think that people can do this in different ways. David Jencks
throws tons of time at code. I throw tons of time at less technical,
and more at community, administrative and legal issues.
Would it be sufficient for someone to take software that they
created, maybe even built a business on, and not only offered to
donate with no strings attached to the project for us to do with as
we wish, but also offered an even more precious commodity, interested
and dedicated people to work on it, to ask for a place at the table?
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Is it a mountain? (Re: Donation of Admin Console- request for
help)
Posted by Jeff Genender <jg...@savoirtech.com>.
Davanum Srinivas wrote:
> +1 to accept both the console and trifork code. Let Geir worry about
> paperwork. (Ask for a software grant from both companies such that we
> can place the code in our SVN.)
+1
> +1 to accept new folks from these contrib as "regular" committers (we
> can have a public vote once we get list of people from these 2
> companies)
-1. Thats not fair to the community. I would ACL it...let them prove
themselves individually before being given the keys to the car. This is
only fair to all the other folks who had to prove their commitment to
community.
>
> Why is this so difficult?
>
> -- dims
>
> On 7/12/05, Bruce Snyder <br...@gmail.com> wrote:
>
>>After rereading this entire discussion, I'm still not sure that we've
>>provided the requested guidance to the original reqeust that started
>>this thread. What's more, given the debate that has taken place, I'm
>>not sure that there's a consensus in any one direction. So I've got a
>>couple of questions:
>>
>>1) Is this the same management console that I downloaded from Gluecode
>>as the Joe evaluation licensed product?
>>
>>2) Will the management console come straight to Geronimo or go through
>>the Incubator?
>>
>>One additional suggestion on the table seemed to surround the
>>establishment of policies surrounding code donation. I'm not clear on
>>why some people feel that policies need to be established. Why are
>>people so hung up on establishing policies for so many things? IMO,
>>rules for rules sake is just silly. I think we need to test the waters
>>with some code donations before we go so far as to establish policies
>>and precedents. Let's please crawl before we walk.
>>
>>Bruce
>>--
>>perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>>);'
>>
>>The Castor Project
>>http://www.castor.org/
>>
>>Apache Geronimo
>>http://geronimo.apache.org/
>>
>
>
>
Is it a mountain? (Re: Donation of Admin Console- request for help)
Posted by Davanum Srinivas <da...@gmail.com>.
+1 to accept both the console and trifork code. Let Geir worry about
paperwork. (Ask for a software grant from both companies such that we
can place the code in our SVN.)
+1 to accept new folks from these contrib as "regular" committers (we
can have a public vote once we get list of people from these 2
companies)
Why is this so difficult?
-- dims
On 7/12/05, Bruce Snyder <br...@gmail.com> wrote:
> After rereading this entire discussion, I'm still not sure that we've
> provided the requested guidance to the original reqeust that started
> this thread. What's more, given the debate that has taken place, I'm
> not sure that there's a consensus in any one direction. So I've got a
> couple of questions:
>
> 1) Is this the same management console that I downloaded from Gluecode
> as the Joe evaluation licensed product?
>
> 2) Will the management console come straight to Geronimo or go through
> the Incubator?
>
> One additional suggestion on the table seemed to surround the
> establishment of policies surrounding code donation. I'm not clear on
> why some people feel that policies need to be established. Why are
> people so hung up on establishing policies for so many things? IMO,
> rules for rules sake is just silly. I think we need to test the waters
> with some code donations before we go so far as to establish policies
> and precedents. Let's please crawl before we walk.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> The Castor Project
> http://www.castor.org/
>
> Apache Geronimo
> http://geronimo.apache.org/
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: Donation of Admin Console- request for help
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Sorry - to take a stab at your original question, it is
essentially the same console you downloaded from Gluecode (I assume there
must have been changes to update it to the current Geronimo, though
perhaps that has not been done yet). As for straight to Geronimo or
through the incubator, that is one of the issues. Finally, I don't know
who or how many committers, but I've heard there are some. :)
Aaron
On Thu, 14 Jul 2005, Bruce Snyder wrote:
> On 7/12/05, Bruce Snyder <br...@gmail.com> wrote:
> > After rereading this entire discussion, I'm still not sure that we've
> > provided the requested guidance to the original reqeust that started
> > this thread. What's more, given the debate that has taken place, I'm
> > not sure that there's a consensus in any one direction. So I've got a
> > couple of questions:
> >
> > 1) Is this the same management console that I downloaded from Gluecode
> > as the Joe evaluation licensed product?
> >
> > 2) Will the management console come straight to Geronimo or go through
> > the Incubator?
> >
> > One additional suggestion on the table seemed to surround the
> > establishment of policies surrounding code donation. I'm not clear on
> > why some people feel that policies need to be established. Why are
> > people so hung up on establishing policies for so many things? IMO,
> > rules for rules sake is just silly. I think we need to test the waters
> > with some code donations before we go so far as to establish policies
> > and precedents. Let's please crawl before we walk.
>
> Being that I haven't gotten any answers to my questions above, I
> figured I'd pose another one:
>
> What committers and how many of them will come with this code?
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> The Castor Project
> http://www.castor.org/
>
> Apache Geronimo
> http://geronimo.apache.org/
>
Re: Donation of Admin Console- request for help
Posted by Bruce Snyder <br...@gmail.com>.
On 7/12/05, Bruce Snyder <br...@gmail.com> wrote:
> After rereading this entire discussion, I'm still not sure that we've
> provided the requested guidance to the original reqeust that started
> this thread. What's more, given the debate that has taken place, I'm
> not sure that there's a consensus in any one direction. So I've got a
> couple of questions:
>
> 1) Is this the same management console that I downloaded from Gluecode
> as the Joe evaluation licensed product?
>
> 2) Will the management console come straight to Geronimo or go through
> the Incubator?
>
> One additional suggestion on the table seemed to surround the
> establishment of policies surrounding code donation. I'm not clear on
> why some people feel that policies need to be established. Why are
> people so hung up on establishing policies for so many things? IMO,
> rules for rules sake is just silly. I think we need to test the waters
> with some code donations before we go so far as to establish policies
> and precedents. Let's please crawl before we walk.
Being that I haven't gotten any answers to my questions above, I
figured I'd pose another one:
What committers and how many of them will come with this code?
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: Donation of Admin Console- request for help
Posted by Bruce Snyder <br...@gmail.com>.
After rereading this entire discussion, I'm still not sure that we've
provided the requested guidance to the original reqeust that started
this thread. What's more, given the debate that has taken place, I'm
not sure that there's a consensus in any one direction. So I've got a
couple of questions:
1) Is this the same management console that I downloaded from Gluecode
as the Joe evaluation licensed product?
2) Will the management console come straight to Geronimo or go through
the Incubator?
One additional suggestion on the table seemed to surround the
establishment of policies surrounding code donation. I'm not clear on
why some people feel that policies need to be established. Why are
people so hung up on establishing policies for so many things? IMO,
rules for rules sake is just silly. I think we need to test the waters
with some code donations before we go so far as to establish policies
and precedents. Let's please crawl before we walk.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: Donation of Admin Console- request for help
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 9:12 PM, Dain Sundstrom wrote:
> On Jul 11, 2005, at 5:44 PM, Geir Magnusson Jr. wrote:
>
>
>> Yep. I never said that you can't, so please don't suggest I was
>> saying that.
>>
>> But it was my impression that both TriFork people and Geronimo
>> people, including you, were interested in the code coming into a
>> SVN repository under the supervision of the Geronimo PMV, with all
>> those people working in that SVN
>>
>
> Ah so we have a misunderstanding in two directions. I am
> interested in the concept of what you have written, but think the
> code should go to incubator and worked on in incubator. I think
> Geronimo should stick to one ACL and just have new code we want
> people to be able to work on directly while being integrated to go
> into incubator.
>
Ah. My mistake then. I was certain that you wished for something
else for TriFork. My apologies.
>
>>> I guess you're not going to be happy. I think that we have
>>> different situations here. My guess is every donation will be a
>>> unique situation. We need to measure the situation and act
>>> accordingly.
>>>
>>
>> I don't agree. I think that having a simple set of rules is
>> needed for transparency and fairness. Of course, exceptions can
>> be made, but that should be to a well-understood and supported
>> policy.
>>
>
> To use Aarons word, I'm ok with "guidelines" or rules of thumbs,
> but we measure each situation as a unique instance. Since, all
> these discussions happen in the public and all are welcome to join
> in, I don't think we will have a problem with a perception of
> unfairness or the stink of a smoke filled room. I think rules and
> precedents in this case can be very dangerous as the a large
> donation can change everything overnight. If we were to accept the
> wrong donation by just following the rules and precedents, it could
> burn the good will that keeps this collaboration project together.
I don't think we have that risk here.
>
>
>>> I hope no one would do that. That would be incredible damaging
>>> to our community. How would you feel if Trifork donated their
>>> web-service implementation? We could suck it into Geronimo and
>>> get everyone using it. Of course that would really hurt Axis.
>>>
>>> I think we avoid any situation that would undermine an existing
>>> healthy open source community. If someone wants to donate
>>> something to compete against an existing healthy Apache licensed
>>> open source community, we can simply suggest they work with the
>>> existing community or start a new one.
>>>
>>>
>>
>> I agree. We should always encourage that. But sometimes
>> competition is good :
>>
>
> Not all competition is good. If we were to accept an webservice
> implementation into Geronimo it would give it an unfair advantage.
> We could permanently damage or kill an otherwise healthy project.
> And why? So we can have our own X?
I think it depends on the situation, right? You can have
implementations of the same technology that are tailored for
different needs.
>
> If the competing implementation is superior, then it should have no
> problem competing without the Apache or Geronimo brands.
>
>
>>>>> The ORB supports a large specification without a (healthy)
>>>>> existing Apache licensed open source version. If there were an
>>>>> existing apache licensed open source ORB, I would rather see
>>>>> the code donated and worked into an exiting project.
>>>>> Alternatively, the group donating the code could start a new
>>>>> project outside Apache, and develop a healthy community of it's
>>>>> own. I do not think that Geronimo should ever assist in
>>>>> undermining an existing (healthy) open source project.
>>>>>
>>>>
>>>> That's fine, but I don't think the donators wish to go this way
>>>> at first, and I think that we're happy to accommodate them.
>>>>
>>>
>>> What? That was a hypothetical situation. I wrote "If there
>>> were an existing apache licensed open source ORB", but as I see
>>> it there is not one, so we should a new project and community here.
>>>
>>
>> No. The CORBA donation is not hypothetical, and intended to come
>> to the Geronimo project. For what reason do you wish to make them
>> go to the incubator?
>>
>
> Holy cow! Please read my email before responding next time. My
> "note" was about a hypothetical situation, which isn't true in this
> case. I was not attempting to link that "note" to a discussion
> about incubator at all. Man!
I see. In the case of the CORBA donation, I thought that there was
general consensus to bring here and get started, and let natural flow
of the project determine if it should be a new project and all...
>
> Obviously you want me to now write something about the incubator,
> so I will...
>
> What is wrong with the incubator?
Nothing.
> You are acting like we banished them to the underworld to prove
> themselves in fiery combat. Maybe I'm wrong, but I blieve that
> this situation is exactly what incubator was designed for. We have
> a large new code base and new committers for it. We can work with
> them and the code in a safe helpful environment while they become
> accustomed to the project and we become accustomed with them. What
> is the big deal?
For what reason do you wish to make them go to incubator? I think
that Geronimo is a safe, helpful environment where they can become
accustomed to the project and we to them. That said, I'm happy to
see them go to incubator and will help there if that's what they
want. But what is different when it comes to Geronimo, right?
My POV is that the incubator serves two purposes - first to ensure
that any code contribution is properly handled, with proper oversight
of the acceptance process. (IOW, the proper software grant is
received from the copyright owner to ensure that the code is being
offered to the ASF by the copyright holder and not someone else.)
The second is, in the event that a community needs to be built around
code that is standalone, that it is done. In our case, it's my
understanding that the intent was to *not* build a standalone project
and community, but start by integrating tightly in Geronimo.
I think that's the key question to be answered. Based on that, it
should go to the proper place.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Donation of Admin Console- request for help
Posted by Dain Sundstrom <da...@iq80.com>.
On Jul 11, 2005, at 5:44 PM, Geir Magnusson Jr. wrote:
> Yep. I never said that you can't, so please don't suggest I was
> saying that.
>
> But it was my impression that both TriFork people and Geronimo
> people, including you, were interested in the code coming into a
> SVN repository under the supervision of the Geronimo PMV, with all
> those people working in that SVN
Ah so we have a misunderstanding in two directions. I am interested
in the concept of what you have written, but think the code should go
to incubator and worked on in incubator. I think Geronimo should
stick to one ACL and just have new code we want people to be able to
work on directly while being integrated to go into incubator.
>> I guess you're not going to be happy. I think that we have
>> different situations here. My guess is every donation will be a
>> unique situation. We need to measure the situation and act
>> accordingly.
>
> I don't agree. I think that having a simple set of rules is needed
> for transparency and fairness. Of course, exceptions can be made,
> but that should be to a well-understood and supported policy.
To use Aarons word, I'm ok with "guidelines" or rules of thumbs, but
we measure each situation as a unique instance. Since, all these
discussions happen in the public and all are welcome to join in, I
don't think we will have a problem with a perception of unfairness or
the stink of a smoke filled room. I think rules and precedents in
this case can be very dangerous as the a large donation can change
everything overnight. If we were to accept the wrong donation by
just following the rules and precedents, it could burn the good will
that keeps this collaboration project together.
>> I hope no one would do that. That would be incredible damaging to
>> our community. How would you feel if Trifork donated their web-
>> service implementation? We could suck it into Geronimo and get
>> everyone using it. Of course that would really hurt Axis.
>>
>> I think we avoid any situation that would undermine an existing
>> healthy open source community. If someone wants to donate
>> something to compete against an existing healthy Apache licensed
>> open source community, we can simply suggest they work with the
>> existing community or start a new one.
>>
>
> I agree. We should always encourage that. But sometimes
> competition is good :
Not all competition is good. If we were to accept an webservice
implementation into Geronimo it would give it an unfair advantage.
We could permanently damage or kill an otherwise healthy project.
And why? So we can have our own X?
If the competing implementation is superior, then it should have no
problem competing without the Apache or Geronimo brands.
>>>> The ORB supports a large specification without a (healthy)
>>>> existing Apache licensed open source version. If there were an
>>>> existing apache licensed open source ORB, I would rather see the
>>>> code donated and worked into an exiting project. Alternatively,
>>>> the group donating the code could start a new project outside
>>>> Apache, and develop a healthy community of it's own. I do not
>>>> think that Geronimo should ever assist in undermining an
>>>> existing (healthy) open source project.
>>>
>>> That's fine, but I don't think the donators wish to go this way
>>> at first, and I think that we're happy to accommodate them.
>>
>> What? That was a hypothetical situation. I wrote "If there were
>> an existing apache licensed open source ORB", but as I see it
>> there is not one, so we should a new project and community here.
>
> No. The CORBA donation is not hypothetical, and intended to come
> to the Geronimo project. For what reason do you wish to make them
> go to the incubator?
Holy cow! Please read my email before responding next time. My
"note" was about a hypothetical situation, which isn't true in this
case. I was not attempting to link that "note" to a discussion about
incubator at all. Man!
Obviously you want me to now write something about the incubator, so
I will...
What is wrong with the incubator? You are acting like we banished
them to the underworld to prove themselves in fiery combat. Maybe
I'm wrong, but I blieve that this situation is exactly what incubator
was designed for. We have a large new code base and new committers
for it. We can work with them and the code in a safe helpful
environment while they become accustomed to the project and we become
accustomed with them. What is the big deal?
-dain
Re: Donation of Admin Console- request for help
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 8:13 PM, Dain Sundstrom wrote:
> On Jul 11, 2005, at 3:52 PM, Geir Magnusson Jr. wrote:
>
>
>> On Jul 11, 2005, at 2:56 PM, Dain Sundstrom wrote:
>>
>>
>>> The console is neither. Since these are very different code
>>> bases, I think they need to be addressed differently:
>>>
>>> Console:
>>> We bring the code directly into the geronimo/trunk/sandbox. We
>>> work on the code there, and any people that worked on the code
>>> before the donation, contribute via patches. Once the code is
>>> ready, we move the code to /geronimo/trunk/applications.
>>>
>>> ORB:
>>> We bring the code and programmers into the Apache Incubator as a
>>> subproject supported by and destined for Geronimo. We develop
>>> the initial code an community in incubator, and then bring it
>>> into the Geronimo project with a separate SVN location. Once the
>>> project develops a good community of it's own we move the project
>>> to a top level project (this could take several years).
>>>
>>
>> These two solutions are not in conflict.
>>
>
> I hope I didn't implied they were. I am simply trying to say that
> they are totally separate situations.
Yes :
a) Code comes to Geronimo SVN, people working on that code that are
not Geronimo committers contribute patches and participate in the
community in a way we pre-define as our process.
b) Code goes to incubator. We participate there.
>
>
>> The problem is that IIRC, the consensus for the ORB wasn't to do
>> it in incubator, but bring the TriFork code and people here and
>> close and involved directly in what we are doing.
>>
>
> Ah... what? Just because the code lives in incubator doesn't mean
> that we can't work closely with the trifork guys. I think it is
> clear that everyone wants to work with the trifork team closely.
Yep. I never said that you can't, so please don't suggest I was
saying that.
But it was my impression that both TriFork people and Geronimo
people, including you, were interested in the code coming into a SVN
repository under the supervision of the Geronimo PMV, with all those
people working in that SVN.
>
>
>> I have no problem with what you say above, but we should treat all
>> contributions the same way, and a contribution from the Incubator
>> is the same as from outside, is it not? Whatever process we
>> require of individuals to get commit status is the same?
>>
>> I'm actually happy if your answers are "no" and "no" as long as we
>> clearly define our process.
>>
>
> I guess you're not going to be happy. I think that we have
> different situations here. My guess is every donation will be a
> unique situation. We need to measure the situation and act
> accordingly.
>
I don't agree. I think that having a simple set of rules is needed
for transparency and fairness. Of course, exceptions can be made,
but that should be to a well-understood and supported policy.
>
>>> Note: I perceive both of these code bases as special cases and
>>> not precedents. The console is specific to Geronimo and really
>>> doesn't work without it, so it belongs in Geronimo.
>>>
>>
>> Well, these are precedents to see how we bring code in (as more
>> will be coming and yes, some of it will be very specific to
>> Geronimo). Hypothetically, if TriFork offered their EJB
>> container, then it - how OpenEJB works notwithstanding - is not a
>> standalone project because the EJB spec can't be implemented
>> legally outside of the full container, is therefore Geronimo
>> specific, and belongs in Geronimo.
>>
>
> I hope no one would do that. That would be incredible damaging to
> our community. How would you feel if Trifork donated their web-
> service implementation? We could suck it into Geronimo and get
> everyone using it. Of course that would really hurt Axis.
>
> I think we avoid any situation that would undermine an existing
> healthy open source community. If someone wants to donate
> something to compete against an existing healthy Apache licensed
> open source community, we can simply suggest they work with the
> existing community or start a new one.
I agree. We should always encourage that. But sometimes competition
is good :)
>
>
>>> The ORB supports a large specification without a (healthy)
>>> existing Apache licensed open source version. If there were an
>>> existing apache licensed open source ORB, I would rather see the
>>> code donated and worked into an exiting project. Alternatively,
>>> the group donating the code could start a new project outside
>>> Apache, and develop a healthy community of it's own. I do not
>>> think that Geronimo should ever assist in undermining an existing
>>> (healthy) open source project.
>>>
>>>
>>
>> That's fine, but I don't think the donators wish to go this way at
>> first, and I think that we're happy to accommodate them.
>>
>
> What? That was a hypothetical situation. I wrote "If there were
> an existing apache licensed open source ORB", but as I see it there
> is not one, so we should a new project and community here.
>
No. The CORBA donation is not hypothetical, and intended to come to
the Geronimo project. For what reason do you wish to make them go to
the incubator?
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Donation of Admin Console- request for help
Posted by Dain Sundstrom <da...@iq80.com>.
On Jul 11, 2005, at 3:52 PM, Geir Magnusson Jr. wrote:
> On Jul 11, 2005, at 2:56 PM, Dain Sundstrom wrote:
>
>> The console is neither. Since these are very different code
>> bases, I think they need to be addressed differently:
>>
>> Console:
>> We bring the code directly into the geronimo/trunk/sandbox. We
>> work on the code there, and any people that worked on the code
>> before the donation, contribute via patches. Once the code is
>> ready, we move the code to /geronimo/trunk/applications.
>>
>> ORB:
>> We bring the code and programmers into the Apache Incubator as a
>> subproject supported by and destined for Geronimo. We develop the
>> initial code an community in incubator, and then bring it into the
>> Geronimo project with a separate SVN location. Once the project
>> develops a good community of it's own we move the project to a top
>> level project (this could take several years).
>
> These two solutions are not in conflict.
I hope I didn't implied they were. I am simply trying to say that
they are totally separate situations.
> The problem is that IIRC, the consensus for the ORB wasn't to do it
> in incubator, but bring the TriFork code and people here and close
> and involved directly in what we are doing.
Ah... what? Just because the code lives in incubator doesn't mean
that we can't work closely with the trifork guys. I think it is
clear that everyone wants to work with the trifork team closely.
> I have no problem with what you say above, but we should treat all
> contributions the same way, and a contribution from the Incubator
> is the same as from outside, is it not? Whatever process we
> require of individuals to get commit status is the same?
>
> I'm actually happy if your answers are "no" and "no" as long as we
> clearly define our process.
I guess you're not going to be happy. I think that we have different
situations here. My guess is every donation will be a unique
situation. We need to measure the situation and act accordingly.
>> Note: I perceive both of these code bases as special cases and
>> not precedents. The console is specific to Geronimo and really
>> doesn't work without it, so it belongs in Geronimo.
>
> Well, these are precedents to see how we bring code in (as more
> will be coming and yes, some of it will be very specific to
> Geronimo). Hypothetically, if TriFork offered their EJB container,
> then it - how OpenEJB works notwithstanding - is not a standalone
> project because the EJB spec can't be implemented legally outside
> of the full container, is therefore Geronimo specific, and belongs
> in Geronimo.
I hope no one would do that. That would be incredible damaging to
our community. How would you feel if Trifork donated their web-
service implementation? We could suck it into Geronimo and get
everyone using it. Of course that would really hurt Axis.
I think we avoid any situation that would undermine an existing
healthy open source community. If someone wants to donate something
to compete against an existing healthy Apache licensed open source
community, we can simply suggest they work with the existing
community or start a new one.
>> The ORB supports a large specification without a (healthy)
>> existing Apache licensed open source version. If there were an
>> existing apache licensed open source ORB, I would rather see the
>> code donated and worked into an exiting project. Alternatively,
>> the group donating the code could start a new project outside
>> Apache, and develop a healthy community of it's own. I do not
>> think that Geronimo should ever assist in undermining an existing
>> (healthy) open source project.
>>
>
> That's fine, but I don't think the donators wish to go this way at
> first, and I think that we're happy to accommodate them.
What? That was a hypothetical situation. I wrote "If there were an
existing apache licensed open source ORB", but as I see it there is
not one, so we should a new project and community here.
-dain
Re: Donation of Admin Console- request for help
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 2:56 PM, Dain Sundstrom wrote:
> Let me clarify. I think we have two very different code bases
> here. The ORB is top-levelable and console is not.
This is true.
> By top-levelable I mean that it is a big standalone code base and
> can reasonably become a standalone project. This is also supported
> by the fact that most ORB projects in open source are standalone
> projects and there are many commercial standalone ORBs.
Yes, and right now, I thought the consensus of us *and* TriFork was
that it *wasn't* to be a standalone subproject or a top-level-
project, but rather brought close and part of Geronimo for now.
Being standalone or TLP is something that can be looked at later as
we learn more and see how the community and code evolves.
> The console is neither. Since these are very different code
> bases, I think they need to be addressed differently:
>
> Console:
> We bring the code directly into the geronimo/trunk/sandbox. We
> work on the code there, and any people that worked on the code
> before the donation, contribute via patches. Once the code is
> ready, we move the code to /geronimo/trunk/applications.
>
> ORB:
> We bring the code and programmers into the Apache Incubator as a
> subproject supported by and destined for Geronimo. We develop the
> initial code an community in incubator, and then bring it into the
> Geronimo project with a separate SVN location. Once the project
> develops a good community of it's own we move the project to a top
> level project (this could take several years).
These two solutions are not in conflict.
The problem is that IIRC, the consensus for the ORB wasn't to do it
in incubator, but bring the TriFork code and people here and close
and involved directly in what we are doing.
I have no problem with what you say above, but we should treat all
contributions the same way, and a contribution from the Incubator is
the same as from outside, is it not? Whatever process we require of
individuals to get commit status is the same?
I'm actually happy if your answers are "no" and "no" as long as we
clearly define our process.
>
> Note: I perceive both of these code bases as special cases and not
> precedents. The console is specific to Geronimo and really doesn't
> work without it, so it belongs in Geronimo.
Well, these are precedents to see how we bring code in (as more will
be coming and yes, some of it will be very specific to Geronimo).
Hypothetically, if TriFork offered their EJB container, then it - how
OpenEJB works notwithstanding - is not a standalone project because
the EJB spec can't be implemented legally outside of the full
container, is therefore Geronimo specific, and belongs in Geronimo.
> The ORB supports a large specification without a (healthy) existing
> Apache licensed open source version. If there were an existing
> apache licensed open source ORB, I would rather see the code
> donated and worked into an exiting project. Alternatively, the
> group donating the code could start a new project outside Apache,
> and develop a healthy community of it's own. I do not think that
> Geronimo should ever assist in undermining an existing (healthy)
> open source project.
That's fine, but I don't think the donators wish to go this way at
first, and I think that we're happy to accommodate them.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Donation of Admin Console- request for help
Posted by Dain Sundstrom <da...@iq80.com>.
Let me clarify. I think we have two very different code bases here.
The ORB is top-levelable and console is not. By top-levelable I mean
that it is a big standalone code base and can reasonably become a
standalone project. This is also supported by the fact that most ORB
projects in open source are standalone projects and there are many
commercial standalone ORBs. The console is neither. Since these are
very different code bases, I think they need to be addressed
differently:
Console:
We bring the code directly into the geronimo/trunk/sandbox. We work
on the code there, and any people that worked on the code before the
donation, contribute via patches. Once the code is ready, we move
the code to /geronimo/trunk/applications.
ORB:
We bring the code and programmers into the Apache Incubator as a
subproject supported by and destined for Geronimo. We develop the
initial code an community in incubator, and then bring it into the
Geronimo project with a separate SVN location. Once the project
develops a good community of it's own we move the project to a top
level project (this could take several years).
Note: I perceive both of these code bases as special cases and not
precedents. The console is specific to Geronimo and really doesn't
work without it, so it belongs in Geronimo. The ORB supports a large
specification without a (healthy) existing Apache licensed open
source version. If there were an existing apache licensed open
source ORB, I would rather see the code donated and worked into an
exiting project. Alternatively, the group donating the code could
start a new project outside Apache, and develop a healthy community
of it's own. I do not think that Geronimo should ever assist in
undermining an existing (healthy) open source project.
-dain
On Jul 11, 2005, at 11:01 AM, Aaron Mulder wrote:
> On Mon, 11 Jul 2005, Dain Sundstrom wrote:
>
>> Note I wrote "I believe". Based on conversations I've had and from
>> what I have seen on this list, *I believe* that this code will
>> ultimately end up in a subproject.
>>
>
> I guess I'm still not clear on "subproject". You mean like with
> its own home page at "http://corba.geronimo.apache.org/" and
> separate JIRA
> and all? Or it uses all the same infrastructure as Geronimo but has a
> separate /trunk somewhere in SVN?
>
>
>> What are you talking about? We are in a thread to discuss the
>> specific donation of the IBM console, not a thread to decide a policy
>> on general code donation and committers. If you would like to
>> discuss those, please start a new thread and address it directly.
>>
>
> For my part, I'm just as happy to try to set a precendent and
> handle the TriFork and IBM donations the same way to start with --
> in a
> separate SVN area in within the Geronimo SVN repo, either each with
> own
> ACL or sharing the Geronimo ACL and contributor employees
> contribute via
> patches. Whether they go on to become "subprojects" or "modules" or
> whatever can be decided later, right?
>
> Aaron
>
Re: Donation of Admin Console- request for help
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 2:01 PM, Aaron Mulder wrote:
> On Mon, 11 Jul 2005, Dain Sundstrom wrote:
>
>> Note I wrote "I believe". Based on conversations I've had and from
>> what I have seen on this list, *I believe* that this code will
>> ultimately end up in a subproject.
>>
>
> I guess I'm still not clear on "subproject". You mean like with
> its own home page at "http://corba.geronimo.apache.org/" and
> separate JIRA
> and all? Or it uses all the same infrastructure as Geronimo but has a
> separate /trunk somewhere in SVN?
No - at best it would be
http://geronimo.apache.org/corba
(or whatever)
IMO, it would be the same infra as geronimo, with the same set of
committers [eventually], sharing the same dev list (until volume
dictates otherwise), with an independent release cycle, that is a
responsibility of the Geronimo PMC.
>
>
>> What are you talking about? We are in a thread to discuss the
>> specific donation of the IBM console, not a thread to decide a policy
>> on general code donation and committers. If you would like to
>> discuss those, please start a new thread and address it directly.
>>
>
> For my part, I'm just as happy to try to set a precendent and
> handle the TriFork and IBM donations the same way to start with --
> in a
> separate SVN area in within the Geronimo SVN repo, either each with
> own
> ACL or sharing the Geronimo ACL and contributor employees
> contribute via
> patches. Whether they go on to become "subprojects" or "modules" or
> whatever can be decided later, right?
>
I believe so.
geir
> Aaron
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Donation of Admin Console- request for help
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Mon, 11 Jul 2005, Dain Sundstrom wrote:
> Note I wrote "I believe". Based on conversations I've had and from
> what I have seen on this list, *I believe* that this code will
> ultimately end up in a subproject.
I guess I'm still not clear on "subproject". You mean like with
its own home page at "http://corba.geronimo.apache.org/" and separate JIRA
and all? Or it uses all the same infrastructure as Geronimo but has a
separate /trunk somewhere in SVN?
> What are you talking about? We are in a thread to discuss the
> specific donation of the IBM console, not a thread to decide a policy
> on general code donation and committers. If you would like to
> discuss those, please start a new thread and address it directly.
For my part, I'm just as happy to try to set a precendent and
handle the TriFork and IBM donations the same way to start with -- in a
separate SVN area in within the Geronimo SVN repo, either each with own
ACL or sharing the Geronimo ACL and contributor employees contribute via
patches. Whether they go on to become "subprojects" or "modules" or
whatever can be decided later, right?
Aaron
Re: Donation of Admin Console- request for help
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 1:43 PM, Dain Sundstrom wrote:
> On Jul 11, 2005, at 10:30 AM, Geir Magnusson Jr. wrote:
>
>
>>> I think you have mixed several separate issues together here.
>>> SoC is a different issue we have discussed before. I believe
>>> that the community wants the Trifork donation to be a subproject,
>>> so will enter via the incubator. The IBM donation falls into a
>>> separate category.
>>>
>>>
>>
>> No, it's not clear to me what the "community" wants re TriFork.
>> It was my understanding that the code would come here along with
>> some people to work on it to get things going as fast as possible.
>>
>
> Note I wrote "I believe". Based on conversations I've had and from
> what I have seen on this list, *I believe* that this code will
> ultimately end up in a subproject.
I believed from our call that irrespective of subprojectness, they
would be coming here directly, and you agreed with that.
>
>
>> Lets put aside "who" for now and come up with a generally
>> acceptable policy.
>>
>
> I agree that "who" doesn't matter, but *I believe* it is a case-by-
> case basis decided based on the code base proposed for donation.
> An ORB and a web-console are vastly different beasts.
>
Yep, but we need to have a consistent policy, right?
>
>>> I suggest that IBM makes the code visible, so Aaron and other can
>>> begin to review it. If we decide that we want the code (and IBM
>>> finishes legal), we check it into /geronimo/trunk/sandbox/$
>>> {console-name-here}, work with it there until we are happy, and
>>> then move it to /geronimo/trunk/applications/${console-name-here}.
>>>
>>
>> As long as this becomes our general policy for accepting code and/
>> or new committers here, I'm fine with it.
>>
>
> What are you talking about? We are in a thread to discuss the
> specific donation of the IBM console, not a thread to decide a
> policy on general code donation and committers. If you would like
> to discuss those, please start a new thread and address it directly.
Well, have you read the whole thread? Aaron introduced the concept
of a general solution :
"I believe the question is essentially the same as the question
around the TriFork CORBA donation."
If you wish to change the subject line, lets do it if we need to...
geir
>
> -dain
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Donation of Admin Console- request for help
Posted by Dain Sundstrom <da...@iq80.com>.
On Jul 11, 2005, at 10:30 AM, Geir Magnusson Jr. wrote:
>> I think you have mixed several separate issues together here. SoC
>> is a different issue we have discussed before. I believe that the
>> community wants the Trifork donation to be a subproject, so will
>> enter via the incubator. The IBM donation falls into a separate
>> category.
>>
>
> No, it's not clear to me what the "community" wants re TriFork. It
> was my understanding that the code would come here along with some
> people to work on it to get things going as fast as possible.
Note I wrote "I believe". Based on conversations I've had and from
what I have seen on this list, *I believe* that this code will
ultimately end up in a subproject.
> Lets put aside "who" for now and come up with a generally
> acceptable policy.
I agree that "who" doesn't matter, but *I believe* it is a case-by-
case basis decided based on the code base proposed for donation. An
ORB and a web-console are vastly different beasts.
>> I suggest that IBM makes the code visible, so Aaron and other can
>> begin to review it. If we decide that we want the code (and IBM
>> finishes legal), we check it into /geronimo/trunk/sandbox/$
>> {console-name-here}, work with it there until we are happy, and
>> then move it to /geronimo/trunk/applications/${console-name-here}.
>
> As long as this becomes our general policy for accepting code and/
> or new committers here, I'm fine with it.
What are you talking about? We are in a thread to discuss the
specific donation of the IBM console, not a thread to decide a policy
on general code donation and committers. If you would like to
discuss those, please start a new thread and address it directly.
-dain
Re: Donation of Admin Console- request for help
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 11:51 AM, Dain Sundstrom wrote:
> On Jul 11, 2005, at 8:19 AM, Geir Magnusson Jr. wrote:
>
>
>> On Jul 11, 2005, at 11:03 AM, Aaron Mulder wrote:
>>
>> Fine : I'm going to suggest
>>
>> /geronimo/sandbox/misc/SoC
>> /geronimo/sandbox/donations/trifork
>> /geronimo/sandbox/donations/ibm
>> ...
>>
>
> I think you have mixed several separate issues together here. SoC
> is a different issue we have discussed before. I believe that the
> community wants the Trifork donation to be a subproject, so will
> enter via the incubator. The IBM donation falls into a separate
> category.
No, it's not clear to me what the "community" wants re TriFork. It
was my understanding that the code would come here along with some
people to work on it to get things going as fast as possible.
Lets put aside "who" for now and come up with a generally acceptable
policy.
(BTW : All code donations are technically made through the incubator
- both the TriFork code as well as IBM code will have to complete
paperwork there...)
>
> I suggest that IBM makes the code visible, so Aaron and other can
> begin to review it. If we decide that we want the code (and IBM
> finishes legal), we check it into /geronimo/trunk/sandbox/${console-
> name-here}, work with it there until we are happy, and then move it
> to /geronimo/trunk/applications/${console-name-here}.
As long as this becomes our general policy for accepting code and/or
new committers here, I'm fine with it.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Donation of Admin Console- request for help
Posted by Dain Sundstrom <da...@iq80.com>.
On Jul 11, 2005, at 8:19 AM, Geir Magnusson Jr. wrote:
> On Jul 11, 2005, at 11:03 AM, Aaron Mulder wrote:
>
> Fine : I'm going to suggest
>
> /geronimo/sandbox/misc/SoC
> /geronimo/sandbox/donations/trifork
> /geronimo/sandbox/donations/ibm
> ...
I think you have mixed several separate issues together here. SoC is
a different issue we have discussed before. I believe that the
community wants the Trifork donation to be a subproject, so will
enter via the incubator. The IBM donation falls into a separate
category.
I suggest that IBM makes the code visible, so Aaron and other can
begin to review it. If we decide that we want the code (and IBM
finishes legal), we check it into /geronimo/trunk/sandbox/${console-
name-here}, work with it there until we are happy, and then move it
to /geronimo/trunk/applications/${console-name-here}.
-dain
Re: Donation of Admin Console- request for help
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 11:03 AM, Aaron Mulder wrote:
>> 1) We must decide on where we bring the software and how we handle
>> interested contributors :
>>
>> a) Bring to Apache Geronimo SVN (w/ or w/o separate ACL) and
>>
>> i) Grant committer status to any offered individuals that wish
>> to continue working on the respective contribution
>> ii) Ask that work continues via submitted patches for some
>> period of time
>>
>> b) Bring to the Apache Incubator and work with the code and people
>> there
>>
>
> I would like to look at the code before deciding whether and how
> to incorporate either of these donations into Geronimo "for real".
Of course - we can always make that decision at any point. For now,
I was suggesting that we vote to accept the code into our repo - a
sandbox if here at Geronimo - or sponsorship if at Incubator.
> But my
> preference on the implementation of that would be to set up some
> temporary
> space in the project SVN, put the code there, let people fuss with
> it, and
> then (if all goes well) when it's massaged into shape vote to fold
> it into
> the SVN tree proper (though I'm not yet sure whether it should be
> part of
> the current "geronimo" tree or in a "related projects" / "sub project"
> area -- that probably depends to some extent on the code and how
> entangled it is).
Yep - I would suggest then we keep it simple and have
/geronimmo/sandbox
as a peer to /trunk
and accept the code into there if we bring to Geronimo.
>
> So, in order to move forward, I would prefer:
>
> - set up a separate area of SVN for donations (currently 2 on the
> table)
Fine : I'm going to suggest
/geronimo/sandbox/misc/SoC
/geronimo/sandbox/donations/trifork
/geronimo/sandbox/donations/ibm
...
as our pattern
> - pick one of:
> - add separate ACL for each donation in there
> - have people from contributing company operate via patches
>
> I would personally lean slightly toward patches, though I
> anticipate the donators may prefer ACLs. In any case, if and when the
> code becomes part of Geronimo proper, I think the donators will
> need to
> qualify for Geronimo commit status as normal.
Right, and that's up to us. "Qualify" is currently subjective.
I'd be happy w/ separate ACLs to let people work as fast and
"normally" as possible, w/o having to wait for patches to be
accepted. There's no danger with SVN. That said, I'd go w/ patches
if that was the consensus.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Donation of Admin Console- request for help
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
> 1) We must decide on where we bring the software and how we handle
> interested contributors :
>
> a) Bring to Apache Geronimo SVN (w/ or w/o separate ACL) and
>
> i) Grant committer status to any offered individuals that wish
> to continue working on the respective contribution
> ii) Ask that work continues via submitted patches for some
> period of time
>
> b) Bring to the Apache Incubator and work with the code and people
> there
I would like to look at the code before deciding whether and how
to incorporate either of these donations into Geronimo "for real". But my
preference on the implementation of that would be to set up some temporary
space in the project SVN, put the code there, let people fuss with it, and
then (if all goes well) when it's massaged into shape vote to fold it into
the SVN tree proper (though I'm not yet sure whether it should be part of
the current "geronimo" tree or in a "related projects" / "sub project"
area -- that probably depends to some extent on the code and how
entangled it is).
So, in order to move forward, I would prefer:
- set up a separate area of SVN for donations (currently 2 on the table)
- pick one of:
- add separate ACL for each donation in there
- have people from contributing company operate via patches
I would personally lean slightly toward patches, though I
anticipate the donators may prefer ACLs. In any case, if and when the
code becomes part of Geronimo proper, I think the donators will need to
qualify for Geronimo commit status as normal.
Thanks,
Aaron
On Mon, 11 Jul 2005, Geir Magnusson Jr. wrote:
> On Jul 11, 2005, at 10:39 AM, Aaron Mulder wrote:
>
> > I'm excited to see this.
> >
> > I believe the question is essentially the same as the question
> > around the TriFork CORBA donation. I'm not sure where that discussion
> > stands -- last time I checked in we were debating the meaning of
> > "subproject". Guess we better wrap that up!
>
> Or decide that it's irrelevant wrt the TriFork and now IBM donations,
> as it's just internal structuring of our code and release processes/
> cycles :) We can solve in parallel, because I don't see the proposed
> trifork roadmap or the IBM contribution resulting in codebases of
> independent release cycle in the near future. In each case, I think
> we all agree that we'd want to integrate into our community and
> general codebase.
>
> >
> > I know there is also a certain amount of paperwork to be filed,
> > etc. -- perhaps Geir can outline the steps there?
>
> Yes. There will be a CCLA, which has a software grant as part of it
> for IBM to make the contribution, and ICLAs for any IBM employees
> that wish to contribute (they'd need it for committership, so there's
> no harm getting it done early... as a matter of fact, we should ask
> this of any regular contributor the project)
>
> BUT FIRST...
>
> 0) We must vote to either accept or reject this contribution
>
> - we may or may not require to see the code, under a satisfactory
> license, before voting
>
>
>
> I ask that all committers discuss so we can bring to a vote for both
> the IBM contribution and the TriFork contribution.
>
> Thanks
>
> geir
>
>
> >
> > Aaron
> >
> > On Mon, 11 Jul 2005, David Klavon wrote:
> >
> >> One of the components that IBM acquired with the purchase of the
> >> Gluecode company was the portlet based administrative console. We
> >> are
> >> in the final stages of obtaining the legal clearance to donate this
> >> component to the Geronimo project and we wanted to give everyone a
> >> heads up about this offering and to solicit feedback on the best
> >> approach to bring this component into Geronimo. Can someone please
> >> provide guidance with the correct procedure to make the code
> >> available
> >> to Geronimo? We are anticipating final legal clearance for
> >> contribution this week so I wanted to provide the heads up now and
> >> make sure that all barriers to contribution were out of the way so
> >> once its cleared we can make it available as quickly as possible to
> >> the community.
> >>
> >> Thanks for your help and guidance.
> >> Dave
> >>
> >>
> >
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
Re: Donation of Admin Console- request for help
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 11, 2005, at 10:39 AM, Aaron Mulder wrote:
> I'm excited to see this.
>
> I believe the question is essentially the same as the question
> around the TriFork CORBA donation. I'm not sure where that discussion
> stands -- last time I checked in we were debating the meaning of
> "subproject". Guess we better wrap that up!
Or decide that it's irrelevant wrt the TriFork and now IBM donations,
as it's just internal structuring of our code and release processes/
cycles :) We can solve in parallel, because I don't see the proposed
trifork roadmap or the IBM contribution resulting in codebases of
independent release cycle in the near future. In each case, I think
we all agree that we'd want to integrate into our community and
general codebase.
>
> I know there is also a certain amount of paperwork to be filed,
> etc. -- perhaps Geir can outline the steps there?
Yes. There will be a CCLA, which has a software grant as part of it
for IBM to make the contribution, and ICLAs for any IBM employees
that wish to contribute (they'd need it for committership, so there's
no harm getting it done early... as a matter of fact, we should ask
this of any regular contributor the project)
BUT FIRST...
0) We must vote to either accept or reject this contribution
- we may or may not require to see the code, under a satisfactory
license, before voting
1) We must decide on where we bring the software and how we handle
interested contributors :
a) Bring to Apache Geronimo SVN (w/ or w/o separate ACL) and
i) Grant committer status to any offered individuals that wish
to continue working on the respective contribution
ii) Ask that work continues via submitted patches for some
period of time
b) Bring to the Apache Incubator and work with the code and people
there
I ask that all committers discuss so we can bring to a vote for both
the IBM contribution and the TriFork contribution.
Thanks
geir
>
> Aaron
>
> On Mon, 11 Jul 2005, David Klavon wrote:
>
>> One of the components that IBM acquired with the purchase of the
>> Gluecode company was the portlet based administrative console. We
>> are
>> in the final stages of obtaining the legal clearance to donate this
>> component to the Geronimo project and we wanted to give everyone a
>> heads up about this offering and to solicit feedback on the best
>> approach to bring this component into Geronimo. Can someone please
>> provide guidance with the correct procedure to make the code
>> available
>> to Geronimo? We are anticipating final legal clearance for
>> contribution this week so I wanted to provide the heads up now and
>> make sure that all barriers to contribution were out of the way so
>> once its cleared we can make it available as quickly as possible to
>> the community.
>>
>> Thanks for your help and guidance.
>> Dave
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Donation of Admin Console- request for help
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I'm excited to see this.
I believe the question is essentially the same as the question
around the TriFork CORBA donation. I'm not sure where that discussion
stands -- last time I checked in we were debating the meaning of
"subproject". Guess we better wrap that up!
I know there is also a certain amount of paperwork to be filed,
etc. -- perhaps Geir can outline the steps there?
Aaron
On Mon, 11 Jul 2005, David Klavon wrote:
> One of the components that IBM acquired with the purchase of the
> Gluecode company was the portlet based administrative console. We are
> in the final stages of obtaining the legal clearance to donate this
> component to the Geronimo project and we wanted to give everyone a
> heads up about this offering and to solicit feedback on the best
> approach to bring this component into Geronimo. Can someone please
> provide guidance with the correct procedure to make the code available
> to Geronimo? We are anticipating final legal clearance for
> contribution this week so I wanted to provide the heads up now and
> make sure that all barriers to contribution were out of the way so
> once its cleared we can make it available as quickly as possible to
> the community.
>
> Thanks for your help and guidance.
> Dave
>
Re: Donation of Admin Console -- Take a Deep Breath
Posted by David Blevins <da...@visi.com>.
On Mon, Jul 11, 2005 at 10:08:50PM -0400, Geir Magnusson Jr. wrote:
>
> I proposed the "Take a Deep Breath Day" idea so that we'd ensure to
> treat each other's posts in the most positive light possible, to
> prevent us from accidentally misreading intent and having the
> discussion turn acrimonious or personal. I never intended it to be a
> way to halt the flow of conversation to let people catch up, but if
> people need time, great...
Maybe we should use the FOX News slogan and call it "Fair and Balanced Day" :)
> So what do you think about these issues, David?
This is going to sound strange, but honestly, I'm thinking my opinion
isn't worth too much to me right now. At this point, I'd rather do
more listening than talking.
-David
> On Jul 11, 2005, at 9:50 PM, David Blevins wrote:
>
> >"Take a Deep Breath Day"
> >
> >I just want to point out that we're hearing from the same three people
> >over and over and we need more feedback from others, so...
> >
> >I'd like to openly ask Dain, Aaron, and Geir have a "Take a Deep
> >Breath Day" and give people some time to catch up think and post some
> >questions and a little space to get in the conversation.
> >
> >That said, we haven't heard from a lot of people and we need you to
> >stop coding for a moment, catch up, think and post some comments.
> >
> >Please do form your opinion as your opinion and post it; let's try and
> >get out of the habit of only responding to someone else's opinion.
> >
> >
> >Very respectfully,
> >David
> >
> >
> >
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
Re: Donation of Admin Console -- Take a Deep Breath
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
I proposed the "Take a Deep Breath Day" idea so that we'd ensure to
treat each other's posts in the most positive light possible, to
prevent us from accidentally misreading intent and having the
discussion turn acrimonious or personal. I never intended it to be a
way to halt the flow of conversation to let people catch up, but if
people need time, great...
So what do you think about these issues, David?
geir
On Jul 11, 2005, at 9:50 PM, David Blevins wrote:
> "Take a Deep Breath Day"
>
> I just want to point out that we're hearing from the same three people
> over and over and we need more feedback from others, so...
>
> I'd like to openly ask Dain, Aaron, and Geir have a "Take a Deep
> Breath Day" and give people some time to catch up think and post some
> questions and a little space to get in the conversation.
>
> That said, we haven't heard from a lot of people and we need you to
> stop coding for a moment, catch up, think and post some comments.
>
> Please do form your opinion as your opinion and post it; let's try and
> get out of the habit of only responding to someone else's opinion.
>
>
> Very respectfully,
> David
>
>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Donation of Admin Console -- Take a Deep Breath
Posted by David Blevins <da...@visi.com>.
"Take a Deep Breath Day"
I just want to point out that we're hearing from the same three people
over and over and we need more feedback from others, so...
I'd like to openly ask Dain, Aaron, and Geir have a "Take a Deep
Breath Day" and give people some time to catch up think and post some
questions and a little space to get in the conversation.
That said, we haven't heard from a lot of people and we need you to
stop coding for a moment, catch up, think and post some comments.
Please do form your opinion as your opinion and post it; let's try and
get out of the habit of only responding to someone else's opinion.
Very respectfully,
David