[01:31] anyone available for a quick question? [01:31] NickServ [01:34] anyone available for a quick question? [15:08] hey guys [15:09] hey willvdl [15:09] has anyone built edubuntu from a minimal ubuntu install? [15:12] I've got a lovely little atom minibox thingy here with a 2G flash etc. and am trying to build up a minimal system before going through the hog of choosing select packages [15:12] so I use the alternate CD and do a command line install for a minimal system [15:12] but the debootstrap complains like a mother-in-law [15:13] a standard install works fine though. both are from a USB CDROM [15:39] weird. not a repeatable problem [15:39] how odd [16:06] ogra: heah, I applied for ~edubuntu-bugs, when you get a chance can you let me in? :-) [16:40] LaserJock, ola [16:40] hi willvdl [16:41] I'm playing with a very nice teeny atom [16:43] it's hawt [16:43] sweeeet [16:45] dual core as well [16:45] anyhoo [16:45] heh [16:45] they are tiny [16:46] the controller chip is bigger than the cpu [16:46] the cpu doesn't even have a fan [16:46] interesting [16:47] if this thing works it will be the ultimate classroom PC... waterproof, heatproof, shatterproof etc. [16:47] it's encased in anodised alluminium with heat tubes [16:47] lol [16:47] it is honestly submersible [16:48] * LaserJock wants one [16:48] how chemical resistant would it be? [16:48] depends. what eats alluminium? [16:49] I know children that are undernourished will eat many things but they probably lack the gum strength to chew through this [16:50] hmm, some acids might do some damage, but mostly it'll eat the anodization off [16:50] I remember an experiment in school [16:50] with an alluminium pencil sharpener [16:50] and a pot of steam [16:51] and a great erupting fireball [16:51] way cool [16:52] ooh ooh. anyone played with DRBL? [17:05] LaserJock, are you familiar with Scientific Linux at all? [17:06] I know of it, I've never used it though [17:06] it's never been all that appealing to me [17:07] hmm, seems to be rhel [17:07] but I haven't seen an app list [17:08] just curious cause they are mentioned from the clonezilla docs [17:09] it's basically taking rhel and recompiling it (ala CentOS) [17:10] but packing all the science related packages on a DVD [17:11] deja vu [17:14] right. I'm hungry and I have a chicken. [17:14] later [19:48] Wow [19:48] * Lns just finished reading the (aging) thread from the list entitled "Edubuntu 7.10 - A Released Debacle and a Practice in Failure" [19:48] Although I disagree with the title [19:49] I think this topic is something that is pure gold to what we're all trying to accomplish [19:49] if anyone wants to start a conversation based on that thread go ahead - otherwise i'll keep working :) [19:49] http://www.mail-archive.com/edubuntu-users@lists.ubuntu.com/msg02967.html [19:52] Lns: go on? :-) [19:53] LaserJock: well, I see the people who have replied and posted in that thread [19:53] And I see that we all have the same motivation to do the right thing and get Edubuntu/UbuntuLTSP absolutely rock-solid in typical setups. [19:54] What I see is the overall issue of how bugs are handled - and not to say LP fails, but IMHO there needs to be much more of a hierarchy, a better priority system for issuing these bugs [19:54] Such as the gnome-watchdog, hanging procs issue that's been happening for over a year now [19:55] IMHO this should have been implemented, tested and put into 8.04LTS. [19:55] But, this is even too specific for the conversation I want to have with the posters/other interested parties [19:56] well [19:56] the biggest problem has consistently been manpower [19:56] exactly [19:56] and i think i might have a solution for that. [19:56] and getting upset with the people who *do* contribute is not a way to excite people about more contributions [19:56] though it might have been thought of before [19:57] LaserJock: i agree 100% [19:57] so while it's good to talk about what we can do better, some of the tone of that thread was disappointing, IMO [19:57] I feel like I want to start a team of LTSP-specific techs, coders and administrators so we can closely collaborate on issues, bugs and questions we have so that fixes get pushed faster. But, again, the issue is manpower. [19:57] So [19:57] obviously, there are a lot of for-profit companies and budget-oriented entities (school districts, govt offices) that *can* contribute money to fixing problems. [19:58] I, for one, am a two-man company that is contracted by places like this to implement LTSP into places like schools [19:59] If there was a "pool" of sorts, almost like a NPO or something similar, smaller companies like me could "contribute" money so that programmers can work to fix these bugs full-time. [19:59] I have no doubt at all that there are plenty of companies/entities that would be willing to contribute as I am. [19:59] I'm not sure if that'd really do much [20:00] although I think it could be nice in terms of promotion, i.e. having money available for promoting Edubuntu/LTSP [20:00] Go on..if the issue is manpower, how is this not a viable solution? [20:00] because money quite often isn't the issue [20:01] it's a community, not a business [20:01] so what's the issue? [20:01] in regards to manpower [20:02] well, generally I think you need things like direction, a RoadMap, and an environment that is healthy for community collaboration, contribution, and expansion [20:03] you need to have leadership, consistency, and vision [20:04] with a relatively small, niche group like Edubuntu it can be difficult to get people [20:04] I think that Edubuntu/UbuntuLTSP has a pretty big user-base [20:05] Maybe the main problem is the current structure itself? [20:05] *How* expansion happens, *how* direction is established, etc? [20:05] well, it's a fairly large user-base, but IMO it's a bit different user-base than what Ubuntu as a whole has [20:06] I think in general Edu work is not a sexy for developer types [20:06] correct [20:06] but...developers will happily code for money when community contribution isn't desired [20:06] and said code can be given to the community in the end, anyway [20:07] the point of Ubuntu and Edubuntu is to have a community project [20:07] I see that as a repetitive issue with F/OSS in general [20:07] paid solutions, while appealing in the short term, do not help community issues [20:08] why does code contributions, whether paid or not, *not* help the community issues? [20:08] s/does/do [20:08] because it tends to stifle community contribution [20:09] it does? [20:09] i.e. "oh, you have to be a paid person to work on Edubuntu?" [20:09] or "oh, well I'm paid to implement this so you should find something else to do" [20:09] but there are plenty of people who *are* paid to contribute already [20:09] or "well, I don't have time to build community, I have to get this code working" [20:10] yes, but it only seems to work out well if you significant community components already there [20:10] I don't see how getting issues resolved and bugs fixed has anything to do with building a community - they seem to be separate functions of the overall goal [20:11] whether someone is paid or not shouldn't have anything to do with it [20:11] so fixing "we lack people" problems by paying people to do work can end up harming more than helping [20:11] ah, but they aren't separate functions [20:12] so I would say, yeah, it's cool to have people paid to work on Edubuntu [20:12] but it won't solve manpower issues in the long run [20:12] wouldn't you think that the more people contribute, regardless of their personal motivation, it will help the community grow? [20:12] nope, not exactly [20:13] paid people contribute what they're paid to contribute [20:13] and it quite hard to convince the people paying that community building is worth the money [20:13] I see it as worth it [20:13] so you might make good advances in the bug-fixing arena and have a dead community in the end [20:14] hmm [20:14] but for me the point is that we don't *need* paid people [20:14] it's great to have them around, no doubt [20:15] but I have confidence in community [20:15] but as the way it is now, there are so many unfixed bugs that the community only fixes the ones they want to fix / have time to fix [20:15] if the community contains paid elements then great [20:16] and that's fine [20:16] pain points lead to people who want to scratch itches [20:16] if people seriously don't have enough interest in fixing bugs then what's the point? [20:17] and this is where I have some issues with the list thread [20:17] I don't mind people bringing up problems [20:17] but I want people to contribute to the solutions [20:18] how do you propose they do so if they aren't a programmer? [20:18] triaging is good, testing is great [20:18] I'm not a programmer per se [20:19] many many Ubuntu developers aren't either [20:19] it's not our responsibility to fix bugs in most cases [20:19] it's about forwarding, tracking, integrating work that others do [20:20] documentation is also a key aspect [20:20] often times people can avoid bugs if told how to do so [20:21] But what happens after the bug is forwarded to say, the gnome dev team, and they sit on it because Edubuntu/LTSP specific bugs aren't a priority to them? [20:21] you poke [20:22] you make it a priority for them :-) [20:22] does that really work all the time though? [20:22] not all the time, no [20:22] but a lot more than you might think [20:23] developers most often dislike bugs in their code and are quite willing to help get things fixed [20:23] sometimes you run into a "dead" upstream where there's no development work being done [20:24] but Debian is also quite helpful [20:24] Are any coders firmly against accepting patches? [20:25] very rarely you come across people that don't want to work with software they've already released [20:25] so they'd maybe say "I'll take patches against the development version only" [20:25] but patches are like candy for most developers :-) [20:26] See, that's my point :) [20:26] I would absolutely love to pay someone, if i could alone, to submit patches for bugs that my clients experience [20:26] even if only submitting patches alone [20:27] right, but what I'm saying is you probably don't even need to pay somebody to do it [20:27] i would gladly pay someone to do that, so my clients would continue to pay ME, and have faith in open-source and LTSP/Edubuntu specifically. [20:27] if you get the community built around it [20:27] hmm [20:27] I mean, I wouldn't turn down donations ;-) [20:27] but I think in terms of Edubuntu as a whole [20:27] so is it the hierarchy of communication broken? what is it about the community that makes it so hard for "normal people" to successfully contribute and get things accomplished? [20:28] it's much healthier to have a good community [20:28] i agree with you on that..the community is the lifeblood of any F/OSS project [20:28] well, right now the problem is really at the top [20:28] or rather the lack thereof [20:28] technically speaking there are currently 0 Edubuntu developers [20:29] ogra's done a tremendous job, but his current work load is elsewhere, so any Edubuntu work is in his no-so-available free time [20:30] I'm just getting back into Edubuntu but am currently work on my PhD so don't have extensive time at the moment [20:30] I agree...I can't believe how much of a help ogra's been over the past couple of years for me, not to mention the countless others that have looked to him for help [20:30] we're the only 2 Ubuntu developers who've worked on Edubuntu really [20:30] Well here's the thing then... [20:31] so I think we need a time of reanalysis, regrouping so that we can get a plan together [20:31] we've got next to no devs for Edubuntu [20:31] (i agree) [20:31] But we have TONS of people using Edubuntu/UbuntuLTSP [20:32] So we have a bunch of admins with no dev team. there needs to be more of a balance obviously [20:32] to get things accomplished faster, bugs squished and happy admins/users [20:33] how can the admins help? That's what I am, essentially [20:33] and i know you mean triaging/reporting problems/etc [20:33] ok, well there's quite a number of things [20:33] it's just a matter of getting things going [20:33] but I *do* that...and then I sit and watch the number of unresolved bugs in my LP sub list grow [20:33] building some momentum [20:34] we could start having weekly bug squashing sessions [20:34] really promote them on the lists and Planet Ubuntu for instance [20:34] what's planet ubuntu? [20:34] http://planet.ubuntu.com [20:35] See...that's another thing..the decentralization of everything is so confusing [20:35] fridge/planet/wiki/lists/irc/etc [20:35] lol, planet is about centralization [20:35] oh [20:35] =p [20:35] gosh, you have no idea [20:35] wait until you get into packaging [20:36] stuff is *everywhere* [20:36] see, that's the problem though! [20:36] we need to fixate on the core issue there [20:36] sure [20:36] but it's a big problem to tackle [20:36] so what [20:36] we're powerful =) [20:36] and we're working on it ;-) [20:37] for instance, right now there are 3 "places" that QA services are hosted in Ubuntu [20:37] well i'd love to know what i can do to best contribute to the centralization of all of these things [20:37] the QA team is working on having a central portal for all of that [20:37] that is awesome [20:37] that's what we need [20:38] ok, so some things I can think of: [20:38] 1) Edubuntu bug days where we can all get together and squash [20:38] 2) Edubuntu Q&A sessions where people can come and ask how they can help and learn about how Edubuntu is developed [20:39] 3) A "How can I help?" doc on www.edubuntu.org [20:39] 4) get edubuntu-devel used again to discuss bugs, etc. [20:40] 5) have a clear roadmap and target [20:40] those are the things that come off the top of my head anyway [20:41] I think #5 is really what i'd like to focus on, anyway [20:41] if people know the direction of the project [20:41] than they are more likely to get involved [20:41] humans are task-oriented [20:41] Who decides what the roadmap is? :) [20:41] good question [20:42] very [20:42] those who show up? ;-) [20:42] Afternoon LaserJock! [20:42] hi Scottie [20:42] heh [20:42] the community, exactly =) [20:42] the ones that are most interested in the project, that prove so [20:43] I just get so frustrated with which is the "best" way to communicate my concerns about LTSP in Ubuntu [20:43] because there are so many ways [20:43] a large scale "this is what we want to do, this is what our targets are" would probably be a starting place [20:43] Lns: Well, you've got an LTSP developer right here, what are your concerns? :) [20:44] hehe..well i see IRC is one of the easiest ways to get in contact w/the devs ;) [20:44] Yup [20:44] LaserJock: i agree exactly with your last statement [20:44] my concerns are that i have issues and bugs that aren't being resolved quickly enough for my clients [20:44] take a gander at https://wiki.ubuntu.com/Xubuntu/Specifications/Intrepid/StrategyDocument [20:44] and it is of no blame to the community [20:44] or the devs involved [20:44] ok, which bugs? [20:44] but it is a concern to me [20:45] hmmmmm...well gnome-watchdog/lingering processes for one [20:45] but i don't want to get specific here [20:45] Why not? [20:45] one minute..sorry [20:46] Define "lingering processes". Are they processes that hang around that cause problems? Or processes that hang around, and don't bother anything? [20:46] well, for me there is still a bit confusion when it comes to LTSP and Edubuntu [20:47] when people say "bugs in Edubuntu" how often are they really saying "bugs in LTSP" [20:47] Well, LTSP's moved officially back "upstream" now, so it's just a project that edubuntu relies on. [20:47] Well, that [20:48] sbalneav: why not? because there are too many bugs for me to list to try and squish with you now :) i want to focus on the goal of better collaboration between non-devs and devs so things can flow better for everyone [20:48] rihgt [20:48] and Ubuntu LTSP stuff is what i mainly want to focus on, personally [20:49] Lns: Let me inject a little reality into your high idealism. [20:49] and for me I honestly don't care about LTSP [20:49] :-) [20:49] well, other than LTSP has the coolest devs in the entire world [20:49] All the LTSP developers are full time employed doing other things besides LTSP [20:50] we work on it when we can, however we can. [20:50] There is no "full time dedicated ltsp developer". [20:50] So... [20:50] well, that's another issue I was going to bring up [20:50] it's hard to employee people who are already employed full-time elsewhere [20:51] sbalneav: i agree with you [20:51] We've got a bugs area right now, and there's an LTSP developer here right now, so if you've got some hot button issues, why not lay it on me NOW, and I'll see if there's anything I can help you with. [20:51] sbalneav: see though, hot-button issues aren't my big issue :) [20:52] i want to make it so hot-button issues are dealt with in the best way possible for *everyone* [20:52] and i know that isn't easy to hear [20:52] right, which means fixing the ones we can when we can when they come up :-) [20:52] but i want to help turn the big gear [20:53] I think ltsp could use a good triage session [20:53] i would love to be involved in that [20:53] it's got 56 open bugs [20:53] which is 1/3 of the open edubuntu bugs [20:53] Ok, you turn the big gear. And when the big gear's turning, pop into either here or #ltsp, and let us know what the issues are. [20:54] sbalneav: is there a convenient day for you in the week? [20:54] or are they all mostly the same [20:54] Probably in a week or two I could stay home and do a bug squashing day. P [20:55] ok, sounds good [20:55] A lot of the bugs assigned to LTSP aren't LTSP bugs per se, but problems with X detection, etc. that are out of our hands. Others have been fixed with the latest ltsp developer conf. [20:55] sbalneav: once you know when that is can you send an email to edubuntu-{devel,users} saying you're gonna have an LTSP bug squashing day? [20:56] Unfortunately, because I didn't get a chance to do any work for 6 months or so, Launchpad kicked me out of edubuntu-bugs. [20:56] right, that's why I think a good day of triage is needed [20:56] So I'll need to get back on that. [20:56] I sure can. [20:56] awesome, thanks [20:57] sbalneav: if you want to know my bugs... they are (and they are not all LTSP specific, but rather semi-large-scale ubuntu deployment specific) LP #s 19033 206583 37253 150068 154685 239342 259163 [20:57] LaserJock: can you add me back into edubuntu-bugs, or is that something ogra has to do? [20:57] sbalneav: ogra for now, since I'm not in yet either ;-) [20:57] ?? [20:58] ogra: sbalneav and I aren't in ~edubuntu-bugs currently [20:58] ogra: hey, I think I got booted from the edubuntu-bugs team. Add me back in? [20:58] i wonder why i didnt get a notification [20:58] LaserJock, re-added [20:59] ogra: danke [20:59] Thankee ogra [20:59] sbalneav, too [20:59] any of you wanna be an admin ? [20:59] I can do it [21:00] it's always good to have more than one :-) [21:00] done [21:00] yeah [21:00] gracias [21:00] especially if the main admin doesnt get mail notifications :( [21:00] yeah [21:02] sbalneav: you think 2 weeks before an ltsp bug day? [21:03] I could run a non-ltsp bug day either before or after [21:03] Would it make sense to have a "group" of real-world UbuntuLTSP/Edubuntu administrators to prioritize certain issues, bugs and feature requests that are common amongst all of them, to more formally present to devs? [21:04] If the admins can, "offline", gather information like this, maybe it would help in the process of bug squashing when the devs know how important certain ones are [21:04] LaserJock, that would make a lot of sense, i'll pull in the last upstream wed. night [21:04] last minute before FF :) [21:04] heh [21:04] as usual [21:04] I've got a last minute I'm trying to do [21:05] * ogra has a million last minute things for ubuntu-mobile so that somewhat hogs me [21:05] plus i took the taks to get touchscreens proper into hal-input [21:05] Lns: well, initially I think we need to take stock of what we have, get them triaged [21:05] so they work at least basically in intrepid [21:06] Lns: certainly opening some discussion on the mailing list would be useful [21:06] LaserJock: ok...but who's going to determine which ones are the most important? [21:06] I'm thinking more along the lines of a "formal" group of administrators [21:06] well, tbh, that's usually not much of an issue [21:06] the mailing list seems to be a mix of admins, users and devs [21:07] people generally work on what they can when they can and it's usually fairly easy to determine what needs prioritization [21:07] Lns: do you feel there's a lack of priority? [21:07] LaserJock: I do, in some cases [21:07] for instance [21:07] at this point I'm shooting for "can we get a CD that installs" :-) [21:09] LP 19033 has been an issue for a while now...and that's a huge priority to me and other admins who wish to deploy centralized firefox configs [21:09] Lns: just FYI, the bugs you provided me with, as far as I can see, none of them are LTSP related, with the possible exception of the fast user switcher [21:09] Launchpad bug 19033 in firefox "systemwide default startup homepage ignored" [Medium,Confirmed] https://launchpad.net/bugs/19033 [21:09] sbalneav: i know..i think my motivation is in larger scope than ltsp-specific issues [21:09] and maybe i'm barking up the wrong tree, but you guys are the ones i communicate mostly with about this kind of stuff [21:10] nah, I think it's appropriate really [21:10] but we need to work on getting people pointed in the right direction [21:10] since i'm using Ubuntu and LTSP as my setup, i come to you guys whne i have problems :) [21:10] ok, well see here's part of my LTPS/Edubuntu issue [21:11] I wonder if it'd make sense to have a LTSP subteam or something [21:11] rather than Edubuntu == LTSP [21:11] The problem is, what's edubuntu except: some artwork, a bunch of package install defaults (edu + ltsp). [21:12] because there are aspects of LTSP being on the Ubuntu disk than should probably be run through Ubuntu or Ubuntu Server channels [21:12] qcad developers don't hang here, nor do kdeedu [21:12] the only people who DO hang here are ltsp people. [21:12] right [21:12] there are a few upstreams that do [21:12] simply because LTSP is the most complicated thing to set up. [21:12] gcompris for instance [21:12] right, so I don't think we (as Edubuntu) should ditch LTSP [21:13] but perhaps it makes sense to sub-team it in some way [21:13] My main issues generally revolve around multi-user Ubuntu installations residing on a single server - not necessarily the LTSP part, but everything that encompasses having many users on a single server. [21:13] so that we can let LTSP issues be focused on, and not entirely by Edubuntu, which doesn't have a lot of resources [21:14] LaserJock: Well, I think the simplest way to do that, now that LTSP is officially "upstream" again, is to just forward people onto #ltsp. [21:14] hmm, yes, that is a good point [21:14] since ogra, myself (getting back to it) both hang out here and #ltsp, it should be good. [21:15] it's more moving LTSP from Edubuntu to upstream than from Edubuntu to Ubuntu in reality [21:15] Probably the SIMPLEST thing would be for you to ALSO hang out on #ltsp, then you could guide people over, and drop them off to our tender ministrations :) [21:15] pfft [21:15] lol [21:15] you're just trying to turn me to the dark side [21:15] heh [21:15] "do as we do, say what we say" [21:16] Exactly [21:16] well, I do have the LTSP figure [21:16] ;-) [21:16] lol [21:16] "Welcome to #ltsp, where the only thing thin are the clients" [21:16] * Lns falls over [21:17] I think that makes the most sense, since #ltsp can help edubuntu people effectively with LTSP issues. [21:17] so i have a (maybe dumb) question that might or might not be related [21:17] Then that gets the ltsp out of this channel, and over to the one where they'll have the best chance of getting help. [21:17] hmm..well maybe not a question [21:17] for LTSP stuff anyway. [21:17] sbalneav: so a good bug triage session would be good to figure out what's LTSP specific and to forward on to LTSP where needed? [21:18] Well, LTSP uses launchpad for it's tracking anyway, so that's not a problem. [21:18] oh, right, cool [21:18] easy then [21:18] I WAS looking at bugs, but the last 6 months my life fell apart, so I got out of triaging bugs. [21:18] yeah [21:19] for example - i have issues with gnome-system-monitor and killing other users' processes. This is definitely in relation to LTSP since it's an LTSP multi-user setup..but it almost seems as though the core ubuntu dev team is ditching focus on multi-user setups, for favour of the best single-user experience. [21:19] I'll sit down tonight and wander through the LTSP bugs, and see which ones aren't an ussue anymore. [21:19] Lns: I don't know that it's quite that distinct [21:19] Lns: Does it work on the console, but not on an LTSP terminal? [21:20] sbalneav: it works with sudo, but not with someone as part of the 'admin' group from a terminal [21:20] Lns: often times it comes down to developers being able to reproduce/test and getting their attention in the first place [21:20] (both from terminal) [21:20] LaserJock: yeah - exactly [21:20] LP 206583 [21:20] Launchpad bug 206583 in ubuntu "System Monitor crashes when lowering nice value of process" [Medium,Fix released] https://launchpad.net/bugs/206583 [21:20] fix released?! =) [21:20] that's new [21:21] Lns: for the first part getting Edubuntu people involved with testing is a win, and for the second, getting bug filled out right and against the right packages is key [21:22] LaserJock: see that's where i see a semi-formal/formal group of admins who have someone that *knows* the right packages can help filter out all the individual chatter/bug dupes/etc [21:22] Lns: correct, this is where ~edubuntu-bugs comes in [21:22] we need to get admins signed up and trained :-) [21:23] but see, for those who don't technically use edubuntu, they might not look there... [21:23] i know this is way beyond the scope of what you guys can help with [21:23] so i hope you don't mind me brainstorming with you [21:23] no problem at all [21:23] =) [21:23] and there are things that can probably be done [21:23] one central issue is the whole Ubuntu Education/ Edubuntu thing [21:24] For me, I would love to be a cornerstone, almost a point of contact for a group of admins that deal with Edubuntu, LTSP, Ubuntu, multi-user servers, and everything in between [21:24] a lot of people use Ubuntu + LTSP and not Edubuntu at all [21:24] because it bleeds into every other aspect of ubuntu [21:24] exactly - like me [21:24] but all our team structure is still Edubuntu [21:24] but again, i come here when it's ubuntu/ltsp specific (and #ltsp) [21:24] mailing lists, LP teams, etc. [21:24] Lns: See, thats NOT really a problem with LTSP. And I know I'm beating this horse into hamburger but you/I/we REALLY need to make sure we distinguish between "An LTSP bug" vs "I've run into a bug, and I'm running an LTSP environment". This one looks like a Gnome bug, that only manisfests itself when you're outside a single user environment [21:25] sbalneav: I think that's key [21:25] sbalneav: exactly. [21:25] what we need is a LTSPers guide to filing bugs [21:25] that's the thing though, most administrators (i'm learning as much as i can) but MOST admins don't even know HOW to file a bug [21:25] to help point them towards when to file against LTSP and when not to [21:26] LaserJock: i don't know if that would help...i think we need a filtering system so that the people who know how to file bugs can, on behalf of others [21:26] it becomes too technical for a lot of people [21:26] as silly as that might sound [21:26] well, it can be done fairly well :-) [21:27] a combination of good bug filing documentation and ~edubuntu-bugs would probably help dramatically [21:27] i dunno...the techs i work with don't even really understand how ltsp works, let alone finding a package name that pertains to their bug [21:28] well, it's not too bad in a lot of ways [21:28] Lns: And did they read the Edubuntu handbook? [21:28] laserjock, no, i agree [21:28] sbalneav: nope..and most of them won't understand it if they did [21:28] in the QA team we've put a lot of emphasis on Launchpad developers to make it easier to find what package to file bugs against [21:29] in the future we'll have search algorithms and per-package bug filing instructions to help [21:29] Lns: So, how do you propose to fix that probmlem? [21:29] I love how LP has improved, and I agree that it is very easy to file bugs [21:29] but when you come against the mass of admins out there, filing hundreds of duplicate bugs because they don't want to search through the possible list of dupes...it becomes an issue [21:29] but for right now I think we can help people say "this looks like an LTSP bug" or "this is not an LTSP bug" [21:30] sbalneav: well one thing i can think of is forming a group of administrators with a hierarchy of their own [21:30] things like "can you reproduce this bug on a system that doesn't have LTSP installed?" [21:30] so things can get handled in the best way possible [21:31] LaserJock: and a lot of people can't even test that if they don't have a non-ltsp system available [21:31] Lns: At your site, or here in #edubuntu? [21:31] dpkg -l | grep ltsp will probably suffice [21:31] sbalneav: i'm thinking in relation to edubuntu/ubuntu/ltsp, but at my site / a separate portal/entity/whatever [21:31] the other aspect of all this, is we're not exactly drowning in bugs [21:32] LaserJock: not yet ;) [21:32] but if you make it easy enough to file bugs [21:32] just think of if microsoft has such an easy bug filing system [21:32] we make it easier to file *better* bugs [21:32] that would be a nightmare [21:33] that's where the emphasis should be, yes [21:33] imho [21:33] but [21:33] still - when the userbase grows, the weeds will start to crop up none the less [21:33] that's why community is important [21:34] by that time we'll have a good triaging team to look after weeds [21:34] yes...the structure. [21:34] so, to start off I think we need as close-knit of a team as we can [21:34] i think i might start looking into how to form a group of multi-user Ubuntu administrators [21:35] Lns: I think the Server Team may have some interest as well in that regard [21:35] server team? [21:35] canonical support server team? [21:35] no [21:36] the Ubuntu Server Team, the people who make the Ubuntu Server distro [21:36] oh ok [21:36] * Lns wouldn't have initially thought to look there either since he installs ubuntu-desktop on his ltsp servers ;) [21:36] granted [21:36] LTSP is in an odd position there [21:36] but server people are often interested in multi-user environments [21:37] seems like a valuable resource to look into none the less [21:37] well thank you guys for the long chat [21:38] in some ways I'm feeling like we need to start from scratch [21:38] it's helped me understand the whole structure a bit better [21:38] start what from scratch? [21:38] figuring out what we want Edubuntu to be, what our targets are [21:38] "Edubuntu" [21:38] not in terms of getting rid of everything we have [21:38] but in terms of re-evaluation of where we want to head [21:39] I really like what Xubuntu did with https://wiki.ubuntu.com/Xubuntu/Specifications/Intrepid/StrategyDocument [21:39] though it's rather long ;-) [21:39] My main push into edubuntu was the LTSP part of it [21:40] wow [21:40] yeah that looks nice [21:40] that would then give us a much better basis for decision making and make Edubuntu maybe more focused [21:41] as well as give something people can say "oh cool, I want to be a part of that!" [21:42] I think all limbs of Ubuntu should have that kind of structure [21:47] Lns: you subscribed to edubuntu-devel? [21:47] no - actually just edubuntu-user at the moment [21:47] and ltsp-discus [21:47] s [21:48] ok [21:48] I'd like to see this kind of discussion moving to edubuntu-devel [21:49] ok, i'll sub to it [21:49] I think one difficult aspect of Edubuntu is that Ubuntu is heavily IRC-dependent whereas I think many Edubuntu users are more email-focused [21:50] well i've seen that many educational-sector people are definitely e-mail driven [21:51] no matter what the project [21:51] the fact that many educational institutions block IRC ports doesn't help ;-) [21:51] hehe..very true. [21:52] not many edu techs/teachers/admins have a lot of time to spend in front of their *own* screen, either [21:52] mhm [21:53] so having a good mailing list is, IMO, fairly critical to getting the developer <-> user communication going better [22:19] LaserJock: i agree...and facilities that might be able to port information/communications to/from the mailing list, as well...as, of course, everyone likes to do things a bit differently ;)