The change in the core version control system from Subversion to Git, insofar as it can be separated from the change in code review systems, seems to have settled in well after last week's switchover ( Signpost coverage). By contrast, the new code review tool Gerrit continues to prove controversial, spawning dozens of threads on developer mailing lists.
The issues raised (many of which seem, at least on the surface, to be fairly minor) are both too numerous and in many cases too technical to be adequately summarised in a couple of lines; nevertheless, in doubtlessly a positive sign, developers seem to be treating the vast majority of the problems encountered (such as an awkward system for responding to comments and the overly personal nature of the autogenerated taglines that accompany certain types of review) simply as issues – bugs needing to be fixed – rather than internalising them as complaints with the fundamentals of the new code review process. Indeed, work on a number of these issues has started already; others will however require changes to Gerrit itself. On the whole, developers seem to be hopeful that all their issues with the new code review process can be resolved, given enough time. Nevertheless, a handful of the the issues raised do seem to have real sticking power, including concerns that Gerrit's code review paradigm may be fundamentally ill-suited to the review of large or complex changes ( wikitech-l mailing list), too difficult for new contributors to come to grips with, or overly conducive to the kind of endless bar-raising that would see the gap between old and new contributors continue to widen.
Though the current trend suggests that issues will continue to be either resolved or ameliorated over the coming weeks, a potential future fly in the ointment is a planned audit of Gerrit's performance in three months' time. Such an audit, a pre-switchover concession to those who initially disliked Gerrit, has the potential to lead to the code review system to being abandoned in favour of a competitor system such as Phabricator. Needless to say, should grievances with Gerrit be unresolved by then – with or without great appetite for a second difficult migration – the audit could be a difficult one to manage.
Write-ups of the Chennai Hackathon (held in the Indian city on March 17) began to be posted online this week, giving an insight into the success of a hackathon with a deliberately broad remit. Overall, thirteen projects were demonstrated at the end of the day, including a "text-a-quote" service, a hand-held device-based pronunciation recorder and work on an instant image rotate function accessible from file description pages ( wikitech-l mailing list). The quality that WMF localisation team member Gerard Meijssen perceived in many of the projects prompted him to comment how they "deserve attention [from the wide] public—they represent missing functionality or they have a different approach to something we are struggling with. They are all by people who have a keen interest in the projects of the Wikimedia Foundation and as such they represent our 'latest generation'".
In total, the hackathon (one of an increasing number of tech-focused Wikimedia meetups being scheduled across the globe) attracted some 21 programmers, overwhelmingly but not exclusively male. In writing up the event, WMF developer and attendee Yuvi Panda described why he thought coders at the "super awesome and super productive" event were able to get so much done in a single eight-hour day:
“ | The event started with us sailing past security reasonably easily, and getting setup with internet without a glitch... Since this was a pure hackathon, there were no explicit tutorials or presentations. As people came in, we asked them what technologies/fields they are familiar with, and picked out an idea for them to work on from the Ideas List. This took care of the biggest problem with hackathons with new people—half the day spent on figuring out what to work on, and when found, it is completely outside the domain of expertise of the people hacking on the idea. Talking together with them fast to pick an idea within 5 minutes that they can complete in the day fixed this problem and made sure people can concentrate on coding for the rest of the day. | ” |
Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for many weeks.
The change in the core version control system from Subversion to Git, insofar as it can be separated from the change in code review systems, seems to have settled in well after last week's switchover ( Signpost coverage). By contrast, the new code review tool Gerrit continues to prove controversial, spawning dozens of threads on developer mailing lists.
The issues raised (many of which seem, at least on the surface, to be fairly minor) are both too numerous and in many cases too technical to be adequately summarised in a couple of lines; nevertheless, in doubtlessly a positive sign, developers seem to be treating the vast majority of the problems encountered (such as an awkward system for responding to comments and the overly personal nature of the autogenerated taglines that accompany certain types of review) simply as issues – bugs needing to be fixed – rather than internalising them as complaints with the fundamentals of the new code review process. Indeed, work on a number of these issues has started already; others will however require changes to Gerrit itself. On the whole, developers seem to be hopeful that all their issues with the new code review process can be resolved, given enough time. Nevertheless, a handful of the the issues raised do seem to have real sticking power, including concerns that Gerrit's code review paradigm may be fundamentally ill-suited to the review of large or complex changes ( wikitech-l mailing list), too difficult for new contributors to come to grips with, or overly conducive to the kind of endless bar-raising that would see the gap between old and new contributors continue to widen.
Though the current trend suggests that issues will continue to be either resolved or ameliorated over the coming weeks, a potential future fly in the ointment is a planned audit of Gerrit's performance in three months' time. Such an audit, a pre-switchover concession to those who initially disliked Gerrit, has the potential to lead to the code review system to being abandoned in favour of a competitor system such as Phabricator. Needless to say, should grievances with Gerrit be unresolved by then – with or without great appetite for a second difficult migration – the audit could be a difficult one to manage.
Write-ups of the Chennai Hackathon (held in the Indian city on March 17) began to be posted online this week, giving an insight into the success of a hackathon with a deliberately broad remit. Overall, thirteen projects were demonstrated at the end of the day, including a "text-a-quote" service, a hand-held device-based pronunciation recorder and work on an instant image rotate function accessible from file description pages ( wikitech-l mailing list). The quality that WMF localisation team member Gerard Meijssen perceived in many of the projects prompted him to comment how they "deserve attention [from the wide] public—they represent missing functionality or they have a different approach to something we are struggling with. They are all by people who have a keen interest in the projects of the Wikimedia Foundation and as such they represent our 'latest generation'".
In total, the hackathon (one of an increasing number of tech-focused Wikimedia meetups being scheduled across the globe) attracted some 21 programmers, overwhelmingly but not exclusively male. In writing up the event, WMF developer and attendee Yuvi Panda described why he thought coders at the "super awesome and super productive" event were able to get so much done in a single eight-hour day:
“ | The event started with us sailing past security reasonably easily, and getting setup with internet without a glitch... Since this was a pure hackathon, there were no explicit tutorials or presentations. As people came in, we asked them what technologies/fields they are familiar with, and picked out an idea for them to work on from the Ideas List. This took care of the biggest problem with hackathons with new people—half the day spent on figuring out what to work on, and when found, it is completely outside the domain of expertise of the people hacking on the idea. Talking together with them fast to pick an idea within 5 minutes that they can complete in the day fixed this problem and made sure people can concentrate on coding for the rest of the day. | ” |
Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for many weeks.
Discuss this story