- Reminder pencil down dates is December 4th, 2012. So blog posts and patches posted after this time will not be considered during your evaluation.
- Note that it’s possible that your code might be in a fine state to land, but we don’t land it. So, target getting stuff up on RB, and getting “Ship it’s” – not necessarily landing.
- John was absent for this meeting. Mentors were noticed in advance.
- If your school has additional requirements for you (papers, presentations, etc), make sure we’re aware of that. (Allyshia,Tahnok, michee, yangtina and jzamb have extra requirements).
Q:(yantina) Will it be helpful for the final review if we round up our work for the term and send an email to all the mentors with links to what we did? (reviewrequests(we posted or commented on), blog posts, link to presentation slide for this project etc)
A: We’ll be able to view your blog posts and review requests without difficulty. Your presentation / outer course-work isn’t something that we should be factoring into our evaluation. So you can include it for interests sake, but we won’t be factoring it in. Might be good blog fodder though and blog posts we *do* notice.
Q:(tahnok) I can’t seem to get buildbot to accept. It barfs when I try to submit a patch. https://gist.github.com/4383fa23b7163c26e373tahnok, mainly fatal: git apply: bad git-diff – inconsistent new filename on line 15.
Q(m_conley): And you can apply the diff without difficulty locally?
A(tahnok): Not sure, i didn’t try.
A(m_conley): ok, give that a shot – let’s see if we can remove BuildBot from the equation
Q(smacleod): Also, what command did you generate that patch using?
A(tahnok): git format-patch master –stdout > fix_empty_poster.patch. the line in question being — /dev/null. +++ b/bot/reviewbot/tools/builtbot.py
A(purple_cow): it looks like there’s actually several patches in that “patch”. probably because you had several commits
A(tahnok). Yeah, there was a bunch of commits. But I tried with single commits as well
A(m_conley): Alright, can you stick around after the meeting?
Q(slchen): How difficult is it to work with memcaching, anyone with more experience than I? just wondering to help prioritize tasks,
A: memcache is a pretty simple thing to use. what are you wanting to use it for?
A(slchen): ChipX86 mentioned that for the thumbnails projectm_conleyhttps://docs.djangoproject.com/en/dev/topics/cache/?from=olddocs#memcachedslchenthis morning I changed the parsing alg to read up to the first 2000 chars of a file.
A(purple_cow): The easiest way to use it from our code is the cache_memoize method
Q(slchen): Would you say it’s something I can learn and apply within an hour or so?
A(m_conley): cache_memoize is defined in djblets.util.misc. Some documentation in there you should read
A(purple_cow): basically you create a cache key that’s unique to your particular data. And then call cache_memoize with that key and the function that computes the data
Q(slchen): Does it update automatically?
A(purple_cow):If it’s in the cache, it will use that, otherwise it calls the function and stores it for the next time
Q(michee): Should I be concerned about making the image diffing too similar to what github does?
A(m_conley):I don’t think that should be a concern, no. In fact, there might be a lot to learn about their design. Prior art is sometimes a great place to start from and improve upon. And users get to inherit the familiarity, which is a bonus,
Q(michee): For the hard deadline, should we be posting code reviews by then or getting ship its by then?
A(m_conley): You should be getting to the ship-it state for the hard deadline.Though, a reminder – you are absolutely *absolutely* welcome to keep hacking on your project after the deadline passes.
A(purple_cow): we’ll still take into account anything that’s posted, but putting up new stuff right before the deadline won’t get as much of a look from us because we’ll be busy writing the evals.
Q(Karl-L): I want to issue a gentle reminder that I’m still in need of some pointers on r/3488. ChipX86 has been doing most of the reviewing for my project specific code, so I’m fine to wait for him to return from vacation if he’s the best person to look at it.
A(mike_conley): I’ll take a peek after the meeting, after we tackle tahnok’s problem
Q(Allyshia): As per the questions that ChipX86 raised regarding the reviewbot manual trigger mockups, can I have a quick confirmation of why we chose to go with the implementation of manual trigger in the first place, to be sure? What are the needs we are addressing, what use cases are we covering.
A(smacleod): We have automatic, and there could be cases of tools we don’t want to automatically trigger, but would still like the option of using. I’ll use r.rb.org as an example: Anyone can post code, so if we automatically trigger say, a builbot plugin, for every review. It could allow people to just run arbitrary code through our buildbot. Thus, manual triggering with permissions seems like a good option to have
Q(Allyshia): Conceptually speaking the manual trigger in itself is not an extension, correct?
A(smacleod): Reminds me of a gotcha -> Not sure how extensions can create and manage permissions. The manual trigger is part of the Review Bot extension not its own. I think we need a more lengthy discussion on the topic, so yeah, lets postpone that to outside the meeting
Q(Amiir): Just want to say that I took r/3434 out of WIP. would be great if someone could look at it so I can fix any issues or get a Ship-It
A(m_conley): Awesome,can do.
Q(m_conley): How is the Lightbox stuff going?
A(Amiir): it’s going well. I pushed a WIP for review yesterday. It’s currently using modalBox
A(m_conley): excellent. Sounds like a good place to start