incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <>
Subject Non-core code, contrib and samples (was: Goal for Flex: Strengthening large-scale Flex applications...)
Date Fri, 13 Jan 2012 11:55:04 GMT
On Fri, Jan 13, 2012 at 12:43 PM, David Arno <> wrote:
> ...I'm going to repeat myself from yesterday here. If you think this
> documentation is useful, get writing it...

Or write some code, maybe an example application, that exposes your ideas.

> ...If what you commit it or submit it as a patch gets approval, then it'll form
> part of future Apache Flex releases. If folk veto it, it won't. Either way,
> it has to be more productive than this endless "Yes we should. No we
> shouldn't" bickering over this topic....

It doesn't have to be black and white between releasing and a veto -
and a release might not include the complete Apache Flex codebase.

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".

We have both of these in the Sling project [1] [2] and that works
quite well: sometimes a module will move from contrib to the core
parts, and the reverse has also happened IIRC to deprecate a core

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.

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.



View raw message