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

Meeting Minutes

Present

Main Meeting

• Rick Spencer (rickspencer3) - chair
• Alberto Milone (tseliot)

• Arne Goetje (ArneGoetje)

• Bryce Harrington (bryce)
• Chris Cheney (ccheney)

• Ken VanDine (kenvandine)

• Martin Pitt (pitti)
• Sebastien Bacher (seb128)

Eastern Edition

• Luke Yelavich (TheMuso)

Apologies

• Till Kamppeter (tkamppeter) - vacation
• Jonathan Riddell (Riddell) - vacation
• Robert Ancell (robert_ancell)

Agenda

• Outstanding actions from last meeting
• Partner Update
• Kubuntu Update
• Mozilla Update
• Release Bugs/Release Status
• Review activity reports
• Any other business

Actions from this meeting

• RESULT: ACTION: rickspencer3 to follow up on conference attendance with randa and team
• ACTION: pitti to create a proposed a3 work item list.

Outstanding actions from last meeting

• ACTION: Martin to create conference attendance wiki page and ask team for adding themselves to it by mail
  • RESULT: ACTION: rickspencer3 to follow up on this with randa and team

Partner Update

• Weekly releases

• This Thursday's release will be the last release of Dx bits that will be in Alpha 2
• OLS is finalizing their planning while also working, especially on server side components

Mozilla Update

ccheney is backporting epiphany-browser along with its dependencies: libsoup2.4, webkit, etc... Because they use newer glib2.0 than what is in hardy he plans to copy the needed functions over so we won't need a full backport of glib as well.

Release Status

• Desktop team is considerably above the trend line, 27 active items, but there should be about 13. Work items will be completed or postponed until we are under the trend line by eow.
• Discussed planning for a3 iteration. rickspencer3 proposes that the desktop team pursue fewer total work items than were completed in a2 in order to leave time for integration and bug fixing. rickspencer3 further proposes that the desktop team bring few if any work items into the final iteration. In this way, making the a3 milestone the last development milestone for the desktop team, again to focus on bug fixing and integration.
• ACTION: pitti to create a proposed a3 work item list.

Bugs

Bug counts seem normal, but the team is still striving for more efficient bug management. rickspencer3 generated a report of all bugs assigned to a package that someone on the canonical-desktop-team is subscribed to. This list is almost 15,000 bugs. rickspencer3 to analyze for potential hot spots.

• ACTION: rickspencer3 to attach bug list to wiki.

New Bugs

46 New bugs are assigned

High/Critical Bugs

62 Critical or High bugs are assigned

Activity reports

Alberto Milone (tseliot)

Blueprint work:

• desktop-lucid-xorg-proprietary-drivers:
  • Implemented the new alternatives system and put the following modified packages in my PPA for testing: libxvmc nvidia-common nvidia-graphics-drivers nvidia-graphics-drivers-173 nvidia-graphics-drivers-96 nvidia-settings screen-resolution-extra xorg-server.
  • Added a utility class for alternatives in nvidia-common and adapted the logic behind driver selection to the new name schemes of the drivers.
  • Updated Jockey (in a bzr branch) so that it can use the new nvidia common and disabled fglrx (as currently it doesn't work with Lucid's X).

  • Updated nvidia-settings, changed its packaging and added support for PolicyKit (thanks to screen-resolution-extra).

• desktop-lucid-touchscreen-handling:
  • Stantum kindly offered to lend me and Peter Hutterer (Red Hat) a 12" multitouch touchscreen developer toolkit to help us implement multitouch in X.Org.

Non-blueprint work:

• Discussing with upstream, namely Peter Hutterer and Dan Nicholson for X and Martin for udev, the design of a new system for using quirks for touchpad and input devices in general.
• Became Core developer.

Arne Goetje (ArneGoetje)

Blueprint work:

• desktop-lucid-ibus-chinese: face to face meeting with other local developers who are interested in his project and have done major development work on existing Chinese input methods, including James Su (author of SCIM) and Tung-han Hsieh (author of xcin). Agreed to set up a mailing list for group conversations and to do some work on unifying the different existing wordlists.

Non-blueprint work:

• uploaded new Firefox translations into Rosetta for Hardy, Intrepid, Jaunty, Karmic and Lucid
• installed Launchpad source on my machine in order to debug translation import problems
• Rosetta import queue cleaning

Bryce Harrington (bryce)

• Wrote test plan for projector use case
• Generalizing arsenal scripts for use with bughugger
• Worked with community members to reorganize X wiki docs
• Rewrote rethrow signals patch for xserver 1.7 to enable apport tested and uploaded to Lucid
• Improvements to patches report web page - show # items, fix formatting.
• Updated the -ati package snapshot
• Wayland
  • Tested building older git versions to get around dependency on drm pageflip kernel branch
  • Created packaging for libeagle
  • Created packaging for wayland
• Catchup email/todo list from holidays
• Contact Intel regarding libdrm/mesa bug blocking us from upgrading

Chris Cheney (ccheney)

Blueprint work:

• desktop-lucid-new-firefox-support-model
  • backporting epiphany-browser, libproxy, libsoup2.4, webkit, etc

Ken VanDine (kenvandine)

Blueprint work:

• desktop-lucid-social-from-the-start
  • desktopcouch message store and configuration storage should land in trunk today or tomorrow
  • new accounts configuration interface is nearly complete, will hopefully land in trunk this week
  • worked on the dbus/python interfaces
• desktop-lucid-empathy-indicator
  • Bumped empathy to 2.29.4

Luke Yelavich (TheMuso)

Accessibility

• Involved with various discussions relating to how audio needs to be handled for the console accessibility use case which many blind linux users are still pushing for. The issue in question is how to allow a screen reader to read a text login prompt on a VT, and have the text spoken. It is thought that consolekit needs to have some setup/user/mechaism to set audio device permissions to a particular UID, which the screen reader/pulseaudio can then make use of for text login prompts. The user session would then run the screen reader/audio bits as normal.
• Received more patches relating to better pulseaudio performance with speech-dispatcher, these have yet to be tested.

Audio

• Audio bug triaging, bugs in question are against pulseaudio, alsa userspace, and the kernel for hardware enablement.
• Managed to get all the mac mini 3,1 audio inputs/outputs working, using hda analyser. I have also started working on the alsa hda driver patch to make it all just work, however further research into hda channel modes, and a few NIDs for pins/mixers still needs to be done, and the patch completed.
• Started working on package updates to make another attempt at allowing an AC# audio stream to be generated from pulseaudio multi-channel output. Of course it cannot be shipped on the disks, but it would be a good option to give users should they wish to send a 5.1 audio signal to their sound system via optical/coaxial S/PDIF cabling.

Accessibility

• Involved with various discussions relating to how audio needs to be handled for the console accessibility use case which many blind linux users are still pushing for. The issue in question is how to allow a screen reader to read a text login prompt on a VT, and have the text spoken. It is thought that consolekit needs to have some setup/user/mechaism to set audio device permissions to a particular UID, which the screen reader/pulseaudio can then make use of for text login prompts. The user session would then run the screen reader/audio bits as normal.
• Received more patches relating to better pulseaudio performance with speech-dispatcher, these have yet to be tested.

Audio

• Audio bug triaging, bugs in question are against pulseaudio, alsa userspace, and the kernel for hardware enablement.
• Managed to get all the mac mini 3,1 audio inputs/outputs working, using hda analyser. I have also started working on the alsa hda driver patch to make it all just work, however further research into hda channel modes, and a few NIDs for pins/mixers still needs to be done, and the patch completed.
• Started working on package updates to make another attempt at allowing an AC# audio stream to be generated from pulseaudio multi-channel output. Of course it cannot be shipped on the disks, but it would be a good option to give users should they wish to send a 5.1 audio signal to their sound system via optical/coaxial S/PDIF cabling.

Martin Pitt (pitti)

Assigned blueprints:

• desktop-lucid-likewise-open-migration: upstream completed all upgrade scenarios, went through first round of review
• desktop-lucid-jockey-hotplug-support: beta available
• desktop-lucid-suspend-quirks-halsectomy (beta available): no progress this week, needs testing
• desktop-lucid-xorg-halsectomy: no progress this week; needs new wacom driver (Bryce's WI)
• desktop-lucid-powermanagement-tweaks: implemented

Non-blueprint work done:

• DMB meeting
• Bug fixing: apport, udev, python-distutils-extra, postgresql-8.4, hal
• Documented SRU procedure and tools
• Improved glib assertion message storing patch, got it upstream
• Desktop startup speed:
  • improved udev-acl speed
  • Speed up nautilus brasero extension loading
• Some Apport retracer maintenance
• Reviewed current MIR process, proposed simplification, announced
• tzdata update for stables

Sponsoring:

• erlang, postgis, pyxdg, simple-scan, xorg-server (jaunty)

Robert Ancell (robert_ancell)

Sebastien Bacher (seb128)

• catching up after two weeks of holidays
• updated evince
• pitivi mir bug

IRC Log

[16:31] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-01-05<<BR>> [16:31] <rickspencer3> shall we start?
[16:32] <kenvandine> yup
[16:32] * tseliot nods
[16:32] <rickspencer3> first item was outstanding items from last meeting
[16:32] <rickspencer3> this was something about pitti creating a wiki for even attendance
[16:33] <rickspencer3> Martin to create conference attendance wiki page and ask team for adding themselves to it by mail
[16:33] <rickspencer3> did we do anything with that?
[16:33] <rickspencer3> I can ping randa and see if she has everything she needs from us
[16:33] <rickspencer3> has everyone indicated their interest in meetings to attend?
[16:34] <rickspencer3> meetings, conferences, parties, etc...
[16:34] <seb128> I didn't
[16:34] * rickspencer3 tap tap, is this thing on?
[16:34] <seb128> I've not noticed any ping or wiki page or anything for that
[16:34] <kenvandine> hehe
[16:34] <kenvandine> there was something...
[16:34] <seb128> I want to go to GUADEC though ;-)
[16:34] <ccheney> url?
[16:34] <rickspencer3> ACTION: rickspencer3 to round up event attendance
[16:34] <rickspencer3> let's take this into email
[16:34] <kenvandine> maybe an email
[16:34] <seb128> I might have overspammed things when coming back
[16:34] <seb128> I had some thousands spams in my inbox
[16:35] <tseliot> attendance? I think I missed this
[16:35] <rickspencer3> tseliot, if you want to attend a conference or event next year, you can tell randa now, and it will be much easier for you to arrange
[16:35] <tseliot> rickspencer3: ah, ok
[16:35] <rickspencer3> I'll send an email and we can get this done that way
[16:35] <rickspencer3> shall we move on?
[16:36] <kenvandine> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-12-08<<BR>> [16:36] <kenvandine> there list is there... maybe he was going to move it somewhere
[16:36] <rickspencer3> ok
[16:36] <rickspencer3> kenvandine, partner update?
[16:36] <kenvandine> ok
[16:37] <kenvandine> there will be some more DX releases this week
[16:37] <kenvandine> which will cover what will end up in alpha2
[16:37] <kenvandine> OLS won't have anything for the desktop in alpha2
[16:37] <kenvandine> but they feel they are on track, mostly
[16:37] <kenvandine> some server side nightmares
[16:38] <kenvandine> but desktop stuff seems ok... even though their work items are trending the wrong way
[16:38] <kenvandine> they just added more work items to match reality, and plan to catch up
[16:38] <kenvandine> we will monitor that
[16:38] <kenvandine> but again, nothing from them until alpha3
[16:38] <rickspencer3> kenvandine, Dx seems rather over their trend-line
[16:38] <kenvandine> a bit
[16:39] <rickspencer3> "a bit" seems maybe an underestimate
[16:39] <kenvandine> that is all i have for now
[16:39] <kenvandine> hehe... well not as bad as OLS
[16:40] <rickspencer3> kenvandine, have they discussed what is going to be in for a2 versus what will be postponed?
[16:40] <kenvandine> we discussed that on monday
[16:40] <kenvandine> i haven't tried to line that up with what they have targeted work items wise though
[16:40] <kenvandine> we should do that so we can adjust work items accordingly
[16:41] <rickspencer3> ok
[16:41] <rickspencer3> I have a meeting with dbarth tomorrow, I'll discuss with him tomorrow and let the desktop team know if I learn anything new
[16:41] <rickspencer3> next is Kubuntu update, but Riddell is on vacation
[16:41] <rickspencer3> so ccheney, Mozilla update?
[16:42] <ccheney> i am currently working on backporting epiphany-browser along with its dependencies: libsoup2.4, webkit, etc
[16:43] <ccheney> they use newer glib2.0 than what is in hardy but currently trying to copy the needed functions over so we won't need a full backport of glib as well
[16:43] <ccheney> as per asac's recommendation
[16:43] <seb128> urg
[16:43] <seb128> that seems crazy to backport all that stack
=== \vish is now known as mac_v
=== mac_v is now known as \vish
[16:44] <ccheney> seb128: yea its leaning towards crazy as more things get added to what needs backporting :-\
[16:44] <pitti> argh, sorry
[16:44] <rickspencer3> ccheney, are you concerned that it won't get done?
[16:44] <pitti> was stuck in gdm debugging, there now
[16:44] <seb128> it's rather than it could break quite some things
[16:44] <rickspencer3> do we have a contingency plan?
[16:45] <seb128> I'm concerned how much that can break
[16:45] <rickspencer3> seb128, well, the situation, as discussed at UDS, is not good
[16:45] <seb128> those libs are not known to have only minor limited changes
[16:45] <asac> to understand how risky it is, we need to know what needs to be backported
[16:45] <ccheney> rickspencer3: breakage plus complication added to the fact that there are lot more than just epiphany that needs changing to get rid of xulrunner depends
[16:45] <seb128> well I would not jeopardize desktop stability for a web browser
[16:46] <seb128> which is not our default one
[16:46] <ccheney> backporting the entirety of glib would cause problems with symbol versioning, right?
[16:46] <rickspencer3> asac, ccheney, if there is too much to backport, or it just doesn't work well, do we have a contingency plan?
[16:46] <seb128> but well I'm out of this one
[16:46] <seb128> just raising warnings that it seems risky
[16:46] <seb128> I would rather drop epiphany support than break desktop just to update it
[16:46] <asac> rickspencer3: we should think about when we get there.
[16:47] <asac> dropping epiphany support is definitly the last result
[16:47] <asac> resort
[16:47] <asac> but thats really low on the option list imo.
[16:47] <seb128> can't you use static copies or something?
[16:47] <rickspencer3> asac, I would rather know that we have a contingency plan
[16:47] <rickspencer3> ccheney, ^
[16:47] <seb128> rather than risk stability for system libs?
[16:47] <asac> so far i didnt see anything uncovered that needs to backport changes to existing glib functions ... just new once
[16:47] <asac> ones
[16:47] <seb128> I'm rather concerned about the libsoup and webkit updates
[16:48] <pitti> we could copy the newer source package and fake the ABI version?
[16:48] <rickspencer3> is dropping epiphany support the contingency plan? seems rather not what we promised
[16:48] <seb128> not about adding functions to glib
[16:48] <asac> seb128: those will go in using a different name
[16:48] <seb128> oh ok
[16:48] <pitti> like, introduce a newer fake abi for the hardy backports?
[16:48] <asac> its just glib and gtk we cannot treat that way
[16:48] <ccheney> pitti: yea we were planning on changing the soname for them
[16:48] <asac> because of plugins
[16:48] <seb128> fine with me then
[16:48] <seb128> I was under the impression you wanted to update system libsoup webkit etc
[16:48] <asac> no thats not the case
[16:48] <seb128> ignore my comments
[16:48] <seb128> ok good
[16:49] <asac> i just want to ensure that webkit and libsoup can be build without upgrading glib/gtk ... but those libs will get a new package name
[16:49] <seb128> ok
[16:49] <rickspencer3> ccheney, so next week you can tell us how the backporting went?
[16:49] <ccheney> rickspencer3: yes
[16:50] <rickspencer3> what is the next step after the backporting of epiphany?
[16:50] <pitti> there's also at least devhelp
[16:51] <asac> we have a huge list of rdepends. not all are required to be moved away
[16:51] <asac> from xulrunner ... only those that are exposed to insecure content
[16:51] <pitti> asac: ah, that'd help
[16:51] <asac> devhelp is probably not a high prio candidate
[16:51] <pitti> devhelp and yelp can stay as they are then, I figure
[16:51] <ccheney> i have to get libsoup2.4 rebuilt in two ways due to a circular dependency then see what breaks next in epiphany build and test it afterwards
[16:52] <asac> yes. libsoup2.4 needs bootstrapping
[16:52] <rickspencer3> ok, so sounds quite some effort for ccheney on epiph. and libsoup this week
[16:52] <rickspencer3> thanks for the update
[16:52] <rickspencer3> moving on?
[16:52] <ccheney> ok
[16:52] <rickspencer3> release status
[16:53] <rickspencer3> so, we are over the trend line in work items, and we have picked a few up
[16:53] <rickspencer3> I went through the list and it appeared that bryyce and kenvandine had the toughest ratios lef
[16:53] <rickspencer3> t
[16:53] <kenvandine> :(
[16:54] <pitti> uh, today there actually was an increase in WIs
[16:54] <kenvandine> i will re-evaluate what is left in social-from-the-start tomorrow, hopefully after all the couch stuff is merged
[16:54] <rickspencer3> kenvandine, bryyce can you guys go through and postpone work items that aren't going to get done for a2?
[16:55] <rickspencer3> pitti, I noticed that, I edited a blueprint or two to move things off the milestone, I wonder if I tweaked something the wrong way
[16:55] <rickspencer3> in any case ...
[16:55] <rickspencer3> the reason I am looking at work items is that I am also looking at bugs
[16:55] <rickspencer3> and we need to get ready for a3 work items
[16:56] <rickspencer3> I would like to suggest that we choose a number which is some fraction of the number of work items we *completed* in a2
[16:56] <rickspencer3> and limit our a3 work items to that number
[16:56] <rickspencer3> and basically assume that we will do few work items for beta 2
[16:57] <rickspencer3> this will force some serious selectivity sooner rather than later
[16:57] <rickspencer3> thoughts?
[16:57] <pitti> we have some 390 WIs left for final lucid
[16:57] <pitti> so this means to drop BP targets aggressively
[16:57] <pitti> (like all the low ones)
[16:57] <rickspencer3> I'm guessing that we'll achieve about 80 or 90
[16:57] <rickspencer3> in a2
[16:58] <rickspencer3> pitti, right
[16:58] <rickspencer3> it's just the facts of our capacity ... we could shoot for 390 work items, but if we have measures that suggest that isn't doable, perhaps we can address that situation now
[16:58] <rickspencer3> I'd rather disappoint people than surprise them
[16:59] <rickspencer3> (at least not surprise them in a bad way)
[16:59] <rickspencer3> and I'
[16:59] <pitti> https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-touchscreen-handling<<BR>> [16:59] <pitti> that has 22 WIs and is low
[16:59] <pitti> and just a target of opportunity anyway
[16:59] <rickspencer3> d also like to ensure that we have plenty of bandwidth for bug fixing and integration
[16:59] <rickspencer3> pitti, right, good point, we can just defer that whole blueprint
[16:59] * rickspencer3 wipes tear from eye
[16:59] <pitti> many of those on http://piware.de/workitems/desktop/lucid/report.html are from Kubuntu, though
[16:59] <rickspencer3> all: what are your thoughts on this approach?
[17:00] <tseliot> things should be easier when I receive the new touchscreen but yes, I doubt it will be ready in time for Lucid
[17:01] <rickspencer3> seb128, kenvandine: thoughts on limiting the number of work items based on the number we got down in a2?
[17:02] <kenvandine> rickspencer3, i think we need to look at them based on the individuals load
[17:02] <pitti> if we include all the "high" ones, we should have a decent amount of work
[17:02] <bryyce> heya
[17:02] <rickspencer3> like each person measures their own capacity based on a2?
[17:02] <pitti> hey bryyce, happy new year!
[17:02] <rickspencer3> hiya bryyce
[17:02] <rickspencer3> kenvandine, like each person measures their own capacity based on a2?
[17:02] <pitti> how about I run through the list and make a proposal for alpha-3 targetting next week?
[17:03] <kenvandine> sort of...
[17:03] <pitti> (based on individual capacity and alpha-2 items)
[17:03] <kenvandine> like how big the work item is
[17:03] <rickspencer3> pitti, <3
[17:03] <rickspencer3> that would rock
[17:03] <kenvandine> and how if one person has like 90
[17:03] <pitti> seems easier than figuring it out in a meeting
[17:03] <kenvandine> yeah
[17:03] <rickspencer3> well, I thought we should discuss the approach as a team
[17:03] <pitti> erm, and based on priority, too, of course
[17:03] <kenvandine> yeah
[17:03] <pitti> right, we should
[17:03] <rickspencer3> seems that it impacts the way people work and their commitments
[17:04] <kenvandine> we should each look at what is on our plate though and weed out the noise to make the big picture easier to digest
[17:04] <rickspencer3> ACTION: pitti to propose a3 work item list based on measured capacity in a2, priority, and work item size
[17:05] <rickspencer3> pitti ^ sound about right?
[17:05] <pitti> *nod*
[17:05] <rickspencer3> speaking of noise
[17:05] * rickspencer3 subtly moves on
[17:05] <rickspencer3> I ran a query yesterday ...
[17:05] <rickspencer3> for all the packages that someone on the the desktop team is subscribed to
[17:05] <rickspencer3> what are the bug tasks on each of those packages?
[17:06] <rickspencer3> the list is almost 15,000
[17:06] <rickspencer3> !
[17:06] <rickspencer3> !!!
[17:06] <pitti> that doesn't say much, though
[17:06] <asac> some are subscribed to whole ubuntu maybe?
[17:06] <pitti> I subscribe to each bug I comment on
[17:06] <rickspencer3> pitti, this is *packages*
[17:06] <pitti> oh, that's package bug contact or explicit sub?
[17:06] <pitti> ah
[17:07] <rickspencer3> I haven't had a chance to slice and dice the data, but it tells me that the desktop has lots of bugs
[17:07] <rickspencer3> well, bug reports anyway
[17:07] <rickspencer3> so I'm hoping that we can use this to hone in on any areas that maybe need a bit more attention or such
[17:07] <asac> 15k source packages really feels like someone or more than one have signed up for whole ubuntu
[17:08] <rickspencer3> asac, 15,000 bug tasks
[17:08] <pitti> I think that was 15k bugs, wasn't it?
[17:08] <asac> ah
[17:08] <rickspencer3> related to subscribed packages
[17:08] <rickspencer3> anyway, if anyone wants to list, I can can attach it to the wiki
[17:08] <rickspencer3> ACTION: rickspencer3 to attach mondo bug list to wiki
[17:09] <rickspencer3> also, please note that we have 46 bugs with status of New that are assigned to someone on the desktop team
[17:09] <rickspencer3> and we also have 62 assigned bugs that are Critical or High
[17:10] <rickspencer3> so I am keen to find the right ratio of work items to bug fixing in a3
[17:10] <rickspencer3> any thoughts on the New or High+ lists?
[17:10] * bryyce ponders
[17:10] <pitti> triaging 62 bugs seems entirely doable
[17:11] <pitti> and almost in the range of the permanent turnover?
[17:11] <bryyce> could be
[17:11] <pitti> 46 I mean
[17:11] <rickspencer3> pitti, right
[17:11] <rickspencer3> that's fine
[17:12] <pitti> but we do need more time to attack assigned bugs
[17:12] <rickspencer3> I'll look through them and see if there are any that should be "won't fix" or otherwise not assigned
[17:12] <bryyce> if the 62 assigned bugs are mostly High, that probably is not to be too concerned with; I imagine most of our bugs should be of at least high priority
[17:12] <pitti> (like what you said when proposing to drop targets)
[17:12] <bryyce> but if a significant number are Critical, that may be a bigger deal
[17:13] <rickspencer3> there are 3 critical bugs
[17:13] <pitti> kenvandine: thaks for fixing the whiteboard; http://piware.de/workitems/desktop/lucid-alpha2/report.html looks better now
[17:13] <kenvandine> :)
[17:13] <bryyce> ok, 3 sounds pretty good actually
[17:13] <rickspencer3> great
[17:13] <seb128> re
[17:13] <seb128> sorry I missed the end of the meeting
[17:14] <rickspencer3> so let's continue to explore how we can be more efficient at finding the right bugs to fix
[17:14] <seb128> the wifi driver crashed or something to way to reconnect, so I rebooted
[17:14] <bryyce> how often are the burn charts regenerated? hourly?
[17:14] <rickspencer3> any other business?
[17:14] <seb128> and empty screen for 15 minutes
[17:14] <pitti> bryyce: hourly, yes
[17:14] <seb128> I though it was doing a fsck or something and did reboot again after a while since it was using cpu
[17:14] <pitti> bryyce: (but I just kicked off a run manually after seeing kenvandine's whiteboard fixes)
[17:15] <bryyce> ah
[17:15] <kenvandine> it doesn't make sense for a blueprint to have a milestone target of alpha-2 with work items in alpha-3 and beta-1 :)
[17:16] <rickspencer3> is that a wrap?
[17:16] <pitti> rickspencer3: so after beta-1, we would ideally have 0 work items from blueprints, and 100% time for bug fixing
[17:16] <rickspencer3> pitti, that is my thought, yes
[17:16] <ArneGoetje> rickspencer3: my bugs on that High list are all for Hardy, they don't apply to Lucid.
[17:16] <rickspencer3> ArneGoetje, but they take time and attention
[17:16] <pitti> rickspencer3: which will blatantly not be true for e. g. kenvandine, since DX/OLS stuff will keep coming; but we could at least try
[17:16] <rickspencer3> if you are not going to fix them, you should close them
[17:16] <rickspencer3> pitti, well, I would say "bug fixing and integration"
[17:16] <kenvandine> yeah... for me that will be the busy time :/
[17:16] <pitti> not close, unassign please
[17:17] <pitti> kenvandine: well, your busy time in lucid is between October and April, right?
[17:17] <kenvandine> hehe
[17:17] <kenvandine> feb/march is when stuff gets crammed down my throat that i might not have been expecting :)
[17:18] * kenvandine doesn't think that will be the case this time ... maybe just wishful thinking :)
[17:18] <rickspencer3> ok, I think that's a wrap?

CategoryDesktopTeam

Back to DesktopTeam.