Re: [discussion] Committer Addition Process
On Sep 20, 2005, at 6:24 PM, Brett Porter wrote: On 9/21/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: 4) A committer will lose commit status after 4 months of inactivity. In order to regain commit status, that person must begin participating by offering a patch, new code, etc :) This seems too much in the long run, but I do think that it is necessary to have a low barrier to entry now, and then trimming back the committer list to active people at either some milestone point or down the track if applying for TLP is appropriate. Many projects do this. HTTPD and Jakarta both have 6 month policies, IIRC, with low barrier to re-entry. It just helps keep things neat and clean. If you intend to be adding a whole lot of new committers, there needs to be some way to continue to contribute via JIRA/ML while the account is created though, and this takes some time (unless Geir is intending to turn them all around himself immediately with his new found powers :) My powers are now mighty and vast! :) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [discussion] Committer Addition Process
On 9/21/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > 4) A committer will lose commit status after 4 months of inactivity. > In order to regain commit status, that person must begin > participating by offering a patch, new code, etc :) > This seems too much in the long run, but I do think that it is necessary to have a low barrier to entry now, and then trimming back the committer list to active people at either some milestone point or down the track if applying for TLP is appropriate. If you intend to be adding a whole lot of new committers, there needs to be some way to continue to contribute via JIRA/ML while the account is created though, and this takes some time (unless Geir is intending to turn them all around himself immediately with his new found powers :) Cheers, Brett
How to package a contribution
If you have a work that you wish to contribute to the Apache Harmony project, I suggest the following process : 1) First, be sure that the work is an original work by you, or if not, you have the right and permission to contribute the software to the Apache Harmony project. We follow the standard Apache rules regarding contributions, and ask for both an Individual Contributors License Agreement http://www.apache.org/licenses/icla.txt or http://www.apache.org/licenses/icla.pdf as well as a Software Grant and Corporate Contributor License Agreement http://www.apache.org/licenses/cla-corporate.txt in the event the contribution isn't owned by yourself. 2) In addition to the ICLA, we augment the contribution process via an Authorized Contributor Questionnaire http://incubator.apache.org/harmony/auth_cont_quest.html and for now, fax to +1 203 665 6400. The Apache Harmony PPMC will handle these. 3) Package your contribution with : a) the Apache License in a file called LICENSE in the root of the contribution directory tree b) Put the header for the Apache License in the top of each file : /** * * Copyright 2005 The Apache Software Foundation or its licensors, as applicable * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ 4) Submit the bundle to the project via a JIRA entry. Please be sure to select "contributing under the Apache License" when doing so. 5) Submit a message to the dev list describing your contribution. Comments or additions to this process welcome. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [legal] Change to Authorized Contributor Questionnaire
In the interest of full disclosure, I also removed the word "PROPOSED" at the top... The changes have been checked in and moved to staging site. You can wait until it goes to www in <4 hours, or go get from SVN yourself. geir On Sep 20, 2005, at 11:17 AM, Geir Magnusson Jr. wrote: Learn as we go. I'm making two changes to the ACQ based on getting one from David. 1) Adding a note at the top that this information is considered public information, and will be shared in the manner deemed appropriate by the Apache Harmony project. The intent is to enable anyone interested in our code to know where it came from. 2) Adding some numbers for each answer so we can easily create a simple DB The version will be v1.0 20050920 geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[legal] Change to Authorized Contributor Questionnaire
Learn as we go. I'm making two changes to the ACQ based on getting one from David. 1) Adding a note at the top that this information is considered public information, and will be shared in the manner deemed appropriate by the Apache Harmony project. The intent is to enable anyone interested in our code to know where it came from. 2) Adding some numbers for each answer so we can easily create a simple DB The version will be v1.0 20050920 geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Call for Contributions (was Re: 4 Months and...)
Of course :) I assume you are willing to continue working with it? I need to do one update to the ACQ - when that is done, please get that, fill it out, and fax to +1 203 665 6437 Then do the ICLA and fax to same number. I'll post in a separate thread how a contribution should be packaged and submitted. geir On Sep 20, 2005, at 10:39 AM, Rodrigo Kumpera wrote: I've written a pet JVM in Java, it includes a very simple JITer, no GC (but it is starting to use MMtk magic, so should be doable to use it), no self-hosting and no support for native code. The code have never left my machine but I'm willing to donate if is desirable. []'s Rodrigo On 9/20/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Sep 20, 2005, at 8:52 AM, [EMAIL PROTECTED] wrote: This is not likely to actually attract code. Opening up SVN to committership would. You've described a reverse of how most projects work if you will such that the barrier is to initial commit rather than lazy veto/etc. Most projects give committership to people that have offered code and patches, don't they? geir -Andy Geir Magnusson Jr. wrote: I'd like to restate that we are always looking for code contributions. I do know of some in preparation, but it should be clear that if you have anything to offer (hey, Dan!) please post a note to dev list to discuss. :) geir On Sep 19, 2005, at 5:35 PM, [EMAIL PROTECTED] wrote: Four months and no code. Open up the repository and let the willing start committing. The discussion has gotten so verbose that there are already people publishing edited digests. Code will reduce the discussion :-) -Andy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [discussion] Committer Addition Process
On Sep 20, 2005, at 10:25 AM, Davanum Srinivas wrote: Geir, Am looking for specific timelines and specific things an indiviual can do to make sure that they catch the eye of the PMC/PPMC for commit status. Offer a patch or contribution. That's pretty specific. For a person looking from outside, there is no info on what they should do (other than what they are doing right now) to become a committer. You are correct, and it's something I'm trying to resolve now. +1 to make a policy doc in svn. But am really interested in getting the ball rolling on voting specific people, get them commit access AND more importantly getting out of their way and let them decide/work on harmony's future. Two things - this is not just a policy doc. it's how we will behave. Second, it's not a "them", it's "us", at least for me :) geir thanks, dims On 9/20/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: I'm going to shameless steal an idea from Andy Oliver. Amended with #4 : 1) Anyone with a contribution that would belong in SVN can be considered for commit status by the PMC (PPMC while in incubation). This contribution can be anything - new code, a patch to existing code, documentation, a change to the website, testing code or other resources, etc. (Hopefully this gets people interested in harvesting good docs from the WIKI, as that's worth commit status IMO) 2) If offered commit status by the PMC and accepted by the individual, we will get an ACQ from the individual along with an ICLA if not already on file with the ASF secretary. I'd ask that individuals wait to do an ACQ until offered, as the ACQ will be evolving over time as we learn, and I'd like to ask that a new committer have the current version on file as of the date of them being added as a commmitter. 3) The individual would be given free reign in the area to which they contributed, and trusted to engage with the relevant part of the community for other areas of our codebase/resourcebase. 4) A committer will lose commit status after 4 months of inactivity. In order to regain commit status, that person must begin participating by offering a patch, new code, etc :) On Sep 20, 2005, at 10:07 AM, Geir Magnusson Jr. wrote: Adding committers to a project is a problem every project faces, and there are quite a large number of ways to do it. I've been too worried about legal issues (and they pop up often) lately, and this is a good subject for us to resolve now. We must * have a visible process to ensure fairness * a low barrier to entry to get people helping * a rigid transparent process to ensure safety of the codebase in terms of IP provenance * a cultural standard through which people work on things that they have demonstrated competence to the rest of the community. For the last point, except for keeping people away from parts of the subversion repository to which they have had prior exposure they can't get resolved, we want to have one kind of committer. However, it's clear that we all have different levels of talent in different areas of technology. So a nice way to work - I think - is that committers are added for work in a specific area on a trust basis, and if they want to work in other areas, they engage with others already working there and get informal approval to commit at will. IOW, don't just go rummaging through code in which you have no experience, but work with those that are. This is something that I've heard work well in projects like Subversion, and we're trying it in Geronimo to recognize that the barrier to entry varies by person and technology they are interested in working on. So I'd like to keep it really simple : 1) Anyone with a contribution that would belong in SVN can be considered for commit status by the PMC (PPMC while in incubation). This contribution can be anything - new code, a patch to existing code, documentation, a change to the website, testing code or other resources, etc. (Hopefully this gets people interested in harvesting good docs from the WIKI, as that's worth commit status IMO) 2) If offered commit status by the PMC and accepted by the individual, we will get an ACQ from the individual along with an ICLA if not already on file with the ASF secretary. I'd ask that individuals wait to do an ACQ until offered, as the ACQ will be evolving over time as we learn, and I'd like to ask that a new committer have the current version on file as of the date of them being added as a commmitter. 3) The individual would be given free reign in the area to which they contributed, and trusted to engage with the relevant part of the community for other areas of our codebase/resourcebase. Comments? If people agree to this, I'd like to add this to our website as part of the project policy. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Davanum
Re: Call for Contributions (was Re: 4 Months and...)
I've written a pet JVM in Java, it includes a very simple JITer, no GC (but it is starting to use MMtk magic, so should be doable to use it), no self-hosting and no support for native code. The code have never left my machine but I'm willing to donate if is desirable. []'s Rodrigo On 9/20/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > On Sep 20, 2005, at 8:52 AM, [EMAIL PROTECTED] wrote: > > > This is not likely to actually attract code. Opening up SVN to > > committership would. You've described a reverse of how most > > projects work if you will such that the barrier is to initial > > commit rather than lazy veto/etc. > > Most projects give committership to people that have offered code and > patches, don't they? > > geir > > > > > -Andy > > > > Geir Magnusson Jr. wrote: > > > >> I'd like to restate that we are always looking for code > >> contributions. I do know of some in preparation, but it should > >> be clear that if you have anything to offer (hey, Dan!) please > >> post a note to dev list to discuss. :) > >> geir > >> On Sep 19, 2005, at 5:35 PM, [EMAIL PROTECTED] wrote: > >> > >>> Four months and no code. Open up the repository and let the > >>> willing start committing. The discussion has gotten so verbose > >>> that there are already people publishing edited digests. Code > >>> will reduce the discussion :-) > >>> > >>> -Andy > >>> > >>> > >>> > > > > > > > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] > > >
Re: [discussion] Committer Addition Process
On Sep 20, 2005, at 10:16 AM, [EMAIL PROTECTED] wrote:
So I'd like to keep it really simple :
1) Anyone with a contribution that would belong in SVN can be
considered for commit status by the PMC (PPMC while in
incubation). This contribution can be anything - new code, a
patch to existing code, documentation, a change to the website,
testing code or other resources, etc. (Hopefully this gets people
interested in harvesting good docs from the WIKI, as that's worth
commit status IMO)
I'm not sure how this seeds initial committers though. Start with
this, any existing Apache committer or member who has turned in his
ACQ and requests commit access. This will at least get an initial
set of committers to the repository. Its also the "likely suspects".
We have an initial committer list that was part of the proposal, just
like every other incubator proposal.
You are a committer and a member. Can't you find a patch for David's
code? ;)
Seriously, I'm not really against this, but I don't see why we'd have
to do this because we are keeping the bar very low for everyone. If
you had commit access right now, what would you do? Could you do that
same thing and post it as a JIRA contribution, and let us turn the
crank? :)
2) If offered commit status by the PMC and accepted by the
individual, we will get an ACQ from the individual along with an
ICLA if not already on file with the ASF secretary. I'd ask
that individuals wait to do an ACQ until offered, as the ACQ will
be evolving over time as we learn, and I'd like to ask that a
new committer have the current version on file as of the date of
them being added as a commmitter.
This will probably be less of a problem when there is code.
It should have nothing to do with code. It's just that we're
evolving the ACQ...
3) The individual would be given free reign in the area to which
they contributed, and trusted to engage with the relevant part of
the community for other areas of our codebase/resourcebase.
And if they request access to another area provided they have no
issues they should be given so forthwidth. Start one UNIFIED
project not 12.
I think you misunderstand. There is only one kind of committer.
A new committer that has filled in the ACQ will have access to the
full repository in reality (modulo places the ACQ says he/she can't
go), with a simple understanding of trust (some would call a
"gentleman's agreement", but I hate that term...) to work in the area
that they got commit for. ("Bob, you did great work on the docs.
We're offering you commit. Keep up the great work on the docs, and
if you want to work elsewhere, be sure to work with other community
members first so you can get in synch with what they are doing")
This has nothing to do w/ a segmented ACL list for the SVN. I want
to avoid balkanization - except for places where we have to prohibit
people based on their ACQ. We want to make sure that our controls
over IP are defensible.
Comments? If people agree to this, I'd like to add this to our
website as part of the project policy.
If this opens the repository to code then I think its great. If
not, then I think it sucks.
Great.
-Andy
geir
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
Re: [discussion] Committer Addition Process
Geir Magnusson Jr. wrote: I'm going to shameless steal an idea from Andy Oliver. Amended with #4 : 1) Anyone with a contribution that would belong in SVN can be considered for commit status by the PMC (PPMC while in incubation). This contribution can be anything - new code, a patch to existing code, documentation, a change to the website, testing code or other resources, etc. (Hopefully this gets people interested in harvesting good docs from the WIKI, as that's worth commit status IMO) I would like to offer this: build.xml: Harmony build build.sh #!/bin/sh ant $* build.bat @echo off REM convenience bat file to build with REM ATTENTION: Set ANT_HOME to the root directory of ANT distribution setlocal PATH=%ANT_HOME%\bin;%PATH% ant %* endlocal Once given commit access I'll begin adding functionality to build java and c targets and launch make files, etc. (I'm mostly ambivilent so long as dumb people can run it and get out binaries) Qualifications: I read books on compiler theory in my spare time and get GCC to output asm to see all the cool native codes that come out (god PPC is so much cooler than Intel). I also know couple things about coding in a hot legal environment and how to be appropriately paranoid while still moving forward. 2) If offered commit status by the PMC and accepted by the individual, we will get an ACQ from the individual along with an ICLA if not already on file with the ASF secretary. I'd ask that individuals wait to do an ACQ until offered, as the ACQ will be evolving over time as we learn, and I'd like to ask that a new committer have the current version on file as of the date of them being added as a commmitter. My CLA is already on file. I'm willing to sign whatever. 3) The individual would be given free reign in the area to which they contributed, and trusted to engage with the relevant part of the community for other areas of our codebase/resourcebase. I am completely untainted because I have made a conscious effort to never read Sun's source because I always intended to do something like this. 4) A committer will lose commit status after 4 months of inactivity. In order to regain commit status, that person must begin participating by offering a patch, new code, etc :) Note that this means voting rights too. This should be automated with a demon process that runs once a month and reaps dead people No whining, you can't argue with CVS^M^M^MSVN's commit logging. -andy On Sep 20, 2005, at 10:07 AM, Geir Magnusson Jr. wrote: Adding committers to a project is a problem every project faces, and there are quite a large number of ways to do it. I've been too worried about legal issues (and they pop up often) lately, and this is a good subject for us to resolve now. We must * have a visible process to ensure fairness * a low barrier to entry to get people helping * a rigid transparent process to ensure safety of the codebase in terms of IP provenance * a cultural standard through which people work on things that they have demonstrated competence to the rest of the community. For the last point, except for keeping people away from parts of the subversion repository to which they have had prior exposure they can't get resolved, we want to have one kind of committer. However, it's clear that we all have different levels of talent in different areas of technology. So a nice way to work - I think - is that committers are added for work in a specific area on a trust basis, and if they want to work in other areas, they engage with others already working there and get informal approval to commit at will. IOW, don't just go rummaging through code in which you have no experience, but work with those that are. This is something that I've heard work well in projects like Subversion, and we're trying it in Geronimo to recognize that the barrier to entry varies by person and technology they are interested in working on. So I'd like to keep it really simple : 1) Anyone with a contribution that would belong in SVN can be considered for commit status by the PMC (PPMC while in incubation). This contribution can be anything - new code, a patch to existing code, documentation, a change to the website, testing code or other resources, etc. (Hopefully this gets people interested in harvesting good docs from the WIKI, as that's worth commit status IMO) 2) If offered commit status by the PMC and accepted by the individual, we will get an ACQ from the individual along with an ICLA if not already on file with the ASF secretary. I'd ask that individuals wait to do an ACQ until offered, as the ACQ will be evolving over time as we learn, and I'd like to ask that a new committer have the current version on file as of the date of them being added as a commmitter. 3) The individual would be given free reign in the
Re: [discussion] Committer Addition Process
Geir, Am looking for specific timelines and specific things an indiviual can do to make sure that they catch the eye of the PMC/PPMC for commit status. For a person looking from outside, there is no info on what they should do (other than what they are doing right now) to become a committer. +1 to make a policy doc in svn. But am really interested in getting the ball rolling on voting specific people, get them commit access AND more importantly getting out of their way and let them decide/work on harmony's future. thanks, dims On 9/20/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > I'm going to shameless steal an idea from Andy Oliver. Amended with > #4 : > > 1) Anyone with a contribution that would belong in SVN can be > considered for commit status by the PMC (PPMC while in incubation). > This contribution can be anything - new code, a patch to existing > code, documentation, a change to the website, testing code or other > resources, etc. (Hopefully this gets people interested in harvesting > good docs from the WIKI, as that's worth commit status IMO) > > 2) If offered commit status by the PMC and accepted by the > individual, we will get an ACQ from the individual along with an ICLA > if not already on file with the ASF secretary. I'd ask that > individuals wait to do an ACQ until offered, as the ACQ will be > evolving over time as we learn, and I'd like to ask that a new > committer have the current version on file as of the date of them > being added as a commmitter. > > 3) The individual would be given free reign in the area to which they > contributed, and trusted to engage with the relevant part of the > community for other areas of our codebase/resourcebase. > > 4) A committer will lose commit status after 4 months of inactivity. > In order to regain commit status, that person must begin > participating by offering a patch, new code, etc :) > > > > On Sep 20, 2005, at 10:07 AM, Geir Magnusson Jr. wrote: > > > Adding committers to a project is a problem every project faces, > > and there are quite a large number of ways to do it. I've been too > > worried about legal issues (and they pop up often) lately, and this > > is a good subject for us to resolve now. > > > > We must > > > > * have a visible process to ensure fairness > > * a low barrier to entry to get people helping > > * a rigid transparent process to ensure safety of the codebase in > > terms of IP provenance > > * a cultural standard through which people work on things that they > > have demonstrated competence to the rest of the community. > > > > For the last point, except for keeping people away from parts of > > the subversion repository to which they have had prior exposure > > they can't get resolved, we want to have one kind of committer. > > However, it's clear that we all have different levels of talent in > > different areas of technology. So a nice way to work - I think - > > is that committers are added for work in a specific area on a trust > > basis, and if they want to work in other areas, they engage with > > others already working there and get informal approval to commit at > > will. IOW, don't just go rummaging through code in which you have > > no experience, but work with those that are. This is something > > that I've heard work well in projects like Subversion, and we're > > trying it in Geronimo to recognize that the barrier to entry varies > > by person and technology they are interested in working on. > > > > So I'd like to keep it really simple : > > > > 1) Anyone with a contribution that would belong in SVN can be > > considered for commit status by the PMC (PPMC while in > > incubation). This contribution can be anything - new code, a patch > > to existing code, documentation, a change to the website, testing > > code or other resources, etc. (Hopefully this gets people > > interested in harvesting good docs from the WIKI, as that's worth > > commit status IMO) > > > > 2) If offered commit status by the PMC and accepted by the > > individual, we will get an ACQ from the individual along with an > > ICLA if not already on file with the ASF secretary. I'd ask that > > individuals wait to do an ACQ until offered, as the ACQ will be > > evolving over time as we learn, and I'd like to ask that a new > > committer have the current version on file as of the date of them > > being added as a commmitter. > > > > 3) The individual would be given free reign in the area to which > > they contributed, and trusted to engage with the relevant part of > > the community for other areas of our codebase/resourcebase. > > > > Comments? If people agree to this, I'd like to add this to our > > website as part of the project policy. > > > > geir > > > > -- > > Geir Magnusson Jr +1-203-665-6437 > > [EMAIL PROTECTED] > > > > > > > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] > > > -- Davanum Srinivas : http://wso2.com/
Re: [discussion] Committer Addition Process
So I'd like to keep it really simple : 1) Anyone with a contribution that would belong in SVN can be considered for commit status by the PMC (PPMC while in incubation). This contribution can be anything - new code, a patch to existing code, documentation, a change to the website, testing code or other resources, etc. (Hopefully this gets people interested in harvesting good docs from the WIKI, as that's worth commit status IMO) I'm not sure how this seeds initial committers though. Start with this, any existing Apache committer or member who has turned in his ACQ and requests commit access. This will at least get an initial set of committers to the repository. Its also the "likely suspects". 2) If offered commit status by the PMC and accepted by the individual, we will get an ACQ from the individual along with an ICLA if not already on file with the ASF secretary. I'd ask that individuals wait to do an ACQ until offered, as the ACQ will be evolving over time as we learn, and I'd like to ask that a new committer have the current version on file as of the date of them being added as a commmitter. This will probably be less of a problem when there is code. 3) The individual would be given free reign in the area to which they contributed, and trusted to engage with the relevant part of the community for other areas of our codebase/resourcebase. And if they request access to another area provided they have no issues they should be given so forthwidth. Start one UNIFIED project not 12. Comments? If people agree to this, I'd like to add this to our website as part of the project policy. If this opens the repository to code then I think its great. If not, then I think it sucks. -Andy geir
Re: [discussion] Committer Addition Process
I'm going to shameless steal an idea from Andy Oliver. Amended with #4 : 1) Anyone with a contribution that would belong in SVN can be considered for commit status by the PMC (PPMC while in incubation). This contribution can be anything - new code, a patch to existing code, documentation, a change to the website, testing code or other resources, etc. (Hopefully this gets people interested in harvesting good docs from the WIKI, as that's worth commit status IMO) 2) If offered commit status by the PMC and accepted by the individual, we will get an ACQ from the individual along with an ICLA if not already on file with the ASF secretary. I'd ask that individuals wait to do an ACQ until offered, as the ACQ will be evolving over time as we learn, and I'd like to ask that a new committer have the current version on file as of the date of them being added as a commmitter. 3) The individual would be given free reign in the area to which they contributed, and trusted to engage with the relevant part of the community for other areas of our codebase/resourcebase. 4) A committer will lose commit status after 4 months of inactivity. In order to regain commit status, that person must begin participating by offering a patch, new code, etc :) On Sep 20, 2005, at 10:07 AM, Geir Magnusson Jr. wrote: Adding committers to a project is a problem every project faces, and there are quite a large number of ways to do it. I've been too worried about legal issues (and they pop up often) lately, and this is a good subject for us to resolve now. We must * have a visible process to ensure fairness * a low barrier to entry to get people helping * a rigid transparent process to ensure safety of the codebase in terms of IP provenance * a cultural standard through which people work on things that they have demonstrated competence to the rest of the community. For the last point, except for keeping people away from parts of the subversion repository to which they have had prior exposure they can't get resolved, we want to have one kind of committer. However, it's clear that we all have different levels of talent in different areas of technology. So a nice way to work - I think - is that committers are added for work in a specific area on a trust basis, and if they want to work in other areas, they engage with others already working there and get informal approval to commit at will. IOW, don't just go rummaging through code in which you have no experience, but work with those that are. This is something that I've heard work well in projects like Subversion, and we're trying it in Geronimo to recognize that the barrier to entry varies by person and technology they are interested in working on. So I'd like to keep it really simple : 1) Anyone with a contribution that would belong in SVN can be considered for commit status by the PMC (PPMC while in incubation). This contribution can be anything - new code, a patch to existing code, documentation, a change to the website, testing code or other resources, etc. (Hopefully this gets people interested in harvesting good docs from the WIKI, as that's worth commit status IMO) 2) If offered commit status by the PMC and accepted by the individual, we will get an ACQ from the individual along with an ICLA if not already on file with the ASF secretary. I'd ask that individuals wait to do an ACQ until offered, as the ACQ will be evolving over time as we learn, and I'd like to ask that a new committer have the current version on file as of the date of them being added as a commmitter. 3) The individual would be given free reign in the area to which they contributed, and trusted to engage with the relevant part of the community for other areas of our codebase/resourcebase. Comments? If people agree to this, I'd like to add this to our website as part of the project policy. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[discussion] Committer Addition Process
Adding committers to a project is a problem every project faces, and there are quite a large number of ways to do it. I've been too worried about legal issues (and they pop up often) lately, and this is a good subject for us to resolve now. We must * have a visible process to ensure fairness * a low barrier to entry to get people helping * a rigid transparent process to ensure safety of the codebase in terms of IP provenance * a cultural standard through which people work on things that they have demonstrated competence to the rest of the community. For the last point, except for keeping people away from parts of the subversion repository to which they have had prior exposure they can't get resolved, we want to have one kind of committer. However, it's clear that we all have different levels of talent in different areas of technology. So a nice way to work - I think - is that committers are added for work in a specific area on a trust basis, and if they want to work in other areas, they engage with others already working there and get informal approval to commit at will. IOW, don't just go rummaging through code in which you have no experience, but work with those that are. This is something that I've heard work well in projects like Subversion, and we're trying it in Geronimo to recognize that the barrier to entry varies by person and technology they are interested in working on. So I'd like to keep it really simple : 1) Anyone with a contribution that would belong in SVN can be considered for commit status by the PMC (PPMC while in incubation). This contribution can be anything - new code, a patch to existing code, documentation, a change to the website, testing code or other resources, etc. (Hopefully this gets people interested in harvesting good docs from the WIKI, as that's worth commit status IMO) 2) If offered commit status by the PMC and accepted by the individual, we will get an ACQ from the individual along with an ICLA if not already on file with the ASF secretary. I'd ask that individuals wait to do an ACQ until offered, as the ACQ will be evolving over time as we learn, and I'd like to ask that a new committer have the current version on file as of the date of them being added as a commmitter. 3) The individual would be given free reign in the area to which they contributed, and trusted to engage with the relevant part of the community for other areas of our codebase/resourcebase. Comments? If people agree to this, I'd like to add this to our website as part of the project policy. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Code into SVN, not the WIKI (Re: [arch] VMCore / Component Model)
On Sep 20, 2005, at 9:29 AM, [EMAIL PROTECTED] wrote: Dude, It's catch 22. There weren't any legitimate committers (because there was no initial code base) at the beginning of the project to "vote". Because of this, there needs to be a lower barrier of entry than a formal procedure. Having a "barrier to entry" isn't in conflict with a "formal procedure". We are going to have a formal procedure because the code pedigree is critical for this project. Otherwise I might suggest a segment of the willing go off and create an initial codebase in a CVS/SVN somewhere that is more open and then submit it. For a project with no code this seems a bit officious. Let the "likely" people in (Mladen for instance is an apache committer in good standing who has plans to do something) and then let Darwin sort them out. Then they can vote in committers in the normal way. The project needs code!!! Rather than being officious, the goal should be to facillitate every means possible to make that happen. It will be messy and there will be serveral misdirections but thats what a repository is for. Forward momentum. This is clearly a position we all believe in - we need code. I'll remark in another summary message. geir -Andy Geir Magnusson Jr. wrote: On Sep 20, 2005, at 9:11 AM, Davanum Srinivas wrote: Geir, When folks have sent in their ACQ/ICLA, we should give them direct commit access (after maybe a VOTE on the ppmc list). I really don't like putting so many road blocks, what exactly are we waiting for? What roadblocks are you talking about? We certainly want a vote and not just make everyone who fills in paperwork a committer. I don't think we need a high bar to entry, but at least a patch, maybe? This is a good subject to discuss. *Any* bulk contribution - i.e. code created outside of the day to day flow of the project by committers should come into a JIRA so the contribution can be inspected and understood to be a clearly delineated contribution. We will be keeping a record of all such contributions. geir Assuming that all is well with the ACQ, this means that we can accept the code you have put in the WIKI into SVN for people to start playing with. You will have to add the code to a JIRA entry for the project, so you can definitively offer it under the Apache license. Thanks, dims -- Andrew C. Oliver SuperLink Software, Inc. Java to Excel using POI http://www.superlinksoftware.com/services/poi Commercial support including features added/implemented, bugs fixed. -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Code into SVN, not the WIKI (Re: [arch] VMCore / Component Model)
On Sep 20, 2005, at 9:36 AM, Davanum Srinivas wrote: So let's do it then...Everyone interested should fill in their paperwork by end of the month. First week next month we can have a VOTE on the PPMC for each person based on their contributions so far. (Let each person state what they are bringing to the table as well if they haven't already). So by end of October we should have a roster of folks with commit privs who can then vote in the next set of committers (or as and when they want to). I really don't want to wait another 4 months and see that we are still in the same situation as we are in today. We won't be. I'll post another note outlining what I think we should do, and we can agree. geir Thanks, dims On 9/20/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Sep 20, 2005, at 9:11 AM, Davanum Srinivas wrote: Geir, When folks have sent in their ACQ/ICLA, we should give them direct commit access (after maybe a VOTE on the ppmc list). I really don't like putting so many road blocks, what exactly are we waiting for? What roadblocks are you talking about? We certainly want a vote and not just make everyone who fills in paperwork a committer. I don't think we need a high bar to entry, but at least a patch, maybe? This is a good subject to discuss. *Any* bulk contribution - i.e. code created outside of the day to day flow of the project by committers should come into a JIRA so the contribution can be inspected and understood to be a clearly delineated contribution. We will be keeping a record of all such contributions. geir Assuming that all is well with the ACQ, this means that we can accept the code you have put in the WIKI into SVN for people to start playing with. You will have to add the code to a JIRA entry for the project, so you can definitively offer it under the Apache license. Thanks, dims -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Code into SVN, not the WIKI (Re: [arch] VMCore / Component Model)
So let's do it then...Everyone interested should fill in their paperwork by end of the month. First week next month we can have a VOTE on the PPMC for each person based on their contributions so far. (Let each person state what they are bringing to the table as well if they haven't already). So by end of October we should have a roster of folks with commit privs who can then vote in the next set of committers (or as and when they want to). I really don't want to wait another 4 months and see that we are still in the same situation as we are in today. Thanks, dims On 9/20/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > On Sep 20, 2005, at 9:11 AM, Davanum Srinivas wrote: > > > Geir, > > > > When folks have sent in their ACQ/ICLA, we should give them direct > > commit access (after maybe a VOTE on the ppmc list). I really don't > > like putting so many road blocks, what exactly are we waiting for? > > What roadblocks are you talking about? > > We certainly want a vote and not just make everyone who fills in > paperwork a committer. I don't think we need a high bar to entry, > but at least a patch, maybe? This is a good subject to discuss. > > *Any* bulk contribution - i.e. code created outside of the day to day > flow of the project by committers should come into a JIRA so the > contribution can be inspected and understood to be a clearly > delineated contribution. We will be keeping a record of all such > contributions. > > geir > > > > > > >> Assuming that all is well with the ACQ, this means that we can accept > >> the code you have put in the WIKI into SVN for people to start > >> playing with. You will have to add the code to a JIRA entry for the > >> project, so you can definitively offer it under the Apache license. > >> > > > > Thanks, > > dims > > > > > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] > > > -- Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
Re: [arch] VMCore / Component Model
Geir Magnusson Jr. wrote: Have you tried to communicate between two components, one in C(++) and one in Java? No, I didn't try that yet. For native compiled java code (gjc) I guess it should be straight forward to extend my proof-of-concept to support it. For java code which runs in the harmony vm the interface will have to be different, but we need this interface too. geir On Sep 19, 2005, at 1:46 PM, David Tanzer wrote: Today I have added some additional Information to the Wiki page. We should also consider using C++ and abstract classes to maintain our component model. While this would make inter-component communication slightly slower it would be easier to maintain. We should also think about using an existing component model like OSGi. The model I posted provides pretty fast communication between components without sacrificing too much flexibility, but it is maybe not as easy to maintain as a clean, object-oriented implementation (i.e. C++). We could discuss how important these aspects are to us, i.e. how much runtime efficiency we are willing to sacrifice for maintainability and flexibility and vice-versa. Regards, David. On Fri, 2005-09-16 at 21:47 +0200, David Tanzer wrote: Ok, it took a little bit longer than I first expected, but now my proof-of-concept implementation of the component model I described is available in the wiki: http://wiki.apache.org/harmony/ComponentModelFunctionPointers I have also linked it from the harmony architecture page. It contains a mechanism for loading components and a basic versioning and dependency management mechanism. The test case loads two components, where one depends on the other. I'll add some more explanations to the wiki page when I have more time, hopefully at the weekend. I have made several assumptions about the directory structure, the coding conventions and the documentation conventions, we should maybe discuss this in a different thread. Regards, David. On Tue, 2005-09-13 at 17:27 +0100, Tim Ellison wrote: David Tanzer wrote: Since we already started to define some component interfaces I think we also should start thinking about a component model which loads / connects such components. Maybe there are also some existing solutions we might want to look at (I must confess I didn't really search yet). Agreed, plus managing the API itself to ensure forwards/backwards version compatibility. I guess a requirement for such a component manager would be that it can load and connect components at runtime and that the specific implementations which are loaded can be configured. It might also be good if the same component implementations can be linked at compile time (i.e. statically) which could have benefits on embedded platforms, but I'm not sure if we really need this. I'm assuming that you are speculating on component management beyond the platform support (i.e. DLL-hell). The java world is already on this path with the OSGi framework (e.g. Felix). It will require a non-trivial solution to ensure that the runtime flexibility does not incur an unacceptable runtime cost. Another requirement would be that the components can be written in different programming languages (i.e. C, C++, Java, ...). It isn't really a problem to solve this for C and C++, but can we also easily support other programming languages? A simple way to implement such a component model in C would be an approach similar to the one Tim Ellison described in [1] where he explains the structure of the J9 VM's portability library. I started writing a proof of concept implementation for this, and I'll add it to the wiki as soon as it's finished. I look forward to seeing the proof of concept. Were you thinking of introducing versioning and dependency management style functions? It would be interesting to have several such proof-of-concept implementations of component models which we can study and the decide which to use. We could even write "import mechanisms" for the different component models so they can import and use components from another model too (of course this would normally imply reduced performance). Regards, David. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/ 200509.mbox/[EMAIL PROTECTED] -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- AUFGABEN DER PHYSIK -- QUANTENMECHANIK Gegebene Konstante: m(Kuh)=400 kg Die Kuh befinde sich auf einer Weide, die ringsum durch einen Zaun abgegrenzt ist. Der Weidezaun sie ideal gebaut, sodass die Kuh ihn (klassich gesehen) nicht passieren kann. Begrnden Sie, dass man die Kuh trotzdem mit gewisser Wahrscheinlichkeit ausserhalb der Weide antrifft.
Re: Code into SVN, not the WIKI (Re: [arch] VMCore / Component Model)
Dude, It's catch 22. There weren't any legitimate committers (because there was no initial code base) at the beginning of the project to "vote". Because of this, there needs to be a lower barrier of entry than a formal procedure. Otherwise I might suggest a segment of the willing go off and create an initial codebase in a CVS/SVN somewhere that is more open and then submit it. For a project with no code this seems a bit officious. Let the "likely" people in (Mladen for instance is an apache committer in good standing who has plans to do something) and then let Darwin sort them out. Then they can vote in committers in the normal way. The project needs code!!! Rather than being officious, the goal should be to facillitate every means possible to make that happen. It will be messy and there will be serveral misdirections but thats what a repository is for. Forward momentum. -Andy Geir Magnusson Jr. wrote: On Sep 20, 2005, at 9:11 AM, Davanum Srinivas wrote: Geir, When folks have sent in their ACQ/ICLA, we should give them direct commit access (after maybe a VOTE on the ppmc list). I really don't like putting so many road blocks, what exactly are we waiting for? What roadblocks are you talking about? We certainly want a vote and not just make everyone who fills in paperwork a committer. I don't think we need a high bar to entry, but at least a patch, maybe? This is a good subject to discuss. *Any* bulk contribution - i.e. code created outside of the day to day flow of the project by committers should come into a JIRA so the contribution can be inspected and understood to be a clearly delineated contribution. We will be keeping a record of all such contributions. geir Assuming that all is well with the ACQ, this means that we can accept the code you have put in the WIKI into SVN for people to start playing with. You will have to add the code to a JIRA entry for the project, so you can definitively offer it under the Apache license. Thanks, dims -- Andrew C. Oliver SuperLink Software, Inc. Java to Excel using POI http://www.superlinksoftware.com/services/poi Commercial support including features added/implemented, bugs fixed.
Re: Code into SVN, not the WIKI (Re: [arch] VMCore / Component Model)
On Sep 20, 2005, at 9:11 AM, Davanum Srinivas wrote: Geir, When folks have sent in their ACQ/ICLA, we should give them direct commit access (after maybe a VOTE on the ppmc list). I really don't like putting so many road blocks, what exactly are we waiting for? What roadblocks are you talking about? We certainly want a vote and not just make everyone who fills in paperwork a committer. I don't think we need a high bar to entry, but at least a patch, maybe? This is a good subject to discuss. *Any* bulk contribution - i.e. code created outside of the day to day flow of the project by committers should come into a JIRA so the contribution can be inspected and understood to be a clearly delineated contribution. We will be keeping a record of all such contributions. geir Assuming that all is well with the ACQ, this means that we can accept the code you have put in the WIKI into SVN for people to start playing with. You will have to add the code to a JIRA entry for the project, so you can definitively offer it under the Apache license. Thanks, dims -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] VMCore / Component Model
Peter Edworthy wrote: [Snip] First of all thanks to David Tanzer, having something solid to start from makes a tremendous difference. The code captures a basic functional spec for a component loader very well. I'm not very familiar with UNIX dynamic libs so if this is way off please say; It seems dlfcn is quite platform specific; would ltdl make more sense? Maybe. I just saw that the APR also provides methods for doing this, so that would be a good solution too. As i said, my code should only be a basis for discussion and a proof-of-concept. It seems as though only one 'native method' is provided per file this way, is that just for the demo code or is it a limitation of this method? No, it's not a limitation of the method, the "struct TestComponent*" could store an arbitrary number of functions. Am I right in thinking that to use the table of 'native method' pointers we will have to place the operands on the stack and then jump to the method (just checking as the code to do that would also be a component and so how would we bootstrap it, jikes had a clever method involving writing from a JVM a startup JVM image with the native code in it)? I'm not sure if we are talking about the same thing here, maybe I just fail to see some important part of the bigger picture. My intention was to provide a mechanism with which we could handle components like the ones for which Weldon Washburn wrote the interfaces for. For example, it could be used to load implementations of http://wiki.apache.org/harmony-data/attachments/HarmonyArchitecture/attachments/gc_interface.txt and http://wiki.apache.org/harmony-data/attachments/HarmonyArchitecture/attachments/vm_gc_interface.txt and interconnect them. It focuses on C (or C++) implementations so far, I'm not sure if we can easily extend it to support other programming languages. I think what you are talking about here is more like the "light-weight native calls" which where proposed by Mladen Turk (correct me if I'm wrong): http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Could this be implemented in Java so long as a native call mechanism existed to 'register' components with each other, there is probably no compelling reason to do this but it might improve cross platform support. That should be no big problem. I mentioned earlier that it would be cool if we had several different prototypes we can play with, compare to each other and discuss about, so maybe someone volunteers for writing one ;-) [Code-In lining] To have a JIT we must have a method of storing 'compiled code' and calling it we could create the basic components as native code stored in the JVM using same system as the JIT. The class loader could then mark inside the byte stream a call to this native code in place of the original byte code. Or the interpreter could act as though the byte code should be interpreted as a call to that method. If this is too inefficient then the JIT will compile the method that the call is within and at this point may well decide to in line the code from the method call. I don't see why we would want to or need to create a different in lining method for these aspects of the interpretor. If we are using the boot strapping method like jikes then maybe some methods should be JIT'ed before the image is written. [native code storage for the JIT] I've never tried to create a JIT, but I assume we need to consider some way of describing the side-effects of a section of code; i.e. what registers are changed/used as input and output. Or do JITs not normally need this as they compile whole methods and so use the stack for data in and out and assume all registers are dirty? Thanks in advance, Peter
Re: Code into SVN, not the WIKI (Re: [arch] VMCore / Component Model)
Geir, When folks have sent in their ACQ/ICLA, we should give them direct commit access (after maybe a VOTE on the ppmc list). I really don't like putting so many road blocks, what exactly are we waiting for? > Assuming that all is well with the ACQ, this means that we can accept > the code you have put in the WIKI into SVN for people to start > playing with. You will have to add the code to a JIRA entry for the > project, so you can definitively offer it under the Apache license. Thanks, dims
Re: Call for Contributions (was Re: 4 Months and...)
On Sep 20, 2005, at 8:52 AM, [EMAIL PROTECTED] wrote: This is not likely to actually attract code. Opening up SVN to committership would. You've described a reverse of how most projects work if you will such that the barrier is to initial commit rather than lazy veto/etc. Most projects give committership to people that have offered code and patches, don't they? geir -Andy Geir Magnusson Jr. wrote: I'd like to restate that we are always looking for code contributions. I do know of some in preparation, but it should be clear that if you have anything to offer (hey, Dan!) please post a note to dev list to discuss. :) geir On Sep 19, 2005, at 5:35 PM, [EMAIL PROTECTED] wrote: Four months and no code. Open up the repository and let the willing start committing. The discussion has gotten so verbose that there are already people publishing edited digests. Code will reduce the discussion :-) -Andy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Call for Contributions (was Re: 4 Months and...)
This is not likely to actually attract code. Opening up SVN to committership would. You've described a reverse of how most projects work if you will such that the barrier is to initial commit rather than lazy veto/etc. -Andy Geir Magnusson Jr. wrote: I'd like to restate that we are always looking for code contributions. I do know of some in preparation, but it should be clear that if you have anything to offer (hey, Dan!) please post a note to dev list to discuss. :) geir On Sep 19, 2005, at 5:35 PM, [EMAIL PROTECTED] wrote: Four months and no code. Open up the repository and let the willing start committing. The discussion has gotten so verbose that there are already people publishing edited digests. Code will reduce the discussion :-) -Andy
Re: [arch] VMCore / Component Model
On Sep 20, 2005, at 12:26 AM, Robin Garner wrote: I think it's important not to take Tim's point about performance too lightly here. There are some key interfaces between components that can't afford the overhead of a function call, let alone an indirect call via a function pointer. Three instances that come to mind are: - Allocation. For best performance, the common case of a new() needs to be inlined directly into the compiled code. - Write barrier (and read barrier if we need one). The common case of a write barrier should be a handful of instructions. - Yield points. Again should inline down to a couple of instructions. I'd be interested in any approaches you may have thought of for these interfaces. Are these things the components would worry about, or can an optimizer deal with these "later" if possible? Now, I'm really just making this up as I go along... what some people call "thinking out loud", but I won't grace this with the term "thinking". I've never written or been inside VM internals, so I'm inventing out of whole cloth here... In earlier discussions of componentization, I kept imagining a model where we have a defined set of capabilities that a component could optionally implement. There would be a required set, as well as optional ones. (This thinking is inspired by the old MSFT COM infrastructure...) In the case of a memory manager, a required one would be the "interface" containing the function pointers for a memory management. An optional one would be "NativeInlineConversion" or something, where an optimizer could find a new() and if it doesn't support the native inlineing, use the function call into the component, and if it does, ask the component for the bit of complied code to use. I'll sketch these out in code once we get David's code contributed properly into JIRA and we register his ACQ. On Mon, 2005-09-19 at 19:46 +0200, David Tanzer wrote: Today I have added some additional Information to the Wiki page. We should also consider using C++ and abstract classes to maintain our component model. While this would make inter-component communication slightly slower it would be easier to maintain. We should also think about using an existing component model like OSGi. The model I posted provides pretty fast communication between components without sacrificing too much flexibility, but it is maybe not as easy to maintain as a clean, object-oriented implementation (i.e. C++). We could discuss how important these aspects are to us, i.e. how much runtime efficiency we are willing to sacrifice for maintainability and flexibility and vice-versa. First order of priority, IMO, is to decide what are the performance critical components, and what are not. For the infrequent cases, we can afford a heavy-weight approach, for those that happen every few bytecodes, we need to be lean and mean. Is this the kind of optimization you want to do now, or do we want to put together a structure that supports it for later? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] VMCore / Component Model
Have you tried to communicate between two components, one in C(++) and one in Java? geir On Sep 19, 2005, at 1:46 PM, David Tanzer wrote: Today I have added some additional Information to the Wiki page. We should also consider using C++ and abstract classes to maintain our component model. While this would make inter-component communication slightly slower it would be easier to maintain. We should also think about using an existing component model like OSGi. The model I posted provides pretty fast communication between components without sacrificing too much flexibility, but it is maybe not as easy to maintain as a clean, object-oriented implementation (i.e. C++). We could discuss how important these aspects are to us, i.e. how much runtime efficiency we are willing to sacrifice for maintainability and flexibility and vice-versa. Regards, David. On Fri, 2005-09-16 at 21:47 +0200, David Tanzer wrote: Ok, it took a little bit longer than I first expected, but now my proof-of-concept implementation of the component model I described is available in the wiki: http://wiki.apache.org/harmony/ComponentModelFunctionPointers I have also linked it from the harmony architecture page. It contains a mechanism for loading components and a basic versioning and dependency management mechanism. The test case loads two components, where one depends on the other. I'll add some more explanations to the wiki page when I have more time, hopefully at the weekend. I have made several assumptions about the directory structure, the coding conventions and the documentation conventions, we should maybe discuss this in a different thread. Regards, David. On Tue, 2005-09-13 at 17:27 +0100, Tim Ellison wrote: David Tanzer wrote: Since we already started to define some component interfaces I think we also should start thinking about a component model which loads / connects such components. Maybe there are also some existing solutions we might want to look at (I must confess I didn't really search yet). Agreed, plus managing the API itself to ensure forwards/backwards version compatibility. I guess a requirement for such a component manager would be that it can load and connect components at runtime and that the specific implementations which are loaded can be configured. It might also be good if the same component implementations can be linked at compile time (i.e. statically) which could have benefits on embedded platforms, but I'm not sure if we really need this. I'm assuming that you are speculating on component management beyond the platform support (i.e. DLL-hell). The java world is already on this path with the OSGi framework (e.g. Felix). It will require a non-trivial solution to ensure that the runtime flexibility does not incur an unacceptable runtime cost. Another requirement would be that the components can be written in different programming languages (i.e. C, C++, Java, ...). It isn't really a problem to solve this for C and C++, but can we also easily support other programming languages? A simple way to implement such a component model in C would be an approach similar to the one Tim Ellison described in [1] where he explains the structure of the J9 VM's portability library. I started writing a proof of concept implementation for this, and I'll add it to the wiki as soon as it's finished. I look forward to seeing the proof of concept. Were you thinking of introducing versioning and dependency management style functions? It would be interesting to have several such proof-of-concept implementations of component models which we can study and the decide which to use. We could even write "import mechanisms" for the different component models so they can import and use components from another model too (of course this would normally imply reduced performance). Regards, David. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/ 200509.mbox/[EMAIL PROTECTED] -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- AUFGABEN DER PHYSIK -- QUANTENMECHANIK Gegebene Konstante: m(Kuh)=400 kg Die Kuh befinde sich auf einer Weide, die ringsum durch einen Zaun abgegrenzt ist. Der Weidezaun sie ideal gebaut, sodass die Kuh ihn (klassich gesehen) nicht passieren kann. Begrnden Sie, dass man die Kuh trotzdem mit gewisser Wahrscheinlichkeit ausserhalb der Weide antrifft. -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] VMCore / Component Model
On Sep 13, 2005, at 1:47 PM, David Tanzer wrote: On Tue, 2005-09-13 at 17:27 +0100, Tim Ellison wrote: [Snip] I guess a requirement for such a component manager would be that it can load and connect components at runtime and that the specific implementations which are loaded can be configured. It might also be good if the same component implementations can be linked at compile time (i.e. statically) which could have benefits on embedded platforms, but I'm not sure if we really need this. I'm assuming that you are speculating on component management beyond the platform support (i.e. DLL-hell). The java world is already on this path with the OSGi framework (e.g. Felix). It will require a non-trivial solution to ensure that the runtime flexibility does not incur an unacceptable runtime cost. [Snip] I look forward to seeing the proof of concept. Were you thinking of introducing versioning and dependency management style functions? I was thinking about a really simple model, basically only a framework which loads shared libraries and creates the function pointer tables you described in your posting. Versioning and dependency management will be a requirement, but I didn't consider it so far in my proof-of-concept (which will take a few more days to finish), and the libraries which are loaded should be configurable. I also think we should be careful not to introduce too much runtime costs, and I'm implementing my prototype under the assumption that we don't need to manage arbitrary components (so I assume that the component interfaces and dependencies are known at compile time). Anyway it would be possible to extend my approach for arbitrary (i.e. unknown) components. I think that ultimately, this will be necessary. I imagine we want to be able to allow others to plug in new components easily. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] VMCore / Component Model
Hi, sorry if this is a bit long, my fault for not catching up with the list for a few days ;-}> headlines are: * Cross-platform and language support - ltdl vs dlfcn - native code needed to access native code, jikes boot strap system - Java based loader? * In-lining of code - let the JIT do it * native code storage for JIT use - how much information is needed to allow good optimization? [cross-platform support] First of all thanks to David Tanzer, having something solid to start from makes a tremendous difference. The code captures a basic functional spec for a component loader very well. I'm not very familiar with UNIX dynamic libs so if this is way off please say; It seems dlfcn is quite platform specific; would ltdl make more sense? It seems as though only one 'native method' is provided per file this way, is that just for the demo code or is it a limitation of this method? Am I right in thinking that to use the table of 'native method' pointers we will have to place the operands on the stack and then jump to the method (just checking as the code to do that would also be a component and so how would we bootstrap it, jikes had a clever method involving writing from a JVM a startup JVM image with the native code in it)? Could this be implemented in Java so long as a native call mechanism existed to 'register' components with each other, there is probably no compelling reason to do this but it might improve cross platform support. [Code-In lining] To have a JIT we must have a method of storing 'compiled code' and calling it we could create the basic components as native code stored in the JVM using same system as the JIT. The class loader could then mark inside the byte stream a call to this native code in place of the original byte code. Or the interpreter could act as though the byte code should be interpreted as a call to that method. If this is too inefficient then the JIT will compile the method that the call is within and at this point may well decide to in line the code from the method call. I don't see why we would want to or need to create a different in lining method for these aspects of the interpretor. If we are using the boot strapping method like jikes then maybe some methods should be JIT'ed before the image is written. [native code storage for the JIT] I've never tried to create a JIT, but I assume we need to consider some way of describing the side-effects of a section of code; i.e. what registers are changed/used as input and output. Or do JITs not normally need this as they compile whole methods and so use the stack for data in and out and assume all registers are dirty? Thanks in advance, Peter
