[02:38] Hi, is anyone online? [07:19] ssds work and should keep working for years even without any tweaking, it's world of choices you have problems with :) [07:54] bug 1059083 not sure if this is lightdm problem or xubuntu specific. [07:54] Launchpad bug 1059083 in ubiquity ""Log in automatically" choice does not work." [Undecided,New] https://launchpad.net/bugs/1059083 [07:54] are you using lightdm?! [07:54] * xnox is out of touch [07:54] yup, we are [07:54] lightdm it is. [07:55] suprising that this doesn't work, shouldn't it simply do the same thing in ubuntu and xubuntu? [07:55] I suppose we had some settings for that, maybe something broke. [07:56] I think that worked for me.. [07:56] considering that my lightdm login is "funny" with massive spinning circles, I would not be surprised if it was lightdm regression.... or change of api..... or something like that. [07:57] xnox: does this affect ubuntu as well? [07:57] I used amd64 [07:57] ochosi: no clue. Haven't tested yet. Just going through my bug mail. [12:03] g'day [12:04] hi knome [12:04] hello elfy [12:04] * elfy needs to get his around this qa thing - got somewhere simple for him to start? [12:05] astraljava is quite a simple person... [12:05] :) [12:05] what is it what you are specifically wondering about? [12:05] that'll be 2 of us then [12:05] what it is I'm supposed to be doing :D [12:06] heh, ok so: [12:06] first of all, make sure you announce mailing lists when we have milestone releases coming up [12:07] yep [12:07] the second one is to attend the weekly QA meeting [12:07] i got to say i have no idea what time that is... [12:07] but astraljava will tell you [12:07] ok - I can find out - I talk to balloons anyway [12:08] looks like it's wednesdays 14UTC [12:08] and if there's something specific to report, report it back to us [12:08] right - not too onerous then :) [12:09] no, not really [12:09] then there's this one thing [12:09] that we still need to get fixed [12:09] the weekly reports to the release team [12:10] i'm ok to do that, but that implies that people should really update the team reports [12:10] ok [12:10] https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001846.html [12:10] that's our last weekly mail, sent in august :P [12:11] but those are the things that we need to report [12:11] if you have ideas how we can make this reporting more effective.. [12:12] I'll have a think knome - so at present - people tell you and then you report to release team? [12:13] * smartboyhw finds that the "not-sending-the-release-mail" isn [12:13] elfy, well, no... [12:13] that serious for Xubuntu, Ubuntu Studio's problem is bigger:P [12:13] elfy, people doesn't tell me, and when we've sent the mail, the person who sent it finds out what has been done himself [12:13] elfy, astraljava has been sending those mails mostly [12:13] ok [12:14] elfy, our last "team report", which would be *really useful* for this, is from 2011 [12:14] https://wiki.ubuntu.com/Xubuntu/TeamReports/ [12:14] knome: Wow that is long [12:15] * smartboyhw thinks the last "team report" for Studio is about 4 years ago:P [12:15] knome: ok - I'll have a think about that then [12:16] elfy, i was thinking if something @IRC would work... [12:17] yep probably - so the kind of thing that needs reporting is stuff that gets mentioned in meetings and from bugs etc [12:18] I'll talk to astraljava [12:18] elfy, this might be useful [12:18] https://wiki.ubuntu.com/ReleaseTeam/Meeting/Agenda/TeamTemplate [12:18] ty [12:19] yep, that's the template [12:19] elfy, anyway, don't geel *obliged* to do it if you don't want to :) [12:20] elfy, you are luckier than me that knome got the testcases rewritten before you become QA contact, I have to do the tiring job:P [12:20] oh - I'm happy to do it knome - I'd not have said I would if I didn't want to :) [12:20] elfy, ok, thanks :) [12:21] welcome :) [12:22] :) [12:22] knome: got my new machine - didn't need to worry about uefi etc - just moved the drives, turned it on and carried on as normal [12:22] hihi, good [12:22] laptop/desktop? [12:23] * smartboyhw thinks UEFI is a bunch of **** developed by Microsoft who clearly does not know what is F/OSS [12:23] desktop - hate laptops - always end up with cramp from the touchpad things lol [12:23] was a barebones thing - no drives no OS [12:23] * smartboyhw is using a laptop to do EVERYTHING including testing:P [12:23] they have their pros and cons [12:24] yep [13:22] What does elfy need to talk to me about? [13:22] astraljava, how to be a QA contact person:P [13:23] astraljava, qa meetings, probably sending mails to release team [13:23] knome: Aren't you sending those emails? [13:24] * smartboyhw now sends mails to release team after getting scott's permission:P [13:25] But that's over on Studio's side. [13:25] astraljava, well, i should be sending, but seriously talking, we should get stuff in order before anybody can send those reliably [13:25] astraljava, i'm talking about team reporting [13:26] Hmm... yet another email template, then? [13:26] no, not anything like that [13:26] internal reporting [13:26] the one who sends the mail to release team should know what people have been up to [13:27] and shouldn't really do the detective work [13:28] Err... well, have fun trying to keep all that in mind. [13:28] They expect to have a list of bugs being worked on, for instance. Can you keep those numbers all in your head? [13:28] well exactly. [13:28] no, i can't [13:28] There you go then. :) [13:29] That's why my inbox exploded, cause I wanted to keep all bug mail during the week, until report was sent. [13:29] there should be a better way to track those bugs and items [13:30] Also, [release]-changes ML was damn easy to pick the changed packages from, too. [13:30] hmm? [13:30] If you come up with any, by all means. [13:30] i'm thinking the reporting could be tied to the work items tracking [13:30] because we need to do that anyway, and i can see how we benefit from that [13:31] if a work item is INPROGRESS, the team works on it, aight? [13:31] Not all bugs directly relate to a work item on blueprints. [13:31] that's true, but they should all be linked to the blueprints [13:32] and if their status isn't fix committed/fix released, they are still worked on, unless they are new/triaged or so, when they're still... new [13:32] I'm not at all sure you'd want to include all bugs to blueprints. [13:32] I know I wouldn't. [13:32] But you're... strange. [13:32] why wouldn't you link all bugs you are workig on that contribute towards a blueprint? [13:32] +n [13:33] Well I suppose then you'd have an obligatory "Improve QA" blueprint for every release. [13:34] not a problem: https://blueprints.launchpad.net/ubuntu/+spec/other-r-xubuntu-bugs [13:34] Ok. Somebody has to update that blueprint throughout the release, then, to make sure that every new bug gets added. [13:34] Volunteers? [13:34] Oh, I know. [13:34] ELFY! [13:34] i mean, creating and maintaining one more blueprint isn't too bad, if that means we'll get the team reports done [13:34] :P [13:34] no, i don't mean *any new bug in xubuntu* [13:35] because we don't need to track bugs we aren't working on [13:35] Those are the bugs I meant when I said I wouldn't want all bugs into blueprints. [13:35] if somebody starts looking at a bug, or is working on it, link it then [13:35] Oh. [13:35] Fine. [13:35] oh. yeah, i don't want them in blueprints too [13:35] s/too/either/ [13:36] Ok. You know how Lionel will feel about this change in the process, right? :) [13:36] since we only need to report those we are working on, it's not too hard to track them under blueprints [13:36] yes, i know, but i've been managing the blueprints anyway [13:36] and i don't think it's a huge burden [13:37] if you have time to look at the bug, or work with it, maybe you will have time to link it, or tell somebody to do that [13:37] When you're battling 140+ bugs a release... [13:37] we haven't been reporting those bugs to the release team before [13:37] and i'm not sure what the policy should be on what is reported [13:37] I did, for a brief period of time, anyway. :) [13:38] yeah, thanks for that [13:38] but the list per mail wasn't >10 [13:38] maybe i/we should talk with skaet [13:38] But I think I was pretty much alone in that. Don't think many teams shared that hobby with me. [13:38] Hey elgy astraljava is here [13:39] "why do we have to report these, since you can simply look at our work items tracker" [13:39] *oops hey elfy [13:39] if a bug isn't worth mentioning in a blueprint, why would it be worth mentioning in the mail to release team? [13:39] i mean, i can't see these *not* walking hand in hand [13:39] Oh it would totally eliminate the need to do that, if they _were_ actually tracked somewhere. [13:40] Currently _this was_ the tracking process. [13:40] ...or _is_, rather. [13:40] But then we're not really categorizing our bugs, either. [13:41] I'm pretty sure the release team is actually interested about release blocker bugs anyway. [13:41] +only [13:41] * smartboyhw is sucking in all those contents:P [13:41] But since our work flow was lacking in this department (too?), it was clearer for me to report them all. [13:41] but, don't you agree that these two procedures are just duplicating each other? [13:42] Yea, I just said so a few lines above. :) [13:42] yep, so that one is sorted out [13:42] ACK [13:42] meh, "what was done engineering wise" [13:42] :P [13:42] i think that's the worst question ever [13:42] knome: +1 [13:42] what does that "engineering" mean really? [13:43] Dunno. Maybe some new features? [13:43] * smartboyhw suggests going to #ubuntu-release to ask that question:P [13:43] Oops;P [13:45] knome: That was easy, pick up the new uploaded packages from -changes. [13:45] No one ever complained about that method. [13:45] It's actually stuff that matters, too. Versioning of packages in the archives. [13:46] Not so much of Xubuntu's packages, of course, as not many (anyone?) depend on them. [13:46] But still, from the release-team-POV, it's useful information. [13:47] And for us, it's usually a no-brainer. Just pick the ones where uploader is either Lionel or Micah. :) [13:47] lol [13:47] Of course Micah uploads other packages when acting as a PP. [13:48] But you get the idea. [13:52] yeah. [13:53] so, there's the "what did you do?" and "what bugs did you work on?" which are sorted [13:53] now, what's about to land blah is trivial too, once you have those done [13:53] and the dependencies/blocking/concerns too [13:53] Yep, most often that was a "N/A" for us. [13:53] * elfy wonders if this conversation is about what I was being told earlier [13:54] elfy, yeah, we're talking about the mails to the release team [13:54] if it is - I missed the beginning :p [13:54] elfy: Yes:P [13:54] elfy, i'll paste you [13:54] thanks knome [13:55] elfy, http://paste.ubuntu.com/1253911/ [13:58] ta [13:59] np [17:19] Anyone wanna run a xubuntu session in open week in a little less then a month? === philballew_ is now known as philballew === yofel_ is now known as yofel [21:04] I'm having a bit of problem with editing the menu. Added a submenu, more or less like here http://wiki.xfce.org/howto/customize-menu#create_sub-menus. And looking at other edits, I can't see what's different with mine. The problem I'm having.. [21:05] The submenu is named after its parent, instead of Myname [21:06] To clarify, the submenu is displaying its parents name in the actual menu, while in the file, I'm using a custom name with Myname [21:06] If I use .., and inside it , using the custom menu name, I still see the parents name displayed [21:20] Well, I've realized the needs to exist somewhere