Update:Lyz pointed out that the default config file that come with the CentOS packages on the Nginx website put root inside the location block instead of outside. She’s just helped me verify that and I verified the same problem with the Ubuntu packages from the Nginx website.
Please don’t rubber-stamp my reviews. Nitpick. Nitpick a lot.
When working with Open Source, some of the best learnings come from code reviews. When I first started coding on projects with strict code reviews Launchpad), I was uncomfortable getting nitpicked. I (wrongly) thought the goal was to have a code review that has absolutely no nitpicks (crazy right?). Whenever someone had a nitpick with my code, I felt like I couldn’t code properly. That’s when I read this excellent mail from Jeroen Vermeulen to the launchpad-dev team:
A rubber-stamp approval can save you minutes or more in the short term, but it does nothing for your longer-term development. A rubber-stamp approval leaves you without proof that the reviewer has read and understood the branch. A rubber-stamp approval sets no performance bar, no communicable standard for reviewers to live up to. A rubber-stamp approval does not tell you whether your branch was excellent, so-so, or too hard to read. A rubber-stamp approval buys you time that you could use towards the self-improvement you’re missing out on, but fails to tell you where you need it most. A rubber-stamp approval deprives you of a chance to harmonize your part of the codebase with our best practices. So I don’t like getting rubber-stamped any more than I like to rubber-stamp others. Good reviews take time, and that’s not time I put in for the sheer fun of it.
It changed my world. I’ve had epicnitpicky code reviews after that. Its even changing how I do my code reviews; I’m warming up to be more nitpicky. Lesson learnt – code reviews are one of the strongest takeaways from open source. So, if you’re reviewing code, please nitpick. Don’t rubber stamp. The professional development of the person whose code you’re reviewing depends on it!
User Days were created to be sets of classes offered during a one day period to teach the beginning or intermediate Ubuntu user the basics in order to get them started using Ubuntu. User Days were born out of a discussion at the Ubuntu Developers Summit in November 2009 regarding Ubuntu Open Week not being targeted enough at users. User Days is hosted over the weekend for many hours at a strech so everyone will be able to participate at some point. Open week, however, is hosted during the week at the fixed time-range.
This, however, is now changing. From this cycle on, Ubuntu Open Week will be targeted at users. As the organizers of User Days for the past 4 cycles, we’ve been wondering what the community thinks about this – Should we continue User Days or should we not. Please mark your opinion in a quick poll that I’ve created.
A while back, I wrote about smart autolinkifying in bugs. Last week, at the urging of Brian Murray, I built on top of the work that I’d already done. This time, it grabs all the bug links and sends to the linkchecker and, in addition to the set of invalid bugs, it also returns a set of valid bugs with bug titles! The after effect is a ‘bug 1245’ link in the body of Launchpad like in bug tracker, merge proposals, etc, where bug 1245 is a valid bug number will have its ‘title’ attribute set to the bug title.
I’ve been hacking on Launchpad for a while now and I’d like to announce some of the new things I’ve added. The first 2 are in production now. The last two, however, will need a few more days to get into production.
Smart autolinkifying in bugs
As evident from the screenshot, it greys out the bug if the bug does not exit (or is private). I wrote in detail about fixing this earlier.
UTC offset along with timezone
We now go the extra mile and display the UTC offset as well to help in some play plan out meetings, etc.
Edit sprite for attachments
Long time frustration of mine. The edit URL for attachments is in a portlet on the right side, not easy to spot. Once this fix rolls out, however, it will be much more friendlier.
Better blueprints validation
Earlier, I’d just get a ‘… is already registered by another blueprint’, this fix, once rolled out, helps ease out and find that blueprint.
To repeat again, the last two fixes are not in production as of me writing this post. Perhaps by next week or the week after, it should be.