Author Archives: elcurto99

Meeting Minutes for March 24th, 2012

Announcements:

  • Review Board has been listed as one of the participating organizations in the Google Summer of Code 2012. Applications will be taken starting Monday, March 26th.

Wilson

  • Busy, but working on Weekly Headlines.
  • Will get it working in the terminal first, then convert the output to email format.

Yazan

  • Roadblock is cleared.
  • Yazan should update the CSS for in-progress reviews.

Curtis

  • Christian’s changes went integrated smoothly into r2810.
  • Mike would like to see a a work in progress update for the rating extension. Curtis will post something before the next meeting.

Willer

  • Having some trouble making the wire frames for the submitters, currently using MS Paint, cant get the spacing right. Mike will help with this after the meeting.
  • Mike will offer some guidance on r2828 after the meeting.
  • Not sure if it is realistic to finish issue 829.

Dave

  • Still needs a review on r2918.
  • Would like to find out more about JS event binding.
  • The element has to be made “draggable” to use onselectstart binding. This makes it physically drag around with the mouse.
  • “select” is the best candidate for an event to bind.

Jim

  • Needs a review on r3001.
  • Publishing a discarded review request will reopen it. Submitted review requests will be reopened/updated.
  • Needs a review on r2966, specifically diffutils.py.
  • Would like to discuss r3000 with Christian when he is available.
  • Will be looking for something to do for the last week. Will either consider making a screen-cast, or go through the issue tracker for small bugs/enhancements to implement.

Steven

  • Will file an issue for a when a draft is in the review request list, but can’t be published.
  • For reviewbot, I want a non-blocking way to execute code analysis after receiving the request. Also looking for opinions on how to do this.
  • Celery is the recommended way to accomplish this.
  • Reviewbot should just be restricted to only the files that were changed.
  • The scope of the reviewbot project is too big, and Steven wont be able to have a fully functioning review bot to the initial standards he had hoped.
  • Webhooks extension is close, code reviews on it would be beneficial.

Anthony

  • Received a code review, no longer blocked on that, and can move forward and make changes.
  • Not sure what to do for the full-file review project, due to the time limitations. Might be able to finish the project after the deadline/exams.
Advertisements

Status Reports – March 17, 2012

Anthony

Status
  • Started to add a framework to deal with file attachments according to their mimetype.
Next steps
  • Continue working on this framework.
  • Start work on the full-file review.
Roadblocks
  • Questions: Should administrators be able to extend this framework to handle additional mimetypes without modifying the reviewboard code?
  • What sort of thumbnails can be expected outside of image mimetypes?

Steven

Status
Next steps
  • Finish extension documentation
  • Finish up WebHooks now that extension upgrades are committed
Roadblocks
  • None

Jim

Status
  • Finally close to getting description diff rendering done. Will post the review once my vm is working
  • the inter-diffs are not show as it should. currently investigating and fixing CSS properies
  • Need reviews on my code.
Next steps
  • Finish my current project
Roadblocks
  • None

Yazan

Status
  • Waiting on feedback for r2881
  • Waiting on feedback for r2964 (Will post once roadblock is resolved)
  • Working on incremental expansion
Next steps
  • Make changes according to feedback
Roadblocks
  • htdocs/rb/static folder is ignored by git, not sure where to edit my CSS.

Dave

Status
  • Submitted review request for next version of capabilities
Next steps
  • Finish capabilities, start next project
Roadblocks
  • None

Curtis

Status
  • Worked on the backend for the rating extension
  • Feeling defeated regarding .select_related() on r2810
Next steps
  • Get the backend of the rating extension working.
  • Move on to front end after it is tested and working
Roadblocks
  • r2810 show_related(), I feel like I know how it should work, but I can’t get it working.

Wilson

Status
  • conceptually mapped solution for r2828
  • conceptually mapped solution for bug 829
    (conceptual because my git is failing)
Next steps
  • fix missed bug in r2828
  • start coding bug 829
Roadblocks
  • git

Wei

Status
  • Posted some starting code to r/2959 about Weekly Headlines
Next steps
  • Continue working on r2959
  • Finish testing r/2891
Roadblocks
  • Need specific requirements for Weekly Headlines
  • Had bugs when running unit test on fresh copy

UCOSP Blog Post – February 13, 2012

We all know Review Board is great for allowing a distributed team to effectively ensure only high quality, standards complaint code is integrated into the end product. But what else makes Review Board great?

From my experiences on the team I can safely say it gives new developers a leg up on the learning curve when starting. I was able to leverage Review Board to quickly learn exactly what  I should, and should not be doing in my code. Through each new code review I was determined not to repeat the same mistakes that were made in my previous review. The intuitive review interface clearly communicates these mistakes back to the developer, allowing them to make the changes and learn from their mistakes.

Review Board also acts as an effective communication platform for any distributed team utilizing it, as it allows the entire team to see the progress of each component, and add their own input to how the end solution should look. This is very important, as communication is one of the toughest aspects when working with a team not based in one site.

I started off in the Code Sprint by getting my feet wet with a couple bugs and a small project. Due to the fact that I haven’t used Django recently, and that the Review Board code base itself is quite large and complex this meant I was in for quite a steep learning curve. I have now moved on to my second project, which itself comes in two parts. The code based part of the project is a rating extension which will allow users to leave anonymous feedback on the quality of the code reviews they receive, while also tracking their own aggregated results over a period of time. These results will allow users to reflect on their code reviewing habits, and make improvements if necessary. This project will be leveraging brand new scripts to simplify the extension building process, by tempting out the base code required for an extension to exist in a Review Board instance.

The second half of this project will involve writing documentation to guide others using these scripts on how to take their extension stub and turn it into a functional and integrated part of their Review Board environment. A lot of developers get the idea that by adding this “one feature” to the project, it will vastly improve their experience using Review Board. This has many problems however, because if every one of these features are added they will start to bloat the code base, making Review Board run slower and harder to maintain. This also requires developer hours, which could be spent working on other features which would benefit more than just a handful of developers. Adding this “one feature” also runs the risk of alienating other developers with features or functionality they don’t need, want, or understand. The great thing about extensions is that they allow these developers requesting the feature to easily create and add the feature to their own instance of Review Board, without impacting everyone else’s experience.

It’s great to be able to work on such a far reaching project like Review Board, and know my improvements are being used all across the world. The project could not be nearly as successful without the big effort put in by each of the mentors. Their ability to offer prompt code reviews, technical guidance, and project ideas really makes working on Review Board a lot of fun. Due to their efforts, more time is spent in the learning or “eureka” phases of development than stuck in a frustrating roadblock.

Minutes for January 28, 2012

Everyone went over which projects they have selected. Dave chose the Diff Viewer Project. Steve will be working on the Static Analysis Extension. Anthony will be tackling the Extension Scaffold Generator. Yazan has not selected any of the projects listed, needs approval from his list of project ideas to pursue. Jim is working on Better Change Description Rendering. Curtis is working on Interdiffs at the moment, and will be starting Reviewer Feedback designs for next week. Wilson is working on Issue 2282. Wei has submitted Review 2818, but still needs a project.

  • Jim needed better clarification on his project. The discussion will be taken offline to cover it in detail.
  • Dave’s only blocking issue was resolved by Christian.
  • Steve has a question about his extension design, if it (PEP8 extension) should extend the base extension or talk to it. Further discussion will be taken offline.
  • Anthony needs to make a new review request for his code review, as it is in a different repository. His extension scaffolding script will need continued polish after some feedback from developers (Curtis and Steve) have used it.
  • Yazan will start by adding required flags on fields which are required before a review is submitted. He will also be looking into uplifting the issue table, and writing some failing tests for dashboard counters. Yazan also has all the pictures from the code sprint.
  • Curtis is investigating custom template tags and is looking for a more elegant solution to determining the enumeration of a diff. He will have some mockups for the reviewboard-social extension ready for next week.
  • Wilson will post his progress up on Review Board, after he receives a quick walk through on the post-review process. He will also be learning more HTML and Django.
  • Wei can update his code review and check off issues once they are fixed. He will be taking on Jacob’s project from laster semester, Tracking User Changes.
  • Development issues can be posted to the review-dev mailing list instead of the UCOSP list. As always, you can post in #reviewboard-students if you need any help.

The next meeting is on February 4th, 2012. Wei will be collecting status reports and Jim will be taking meeting minutes.

February 4th – status reports: Wei Lu, minutes: Jim

Curtis: Winter 2012 Development Plans

Accomplished:

  • Fixed issue 1252 and the changes were pulled into master this past Friday.
  • Merged in feature request changes from issue 2271, changes are currently waiting to be pulled into master.

Plans:

  • Currently tackling a small project to show the incremental changes when a new diff is uploaded for code review. A solution is available for code review, however I am not satisfied with this work-around approach. I believe there is a better way to get the diff number, it would be nice if someone could work through the code with me and help identify its source.
  • I will be tackling an extension that will allow you to review a code review.  A likely name for this will be reviewboard-social. It looks like I will be working closely with Anthony and Steve to gain their extension knowledge.
  • I have been investigating into the OpenID Authentication emhancement, as it seems interesting. It seems this could be made much easier with the django-social-auth.

It was great meeting everybody. I hope you all enjoyed visiting Vancouver.

 

Curtis