search

saxifrage / cityasacampus

An open-source platform for connecting and showcasing resources within local learning communities.
http://cityasacampus.org/
5 stars 4 forks source link

2015-12-01 CaaC Standup #362

Closed MatthewVita closed 8 years ago

MatthewVita commented 8 years ago

previous standup: https://github.com/saxifrage/cityasacampus/issues/353

What I accomplished last week:

What I intend to do this week:

Obstacles that are impeding my progress:

Favorite holiday song

December availability

chadwhitacre commented 8 years ago

last week:

this week:

blockers:

song:

December:

dmtroyer commented 8 years ago

Last week:

This week:

Blockers:

Favorite Holiday Piece:

December:

chadwhitacre commented 8 years ago

Favorite holiday song

I suppose I missed an opportunity to pick something by the Grateful Dead. :-P

chadwhitacre commented 8 years ago

Since I wasn't able to come into the office today, I just called @timothyfcook on the phone. The impression I get is that we need to start bringing this project in for a landing. It seems that the "golden spike" will be when the Rails app is connected to the CaaC Map, so I'm going to turn my attention to that.

chadwhitacre commented 8 years ago

/me dives in on #255 and #227 ...

chadwhitacre commented 8 years ago

and #201 ... :swimmer:

dmtroyer commented 8 years ago

@whit537 just to confirm, you're doing #227 and #201 on the angular side, right?

dmtroyer commented 8 years ago

@whit537 @MatthewVita could I kindly request that merges to master be squashed first into more tangible feature groupings? Maybe one commit for a whole PR? I'm having some rebase issues and it makes it much more difficult to resolve them when I have no idea where the Heroku changes started, for example.

chadwhitacre commented 8 years ago

could I kindly request that merges to master be squashed first into more tangible feature groupings? Maybe one commit for a whole PR?

Okay.

I'm having some rebase issues and it makes it much more difficult to resolve them when I have no idea where the Heroku changes started, for example.

Does the commit list for the PR help?

chadwhitacre commented 8 years ago

@whit537 just to confirm, you're doing #227 and #201 on the angular side, right?

Yeah, I'll branch from token-auth (#357).

chadwhitacre commented 8 years ago

I've toggled Travis to only build when .travis.yml is present. This will prevent the noisy build failures we're seeing on PRs since #361 hasn't landed yet, without hampering work on #361 itself.

screen shot 2015-12-04 at 5 10 27 pm

dmtroyer commented 8 years ago

I've toggled Travis to only build when .travis.yml is present. This will prevent the noisy build failures we're seeing on PRs since #361 hasn't landed yet, without hampering work on #361 itself.

Thank you @whit537 !

dmtroyer commented 8 years ago

Does the commit list for the PR help?

Yes, it did! @whit537 Sorry to be such a grump.

MatthewVita commented 8 years ago

Yes, it did! @whit537 Sorry to be such a grump.

{aside} This is something I struggle with. I like to commit early/often along the way describing what the heck I'm doing but when merging feature xyz branch into master/main/trunk/etc, I don't know if squashing everything into a "adds feature xyz" commit is best or if keeping all of the commits help to "tell a story" in some way. I've seen it done both ways at my job and with other OSS projects. Anyways... {aside}

dmtroyer commented 8 years ago

This is something I struggle with. I like to commit early/often along the way describing what the heck I'm doing but when merging feature xyz branch into master/main/trunk/etc, I don't know if squashing everything into a "adds feature xyz" commit is best or if keeping all of the commits help to "tell a story" in some way. I've seen it done both ways at my job and with other OSS projects. Anyways...

The more I think about it, either way or both works for me. The tools are there to do what I was trying to do (diff before and after heroku), I was just having a crotchety knee-jerk reaction to the situation.

chadwhitacre commented 8 years ago

I was just having a crotchety knee-jerk reaction to the situation.

:relaxed:

I've seen it done both ways at my job and with other OSS projects.

Ditto. Seems that squashing is a little more work at merge time for less work when reading history later on. I generally find that I merge PRs much more frequently than I read history, and consequently have preferred to optimize that step (i.e., by not squashing commits). I tend to view commit squashing as a sign of a mature, stable project, largely because a couple years ago I learned that jQuery maintains an extremely clean history:

screen shot 2013-09-02 at 11 33 41 pm

On the other hand, I learned in the same conversation that GitHub doesn't. :shrug:

keeping all of the commits help to "tell a story" in some way

GitHub keeps all the old commits around even after a rebase-n-squash. If after rebasing you reference the previous head and/or the list of commits, then someone who wants to see the detailed story of the PR is still more or less able to. Here's a recent example.

I've actually never worked regularly on a project that observes commit squashing, so I'd be fine to try it out here, especially if we can observe the practice of linking to the previous commits list as a way to preserve full history.

MatthewVita commented 8 years ago

Thanks for the thoughts.

I realize that GitHub keeps old commits around, it's just not very visible is my issue.

Anyways, let's try the squashing moving forward for this project. We'll just have to try and keep our PRs small.