Developer meeting November 2010

Developer meetings > November 2010 meeting

The meeting was at 07:00 UTC on Thursday, 25 November 2010. We had 37 participants and we covered everything in around 1½ hours.

• Meeting notes (developer chat history only available to developers with CVS write access)

A recording of the meeting will be available soon.

Agenda

• Moodle 2.0 release
• Development:Process
• Development:Git Migration
• Converting unit tests to PHP Unit -- I hope someone will tell us what the plan is with this.
• Heads up: Development:Question_Engine_2 coming in Moodle 2.1 -- Tim Hunt
• Proposal for a better cron infrastructure -- Penny or Tim -- if we run out of time, we could drop this, but it is a nice idea that was talked about a year ago, and it would be nice not to forget it.
• Performance Profiling - Dan P [on behalf of Eloy]

Git Migration Concerns

There has been some discussion in the developer chat room about potential git workflows. Some immediate concerns about a workflow:

• Slow moving reviews. Especially for lesser known contributors, git makes reviewing and 'commiting' as an external contributor much easier, but code reviews are a social rather than technical problem. Time needs to be allocated to 'coaching' people who don't make the cut. The code review structure needs to be such that the top doesn't become a bottleneck.

• Multiple ineffective sign-off levels. There is no point jumping through multiple levels of code review if its not done effectively. (Upon writing this I realise we need to just try it and make sure it doesn't become like this, rather than expecting it to fail--Dan Poltawski 09:34, 23 November 2010 (UTC)).

• How to manage the code-review 'work-stack'? If there is a list of 'merge requests'? If we continue to use the tracker for this we're likely to get the problem of 'lost patches' sitting in bugs which have never been looked at by a core contributor.

• Loss of 'kudos' for existing commiters. Like it or not, some respect comes with commit access. This can be replaced by reviewing roles having a place in the code review 'tree'.
  • We can use this to ensure better code review happens though. If i'm a mid-level reviewer, I would want to improve my kudos by only letting good stuff through ;-)
  • Please note git supports both Committer: and Author: field for each commit. So we can easily to respect original author of the patch. --David Mudrak 13:08, 24 November 2010 (UTC)
    • Perhaps the solution to the original question is a general rule that nobody should commit their own work. The credit goes to the author (which would encourage more contributions) and a workflow would need to be developed that would ensure quick review when appropriate. The list of "Moodle Developers" would be those who have authored code that is committed (perhaps with an indication of the number of contributions to distinguish major developers). --Gary Anderson 19:19, 24 November 2010 (UTC)
    • Sorry, the problem is not that there is lack of credit, in fact its much better in git than CVS, as the original author should be retained (so new contributors get credit from the start). The problem is instead of 'established contributors' who currently have 'kudos' in the form of commit access. This will be lost, and I think there is still a place for such kudos (in the form of reviewer roles, perhaps). --Dan Poltawski 20:16, 24 November 2010 (UTC)
    • In addition to having other roles like reviewer, etc. we could use something like the Linux kernel 'tag lines' (see http://www.kernel.org/doc/Documentation/SubmittingPatches sections 12-14). Then we could update moodle.org "bagdes" dynamically, like we currently do for particularly helpful moodlers, based on the number (and type) of times the user appears on those tag lines for the commits in a given time frame Iñaki Arenaza 22:10, 24 November 2010 (UTC)