#ubuntu-meeting 2005-07-01 <ubuntu_demon> hi * terrex dice: ahora s que s, me ausento. taluego #ubuntu-meeting 2005-07-02 * ..[topic/#ubuntu-meeting:Seveas] : Logs - http://people.ubuntu.com/~fabbione/irclogs || Tue 28 June 20:00 UTC: Tech Board -- https://wiki.ubuntu.com/TechnicalBoardAgenda || Thu 30 June 14:00 UTC Documentation Team -- https://wiki.ubuntu.com/DocteamMeetingAgenda || Tue 5 July 22:00 UTC Community Council -- http://wiki.ubuntu.com/CommunityCouncilAgenda || http://wiki.ubuntu.com/Calendar || This is NOT #ubuntu, or #ubuntu-devel || UTC time --> `date --utc` <terrex> Is there any wikipage or anywhere see the agenda of the month for all teams? <terrex> It's really nice to make an integration with evolution and make a "shared agenda" server, dont you think? * ..[topic/#ubuntu-meeting:Seveas] : Calendar -- https://wiki.ubuntu.com/Calendar || Logs -- http://people.ubuntu.com/~fabbione/irclogs || Tue 28 June 20:00 UTC: Tech Board -- https://wiki.ubuntu.com/TechnicalBoardAgenda || Thu 30 June 14:00 UTC Documentation Team -- https://wiki.ubuntu.com/DocteamMeetingAgenda || Tue 5 July 22:00 UTC Community Council -- http://wiki.ubuntu.com/CommunityCouncilAgenda || http://wiki.ubuntu.com/Calendar || This is NOT #ubuntu, or #ubuntu-devel || UTC #ubuntu-meeting 2005-07-03 * ..[topic/#ubuntu-meeting:pitti] : Calendar -- https://wiki.ubuntu.com/Calendar || Logs -- http://people.ubuntu.com/~fabbione/irclogs || Tue 28 June 17:00 UTC: Tech Board -- https://wiki.ubuntu.com/TechnicalBoardAgenda || Thu 30 June 14:00 UTC Documentation Team -- https://wiki.ubuntu.com/DocteamMeetingAgenda || Tue 5 July 22:00 UTC Community Council -- http://wiki.ubuntu.com/CommunityCouncilAgenda || http://wiki.ubuntu.com/Calendar || This is NOT #ubuntu, or #ubuntu-devel || UTC <pitti> @all: Today's TB meeting needs to start earlier, at 1700 UTC <jbailey> Err, that's awfully short notice for a change, isn't it? * jbailey can't make that time. <jbailey> Oh good, agenda doesn't concern me really anyway. <seb128> hey dholbach :) <dholbach> hey :) <\sh> huhu daniel :) <ogra> hoho dholbach <ivoks> howdy <ogra> dholbach, i added a mention of revu to the expanding universe goal, but didnt change the status <mdz> 2 minutes <ogra> dholbach, to make th eprogress visible * pitti waves to everybody and gets a seat * ogra puts a pot coffee on the table <dholbach> ogra: excellent <mdz> good morning, everyone <mdz> waiting for sabdfl and Keybuk * ogra quickly uploads a fixed ffmpeg before the meeting <ogra> :) <\sh> ogra: u made it? ,-) <Keybuk> (I'm almost entirely not present, but will respond if my name goes blue ;p) <ogra> \sh, with a lot of help from mvo (you should call him the AssemblerKing now) <\sh> ogra: good to know *eg* <mdz> ok, that's quorum at least :-) <dholbach> ogra: mvo rocks <ogra> yeh <mdz> we seem to have one MaintainerCandidate to process <ogra> +a <mdz> Ankur Kotwal? <ogra> DanielN ? <\sh> Unfrgiven: <ogra> huh ? <ogra> a <ogra> ah <\sh> Ankur is Unfrgiven <mdz> he's applying for MOTU <\sh> and DanielN_atw is not online <ogra> yep... i always muddle Ankur and Ante :) <sabdfl> hi all <ivoks> i'm Ante :) <ogra> hey sabdfl <dholbach> hi mark <\sh> for Unfrgiven I can give a ++ for MOTU...he did a lot for cxx and stuff <ogra> ivoks, i know.... but ivoks is more familiar ;) <ogra> absolutely <ogra> \sh++ <sabdfl> mdz: you under way? <mdz> sabdfl: yes <mdz> sabdfl: currently Unfrgiven (https://wiki.ubuntu.com/AnkurKotwal) is being considered for MOTU maintainership <\sh> and for DanielN_atw , he made some progress in those 2 weeks after the last meeting and I think he would be a good candidate. Ogra, what do u think? <mdz> ogra and \sh both support his admission <dholbach> i worked with him on a package, but that's some weeks ago, he did it well <ivoks> ++ by me too <dholbach> i read his name a cuople of times on the c++ library list <ogra> sabdfl, we also met hi at udu, he made good progress with packaging since then <ogra> him even <dholbach> that's true, ogra <sabdfl> ok, fine by me if ogra and \sh have worked with him and think he's up to it <ogra> absolutely :) <mdz> likewise <Keybuk> same for me <dholbach> excellent :) <ogra> yay :) <ivoks> great <\sh> heissa :) <dholbach> watch the MOTU team grow :) <sabdfl> welcome aboard Unfrgiven! <mdz> Unfrgiven: congratulations and welcome <\sh> he's going mad when he's hearing that :) <ogra> so welcome Unfrgiven (in sleeping absence ) <mdz> next up, Riddell on choosing an office suite for Kubuntu <sabdfl> Riddell: is there a wiki page that outlines the options and arguments? <Riddell> sabdfl: no there isn't <sabdfl> this sort of thing is best done in spec format, as a proposal <Riddell> trouble is I don't yet have an answer to propose :) <Riddell> koffice is faster and smaller and integrated <sabdfl> because whichever way it goes, in future people will want to know what was factored into the decision <mdz> the guiding principle should be to do whatever the KDE community will love <pitti> Riddell: what about stability? <sabdfl> mdz: agreed <\sh> Riddell: what about the compatiblity to ms office? <ogra> mdz, whyt about MS compatibility ? <Riddell> openoffice is probably less buggy and more compatible with MS Officce <pitti> Riddell: OO.o is a pain both stability- and performance-wise, is KOffice any better? <\sh> ogra: *g* <ogra> heh <sabdfl> in addition, since openoffice is in main, we should also make sure that k-oo.o love is around and available, even if it isn't the default <Riddell> pitti: it's a lot better performance wise, not so stability wise <mdz> ogra: see above; if MS compatibility is of great importance to the KDE community, they will factor that into their opinions <Mithrandir> sabdfl: k-oo.o love is utterly painful for amd64. <sabdfl> Riddell: we had a similar debate around abiword + gnumeric vs oo.o <\sh> mdz: i don't think it has to do with KDE alone...it's a matter of integration of * Linux into the office structure of companies <sabdfl> Mithrandir: is that true for the goo.o too.o? <Riddell> sabdfl: where can I find out about the discussions of that? <Mithrandir> sabdfl: less so, but yes. <Mithrandir> sabdfl: that is, more packages => more pain. <mdz> \sh: to a certain extent, such companies will make their own decisions about which software to use <ogra> mdz, true.... but still non KDE people will switch too :) <sabdfl> Riddell: poorly documented i'm afraid, we mostly had it on irc in the SSDS days <mdz> the default should be the "right thing" for a KDE-oriented distribution <\sh> mdz: and most of the companies using OOo as a choice <mdz> what do other KDE distributions do? <Mithrandir> sabdfl: I'm throwing in a data point, I'm not trying to veto (which I wouldn't be able to) k-oo.o. <\sh> they put both <Riddell> mdz: the only distribution to ship with koffice is mepislight <ivoks> oo.o seems more mature atm, but koffice is doing great improvment, imho <Riddell> ship as default that is <sabdfl> Mithrandir: your say counts for a lot around here, so don't be shy <Riddell> one agrument is that if nobody uses koffice then it will never improve <Mithrandir> sabdfl: the pain will be significantly less with ooo2 once we get it usable in a 64 bit form. <sabdfl> Riddell: similarly for Gnome office and KOffice, though <mdz> the 32-bit stuff for oo.o2-kde will be painful, yes,, but we'll need to do it regardless of which office suite is default in kubuntu <\sh> Riddell: what about shipping with koffice and OO? <Riddell> \sh: no space for that <sabdfl> and with java and sun, there's a feeling that it would be good to have strong ground-up-free office suits <mdz> how big is koffice? <ogra> \sh, no redundancys ! <Riddell> although we will probably ship with kexi (database) and krita (drawing) <Mithrandir> mdz: but we won't have to package half of kde in ia32-libs-kde if we don't use ooo for kubuntu. <sabdfl> mdz: is oo.o2 64-bit K difficult because of the C++ nature of K? <Riddell> mdz: source is 20MB <mdz> sabdfl: it's difficult because KDE has a huge dependency chain which would need to be repackaged a la ia32-libs <ivoks> 20? * \sh likes the idea to ship koffice with a real kde distro ;) <mdz> Mithrandir: even if kubuntu uses koffice by default, we should have oo.o2-kde available on all supported architectures <Mithrandir> sabdfl: ooo2 64 bit is difficult because the programmers writing staroffice thought that having assembly in a office suite made sense. <Mithrandir> mdz: do I get an extra bottle of whisky a month to endure the pain? ;-) <\sh> Mithrandir: no whisky while you're working ;-) <Riddell> koffice .debs are 21MB <Mithrandir> \sh: you haven't done ia32-libs, I see. :-) <uniq> the (few) comments on koffice vs. oo.o on kubuntu-users@list are all more or less pro oo.o. <pitti> \sh: you need the alcohol to double the 32 bit <\sh> Mithrandir: nope...but other nasty stuff;) <mdz> Riddell: what is your gut feeling? <\sh> pitti: yeah...this I know perfectly ;) <Mithrandir> anyhow, ooo is k-able on amd64 just fine, it's just painful. <dholbach> stabitily and exchangebility maybe should be the keypoint, imho - since people judge a distribution by what they use and what (and probably what not) works for them --- i say that without being a fan of oo.o and its not-integrated-ness, and i agree with riddell on getting users for improving, new products <Riddell> mdz: I've been trying to use koffice as much as possible this last week since 1.4 release. for lugradio live kpresenter couldn't open it's own slides and I had to re-do my whole talk. that put me towards keeping openoffice <pitti> Riddell: is "not so stable" == "it crashes every half an hour"? or is it better? <\sh> Riddell: do u think the userbase will increase for koffice, if kubuntu is shipping it as default? <pitti> Riddell: I'd judge stability over performance <Riddell> pitti: "it crashes every half an hour" isn't too far off I suspect <pitti> Riddell: then you will rather scare away people with it, I'm afraid <Riddell> \sh: yes I do <\sh> Riddell: so, ship it...we have OO in anyway available <mdz> Riddell: so if you're leaning toward openoffice, and kubuntu-users seems to be leaning the same way, is there someone who can speak for koffice? <pitti> Riddell: ... not that OO.o wouldn't be scary on any but the latest and greatest number crunching hardware <Riddell> \sh seems to speak for koffice <Riddell> amu is a big koffice fan <ogra> \sh, whats the use of an ofiice suit that crashes every 1/2h, have fun with the bugreports you cant solve in a stable distro ? <Mithrandir> I was a fan of koffice five years ago, but it sounds like it might not have moved too much since then? <\sh> ogra: well, thinking of ms word which is crashing for me every single time I try to open a big document I don't have anything against a crashing presenter <dholbach> it's the same for gnome: abiword and gnumeric, but without a presenting software, you can't hand gnome-office to the average user yet, that's disappointing, but that seems to be life atm :-/ <ivoks> we can't ship crashing app. <pitti> \sh: that isn't the thing we should compare software to <\sh> lets say it like this: if kubuntu is shipping as default with koffice, we can also try to stablelize it <sabdfl> Mithrandir: if we were to put a google-size bounty on proper oo.o2 64-bit support, is there anyone you can think of in the upstream crowd who could take it on? <ogra> \sh, we'll talk about it after you lost your first ubuntu slides 1/2h before the telk ;) <sabdfl> upstream being oo.o community <ogra> talk <pitti> dholbach: gnumeric is a great piece of software, it jsut works and is fast (as opposed to OO.o spread, which is buggy and slow as hell) <Mithrandir> sabdfl: I don't know upstream, so no, but I could look around. <\sh> pitti: we have OO in the repos...so the user is able to install OO in an way <pitti> dholbach: it's abiword that sucks, though <dholbach> pitti: anyway, gnome-office just isnt ready yet :-/ <pitti> \sh: right, but only one will be shipped on the CD <pitti> dholbach: agreed <ogra> pitti, its the missing presentation program that sucks imho <pitti> \sh: the point is, many users can't download big debs, they depend on a CD <uniq> \sh: koffice is smaller to download. <ivoks> then with koffice, you could put more apps on CD? <ivoks> that would be + for koffice <seb128> pitti: what's wrong about abiword? <mdz> Riddell: I think the best thing to do is to collect points in favor of each suite and document them on a wiki page <mdz> Riddell: once that's done, the answer could well be obvious <\sh> well, from my point of view, I would like to see KDE applications on a kde distro and vice versa. <Mithrandir> sabdfl: Pavel Janik is doing some work on it already. alexanderlisa@example.com <pitti> seb128: it lacks too much important features, and the MS compatibility is much worse than OO.O's <Riddell> mdz: sounds like a plan <seb128> pitti: bah, not the place to argue about that :) <sabdfl> Mithrandir: is he upstream? distro? good credentials? <pitti> seb128: however, I only use gnumeric, and I never ever use a WYSIWYG word processor, so don't count on my opinion about abiword too much <seb128> pitti: happy about gnumeric? :) <pitti> seb128: gnumeric rocks <seb128> yeah ;) <sabdfl> ok, i think this needs to be specced <sabdfl> Riddell: could you put a spec together? <sabdfl> Oo.O2 vs KOffice - the default in Kubuntu <Riddell> sabdfl: I'm not sure what that would be. isn't a spec more "we will do this" rather than "which should we do"? <mdz> right, the comparison chart we discussed would form the meat of a spec <sabdfl> Riddell: it starts with "these are the options" <mdz> just add some background to it <pitti> Riddell: after that discussion, do you think KOffice is still an option to consider? <sabdfl> then when there's a decision, you put that at the top <sabdfl> so afterwards it reads: <sabdfl> "this spec documents our decision to run with OO.o2 for Kubuntu Breezy" <sabdfl> "rationale" <sabdfl> blah blah blah <pitti> Riddell: (I don't want to imply a "no" in any way) <sabdfl> </subliminal advertising> <mdz> Riddell: invite the kubuntu community to add their own thoughts to the list, within guidelines (keep it objective) <sabdfl> yes, the doc is open so people with an interest in either course of action can add pro's and con's <Keybuk> ( <mdz> if it's still unclear at that point, we'll discuss it again with this additional context <Keybuk> sorry, desktop crapped out and decided that it didn't want to be on there <sabdfl> then it's easier to bring it to the TB and take an up or down vote amongst the kubuntu leaders and tb <Mithrandir> sabdfl: I think he's upstream, yes. His blog has 271 entries on ooo and he's been doing amd64 porting for a bit of fair time. I don't know him personally so I can't comment on his saneness, but it seems to be ok. <sabdfl> cool <Riddell> pitti: I think it's an option, see jdub's speach on how gnome office can overtake openoffice. same for koffice <sabdfl> Riddell: there are definitely arguments in favour of lightweight native tools <pitti> Riddell: ok, great. well, spec and argument collection sounds really sane then IMHO? <sabdfl> but we do have to make a decision on the default <sabdfl> even if both end up in main, as we did with gnome office <sabdfl> anything more on Kubuntu Office? <Riddell> I'll write the spec then <Mithrandir> sabdfl: he's a Novell employee, fwiw. <sabdfl> Mithrandir: could be interesting :-) <mdz> ok, next up, pitti on language packs <Mithrandir> sabdfl: well, I guess they're interested in a 64 bit OOo this year too.. <sabdfl> Riddell: you don't have to write it any further than needed to justify your own viewpoint, get someone else to argue the other side :-) <pitti> I wrote about the problem yesterday <pitti> so far I still think that the solution proposed in the udu spec (split up packs into -main/-gnome/-kde) is the way to go <pitti> however, I'd like to collect more opinions about that <pitti> the actual source of problem is that Kubuntu is not a proper derivative <seb128> 3) from the mail seems to be best option imho <pitti> with its own archive and so on <sabdfl> " Besides language-support-lang, Kubuntu additionally installs kde-i18n-lang. " <sabdfl> pitti: how do you propose to do that? <pitti> sabdfl: that is to avoid splitting the -support packages, too <pitti> sabdfl: it's already done <sabdfl> if someone wants to add a new language to the system, how does the system know to install the -kde or the -gnome pack? <pitti> sabdfl: the Kubuntu installer just does it and our language selector application can do it, too <sabdfl> pitti: how does it know if the user has, for example, installed Kubuntu and added abiword? <ivoks> khm... <pitti> sabdfl: the crude solution would be that langpack-o-matic just checks whether gnome and/or kde is installed <sabdfl> pitti: see above - "gnome" and "kde" become fuzzy concepts over time <sabdfl> it's easy at install time <sabdfl> hard once the sysadmin starts adding and removing packages <pitti> sabdfl: the fine-grained one is to check which packages are installed, so that the relevant pack could be installed if needed <pitti> sabdfl: so if language selector sees "ah, abiword is installed", it would pull in the gnome one <pitti> sabdfl: it's not an optimal solution, I'M aware of that <pitti> sabdfl: it also makes elmo cry because it will add 400 packages <pitti> sabdfl: but I don't know a better solution <Mithrandir> this sounds like a good use case for Enhances: support, btw. <pitti> if anybody does have a better solution, speak up :-) <Mithrandir> pitti: implement support for Enhances in dpkg and apt. :-) <pitti> Mithrandir: how does that help to not split langpacks? <mdz> pitti: the root problem is what? a combined language pack is too large? <pitti> mdz: yes, we can't fit them all onto the CDs <mdz> we already can't fit them all onto the CD <mdz> how many would we lose? <pitti> mdz: KDE translations alone are bigger than main+gnome right now <mdz> so we would lose more than half? <Mithrandir> pitti: it helps the packaging system note that "oh, you have this installed, then you probably want this too". <pitti> mdz: we ship all on most CDs <pitti> Mithrandir: ugh, that would be pretty intrusive; I think mvo and I had a better solution for the langpack selector at least <mdz> pitti: we ship all on 2 out of 6 CDs ;-) <pitti> oh? <pitti> hm <pitti> yes, we would loose more than half of the translations <dholbach> "order your ubuntu cd-case today." <mdz> but one of those two is the i386 install CD, which accounts for a disproportionate number of uses <\sh> is a dvd not cheaper then? <Mithrandir> dholbach: s/case/backpack/. :-) <pitti> well, DVDs would solve the problem at instant :-) <mdz> \sh: DVDs are more expensive than CDs <mdz> and less portable <ivoks> is it possible to do CDs by area? east europe, midle east, etc? <sabdfl> \sh: we still have to focus on 650MB CD's, unfortunately <pitti> or make Kubuntu a proper derivative with its own archive <ogra> \sh, not everybody has a DVD reader <mdz> ivoks: it is possible to create them, but it is impractical to test them <mdz> ivoks: we already must test 8 images for each release candidate <pitti> mdz: if langpack-o-matic could create different langpacks for Kubuntu than for Ubuntu, that would rock, but with the current structure it can't <\sh> ogra: yes :) i forgot the *grmpf* ;) <mdz> er, 9 <ivoks> oh, then this would be too much <ivoks> didn't think of that :) <mdz> pitti: what's the least intrusive way to split the langpacks? <pitti> one alternative would be to split it to l-p-ubuntu and l-p-kubuntu <pitti> and copy the common stuff into both <pitti> but that's ugly IMHO <sabdfl> pitti: i'm happy with your first proposal <mdz> unified language packs, while inefficient in terms of space, are awfully attractive due to their simplicity <sabdfl> it just means the language selector needs to be smart <pitti> mdz: right <pitti> sabdfl: so we don't support KDE translations in Rosetta? <sabdfl> mdz: you mean install all the gnome translations on a fresh kubuntu box? <mdz> sabdfl: I mean the approach we're already using <pitti> sabdfl: would be the easiest solution, but redundant and non-symmetrical <sabdfl> pitti: what's non-symmetrical about -base, -gnome and -kde? <pitti> mdz: what do you mean by "way to split"? <pitti> sabdfl: oh, I thought you meant (1) in my mail <mdz> pitti: I can't find your email; what was the subject? <pitti> sabdfl: (1) in mail was the status quo <mdz> ah, found it <sabdfl> no, LanguagePackRoadmap <pitti> "27.06.05 18:43 Martin Pitt Preparing tomorrow's language pack TB topic" <pitti> sabdfl: ah, ok, so that would be the split <sabdfl> it has its warts, but i can't see a better one <mdz> pitti: is there any significant advantage of (3) over (1) for breezy? <Riddell> mdz: it means kubuntu has translations on CD <mdz> Riddell: gnome translations, you mean? <pitti> mdz: Rosetta support mainly <pitti> mdz: and Kubuntu does not need to ship gnome translations and instead has room for kde ones <Riddell> mdz: 3 means we have translations, 1 means we don't have KDE translations <pitti> well, there is no golden solution anyway, we just have to choose the pain <mdz> pitti: why does (1) make rosetta support impossible? <Riddell> mdz: nowhere for rosetta to output to <pitti> mdz: not impossible, but we had to regenerate kde-i18n-foo, which consists of more than translations <mdz> oh, I see, it uses kde-i18n-foo rather than language-pack-kde <pitti> mdz: it would be possible, I guess, with some hacking <mdz> (3) seems the clear winner, to me <pitti> would it be possible to give Kubuntu it's own archive? <mdz> not for breezy <pitti> or would that make sense? <pitti> no, not for breezy, but in the long run <pitti> I think we could live with option (1) for breezy <pitti> if we have a solution in sight for breezy+n <mdz> we should take advantage of rosetta for kubuntu * Riddell doesn't like (1) at all <pitti> understandable <pitti> mdz: I think the biggest con of (3) is the hoary->breezy upgrade <mdz> I don't see that as a major issue <mdz> when the language pack is upgraded, we'll drop an update-notifier hook to prompt the user to reconfirm their language settings <pitti> well, upgrade notes, just as for Hoary (when users lost all their translations as well) <pitti> that sounds good <mdz> any further unresolved issues regarding language packs? <pitti> Ineed to convince elmo to accept 400 new packages :-) <pitti> anybody has serious issues with (3)? <mdz> elmo: would you like to weigh in on this? <ogra> pitti, give them to doko, then elmo wont even recognize ;) <pitti> ok, thanks guys for your input <mdz> ok, you can follow up with elmo later if he takes issue with it <pitti> ok, I'll do <mdz> next up, REVU with no person associated with it <mdz> ogra? <sabdfl> hmm... sec * \sh is the spokesman :) <pitti> it's always better to hear more than just the own opinion when trashing he archive :-) <\sh> and ogra :) and dholbach <sabdfl> linspire just did their German edition release <ogra> mdz, you could put MOTU aside :) <sabdfl> they wait till they have a certain coverage of translations, then release a dedicated iso <sabdfl> has the advantage that the installer can skip the language question <sabdfl> and just install the language it is dedicated to <mdz> ogra: /me points to the "INCLUDE YOUR NAME" comment in the wiki <sabdfl> i wondered if there is any interest in us making similar releases? * \sh is the faulty one :) <mdz> sabdfl: we've discussed it; the primary issue is testing <ogra> mdz, i didnt put it there ... \sh ! <ogra> :) <Mithrandir> sabdfl: but then, you get to keep half a gazillion ISOs on cdimage. <mdz> we need to at least sanity check every ISO release <sabdfl> mdz: i don't know how this would fit into the broader picture, i would not want to amp up the number of iso's on the main release <\sh> mdz: put the blame on me pls :) i need to put it asap on the agenda :) <mdz> if we do 10 localized ISOs, we need to test them all <sabdfl> i suspect these would best be distributed from the loco websites <mdz> 10 locales x 3 architectures = 30 more test cases <sabdfl> we would only do releases that the loco teams want, they test, when they're happy, we push the button <Mithrandir> mdz: have we considered doing some sort of automated testing similar to the lab joeyh has set up? <pitti> right now we still have the ability to ship 10 translations on a CD, which make them somewhat more universal <mdz> Mithrandir: where "considered" -> "gee, that would be nice" <ogra> sabdfl, you mean additional localized ones ? or our default release ? <ivoks> sabdfl: maybe is possible to have more locos in same image, this way more loco teams would work on testing <pitti> sabdfl: that would make much sense with translations we don't put on CDs though, even if the images are sort of unofficial <sabdfl> ivoks: that's a cool idea <Mithrandir> mdz: not "gee, that would be nice, let us commit some resources to it"? <sabdfl> if we could automate the process of generating the install iso, we could make this work <mdz> sabdfl: I expect we would need the launchpad infrastructure in order to manage production of localized ISOs <sabdfl> mdz: absolutely <mdz> maintaining that many sets of seeds is impractical in our current setup <sabdfl> i'll bounce the idea off kinnison in brazil <mdz> ok, can we close the language pack discussion? <sabdfl> ok <sabdfl> thanks <pitti> from my side yes <pitti> thanks <ogra> revu ! <mdz> right, next is \sh on REVU <ivoks> :> <\sh> yes <\sh> I don't know if anybody is informed about our new toy :) <ogra> \sh, give us an introduction :) <mdz> \sh: perhaps a one-line explanation of what REVU does, for the benefit of those listening at home :-) <sabdfl> url again? <ogra> http://siretart.tauware.de/revu/ <ivoks> http://siretart.tauware.de/revu/ <\sh> https://wiki.ubuntu.com/REVU?highlight=%28REVU%29 <\sh> to have a view inside, please refere to http://revu.ubuntu.linux-server.org/ <\sh> I created an account for you all, that u can have a look inside <\sh> username: alexanderlisa@example.com and pw: sabdfl ;) <ogra> sabdfl, its a tool for test autobuilding packages, collecting comments and seeing all data about a package that should get reviewed <\sh> (will be deleted in anyway after this meeting :)) <\sh> some adds to ogra: <dholbach> and collecting advocates (3 for MOTU NEW packages) <ogra> yeah <\sh> right now we're reviewing newpackages for MOTU via wiki..which is not bad, but it's sometimes confusing <ogra> so it perfectly mirrors our review process <ogra> and its written in python :) <\sh> so siretart had an idea of doing it via a webinterface, with database and build automation <\sh> siretart and a friend of him wrote this nice little peace of software, and now we're trying to establish it to the motu world :) <sabdfl> ROCKS! <\sh> right now, uploading packages (debuild -S -sa) and putting comments etc. is working. the test build is included the next days <dholbach> automatic linda and lintian are additional features <ogra> but we feel it would belong into the DC, but we need a sbuild capable environment, so a vserver might not work <\sh> we have only limited resources on our servers, siretart has only a vserver without the possibility to create a sbuild env. and I have only my server with more then one service running on it <ogra> (strike one but :) ) <\sh> dholbach: it's included already ;) <\sh> we can inject all automatic tests we need through hooks <dholbach> \sh: i didn't say they were missing :) <\sh> ok, now we're looking for a permanent home :) <mdz> \sh: are you interested in working on AutomatedTesting as well? ;-) <mdz> right, the matter at hand <sabdfl> are the linode servers not capable of sbuild? <\sh> mdz: let me do my other todos first :) <Kamion> surely you can chroot from a vserver ... * \sh needs a cloning facility ;) <mdz> assuming you get root in the vserver <ogra> mdz, \sh first needs to write a KDE version of gnome-power ) <\sh> Kamion: sbuild also? would u provide us with a solution? what we found out, that we need admin capabilities <\sh> and then update-manager and SER and my normal work, and then life <sabdfl> mdz: i think linode gives you root <sabdfl> it's either Xen or UML based <ogra> \sh, forget about your normal work, who nees TV anyway :) <Kamion> \sh: if you don't have root, then indeed that would be a problem; if you do, then it's relatively straightforward assuming sufficient disk space <mdz> sbuild just requires root <\sh> ogra: u pay my rent? ,-) <ogra> heh, depends *g* <\sh> and my wife ;-) <\sh> ex at least ;) <ogra> NO ! <\sh> more expensive ;) <ogra> yep <dholbach> guys... :) <ogra> ok, offtopic here <mdz> \sh: so is the root issue that you need help setting up sbuild? <ogra> mdz, nope, we'd like a machine in the DC <sabdfl> ogra: why? <\sh> mdz: it's that and resources...I can handle only a bit more...but then my server will break <ogra> sbuild in the test env is already running <sabdfl> how about a linode? <ogra> sabdfl, can we ge sbuild running there ? <ogra> get even <sabdfl> ogra: yes, i believe so, it's a root environment <sabdfl> UML i think <ogra> ah, great, then this would suffice <elmo> uh <ogra> elmo, objections ? <sabdfl> elmo: we need to get a purchase order for a bunch of linode's in <elmo> this is a buildd that only accepts uploads signed by universe maintainers right? <ogra> elmo, yes <sabdfl> then we need a very lightweight process to get those fired up <\sh> elmo: yes <dholbach> elmo: and MOTU hopefuls <ogra> elmo, with additional acess control before <elmo> if so - I'm 95% completed work on something that makes it a moot point <elmo> oh, ok, not for MOTU hopefuls <mdz> this is essentially entirely untrusted stuff <mdz> it's probably not even signed at the moment <elmo> ok, nm then <sabdfl> elmo: we will need the "build a package for anybody" stuff in due course, but i think linode is the answer for this one <mdz> and certainly not by a key we can authenticate <\sh> there is no package coming from this system <elmo> sabdfl: want me to sort that out? <sabdfl> elmo: yes please <\sh> all packages are reviewed only and uploaded by MOTUs with upload right to universe <mdz> sabdfl: as long as it doesn't steal cycles from backports ;-) <dholbach> \sh: NO, they are uploaded by MOTU hopefuls as well <ogra> dholbach, he means in the end <dholbach> ogra: well uploads to the archive were already handled before :) <ogra> dholbach, yeps <ogra> :) <mdz> ok, so the resolution is to set up a linode system to run these builds <mdz> any further unresolved issues? <sabdfl> \sh: we will pay for the linode system, she's yours to play with <mdz> \sh: will this meet your needs? <\sh> sabdfl: we are honoured :) and I have to say thx for siretart in absence as well :) <sabdfl> elmo: let's talk about a streamlined linode-for-community deal tomorrow? <\sh> mdz: of course <elmo> sabdfl: sure <sabdfl> elmo: are you in london tomorrow? <elmo> sabdfl: all week <sabdfl> cool <mdz> I am in london in ~48 hours <sabdfl> next up? <sabdfl> mdz: rock :-) <ogra> sabdfl, done :) <mdz> that's the end of the agenda <mdz> any other business? <sabdfl> \sh: REVU looks very cool, well done <\sh> sabdfl: I will report it to siretart, I think he will be very proud to hear that :) <ogra> sabdfl, its siretarts baby, \sh has set up the backend <mdz> ok, looks like it's safe to adjourn <mdz> thanks, everyone <\sh> thx mdz <ogra> thanks mdz <pitti> thanks folks <dholbach> thanks mdz * ..[topic/#ubuntu-meeting:Seveas] : Calendar -- https://wiki.ubuntu.com/Calendar || Logs -- http://people.ubuntu.com/~fabbione/irclogs || Thu 30 June 14:00 UTC Documentation Team -- https://wiki.ubuntu.com/DocteamMeetingAgenda || Tue 5 July 22:00 UTC Community Council -- http://wiki.ubuntu.com/CommunityCouncilAgenda || Tue 12 July 22:00 UTC: Tech Board -- https://wiki.ubuntu.com/TechnicalBoardAgenda || This is NOT #ubuntu, or #ubuntu-devel #ubuntu-meeting 2005-07-05 <highvoltage> anyone on this channel coming to the edubuntu summit? <mdke> hello everyone <jsgotangco> hi <jsgotangco> we can start in a few minutes <mdke> 5 mins? <jsgotangco> sure <jsgotangco> im still testing out this hula account <mdke> aha <jsgotangco> hno73: hey <hno73> hello all :) <jsgotangco> ok let's just wait the others in a minute or so * mdke nods <mgalvin> hi all * froud waves <squinn> hi al <squinn> ll <squinn> dah all* <jsgotangco> alright lets start * froud nods <jsgotangco> ok this is the start of the regular meeting which will happen bi-weekly <jsgotangco> to start of, let's introduce ourselves so we'll know who's here <jsgotangco> -> Jerome Gotangco <froud> Sean Wheller * mgalvin Matt Galvin * hno73 <- Henrik Nilsen Omma <mdke> <-- matthew east <jsgotangco> great any lurkers? :) <jsgotangco> hmm i guess none, we're well represented anyways <froud> https://wiki.ubuntu.com/DocteamMeetingAgenda <jsgotangco> https://wiki.ubuntu.com/DocteamMeetingAgenda <jsgotangco> that's our agenda for today <jsgotangco> btw, this page will be always upated for the next meetings <jsgotangco> alright we go straight to agenda #1 <jsgotangco> StyleGuide <jsgotangco> hmmm jeffsch is still not here although i made sure i set the meeting with him in mind <froud> Jeff is leading that, but is not present <squinn> Okay. <jsgotangco> yeah, but he said this was a good time for him anyway... <mdke> come back to it when he arrives? <jsgotangco> this is pretty much WIP at the moment and it needs love <froud> no move on <jsgotangco> the reason why we had to put this first in agenda is because we'll need consistency in the documents <froud> yes people need to take a look and see if they can contribute to it <froud> I can take the docbook section, pending decisions on this meeting <jsgotangco> jeffsch actually asked me to look into some sections to contribute like writing for an international audience <mdke> there is a lot of good material in the gnome guide for that <mdke> i would suggest copying it <jsgotangco> yes, jeffsch actually suggested it <froud> also look a KDE Guide :-) <jsgotangco> he has a good number of referrences on the doc <mdke> yeah <jsgotangco> but he hopes people who are currently contributing would also consider the contribution to the Style guide because we will all use it <froud> so jsgotangco you will take the international audience aspect <jsgotangco> froud: yup, i'll cover that <froud> I will take the docbook aspect <froud> what else is there <jsgotangco> https://wiki.ubuntu.com/StyleGuide <judax> greetings, sorry I am late <froud> who are we following for Grammar and Spelling <jsgotangco> i suggest people look into it and see what to contrribute <froud> is it Chicago Manual of Style? <squinn> <- Sean Quinn, oops sorry. <jsgotangco> froud: i believe so, that's what jeffsch preferred if i remember <froud> OK <froud> so then those sections should be easy to complete <jsgotangco> if the Style Guide is released in a few months, we can all adhere to it to our docs for breezy <froud> just reference the CMS <mdke> jsgotangco, + <mdke> everyone should take the time to read it <jsgotangco> completion of the Style Guide is a signicant accomplishment for the project itself <jsgotangco> speaking of jeffsch <jeffsch> howdy <jsgotangco> jeffsch: we were just discussing styleguide <froud> speak of the devil and he will appear <squinn> yeah, welcome jeffsch..nice timing <froud> jsgotangco: you want recap for jeffsch <jsgotangco> jeffsch: we just started with styleguide and who will tackle on the parts <jsgotangco> i will look into international audience <jsgotangco> froud will tackle docbook stuff <jsgotangco> for grammar stuff, will we be using chicago manual? <squinn> yes, i think so, jsgotangco <jsgotangco> jeffsch? <jeffsch> do we all have access to chicago? <froud> jeffsch: are you ok with CMS <froud> I do <jsgotangco> im a bit familiar with it <jeffsch> if we don't have access to it, then there's not much point specifying it <froud> http://www.press.uchicago.edu/Misc/Chicago/ <squinn> froud, right. <froud> http://www.press.uchicago.edu/Misc/Chicago/cmosfaq/cmosfaq.html <froud> You can register to it and use it as a search <froud> if you dont have a print copy <jeffsch> yes, but that is not the whole manual <jsgotangco> hmmm do we really need everyone to know CMS <froud> jeffsch: no but what is there is good <froud> http://www.chicagomanualofstyle.org/search.html <froud> jsgotangco: no not realy <froud> its mostly for resolving dispute <squinn> oh, wow, they're about $35 for print <froud> when ppl disagree CMS governs <jsgotangco> ok so we let everyone work first in their own but we'll need a review period on docs for editorial stuff <froud> yep <jsgotangco> ok the question now is who would contribute in that particular section <jsgotangco> (it is pretty crucial btw) <froud> what spelling and grammar? <froud> not me dude I stink in both these departments <jsgotangco> anyone what to take a look at it at least? <squinn> I could contribute a little bit to the StyleGuide. <jsgotangco> if not we'll put it still in the open <froud> jsgotangco: jeffsch is the lingo expert, but he did all the work <squinn> But not in a lead. <jeffsch> jsgotangco: are we talking about who does reviews, or who does styleguide? <jsgotangco> well i can't do that either, english isn't my primary language <jsgotangco> jeffsch: styleguide <froud> jeffsch: grammar and spelling <froud> https://wiki.ubuntu.com/StyleGuide/GrammarPunctuationSpelling <jeffsch> people have signed up for "doc leads" on DocteamProjects.... <jeffsch> maybe they can take some responsibility <froud> more, huh :-) <squinn> Right. <jsgotangco> ok i will review the other style guides and see what we can do <jeffsch> one of the hazards of stepping forward, i guess :-) <mgalvin> i speak english as my primary lang, I am sure I can at least help with some of that <jsgotangco> mgalvin: great <squinn> Again, I can contribute with StyleGuide <froud> there you go :-) <mdke> i can help review docs, but probably not work on Styleguide <squinn> but I can't take StyleGuide in a lead position. <squinn> Just as a contributer. <jsgotangco> sure UK english sounds better IMO <mdke> squinn, cotnributor is awesom <mdke> jsgotangco, ++++++ <mdke> ;) <jeffsch> ok great! so we have mgalvin, squinn, mdke woo hoo! <froud> jsgotangco: UK en is rotten :-) <jeffsch> did i miss anyone? <mdke> jeffsch, i can't work on the styleguide <mdke> but I will do review of docs based on what the styleguide says <jeffsch> doh! i read too quickly... <froud> cool <squinn> hah i noticed that <jsgotangco> jeffsch: i'll do the i18n <jsgotangco> alright, StyleGuide seems to be back on track... <jsgotangco> anything more on StyleGuide <jsgotangco> ? * mgalvin stepping away for a moment, will be back in a min <jsgotangco> hmm not sure if i am lagged, but we'll move to #2 <jsgotangco> "Revisit Doc Planning" <squinn> no lag jsgotangco <jsgotangco> hmmm who added this <squinn> we're just quiet. <jeffsch> me <mdke> jeffsch, perhaps you can outline what you mean briefly <jsgotangco> i think jeffsch is suggesting each doc have a spec of sorts <squinn> jeffsch, do you mean that every doc has a plan like the StyleGuide did? <mdke> yeah, the thing for the styleguide looks incredibly professional <jeffsch> we need to know who we are writing for, and the purpose of the doc <mdke> would help newcomers <squinn> mdke, I can agree with you there. Quite well done. <jsgotangco> (its actually a good idea to have a spec of sorts) <squinn> Oh, yeah. <squinn> jeffsch, ++++ <froud> jsgotangco: this goes back to https://docteam.ubuntu.com/repos/trunk/teamstuff/content-specification.xml <froud> and https://docteam.ubuntu.com/repos/trunk/teamstuff/information-plan.xml <mdke> do we thing something brief like that of the Styleguide is a good idea? I give my +1 <jsgotangco> hmmm i haven't been reading the teamstuff in svn... <jeffsch> froud: yes, the idea has been around for a while, but we have yet to do anything with it <froud> It was an idea way back but got no support <froud> snap <jsgotangco> i'd give my vote on something like this <mdke> i think something brief like has been done on the Styleguide is a good idea, anything more detailed might be more work than we can handle though <jsgotangco> it gives a good idea on what to do for newcomers <froud> I will do it for the Kubuntu docs <jsgotangco> froud: ALL? :) <froud> If I must <mdke> can the persons who are taking charge of each doc take care of it? <jsgotangco> i was thinking of what mdke just suggested <mdke> i think that could be an important part of what that job involves <jsgotangco> and use the style used in the StyleGuide <froud> well I will open a docspec dir in kde <mdke> along with maintaining the status and preview <froud> and put the files there <froud> then people can take ownership <jsgotangco> ok can we announce this on the list then for the specs for docs <froud> but so far nobody but jjesse and I have reported ownership <froud> for Kubuntu that is <jeffsch> should the doc plan be only in svn? perhaps a wiki page for each doc <mdke> i don't think svn is necessary actually, just wiki page <squinn> jeffsch, + for wiki page for each doc <jsgotangco> wiki too for me <froud> I would like svn and html previews <froud> at least for Kubuntu stuff <jsgotangco> alright <jsgotangco> so wiki it is, but froud will do stuff for Kubuntu <mdke> html preview of what? <mdke> of the document plan? <froud> jsgotangco: all th ekubuntu stuff in https://docteam.ubuntu.com/repos/trunk/teamstuff/information-plan.xml links to http://lnix.net/~froud <judax> I have offered ownersip in Kubuntu area <froud> judax great on what? <judax> quickguide and can take more if needed <jsgotangco> ok hold on this is getting too big <jsgotangco> the proposal is do to a simple spec for docs <froud> cool can you update on https://wiki.ubuntu.com/DocteamProjects <froud> I see troy has some stuff too <froud> jsgotangco: I think let the spec be what people want make it <mdke> i would tend to agree with froud <froud> if its short, so be it <froud> if its long, so be it <squinn> jsgotangco, I like froud's idea, +. <mdke> with the minimum being something similar to the Styleguide plan <froud> +1 <jsgotangco> right, so people who are doing docs, please consider making a spec and refer to the plan in StyleGuide <squinn> Okay. <jsgotangco> we cool in that then <mdke> yeah <jeffsch> +1, except change "please consider making" to "please make" <mdke> let's increase our speed otherwise we won't get through the issues <squinn> Yes, please, + mdke <jsgotangco> ok all people writing docs SHOULD MAKE one :) <froud> ok for kubuntu you will find kde/docspecs <froud> svn commit -m add docspec folder docspecs --non-interactive <judax> +1 <jsgotangco> ok any more stuff on this, please send to list <froud> kk <jsgotangco> we'll go to #3 - format to ship <jsgotangco> this is gonna be tough * froud ducks <mdke> i don't think it will be too bad <jsgotangco> has anyone read froud's treatise? :) <judax> aye <squinn> okay, quick off-topic question..let's not make it a discussion..how can i get an html preview from my svn repo on my computer locally [~/ubuntu-doc/foo/bar] to the web? <squinn> jsgotangco, reading now <froud> jsgotangco: there may be a simple solution <jsgotangco> froud: please elaborate <jsgotangco> (kubuntu is not an issue here btw) <froud> let gnome do yelp xml * mgalvin back <froud> and kde we will do html <froud> thatleaves only one problem <jsgotangco> yes? <froud> providing that gnome ppl are prepared to lose publishing features <mdke> why would we do different things for gnome and kde? <froud> then i see no problem <froud> next problem would be the profiles <mdke> hang on <froud> yelp wont like them <jsgotangco> they wont <froud> mdke: status quo <hno73> what do you mean by publishing features? <squinn> hold on <hno73> indexes etc? <froud> yes <squinn> <xref> i think <mdke> don't move to profiling yet pls froud, we can deal with it next issue <froud> hno73: yes <squinn> speaking of xref, shaunm over at gnome-doc-utils says next release is around the corner <froud> k <mdke> let's focus <squinn> that will fix endterm <froud> squinn: yes <jsgotangco> ok give me a few minutes brb <froud> ppl I proposed the html route to enable certain features and functions <froud> and b'cause I thought we could take advantage of them <mdke> what are the disadvantages of html? <froud> but if it makes life difficult then let's side step it <mdke> does yelp support it properly? <froud> mdke: ye <mdke> so what are the disadvantages? <froud> mdke: none <mdke> advantages would be that we can publish the same files in ubuntu-doc package AND online <froud> mdke: yes <mdke> does any one see disadvantages? <froud> and custom style as we wish <hno73> How do we link pages together (ie navigation) <squinn> yep, which is kind of nice <hno73> Yelp has some side bar system <squinn> yes <hno73> we need to code that in HTML <squinn> hno73, sidebar seems to be disable for HTML <froud> hno73: you mean the toc <squinn> but i just checked about ubuntu hold on <hno73> not just toc, but generally how the user navigates around the docs <hno73> forward back and sideways <froud> chunked html provides GRUB <froud> next prev, home <hno73> Look at this: http://www.theopencd.org/files/beta/4/en/firefox_desc.html <hno73> Side menu and tabs that we might use <froud> ok <jsgotangco> back <hno73> next prev, home can be added too <froud> chunk output adds it by default <mdke> sounds good <hno73> do you have link to chunk? <froud> http://lnix.net/~froud/kubuntu-install/C/index.html <hno73> ok, thanks <froud> we can decide whether or not to suppress the meta <hno73> right <jsgotangco> will HTML be more acceptable then for GNOME <froud> CSS can do most of the work <squinn> right <squinn> and yeah, userguide comes out in chunk output <froud> in hoary we did ship html versions, they were just not used <squinn> here's my question <squinn> do we still edit in xml? <froud> yes <squinn> and then make qg/ug/html ? <jsgotangco> squinn: of course, its our source <froud> see kde/Makefile <mdke> froud, that html looks great <squinn> ah, that's true, jsgotangco <froud> with pwd kde do make kall <mdke> needs a bit of ubuntu bling tho <squinn> mdke, a logo here and there <froud> mdke: it uses kde help:/common/kde-default.css with the kio-ioslave <mdke> we can use the ubuntu css <hno73> squinn: a bit more <hno73> mdke: yes <mdke> henrik you can sort that? <froud> mdke: on a kubuntu system it looks like kde docs do <mdke> cool <hno73> mdke: yes, let me look at the chunk build process <jsgotangco> it seems we're sold on HTML> <jeffsch> if we decide on html output for gnome, then how does that change the packaging process? <jsgotangco> good question <mdke> yep <mdke> what problems are we likely to have with -devel? <froud> jeffsch: it does not <hno73> who packages the docs ATM? <mdke> hno73, its kind of improvised <froud> enrico <jsgotangco> (enrico's pretty much active btw, helping out in the sidelines) <froud> yes, bless his cotton socks <hno73> mdke: let's try to catch mdz tomorrow and get clarity on that process <froud> ppl this is a tradeoff decision <squinn> i'll be right back <hno73> including timing <froud> hno73: enrico is whitelisted <squinn> hno73, who's mdz? <froud> he packages and uploads <jsgotangco> squinn: Matt Zimmerman <squinn> thought so <squinn> just wasn't sure <hno73> squinn: Ubuntu lead developer <mdke> hno73, is he in london? <hno73> I still want to ask him about the timeframe <hno73> mdke: yes for a few days <froud> hno73: for Kubuntu, uniq is building debian/ <jsgotangco> ok <froud> we should have regular deb builds for kubuntu in a few days <jsgotangco> we're taking a chunk here <jsgotangco> ok so what's the consensus on this issue <mdke> i am attracted to the html idea <judax> +1 html <mgalvin> +1 html <hno73> I'd like to see HTML for both GNOME and KDE <hno73> simpler that way <jsgotangco> mdke: take advantage on the edubuntu summit and catch some people to discuss the issue <froud> please note that this applies only to ununtu-docs not any gnome doc that happens to get developed in our svn <jsgotangco> right <jsgotangco> good point <froud> those docs must conform to gnome <mdke> jsgotangco, ok i'll try <froud> because the move upstream <mdke> what gnome docs are worked on in our svn? <jsgotangco> is a long road ahead? *grin* <froud> for example in hoary I did ubuntu-update manager and ubuntu-device database <jsgotangco> OK so what's the consensus.... <froud> there may be gnome apps developed at ubuntu but not upstream yet, we can do those docs in svn <squinn> +1 html <hno73> HTML with some added bling <mdke> cool <jeffsch> +1 html, plus look at getting a sidebar <mdke> told you it would be easy <jsgotangco> great... <mdke> we can put the decision to the TB soon <jsgotangco> right so
{'channel': 'ubuntu-meeting', 'month': 7}