on a branch? ;)
On Thu, Feb 12, 2015 at 2:47 PM, Andrew Grieve wrote:
> Awesomesauce. Going to move forward then (with putting back the
> accidentally deleted test). If there's other things missed, they can be
> brought back as well.
>
> On Thu, Feb 12, 2015 at 12:47 PM, Brian LeRoux wrote:
>
>
Awesomesauce. Going to move forward then (with putting back the
accidentally deleted test). If there's other things missed, they can be
brought back as well.
On Thu, Feb 12, 2015 at 12:47 PM, Brian LeRoux wrote:
> I see no situation where we don't want a feature branch vetted by >1 person
> befo
I see no situation where we don't want a feature branch vetted by >1 person
before we land anything on master …short of fixing broken tests.
I assume good faith. Joe: you had a bad day and, I think, you still feel
mistrust after previous commits landing on master stalling out your work
last summer
This commit may not have warranted this discussion.
I think we agree that large changes/commits should be on feature branches, and
discussed before being merged.
Let's go with that.
> On Feb 12, 2015, at 8:49 AM, Andrew Grieve wrote:
>
> Sounds like you've been having a rough time. :( Hope
Sounds like you've been having a rough time. :( Hope you get through it.
Believe me when I say I hear you loud and clear about making changes on
feature branches. I just don't think this one fits.
- No one (other than me) has touched the tests since September of last
year, so it's unlikely that a
On Thu Feb 12 2015 at 7:44:52 AM Andrew Grieve wrote:
> I agree that significant changes should be reviewed first. But for the most
> part Cordova is a review-after-commit kind of place,
No, it's not. Cordova is only like that because you consistently make it
like that. Constantly committing
I agree that significant changes should be reviewed first. But for the most
part Cordova is a review-after-commit kind of place, and this change didn't
touch any code that we release (strictly tests... that have been broken for
a very long time), so I don't think it qualifies.
On Thu, Feb 12, 2015
You may or may not, but I think it would be nice to let others review your
(significant) changes before dumping them to master.
> On Feb 11, 2015, at 6:34 PM, Andrew Grieve wrote:
>
>> On Wed, Feb 11, 2015 at 5:00 PM, Jesse wrote:
>>
>> +1 Revert
>>
>> And please let's stop deleting what
Sorry for the scare. Maybe I wasn't clear, but I did not delete any failing
tests. I *fixed* the failing tests by having them wait on mutexes instead
of using Thread.sleep().
What I *did* delete:
- Duplicate tests
- Massive amounts of copy & paste (refactor from having one activity
per-test, to ha
On Wed, Feb 11, 2015 at 5:00 PM, Jesse wrote:
> +1 Revert
>
> And please let's stop deleting what other people wrote just because we
> don't recognize it. These things should require discussion.
>
Bit of a jump to conclusions, don't you think? What makes you think I don't
recognize the code I ch
I'm reverting this now, 37 tests with 4 failures is much better than roughy
20 tests with 0 failures. (I didn't run the refactored tests, since
there's no point if critical tests are missing).
On Wed Feb 11 2015 at 2:01:51 PM Jesse wrote:
> +1 Revert
>
> And please let's stop deleting what othe
I think there's a lot of value in the Unit Tests, having wrote the majority
of them initially. If I wasn't dealing with everyone in my house getting
sick, I'd check to make sure these tests were still testing what I intended
them to test, since we have a habit of losing the intent behind the test
+1 Revert
And please let's stop deleting what other people wrote just because we
don't recognize it. These things should require discussion.
@purplecabbage
risingj.com
On Wed, Feb 11, 2015 at 1:53 PM, Joe Bowser wrote:
> I think we should revert this refactor. With the new refactored tests,
>
I think we should revert this refactor. With the new refactored tests,
they may pass but we lost a lot of the useful tests that we once had and
these new tests have no value. I don't know why you took it upon yourself
to throw away all the JUnit tests that didn't pass, but that misses the
point.
Does travis provide Android emulators? I'd guess it'd be too slow to put on
Travis. And honestly, there's still not a lot of value in the unit tests
atm.
On Wed, Feb 11, 2015 at 3:12 PM, Murat Sutunc wrote:
> This is great news!
> I've finally got the android travis enabled too. We have jshint a
This is great news!
I've finally got the android travis enabled too. We have jshint and jasmine
test coverage on every commit now.
(https://travis-ci.org/apache/cordova-android/builds/50295748)
Now that we're passing all junit tests, I think the next step for us should be
to integrate junit t
16 matches
Mail list logo
