Quoting Alex Harui <aha...@adobe.com>:
Yes Alex this makes sense. I realize the point of Apache is to be
democratic by it's very nature. I wouldn't even think about committing
any component like code without a huge discussion on it's impact and
value with the community first.
I was just trying to get the most extreme case clear in my head.
Besides, with something like the TabNavigator, I think adding an
interface here or there and allowing alternate implementations makes
much more sense than bickering about "which" component should be used.
I also think that the list should really have a decent discussion
about the future uses of interfaces and the lack of them in the
framework to allow for customizations through composition instead of
subclassing or copy and paste craziness.
Mike
So for practical reasons, I think we're going to start with
commit-then-review.
If you try to commit a new component, that commit will be reviewed and
vetoed out if there is a problem.
So let's get specific. Let's say you want to contribute your version of a
Spark TabNavigator component. Adobe has almost finished its version and
promised to commit it. I would recommend starting a discussion on this list
about whether to take yours vs Adobe's. That way you'll at least have an
idea whether folks are willing to review your version or want to wait for
Adobe. Then if you do decide to commit, we'll take a harder look at the
code and maybe you'll get rejected if we find some major problem, but
otherwise it gets in. And if folks want to wait for Adobe and you disagree,
you can offer it up under a different package name. I suppose someone might
still try to veto that based on confusing folks about which TabNavigator to
use, so that might be worth discussing up front as well, but I personally
don't have a problems with different flavors of components.
-Alex
