Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of aharui@adobe.com designates
 64.18.1.185 as permitted sender)
From: Alex Harui <aharui@adobe.com>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Date: Wed, 4 Jan 2012 12:57:33 -0800
Subject: Re: Committer duties and information
Thread-Topic: Committer duties and information
Thread-Index: AczLIZKZBXTPlUrJTuy4P2ZLytKaCAAAegfA
Message-ID: <CB29FD3D.39086%aharui@adobe.com>
In-Reply-To: 
 <CANi2vaeCK5PhWjaTUEWw77aLN12i+FR12QvG8Xa3+-fSugkdrw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-Entourage/13.11.0.110726
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

My understanding is that some projects require all committers to submit JIR=
A
patches first, so they can get reviewed before commit because reverting
commits is painful in many ways and they think the likelihood of bad commit=
s
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 traffi=
c
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" <bortsen@googlemail.com> wrote:

> Alex,
>=20
> do you mean "commit-and-review" like in "commit to SVN"?
>=20
> Or is it meant that people contribute the code (through JIRA), tell peopl=
e
> on the list about it so the code can get reviewed, voted in/out and
> eventually comitted to the SVN by some committers?
>=20
> Dirk.
>=20
> 2012/1/4 Alex Harui <aharui@adobe.com>
>=20
>> So for practical reasons, I think we're going to start with
>> commit-then-review.
>>=20
>> If you try to commit a new component, that commit will be reviewed and
>> vetoed out if there is a problem.
>>=20
>> 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 a=
n
>> idea whether folks are willing to review your version or want to wait fo=
r
>> 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 personall=
y
>> don't have a problems with different flavors of components.
>>=20
>> -Alex
>>=20
>>=20
>> On 1/4/12 12:19 PM, "Michael Schmalle" <mike@teotigraphix.com> wrote:
>>=20
>>> Quoting Jonathan Campos <jonbcampos@gmail.com>:
>>>=20
>>>> That is an exact question that I asked at the Flex Summit specifically
>> for
>>>> the group.
>>>>=20
>>>> Roy Fielding had a great analogy/answer.
>>>> The main idea is that this is that we are throwing a party, not runnin=
g
>> a
>>>> business with free labor. So people need to be energized about what th=
ey
>>>> are doing, they aren't there to be given tasks.
>>>>=20
>>>> As such there is no roadmap. You may come up with a great idea and sta=
rt
>>>> 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 agains=
t.
>>>>=20
>>>> 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.
>>>>=20
>>>> Make sense?
>>>>=20
>>>> J
>>>=20
>>> This actually does make sense for features.
>>>=20
>>> 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?
>>>=20
>>> 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?
>>>=20
>>> 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.
>>>=20
>>> Thanks,
>>> Mike
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>=20
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>=20
>>=20

--=20
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui