incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk Eismann <bort...@googlemail.com>
Subject Re: Committer duties and information
Date Wed, 04 Jan 2012 21:04:51 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message