MotuProcessRevisited

Revision 4 as of 2008-08-06 16:30:38

Clear message

Summary

This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec.

Release Note

This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.

Rationale

This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified.

Use Cases

Assumptions

Design

You can have subsections that better describe specific parts of the issue.

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

Include:

  • data migration, if any
  • redirects from old URLs to new ones, if any
  • how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during CD testing, and to show off after release.

This need not be added or completed until the specification is nearing beta.

Outstanding Issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

Meeting Notes

  • List of processes

    • <process 1>

      • <note 1>

      • ...
    • ...
    • ...
    • Sponsorship
      • ubuntu-universe-sponsors
      • ubuntu-main-sponsors
      • standard names (consistent bug summary) "Candidate Revision X.YubuntuZ"
        • PPA might help with this by providing buildlogs and webspace for publishing the work
          • Some people find PPA packages more difficult to review than debdiffs
        • Launchpad could provide some interface changes to make this easier as well
          • launchpad had some fixes to the /text at the end

      • link to sponsorship overview: http://people.ubuntu.com/~dholbach/sponsoring/

      • make a note on http://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews (unsubscribe team, assign to yourself)

    • Merging

      • http://dad.dunnewind.net/universe.php

        • DaD as front-end for MoM (use MoM patches & reports)

        • Dad as front-end for LP activity tracking backend?
      • The merging guide needs some improvement

      • have a summary of what merging is on UbuntuDevelopment, have a merging guide on a subpage

        • Merging Guide needs to target both MOTU and Contributor
      • Use bugs to track who is doing what (find and restore lpbugs.py)
      • A lot of people don't have a problem with people doing their merges, as long as they follow a specifified procedure. Of course, documenting these would be good
      • Make the sponsorship queue itself have a functionality where someone can "take" -- perhaps same with merge bug list. The idea is to make it easy in the web application to see if an item is being worked on and by who
      • Create tool to make adding / closing LP bugs for merges completely painless from the command line. Patch requestsync to allow overwriting merge bug for sync request.
        • - that tool should make it easy to query open bugs in malone + debbugs!!! - makes malone as a database-like backend for tracking merges
      • Merge tag?
        • launchpad.net/ubuntu/+bugs?field.tag=merge
      • discuss 'locking' merges on the list
    • Becoming MOTU
  • Would be useful to have a list of MOTUs, their IRC nick, and (perhaps) their interests next to it

    • + https://launchpad.net/~motu/+members is a base, perhaps?

    • Could encourage MOTU to update their profile with interests.
      • - Use the IRC nick field on LP
    • Mentoring - ideas

      • more Q&A sessions

        • Weekly MOTU Q&A provides another easy forum for easy questions (mailing list is a bit of an obstacle for some with simple questions; forums and IRC less so)

      • Agressive marketing of ubuntu-motu-mentors@lists.ubuntu.com - ROCK ON!

      • Better marketing of #ubuntu-motu as collaborative team mentor

  • StableRelease Updates

  • FF exceptions
    • New Packages
      • Need to make schedule clearer to REVU Contributors, to explain gap after FF - also include the time in UTC of that date (also provide best guess as to next REVU cycle start)
      • explain that REVU contributions might not be reviewed after FF, point people to TODO page
    • UVF
      • Packages which have blanket-ish exceptions (ones that don't affect others, ones that are basically snapshots, or stuff that are important to have the latest version of (security stuff))
    • Coordinate with archive-admins regarding verification of freeze exceptions - what kind of verification? (do you want them to re-review the bugs?) (No. For gutsy, slangasek worked with uvf team: this should be normal practice rather than because there was a new archive-admin)
  • Conflict

    • https://wiki.ubuntu.com/MOTU/Council

    • So far council hasn't done anything but new applications
    • encourage people to raise problems with the MC team
      • need documentation of contact point: public list? Private mail? IRC?
        • public list, if not a touchy subject, else private mail to all members

          • Right. It just needs documentation in the charter Smile :)

          • willdo Smile :-)

  • BOTTLENECKS
    • Sponsorship
      • NEW Packages
        • REVU days
          • fixed date and time (global Mondays - 49 hours a week)
          • "it's not REVU day, I won't do anything today)
          • good, that people can directly follow up on comments
          • needs more PIMPing
        • if we should ever make the switch to launchpad, easier to subscribe teams who have a natural interest in that new package ++
    • MOTU School sessions
      • videos?
      • screencasts?

      • course material handed out to LoCo folks

      • ...
    • ...
  • Other Notes

    • packaging guide should have debdiff tutorial (http://wiki.ubuntu.com/MOTU/Recipes - needs merging)

    • Ubuntu backports only covers packages that don't need source modifications (very simple there: file bug)
    • Jeff Bailey might make a video tutorial for Google video offering packaging help.
      • Offered that Google offices would be willing to help make and post videos if you're local to them.
  • TODO Items
    • talk to Scott about DaD merge, talk to Dad people about using MOM patches
    • ask MOTUs to update launchpad profile with interests
    • vote on new motu-uvf members
      • candidate pool should be (at least) team size +1

CategorySpec