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.
- Recording of the meeting (login as a guest by providing your email address, name and session password moodle)
Meeting participants, if anything we discussed has been been missed out, please edit the page and add it!
Moodle 2.0 release
Martin said it was good to have the Moodle 2.0 release as a milestone. We won't branch for a while yet but will work on refining 2.0. Not branching makes things easier for migration to git. We won't be working much more with 1.8, just security fixes.
Moving to git
Martin described how there have been good discussions in HQ about processes and how we can go forward. We will be switching completely to git as primary repository, CVS will be a mirror, people using CVS to update their sites won't notice anything, only devs will notice. Not sure of timing of switch yet, will have a lot more control over checkins, much more defined process with more reviewing.
The triage role makes sure all fields filled in correctly, product owner role name from scrum, development period could be 2 weeks or 1 month, may use crucible, one point of git is that people can use their own tools. We're looking for good ideas, conventions from other projects on how they name things! Component maintainer may well be external developer, QA testing role could be Helen or anyone who knows how to use moodle. If a test fails, code is reverted, goes back to integration reviewer who either rejects patch or gets it fixed, then it goes back to QA.
Where do unit tests fall into sequence? The plan is to have unit tests running automatically more often.
Tim commented that all reviewing should happen in one place, contributors should see where things are at, all requests for reviews from different people should be in one central place.
Anthony asked about contrib and git. Martin explained that we'd start with core then contrib can follow, though anyone can start using git for contrib now.
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.
Martin explained that the problem previously was that we never had well-defined roles, and some people were filling multiple roles. It will be much better when people know exactly what they are doing. If certain things take a long time then we know we need to get somebody extra in.
Dan Marsden commented that he saw component maintainers as a bottleneck. Martin replied that we can have multiple maintainers.
- 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)
Other stuff
- Converting unit tests to PHP Unit
- Martin said that Petr had come across problems with PHP Unit, though they're hopefully fixed now. Martin will decide when we switch to PHP Unit in the Moodle 2 codebase, it's technically possible to do it immediately.
- Heads up: Development:Question Engine 2 coming in Moodle 2.1
- Tim explained that all the code is done in OU version, the OU will release all on 6 December 2010. It's had a lot of testing, starting last May. Tim is feeling good about the code, but scared about the db upgrade. The plan is to make it a branch of Moodle 2, which will involve certain amount of rework. Tim has written a lot of unit tests which all pass.
- Martin commented that it was a very good spec as usual.
- Tim explained that the proposal for a better cron infrastructure was a nice idea that was talked about a year ago in the hackfest. The cron is one big script, we should make it smarter e.g. call this function every 5 mins, that function at 2am, keep logs in db, admins reports so they can see everything cron is doing and anything failing.
- Martin replied that it sounds like a good idea and asked for volunteers.
- Performance Profiling
- Dan explained that his colleague Ruslan had been working on it (see the discussion Moodle performance testing: 1.9 vs. 2.0). Eloy is working on xhprof, can find out all kinds of profiling info. A cool thing Eloy has done is mark a run as a reference run, then you can view profiling differences with last reference run. (See the recording of the meeting for a demo.)
- Martin said we should get it into head asap. We should be focusing on performance stuff now.
Martin concluded the meeting by mentioning that La Trobe university in Victoria is launching Moodle 2.0 in January. Martin said that he hadn't yet worked out the 2.01 roadmap. The git switch will happen pretty soon, hopefully in the next week, will give everyone a warning, take away CVS write access, CVS server will stay where it is. The new JIRA is up, have a play and report any bugs!
Finally, a big thank you to everyone who made check-ins to Moodle 2.0 code :-)
See also
- Meeting subtitles developer conversation for additional meeting notes (only available to developers with CVS write access)
