Meeting Minutes: February 16, 2014

Attendees

Mentors: Christian, David, Mike, Steven

Students: Anselina, Bhushan, Edwin, Joonas, Olessia, Mirai, Stephanie, Tomi, Tami

Excused: lines

Announcements

General

  • Thank you for a great weekend at the code sprint!
  • Gearing up for RB 2.0 beta 3 and RBTools 0.6, and each of you now has code going into one of both of those releases. Congrats!

Code reviews

  • We have a bunch of WIP review requests up. Each of you should do at least one code review for someone else this week. It doesn’t even have to be a review for one of your peers. You could review our code, or third-party contributors, but it’s probably the least resistance (and the most opportunity to give comments) on the WIP requests.

Round-robin

Anselina

  • Has been refactoring the code for her project, and needs to modify it a bit for the pre-receive hook.
  • Will resolve the issues raised in m_conley’s review.
  • Will have a new WIP up by the next meeting.

Bhushan

  • What he’s done is not ready to be committed, but can he just attach the incomplete file on the review request?
    m_conley: *Absolutely*. Even if your patch is just (in your opinion), garbage – it’s exploratory, or full of print/dump statements, or it’s just comments. That’s totally fine. It’s a WIP (work-in-progress) patch, and that’s expected. All we want to do is see where you’re at each week. And, if at this point, all you have is pencil sketches or broken code, that’s totally fine. Also, it’s not just a way of letting us know where you are – more than once, we’ve had a student’s harddrive go down during the semester, and they hadn’t been backing stuff up or pushing to a fork or anything. This is a way of making sure that your stuff is *somewhere*, and reasonably up to date. That way, even if your harddrive goes down, you’re at the most put a week behind.

Edwin

  • Has been figuring out what code is relevant, messing around with the front end and seeing what updates what on the front end side.
    ChipX86: It’s a large codebase, so if you’re lost for more than a day, hop in and we’ll help guide you. That also goes for if you’re not completely sure how to best implement something.
    m_conley: Everybody – this is a perfect WIP patch: https://reviews.reviewboard.org/r/5480/diff/# <– I see “Blah blah blah”, and “test test test”. This is totally fine. It’s not a thing we’d ever land, but it does a great job of telling us where you are and what you’re working on.

lines (Excused – mid-flight)

Joonas

  • m_conley: Saw that you and Mirai sent out your survey last week. How many responses have come in?
    bro1: Only 6 so far.
    ChipX86: Surveys are hard that way. I’ll try to help with that a little.
    m_conley: How many responses are you hoping to reach?
    bro1: 36 would be nice, but I’m thinking around 20 at the minimum.
    m_conley: I think we have to assume that we’re not going to have ~20 responses until several weeks in, if we’re lucky. Putting some pressure on one of those bugs you identified is a great idea.
    purple_cow: We’ll tweet the survey to try to get more responses.
  • Will focus on tablet usage, while Mirai works on smartphone usage.
  • Will tackle issue #3243.

Olessia

  • Worked on getting remote repository lists from Bitbucket, Beanstalk, and adding pagination to the GitHub implementation.
  • Re: m_conley’s review: the two cases are actually different – in one case (Bitbucket), we stop when there’s no key next in the response dict (because Bitbucket is nice and lets us know what/if there is a URL to query next). In Beanstalk’s case, we stop when we get an empty response because in the response dict we have no info of what/whether there is a next page. Will keep in mind what m_conley said and look closer at the issue.
    m_conley: Perhaps there’s a way of getting a count of the total pages/entries? I’m just worried about exit conditions.
    purple_cow: We can also talk to them if they’re missing it. They were super responsive to us when we’ve asked for APIs in the past.
    ChipX86: So, if they don’t have it, I suggest this: e-mail them, and tell them you’re working with the Review Board project as a student and are trying to add better support for their APIs. They’re friendly. You can also give them our e-mail addresses.
  • Could not see any repos in the Beanstalk account.
    ChipX86: You should be able to see them. I also set you as an admin about 15 mins ago. Make sure you’re on the beanbag account.
    Managed to see two repos afterwards.
  • What should she focus on this week?
    ChipX86: How about expanding the branches/commits fetching? This is for the New Review Request page. We have support for fetching that info for GitHub, but not other services. It’s also all part of the HostingService work (and any work done there could benefit people immediately in 2.0).

Mirai

  • While the survey responses are coming in, he will keep looking at the most severe issues that they found at the code sprint. Unfortunately hasn’t been able to do much besides the survey this week.
  • Will send in some review requests early next week.

Stephanie

  • Worked on getting the backend to save the positions of the widgets after the users move them around.
  • She hasn’t incorporated the code review suggestions yet.

Tomi

  • m_conley: Have you been getting useful information from the mailing lists?
    Yes, got some new ideas.
  • Seems that the workflows are quite different for bug trackers and HostingService class since everyone wants to have a different workflow.
    ChipX86: I think for now, we support the basic operations. API that can do things like post changes, query for information, etc.
  • Plans to make it configurable so that people can tie RB events to certain actions. 
    ChipX86: I’d love to see the design you have in mind when you’re ready to show it. Are you collecting this info on a Hackpad? That helps us keep track of it, ask questions inline, etc.

    purple_cow: Either there or a review request.
    Will export it to a Hackpad, and post some code soon. Had to create his development setup once again.
  • Currently, the bug tracker is just a text field in HostingService, but he is thinking of making it a class that does more complicated things.
    ChipX86: I think we want a new module (bugtrackers) that has its own set of classes. Right now, every repo/service needs to have its own bug tracker info. We can clear this up after the meeting – I can give you a braindump of how it all works.

Tami

  • There’s a lot of errors right now on her WIP patch, so she’s just working on sorting them out.
  • Settled on a tabs design.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s