incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: Committer duties and information
Date Wed, 04 Jan 2012 20:57:33 GMT
My understanding is that some projects require all committers to submit JIRA
patches first, so they can get reviewed before commit because reverting
commits is painful in many ways and they think the likelihood of bad commits
is high because of the complexities involved.

I was leaning towards doing that (we always reviewed before commit on the
Flex team in Adobe but used email instead of JIRA) but I don't want to put
another obstacle in place and I'm not clear that I want that kind of traffic
in JIRA.

So, I think committers will just be able to check in code and we'll have to
get the commit emails and review then. And veto if we see a problem.  But I
can certainly be convinced otherwise.

On 1/4/12 12:43 PM, "Dirk Eismann" <> wrote:

> Alex,
> do you mean "commit-and-review" like in "commit to SVN"?
> Or is it meant that people contribute the code (through JIRA), tell people
> on the list about it so the code can get reviewed, voted in/out and
> eventually comitted to the SVN by some committers?
> Dirk.
> 2012/1/4 Alex Harui <>
>> 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
>> On 1/4/12 12:19 PM, "Michael Schmalle" <> wrote:
>>> Quoting Jonathan Campos <>:
>>>> That is an exact question that I asked at the Flex Summit specifically
>> for
>>>> the group.
>>>> Roy Fielding had a great analogy/answer.
>>>> The main idea is that this is that we are throwing a party, not running
>> a
>>>> business with free labor. So people need to be energized about what they
>>>> are doing, they aren't there to be given tasks.
>>>> As such there is no roadmap. You may come up with a great idea and start
>>>> working on it, then when other people see what you are doing they may
>> join.
>>>> Over time your idea snowballs and gets added in, but this doesn't mean
>> that
>>>> there is a formal roadmap for people to sit at and program away against.
>>>> However this is where Spoon comes in. We do have plans and roadmaps of
>>>> features we want to add. Some take time and require people. If you are
>>>> interested in our roadmap (our party) you and anyone else is free to
>> join.
>>>> Make sense?
>>>> J
>>> This actually does make sense for features.
>>> So can I ask this, am I to then just look at the bug base, say hey
>>> that looks like something I can fix, fix it then commit it?
>>> Don't jump on this to quick, I am saying there needs to be a unit
>>> test? I remember Alex saying that Apache is usually commit & review
>>> but that they were trying for a review and commit in the beginning.
>>> Has anybody else heard this?
>>> Does there have to be votes on say a new component that would be added
>>> to the SDK? I'm really just trying to understand the algorithm of
>>> develop/test/fix/commit for an initial committer.
>>> Thanks,
>>> Mike
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.

Alex Harui
Flex SDK Team
Adobe Systems, Inc.

View raw message