Reviews are hard

It’s a vast subject, but one thing is certain: reviewing other people’s code is hard. Because good mentoring require technical and non-technical skills (such as patience).

I would like to dive directly into a specific detail of code reviews. It’s an iterative process: author submits code for review, reviewer make suggestions, author amends or pushes more code, reviewer make different or more suggestions, and so on.

In Git, « more code » takes the form or one or more commits appended to the Pull Request (or Merge Request if you use Gitlab, for simplicity I’ll just use « Pull Request » in this piece). And « amended code » means overwriting existing commits and force-pushing, which makes the old commits disappear.

As a reviewer, it can be very annoying because what I first look for in an update is whether my suggestions have been implemented or not, and how. That’s why authors are sometimes encouraged to push new commits in their Pull Requests and never overwrite existing ones. It makes the reviewer’s job way easier, because the UI can just show the new commit and they’ll know what’s changed.

But having this policy has drawbacks. When the Pull Request is merged (by fast-forward or not) in can leave awkward commits in the history, like « implement suggestions », « fix according to review », « review fixes again », etc… And merging the PR by squashing it isn’t always relevant, sometimes I do want to have several commits, because they address different parts of the problem.

How can we solve this? Well, it would be nice if I could see the difference between the current state and the last time I reviewed regardless of whether the author has amended their commit or not. And for that, I need to have a local copy of that commit. Fortunately that’s one of the things that git is very good at: you just make a local branch that tracks the PR’s branch, and when the code is changed you make another one. And then you can diff between those branches and see what changed.

OK, sounds simple enough. I have an itch, let me scratch it.

I present you git-pr-branch! A « small » utility that will create branches from Pull Requests, and do a few things with them. You’ll be able to automatically create the PR-based branches that I just explained about. You’ll also be able to display a nice listing of the branches, their associated PR, the PR status (open or closed), and the PR URL to clickety click. And since this can end up in quite a lot of branches, there’s also a sub-command to clean all that up, and delete branches whose PR is closed.

Ironically, it’s hosted on Gitlab but at the moment it only works on Github and Pagure. I’ll add Gitlab support if I end up working more with Gitlab (something tells me it’s likely to happen in the near future), but you can also send me a patch if you want it sooner.

While writing this side project, I discovered the fantastic python library attrs. It’s really awesome, I encourage you to try it out. (as always, my side projects are a good opportunity to try out new libraries or frameworks that I discover 😉 )

The python packages are on PyPI, and for the lazy Fedora and Mageia users out there I’ve made a COPR repository that you can enable on Fedora 32 and Mageia 7. Once installed, just run git-pr-branch (or git pr-branch) to discover the available commands.

Feel free to tell me what you think of the tool. Do you like the idea? Are you going to use it in your reviewer workflow? Did I bother writing code again when there is an obvious and better tool to do it? Let me know! 🙂

[EDIT] I’ve made a COPR repo, added the link.
[EDIT2] It now works with Pagure too, added the reference.

My experience of Flock 2017

Flock, the annual Fedora contributor’s conference, is now over. It took place in Cape Cod this year (near Boston, MA), and it was great once again.

It started with a keynote by our project leader Matt, who insisted on Fedora’s place in the diffusion of innovation. We are targeting the inovators and the early adopters, right until the « chasm » (or « tipping point ») before the early majority adoption. This means 2 things:

  • on one side, we must not be so bleeding edge that we would only reach the innovators
  • on the other side, we must keep innovating constantly, otherwise we’re not relevant to our targeted people anymore.

As a consequence, we must not be afraid to break things sometimes, if that’s serving the purpose of innovation.

A lot of the talks and workshops were about two aspects of the distribution that are under heavy development right now:

  • modularity: the possibility of having different layers of the distribution moving at different speed, for exemple an almost static base system with a frequently updated web stack on top of it.
  • continuous integration: the possibility of automatically running distro-wide tests as soon as a change is introduced in a package, to detect breakage early rather than in an alpha or beta phase.

Seeing where the distribution is going is always interesting, not only in itself but also because it reveals where my contributions would be most useful.

As always, Flock is an opportunity for me to meet and talk to the people I work with all year long, to share opinions and have hallway talks on where our different projects are going (I had very interesting discussions with Jeremy Cline about fedmsg, for example), and to learn the new tools that all the cool kids are using and may make my workflow easier and more productive.

It’s also a great opportunity to help friends on things I can do, and to share knowledge. This year was the first one when I didn’t give a talk about HyperKitty, I guess that means it’s now mainstream 🙂

Instead, I gave a workshop on Fedora Hubs, our collaboration center for the Fedora community. If you don’t know what Fedora Hubs is, I suggest you check out Mizmo’s blogpost and Hubs’ project page. The purpose of the workshop was to teach attendees how to write a basic but useful widget in Fedora Hubs. I wrote all the workshop as an online tutorial, for multiple reasons:

  • People can go through it at their own pace
  • My time is freed up to walk between the trainees, answer their questions and help them directly
  • Attendees can go back to it after Flock if they need to or if they haven’t completed it in time
  • It can be re-used outside of Flock (for exemple, by you right now 😉 )

I believe it’s a better way to teach people (see Khan Academy founder’s talk on TED): the teacher’s time is better used answering questions and having direct interactions with attendees, rather than at doing non-interactive things like talking.

There were about 10 people in the workshop, and 4 of them completed the tutorial in time, which is pretty good considering the conditions (other talks and workshops going on at the same time, bandwidth problems, etc.)

Also, I’m getting more and more interested in the teaching / mentoring aspect of software engineering. I like to do it, and I get good feedback when I do. That’s clearly a path to explore for me, although it’s still a bit stressful (but that’s usually a good sign, it means I’m taking it seriously). I don’t want to switch to that entirely, but having some more on my workplate would be nice, I think. The Outreachy program is very appealing to me, it would align perfectly with my other social commitments. I remember there’s also an NGO that offers software training for refugees in Paris, I’ll investigate that too.

 

The workshop on Fedora Hubs at Flock 2017 will be awesome

TL;DR: come to the Hubs workshop at Flock! 🙂

This is a shameless plug, I admit.

In a couple weeks, a fair number of people from the Fedora community will gather near Boston for the annual Flock conference. We’ll be able to update each other and work together face-to-face, which does not happen so often in Free Software.

For some months I’ve been working on the Fedora Hubs project, a web interface to make communication and collaboration easier for Fedora contributors. I really has the potential to change the game for a lot of us who still find some internal processes a bit tedious, and to greatly help new contributors.

The Fedora Hubs page is a personalized user or group page composed of many widgets which can individually inform you, remind you or help you tackle any part of you contributor’s life in the Fedora project. And it updates in realtime.

I’ll be giving a workshop on Wednesday 30th at 2:00PM to introduce developers to Hubs widgets. In half an hour, I’ll show you how to make a basic widget that will be already directly useful to you if you’re a packager. Then you’ll be able to join us in the following hackfest and contribute to Hubs. Maybe you have a great idea of a widget that would simplify your workflow. If so, that will be the perfect time to design and/or write it.

You need to know Python, and be familiar with basic web infrastructure technologies: HTML and CSS, requests and responses, etc. No Javascript knowledge needed at that point, but if you want to make a complex widget you’ll probably need to know how to write some JS (jQuery or React). The Hubs team will be around to help and guide you.

The script of the workshop is here: https://docs.pagure.org/fedora-hubs-widget-workshop/. Feel free to test it out and tell me if something goes wrong in your environment. You can also play with our devel Hubs instance, that will probably give you some ideas for the hackfest.

Remember folks: Hubs is a great tool, it will (hopefully) be central to contributors’ worflows throughout the Fedora project, and it’s the perfect time to design and write the widgets that will be useful for everyone. I hope to see you there! 🙂

React.js is pretty cool

These days I’ve been working on Fedora Hubs, it’s a Python (Flask) application, with a React.js frontend. I know Python quite well now, but it’s the first time I dabble in the React.js framework. I must say I’m pretty impressed. It solves a lot of the issues I’ve had with dynamic web development these last years. And it manages to make writing Javascript almost enjoyable, which is not a small feat! 😉

I’m still wrestling with Webpack and ES6, but I’ll get there eventually. React is really a great way to build UIs. Plus some people are writing the Bootstrap components in React, so this is very promising.