Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
From: "Rui Silva" <flex@rduartes.net>
To: <flex-dev@incubator.apache.org>
Subject: re: Non-core code,
 contrib and samples (was: Goal for Flex: Strengthening large-scale Flex
 applications...)
Date: Fri, 13 Jan 2012 04:03:53 -0800
Reply-To: flex@rduartes.net
Message-ID: <7087560d$59c0a553$1e63cc42$@com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

> From: "Bertrand Delacretaz" <bdelacretaz@apache.org>
> Many projects have a "contrib" folder in their code repository, where
> code that's not part of the core project but might be interesting to
> part of the community lives. Same for "samples".
>

Was trying to get my head around what contrib and sample would be and how 
those would be different from the whiteboard, until I thought about all the 
accessory stuff people may want to contribute that don't necessarily belong 
to core Flex (docs, scripts, tools, etc..). I agree that instead of sending 
people away to find another repository for their stuff, they could leave it 
in a contribs folder in here. Some level of validation and cleaning up 
should be performed from time to time (mainly to guarantee that it is not 
abused to store stuff that is *really* unrelated to Flex).

> The contrib and samples modules might have different release cycles as
> the core, and some of them might be out of sync with the core project,
> that's fine as having them in there makes it clear what their status
> is. Many contrib/samples modules are one-man shows which is fine as
> well. You might see that as the next step up from the whiteboard area.

Well, I guess you explained it here quite well. Those folders could house 
stuff that isn't even expected to be merged directly to the main branch (up 
until the point it is deemed interesting enough to be merged). While I'd 
expect all code in Whiteboard to result initially from TRUNK branching, the 
contents in CONTRIBS and SAMPLES could be or not. 

> Creating a contrib and samples folders in the Flex trunk, if/once
> people have stuff to commit in there, might be a good idea for this
> project as well. Instead of kicking out people who want to work on
> sample code that's only interesting to a subset of the Flex audience,
> give them a space under samples or contrib.

I agree.