Development Team/Meetings

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://irc.freenode.net#sugar-meeting. 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://irc.freenode.net#fedora-olpc. 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

About

  • 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.

Who

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

  • none

Previous Meetings

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 bugs.sl.o and any comments(and patches) to bugs.sl.o, 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

Logs

logs

minutes

Topics

  • State of 0.88 release