El sáb, 11-04-2009 a las 19:56 +1000, Gavin escribió: > > > -----Original Message----- > > From: tcu...@vafer.org [mailto:tcu...@vafer.org] On Behalf Of Torsten > > Curdt > > Sent: Saturday, 11 April 2009 7:26 PM > > To: general@incubator.apache.org > > Subject: Re: [PROPOSAL] Commons Incubator > > > > On Sat, Apr 11, 2009 at 10:22, Niclas Hedhman <nic...@hedhman.org> wrote: > > > On Fri, Apr 10, 2009 at 6:32 PM, Torsten Curdt <tcu...@apache.org> > > wrote: > > >> Well, the point is: we are talking about small libraries. > > >> > > >> Imagine there is library X which was developed by only 2 developers. > > >> They want to bring this code to Commons. What to do? IP clearance is > > >> one thing. But what about the 2 developers? Just make them committers > > >> while they have no clue about Apache? Doesn't sound like a good idea. > > >> Just accepting their code and make them send patches until we feel > > >> they are ready? Feels not appropriate since they are the authors of > > >> the code. On the other hand going through the "normal" incubator is a > > >> bit over the top for a project that is so small that it is not > > >> targeting to become it's own project. Building a community is not > > >> really that applicable in this case. It's rather about integrating it > > >> into an existing community. > > > > > > Careful now, you are sinking your own proposal with your arguments. > > > > Not at all. You are mixing things up :) > > > > > 1. The proposal says that there is no need to build a community, since > > > the entire Commons community is there to make sure everything is Ok. > > > > Indeed that is the case. > > > > > 2. You say that you can't just make them committers, insinuating that > > > the Commons community will NOT be there to make sure everything is Ok. > > > > No - that is just you saying that :) > > > > There is a difference between having oversight and training people in > > the Apache way. This is not the same thing. > > > > If other projects get new committers through bulk contributions and > > train them later... Well, then that is suboptimal from my perspective. > > Any future committer has to learn the Apache way "the hard way". Just > > throwing some code at us doesn't make them understand. And this is > > were this approach falls down for us. > > > > I personally have not experience with such contributions "thanks for > > the code *magic wand* now you are also a committer". Either the new > > people have been around long enough so making them a committer soon > > after the code contribution was a non-problem or they sent patches > > until we felt they are ready. But hey - might have been differently > > for other projects ...not that I would be very happy about it. > > > > The incubator approach just doesn't work well for projects that have a > > very small scope and user base IMO. The current incubator is about > > establishing a project. We rather would to like to have something that > > helps integration into an existing project. > > I understand both points of view here. Unfortunately however different > circumstances of the code 'donations' are getting differing treatment. > > My view, and I believe Torstens view is that to become a committer means to > join the dev lists, send in patches, be part of the community, gain trust > with the project members and then after a while be voted in as a committer. > Now if someone has a nice great big chunk of code, or even a whole > mini-subproject to donate, then they should so just that, donate the code > and if they wish to continue working on that code then send in patches to > the list or issue tracker. Eventually you'll get commit access, will have > learnt the Apache Way and all is dandy. > > The 'other' view is I believe mainly Company orientated. Company X pays
Non sequitur, and I think not the case under discussion. *My* other view is a person (definitely not a BigCo) that has developed a small code chunk (library, etc.) that would fit nicely in a given project. The code is taken and the person is granted commit rights. a) code changes can be undone in case of error, this is what scm is for b) there is -1 (veto) on technical decisions, that helps settling the community after the addition c) the person does not feel that her code is stolen, etc. Obviously I don't mean a policy cast in stone, but a judgement call on the given PMC. If they feel there can be any problems, there are several ways forward: - have the prospect committer donate the code and send patches for a while (as Gavin proposes) without being committer - have the prospect committer "refactor" the code in a sandbox, where s/he can be watched, as learning process - ... Regards Santiago > person Y to work on code that they want to be 'donated' to Project Z (which > just happens to have come from Company X in the first place.) The last thing > they want is for person Y to go through the Apache Way initiation ceremony > that could last months, they want him/her in there carrying on committing to > it as usual. Hence we have the 'here's some code, here's a new committer or > two to go with it'. > > The 'other' view imho is wrong and just bypasses what we are about. Every > now and then someone has to remind us, we are a group of individuals > belonging to a community that works on code. Company Z and all the other > Companies out there need to understand this, especially when considering > employing someone and paying them to work on open source projects. (Can't > you just tell I don’t work for a Company Z) > > In Company Z defence, the ASF has benefitted greatly and is greatly enhanced > by projects that have been brought in by these Company types. Many projects > would not have even got off the ground if it wasn’t for them. In return > however there have been willing volunteers jumping in and joining these > projects and providing their own free volunteer time and coding expertise > that advantage mainly Company Z because they sell services that use the > projects product. > > In summary I don’t agree with a Commons Incubator, just get the code cleared > and accepted, get the developers to join the ranks of patch makers until you > feel they are ready for committer-ship (which is much more than just code, > and who knows they may grasp the concept quickly and be ready in a couple of > months). > > Gav... > > > > > cheers > > -- > > Torsten > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > -- > > No virus found in this incoming message. > > Checked by AVG. > > Version: 7.5.557 / Virus Database: 270.11.51/2052 - Release Date: > > 4/10/2009 6:39 AM > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
