Development Team/Meetings

From Sugar Labs
< Development Team
Revision as of 06:47, 31 October 2017 by Quozl (talk | contribs)
Jump to navigation Jump to search

Team Home   ·   Join   ·   Contacts   ·   Resources   ·   FAQ   ·   Roadmap   ·   To Do   ·   Meetings

  • The Development team once held regular, bi-weekly meetings on Mondays at 14 UTC (9:00 EST) on irc:// See Sugar-devel, the Sugar and Activity developers' email list for current development discussions.
  • The Fedora development project for the OLPC XO and a Sugar distribution once held weekly meetings on Thursdays at 17:00 UTC (12:00 EST) on irc:// See devel, The OLPC system hardware and software developers' email list for current discussions.
(Hint: You can use an online time calculator to convert from UTC to your local time zone or back.)

The Sugar Labs Meetings calendar is available in a variety of formats at these links: XML.gif ICal.gif HTML.gif

Upcoming Agenda


  • Quick update about what we have been working on and eventually the problems we have run into.
  • Discussion about the implementation details of tickets we are planning to work on. Figure out how to split up the work and who should be owning the various parts.
  • Questions from activity authors about specific aspects of the platform and more in general on how to better integrate their activity in Sugar. Report about problems they run into.
  • Help out new contributors to figure out where to start. Point out the tickets we need help with, discuss with them the implementation.


The meeting is mainly targeted to Sugar core and activity developers, but everyone interested is welcome to join. It's primary purpose is to try to open the development up a bit, make it more transparent and allow the community to participate more easily. For when to join see 'When and Where'.

How to add topics

You can add the topics that you want to discuss during the week to the topics section for the meeting. They will be collected during the week and send out in the meeting announcement on Thursday morning.

Upcoming Meetings

1st November 2017 21:00 UTC

  • what we have been working on.

Previous Meetings

24th October 2017 22:00 UTC

minutes log


what we have been working on
updating examples and testing of Music Blocks, testing new WebKit GTK+ with Browse, looking for source code commits for the FindWords-3.1 activity, and releasing MusicKeyboard-11.

17th October 2017 22:00 UTC

minutes log


what we have been working on
features in Music Blocks, assessing GTK+ 3 porting, preparing for and merging translations,
impact of GTK+ 2 removal in Fedora and Debian
GTK+ is a library, see GTK+ and GTK+, GTK+ 3 is incompatible with GTK+ 2, many activities for Sugar depend on GTK+ 2, GTK+ 2 is scheduled for removal in Fedora 28 and in Debian Buster, removal already starting in Debian, bad user experience with Browse and is non-starting activities, all Fructose activities are converted, Labyrinth is of interest to OLPC and has an upstream port, Record is of interest to OLPC and has an in-progress port at, Moon is of interest to OLPC and has a JavaScript port, GCI will have porting tasks.

10th October 2017 22:00 UTC

Only one developer was available, so the meeting did not happen.


post-release 0.112 review
no test reports received.
what we have been working on
new gst-plugins-espeak, contributors list, releasing, testing 0.112, font size in Terminal, bugs in gst-plugins-espeak.

Report was made by mail.

3rd October 2017 22:00 UTC

Only one developer was available, so the meeting did not happen.


progress of testing 0.111
going well, and a bootable build is available.
merging any translations
no new translations, so no need for merge.
readiness for 0.112
release notes are complete, nothing is blocking release on 9th October.
what we have been working on
Memorize and Speak activities do fail to start on Ubuntu 17.04 Artful due to default voice missing from espeak, since fixed in gst-plugins-espeak. sugar-docs has been updated for using sugar-live-build as a development environment, and remove sugar-build. The AbiWord fix for #4915 Write activity flicker has been accepted by Ubuntu and Debian, and has tested fine in those distributions. Also on GitHub have been commits in embedded Music Blocks, embedded Turtle Blocks, Help, and ImageViewer.

Report was made by mail.

26 September 2017 22:00 UTC

minutes log


progress of testing 0.111
some testing is being done, but more testing would be helpful, see testing 0.111,
merging latest translations
asked translators mailing list, no new translations made, strings for save-as feature are new, some Music Blocks strings changed too,
readiness for 0.112
some time before translations must be in per schedule, release process well understood and should not take long, possibility of a test image,
what we have been working on
bug #4915 ("Write redraws excessively - heats my lap") the AbiWord flicker, a fix is available, but upstream wants it also fixed on Wayland, though Ubuntu has taken it, applying the fix is straightfoward; release notes are to include Turtle Blocks porting, and therefore other activities (done, see 0.112#Notes), Turtle Blocks 216 for upload (done), and a test image is nearly complete, which can be a replacement for sugar-build, see Sugar Live Build.

19 September 2017 21:00 UTC

minutes log


Release Manager
We ack'd James Cameron in his role as release manager for 0.112.
Community Standards
We reiterated the importance of civil behavior and the necessity to work with the community, not unilaterally. We also reviewed the mechanisms we use for pull requests, reviews, and merging.
0.112 release testing
We discussed 0.112/Testing
Version numbering
We agreed to investigate the possibility of switching to 113 for the next release (a monotonic numbering system).
We agreed to work with SCG to do the ground work necessary to get ALSOv3 launched.

30 October 2010 22:00 UTC

minutes, log

Not discussed:

  • Settle down patch submitting workflow:
    • email based workflow as a primarily model (check other FOSS projects to gather all existed experience) alsroot 07:35, 27 October 2010 (EDT)
    • write an email-bot/trac-plugin to make an email<->trac sync. Will be useful, e.g., for non-developers who track bugs status and to let people know the current status in most convenient way. All emails, w/ ticket set, will be posted to and any comments(and patches) to, to tickets w/ previously sent patches, will be emailed. alsroot 07:35, 27 October 2010 (EDT)
  • Requirement to use pylint/pep8 in git pre-commit:
    • sugar-lint, because it is a standalone project and can be used as-is also, e.g., for activities (i.e., as unified lint tool within sugar doers) alsroot 07:39, 27 October 2010 (EDT)
  • Increase a level of trust within core team, make patch reviewing workflow more clear:
    • Any committer, to a particular core project, might be a reviewer (we either should trust all these people or drop them from committer list) alsroot 07:59, 25 October 2010 (EDT)
    • To accept regular (reviewer decides whether patches are regular or not, of course, better to discuss it with other committers if there are doubts) patches, only one reviewer is needed alsroot 07:59, 25 October 2010 (EDT)
    • Non-regular patches should be formed in Features. These patches might take several tens of K. This is by design; that it is hard not only to develop, but also to review and it should involve several committers for a reasonable amount of time. alsroot 09:28, 25 October 2010 (EDT)
    • Review process should not include debates about coding style, if coding style conforms to lint checks and Hacking Policy (if it has unequivocal statements, needs to be rechecked), it should be applied alsroot 09:33, 25 October 2010 (EDT)
    • Purism is good but there is no need to achieve it by single patch, it might be changed in post-commit patches if second reviewer (e.g., looking to the patch thread on mailing list) found an issue in already commited code. alsroot 13:39, 25 October 2010 (EDT)
  • officially dropping support for 0.86? (e.g. #1838)
    • do we need to discuss thing like that on Development Team meeting, is it a more appropriate task for Deployment and Platform teams? alsroot 07:59, 25 October 2010 (EDT)
  • big (and small) ideas for 0.92 --Walter 13:17, 25 October 2010 (EDT)
  • Support isolated start of glucose components. In that case, merge sugar-base to sugar-toolkit (patches [yet] don't implement it but import sugar-base from sugar-toolkit) to have API that will be used as a single access point to sugar core functionality for activities. alsroot 08:12, 30 October 2010 (EDT)

Wednesday 30 June 2010 13:00 UTC

minutes, log

  • Introduction: the release cycle approach
  • Define the overall goal for 0.90
  • Review processes (review, Feature)
  • Open positions (development team, design team, testing team)

Monday 22 March 2010 14:00 UTC

minutes, log.

  • Welcome newcomers
  • 0.88 Release: hard code freeze, final release, 0.88.1

Monday 8 March 2010 14:00 UTC

minutes, log.

  • backport SL#1787 to 0.86, push out + announce new release
  • 0.88 Release: bug database cleanup, code review, stabilization, etc

Monday 22 February 2010 14:00 UTC

minutes, log.

  • 0.88 Release: bug database cleanup, fix bugs, etc
  • Activity Team: Move to new toolbar

Monday 8 February 2010 14:00 UTC





  • State of 0.88 release