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
>> 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" <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
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.
>>>> 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.
http://blogs.adobe.com/aharui


Mime
View raw message