[01:54] <jcastro> lamlex: ping
[01:55] <jcastro> lamlex: how would you feel about a "multi-monitor" tag in lp.net/unity?
[07:51] <didrocks> good morning
[07:54] <oSoMoN> good morning
[09:50] <kvalo> kamstrup: hi. do you have time for review? https://code.launchpad.net/~kvalo/indicator-network/libconnman-control-technology/+merge/50750
[10:05] <njpatel> rodrigo_, Settings schema 'org.gnome.desktop.interface' does not contain a key named 'toolkit-accessibility'
[10:05] <njpatel> rodrigo_, how do I fix/work-around that?
[10:08] <njpatel> rodrigo_, sorry, session died
[10:08] <njpatel> still having the same issue
[10:08] <njpatel> didrocks, ^ know anything about that?
[10:12] <didrocks> njpatel: is that the latest revision?
[10:12] <njpatel> yeah
[10:12] <njpatel> and updated box
[10:12] <njpatel> I can't start unity :/
[10:12] <didrocks> njpatel: I'm still updating, my bet is that the schema is update in /usr/local/share and not in /usr/share
[10:13] <njpatel> didrocks, there are no schemas in /usr/local in my system
[10:13] <njpatel> didrocks, this schema isn't from unity, I don't think
[10:13] <didrocks> njpatel: yeah, it's not, let me see here
[10:14] <didrocks> njpatel: so yeah, no /usr/share/glib-2.0/schemas/org.gnome.desktop.interface.gschema.xml in toolkit-accessibility
[10:14] <njpatel> awesome
[10:14]  * njpatel adds a way to disable a11y in unity
[10:16] <didrocks> njpatel: oh yeah, please :)
[10:17] <kamstrup> kvalo: approved
[10:17] <njpatel> added UNITY_A11Y_DISABLE
[10:17] <njpatel> (in my branch, which I'm proposing in a bit)
[10:19] <didrocks> njpatel: so, unity will break in with older gsettings-desktop-schemas
[10:19] <didrocks> njpatel: not sure there is a comment in the log telling that we need the new one
[10:19] <njpatel> right
[10:22] <rodrigo_> njpatel, we need a new gsettings-desktop-schemas, which you can get from the gnome3 ppa -> https://edge.launchpad.net/~gnome3-team/+archive/gnome3/+packages
[10:23] <rodrigo_> njpatel, take care though to just install that package
[10:23] <didrocks> rodrigo_: is it in natty already?
[10:23] <didrocks> rodrigo_: because there is a release tomorrow :)
[10:23] <rodrigo_> seb128 was going to upload it to main as soon as debian does the update
[10:24] <didrocks> so, if it makes unity fail at start…
[10:24] <didrocks> seb128: some info on that? ^^
[10:24] <njpatel> can we just get it in?
[10:24] <didrocks> in any case, unity needs to breaks on the older one to avoid cherry-pick upgrade issue
[10:28] <rodrigo_> it should probably depend on 0.1.7
[10:28] <seb128> (on the phone)
[10:29] <didrocks> rodrigo_: rather breaks on older, isn't it?
[10:29] <didrocks> rodrigo_: or there is now lib symbols?
[10:29] <rodrigo_> anyway, pochu from debian is going to update it today, and then it will be merged with the ubuntu package
[10:29] <rodrigo_> didrocks, no symbols in gsettings-desktop-schemas, just schemas
[10:30] <seb128> it can by synced frm debian most likely
[10:30] <seb128> he did the update
[10:30] <kvalo> kamstrup: thanks!
[10:30] <didrocks> rodrigo_: yeah, so breaks: on older
[10:31] <rodrigo_> didrocks, ok
[10:31] <didrocks> rodrigo_: can you warn us on that for the future please? MacSlow was desperate yesterday evening :)
[10:32] <seb128> didrocks, rodrigo_, njpatel: sorry on the phone but the new gsettings-desktop-schemas can likely be synced from experimental, pochu did the update
[10:32] <seb128> someone should check they patch to change the default screensaver though
[10:32] <rodrigo_> didrocks, I didn't know that branch had landed, we discussed it yesterday and we talked about doing the merge after the package was updated
[10:32] <rodrigo_> but seems the branch was merged before
[10:33] <didrocks> rodrigo_: yeah, the branch was merged yesterday
[10:33] <rodrigo_> seb128, ah, already updated then?
[10:33] <rodrigo_> didrocks, yes, I see it now
[10:33] <didrocks> seb128: I won't have the time, in any case, I need unity to breaks: on it for avoid partial upgrades
[10:34] <MacSlow> didrocks, sweet... the fix works
[10:34] <seb128> didrocks, just sync-source g-d-s if you want
[10:34] <seb128> we can fix the default screensaver thing later on
[10:34] <didrocks> seb128: ok, doing that then :)
[10:34] <didrocks> from experimental?
[10:34] <seb128> yes
[10:34] <didrocks> ok, doing, thanks!
[10:35] <seb128> you're welcome
[10:35] <rodrigo_> seb128, default screensaver?
[10:35] <seb128> rodrigo_, the debian guy added a patch to change the default value of the screensaver key
[10:35] <rodrigo_> seb128, we don't use that schema in natty, only in the gnome3 ppa, right?
[10:35] <rodrigo_> ah ok
[10:36] <rodrigo_> anyway, need to reboot, brb
[10:36] <MacSlow> njpatel, rodrigo_, didrocks: was the issue with unity r878 and r879 solved?
[10:36] <didrocks> MacSlow: yeah, you need a newer g-d-s
[10:36] <didrocks> MacSlow: I'm doing the sync now
[10:36] <MacSlow> didrocks, what?!
[10:36] <MacSlow> ok
[10:36] <didrocks> gsettings-desktop-schemas
[10:38] <njpatel> MacSlow, once I get an +1, I'll merge my branch that has a workaround that disables a11y
[10:38] <njpatel> MacSlow, will ping you
[10:38] <didrocks> njpatel: yeah, sorry doing the sync first :)
[10:39] <njpatel> np :)
[10:39] <MacSlow> njpatel, cool... after that I'll merge-propose the superkey-label stuff
[10:41] <njpatel> MacSlow, sweet
[10:42] <MacSlow> njpatel, I guess you've seen the screencasts
[10:42] <njpatel> MacSlow, yep, very cool :D
[10:42] <MacSlow> the dynamic reassigning of reordered icons is very cool
[10:42] <MacSlow> njpatel, a bit over the top... but funky
[10:42] <njpatel> yeah, /me likes
[10:43] <njpatel> no, it's attention to detail, so it's nice to see :D
[10:53] <didrocks> MacSlow: the good news is that it wasn't to complicated to get it from the model :)
[10:54] <MacSlow> didrocks, :)
[10:54] <didrocks> yeah for effiency \o/
[10:54] <didrocks> MacSlow: so, basically, you'll need gsettings-desktop-schemas 0.1.7-2, sync done, but still need rebuild and publish
[11:17] <njpatel> rodrigo_, we need to switch to gconf from gsettings for the a11y stuff, as natty is going to still be using gsettings
[11:17] <njpatel> bah, still be using gconf*
[11:17] <njpatel> seb128, didrocks ^
[11:18] <seb128> rodrigo_ is back
[11:18] <rodrigo_> njpatel, talk to apinheiro, I thought it was already using gsettings
[11:18] <njpatel> apinheiro, ^
[11:18] <apinheiro> njpatel, I don't understand
[11:18] <seb128> rodrigo_, right, it's using gsettings, it should not
[11:18] <apinheiro> we are using gsettings
[11:18] <apinheiro> ah
[11:18] <seb128> natty is GNOME 2.32
[11:18] <apinheiro> well
[11:18] <seb128> it's using gconf
[11:18] <njpatel> right, but we need to use gconf
[11:18] <apinheiro> " natty is going to still be using gsettings"
[11:18] <apinheiro> hmmm
[11:18] <njpatel> apinheiro, I corrected myself afterwards
[11:18] <seb128> " bah, still be using gconf*"
[11:18] <seb128> on the next line
[11:18] <apinheiro> ups sorry
[11:18] <apinheiro> njpatel, ok
[11:19] <apinheiro> lets create two bugs about that
[11:19] <apinheiro> one for the service panel
[11:19] <apinheiro> and the other for unity
[11:19] <njpatel> So, yeah, please switch to gconf, I'm about to land a branch that adds gconf as a dep, so if you wait ~20mins you can branch off trunk
[11:19] <rodrigo_> apinheiro, but at-spi1 uses gsettings already?
[11:19] <njpatel> rodrigo_, I think this is for the "should we enable a11y" check
[11:19] <apinheiro> rodrigo_, yes, but it was not a replacement
[11:20] <rodrigo_> njpatel, yes
[11:20] <apinheiro> and it doesn't include the enable toolkit gconf
[11:20] <rodrigo_> apinheiro, ah, so it supports both gconf and gsettings?
[11:20] <apinheiro> njpatel, there is just a problem
[11:20] <apinheiro> that the old gconf variables
[11:20] <apinheiro> doesn't include the bridge location
[11:20] <apinheiro> that was one of the reasons to move to gsettings
[11:20] <rodrigo_> right, and we need it
[11:20] <njpatel> so we can use both, right? Thats fine
[11:20] <rodrigo_> both?
[11:21] <apinheiro> njpatel, as I said there isn't any gconf variable exposing the atk-bridge location
[11:21] <seb128> well another option is to patch the capplet to write in gsettings
[11:21] <njpatel> connect to gconf to monitor whether we need to be enabled or not
[11:21] <njpatel> and connect to gsettings to get the settings
[11:21] <rodrigo_> ugh
[11:21] <apinheiro> njpatel, ah ok
[11:21] <rodrigo_> everything we need is in gsettings, so why not just use that?
[11:21] <apinheiro> so you are saying that to check if a11y is enabled
[11:21] <njpatel> seb128, but will other applications be listening to gsettings in natty?
[11:21] <apinheiro> we should use gconf
[11:21] <rodrigo_> unity already uses gsettings for other stuff, right?
[11:22] <apinheiro> but to get the bridge location
[11:22] <apinheiro> use gsettings?
[11:22] <njpatel> apinheiro, exactly, so we follow what the rest of the desktop is doing
[11:22] <apinheiro> but one question, as rodrigo_ says
[11:22] <apinheiro> why don't use
[11:22] <seb128> njpatel, oh, I meant to write in gconf and gsettings
[11:22] <njpatel> rodrigo_, we need to use gconf too where we have to read settings from gnome that aren't in gsettings yet
[11:22] <apinheiro> gsettings for both
[11:22] <seb128> njpatel, i.e write both keys
[11:22] <apinheiro> ah ok
[11:22] <apinheiro> because the bridge location is already on at-spi1
[11:22] <apinheiro> right?
[11:22] <njpatel> seb128, oh, okay, that would work too, as long as we're sure we're not breaking scripts that relied on the old location (and didn't use the capplet)
[11:23] <rodrigo_> we have a gconf->gsettings bridge in g-s-d 2.91., so we could port it to 2.32
[11:23] <rodrigo_> instead of having to patch apps to write to both gconf and gsettings
[11:23] <njpatel> Instead of all of this, why not just connect to gconf to get the initial true/false, and monitor that for natty?
[11:24] <rodrigo_> because we need to read gsettings for the atk bridge location
[11:24] <rodrigo_> right apinheiro?
[11:24] <seb128> rodrigo_, isn't the bridge the other way around?
[11:24] <apinheiro> or make the ugly assumptions that firefox does
[11:24] <apinheiro> the other way around?
[11:24] <apinheiro> what do you mean?
[11:25] <njpatel> rodrigo_, I don't understand, gconf and gsettings aren't mutually exclusive, you can use both
[11:25] <njpatel> we *do* use both when we need to work with old GNOME stuff
[11:25] <njpatel> i'm just about to land a branch that does that
[11:25] <apinheiro> njpatel, well, but my question is still here
[11:25] <apinheiro> why don't use gsettings to check in the a11y is enabled?
[11:26] <seb128> because the GNOME dialog doesn't write in gsettings
[11:26] <njpatel> apinheiro, because the capplet isn't updating gsettings, it's just updating gconf
[11:26] <seb128> so the key will never be set
[11:26] <apinheiro> ok
[11:26] <seb128> we still have GNOME 2.32
[11:26] <njpatel> apinheiro, and because we don't know if other people's tools are also just updating gconf instead of gsettings
[11:26] <apinheiro> thanks, no I understand
[11:26] <apinheiro> so concluding:
[11:26] <njpatel> so I'd like to just work with gnome as it is
[11:26] <apinheiro> a11 enabled: use gconf as the dialog is updating it
[11:27] <apinheiro> atk-bridge location: use gsettings as at-spi1 already has a patch with it
[11:27] <apinheiro> right?
[11:27] <njpatel> right
[11:27] <apinheiro> ok, was hard, but in the end we conclude something ;)
[11:27] <apinheiro> ok
[11:27] <apinheiro> so lets create two bugs
[11:27] <apinheiro> one for the service
[11:27] <apinheiro> and one for unity
[11:27] <apinheiro> btw
[11:28] <apinheiro> njpatel, this is related with MacSlow mail about unity hanging on start?
[11:28] <njpatel> apinheiro, i believe that is because we don't have the very latest gsetting schemas, didrocks has uploaded them
[11:29] <apinheiro> well, yes, I realized that by mistake, I update the accessibility check to "toolkit-accessibility"
[11:29] <apinheiro> as it is right now on upstream
[11:29] <apinheiro> my mistake
[11:29] <apinheiro> anyway, gsettings causing a crash
[11:29] <apinheiro> just because you are asking for a wrong setting name
[11:29] <apinheiro> is really bad
[11:29] <apinheiro> as we need to move it to gconf
[11:30] <apinheiro> I can make a sanity commit
[11:30] <apinheiro> in order to not check the gsettings for the accessibility
[11:30] <njpatel> yeah, I can't believe gsettings does that
[11:30] <apinheiro> so people could start unity wihout problem
[11:30] <njpatel> I'm waiting to merge something that adds a UNITY_A11Y_DISABLE option
[11:30] <rodrigo_> well, there's a way to check for the schema before getting the key
[11:30] <apinheiro> then it would be solved when we integrated the gconf thing
[11:30] <njpatel> so I think that shoudl be fine
[11:31] <apinheiro> well, our "unity_a11y_disable" was just disabling the gsettings
[11:31] <njpatel> rodrigo_, that's the most annoying aspect, that it g_error's but there isn't a way to sanity check! :)
[11:31] <apinheiro> I didn't know that gsettings was so unstable
[11:31] <njpatel> it's by design it seems (to g_error)
[11:31] <apinheiro> rodrigo_, yes we are checking if the schema is there
[11:31] <apinheiro> but it seems
[11:32] <apinheiro> that if you ask for a setting on this schema
[11:32] <apinheiro> and this setting is not on the schema
[11:32] <apinheiro> it crashes
[11:32] <apinheiro> njpatel, but ok, I will make a sanity commit to avoid the unity crash
[11:32] <rodrigo_> apinheiro, no, afair, we are calling g_settings_get directly, without calling g_settings_list_schemas, right?
[11:33] <apinheiro> no
[11:33] <apinheiro> we have a check
[11:33] <apinheiro> static gboolean
[11:33] <apinheiro> has_gsettings_schema
[11:33] <njpatel> apinheiro, sweet
[11:33] <rodrigo_> ah, right
[11:33] <apinheiro>   /* we need to check if AT_SPI_SCHEMA is present as g_setting_new
[11:33] <apinheiro>      could abort if the schema is not here*/
[11:33] <apinheiro> so although we check it to avoid a crash is the schema is not there
[11:34] <apinheiro> it will crash if we ask for a wrong setting
[11:34] <apinheiro> wrong == wrong name
[11:34] <njpatel> apinheiro, is there a way to check if a schema exists?
[11:34]  * njpatel should do the same sanity check where he uses gsettings
[11:34] <njpatel> you dont' want your WM crashing ;)
[11:35] <apinheiro> njpatel, yes, we use that on the a11y initialization
[11:35] <apinheiro> unitya11y.cpp method has_gsettings_schema
[11:35]  * njpatel looks
[11:36] <apinheiro> njpatel, we ask all the schemas available
[11:36] <apinheiro>   list_schemas = g_settings_list_schemas ();
[11:36] <apinheiro> and then we check if our schema is on this list
[11:36] <njpatel> oh :/
[11:36] <njpatel> that seems slow
[11:36] <didrocks> maybe better to desrt once here?
[11:37] <njpatel> to do what to desrt? !
[11:37] <njpatel> ;)
[11:37] <didrocks> argh, eating words :p
[11:37] <didrocks> ask*
[11:37] <didrocks> or hit if you are really angry about that crash :)
[11:37] <didrocks> I let you choose guy! ;)
[11:38] <apinheiro> njpatel, well, there isn't a really big list of schemas installed
[11:38] <apinheiro> and it is just a comparison with the list
[11:38] <apinheiro> in practice, I didn't notice any slowdown
[11:39] <njpatel> apinheiro, sure, sorry, I'm just thinking out alound
[11:39] <njpatel> I guess gsettings has a cache anyway
[11:39] <njpatel> so it won't be bad
[12:01] <apinheiro> njpatel, I have just made the sanity commit
[12:01] <njpatel> thanks
[12:02] <njpatel> MacSlow|lunch, trunk should be safe now
[12:44] <MacSlow> njpatel, thanks!
[14:22] <didrocks> ronoc: hey, IIRC, you told me to reset something in gsettings that can explain why I have banshee twice in the soundmenu, I remember to do that, log out/log in, but I have still have two of them
[14:25] <jcastro> didrocks: dbarth: any other branches pending?
[14:25] <jcastro> from new people?
[14:26] <didrocks> jcastro: not that I noticed
[14:32] <lamlex> morning all
[14:32] <jcastro> didrocks: lamlex: I had an idea yesterday
[14:32] <jcastro> what do you guys think of lumping all the twinview/multimonitor stuff in a tag?
[14:32]  * lamlex claps
[14:33] <lamlex> jcastro: do you think that it's a big enough section of bugs?
[14:33] <m_conley> hooo boy, I absent-mindedly did apt-get upgrade, and Natty on my Virtualbox is broken.  *sigh*.
[14:33] <lamlex> cyphermox has a branch up now for better multi-monitor support
[14:33] <jcastro> I counted at least 6 or 7 unscientifically yesterday
[14:34] <didrocks> lamlex: isn't it only for changing resolution? it's really muti-monitor support?
[14:34] <didrocks> jcastro: hum, that would be possible
[14:35] <lamlex> didrocks: no it's also to relayout on monitor added (afaik)
[14:36] <didrocks> ok :)
[14:37] <cyphermox> lamlex, better?
[14:37] <lamlex> i haven't tested it
[14:37] <lamlex> nvidia
[14:37] <lamlex> is f'ing up my life
[14:38] <cyphermox> fwiw I got a review from smspillaz too, and he brought up a good point, hooking up to outputChangeNotify
[14:38] <ronoc> didrocks, gsettings reset  com.canonical.indicators.sound blacklisted-media-players
[14:38] <jcastro> anyone running a daily or trunk of unity?
[14:39] <ronoc> didrocks, whoops sorry it should be
[14:39] <ronoc> didrocks, gsettings reset  com.canonical.indicators.sound interested-media-players
[14:39] <didrocks> ronoc: ok done, at next login, it should be changed, right?
[14:39] <didrocks> jcastro: almost trunk there, why?
[14:40] <jcastro> didrocks: I need a screenshot of the fixed trash can quicklist
[14:40] <ronoc> didrocks, just restart the service
[14:40] <jcastro> I have the broken one, I want to show a before and after
[14:40] <ronoc> killall indicator-sound-service
[14:41] <didrocks> jcastro: if you are not afraid of French, I can show you :)
[14:41] <jcastro> didrocks: good enough
[14:49] <didrocks> ronoc: excellent! I got two soundbars now (think it's a known issue, right?) but just one bansee
[14:50] <ronoc> didrocks, if the service crashes its a side effect, will fix
[14:50] <didrocks> jcastro: http://people.canonical.com/~didrocks/correct-tash-quicklist.png
[14:50] <didrocks> ronoc: ok, thanks :)
[14:52] <jcastro> didrocks: that's the correct one? It looks like mine, wrong. :)
[14:52] <didrocks> jcastro: hum? no it's centered on the Trash now
[14:53] <didrocks> jcastro: before it was above it
[14:53] <jcastro> oh I see it now
[14:53] <jcastro> thanks
[14:53] <didrocks> yw :)
[14:53] <jcastro> ok, there still appears to be too much space
[14:54] <jcastro> in the quicklist itself, but whatevs
[14:54] <didrocks> jcastro: the bug wasn't about that, just the placement :)
[15:32] <lamlex> didrocks: https://bugs.launchpad.net/unity/+bug/604619
[15:32] <lamlex> I can mark invalid right
[15:33] <jcastro> Anyone know what's up with: https://bugs.launchpad.net/unity/+bug/718886
[15:35] <vish> bug 718886
[15:35] <vish> weird bot!
[15:35] <vish> iirc, usually bot would announce the bug even when link is pasted..
[15:39] <didrocks> lamlex: oh right, I think it's gone for a while :)
[15:39] <didrocks> jcastro: I can't reproduce it
[15:39] <jcastro> ah
[15:57] <lamlex> didrocks: this one? https://bugs.launchpad.net/unity/+bug/604621
[16:00] <didrocks> lamlex: this one is still valid I guess as zg is empty (or you can replace with recent files)
[16:01] <didrocks> lamlex: but I think in that case, we have now the home folder showing
[16:08] <lamlex> didrocks: well this is for applications
[16:11] <didrocks> lamlex: yeah, not sure about that one, we should check
[17:29] <kenvandine> dbarth, ping
[17:49] <didrocks> "Don’t worry, these are from two different computers, we won’t turn your labels into French"
[17:49] <didrocks> jcastro_: -> I can make this a reality ^ :-)
[17:49] <jcastro_> yeah!
[17:52] <didrocks> jcastro_: I changed the "lock" state for the fading for next release
[17:52] <didrocks> jcastro_: should be more obvious now
[17:52] <didrocks> jcastro_: sorry, misread your post, that what you stated :)
[17:54] <didrocks> (I like the (NEW!) tag, sounds like in a supermarket)
[17:56] <apinheiro> njpatel, btw, the gconf thing is finished
[17:56] <apinheiro> https://code.launchpad.net/~apinheiro/unity/Bug723699/+merge/50963
[17:57] <apinheiro> just waiting for review
[17:57] <apinheiro> (although rodrigo already reviewed it)
[18:12] <njpatel> apinheiro, sweet, thanks!
[18:26] <achiang> hello, can someone help me debug an issue i found in unity-place-applications? the problem is trying to launch the FBreader app from the dash; it doesn't seem to work because the .desktop file's path has capital letters in it, and i think u-p-a might be sending the wrong path
[18:27] <achiang> a clue on where to narrow my search would be much appreciated
[18:36] <kvalo> ronoc: if you have time for review (can wait until tomorrow): https://code.launchpad.net/~kvalo/indicator-network/settings-tech-control/+merge/50972
[19:15] <htorque> lamlex, bug 684361 -> the answer is "no" - i can't batch-change the status, could you do it?
[19:15] <lamlex> sure
[19:15] <lamlex> thanks
[19:15] <htorque> thanks :)
[19:28] <vish> lamlex: hey, any reason Bug #686133 has the ayatana design task open..
[19:28] <vish> ?
[19:28] <vish> stupid ubot5 !  ;p
[19:28] <vish> lamlex: btw, when closing a unity bug as opinion or invalid, do feel free to close the papercut task too ;)
[19:29] <vish> Bug 686133
[19:29] <vish> meh, ubot5 is not a very good bot..
[19:29] <lamlex> hah
[19:30] <lamlex> vish: can you just paste link?
[19:30] <vish> lamlex: https://launchpad.net/bugs/686133
[19:30] <lamlex> oh, bugbot got that part right
[19:30] <lamlex> why does that have a design task?
[19:30] <lamlex> because that's a design issue
[19:31] <lamlex> oh open
[19:31] <vish> i dont know..
[19:31] <lamlex> well design has not made a decision I guess
[19:31] <lamlex> sorry I misunderstood what you were asking me at first
[19:31] <vish> lamlex: chris was in a phase where he opened a design task for a lot of bugs.. and this was one of them ;)
[19:32] <lamlex> yah this should have a design task, that is good
[19:32] <vish> lamlex: right, but since you closed the task as opinion it seemed like there was a decision..
[19:32] <vish> unity one.
[19:32] <lamlex> vish: no, just updating based on unity bug policy
[19:33] <vish> ah!
[19:33] <lamlex> https://wiki.ubuntu.com/Unity/FilingBugs#Design%20Bugs
[19:33] <lamlex> we mark the unity task opinion to get it out of our face until design makes a decision
[19:33] <vish> hmm, thats not an ideal workflow..
[19:34] <lamlex> then design marks the unity task confirmed (or triaged-I forget which) or wontfix when theyve made a decision
[19:34] <lamlex> vish: no it's pretty ideal
[19:34] <vish> lamlex: for other Ubuntu packages, opinion should be used for something that the designer will not fix
[19:34] <vish> lamlex: but lets people continue the discussion
[19:35] <lamlex> vish: well the ayatana-design task doesn't got to opinion
[19:35] <lamlex> there are some semantics here
[19:35] <lamlex> the unity task is "we dont care but keep talking we are not dealing with this until we hear from design"
[19:35] <vish> yea, but now unity workflow is different from *all* ubuntu pacakges
[19:35] <vish> packages*
[19:35] <lamlex> no it's not really it's just specialized
[19:36] <lamlex> because the unity team is saying we can't look at this but you can keep discussing
[19:36] <vish> lamlex: actually it will lead to confusions :), ex: see the comment there after you marked opinion
[19:36] <vish> he thought you consider it case closed
[19:37] <vish> it could have been an "incomplete", IMO
[19:38] <lamlex> we talked about that but that's not ideal for us
[19:38] <lamlex> incomplete means waiting for more user input
[19:38] <lamlex> the UNITY team are not waiting for user input, that's why the design task stays open
[19:38] <vish> well, its not necessarily always, incomplete can be waiting on some other task too..
[19:39] <lamlex> this is the workflow that is best for us, it's not that complex and people will need to get used to it
[19:39] <vish> ok.. ;)
[19:39] <lamlex> we need to get design bugs off of our radar until the design team tells us what to do
[19:39] <lamlex> wontfix isn't right, incomplete doesn't get them out of the way
[19:40] <vish> if the team wanted to differentiate, it could be incomplete status + a needs-design tag
[19:40] <vish> thats another way design bugs are handled in other ubuntu packages
[19:40] <lamlex> it stays in the bug list though
[19:40] <vish> you can do lp searches with status and tags
[19:41] <lamlex> to exclude on tags?
[19:41] <vish> yup
[19:42] <lamlex> well damn, someone should have told me that before we made this workflow and have already been using it a ton
[19:42] <lamlex> ill talk to didrocks tomorrow I guess
[19:42] <vish> thanks.. :)
[19:44] <vish> lamlex: https://wiki.ubuntu.com/Bugs/Tags#Different%20ways%20you%20can%20help
[19:44] <vish> those are some common tags.
[19:44] <vish> rather, most of the common tags
[19:45] <lamlex> thanks
[19:48] <vish> lamlex: for excluding tags, the link should end in > +bugs?field.tag=-TAGNAME   note the "-" before the tagname
[19:48] <lamlex> yah
[19:48] <lamlex> i found it in the lp help docs :\