Return-Path: 
 <general-return-21596-apmail-incubator-general-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-general-archive@www.apache.org
Received: (qmail 16236 invoked from network); 11 Apr 2009 20:29:57 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 11 Apr 2009 20:29:57 -0000
Received: (qmail 67052 invoked by uid 500); 11 Apr 2009 20:29:56 -0000
Delivered-To: apmail-incubator-general-archive@incubator.apache.org
Received: (qmail 66865 invoked by uid 500); 11 Apr 2009 20:29:55 -0000
Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:general-help@incubator.apache.org>
List-Unsubscribe: <mailto:general-unsubscribe@incubator.apache.org>
List-Post: <mailto:general@incubator.apache.org>
List-Id: <general.incubator.apache.org>
Reply-To: general@incubator.apache.org
Delivered-To: mailing list general@incubator.apache.org
Received: (qmail 66855 invoked by uid 99); 11 Apr 2009 20:29:55 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 11 Apr 2009 20:29:55 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of bernd.fondermann@googlemail.com
 designates 209.85.218.219 as permitted sender)
Received: from [209.85.218.219] (HELO mail-bw0-f219.google.com)
 (209.85.218.219)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 11 Apr 2009 20:29:45 +0000
Received: by bwz19 with SMTP id 19so1574621bwz.12
        for <general@incubator.apache.org>;
 Sat, 11 Apr 2009 13:29:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=gamma;
        h=domainkey-signature:mime-version:received:in-reply-to:references
         :date:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        bh=rzTV5l6b+9XYQnk0OxKCACPy8BtsEk61bsBj0erkQBo=;
        b=JUEspJ6lRqptWzYHJO9g+wiJkaSBPTV4Ot3T+i9C0LGeKCai935R2R0i2b6Nevmw/d
         qgegvDmzYbyYL4feIPJ+bjujS6C34gLXCsHbs0l4YD7rsib+rH+2BavQiZgiH/h9/Ls+
         j4Dpuf3PUGxdnjI1IumNP5Pb9iCnFu+rrsI6s=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=eu+GRM7dO0bXI1nkWhFJ8iN432IrL653+ReG99N4I9DktPEkIPBM8zFwflk4GbVlcX
         pDMa5kdi3BUi2t/kVoA3KisoVx6K9i9zGQiMrxnDF3VUiB2OTyOU3zg9CnIz6asI8Zcj
         b3jHYDmRglKzKy1i3jvar+7tD1y0W1WIGPVP8=
MIME-Version: 1.0
Received: by 10.223.126.69 with SMTP id b5mr1363888fas.34.1239481765007; Sat,
	11 Apr 2009 13:29:25 -0700 (PDT)
In-Reply-To: <f470f68e0904111224m3641e8a4p891ab4ad9a242fb0@mail.gmail.com>
References: <71717.75209.qm@web55105.mail.re4.yahoo.com>
	 <5c902b9e0904092059y3111ad1hb9bd255556b9525e@mail.gmail.com>
	 <caf30e2a0904092359t34d80730m5a5135794f4a8f4f@mail.gmail.com>
	 <6c59d89a0904100332g5a09e9e2jb8ac02366d26ea49@mail.gmail.com>
	 <caf30e2a0904110122o7a0b9d2di85ffd5ef36edb619@mail.gmail.com>
	 <6c59d89a0904110226g2c0e9c6dqb0b33b48fae46e15@mail.gmail.com>
	 <7BD05F5BDB3F438F99D79F8A37FC90CC@developer>
	 <f470f68e0904111224m3641e8a4p891ab4ad9a242fb0@mail.gmail.com>
Date: Sat, 11 Apr 2009 22:29:24 +0200
Message-ID: <88f6e29a0904111329u75342854nf6fd6f645e592999@mail.gmail.com>
Subject: Re: [PROPOSAL] Commons Incubator
From: Bernd Fondermann <bernd.fondermann@googlemail.com>
To: general@incubator.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked by ClamAV on apache.org

On Sat, Apr 11, 2009 at 21:24, Robert Burrell Donkin
<robertburrelldonkin@gmail.com> wrote:
> On Sat, Apr 11, 2009 at 10:56 AM, Gavin <gavin@16degrees.com.au> wrote:
>>> -----Original Message-----
>>> From: tcurdt@vafer.org [mailto:tcurdt@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 trus=
t
>> with the project members and then after a while be voted in as a committ=
er.
>> 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 cod=
e
>> and if they wish to continue working on that code then send in patches t=
o
>> the list or issue tracker. Eventually you'll get commit access, will hav=
e
>> 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 (wh=
ich
>> just happens to have come from Company X in the first place.) The last t=
hing
>> they want is for person Y to go through the Apache Way initiation ceremo=
ny
>> that could last months, they want him/her in there carrying on committin=
g 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. Ever=
y
>> 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=92t 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.

I sympathize with the general desire to be able to grow small code
bases at Apache. (We had this discussion in the labs list a short
while ago.) And for sure the Common's people have know-how how to
handle small projects.

But, establishing "Commons Labcubator" within the Incubator doesn't
seem like the right approach to me. Either it's a Commons project,
then it should grow in Commons, or it's another project's small code
base, then it should be nurtured there, or it's something completely
different, then it should grow in Labs (which is language agnostic,
BTW).

I'd like to re-iterate though, that dealing with (developing and
releasing) independent small code bases (in terms of contributors and
code) is not easily possible at the ASF at the moment. This is why we
lost the Orthrus Lab to Google Code. The more projects and products we
host, the more difficult (or impossible) it gets to spot the
interesting ones.

So this is not only a Commons-specific issue. It also applies to other
"regular TLP"s and Labs as well.

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org