For minutes of previous meetings, please see DesktopTeam/Meeting.

Present

• Rick Spencer (rickspencer3) - chair
• Alexander Sack (asac)

• Arne Goetje (ArneGoetje)

• Bryce Harrington (bryce)
• Chris Cheney (calc)
• Jonathan Riddell (Riddell)

• Ken VanDine (kenvandine)

• Martin Pitt (pitti)
• Sebastien Bacher (seb128)
• Tony Espy (awe)
• Till Kamppeter (tkamppeter)

Apologies

• Robert Ancell (robert_ancell) - out of timezone

• Luke Yelavich (TheMuso) - out of timezone

Agenda

• Reviews
• GIMP
• Blueprints, specs, burndowns
• Bug hygiene
• Team Meeting: Eastern Edition
• Release Bugs/Release Status
• Review activity reports
• Any other business

Actions from this meeting

• All: schedule a time for performance review
• rickspencer3: create burndown chart script for blueprints
• All: add work items to burndown chart as defined by burndown chart script
• All: unasign bugs that will not be addressed in Karmic, including release targeted ones

Reviews

• Desktop team employees should schedule a time with rickspencer for performance reviews

The GIMP

• rickspencer3 proposes pulling the gimp from the CD:
  • It takes up a lot of space that we need for couchdb, etc...
  • F-Spot has key features, like crop and red-eye removal
  • It's a power user tool, users shouldn't stumble into it
• Discussion points brought up that
  • The gimp currently uses 26 megs of space, 20 of which are documentation, which could be moved online
  • The gimp, though not totally user friendly, is very useful, and does not require "importing" to edit
• The current plan of record is:
  • Keep the gimp in the default install
  • If we need the room, switch the gimp to online only documentation
  • If we still need the room, kick it out altogether

Blueprints, etc...

• About 50% of the blueprints are approved
• Decision was taken to track work items on the blueprint white boards
• Burn down chart will be generated form whiteboards asap
• In order to accommodate different work flow, the system may later be extended to allow tracking with bugs as well

Bug Hygiene

• rickspencer3 asked that team members only have bugs assigned that they intend to fix in Karmic
• Rich discussion followed regarding bug usage
• Little was concluded, except that a problem definition was needed before progress could be made in the discussion

Team Meeting: Eastern Edition

• An addition team meeting will be added to accommodate team members in Easter time zones.
• The meeting will be at 23:00 UTC on Tuesdays. All are invited to attend.

Release Bugs/Release Status

We have many release targeted bugs across multiple previous releases. Apparently, much of this is cruft that should be removed.

Karmic

Jaunty

Intrepid

Hardy

dapper

Activity reports

Alexander Sack (asac)

Spec state:

• desktop-karmic-browsers - drafted. requested approval

• desktop-karmic-firefox-3.5 - drafted. requested approval

• desktop-karmic-bluetooth-stack - drafted. requested approval

• mozilla-karmic-firefox-wifi-scanning - 95% drafted, discussed with upstream. next: finish document and request approval.

• desktop-karmic-network-ui - drafting, waiting for awe to come back from vac.

• desktop-karmic-network-status - pre-discussion done during UDS, need to spec this together with holtmann (connman) and dcbw (NM); project is a two cycle project i guess

• desktop-karmic-modemmanagers - drafting.

• desktop-karmic-con-man - informational, will put the content in asap

Mozilla work:

• security update preparations and call for testing for firefox/xulrunnr and thunderbird
• LP: #319480 - firefox crashed with SIGSEGV in memalign(); long standing issue, causing segfault on every shutdown on 1.9.1+ branches. I finally fixed this by leaking the environment vars set.

Sponsoring/Mentoring

• adblock-plus
• greasemonkey
• gnome-bluetooth

Misc

• submitted patch to libnotify upstream to adds convenience function for probing
  • for capabilities (see LP: #383875)
• work with crevette on gnome-bluetooth

Arne Goetje (ArneGoetje)

Specs:

• desktop-karmic-language-selector-karmic - drafting, need mpt and cjwatson to review and fill in the blanks

• desktop-karmic-translations - informational, will split out items and file them as bugs or blueprints, although nothing for the desktop team to work on.

• desktop-karmic-input-methods - informational, needs more discussion, nothing to implement during Karmic cycle.

• desktop-karmic-fonts - informational, will split out some to do items, but these items may not be finished for Karmic.

Misc

• Investigated buggy firefox translations in the langpack PPA for Jaunty: this is because of message sharing being implemented in Rosetta. Trying to fix this with new XPI uploads into Rosetta, so far with no success. Launchpad Translations team is informed, we won't ship Jaunty langpack updates until message sharing is fully in place.

Bryce Harrington (bryce)

Distro

• AllHands May 18-22

  • - Presentation on X.org
• UDS May 25-29
  • - Several sessions on X topics and bug handling
• Sponsored: libx11(#379785)

X.org

• Extensive -intel bug triage work with Jesse Barnes at UDS
• Wrote script to parse Xorg.0.log files into python data object
• Lots of planning work for X.org in coming months
• Packaged new libdrm 2.6.11 release from upstream
• Packaged git snapshot of -intel 2.6.99.1+git
• Merged -ati from Debian
• Closed bunch of bugs fixed by new -intel and -ati
• Completed/closed several blueprints now done as of UDS
• Packaged, proposed intel-gpu-tools for Karmic
• Worked on Jaunty X freeze issues a bunch. Set up a wiki page to
  • track all the various proposed fixes. Set up several PPAs:

    https://wiki.ubuntu.com/X/Bugs/IntelDriver#Fixes

• Drafted and distributed Karmic X.org driver req's/plan
  • (for desktop-karmic-xorg blueprint, now nearly done)
• Kernel Mode-setting
  • - Intel: -intel seems to be working okay; merged in 2.6.99.1+git to
    • Karmic, worked on / upstreamed relevant bug reports
    - ATI: tested -ati with apw's kernel - the kernel side more
    • or less works, but additional support is needed in X. Work continues in xorg-edgers
    - Nvidia: Tested -nouveau on G70 and G86 core cards; neither worked
    • but for different reasons. ordered a G92 card which supposedly has received better testing. At this point I'm really having my doubts that -nouveau is far enough along to replace -nv, let alone do kernel mode setting...
• Updated pci id's for -nv

Chris Cheney (calc)

• Uploaded openoffice.org 1:3.1.0-3ubuntu1
• Uploaded openoffice.org 1:3.1.0-3ubuntu2 to h/i/j/k
• Uploaded openoffice.org-l10n 1:3.1.0-1ubuntu2 to h/i/j/k
• Uploaded openoffice.org-l10n 1:3.1.0-3ubuntu2 to h/i/j/k
• Found someone to do KDE 4 integration for OOo.
• Found someone to do KDE 4 icon style for OOo.
• All Hands
• UDS Karmic
• Weekly OOo Release Status Meetings
• Weekly desktop team meeting
• Lots of OOo bug triage
• Note - also working on OEM Team

Jonathan Riddell (Riddell)

done:

• a day recovering from the UDS plague
• full day new queue processing (quite some backlog there)
• overseeing and releasing KDE 4.2.4 packages
• packaging and announcing Amarok 2.1
• overseeing KDE 4.3 beta 2 packages
• processing e-mail backlog

todo:

• alpha 2 testing
• off thursday and friday

Ken VanDine (kenvandine)

Done:

• MIRS for:
  • empathy
  • telepathy-gabble
  • telepathy-salut
  • telepathy-haze
  • telepathy-idle
  • telepathy-glib
  • telepathy-mission-control
  • libtelepathy
• Updated messaging indicator patch for empathy 2.27.2 and trunk, submitted upstream
• Reviewed notification related patches sent upstream for acceptance
• Fixed a loudmouth bug that breaks jabber in empathy for many people

Todo:

• Finish up the follow-up work on the MIRs
• U1 Acceptance testing report
• Update gtk csdeco ppa build for Cody
• Social from the start follow-ups
• Alpha 2 iso testing

Luke Yelavich (TheMuso)

Accessibility

• Drafted gnome-speech replacement specification. See https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnome-speech-replacement

• Started work on a main inclusion report to promote liblouis (http://code.google.com/p/liblouis/) to main, to provide grade 2 translation support for the Orca screen reader.

• Further speech-dispatcher pulseaudio output debugging. Will need to work with Lennart on this one.

Audio

• Audio bug triaging, bugs in question are against pulseaudio, alsa userspace, and the kernel for hardware enablement.
• Finished updating the alsa stack to 1.0.20. Forgot that plugins also needed doing, so took care of that, as well as alsa-tools.
• Obtained some audio hardware that has limited to no support at least in Ubuntu, to try and get it to the point where it just works.
• Started to put a package together of the latest git snapshot of gnome-media, for local testing. I want to see how well the pulse volume control allows for changing audio devices and switching audio streams between audio devices.

dmraid

• Triaged some bugs for dmraid, since I have not yet heard of who is taking over maintainership. Still need to prepare some patches to push to debian.

Misc

• Took care of more merges/syncs that popped up on merges.ubuntu.com.

Martin Pitt (pitti)

Karmic spec drafting:

• desktop-karmic-automagic-python-build-system: drafted, waiting for review from Rick
• desktop-karmic-symptom-based-bug-reporting: drafted, approved

Karmic feature work:

• desktop-karmic-automagic-python-build-system:
  • status: branch available which implements about half of the functionality
  • no progress this week
• desktop-karmic-symptom-based-bug-reporting:
  • first functional version of interactive hooks available in a branch and my PPA
  • blogged about it to get some testing
• hal deprecation:

  • created https://wiki.ubuntu.com/Halsectomy for tracking progress

  • switched Karmic to udev-extras for keymaps and ACLs
  • created libgphoto2 patch for producing working udev rules, got it accepted upstream

  • discussion about hal-cups-utils -> udev migration

Other work done:

• Got the desktop CDs back into size limit for Alpha-2 by dropping ekiga (karmic goal anyway) and all langpacks
• Cleaned up old apport crash reports which were not accessible for anyone
• Debugged USB problem on Till's computer
• Some hal/hal-info maintenance
• Some bug fixes (cups, jockey, udev-extras)
• Set up automatic armel apport retracer
• DX integration conf call
• Tested new gdm; some upgrade and install problems, currently too broken for alpha-2
• Updated to new gnome-power-manager

Currently open stable/milestoned bugs:

• 334446 (Remove gnome-pilot from the default ubuntu install): simple to do, needs some discussion though

Merges:

• mine are all done
• Checked some merges from other people which could be synced (and synced them): gawk-doc, ed, apmd, dictd, gnome-common, libsndfile, librsvg, libfile-basedir-perl, hyphen, wvstreams, unzip, portmap

Sponsoring:

• app-install-data-ubuntu, brasero, cdbs, fakeroot, fftw3, gnome-doc-utils, gnome-pilot, hal, pbuilder, pessulus, pyopenssl, tracker, transmission, exiv2
• Reviewed, not uploaded: cloop, dput, pyvorbis

Robert Ancell (robert_ancell)

• First draft of Compiz problem page for users: https://wiki.ubuntu.com/VisualEffects

• Package updates: anjuta 2.27.2, glade 3.6.4, python-opengl 3.0.0, gdl 2.27.2 (blocked by needing to rebuild dependencies)

• Investigated delays in GtkBuilder, worked on some patches to speed up (up to 40% faster)

• Triaging (especially empathy so ready for Karmic)

Sebastien Bacher (seb128)

karmic specs drafting:

• desktop-karmic-gnome-3: drafted, approved
• desktop-karmic-default-media-player-choice: drafted, waiting for an

another review round after update

• desktop-karmic-messaging-and-communication-selection: drafted,

waiting for an another review round after update

• desktop-karmic-default-application-priorities: drafted, approved

other tasks:

• catching up on emails after uds, etc
• GNOME updates: gtksourceview pygobject pygtk glib rhythmbox deskbar-applet evince libgnomekbd gtkhtml gtk gnome-applets alacarte
• updated the notify-osd version in karmic
• worked on some karmic desktop packages bugs
• desktop bugs triage
• updated gdm to the current 2.26 tarball and uploaded to the

ubuntu-desktop karmic ppa for testing, still some issues to solve before uploaded to karmic

sponsoring: totem poppler gnome-python pidgin notify-osd deskbar-applet

Till Kamppeter (tkamppeter)

• Updated Poppler to fix two printing-related bugs: LP: #335397 (Copying ASCII85-encoded binary data from the PDF input file produced broken PostScript), LP: #382379 (Added PostScript output mode using the original paper sizes instead of a user-supplied or default paper size).

• Discussed returning to Poppler for the pdftops CUPS filter as Ghostscript's PostScript output devices ("pswrite" and "ps2write") both lead to lots of problems. Posted on ubuntu-devel, created a master bug (LP: #382379). Posted test pdftops filter on all related bugs to survey the users. No regressions so far.

• Added pdftoopvp CUPS filter to the CUPS package on Karmic, as part of the newest PDF filters add-on.

IRC Log

• [17:30] * rickspencer3 taps gavel on desk

• [17:30] <rickspencer3> pitti: ?

• [17:30] * pitti waves

• [17:30] <rickspencer3> did awe make it back in time?

• [17:31] <rickspencer3> Riddell: ?

• [17:31] * awe waves

• [17:31] <rickspencer3> tkamppeter: ?

• [17:31] <rickspencer3> pitti: shall we begin?

• [17:31] <pitti> sure

• [17:31] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-06-09

• [17:32] <rickspencer3> first topic: reviews

• [17:32] <rickspencer3> I got back all the info - so please schedule a time with me at your earliest possible convenience

• [17:32] <rickspencer3> I think Riddell and asac are already on the calendar

• [17:32] <rickspencer3> questions?

• [17:32] <pitti> rickspencer3: is that performance review?

• [17:32] * asac checks calendar

• [17:32] <rickspencer3> pitti: yes

• [17:33] <rickspencer3> sorry

• [17:33] <rickspencer3> ACTION: All: schedule a time for performance review

• [17:33] <rickspencer3> next is a discussion topic

• [17:33] <rickspencer3> rickspencer3 proposes pulling the gimp from the CD

• [17:34] * kenvandine seconds that

• [17:34] <pitti> admittedly I'd shed a tear when we do that

• [17:34] <calc> that might cause issue with scanning, esp if we go to gnome-scan

• [17:34] <rickspencer3> here's my thoguhts:

• [17:34] <rickspencer3> * It takes up a lot of space that we need for couchdb, etc...

• [17:34] <rickspencer3> * F-Spot has key features, like crop and red-eye removal

• [17:34] <rickspencer3> * It's a power user tool, users shouldn't stumble into it

• [17:34] <kenvandine> calc: no, i don't think so

• [17:34] <calc> usually scanned images aren't good enough quality when first scanned in...

• [17:34] <pitti> but it'd give us 6 MB, plus another 20 when we figure out language-support-* stuff

• [17:34] <kenvandine> calc: perhaps :/

• [17:35] <asac> to some degree its nice to show "here, ubuntu even has a graphics program installed by default", but otoh i dont think its that useful for normal users

• [17:35] <calc> so we may want to throw out the scan program as well if do go ahead and throw out gimp

• [17:35] <rickspencer3> there's a potential issue with gnome-scan?

• [17:35] <tkamppeter> hi

• [17:35] <pitti> and it's a really "forefront" foss app

• [17:35] <calc> aiui gnome-scan actually more or less works as a plugin to gimp

• [17:35] <seb128> I've been pondering about dropping gimp for a while too now

• [17:35] <rickspencer3> asac: and pitti: make good points

• [17:35] <kenvandine> gnome-scan has it's own UI

• [17:35] <kenvandine> but

• [17:35] <kenvandine> also a gimp plugin

• [17:35] <bryce> pitti: these days there's lots of forefront foss apps...

• [17:35] <seb128> shame that we don't have a simple application to sketch or draw something quickly though

• [17:36] <calc> kenvandine: the UI doesn't let you do much of anything though, right?

• [17:36] <kenvandine> calc: assuming normal users will fiddle with gimp

• [17:36] <asac> what is couchdb (sorry if i missed this key app) ?

• [17:36] <kenvandine> lets you scan

• [17:36] <calc> kenvandine: as far as color correction, skew correction, etc?

• [17:36] <pitti> but if I were to pick the next app that we kick, it'd be gimp, yes

• [17:36] <kenvandine> calc: none of that

• [17:36] <pitti> asac: backend storage for U1

• [17:36] <rickspencer3> it seems to me that f-spot kind of made the GIMP less necessary

• [17:36] <seb128> pitti++

• [17:36] <pitti> (or the other way round :-P)

• [17:36] <seb128> <pitti> but if I were to pick the next app that we kick, it'd be gimp, yes

• [17:36] <seb128> ^ same from me

• [17:36] <rickspencer3> pitti: asac: it's not just for U1

• [17:37] <rickspencer3> generally, a default structured data store is a good thing

• [17:37] <rickspencer3> but U1 definitely would be a prime beneficiary

• [17:38] <rickspencer3> so, consensus seems to be that if there is still room on the CD, we may as well keep the GIMP?

• [17:38] <pitti> rickspencer3: well, the world uses sqlite or bdb, which we already ship

• [17:38] <pitti> rickspencer3: personally I wouldn't kick it "just because"

• [17:38] <pitti> only if we need the space

• [17:38] <seb128> same here

• [17:38] <asac> right agreed.

• [17:39] <rickspencer3> what about my point that it is a power user tool that is redundant with f-spot for most users?

• [17:39] <seb128> gimp is maybe not the most user friendly application but it has its users and is a well known opensource project

• [17:39] <calc> i had heard someone mention a lot of the disk space usage of gimp is its documentation? i may be confused though

• [17:39] <pitti> f-spot is not even close to a photo editor

• [17:39] <seb128> well if we consider that image editing is limited to photo

• [17:39] <pitti> calc: yes, 20 MB docs vs. 6 MB app

• [17:39] <bryce> could gimp be stripped down to a gimp-lite or something, e.g. removing most of the modules, palettes, etc.?

• [17:39] <rickspencer3> pitti: but for most users photo editor = crop, rotation, red-eye removal

• [17:39] <calc> pitti: perhaps we can get rid of the docs? lol

• [17:39] <seb128> rickspencer3: image != photo though

• [17:40] <seb128> do you import your screenshots in fspot?

• [17:40] <rickspencer3> seb128: right

• [17:40] <pitti> calc: we want to reorganize language-support-* a bit, but not sure whether we want to drop the English documentatino

• [17:40] <seb128> I use gimp when I've to resize a screenshot for example

• [17:40] <calc> pitti: ok

• [17:40] <rickspencer3> seb128: does not f-spot handle that?

• [17:40] <pitti> seb128: ... or for just about anoything else

• [17:40] <seb128> I don't import my screenshot in f-spot

• [17:40] <rickspencer3> this is true

• [17:40] <seb128> f-spot handle my photos

• [17:40] <rickspencer3> the "import" requirement is onerous

• [17:40] <pitti> in fact, gvfs-gphoto makes me not use any f-spot/gthumb etc. at all any more

• [17:40] <seb128> sort those by exif tags, etc

• [17:41] * calc personally doesn't like apps that take over his data like fspot, itunes, etc, but ymmv

• [17:41] <rickspencer3> I wish that the gnome image viewer did cropping, red-eye, and annotation (like you could paint on it)

• [17:41] <ArneGoetje> I use gimp for scanning documents with my flatbed scanner.

• [17:41] <bryce> calc: same

• [17:41] <rickspencer3> we all know that GIMP is useful

• [17:41] <rickspencer3> the question is, does it belong on the CD

• [17:41] <rickspencer3> ?

• [17:41] <pitti> I'd be inclined to stop shipping the documentatin

• [17:41] <seb128> what problem do we try to solve?

• [17:42] <asac> if we have a good replacement for all important use-cases then no.

• [17:42] <pitti> and change it so that F1 leads to a browser with the online documentatino

• [17:42] <seb128> win CD space?

• [17:42] <pitti> it already opens a browser anyway

• [17:42] <rickspencer3> pitti: because it is so easy to use, no one needs to docs?

• [17:42] <rickspencer3> </sarcasm>

• [17:42] <seb128> reduce user confusion to have different applications to do a similar job?

• [17:42] <asac> but i would hate to have like 4 apps covering those use-cases. at best we have a single lean app that does all the main use cases

• [17:42] <pitti> rickspencer3: no, but not everyone might need them locally installed

• [17:42] <rickspencer3> seb128: both points

• [17:42] <seb128> if we need CD space I vote for dropping it

• [17:42] <rickspencer3> seb128: that seems to be the consensus

• [17:42] <bryce> rickspencer3: I would think from a larger view, that we ought to include as many applications (or at least, as most functionality) as possible on the cd.

• [17:42] <rickspencer3> not strong will to remoe it

• [17:42] <seb128> if we don't I vote for keeping it, it replies to some need we would not fit otherwise

• [17:43] <pitti> ^ seems that's the consensus then

• [17:43] <rickspencer3> bryce: except we should not have overlapping apps in terms of functionality

• [17:43] <seb128> well, I would love to ship a small gtk image editor easy to use with basic features if we had one

• [17:43] <seb128> do we have one application matching this definition?

• [17:43] <rickspencer3> seb128: lets build an image editor in quickly!

• [17:43] <seb128>

• [17:43] <rickspencer3> there's a sweet python image library

• [17:44] <rickspencer3> ok, I'll capture the POR as:

• [17:44] * kenvandine thinks f-spot should have a edit mode without using the library

• [17:44] <rickspencer3> 1. keep GIMP unless we need room

• [17:44] <kenvandine> like it has a viewer now

• [17:44] <rickspencer3> 2. if we need room, try web documentation only

• [17:44] <seb128> kenvandine: can you resize images in f-spot?

• [17:44] <rickspencer3> 3. If we still need room, remove from the disk

• [17:44] <pitti> +1

• [17:44] <kenvandine> seb128: not in the viewer, on in the library

• [17:44] <seb128> +1

• [17:44] <calc> +1

• [17:44] <ArneGoetje> +1

• [17:44] <awe> +1

• [17:44] <kenvandine> +1

• [17:45] <rickspencer3> sweet

• [17:45] <rickspencer3> next topic

• [17:45] <rickspencer3> Blueprints, specs, burndowns

• [17:45] <rickspencer3> I suppose I should turn the mic over to pitti

• [17:45] * rickspencer3 apologizes for not telling pitti about this topic before now

• [17:45] <pitti> https://blueprints.edge.launchpad.net/ubuntu/karmic/+specs?searchtext=desktop-karmic

• [17:45] <pitti> so, good job everyone so far

• [17:46] <pitti> we have about half of them approved

• [17:46] <pitti> please try to get your remaining ones drafted by next meeting

• [17:46] <pitti> I usually review them within 4 hours (or on next morning)

• [17:46] <pitti> the only outstanding review is for rickspencer3 to do

• [17:47] <rickspencer3> *cough*

• [17:47] <rickspencer3> in terms of burndowns, what is the timeline for getting that system set up?

• [17:47] <pitti> any questions about them?

• [17:47] * rickspencer3 is about 5 seconds in the future

• [17:47] <pitti> FYI, I also did a "karmic crack summary" on https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus

• [17:48] <pitti> for burndowns we need to agree on how to define work items

• [17:48] <pitti> my proposal is to keep it very simple

• [17:48] <seb128> what do we call "burndown" there?

• [17:48] <pitti> add something like this to the blueprint's whiteboard:

• [17:48] <pitti> Work items:

• [17:48] <pitti> do foo:TODO

• [17:48] <pitti> do bar:DONE

• [17:48] <pitti> do baz:POSTPONED

• [17:48] <pitti> ---

• [17:49] <rickspencer3> so track on the white board, not in bugs?

• [17:49] <pitti> and then have the script parse them

• [17:49] <pitti> rickspencer3: well, that's the thing I'm not sure about

• [17:49] <pitti> rickspencer3: we could either transform the WIs to bugs and track the status there

• [17:49] <pitti> or just use blueprints exclusively

• [17:49] <asac> pitti: i would love to be able to add work items directly to the spec wiki pages and have a bot that assembles a central list

• [17:49] <rickspencer3> hmmm

• [17:49] <pitti> the latter is easier to set up

• [17:49] <rickspencer3> thoughts?

• [17:49] <pitti> the former has the advantage that some work items aren't attached to specs

• [17:50] <rickspencer3> I would go with "easier to set up" in the meantime

• [17:50] <pitti> so the burndown script needs to be able to collect bugs anyway

• [17:50] <seb128> I've difficulties to understand what is "burndown" there and what we try to solve

• [17:50] <rickspencer3> so basically it would wget, parse, and pipe the info into the script?

• [17:50] <pitti> seb128: track number of open/done work items over time

• [17:50] <seb128> related to specs?

• [17:50] <rickspencer3> seb128: this is a graph that compares work done compared to work left over time

• [17:50] <seb128> or any items?

• [17:50] <asac> seb128: remember the workitems list with the chart we tried last cycle? the idea is to improve that

• [17:50] <pitti> seb128: to feature work in general, except bugs

• [17:50] <rickspencer3> seb128: I think related to specs

• [17:51] <seb128> ok thanks

• [17:51] <pitti> I think we should start with blueprints only

• [17:51] <pitti> and then extend the system to also track bugs

• [17:51] <pitti> and if we like it, we might go to change the bug states instead of the whiteboards

• [17:52] <rickspencer3> seb128: I'll send you a link to one from last team meeting when I find one

• [17:52] <pitti> rickspencer3: WDYT?

• [17:52] <seb128> rickspencer3: thanks

• [17:52] <rickspencer3> pitti: I think of bugs as different than work items

• [17:52] <pitti> rickspencer3: no, not "bugs against nautilus"

• [17:52] <rickspencer3> I see

• [17:52] <rickspencer3> you are right

• [17:52] <rickspencer3> (natch)

• [17:52] <pitti> but "bugs against desktop-team-workitems" as a mere means of tracking status and assignee

• [17:53] <rickspencer3> pitti: agreed

• [17:53] <rickspencer3> I think that you are right that starting with the simpler system is best

• [17:53] <asac> so do i understand correctly that we will have some syntax to highlight work items in the spec wiki pages?

• [17:53] <kenvandine> +1

• [17:53] <pitti> e. g. I have a task for "speed up gnome-panel" which doesn't have a spec

• [17:53] <rickspencer3> asac: the white board, I think

• [17:53] <pitti> but it takes me about the same time to create a blueprint as it takes me to create a work item bug report

• [17:54] <pitti> asac: wiki page is another possibility

• [17:54] <seb128> pitti: you don't suggest creating a blueprint to speed up gnome-panel do you?

• [17:54] <rickspencer3> the white board seems meant to track status

• [17:54] <pitti> but whiteboard tracks the metadata/status already, so it would be appropriate; you disagree?

• [17:54] <asac> i think we can start with whiteboard now

• [17:54] <pitti> seb128: *shrug* why not; it doesn't need a wiki page, just a whiteboard, assignee, and short summary

• [17:54] <pitti> seb128: like "cache desktop file read, cache translations, speed up xxx", etc.

• [17:55] <seb128> yet another system to track, *shrug*

• [17:55] <seb128> I would rather use standard launchpad bugs

• [17:55] <pitti> well, you need to track your blueprints anyway..

• [17:56] <rickspencer3> I think it makes sense to start with blueprints, and then extend it to bugs, perhaps a hybrid

• [17:56] <awe> pitti: couldn't the script create launchpad bugs automatically?

• [17:56] <pitti> awe: sure, it could

• [17:56] <asac> pitti: if possible allow us to assign specific subtasks to someone else like foo@pitti:DONE

• [17:56] <seb128> I will follow what other people decide but I've a dislike for blueprints in launchpad

• [17:56] <asac> with the spec assignee being the default

• [17:57] <seb128> those are out of my workflow, not easy to sort of filter, etc, etc

• [17:57] <awe> seb128: +1

• [17:57] <pitti> asac: well, the purpose is just a cumulative status, we don't actually need to track assignees

• [17:57] <rickspencer3> hmmm

• [17:57] <asac> for me the main use case is to look at this list and see what tasks i have left

• [17:57] <pitti> but bugs are fine for me, just complicate the system somewhat

• [17:57] <rickspencer3> pitti: it seems that some people are more bug-centric and some are more blueprint-centric

• [17:57] <asac> (at least from the assignee perspective)

• [17:57] <seb128> I think blueprint complicate the system, we work on bugs usually and our workflow and tools are designed for those

• [17:57] * kenvandine thinks bugs are easier

• [17:57] <pitti> for the people who prefer bugs, would you create those bugs manually?

• [17:58] <kenvandine> pitti: sure

• [17:58] <pitti> if not, it doesn't make sense to me to define the work items at one place and track them somewhere else

• [17:58] <pitti> kenvandine: but that's hard!

• [17:58] <kenvandine> pitti: problem is... we need some umbrella

• [17:58] <asac> i think making bugs mandatory is too heavy

• [17:58] <rickspencer3> pitti: is it so hard?

• [17:58] <kenvandine> so a way to group them together

• [17:58] <kenvandine> it isn't hard at all

• [17:58] <ArneGoetje> how would we file work items as bugs?

• [17:58] <kenvandine> we do it all the time

• [17:58] <pitti> s/hard/cumbersome/

• [17:58] <rickspencer3> hmmm

• [17:59] <rickspencer3> ArneGoetje: I think just tag them "work-item" or such

• [17:59] <rickspencer3> could be time-consuming, yes

• [17:59] <ArneGoetje> I mean, file against which project?

• [17:59] <kenvandine> i think the hard part is organizing them... it would be nice to have a umbrella (blueprint) linked to all the associated bugs

• [17:59] <seb128> whatever needs being worked?

• [17:59] <pitti> you need to find the right project, right tags, set assignee, wait for LP, etc.

• [17:59] <seb128> changes land to ubuntu so their always concern an ubuntu component

• [17:59] <pitti> and link them to blueprints, etc.

• [17:59] <pitti> seb128: not true

• [17:59] <pitti> apport-retracer-enhancements

• [18:00] <pitti> xorg-testing-infrastructure

• [18:00] <seb128> hum ok

• [18:00] <pitti> help-stripping-in-soyuz

• [18:00] <pitti> compiz-bug-workflow

• [18:00] <kenvandine> LP isn't designed to be used for project management, i agree

• [18:00] <rickspencer3> kenvandine: seb128: awe: would you be willing to try the blueprint way?

• [18:00] <seb128> pitti: 1 example was enough

• [18:00] <kenvandine> rickspencer3: sure... willing to

• [18:00] <rickspencer3> I think it would be much faster to get the burn down chart going

• [18:00] <rickspencer3> and then I could start sleeping at night

• [18:00] * kenvandine misses jira

• [18:00] <seb128> rickspencer3: well, you are the one deciding there so sure, I will try what you say

• [18:00] <kenvandine> it was great at that stuff

• [18:00] <awe> rickspencer3: sure

• [18:01] <kenvandine> rickspencer3: we want you to sleep!

• [18:01] <rickspencer3> seb128: are you granting me dictatorial powers?

• [18:01] <pitti> and we want to look at charts pointing downwards to 0!

• [18:01] <rickspencer3> because if so, my car needs washing badly, and also my roof ...

• [18:01] <rickspencer3>

• [18:01] <kenvandine> hehe

• [18:01] <seb128> rickspencer3: would you like to be granted dictatorial powers?

• [18:01] <rickspencer3> too much responsibility

• [18:02] <seb128> rickspencer3: joke aside I strongly dislike blueprint because they are paperwork usually and don't fit my workflow but I'm fine using those we already do for specs

• [18:02] <seb128> lol

• [18:02] * seb128 really think we need a task tracking system

• [18:02] <rickspencer3> let us start with the blueprint method, with the understanding that we will be enhancing the system to accommodate more workflows

• [18:03] <rickspencer3> seb128: that's another option entirely

• [18:03] <rickspencer3> we could probably hop on some web app designed for this

• [18:03] <seb128> let's start with the blueprint use for now, quick and easy

• [18:03] <pitti> I do think we need to extend it to use whiteboard AND bugs

• [18:03] <seb128> we can figure better ways later

• [18:03] <rickspencer3> but that would be *yet another* place to track

• [18:03] <pitti> then seb128/awe can switch to bugs if they want

• [18:03] <rickspencer3> pitti: agreed

• [18:03] <bryce> rickspencer3: no more places to track please

• [18:03] <pitti> bug TRACKer

• [18:03] <rickspencer3> can I say the POR is that we will create a simple whiteboard based system to start

• [18:03] * kenvandine thinks LP should have task management added

• [18:04] <kenvandine> rickspencer3: yup

• [18:04] <rickspencer3> and that we will extend it to use bugs if desired?

• [18:04] <bryce> personally I kind of like the blueprint system, however I admit I've grown to not rely on it very much. Honestly it provides little benefit that couldn't be replicated easily with bugs + a wiki page

• [18:04] <pitti> kenvandine: bugs against a special project do pretty much that

• [18:04] <kenvandine> pitti: mostly yes

• [18:05] <seb128> pitti: we need bugs against teams

• [18:05] <rickspencer3> pitti: do you have info you need? can we move on, topic-wise?

• [18:05] <bryce> maybe with lp going open source, if the blueprint system code is included, it could be improved and better integrated with bugs

• [18:05] <pitti> rickspencer3: fine for me

• [18:05] <rickspencer3> all? next topic?

• [18:05] <pitti> rickspencer3: do you own that?

• [18:05] <seb128> next!

• [18:05] <kenvandine> long meeting today

• [18:05] <rickspencer3> pitti: I think we own it jointly

• [18:06] <rickspencer3> lets discuss tomorrow in our call

• [18:06] <pitti> yep

• [18:06] <rickspencer3> I can do the work if needed

• [18:06] <rickspencer3> very related topic:

• [18:06] <rickspencer3> Bug hygiene

• [18:06] * pitti gets the spray

• [18:06] <rickspencer3> by this I mean ... I would prefer it if bugs assigned to team members were bugs that were going to be fixed by those team members in the near future

• [18:07] <rickspencer3> some of us have lots and lots and lots of bugs assigned

• [18:07] <rickspencer3> thoughts?

• [18:07] <asac> feel free to unassign me from everything (assuming you have the script ready for that)

• [18:08] <rickspencer3> asac: seriously?

• [18:08] <seb128> I tend to assign me bugs I'm going to work on during the current cycle

• [18:08] <asac> well. i dont really use assignments atm for anything but priortizing bug mail.

• [18:08] <pitti> https://launchpad.net/people/+me/+assignedbugs should be honest and realistic indeed

• [18:08] <seb128> not sure what "near future" you envision though

• [18:08] <seb128> one cycle?

• [18:08] <bryce> rickspencer3: I generally use assignment more like a bookmark, for bugs I know that are either clear now how to fix, or that I really don't want to lose track of for whatever reason

• [18:08] <rickspencer3> seb128: what do you think would be a good time frame?

• [18:08] <awe> rickspencer3: what about the analysis phase? ie. should a bug be assigned to someone that's trying to determine the cause? then unassigned if it's too invasive, not possible to fix?

• [18:09] <pitti> both as a tool for yourself to track your work, as a means to say "no" to more work, and for release management

• [18:09] <seb128> rickspencer3: as said "current cycle" is my usual metric

• [18:09] <pitti> time frame> karmic beta?

• [18:09] <asac> and release team ... so unassign everything that isnt on release team radar maybe.

• [18:09] <pitti> "karmic"

• [18:09] <pitti> awe: that's fine

• [18:09] <pitti> if you have a bug which you realistically aren't going to work on, it's _much_ better to unassign yourself

• [18:09] <rickspencer3> let's start with seb128's definition of "near future" = current release

• [18:10] <bryce> I don't like the idea of using assignment for tracking my work, for a couple reasons...

• [18:10] <pitti> that way it's clear for others that nobody owns it, and that it's free for community involvement

• [18:10] <rickspencer3> awe: that sounds fine to me

• [18:10] <pitti> bryce: I'm curious, why?

• [18:10] <kenvandine> bryce: funny... that is exactly what i want to use it for

• [18:10] <bryce> 1. many of the high importance bugs I work on get a CRAPLOAD of bug mail, and I don't want to be buried by it (e.g. the freeze bugs, the perf bugs...)

• [18:10] <kenvandine> and the definition actually:)

• [18:10] <seb128> bryce: what other way to track your tasks do you use?

• [18:10] <pitti> I find +assignedbugs a very valuable tool

• [18:11] <bryce> 2. I work on a lot of bugs without wanting to *commit* to fixing them, until a patch is available and proven to work

• [18:11] <pitti> bryce: but that's a question of filtering, not keeping a realistic +assignedbugs list, certainly?

• [18:11] <pitti> 2. sounds like a case for subscription, not assignment

• [18:11] <bryce> pitti: filtering?

• === onestone_ is now known as onestone

• [18:12] <awe> pitti: do you use milestones to denote bugs that are committed to being fixed?

• [18:12] <pitti> bryce: routing that bug mail to a different mailbox

• [18:12] <pitti> awe: very seldomly; only for the crucial release blockers

• [18:12] <pitti> awe: if I commit to fix a bug, I assign it

• [18:12] <bryce> pitti: well mail from assigned bugs goes to my INBOX (same as subscribed bugs)

• [18:12] <pitti> awe: conversely, if I say "I won't work on that", I unassign

• [18:13] <pitti> bryce: but if you are working on them, don't you want them?

• [18:13] <bryce> pitti: erm, you've seen that 500+ comment x freeze bug

• [18:13] <rickspencer3> I think that there is a legitimate need on the part of stake holders to be able to look at the current set of bugs, and know what is being worked, what is not being worked on, what won't be worked on, etc...

• [18:13] <rickspencer3> I suspect this will take some effort on our part to be consistent in how we handle bugs

• [18:14] <rickspencer3> there are too many ambiguous states right now that a bug can get into

• [18:14] <rickspencer3> this creates a lot of work and confusion

• [18:14] <rickspencer3> thoughts?

• [18:15] <pitti> bryce: yeah, but most of it was just "look and delete" fortunately

• [18:15] <pitti> bryce: so, if the bug mail is a problem, my feeling is that this is a different problem than the assignment of bugs; WDYT?

• [18:16] <rickspencer3> bryce: for instance, the fact that you and seb128 and asac each handle bugs differently means that I have to know your idiosyncrasies to understand the "bugscape" and well as the status of individual bugs

• [18:16] <pitti> s/I/everyone/

• [18:17] <pitti> bryce: I'm curious, how do you track the ones you work on then?

• [18:17] <bryce> pitti: it may be a different problem, but if so we need a better way of managing it...

• [18:17] <kenvandine> i think it is important that everyone agrees on the state assigned, and i think the general user base thinks that means someone is working on it or planning to work on it

• [18:17] <seb128> rickspencer3: what do you try to track? things we are working on and things important for the next milestone I guess?

• [18:18] <seb128> so milestoned bugs and assigned bugs?

• [18:18] <rickspencer3> seb128: I think different people looking at the bugs have different needs

• [18:18] <seb128> ie what is the problem we try to solve?

• [18:18] <bryce> pitti: I usually use queries/reports heavily to identify bugs to work on, and maintain a todo list of ones I'm tracking closely

• [18:19] <rickspencer3> okay, I think we need a deeper dive on this than we will be able to get here

• [18:19] <bryce> pitti: I used to use 'assigned' as my todo list of things I'm working on, but the two problems I mentioned earlier lead to me stopping

• [18:19] <asac> i think we can agree that we shouldnt be assigned to bugs if we are not working on them

• [18:19] <pitti> seb128: we need a common workflow in order to work effectively

• [18:19] <pitti> first for everyone to manage workload

• [18:19] <asac> also we already agree how to properly mark bugs so they get on the release team radar

• [18:19] <rickspencer3> so let's cut this off, but pick it up next week with more definition

• [18:19] <asac> for everything else we should really ask ourselve what we are trying to solve (like seb128 said)

• [18:20] * rickspencer3 sorry to have opened a can of works without a broom handy

• [18:20] <pitti> and second, if someone (release team, me, you) assign a bug to someone else, we need some commitment to get a reply, a fix, or an unassignment

• [18:20] <seb128> lol

• [18:20] <seb128> pitti: I don't think you can fit differently minds in a same workflow though

• [18:20] <asac> i think pitti's reason is valid. but that means: "assignment == commitment to respond" and not "fix"

• [18:20] <seb128> everybody has a workflow adapted to the way he,she is working

• [18:21] <seb128> or thinking

• [18:21] <rickspencer3> For my part, I strongly agree with pitti on this point

• [18:21] <rickspencer3> can we pick this up next week?

• [18:21] * bryce agrees with seb128

• [18:21] <seb128> sure

• [18:21] <seb128> I'm happy to keep discussing that here out of the meeting too

• [18:21] <pitti> but if everyone has an arbitrarily different method, it doesn't help anyone either

• [18:22] <seb128> right, which is why we should start by stating what are the issue and what we try to solve

• [18:22] <seb128> ie "we don't have a coherent way to track what tasks are being worked right now"

• [18:22] <seb128> just "people work differently" is not an issue

• [18:22] <bryce> right

• [18:22] <pitti> "track tasks being worked on" is a very important piece here

• [18:23] <pitti> both for you and for anyone else

• [18:23] <seb128> yes, I agree

• [18:23] <seb128> I'm just trying to understand the scope of what you try to achieve

• [18:23] <rickspencer3> there is a set of problems, and we should do well to define those

• [18:23] <seb128> is that the only goal?

• [18:23] <pitti> bugs which have an assignee, and nto being worked on for years is obviously bad

• [18:23] <seb128> right too

• [18:23] <seb128> can we get a list of those issues

• [18:23] <seb128> then we can work on adressing the issues

• [18:23] <pitti> and if your +assignedbugs is 500 items, it's useless for you to manage your work

• [18:23] <seb128> ?

• [18:23] <rickspencer3> internal partners don't know what the status of bugs mean

• [18:24] <seb128> I agree with all that

• [18:24] <bryce> I would say that if the goal is to track what people are working on, there's probably much better ways than using bug assignment

• [18:24] <rickspencer3> users have unrealistic expectations about how bugs will be handled and solved

• [18:24] <pitti> it's not about users, it's about us

• [18:24] <rickspencer3> there is no way to assess the general quality of the project

• [18:24] <rickspencer3> individual engineers have no way to control their bug related work load

• [18:24] <seb128> let's defer this discussion to after meeting with interested people?

• [18:24] <seb128> and reschedule for next week?

• [18:25] <bryce> ok

• [18:25] <rickspencer3> etc...

• [18:25] <rickspencer3> seb128: right

• [18:25] <seb128> so we have a better scope next week?

• [18:25] <awe> +1

• [18:25] <ArneGoetje> +1

• [18:25] <rickspencer3> good

• [18:25] <rickspencer3> almost done

• [18:26] <rickspencer3> speaking of bugs, I see a slew of assigned *and* release targeted bugs for releases going back to dapper

• [18:26] <rickspencer3> should I be concerned?

• [18:26] <rickspencer3> (see wiki page for the lists)

• [18:26] <seb128> we should probably review the list and clean those

• [18:26] <bryce> rickspencer3: that happens a lot

• [18:27] <rickspencer3> this is maybe a little too close to the last topic

• [18:27] <rickspencer3> so let's move on?

• [18:27] <rickspencer3> next: Team Meeting: Eastern Edition

• [18:27] <rickspencer3> * Luke, Robert, and I will be arranging a secondary team meeting to follow up from the main one.

• [18:27] <rickspencer3> * This is designed to ensure that everyone stays up to date, without the need to disrupt their sleep.

• [18:27] <rickspencer3> * Anyone else interested in joining, feel free

• [18:27] <rickspencer3> ArneGoetje: ?

• [18:27] <rickspencer3> this will be weekly as well

• [18:27] <ArneGoetje> rickspencer3: depends on the meeting time

• [18:28] <asac> what time?

• [18:28] <rickspencer3> asac: ArneGoetje: I left that to Luke and Robert to decide

• [18:28] <rickspencer3> I presume it will be in my evening, their morning, and your middle of the night

• [18:28] <seb128> depends of the middle of the night

• [18:29] <seb128> if that's around midnight I will probably join some of those

• [18:29] <ArneGoetje> rickspencer3: let's see what they come up with.

• [18:29] <seb128> if that's later probably not

• [18:29] <rickspencer3> ArneGoetje: seb128: asac: feel free to discuss with them

• [18:29] <seb128> anyway let's see what they pick

• [18:29] <rickspencer3> ok

• [18:29] <rickspencer3> any other business?

---

CategoryDesktopTeam

Back to DesktopTeam.