Quoting Alex Harui <aharui@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
>
|