Author Archives: nh2reviewboard

Status Reports: Mar 1, 2013

Yuri Honami

CURRENT

  • [accounts/managers.py]
    • add some code to user_page.html for show all trophies(review request ID) stored in the database.
    • keep Hiroki’s model up to date. 2013-02-27.
    • call the compute_user_all_trophies, which is func of [accounts/managers.py], when user access user_page.html.(see view.py)
    • move JSONField from LocalSiteProfile class to Profile class.

ROADBLOCKS

  • UNIT TEST!!

NEXT

  • try to write unit test.

QUESTIONS

  • none

Hiroki Gohara

CURRENT

ROADBLOCKS

  • I don’t have ideas how to improve Trophy case next.

NEXT

  • Didn’t decide yet

QUESTIONS

  • How should I do next?

Surya Nallu

CURRENT

  • Added spinners during installation/search; ability to provide/see screenshots for an extension and compatibility information for an extension.
  • Pre-installation check for dependencies on the environment. Proceed with installation only if all dependencies are okay or warn about missing ones.
  • Fire up a confirmation for installation and in doing so, show any terms/prerequisite information needed to know. Install, only if confirmed.

ROADBLOCKS

  • none

NEXT

  • Discussed with ChipX86 and m_conley on what my next steps should be:
  • Fix some UI/usability issues pointed out (see: http://pastie.org/private/tnpp7yu06m4nsn8b6iydrq for the suggestions).
  • Add category information to an extension. Furthermore the categories can be used for browsing extensions on the search interface.
  • Look/play with other stores (such as Mozilla’s, WordPress’, iStore) and come up with new tasks for the weeks ahead.

QUESTIONS

  • none

Jon Demelo

CURRENT

  • Addressed first round of required adjustments for the Depends On review request.

ROADBLOCKS

  • Did not have a lot of time this week, as expected, due to it being my midterm week for my other classes.

NEXT

  • Once these midterms are out of the way, I’ll follow up on any final changes to my review request, and then move on to my next project, which will be determined based off the meeting suggestions and how I feel I can do my best work.

QUESTIONS

  • none

Greg Wang

CURRENT

  • Add rich_text field for `BaseReviewRequestDetails` in db evolution script.
  • Switch to use `Marked` + `Google Code Prettify` js libs to render Markdown

ROADBLOCKS

  • Jumping is quite an issue when using JavaScript to render the text
  • Really want to settle with one way of rendering (JS user-end / Python Server-end)

NEXT

  • Try more JS/Python markdown libraries and collect info…
  • Try solve the anchor related issue with `marked`
  • Adjust the css style for markdown text

QUESTIONS

  • Any suggestions on the Markdown stylesheet? Github style? or RB has their own style?

Katherine Schramm

CURRENT

  • working on a Review DataGrid still

ROADBLOCKS

  • other classes (I ended up dropping one class this week and a deadline just passed in another, so things should lighten up for a while)

NEXT

  • other classes (I ended up dropping one class this week and a deadline just passed in another, so things should lighten up for a while)

QUESTIONS

  • none

Niklas Hambüchen

CURRENT

  • Did massive test refactoring for #3837 (RR open)
  • Fixed –revision-range as planned (RR open)

ROADBLOCKS

  • Need somebody to review my 400 lines refactoring (easy but daunting)

NEXT

  • local git clone HOWTO as discussed

QUESTIONS

  • How should I test my change to rbtools?
Advertisements

Meeting Minutes for Group A – February 17th, 2013

Announcements

  • Mike: Status reports didn’t work well this week. Reasons:
  • – Gabriel dropped the course in the middle of collecting them.
  • – Only a few were sent to the mailing list.
  • Mike emphasizes we should keep an eye on the calendar. https://reviewboardstudents.wordpress.com/calendar/
  • Mike announces: This week is great to post [WIP] code, even if it’s broken.
  • ChipX86 announces: There are now 2 unit test suites, one for Python and one for JS. The JS one is at http://localhost:8080/js-tests/. He also mentions everyone should get familar with writing unit tests.

Notes

  • All expected people are present.
  • Niklas asks about RR editing permissions set for users which don’t become visible; we agree to figure it out after the meeting.
  • Niklas also asks if somebody can explain how post-review –revsion-range works on SVN, also after meeting.
  • Concerning Markdown integration, ChipX86 thinks there’s far too much focus on making all this optional (settings, extensions). He suggests a single flag setting if comments, descriptions and so on are “rich” or not, default false.
  • We need database evolution for this, ChipX86 suggests to add a column to all things, setting markdown=false for existing posts. Greg argues that this might add a lot of data; the consensus is that this extra data is quite small in comparison and space is cheap.
  • It is agreed that we need a boolean per post to say if it was created with Markdown or not. ChipX86 suggests that users should not be able to toggle Markdown per post – everything new shall be Markdown.
  • smacleod asks if this should go in review-requests’ “extra_data”; ChipX86 finds it harder to manage and not easy to populate with a default.
  • ChipX86 mentions that for Markdown previews, there is http://code.google.com/p/pagedown/wiki/PageDown. Greg has already looked at it and tries to integrate it. ChipX86 also mentions to consider markdown2 on the Python side, Niklas mentions Github-flavoured Markdown being a good fit for dealing with code, but it’s unclear so far if there is a JS library for previews.
  • We agree that with client-side only JS Markdown rendering, we must pay attention to not make the content jump when text is being rendered as Markdown (alternatives are spinners to wait until rendering is done).
  • Felix says he feels awkward with Django and suggests going through the Django tutorial before starting work. Mike says that we shall try to get Felix’s setup run as soon as possible, and that he shall ping as soon as there are difficulties.
  • Surya posts 4 minute video about the extension browser he made (http://www.youtube.com/watch?v=Xvntl7ksjPA&hd=1). We agree on that this is awesome.

– Q (Katkat): Working on ReviewRequestDataGrid, question: Is this meant to be just a list of the review requests the user has done reviews for, or should it include data on the reviews themselves too (like the date the review was submitted or something)?

A: A good start is just listing the reviews that a user has written. Might be a good idea to brainstorm some interesting columns we can add too. Other suggestions: the date it was submitted, how many issues were opened, whether or not they gave a ship-it, if any issues are still unresolved.

Student blog post: Niklas @ Reviewboard

Hey, I’m Niklas, a third-year Computing student from Imperial College London, and on one of the group of students working on ReviewBoard this winter as part of the Open source, project-based, collaborative university curriculum organized by Facebook.

The goal of this industry-sponsored, cross-university project is to allow Computing students from around the world to make collaboration in a widely used open-source project part of their degree. While in a normal Computing course you would usually theory, work on practice problems set by academics, and write an exam in the end, this course is different: You work on a real-world product, probably used by thousands of individuals or companies.

The course started off as a 2-day Hackathon at Facebook’s office in Palo Alto in mid-January, and continues to run over the next few months, according to each student’s university timetable.

While the course does not count as a for-credit module at my uni and I’m therfore participating for the fun and the experience, I think it is a great idea, and I find that something like this should be part of every Computing degree.

My part in Reviewboard this Winter

I had used Reviewboard before, and I found it quite good, but not perfect, which is why I picked it as one of my favorite projects to work on.

The starting-off hackathon was great as both a free-time activity and a learning experience.

I met Mike, Christian, David and Steven from the ReviewBoard team, and from their experience of ReviewBoard’s deployment in the companies they work for as well as in others, I could get a good insight on what ReviewBoard aims at, what users expect, and what development is focused on.

On the technical side, I could also exchange some experiences about Git workflows, and from our mentors I could learn about what it is like for them to work part-time on an open-source project while also working at companies where a lot of time is spent on writing open-source software.

Getting started

To get into the project, my first contributions were fixing an error that occurs when you try to access properties of a review request that doesn’t exist and [making sure that the “add comment” button is only shown when you are logged in. I also got into how tests are written for ReviewBoard.

What I’m focusing on

When I first tried out ReviewBoard in 2012, I found that some workflows are harder than I expected them to be, especially for small, flexible teams without fixed policies, such as a project group of students or a small open-source team.

I will therefore spend the rest of the term on this: Making ReviewBoard easier for small teams.

What originally annoyed me most is that after rising an issue about some piece of code, I was unable to declare the issue as fixed myself; it always required an additional roundtrip, summoning up the person who originally wrote the code and posted the review request, even for issues that are obviously fixed. So I implemented that comment creators can now fix/drop issues themselves. It took me quite a bit to figure out what the control flow for the fixing of issues was, but in return I now have a better understanding about how ReviewBoard webapi requests are handled.

One thing I would wish for the project to have is a simpler way of testing, especially something I would call “testing primitives”. For testing my change above, I have to control two users at the same time, create a review request, create a file review and create an issue n that file review, and only *then* I can test if what I’m interested in actually works: Closing the issue. The steps before that are mainly preparatory steps, but I still have to execute them quite technically, crafting the webapi calls by hand. I don’t go as far as asking for something like Cucumber, but I would prefer to write these steps with primitives like this instead:

    u1 = give_me_whatever_arbitrary_user()
    u2 = give_me_whatever_arbitrary_user()
    r = make_arbitrary_file_review(user=u1)
    issue = open_some_issue_on(r, user=u2)

    # And now the actual testing code to see if u2 can close the issue themselves

Here, I don’t really care what the contents of the file review or the text of the issue are, I just want *some*, and I would like to get them automatically, without thinking about it, so that I can write tests in a way as easy as above.

Maybe we can set up something like this?

When I done with this, I will have a look on whether I can improve the command line tool that submits code changes, making it a bit easier for the cases I’m especially interested in.

Going on

So far, I’ve enjoyed working on ReviewBoard; if you want to get into contributing to open-source software, it’s a good place to join.