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" <bort...@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 <aha...@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" <bort...@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 <aha...@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" <m...@teotigraphix.com> wrote: >>>> >>>>> Quoting Jonathan Campos <jonbcam...@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
