On Sat, Apr 11, 2009 at 10:56 AM, Gavin <ga...@16degrees.com.au> wrote: >> -----Original Message----- >> From: tcu...@vafer.org [mailto:tcu...@vafer.org] On Behalf Of Torsten
<snip> >> The incubator approach just doesn't work well for projects that have a >> very small scope and user base IMO. +1 the smaller the code base, the more problems the incubator has with it micro-libraries are particularly difficult >> The current incubator is about >> establishing a project. We rather would to like to have something that >> helps integration into an existing project. from the incubator perspective, IMO the effort that the incubator has had to put into small code bases has been totally out of proportion and this energy would have been much better invested into stopping some of the larger, higher profile failures. it's time to acknowledge that the incubator only has a certain level of energy and the IPMC should be investing it where the risks and gains are highest. the commons has established an excellent track record in understanding how to develop micro-libraries as a community. if the commons can supply the energy required to create a specialist section for small code bases then this will allow the IPMC to focus it's efforts on the larger code bases. > 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 > 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) this required enculturalisation of close code bases was a major driving factor behind the setting up of the incubator. the incubator has been successful at doing this. the incubator has been less successful with existing openly developed FOSS projects, and IMO it's few successes have a lot more to do with the qualities of the incoming projects than the effectiveness of it's methods. the incubator has not enjoyed success with small code bases. commons has a wealth of expertise with these kinds of projects. from an IPMC perspective, i think we need to grab this chance to get some help on this. however, IMHO i'm not sure that we can hit upon the right set of rules straight away, and i'm also not sure whether the current proposal is the right approach. i do think we should approve the principle of a specialist incubator for small codebases staffed by experts from the commons. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
