flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Committer duties and information
Date Wed, 04 Jan 2012 21:12:41 GMT
Maybe it is just me.  The reviewing of patches from JIRA was really painful.
Requiring reviews of everything is impractical if I want to fix just one
last thing in the middle of the night before cutting a release.  Sometimes,
I think you just gotta trust people.  And use automation instead of humans
to double check things.

But also, we won't have the old bugs migrated to JIRA for a while so people
can get started sooner if we do commit then review, which seems to be the
Apache default.

On 1/4/12 1:04 PM, "Dirk Eismann" <bortsen@googlemail.com> wrote:

> review-and-commit sounds more natural to me as well, maybe I'm just not
> seeing the benefits for commit-and-review.
> Dirk.
> 2012/1/4 Alex Harui <aharui@adobe.com>
>> My understanding is that some projects require all committers to submit
>> 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" <bortsen@googlemail.com> 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 <aharui@adobe.com>
>>>> 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" <mike@teotigraphix.com> wrote:
>>>>> Quoting Jonathan Campos <jonbcampos@gmail.com>:
>>>>>> 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
>>>> join.
>>>>>> Over time your idea snowballs and gets added in, but this doesn't
>>>> 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
>>>>>> features we want to add. Some take time and require people. If you
>>>>>> interested in our roadmap (our party) you and anyone else is free
>>>> 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.
>>>> http://blogs.adobe.com/aharui
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui

Alex Harui
Flex SDK Team
Adobe Systems, Inc.

View raw message