Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v734)
In-Reply-To: <83EFFC2C-10E1-419F-84F9-A545BE31D28E@iq80.com>
References: <4B3CC3C8-07EA-4155-9963-649DEC6CCDB9@apache.org>
 <83EFFC2C-10E1-419F-84F9-A545BE31D28E@iq80.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <5988DE1B-2014-4C3E-9B35-14D0C536478E@apache.org>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geirm@apache.org>
Subject: Re: [vote] PMC to accept DayTrader contribution and/or/not create
 "application" subproject
Date: Tue, 20 Sep 2005 12:38:24 -0400
To: dev@geronimo.apache.org


On Sep 20, 2005, at 12:28 PM, Dain Sundstrom wrote:

> +1  Accept the DayTrader donation into the project
>
> -1  Do not create Applications subproject.
>
> I think I'm a bit confused here.  You seem to be implying that if  
> the code is at "scm/geronimo/daytrader" it is a subproject.

I was going to disagree, but after thinking for a sec, ... well,  
yes.  To me only things that distinguish a subproject from main tree  
is that

a) it's not in the main tree

b) it has separate release cycles

c) it has a subheading on the web site so there can be specific docs  
describing it

There's not much more to it.  There is nothing special about the  
people working on it.  We all are working on it, effectively.

> I think it makes since to move the applications out of trunk to  
> keep it "clean", but I don't think that requires us to create an  
> applications subproject.  I getting the feeling that "subproject"  
> is our new golden hammer (http://en.wikipedia.org/wiki/ 
> Golden_hammer), and creating a subproject with one person is a  
> pretty good sign.  I say let's not put the cart before the horse  
> and when we get more people involved in applications we can take on  
> the burden of adding subproject.

What do you see the burden as?  Right now, we have the code hanging  
around, and I was just suggesting that we

a) move it out of the main tree

b) let it have separate release cycles

c) let there be space on the website so it can be described, pointed  
to, etc

Does this help?  We can optionally add another "project" in JIRA so  
that the release numbers don't get confusing, like we did for tools,  
but that's just because components in JIRA can't have separate  
versions and releases.

geir

>
> -dain
>
> On Sep 20, 2005, at 9:13 AM, Geir Magnusson Jr. wrote:
>
>
>> There has been little comment or complaint about the "DayTrader"  
>> contribution GERONIMO-1016.
>>
>> I have done a cursory review and committed the code minus the  
>> binary code (.class and .ear) into trunk/sandbox.  I did this as a  
>> courtesy to Matt so he can keep working and submitting patches for  
>> now.  (Matt, get rid of the App.java stuff that seem to be maven  
>> detritus..)
>>
>> For efficiency, I'd like to vote on two things.
>>
>> First, whether or not to accept.  All votes welcome, PMC votes  
>> binding :
>>
>> [ ] +1  Accept the DayTrader donation into the project
>> [ ] -1  Do not accept DayTrader donation into the project
>>
>>
>> Second, we now have a collection of samples, applications and  
>> such.  I think that it would help keep the trunk clear if we  
>> started an Applications subproject (peer with DevTools) and move  
>> everything like it there.
>>
>> [ ] +1 Create an Applications subproject (to which Apache Geronimo
>>        subproject rules apply) and move DayTrader (if accepted)
>>        with other relevant codebases into it
>> [ ] -1 Do not create Applications subproject.  Leave in trunk.
>>
>>
>> I'm happy for people to pose alternatives if there are good ones -  
>> I just didn't see any on the threads so far.
>>
>> geir
>>
>> -- 
>> Geir Magnusson Jr                                  +1-203-665-6437
>> geirm@apache.org
>>
>>
>>
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org