History

BugMashPostMortem

Technical

  • Bot should not hand out tickets that are resolved, committed, wontfix, or duplicate status, whether they're tagged BugMash or not
  • Bot should support !work and !status on any ticket, not just flagged ones
  • Need a queue of things waiting for core attention/commit
  • Should set a maximum number of +1/-1 and verified/not-reproducible somehow, so people don't keep looking at the same tickets
  • More integration between bot & scoreboard?
  • Should we have more tags? bugmash, bugmashfinished, bugmashwaitingforcore?
  • Bot needs to be less random with its randomization - should hand out from a persistent random-ordered queue to minimize seeing the same things over and over. Need to modify the queue on the fly though because we added and subtracted tickets over the course of the bugmash.
  • User registration?
  • Scoreboard should (more prominently) link back to wiki, main RailsBridge.org, Paypal button. We missed opportunities to promote & recruit for RailsBridge.
  • Bot should have a "!help 2345" or "!stuck 2345" so you can alert someone that you need help
  • Bot should have a "!me" to see what you are assigned to right now.
  • Should provide stats other than points like LOC committed
  • Allow people to set up teams for scoreboard
  • Bot should have a "!review 2345" to ask someone to review a patch (work with the bugmashwaitingforcore tag above)
  • We might want to depart from the strict lottery for some prizes - most points, something just for new contributors (first time to rails)...
  • on the above: maybe we can use this event to "handicap" participants and put them in pools/groups. each group has its own set of prizes. of course we wouldn't restrict anyone to any group. they should be able to be in any one they want. the hook is that the tougher pool/groups/brackets have better prizes/prestige. We could also have a "rookies" group for first timers so they aren't trampled.
  • along with the bot & scoreboard we should also monitor the CI server to make sure nothing is broken.
  • It would be a good idea for the bot to keep a log of the IRC channel for the duration of the bugmash
  • we could tie the bugmash site into the rails CI to track build status and flag any new emergencies - either by scraping ci.rubyonrails.org or by adding an email to the CI site's notifier list
  • need to get the badge working (something similar to Dr Nic's GitHub badges http://github.com/drnic/github-badges/tree/master. This means we'll have to keep event history.

docs (git, rails, etc.)

  • We need a set of basic explanation about tools that people can use in the Mash such as "rake dev" and other instructions: how to access the repo's rails bin.
  • Document useful stuff like 'rake mysql:rebuild_databases` and `rake dev`
  • Need to have some instructions on handling branching, rebasing, patching the right branch, etc etc...captured this from #railsbridge as a reminder:
  • Need to set clearer expectations for 2-3-stable vs master
  • we should emphasize testing on pg + sqlite + mysql if touching AR

bitsweat: regarding https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1218
[3:47pm] bitsweat: the master patch demonstrates something you should NOT do when porting other ppls commits
[3:47pm] bitsweat: it changes the authorship and collapses the other commits into one
[3:47pm] bitsweat: not sure how to explain this in guide form...
[3:47pm] bitsweat: need to cherry-pick the 2-3-stable commits to master and get them working, then apply any of your own commits separately
[3:47pm] bitsweat: then format-patch them all together
[3:48pm] Politoed: I see
[3:48pm] Politoed: but the 2-3-stable patch may not apply to master, right?
[3:48pm] bitsweat: right
[3:49pm] bitsweat: when you cherry-pick to master, you can resolve conflicts
[3:49pm] bitsweat: Politoed: then commit the result while maintaining the original author and commit message
[3:49pm] bitsweat: the git message when a cherry-pick fails describes what to do
[3:49pm] bitsweat: you git commit -c <the cherry-picked revision>
[3:50pm] bitsweat: to preserve the commit info
[3:51pm] bitsweat: Politoed: your 2-3-stable patch there is exactly how it should work... :)
[3:51pm] bitsweat: you applied the previous patch, then yours, then format-patched

  • Also:

bitsweat: anyone know how to increase git's rename limit?
[4:10pm] eostrom: bitsweat: http://kerneltrap.org/mailarchive/git/2008/4/26/1610414
[4:11pm] bitsweat: this makes merging and cherry-picking between master/2-3-stable more reliable
[4:11pm] bitsweat: since it can track more renames rather than failing with a conflict
bitsweat: git config --global merge.renameLimit 0

  • From Josh Nichols (aka technicalpickles):

Jeremy Kemper mentioned how to get patches to leave behind details
when a patch doesn't apply, git apply --reject, which leaves .rej
files around.

  • From Dan Croak:

I didn't look at any documentation. Contributing to Rails or anything.

I'm lazy, like everyone else. I need one page, a cheat sheet, colorful
and well-designed, where I can figure out what to do. Maybe a section
for git branches, one for git patching, patch applying, etc.

Contact Amy Hoy to do something like this?

http://slash7.com/articles/2006/10/8/rjs-demistified-with-pretty-colors

misc.

Also available in: HTML TXT