=== jjohansen is now known as jj-afk [01:02] it'd really be nice to be able to read the PDFs my bank sends me without booting windows. [01:02] (write password, null read password) [01:02] * lamont wonders which package to file that bug against [01:05] evince [01:07] Really? I thought it'd be poppler === bjf is now known as bjf[afk] [01:14] well, poppler perhaps [01:14] I usually start at the top and let them worry about it ;-) [01:14] though I think poppler is now libpdf or something [01:15] lamont: I think okular will handle those. [01:16] lamont: send me your bank statements, i'll read them to you. ;) [01:20] evince in Maverick grew the ability to read my bank statements, which was nice :) === bjf is now known as bjf[afk] [01:34] ScottK: I'd prefer not to install the world of kde just to see it.. I'd rather libpdf got smart enough to open null-password files [01:34] achiang: heh [01:35] lamont: It should be somewhat less than the whole world these days. Isn't that still better than having to use Windows. [01:35] lamont: It's just kdelibs and the base runtime. None of the workspace components needed. [01:36] 9 upgraded, 64 newly installed, 0 to remove and 221 not upgraded. [01:36] Need to get 56.0MB of archives. [01:36] which tells me it's time for a dist-upgrade === dendro-afk is now known as dendrobates [01:37] I'd be happy enough to just know which packages I need to downgrade to hardy-versions, since I think libpdf or whatever just didn't believe in passwords back then, or something like that [01:38] Keybuk: so is libpdf the right place to file the bug? [01:39] errr [01:39] I really don't know [01:39] I find that application authors are much more helpful if you misfile a bug on them, than library authors [01:39] a bug filed on a library tends to stay there ;-) [01:40] ah, good point [01:40] though epdfview (libpoppler based) has the same issue. [01:40] I'll toss it at evince === dendrobates is now known as dendro-afk === hunger is now known as Guest49265 [03:14] I'm looking to create an indicator applet, anyone know a good tutorial? [03:26] dugger5688: I don't think there is a good (or any) tutorial, you should just read source of applications that use it [03:34] kklimonda: That's what I ended up doing, thanks. [03:37] dugger5688, these might be of help: https://wiki.ubuntu.com/MeetingLogs/devweek1001/AppsOnThePannel , https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Technical%20Resources [03:43] ajmitch, Hey. Do you have a bit of time to talk about ARB/-extras and how this affects the support team? [03:45] woa [03:45] another dugger [03:47] persia: alright [03:48] ajmitch, So, if I'm reading stuff correctly, if there is a bug, there is an expectation that the author will fix it, and arbitrary developers won't be able to upload changes. Is that correct? [03:49] at the moment I'm unclear on the permissions surrounding extras.u.c [03:49] It's the ~a-r-b PPA. [03:49] Right now !extras is an alias to !repos, which doesn't mention extras.u.c at all, and I think we'd do well to advise the support teams of what level of support we can offer, and how they can request it, etc. [03:49] wgrant: right, I wasn't sure if that PPA was just a staging area or if extras was being exposed as another pocket [03:50] ajmitch: It's synced from the PPA and resigned. [03:50] pocket copy from the PPA to somewhere else or not isn't really important: mirror implementation detail :) [03:50] This makes the set of extremely dangerous Launchpad users quite a lot larger :( [03:51] How so? Isn't the ~a-r-b PPA restricted to ~a-r-b members? That's only four new people to trust. [03:51] (although they are subject to less peer-review than usual) [03:51] persia: to be honest, I was expecting to have a little bit of time to discuss implementation specifics on the list before the process was announced :) [03:52] persia: ~a-r-b isn't just the ARB. [03:52] It has a few others as well. [03:52] * persia digs at LP [03:52] https://edge.launchpad.net/~app-review-board/+members [03:54] Right, so untrusted folk are tremolux, wendar, jono, and fagan, with special danger from tremolux, and jono, and expanded permissions for mvo. [03:54] Given that mvo basically controls how we install software anyway, I'm not sure that it's really expanded permission there. [03:55] So just tremolux, wendar, jono. [03:56] Anyway, that's a separate can of worms than the one I wanted to review today :) [03:56] ideally it'd be owned by the TB [03:56] right, the issue was of bugfixes [03:56] Couldn’t there have just been an “extras” component alongside main, restricted, universe and multiverse, with a similar process to them (with -proposed and all) etc? [03:56] So if it is the ~a-r-b PPA, then I'm fairly confident that ~ubuntu-dev can't support it. [03:57] ion, No, for complicated reasons having to do with Release and Packages files. [03:57] why I was wondering if it was a separate pocket was whether the packages will even show in launchpad to be able to file bugs against them [03:57] wgrant, Do you know if Malone will allow bugs to be filed? [03:57] * freeflying [04:03] ajmitch, Whilst we wait, I was thinking we might adjust !extras to be "extras.ubuntu.com contains new software made available after the formal release. This software is unsupported by the Ubuntu team, but the original authors offer some support." [04:03] Does that wording seem acceptable to you? [04:03] that seems reasonable [04:04] OK. I'll request that change, and let the meme seep through the various channels by which the support team collect information :) [04:05] Err, rather "extras.ubuntu.com is an additional !repo that contains..." [04:06] g/c [04:06] persia: It's not just unsupported. It's not part of Ubuntu. [04:06] ScottK, You have better alternative text? [04:08] repo's url is misleading :/ [04:08] I don't understand why it's under ubuntu.com [04:08] * ajmitch would love to stay & discuss that, but has a bus to catch in 5 minutes :P [04:08] "extras.ubuntu.com is an external repository for new software made available after the Ubuntu release. This repository is not part of the Ubuntu distribution and the software is completely unsupported by the Ubuntu team, but the original authors may offer some support." [04:08] persia: To LP it's just another PPA. [04:08] persia: It's not like partner. [04:08] persia: ^^^ [04:08] wgrant, So no bugs. Thanks. [04:08] ajmitch, Does ScottK's suggestion also work for you? [04:09] persia: But you can make a project with the same name that can get bugs. [04:09] ScottK: Is "completely" really necessary? [04:09] persia: See ~kubuntu-ppa and /kubuntu-ppa for an example. [04:09] kklimonda: Yes. [04:09] ScottK, Right, but not using the recommended bug reporting mechanisms (e.g. ubuntu-bug, apport, etc.) [04:09] kklimonda: Universe is also unsupported. [04:09] persia: Of course not. Those are recommended for Ubuntu and this is not part of Ubuntu. [04:09] ScottK: I mean, are people going to get confused if we leave this word out. [04:09] kklimonda: So it needs to be made clear that extras are even less supported. [04:09] wgrant, For some value of "unsupported" [04:10] * persia will be filing a blueprint about that any day now [04:10] persia: Yes, but it's billed as unsupported. [04:10] I know. I just wish that it wasn't, or that what was billed as "supported" had a well-defined support group. [04:10] kklimonda: Here's what is said about Universe in sources.list: software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu team. [04:10] This is less supported than that. [04:11] Considerably. Lots of folk support lots of parts of universe. [04:11] ScottK: whoa, I haven't seen that :) [04:11] Some folk release flavours based on healthy chunks of universe. [04:11] Who decided it would go under extras.ubuntu.com? [04:11] That's asking for trouble. [04:11] wgrant, opaque [04:11] wgrant: Probably rickspencer3. [04:11] Yay. [04:11] wgrant: It's all been pointed out multiple times, but they are doing it anyway. [04:11] I know. [04:12] I just hoped that some new knowledge might have come to light. [04:12] All the more reason to ensure the support team understands: we can best avoid confusion by prepping the first line to give good answers. [04:12] I don't think there's much actual knowledge involved. [04:13] As well as giving an incorrect image, it also grants unvetted people access to my machine. [04:13] Previously it would need someone who had been interrogated by the DMB. [04:13] Only four of them, and in a way that can be avoided. [04:14] There are members on the ARB who are not ~ubuntu-dev. [04:14] Right. jono, wendar, fagan, and tremolux [04:14] i don't interrogate anyone :( [04:14] dmb, But we, on the DMB, do. Capitalisation is important. [04:14] dmb: You are a dmd, but not the DMB. [04:14] :) [04:15] ajmitch, So, can I use ScottK's version, or do you want me to proceed with mine? (I like ScottK's better) [04:17] ScottK: do you know whether there have been arguments for not doing it through -backports? Is it to make it easier for.. random developers to get their software into Ubuntu? [04:17] * persia would also accept a nod from stgraber, mvo, or statik [04:17] I just don't quite understand how does it help us to deliver good software.. [04:17] kklimonda: It's all been discussed. They've decided to do it the way they are doing it. The community input is not particularly relevant. [04:17] kklimonda: It doesn't. [04:18] It lets Canonical make a marketing point about Ubuntu being great for app developers. The technical reality doesn't seem to be particularly important. [04:18] ScottK: It's not been discussed. [04:18] Discussion was not allowed. [04:18] Or was ignored. [04:19] wgrant: No. It was discussed at UDS-M. [04:19] * persia didn't want to bring up all the potential things about extras.ubuntu.com: just to set some expectations for the support team [04:19] I'm not fond of entire "opportunistic development" idea and now this.. [04:19] It was "too hard". Implementing a whole new pocket was easier. [04:22] kklimonda: I think opportunistic development is a great thing to support since a LOT of that kind of work goes on inside companies, but that doesn't translate at all into the arb stuff. [04:23] A lot of that work goes on outside companies too, resulting in nifty cool things. [04:30] persia: I'm fine with both yours and ScottK's versions. The "external" bit is going to be quite unclear for a lot of people I'm guessing as it's going to be on .ubuntu.com but I don't really have any better suggestion. [04:30] (sorry, took me a while to read the backlog) [04:31] stgraber: I'd like it better if it were on canonical.com (it would be clearer), but not much we can do about that. [04:31] Maybe we can get it fixed for Natty. [04:32] ScottK: persia: but those cool things created outside of companies are often buggy or.. really simple. I haven't seen anything cool myself other than various scripts which are more of hacks -- in a good way -- then applications. Or maybe I'm just afraid that we'll create environment for tinkerers.. which isn't actually that bad.. but I feel like it misses the spot, especially when people blog [04:32] about new indicators which are against guidelines created by Canonical designers. But then I may be prejudiced - "opportunistic" has a really negative meaning in Polish. [04:33] kklimonda: When it's good, it's about it being easy to solve a small local problem. We should be in favor of that. [04:33] Converting that into applications that are suitable for general use is a lot of work. [04:33] Nominally it's an order of magnitude harder (See Fred Brooks, The Mythical Man-Month). [04:34] That's where the confusion is. [04:34] persia, I am not on the ARB, to be clear [04:35] jono: Hm, but you're in ~a-r-b... [04:35] jono: But you're on the LP team, so you have whatever accesses it has. [04:35] ScottK: well, canonical.com would feel weird too as it's not a canonical-only archive as partner is for example, but I'd certainly like to see that evolve into something more like the archive, where the ARB would act as archive admin (looking at the queue, accepting new packages, ...) and having the other ubuntu-dev be able to upload updates as usual. That'd also mean that bug could be reported as for any other packages (ideally, LP would m [04:35] ScottK: every time I see this title I read it "The Mythical Man-Moth" ;) [04:36] stgraber: You got cut off. [04:36] stgraber: But that sounds like -backports. [04:36] jono: ah, it says that you are on https://launchpad.net/~app-review-board/+members but I guess it's just because you're meant to administer it then? [04:36] highvoltage, yep [04:36] stgraber: Unfortunately many of the things one needs to know to be do archive admin work aren't in what they ask for for ARB members. [04:37] I just set up the team, that's all [04:37] I am not eligible to assess apps [04:37] jono: But the secuirty footprint is the same is if you were. [04:37] I don't too much care about the ARB making bad decisions. [04:37] ScottK: I want to eliminate the spring package duplication (spring-engine needs to be a dummy that installs spring). Can I just upload a new spring package providing the dummy or do I need to first file a task to remove spring-engine? [04:37] ScottK, security footprint? [04:37] wgrant: "(ideally, LP would make it clear that it's on "extra" and not supported in any way)" I guess that's the missing part ;) [04:37] YokoZar: Go ahead and then file a bug asking for removal of the old source. [04:37] I care about the fact that compromise of their browser results in compromise of every Ubuntu machine on the planet. [04:38] jono: If someone gets your LP cookie, they can do the same stuff any arb member can do. [04:38] ScottK, is this something you are seriously worried about? I think I can maintain my security :-) [04:38] jono: I don't think anyone can. I have had LP admin cookies on multiple occasions. [04:38] People make mistakes. [04:38] jono: Security is about minimizing risk and removing it where it's not necessary. [04:39] The fewer people can make fatally large ones, the better. [04:39] ScottK, right, but what is the worst that could happen? they can post to the group - there is no upload access from the arb group [04:39] jono: Er... [04:39] jono: They own the PPA. [04:40] http://extras.ubuntu.com/ubuntu/dists/maverick/Release [04:40] erk, wise point :-) [04:40] lol [04:40] extras.ubuntu.com is that PPA, resigned. [04:40] what would you recommend I do to mitigate the security risk? [04:40] leave the team? [04:40] I don't know. [04:40] Turn over the team to the tech board, probably. [04:40] It needs to be discussed with people. [04:40] well I am happy to take appropriate steps [04:40] And not just rushed through without consulting anybody. [04:40] srsly. [04:40] ScottK, seems entirely reasonable [04:41] maybe I can hand it to the TB and they can discuss appropriate actions [04:41] If any of them get compromised, we're already screwed, so this doesn't make it worse. [04:42] ScottK, if you have a better suggestion I am happy to hear it [04:42] jono: the whole ARB thing is a serious blow to the quality of ubuntu process, stgraber's suggestion makes a lot of sense [04:42] No, I think that's the best thing, but I'd discuss it with them first. [04:42] highvoltage, what was stgraber's suggestion? [04:42] highvoltage: Who needs input from the development community? Silly. [04:43] wow, it is frosty in here [04:43] jono: scroll up a bit to the part about 23:37 < stgraber> ScottK: well, canonical.com would feel weird too as it's not a canonical-only archive as partner is for example, but I'd certainly like to see that evolve into something more [04:43] remember this process is experimental and we are going to discuss this at UDS [04:43] and if required adjust and refine where required [04:43] jono, If you don't want to be on the team, there's a way to be owner of the team, and not a member, but still admin. I don't know the details of setting that up, but it's why I can't upload to most of main. [04:43] I was merely asked to put together the process, which I did [04:43] jono: what is more frosty? good feeback from people who care? or canonical saying they're going to implement something really bad and they don't care what anyone has to say about it? [04:43] jono, This doesn't make the risk much lower, but a little bit. [04:43] persia, ahhh thanks for the input, I will investigate this [04:44] highvoltage, I was referring to the general tone in here, it just feels rather frosty [04:44] * highvoltage hands jono a cup of hot chocolate [04:44] lol, thanks :-) [04:45] jono, Note that you still need to preserve your keys: I'm not core-dev, but my LP credentials are at least as useful to an attacker as any core-devs. Yours will soon become considerable (getting your LP password means having root on millions of machines) [04:45] jono: The whole ARB thing does seem to have been implemented in a manner that was pretty impervious to community feedback. [04:45] I am not denying that things can be improved in the process, absolutely, and we should have a throrough assessment at UDS [04:45] ScottK, I disagree [04:45] I'm not suprised. [04:45] ScottK, I believe that community feedback has been accomodated, but the outcome is not what you would prefer [04:45] So, can we dispute specific technical issues? [04:45] ScottK, I am fully aware of your unhappiness and concern with the ARB [04:46] So we are opening up new holes on people's machines... before we do the assessement. [04:46] jono: I'm not the only one. [04:46] Awesomeness. [04:46] There's been some process issues, but I think we'd do better to fix it than to go over what happened badly so far. [04:46] ScottK, agreed, but there are also others who welcome the process [04:46] persia, I think UDS is the perfect venue to bring all concerns [04:46] persia, agreed [04:46] jono, I think it's important not to conflate people who want it to be clearer and easier to add apps post-release with people who like a specific process. [04:46] jono: Why? Last UDS it wasn't so perfect. Why will this one be different? [04:47] persia, agreed [04:47] jono: I agree with the goal, I just think this is a very poor way to achieve it. [04:47] ScottK, because we can try the process, assess it's success, and review it at UDS [04:47] ScottK, I know this, we have already discussed this [04:47] I am not wanting to deafen you, but I am not sure why we should have the conversation again [04:47] Absent appropriate technical underpinnings, the process can't succeed. [04:47] I think we are clear on each other's points [04:48] Certainly. [04:48] ScottK, I think your feedback and a solid review at UDS will be very valuable [04:48] We'll see. [04:48] and as I made clear in the discussions, my sole resonsibility was to put together an assessment board, I am not qualified to provide input on the technical implementation [04:49] Forcing feedback to occur after it's all already implemented seems a little odd. [04:49] I'm aware of that. [04:49] if you disagree with the governance, then that is up to me, but it sounds like your primary concern is the technical approach [04:49] jono: Don't get confused with me being upset about the structure as a whole and me blaming it all on you, I don't. I know what you were trying to do. [04:49] personally I think the sandboxing approach you mentioned on the phone, ScottK, makes great sense [04:50] It's the only way. [04:50] ScottK: jono doesn't seem to understand the problems (or doesn't want to) [04:50] ScottK, I know, and I respect your honestly and balance [04:50] highvoltage, what don't I understand? [04:50] highvoltage: I think it's mostly just not in the part of the initiative that's his problem. [04:50] ScottK, yeah, again, with the caveat that I am not the best qualified on the technical approach, I agree that a sandbox seems the best approach and safe [04:50] jono: My biggest problem with the process is that absent that appropriate technical basis, it's horribly premature. [04:50] jono, I think folks have issues with both, on three points: 1) that the technical critiques and alternate model discussed at UDS (and afterwards) did not appear to be considered, 2) That the body of approvers is not restricted to the already trusted ~ubuntu-dev, and 3) That the process development was relatively opaque, even to members of the new board. [04:51] jono: 23:47 < jono> ScottK, I believe that community feedback has been accomodated, but the outcome is not what you would prefer [04:51] jono: that sentence tells me that you haven't really been listening [04:51] persia, on the latter point, I was entirely guilty [04:51] jono, I don't claim this is the place and time to discuss it, but I think it's important to separate the concerns in order to avoid pointless arguments blocking real progress. [04:51] the process was developed in the open (wiki, with the TB etc), but I did a terrible job of involving ubuntu-devel [04:52] highvoltage, how does this infer that I have not been listening? [04:52] highvoltage, just because the eventuall decision was not in line with some opinion on ubuntu-devel does not mean I wasnt listening [04:52] jono, Always feel free to lean on me if you're unsure how to involve development folks in something. I can't promise people will like it, but I can promise you'll get feedback and discussion. [04:52] highvoltage, also, as I have made clear, I am not involved in the technical implementation [04:53] highvoltage, and I apologized fully about not involving ubuntu-devel enough [04:53] jono: because you think that it's just about prefered outcome. it's not, it's that people care about ubuntu and want to make it better, and this process isn't doing that [04:53] highvoltage, hence, I believe I did listen in the area of *my* responsibility, but you should not judge me based on the responsibility of the technical process [04:53] jono: yay plausable deniability. [04:53] persia, I always respect and value your opinions and experience, thanks for the offer [04:53] highvoltage, Don't kill the messenger: jono didn't have choice about some large parts of this (as I interpret backscroll) [04:54] persia, again, I really could have done a better job with the process development [04:54] persia: ok [04:54] jono: sorry if I come across too hard [04:54] highvoltage, no worries, pal - I am sorry you are frustrated :-( [04:54] highvoltage, Not that I'm telling you not to raise the points, just not to pin it all on one person :) [04:54] Where are we to give feedback? [04:54] highvoltage, yeah, I think your points are better attributed to those who built the technical implementation [04:55] The ARB doesn't know why it happened like this. [04:55] wgrant, what kind of feedback? technical process? [04:55] jono: Technical issues, process issues... [04:55] wgrant, feel free to provide process issues to me [04:55] technical issues, Rick Spencer is probably a good person to talk to [04:55] Discussion on the ML was limited to being told that it was all set in stone. [04:55] jono, I suspect that those answers are likely some of the issue: I suspect people would like to hear "The CC" and "The TB". [04:56] Do the CC or TB have power any more? [04:56] wgrant, well, that is not 100% true, nothing was set in stone, but I agree that a largely completed draft was presented to ubuntu-devel as a whole, and I have said, that was a mistake on my part [04:56] Some, in some areas, depending. [04:57] As I see it, Platform will come along and push things, and the relevant governance body might wave them through. [04:57] wgrant, why do you assume that? [04:57] neither the CC or TB is pushed to approve anything [04:57] I can 100% guarentee this [04:57] and I would whole-heartedly push back if Canonical tried to force the hand of the CC or TB [04:58] It was apparently accepted without any discussion with people not directly related to its implementation. [04:58] jono: That's true, but they are busy people. They evaluate what is put in front of them. The analysis of alternatives given to the TB didn't even include using the existing backport pocket as an option that was consdiered. [04:58] jono, CC is fairly independent, but also fairly inactive, which is OK, but lots of stuff gets directed to you, rather than to CC, which complicates the picture. No offense to you, but it weakens the perception of CC as point of contact and point of decision. [04:58] wgrant, the TB evaluated the process and made a series of suggestions which were merged in, they then approved the process based on the changes [04:59] wgrant, and I have already apologized for not including ubuntu-devel in the discussion, not sure what else you want me to do, I can't change history :-) [04:59] Most of TB is privy to data that may not be widely exposed, and under (mild) restrictions: they are unlikely to disagree with certain classes of initiative (many of which are good in the first place). [04:59] wgrant, I can assure you I will not make the same mistake again [05:00] ScottK, I agree, but I am not sure it is scalable to present alternatives with every proposal to the TB - I do though have faith that if the TB felt an approach had a better technical alternative, they would pick up on it [05:00] I am disappointed that we have a new, opaque, extremely security-sensitive process. [05:00] I firmly believe that the CC and TB are able to control the project if they choose to do so. I'm not sure that such a choice has always been made in the past. I'm not convinced that waiting for complaints is not a useful way for the boards to operate, as long as people are making complaints. [05:00] And we *cannot* fix it. [05:00] persia, well things often come to me, but if it affects the charter that the CC are responsible for, I send it to the CC [05:01] the CC never ask me to make decisions [05:01] but indeed many come to me before the CC, and then I move it to the CC if it needs their attention [05:01] jono, I know. I see that. Doesn't change the perceptions I hear from folks not as familiar with our governance structures as you and I :) [05:01] persia, maybe we need to improve that perception, what do you think we could do to improve it? [05:01] jono: The wiki page specifically described alternatives that were considered and didn't include the one that to many of us made the most sense. That's really, in some sense, cooking the books. I don't blame the tech board a bit. They can't evaluate information they don't have. [05:02] jono, To be clear, I'm not critiquing you. I think you are a valuable member of our community, an important leader, and do your job well. That doesn't mean I don't think there are areas for improvement, here and there. [05:02] wgrant, i am sorry for your frustration, but we did discuss reviewing the process at UDS, and I think you should express your feedback strongly then [05:02] jono: ... after the process is implemented. [05:02] ScottK, the process I put together didnt outline alternatives [05:02] jono, I think that it makes sense to sit down and review all our governance structures, who reports to whom, how, what accountability groups have, what responsibilities groups have, etc. And make sure it's all in one document somewhere, and point folks there. [05:03] jono, I'm hoping the track you lead at UDS will let us start on some of that. [05:03] persia, it might be good for us to draw a governance map of how everything fits together and socialize it as a whole [05:03] persia, good idea [05:03] sorry guys, but I need to run [05:03] Have a good night. [05:04] Night jono. [05:04] sorry for the frustration, I hope we can alleviate it soon - again, please feel free to provide feedback to me on the process [05:04] biab [05:05] jono: I know you're just the process guy, but until the technical elements are defined it's impossible to get the process right. [05:06] The converse is also true to some degree. The two are best considered in concert. [05:06] ScottK, I am positive we can get the process right [05:06] ScottK, I think if you can recommend a strong proposal for a better alternative at UDS, that could be awesome [05:07] in my mind, if there is a clearly better technical implementation that does not require significant resources to implement, then it would be bonkers not to consider it [05:07] Did anyone ever document the backport-based process we reviewed at UDS last time? [05:07] ScottK, maybe you, wgrant and persia could put together a proposal ready for UDS? [05:08] * persia would want to see Laney and stefanlsd involved as well, as they were part of the group that argued that process last time. [05:08] jono, Anyway, you have somewhere else to be (noted above). Go. Come back. [05:08] persia, totally [05:09] We could also unterminate the mailing list discussion, so we can get additional viewpoints... [05:09] jono: Unless rickspencer3 indicates he's open to do it a different way, I think it would be a waste of time. [05:09] I think having a prepared proposal could be awesome for the discussion [05:09] ScottK, I know rickspencer3 would be open to better technical solutions that meet the goal [05:09] And to follow-up on what initiated this discussion (and thanks to stgraber for the approval) [05:09] !extras [05:09] extras.ubuntu.com is an external !repo for new software made available after the Ubuntu release. This repository is not part of the Ubuntu distribution and the software is completely unsupported by the Ubuntu team, but the original authors may offer some support. [05:09] jono: There precious little evidence of that in the actions to date. [05:09] persia: Looks reasonable. [05:09] ScottK, I think that is a bit harsh [05:10] Lets start from the assumption that things can be sorted, and approach our governance bodies if they can't. [05:10] jono: What changed based on the developer feedback to your call for arb members? [05:10] ScottK, rickspencer3 is very open and flexible to the best solution; I don't believe it is "his way or the highway" [05:10] Complaining at folks because of corporate affiliation doesn't help maintain our community. [05:10] persia, entirely agree [05:10] That may be, but so far the entire evolution has been remarkably insensitive to outside feedback. [05:11] ScottK, as persia says, if you feel there is corruption here, you should raise it with the CC/TB [05:11] jono: It's not corruption, it's just how Ubuntu works. [05:12] ScottK, no it isn't - no one has the right to force their will on people, but people do hav ethe right to be passionate [05:12] it sounds like you have a concern that rickspencer3 is forcing his will on people, and if you have evidence to suggest this, it would not be unreasonable to raise this with the CC/TB [05:13] jono: What's the community process for deciding what apps go in the default Ubunt install? [05:13] ScottK, what kind of apps? [05:13] There isn't one. Canonical managers basically decide and that's what happens unless there is overwhelming community feedback to the contrary. [05:13] hey snookies! [05:13] ScottK: you file a RFP! :D [05:14] so while there's people who know how things work awake and online and such.... if there's a blueprint from four years ago that was never implemented, is it valid to bring it up again for natty? [05:14] ScottK, right, but if you are arguing this is the Ubuntu way, why are you complaining if rickspencer3 pushes something through? [05:14] * nixternal can't even read what the hell is gooin on in here [05:14] nixternal: spirited discussions [05:14] jono: I didn't say I like it. [05:14] ScottK, then change it [05:14] maco: yes. that's why blueprints are not deleted [05:14] ajmitch: i am quite drunk, do is o.....bah [05:14] But as nixternal pointed out on another channel, I've not drunk sufficiently tonight, so I'll see you all later. [05:14] * ajmitch was just catching up on scrollback [05:15] ajmitch: i read the first 2/3 of it and gave up [05:15] i need to be hanging out with jono right now. white castle style! [05:15] ScottK, ok [05:15] nixternal, let's roll! [05:15] nixternal: heh [05:15] nixternal: what, you want sliders? [05:15] hell now! [05:15] no! [05:15] anyway, I best leg it, I need to tidy the house in a sec [05:15] no sliders; i was out drinking and fighting witht he tea baggers tonight. much fun [05:15] jono: I'd just wished we'd had a bit of time to discuss organisational issues before you announced the process, but that's past now [05:16] ajmitch, yeah, I apologized for that :-( [05:16] jono: fyi, we need to talk. have a conference coming up and would like you to be here. next april actually [05:16] * ajmitch is still hoping to get some responses back from others on the arb list [05:16] nixternal, sweet, let's talk soon [05:17] right, I am off, laters all! [05:17] later [05:18] highvoltage: so how would you suggest i bring up this blueprint again? its one requesting a font manager in the default install, which says to me it goes in the default packages session, whenever teh heck that is at uds, but somehow need to make 2 blueprints fit one session or something.... [05:19] maco: I can't tell you how to best match your blueprints to sessions, but you can add it to the UDS by clicking on "Propose for sprint" [05:19] mmk [05:19] You probably want to review and clean up the spec to be accurate for natty. [05:21] the current spec wiki page for it is a bit funny in the use case section, because as akk pointed out, it looks like the one name that is used for 3 separate use cases is really someone with an inflated idea of their own skill level writing pseudononymousely [05:22] Lots of times use cases are things-the-author-wants-to-be-able-to-do [05:23] Way-back-when when the other Jane managed a nice spreadsheet for us to review, everyone would look at all the blueprints, and add their own use cases. We just have too many now. [05:23] persia: which may still be valid though [05:23] highvoltage, They almost certainly are valid, although perhaps in need of stylistic help. [05:23] * highvoltage remembers other Jane's spreadsheet [05:23] culling a few blueprints might be useful one day [05:24] certain people want to remove blueprints altogether :) [05:24] maco: Why would we need a font manager when everyone will love the new Ubuntu font? [05:24] I'm in favour of either removing blueprints (and adding spec pages to certain bugs) or revamping with mpt's mockups of a total project management system. [05:25] ScottK, Because I can't use that font here. Neither can at least half the population of the world. Next LTS maybe. [05:25] persia: either way, it's an area that sorely needs some love [05:25] ajmitch, Totally. === almaisan-away is now known as al-maisan [06:29] jono: re your severed fifth post: Maverick is 10.10, not 10.04. [06:31] ScottK, wow, I am an idiot, thanks for the note [06:31] fixing now [06:32] No problem. Stuff happens. [06:32] :-) [06:40] Good morning [06:40] kees: I liked mdeslaur's suggestion to go back to what lucid had, so that it's configurable [06:41] kees: personally I don't want any timeout; I need it so often during the day, and it's quite a long one [06:41] kees: ideally it would be forgotten on suspend [06:44] Speaking of credentials timing out... is anybody else finding that maverick's seahorse-agent isn't prompting to reuse GPG passphrases? [06:44] It just does it silently without asking for confirmation :( [06:48] morning pitti [07:12] '/ === amitk-afk is now known as amitk [09:21] pitti, Hi Martin, I am (once again) trying to get forward in the task of getting the Lucid proposed kernel to updates. There are a few more verifications done by now. But there are also 5 (including the one already marked) that sound like verification failed. All ALSA quirks which seem to have no effect. [09:22] smb: as long as they just don't fix the bugs, but don't introduce regressions, it's fine; we can just keep them open [09:22] or rather, reopen them after moving to -updates (since that autocloses bugs) [09:23] Would this require an additional upload with the bug numbers manually removed? All or at least most of the patches are coming through upstream stable [09:23] Ah ok, answers the question [09:24] I'd prefer that because generating a new upload is time consuming [09:25] pitti, I would set the verification failed tags then and I would write mail to Daniel and David to make them aware. Do you want to be on cc? [09:25] smb: that's fine, I'm already sub'ed to the bugs [09:26] (and we should keep the communication there) [09:26] smb: if you mail them, perhaps CC: the bugs? [09:26] Hm, sounds reasonable to document it better [09:26]