Feb 05 19:00:21 sure, here we go. Feb 05 19:00:27 10... 9....\ Feb 05 19:00:35 ill ask that everyone be respectful to the current speaker, im sure this wont be a problem Feb 05 19:00:36 carpaski: hehe, I actually have an time-source locally synced to some 20 other nodes. Feb 05 19:00:42 hello guys, hope its ok to lurk around here :) Feb 05 19:00:51 * port001 is away: gym Feb 05 19:00:55 offtopic questions or anyone looking to join up, please hang on until after the meeting Feb 05 19:01:21 hopefully youve all read the project page, if not, youll probably have no idea what we are talking about :) Feb 05 19:02:04 the basic premise at this point is an extremely flexible backend library for building any number of installers Feb 05 19:02:07 --> kn0rki (~kn0rki@pD953677D.dip.t-dialin.net) has joined #gentoo-installer Feb 05 19:02:42 a large ammount of the organization and planning is thanks to esammer, and it like to give him the floor for his first topic, thanks everyone for coming :) Feb 05 19:02:53 s/it/id Feb 05 19:03:22 hello all. i'm going to discuss the items in the email i sent to both -installer and -dev Feb 05 19:03:44 the first of which is our overall design status Feb 05 19:04:15 a number of documents including a rough design doc, a uml use case, and a very incomplete class diagram have been done Feb 05 19:04:28 they are all available from the project page Feb 05 19:05:02 there's little i can say about them that they dont' say for themselves. a little incomplete, but a basis for going forward. Feb 05 19:05:33 those who are interested should read and comment on them either here or on the -installer list Feb 05 19:05:56 (after the meeting) Feb 05 19:06:00 in terms of design, we have a "back end" which is really just a set of APIs (in python) that cover most of the functionality Feb 05 19:06:23 this supports the control logic depending on each arch and what we call arch templates Feb 05 19:06:53 arch templates define all logic for each arch and the raw actions to take for said arch. Feb 05 19:07:02 <-- acooks (~acooks@tbnb-ip-nas-1-p260.telkom-ipnet.co.za) has left #gentoo-installer ("Leaving") Feb 05 19:07:31 the back end works with and can generate or "play back" install profiles that contain all info for recreating the installation (cflags, use flags, etc.) Feb 05 19:07:46 the front ends are interchangable and contain all UI logic. Feb 05 19:08:06 front ends will be available for text, ncurses, gtk, qt, SOAP end points - whatever you want Feb 05 19:08:28 this keeps logic and control separate and makes for easy development / customization Feb 05 19:08:52 that's the general overall design we have in a nutshell. Feb 05 19:09:05 <-- kn0rki (~kn0rki@pD953677D.dip.t-dialin.net) has left #gentoo-installer ("Leaving") Feb 05 19:09:07 of course, there's a lot more to it than that, but the docs will go into greater detail Feb 05 19:09:48 tseng: unless there's something to add, i'll move along down the rest of the items (which are shorter, i promise) Feb 05 19:09:59 sounds good. Feb 05 19:10:08 ok. moving along. Feb 05 19:10:57 the features we have are what you'd expect. they do not remove any flexibility (or that is the aim) from the current process. Feb 05 19:11:15 section 2 of http://www.gentoo.org/proj/en/releng/installer/design.xml lists the big ones Feb 05 19:11:30 but most of this i covered with the design overview Feb 05 19:12:31 we'll get into questions about specific features at the end, but suffice it to say, it's multi front ends, automated deployment, full arch support, reusable back end, customization of steps and process, and more Feb 05 19:13:04 we also just spoke briefly about l10n support in the UIs. this is a greater issue which we can cover in QA Feb 05 19:13:25 moving on (unless i've missed something) Feb 05 19:13:45 do you mean we won't discuss l10n today? Feb 05 19:14:01 discussion is last. Feb 05 19:14:07 danarmak: the specific implementation, not right now. we can in QA. Feb 05 19:14:20 er... Feb 05 19:14:26 QA as questions/answers? Feb 05 19:14:30 yes Feb 05 19:14:34 sorry, misunderstood. please continue. Feb 05 19:14:41 ok. Feb 05 19:14:51 in terms of publicity, we've been a little quiet. Feb 05 19:15:07 this is mainly because this is a hot spot of discussion for a lot of people Feb 05 19:15:18 * tigger^ coughs Feb 05 19:15:35 we wanted to get an initial design done so that we can answer questions as fast as we know they'll be asked. Feb 05 19:16:19 we do NOT want to remove flexibility from anyone which is a major (and justified) concern and we wanted to figure out how to accomplish that before the onslaught of questions Feb 05 19:16:55 now that we have a semi functional design and a team in place, we will start on a very rough prototype to show people. Feb 05 19:17:27 this prototype should be semi working when we announce to GWN and gentoo.org so people can SEE an example of the design in action. Feb 05 19:18:21 hopefully, this prototype shouldn't take too long (2 - 4 weeks, *maybe*) Feb 05 19:18:30 but i don't want to commit to a date Feb 05 19:19:10 after this is done, we will open it up to the full community at which point we'll integrate comments and suggestions Feb 05 19:19:32 and by full, i mean users and devs (GWN, gentoo.org news, etc.) Feb 05 19:19:52 tseng: anything else wrt this? Feb 05 19:20:05 esammer: main web home Feb 05 19:20:09 esammer: "project pages" Feb 05 19:20:20 the mailing list and here will be where the action happens Feb 05 19:20:31 but milestones etc will be made more public Feb 05 19:20:46 we do have the list and the project pages in place as a beginning for those interested. Feb 05 19:20:52 right. Feb 05 19:21:11 anything else? Feb 05 19:21:24 i dont think. Feb 05 19:21:42 ok. the initial delegation of tasks. Feb 05 19:22:11 we already have a few coders, as well as documentation and advisers. Feb 05 19:22:13 i'll sit back and take credit for your hard work. Feb 05 19:22:20 heh Feb 05 19:22:50 i think we might want to wait until we get to recruitment / getting involved as we'll hopefully have more names in the proverbial hat Feb 05 19:23:04 spyderous spy|lab Feb 05 19:23:05 esammer, could you lay out an idea of what needs done breifly Feb 05 19:23:11 sure. Feb 05 19:23:13 and we can tentatively put names to it Feb 05 19:23:28 --- pauldv|away is now known as pauldv Feb 05 19:24:21 currently, we have tseng, klieber, spyderous, and pauldv, and myself doing design and adviser work. karltk, npmccallum, and myself are coding. blackace has been doing our docs with tseng (iirc). Feb 05 19:24:30 design has mostly been a group effort Feb 05 19:24:40 we need more coders, imo. Feb 05 19:25:01 we also have danarmak and dams that have been helping Feb 05 19:25:03 esammer: I don't think the prototype phase is the best period to add coders. Feb 05 19:25:13 I dont think youll have any problems in that respect, and you need not worry. (sorry please continue) Feb 05 19:25:30 esammer: most certainly we will need more coders as the initial implementation has stabilised. Feb 05 19:25:31 karltk: it's possible you're correct. that is something we need to figure out Feb 05 19:25:41 johnm: i think you're right Feb 05 19:25:45 right Feb 05 19:25:47 both very good points. Feb 05 19:26:12 in case i glazed over it, implementation is python and some shell magic Feb 05 19:26:38 esammer: I assume python will be put on the livecd? Feb 05 19:26:46 tigger^: that's a good question. Feb 05 19:26:59 assuming it isn't already, I didn't think it was Feb 05 19:27:04 there was talk of that or a custom live cd with the stuff needed for the installer Feb 05 19:27:09 tigger^: how can portage work without python? Feb 05 19:27:18 karltk: portage doesn't need to Feb 05 19:27:25 tigger^: I don't think it is a big problem to add it Feb 05 19:27:25 karltk: portage is in the tarball remember? Feb 05 19:27:26 tigger^: it isnt. it may also rais ean issue of what UI languages can be used (python hooks) Feb 05 19:27:30 it is on the livecd's Feb 05 19:27:30 portage isn't on the livecd, it's in the stage tarball Feb 05 19:27:31 karltk: i think python is only in the *stages* not the livecd Feb 05 19:27:38 tigger^: ah, mea culpa. Feb 05 19:27:58 this problem will quickly solve itself if we have a finished product and a need for python Feb 05 19:28:03 I just checked, it is on the livecd's Feb 05 19:28:04 pauldv: me neither really, just saying Feb 05 19:28:12 iggy: python is? Feb 05 19:28:20 esammer: yes Feb 05 19:28:21 iggy: thats one less issue. Feb 05 19:28:26 that's odd. wonder why. Feb 05 19:28:27 ok. that answers that. Feb 05 19:28:27 johnm: that's livecd-specific. whatever gentoo users for their official livecds may not be the desired choice for people using catalyst to build their own livecds Feb 05 19:28:38 python2.2 if it matters Feb 05 19:28:48 iggy: it does. and 2.2 is good enough:) Feb 05 19:28:55 iggy: the range of languages able to be used as a UI may still have an impact. but minimal I'm sure Feb 05 19:28:59 we'll also need more modules, but these are all implementation details Feb 05 19:29:20 npmccallum: actually, it would affect the roadmap. Feb 05 19:29:41 obviously, a live cd that doesn't have a full X environment limits the UIs available so that will be another issue. we'll need to work with the releng team (corect?) to find out what we can do here. and no, X won't be on every live cd because of this. Feb 05 19:29:51 if the sooner we can have a good idea of the installer core and specify the module interfaces, the sooner we can put more people to work on the various plugin modules in parallell Feb 05 19:30:14 if the/the Feb 05 19:30:26 ok. so this is something that has to be worked on. Feb 05 19:30:58 And my appologies for interrupting once more, but just in case it hasnt been thought of in design, we should leave opportunity for portage-ng support. Feb 05 19:31:10 esammer: what are you referring to by "this", coordinating with the releng team? Feb 05 19:31:49 npmccallum: the releng team controls what's on the live cd, iirc, which will affect what UI support the installer will have Feb 05 19:32:46 esammer: right, I'm just trying to understand what to put on the TODO list :) Feb 05 19:32:48 either way, the base back end can be worked on before this is decided. this will affect the roadmap though, as karltk said, so it should be looked into quickly. Feb 05 19:32:54 although the ability for anyone to build their own livecds should have a big effect on that. Feb 05 19:33:01 spyderous spy|lab Feb 05 19:33:03 spy|lab: yes Feb 05 19:34:01 npmccallum: just put down that we need to figure out what is required of the live cd, if it can be the regular live cd and if a custom live cd is required Feb 05 19:34:35 in the interest of time, i'm going to move along. this isn't going to be decided right now. Feb 05 19:35:53 spyderous spy|lab Feb 05 19:36:02 <-- acidfunk has quit ("ACAB") Feb 05 19:36:25 to cover tasks again, quickly - karltk, npmccallum, myself coding. blackace documentation. project pages tseng & spy|lab? advisers - everyone else. design community and karltk & myself will coordinate it Feb 05 19:36:30 is this acceptable? Feb 05 19:36:34 <-- tigger^ (~rob@smtp.gentoo.org) has left #gentoo-installer Feb 05 19:36:43 yes. Feb 05 19:36:50 ok. Feb 05 19:36:53 yep. Feb 05 19:37:07 release cycles and practices Feb 05 19:37:22 esammer: sounds ok to me Feb 05 19:37:34 are we ok with following a XP style system where we code, test, release every X days? Feb 05 19:37:47 s/days// Feb 05 19:38:12 maybe target that, but also try and put out a decent snapshot? Feb 05 19:38:22 a little flexible of the time Feb 05 19:38:29 tseng: right, with snapshots at the end of each cycle Feb 05 19:38:43 esammer: I prefer the gnome/mozilla style releases. although initially, days->weeks seems quite alright to me. Feb 05 19:38:46 how stable/complete or alternatively WIP will such releases be? what are you willing to release? will there be a latest-stable and latest-dev release? Feb 05 19:38:46 we can release snapshots if we pass a milestone or something Feb 05 19:39:05 esammer: yes, xp lends itself extremely well to prototyping projects Feb 05 19:39:44 esammer: I've run a few commercial prototyping projects using xp, and the good thing is that you always have a running prototype (after the initial release) that you can point people to. Feb 05 19:39:45 i'd suggest a bimonthly snapshot, say the 15 and 30 Feb 05 19:39:49 danarmak: i think we'll have unstable (could be broken) snapshots and maybe milestone snapshots that are semi stable initially Feb 05 19:40:04 karltk: that's what i was thinking as well Feb 05 19:40:06 then manual snapshots in addition to that when we feel it'd be useful Feb 05 19:40:40 as long as each snapshot isn't broken or dangerous, the more often for testing, the better. Feb 05 19:40:45 imo, that is Feb 05 19:41:33 we'll decide the frequency as we see how the code initially develops, but let's plan on very short cycles to allow for a lot of feedback and community review Feb 05 19:41:55 is this ok? Feb 05 19:42:04 sounds good to me. Feb 05 19:42:11 ok. Feb 05 19:42:25 I think the most important thing is to start with one frontend only. You will probably need to review design so each frontend adds duplicate efforts when things change Feb 05 19:42:37 pauldv: this is true. Feb 05 19:42:53 before any frontend there has to be a begining of the api Feb 05 19:43:13 we already discussed starting with the kickstart-style frontend after this is in place Feb 05 19:43:22 pauldv: the various frontends will hopefully be "just" as any other pluggable module. Feb 05 19:43:34 --> z3b (~z3b@p213.54.31.103.tisdip.tiscali.de) has joined #gentoo-installer Feb 05 19:43:43 if we can start with a back end that takes a profile and runs with it, i'd be happy. Feb 05 19:43:59 karltk: I know, that's why you can delay creating them until you are fairly certain that the interface/api is stable Feb 05 19:44:06 you need a tiny bit of user intereaction here Feb 05 19:44:24 for the standalone, which is why that will be first out.. Feb 05 19:45:01 pauldv: exactly. Feb 05 19:45:02 ok. so we'll start with something that is probably just a profile parser and hands off for execution to the api (back end) Feb 05 19:45:35 we'll develop each front end as appropriate when the api becomes stable(ish) Feb 05 19:45:54 although it's probably easier to start with text based UIs Feb 05 19:46:16 in terms of resources Feb 05 19:46:34 i think we have everything we need right now - project page, cvs access, lists, irc, etc. Feb 05 19:46:37 are we missing anything? Feb 05 19:47:16 i suppose that's a "no." :) Feb 05 19:47:24 i'll move on then... Feb 05 19:47:33 yes, a bug repository Feb 05 19:47:39 karltk: good call. Feb 05 19:47:41 bugs.g.o? Feb 05 19:47:58 can we get a product in bz or something similar? Feb 05 19:48:04 klieber: that's good enough, if we can get our own "module" or whatever it's called in bugzilla:) Feb 05 19:48:15 I have connections...I'll see what I can do. Feb 05 19:48:26 klieber: cool. that would be very helpful Feb 05 19:48:27 klieber: (lol), that's good. Feb 05 19:48:51 anything else? Feb 05 19:49:14 esammer: we may want to add an installer-specific bugreport tool early on, to avoid having people litter the other products with installer-specific bugs Feb 05 19:49:30 karltk: sure. that's fine. Feb 05 19:49:31 we don't have a general link to our project page from the "projects" page Feb 05 19:49:37 but that is small Feb 05 19:49:45 that's because it isn't top-level Feb 05 19:50:09 the desire for a proper project directory on g.o. is a different debate, I think:) Feb 05 19:50:24 where we do need a link is off the releng index, drobbins Feb 05 19:50:38 yeah Feb 05 19:51:15 ok, small issue with the bugzilla thing... Feb 05 19:51:18 ok. someone can look into that, but i think we'll only really need that when we start announcing to the entire community Feb 05 19:51:19 npmccallum: add bugzilla + releng link Feb 05 19:51:29 already done Feb 05 19:51:32 :) Feb 05 19:51:35 klieber: what's that? Feb 05 19:51:39 I guarantee that if I create a new bz product called "installer" you guys will be the proud new parents of any/all install related bugs. Feb 05 19:51:48 "I can't partition my hard drive. waaahhhh!!!" Feb 05 19:51:48 heh Feb 05 19:52:09 so do you want to have another name? Feb 05 19:52:16 GLI? Feb 05 19:52:17 ok. is anyone opposed to something like "GLI" Feb 05 19:52:19 heh Feb 05 19:52:20 "chickenpoop" Feb 05 19:52:27 karltk: no. Feb 05 19:52:33 :) Feb 05 19:52:35 klieberismydaddy Feb 05 19:52:41 * klieber coughs Feb 05 19:52:46 how about GLI :) Feb 05 19:52:52 that works too.. Feb 05 19:52:56 klieber: that's fine. Feb 05 19:52:58 GLI it is... Feb 05 19:52:59 GLI is suitably obscure Feb 05 19:53:25 then wranglers can move stuff there as needed. Feb 05 19:53:27 esammer: please bug seemant about adding the installer subproject as a subproject on the releng project page Feb 05 19:53:34 so obscure that people won't know to file it in that category Feb 05 19:53:37 pauldv: will do. Feb 05 19:53:55 spy|lab: there is a one-sentence description as well :P Feb 05 19:54:26 klieber: "File all GLI-related bugs here." Feb 05 19:54:46 heh Feb 05 19:54:50 ok - is anyone opposed to regular (if only informal) meetings? Feb 05 19:55:02 that's probably a good idea. Feb 05 19:55:08 or should i call them "review points"? Feb 05 19:55:15 weekly? Feb 05 19:55:19 (as to not offend corporate types) Feb 05 19:55:40 in terms of frequency, it should probably coincide with coding and snapshots Feb 05 19:55:43 or testing Feb 05 19:55:48 do we need meetings? Feb 05 19:55:53 or just status reports? Feb 05 19:56:01 klieber: that's why i'm asking Feb 05 19:56:02 status reports can be on the project page. Feb 05 19:56:09 I'd suggest status reports. Feb 05 19:56:14 i dont think we need a meeting again soon.. Feb 05 19:56:20 we must have status reports. Feb 05 19:56:20 meetings should be ongoing via the mailing list and here. Feb 05 19:56:23 rather than anything formalized. Feb 05 19:56:27 right. Feb 05 19:56:29 (imo) Feb 05 19:56:29 not till we have a prototype Feb 05 19:56:43 we should have status reports even before then, I would think Feb 05 19:56:48 ok. no meetings, status reports. Feb 05 19:57:01 meetings after prototype? Feb 05 19:57:05 meetings as necessary, might be a better way to put that =P Feb 05 19:57:09 ocassionally Feb 05 19:57:15 what spy said.. Feb 05 19:57:19 sounds good to me Feb 05 19:57:27 ok, I suggest that for now, we have impromptu meetings, or meetings called on -installer. Feb 05 19:57:29 for the coders, i suggest we either meet regularly or spend a lot of time here together to dicuss coding issues Feb 05 19:57:38 if it turns out that this doesn't work well enough, we can always reconsidre. Feb 05 19:57:50 I'll be here often (IRC) Feb 05 19:58:15 esammer: yeah, as I said elsewhere, we should also investigate a network canvas and an audio conferencing tool for the tough discussions. Feb 05 19:58:36 karltk: that's fine. we can figure that out amongst ourselves, i think. Feb 05 19:58:50 ok... Feb 05 19:58:53 moving on? Feb 05 19:59:02 frequency of status reports? Feb 05 19:59:05 esammer: you're at the end of the list. are you wrapping?;P Feb 05 19:59:08 did we cover that? Feb 05 19:59:21 esammer: just call a meeting when needed Feb 05 19:59:21 yeah.. Feb 05 19:59:24 npmccallum: let's say weekly initially Feb 05 19:59:33 who do you want bug mails to go to? Feb 05 19:59:40 npmccallum: at least alongside the releases. Feb 05 19:59:41 um.. Feb 05 19:59:44 gli-bugs@g.o? Feb 05 19:59:59 okaly dokaly neighbor Feb 05 20:00:05 --> Luke-Jr (~luke-jr@198.248.39.176) has joined #gentoo-installer Feb 05 20:00:16 ok Feb 05 20:00:23 one more thing before we do QA / wrap up - recruitment / getting involved Feb 05 20:00:49 karltk mentioned that the actual coders we have for the prototype are ok, which is probably true. Feb 05 20:01:31 so, in a more generic sense, those who want to get involved are urged to join gentoo-installer@l.g.o and idle in here. Feb 05 20:01:56 esammer: while I think that publicity is nice, be carefull with not recruiting more people than is actually usefull (it will only slow things down) Feb 05 20:02:13 pauldv: correct, which is why i'm going to go with karltk Feb 05 20:02:54 i would like to invite everyone here to go over the design docs and comment, though. Feb 05 20:03:08 we need (constructive) input. Feb 05 20:03:12 blue! Feb 05 20:03:14 oh sorry. Feb 05 20:03:18 yes, yes, blue Feb 05 20:03:43 has anyone tested the cvs module yet to see if it works? Feb 05 20:03:52 klieber: i haven't, no. Feb 05 20:03:54 also, how do you want to distribute tarballs? Feb 05 20:04:08 we can use /experimental if you'd like Feb 05 20:04:21 rather than ~esammer Feb 05 20:04:23 i'd put 'em out of someone's dev.g.o website initially, no point in mirroring for such small numbers Feb 05 20:04:25 klieber: that's probably a good idea. Feb 05 20:04:36 in this instance, would adding an ebuild for snapshots be ok? Feb 05 20:04:50 if you do that, I'd rather you not pull off of dev, then. Feb 05 20:04:52 esammer: can people install the installer? Feb 05 20:04:57 and use /experimental instead Feb 05 20:05:00 karltk: heh Feb 05 20:05:02 once we have a release, do we want to make an ebuild and put it in the tree? (does catylist need it in the tree?) Feb 05 20:05:24 i wouldnt provide an in-tree ebuild Feb 05 20:05:26 npmccallum: it's going to be quite some time before we can interact with catalyst Feb 05 20:05:26 is the arch-tempelates going to be DTD's? i think it be neat Feb 05 20:05:31 at this point or any time soonish Feb 05 20:05:39 karltk: should be able to install, so they could generate a profile with the front-end to use remotely Feb 05 20:05:59 ok. no ebuild, snapshots in /experiemental? Feb 05 20:06:14 enriQUE_: we'll get to Q&A in a moment, i promise :) Feb 05 20:06:17 spy|lab: that's probably a good idea when we have a semi-stable interactive front-end Feb 05 20:06:27 esammer: let me know before you want to distribute the first snapshot, so I can set up a proper directory structure, etc. Feb 05 20:06:36 ah, pardon me... Feb 05 20:06:38 klieber: sounds good. Feb 05 20:06:41 enriQUE_: no worries Feb 05 20:06:55 for now, I'd like for us to aim for making the release accessible to the people directly interested the projet, and not all-and-sundry users Feb 05 20:07:54 ok - so /experimental or d.g.o? Feb 05 20:08:00 initially Feb 05 20:08:29 klieber: you're infra, why don't you make the call. Feb 05 20:08:32 agreed Feb 05 20:08:40 either is fine; we need a place in /experimental eventually. Feb 05 20:08:52 experimental then Feb 05 20:09:07 /exp it is Feb 05 20:09:46 i'm going to turn this back to tseng (who can open it to Q&A) because i'm tired of typing like crazy Feb 05 20:10:10 (someone wake up tseng) :) Feb 05 20:10:22 tseng: cookies! Feb 05 20:10:37 ok. i'll open it up to Q&A. :) Feb 05 20:10:43 he's in #gentoo-dev Feb 05 20:10:52 --> bion (~bion@nat.resnet.ltu.edu) has joined #gentoo-installer Feb 05 20:11:03 First: my apologies for being eager and abrupting in the team meating :"> Feb 05 20:11:09 enriQUE_: no problem. :) Feb 05 20:11:30 Secondly my question was: is the arch-tempelates going to be DTD's? I think it'd be neat (being an webstandards- and GUI/UI-enthusiast) Feb 05 20:11:53 HI! Feb 05 20:11:56 enriQUE_: there will be DTDs for all XML files (install profiles and arch templates) so documents can be vaidated properly Feb 05 20:12:01 tseng: :) Feb 05 20:12:10 i guess its open now :) Feb 05 20:12:11 validated, even Feb 05 20:12:16 ill eat my cookies Feb 05 20:12:28 enriQUE_: we'll probably also write a semantic validator, for the cases possible. Feb 05 20:13:18 --> roger55 (~roger@dsl-243-200.utaonline.at) has joined #gentoo-installer Feb 05 20:13:42 --> [dx]anti (~russ@164.109.8.241) has joined #gentoo-installer Feb 05 20:13:43 reason being of course that I'd like to be able to contribute, though just being an simple webcoder :P Feb 05 20:14:06 ok to ask next question? Feb 05 20:14:13 danarmak: shoot Feb 05 20:14:22 enriQUE_: i don't see a problem there. Feb 05 20:14:22 enriQUE_: hang around here and you'll find plenty of work:) Feb 05 20:14:28 well, i'd like to raise the issue of l10n :-) Feb 05 20:14:51 we've discussed this before but now there's a much bigger audience so perhaps some more questions will get answered by knowledgeable people. Feb 05 20:15:07 are installer frontends to have l10n (localization - display of text in various languages)? Feb 05 20:15:14 danarmak: _yes_ Feb 05 20:15:16 danarmak: yes. Feb 05 20:15:23 ok, i know that part :-) Feb 05 20:15:29 <[dx]anti> danarmak, _("yes") Feb 05 20:15:40 how it will be handled is more an implementation issue, i think. Feb 05 20:15:41 i wanted to present the issue for those who weren't here before; will try to make shorter Feb 05 20:15:42 anti: lol Feb 05 20:15:48 danarmak: i'm a little confused about l10n, i18n and UTF-8 ... do you have any resources you could point me and anyone else at? Feb 05 20:16:13 spy|lab: you forgot m17n:) Feb 05 20:16:20 karltk: i can't forget something i didn't know Feb 05 20:16:39 oh, i want to push a11y on this Feb 05 20:16:40 anyway, the more interesting thing is how much/well frontends can share translations; Feb 05 20:17:06 does anyone know the possibilities of l10n for a console FE Feb 05 20:17:09 danarmak: i believe gettext handles most of the string database stuff. we can use something like that. Feb 05 20:17:23 and which frontend library we'd best use for it with that in view, even if we don't engage in l10n right away. Feb 05 20:17:25 danarmak, i believe redhat has utf8 console Feb 05 20:17:32 <[dx]anti> Just joined here, don't know much about the project really. Are the goals of GLI to be good Desktop / Home User installer, or also include kick start like functionality, remote and bulk installation? Feb 05 20:17:36 but i have no details Feb 05 20:17:40 tseng: and does it just work? i haven't tried so.... Feb 05 20:17:48 danarmak: the technical details are at best skimpy atm. the gtk+ and qt frontends a fairly trivial; both gtk+2 and qt have very good i18n support that's well-documented. Feb 05 20:17:48 [dx]anti: go to the homepage, read the docs before you ask anything else =P Feb 05 20:18:04 karltk: right. Feb 05 20:18:29 danarmak: however, you cannot expect to have the same strings in the textmode ui as the graphical ui. Feb 05 20:18:32 <[dx]anti> spy|lab, ah yes :) Feb 05 20:18:32 danarmak: i only know it exists in some form, tbh.. Feb 05 20:18:34 the issue is basically, although we perhaps won't be implementing it right away, how much we need to plan ahead when designing the first FE(s) Feb 05 20:19:03 a11y is also an issue, but someone else should talk about that, i don't know anything. Feb 05 20:19:03 danarmak: so there will not be a 100% overlap of the localisable text present in the textmode and the graphical mode frontends. Feb 05 20:19:24 danarmak: being that there will be many FEs designed for different purposes (web interface, Desktop, Newbie install, etc) they probably won't share much text at all Feb 05 20:19:33 plop Feb 05 20:19:35 there are a number of provisions for l10n and text databases. i don't foresee a problem here. Feb 05 20:19:50 esammer: the only problems are with display, not storage Feb 05 20:19:55 afaik anyway Feb 05 20:20:10 look fex at how kde does things: Feb 05 20:20:17 danarmak: well, i know it can be done and that's all that's really important right now. Feb 05 20:20:31 when using l10n for hebrew, which is right-to-left, it also reverses the direction of widgets like trees... Feb 05 20:20:38 so just an idea to think over :-) thanks. Feb 05 20:21:12 danarmak: absolutely. we will certainly support as many languages as humanly possible with as many UIs as possible. Feb 05 20:21:14 widgets are a long way away, we need API first Feb 05 20:21:14 So this is GLIS-based or are you actually going to recreate what I already started? Feb 05 20:21:16 danarmak: we'll obviously have to recruit some i18n guys; I know graphical mode is easy enough, but is there a hebrew console?;) Feb 05 20:21:34 Luke-Jr: we'll reuse all the good ideas. Feb 05 20:21:45 Luke-Jr: check out the design doc and others on the homepage in topic Feb 05 20:21:48 Luke-Jr, we aren't reusing code however Feb 05 20:21:51 spy|lab: I did. Feb 05 20:21:57 karltk: there's a good english+hebrew console via hebrew<->ascii mapping. i've never seen a unicode console, or a unicode console font. Feb 05 20:22:08 Luke-Jr: but as we have different requirements than what GLIS did, we can't reuse much code. Feb 05 20:23:01 karltk: Mine wasn't GLIS-based nor compatible. Feb 05 20:23:07 nor usable Feb 05 20:23:08 but anyway Feb 05 20:23:12 danarmak: ok. well, I can't tell you more than that we really want this to be handled well, but that we'll have to do an initial prototype on the basic stuff first. we may then do a new prototype (or several) on how to i18n the beast:) Feb 05 20:23:26 klieber: Nor is any project usable until it reaches a certain stage Feb 05 20:23:42 Luke-Jr, klieber: can you please save your arguments for a different time or forum Feb 05 20:23:59 Luke-Jr: we've mostly abandonded the code from the nine previous installer attempts. Feb 05 20:24:56 Luke-Jr: since you read the design docs, and I don't have cvs on this box I'm at currently, do you know if there are pieces of your installer project that would be reusable in GLI? Feb 05 20:24:58 karltk: Based on the docs, it looks like you could possibly be rewriting the one I am working on. Feb 05 20:25:09 is this going to be another "failed" attempt? Feb 05 20:25:24 shouldn't everyone interrested actually be involved? Feb 05 20:25:42 * karltk has to leave now. Feb 05 20:25:44 thats an odd question Feb 05 20:25:50 bye karltk Feb 05 20:25:55 are there any other questions? Feb 05 20:26:02 no, we dont expect this attempt to fail, certainly Feb 05 20:26:03 karltk: I was using stdin/out between 2 processes as an API. It's possible that the GUIs could be merged to use either API. Feb 05 20:26:04 esammer: will you write up the log and post it to -installer? Feb 05 20:26:09 karltk: yes Feb 05 20:26:13 Luke-Jr: where does it live? Feb 05 20:26:22 bion: we've recruited developers from the 3 successful installer projects to lend ideas/expertise Feb 05 20:26:28 karltk: ATM, on my PC. Feb 05 20:26:37 karltk: or in the gentoo CVS Attic Feb 05 20:26:51 Luke-Jr: can you mail a snapshot to karltk@gentoo.org, (don't use outlook, or it'll go do /dev/null;) Feb 05 20:27:13 <-- Luke-Jr has quit (Client Quit) Feb 05 20:27:15 tseng: this is going to be xml based? Feb 05 20:27:24 karltk: thats quite offensive :) Feb 05 20:27:26 --> Luke-Jr (~luke-jr@198.248.39.176) has joined #gentoo-installer Feb 05 20:27:26 bion: a bit, its fairly well outlined in the doc Feb 05 20:27:45 johnm: the only outlook mails with attachments I get are virii anyway. Feb 05 20:27:52 i have read the doc Feb 05 20:28:41 karltk: http://www.gentoo.org/cgi-bin/viewcvs.cgi/users/luke-jr/ingen/?cvsroot=gentoo Feb 05 20:28:45 karltk: k, but when using be sure you're in a chroot unless you've commented out some code. it does attempt to do part of the install. Feb 05 20:28:59