path: root/installer/meetings/2004/20040205_log.txt

Feb 05 19:00:21 <tseng>	sure, here we go.
Feb 05 19:00:27 <danarmak>	10... 9....\
Feb 05 19:00:35 <tseng>	ill ask that everyone be respectful to the current speaker, im sure this wont be a problem
Feb 05 19:00:36 <johnm>	carpaski: hehe, I actually have an time-source locally synced to some 20 other nodes.
Feb 05 19:00:42 <enriQUE_>	hello guys, hope its ok to lurk around here :)
Feb 05 19:00:51 *	port001 is away: gym
Feb 05 19:00:55 <tseng>	offtopic questions or anyone looking to join up, please hang on until after the meeting
Feb 05 19:01:21 <tseng>	hopefully youve all read the project page, if not, youll probably have no idea what we are talking about :)
Feb 05 19:02:04 <tseng>	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 <tseng>	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 <tseng>	s/it/id
Feb 05 19:03:22 <esammer>	hello all. i'm going to discuss the items in the email i sent to both -installer and -dev
Feb 05 19:03:44 <esammer>	the first of which is our overall design status
Feb 05 19:04:15 <esammer>	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 <esammer>	they are all available from the project page
Feb 05 19:05:02 <esammer>	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 <esammer>	those who are interested should read and comment on them either here or on the -installer list
Feb 05 19:05:56 <tseng>	(after the meeting)
Feb 05 19:06:00 <esammer>	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 <esammer>	this supports the control logic depending on each arch and what we call arch templates
Feb 05 19:06:53 <esammer>	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 <esammer>	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 <esammer>	the front ends are interchangable and contain all UI logic.
Feb 05 19:08:06 <esammer>	front ends will be available for text, ncurses, gtk, qt, SOAP end points - whatever you want
Feb 05 19:08:28 <esammer>	this keeps logic and control separate and makes for easy development / customization
Feb 05 19:08:52 <esammer>	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 <esammer>	of course, there's a lot more to it than that, but the docs will go into greater detail
Feb 05 19:09:48 <esammer>	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 <tseng>	sounds good.
Feb 05 19:10:08 <esammer>	ok. moving along.
Feb 05 19:10:57 <esammer>	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 <esammer>	section 2 of http://www.gentoo.org/proj/en/releng/installer/design.xml lists the big ones
Feb 05 19:11:30 <esammer>	but most of this i covered with the design overview
Feb 05 19:12:31 <esammer>	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 <esammer>	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 <esammer>	moving on (unless i've missed something)
Feb 05 19:13:45 <danarmak>	do you mean we won't discuss l10n today?
Feb 05 19:14:01 <tseng>	discussion is last.
Feb 05 19:14:07 <esammer>	danarmak: the specific implementation, not right now. we can in QA.
Feb 05 19:14:20 <danarmak>	er...
Feb 05 19:14:26 <danarmak>	QA as questions/answers?
Feb 05 19:14:30 <esammer>	yes
Feb 05 19:14:34 <danarmak>	sorry, misunderstood. please continue.
Feb 05 19:14:41 <esammer>	ok.
Feb 05 19:14:51 <esammer>	in terms of publicity, we've been a little quiet.
Feb 05 19:15:07 <esammer>	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 <esammer>	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 <esammer>	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 <esammer>	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 <esammer>	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 <esammer>	hopefully, this prototype shouldn't take too long (2 - 4 weeks, *maybe*)
Feb 05 19:18:30 <esammer>	but i don't want to commit to a date
Feb 05 19:19:10 <esammer>	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 <esammer>	and by full, i mean users and devs (GWN, gentoo.org news, etc.)
Feb 05 19:19:52 <esammer>	tseng: anything else wrt this?
Feb 05 19:20:05 <karltk>	esammer: main web home
Feb 05 19:20:09 <karltk>	esammer: "project pages"
Feb 05 19:20:20 <tseng>	the mailing list and here will be where the action happens
Feb 05 19:20:31 <tseng>	but milestones etc will be made more public
Feb 05 19:20:46 <esammer>	we do have the list and the project pages in place as a beginning for those interested.
Feb 05 19:20:52 <esammer>	right.
Feb 05 19:21:11 <esammer>	anything else?
Feb 05 19:21:24 <tseng>	i dont think.
Feb 05 19:21:42 <esammer>	ok. the initial delegation of tasks.
Feb 05 19:22:11 <esammer>	we already have a few coders, as well as documentation and advisers.
Feb 05 19:22:13 <spy|lab>	i'll sit back and take credit for your hard work.
Feb 05 19:22:20 <esammer>	heh
Feb 05 19:22:50 <esammer>	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 <tseng>	esammer, could you lay out an idea of what needs done breifly
Feb 05 19:23:11 <esammer>	sure.
Feb 05 19:23:13 <tseng>	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 <esammer>	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 <esammer>	design has mostly been a group effort
Feb 05 19:24:40 <esammer>	we need more coders, imo.
Feb 05 19:25:01 <esammer>	we also have danarmak and dams that have been helping
Feb 05 19:25:03 <karltk>	esammer: I don't think the prototype phase is the best period to add coders.
Feb 05 19:25:13 <johnm>	I dont think youll have any problems in that respect, and you need not worry. (sorry please continue)
Feb 05 19:25:30 <karltk>	esammer: most certainly we will need more coders as the initial implementation has stabilised.
Feb 05 19:25:31 <esammer>	karltk: it's possible you're correct. that is something we need to figure out
Feb 05 19:25:41 <esammer>	johnm: i think you're right
Feb 05 19:25:45 <esammer>	right
Feb 05 19:25:47 <tseng>	both very good points.
Feb 05 19:26:12 <esammer>	in case i glazed over it, implementation is python and some shell magic
Feb 05 19:26:38 <tigger^>	esammer: I assume python will be put on the livecd?
Feb 05 19:26:46 <esammer>	tigger^: that's a good question.
Feb 05 19:26:59 <tigger^>	assuming it isn't already, I didn't think it was
Feb 05 19:27:04 <esammer>	there was talk of that or a custom live cd with the stuff needed for the installer
Feb 05 19:27:09 <karltk>	tigger^: how can portage work without python?
Feb 05 19:27:18 <tigger^>	karltk: portage doesn't need to
Feb 05 19:27:25 <pauldv>	tigger^: I don't think it is a big problem to add it
Feb 05 19:27:25 <tigger^>	karltk: portage is in the tarball remember?
Feb 05 19:27:26 <johnm>	tigger^: it isnt. it may also rais ean issue of what UI languages can be used (python hooks)
Feb 05 19:27:30 <iggy>	it is on the livecd's
Feb 05 19:27:30 <danarmak>	portage isn't on the livecd, it's in the stage tarball
Feb 05 19:27:31 <esammer>	karltk: i think python is only in the *stages* not the livecd
Feb 05 19:27:38 <karltk>	tigger^: ah, mea culpa.
Feb 05 19:27:58 <tseng>	this problem will quickly solve itself if we have a finished product and a need for python
Feb 05 19:28:03 <iggy>	I just checked, it is on the livecd's
Feb 05 19:28:04 <tigger^>	pauldv: me neither really, just saying
Feb 05 19:28:12 <esammer>	iggy: python is?
Feb 05 19:28:20 <iggy>	esammer: yes
Feb 05 19:28:21 <johnm>	iggy: thats one less issue.
Feb 05 19:28:26 <spy|lab>	that's odd. wonder why.
Feb 05 19:28:27 <esammer>	ok. that answers that.
Feb 05 19:28:27 <karltk>	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 <iggy>	python2.2 if it matters
Feb 05 19:28:48 <karltk>	iggy: it does. and 2.2 is good enough:)
Feb 05 19:28:55 <johnm>	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 <npmccallum>	we'll also need more modules, but these are all implementation details
Feb 05 19:29:20 <karltk>	npmccallum: actually, it would affect the roadmap.
Feb 05 19:29:41 <esammer>	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 <karltk>	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 <karltk>	if the/the
Feb 05 19:30:26 <esammer>	ok. so this is something that has to be worked on.
Feb 05 19:30:58 <johnm>	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 <npmccallum>	esammer: what are you referring to by "this", coordinating with the releng team?
Feb 05 19:31:49 <esammer>	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 <npmccallum>	esammer: right, I'm just trying to understand what to put on the TODO list :)
Feb 05 19:32:48 <esammer>	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 <spy|lab>	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 <esammer>	spy|lab: yes
Feb 05 19:34:01 <esammer>	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 <esammer>	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 <esammer>	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 <esammer>	is this acceptable?
Feb 05 19:36:34 <--	tigger^ (~rob@smtp.gentoo.org) has left #gentoo-installer
Feb 05 19:36:43 <tseng>	yes.
Feb 05 19:36:50 <esammer>	ok.
Feb 05 19:36:53 <spy|lab>	yep.
Feb 05 19:37:07 <esammer>	release cycles and practices
Feb 05 19:37:22 <pauldv>	esammer: sounds ok to me
Feb 05 19:37:34 <esammer>	are we ok with following a XP style system where we code, test, release every X days?
Feb 05 19:37:47 <esammer>	s/days/<measure of time>/
Feb 05 19:38:12 <tseng>	maybe target that, but also try and put out a decent snapshot?
Feb 05 19:38:22 <tseng>	a little flexible of the time
Feb 05 19:38:29 <esammer>	tseng: right, with snapshots at the end of each cycle
Feb 05 19:38:43 <johnm>	esammer: I prefer the gnome/mozilla style releases. although initially, days->weeks seems quite alright to me.
Feb 05 19:38:46 <danarmak>	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 <esammer>	we can release snapshots if we pass a milestone or something
Feb 05 19:39:05 <karltk>	esammer: yes, xp lends itself extremely well to prototyping projects
Feb 05 19:39:44 <karltk>	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 <spy|lab>	i'd suggest a bimonthly snapshot, say the 15 and 30
Feb 05 19:39:49 <esammer>	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 <esammer>	karltk: that's what i was thinking as well
Feb 05 19:40:06 <spy|lab>	then manual snapshots in addition to that when we feel it'd be useful
Feb 05 19:40:40 <esammer>	as long as each snapshot isn't broken or dangerous, the more often for testing, the better.
Feb 05 19:40:45 <esammer>	imo, that is
Feb 05 19:41:33 <esammer>	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 <esammer>	is this ok?
Feb 05 19:42:04 <karltk>	sounds good to me.
Feb 05 19:42:11 <esammer>	ok.
Feb 05 19:42:25 <pauldv>	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 <esammer>	pauldv: this is true.
Feb 05 19:42:53 <tseng>	before any frontend there has to be a begining of the api
Feb 05 19:43:13 <tseng>	we already discussed starting with the kickstart-style frontend after this is in place
Feb 05 19:43:22 <karltk>	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 <esammer>	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 <pauldv>	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 <tseng>	you need a tiny bit of user intereaction here
Feb 05 19:44:24 <tseng>	for the standalone, which is why that will be first out..
Feb 05 19:45:01 <karltk>	pauldv: exactly.
Feb 05 19:45:02 <esammer>	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 <esammer>	we'll develop each front end as appropriate when the api becomes stable(ish)
Feb 05 19:45:54 <esammer>	although it's probably easier to start with text based UIs
Feb 05 19:46:16 <esammer>	in terms of resources
Feb 05 19:46:34 <esammer>	i think we have everything we need right now - project page, cvs access, lists, irc, etc.
Feb 05 19:46:37 <esammer>	are we missing anything?
Feb 05 19:47:16 <esammer>	i suppose that's a "no." :)
Feb 05 19:47:24 <esammer>	i'll move on then...
Feb 05 19:47:33 <karltk>	yes, a bug repository
Feb 05 19:47:39 <esammer>	karltk: good call.
Feb 05 19:47:41 <klieber>	bugs.g.o?
Feb 05 19:47:58 <esammer>	can we get a product in bz or something similar?
Feb 05 19:48:04 <karltk>	klieber: that's good enough, if we can get our own "module" or whatever it's called in bugzilla:)
Feb 05 19:48:15 <klieber>	I have connections...I'll see what I can do.
Feb 05 19:48:26 <esammer>	klieber: cool. that would be very helpful
Feb 05 19:48:27 <karltk>	klieber: (lol), that's good.
Feb 05 19:48:51 <esammer>	anything else?
Feb 05 19:49:14 <karltk>	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 <esammer>	karltk: sure. that's fine.
Feb 05 19:49:31 <npmccallum>	we don't have a general link to our project page from the "projects" page
Feb 05 19:49:37 <npmccallum>	but that is small
Feb 05 19:49:45 <spy|lab>	that's because it isn't top-level
Feb 05 19:50:09 <karltk>	the desire for a proper project directory on g.o. is a different debate, I think:)
Feb 05 19:50:24 <spy|lab>	where we do need a link is off the releng index, drobbins
Feb 05 19:50:38 <npmccallum>	yeah
Feb 05 19:51:15 <klieber>	ok, small issue with the bugzilla thing...
Feb 05 19:51:18 <esammer>	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 <tseng>	npmccallum: add bugzilla + releng link
Feb 05 19:51:29 <npmccallum>	already done
Feb 05 19:51:32 <tseng>	:)
Feb 05 19:51:35 <esammer>	klieber: what's that?
Feb 05 19:51:39 <klieber>	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 <klieber>	"I can't partition my hard drive. waaahhhh!!!"
Feb 05 19:51:48 <mut3x>	heh
Feb 05 19:52:09 <klieber>	so do you want to have another name?
Feb 05 19:52:16 <npmccallum>	GLI?
Feb 05 19:52:17 <esammer>	ok. is anyone opposed to something like "GLI"
Feb 05 19:52:19 <esammer>	heh
Feb 05 19:52:20 <karltk>	"chickenpoop"
Feb 05 19:52:27 <esammer>	karltk: no.
Feb 05 19:52:33 <esammer>	:)
Feb 05 19:52:35 <tseng>	klieberismydaddy
Feb 05 19:52:41 *	klieber coughs
Feb 05 19:52:46 <klieber>	how about GLI :)
Feb 05 19:52:52 <tseng>	that works too..
Feb 05 19:52:56 <esammer>	klieber: that's fine.
Feb 05 19:52:58 <npmccallum>	GLI it is...
Feb 05 19:52:59 <karltk>	GLI is suitably obscure
Feb 05 19:53:25 <tseng>	then wranglers can move stuff there as needed.
Feb 05 19:53:27 <pauldv>	esammer: please bug seemant about adding the installer subproject as a subproject on the releng project page
Feb 05 19:53:34 <spy|lab>	so obscure that people won't know to file it in that category
Feb 05 19:53:37 <esammer>	pauldv: will do.
Feb 05 19:53:55 <klieber>	spy|lab: there is a one-sentence description as well :P
Feb 05 19:54:26 <spy|lab>	klieber: "File all GLI-related bugs here."
Feb 05 19:54:46 <klieber>	heh
Feb 05 19:54:50 <esammer>	ok - is anyone opposed to regular (if only informal) meetings?
Feb 05 19:55:02 <karltk>	that's probably a good idea.
Feb 05 19:55:08 <esammer>	or should i call them "review points"?
Feb 05 19:55:15 <spy|lab>	weekly?
Feb 05 19:55:19 <esammer>	(as to not offend corporate types)
Feb 05 19:55:40 <esammer>	in terms of frequency, it should probably coincide with coding and snapshots
Feb 05 19:55:43 <esammer>	or testing
Feb 05 19:55:48 <klieber>	do we need meetings?
Feb 05 19:55:53 <klieber>	or just status reports?
Feb 05 19:56:01 <esammer>	klieber: that's why i'm asking
Feb 05 19:56:02 <tseng>	status reports can be on the project page.
Feb 05 19:56:09 <klieber>	I'd suggest status reports.
Feb 05 19:56:14 <tseng>	i dont think we need a meeting again soon..
Feb 05 19:56:20 <karltk>	we must have status reports.
Feb 05 19:56:20 <klieber>	meetings should be ongoing via the mailing list and here.
Feb 05 19:56:23 <klieber>	rather than anything formalized.
Feb 05 19:56:27 <tseng>	right.
Feb 05 19:56:29 <klieber>	(imo)
Feb 05 19:56:29 <npmccallum>	not till we have a prototype
Feb 05 19:56:43 <klieber>	we should have status reports even before then, I would think
Feb 05 19:56:48 <esammer>	ok. no meetings, status reports.
Feb 05 19:57:01 <npmccallum>	meetings after prototype?
Feb 05 19:57:05 <spy|lab>	meetings as necessary, might be a better way to put that =P
Feb 05 19:57:09 <tseng>	ocassionally
Feb 05 19:57:15 <tseng>	what spy said..
Feb 05 19:57:19 <npmccallum>	sounds good to me
Feb 05 19:57:27 <karltk>	ok, I suggest that for now, we have impromptu meetings, or meetings called on -installer.
Feb 05 19:57:29 <esammer>	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 <karltk>	if it turns out that this doesn't work well enough, we can always reconsidre.
Feb 05 19:57:50 <npmccallum>	I'll be here often (IRC)
Feb 05 19:58:15 <karltk>	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 <esammer>	karltk: that's fine. we can figure that out amongst ourselves, i think.
Feb 05 19:58:50 <esammer>	ok...
Feb 05 19:58:53 <esammer>	moving on?
Feb 05 19:59:02 <npmccallum>	frequency of status reports?
Feb 05 19:59:05 <karltk>	esammer: you're at the end of the list. are you wrapping?;P
Feb 05 19:59:08 <npmccallum>	did we cover that?
Feb 05 19:59:21 <pauldv>	esammer: just call a meeting when needed
Feb 05 19:59:21 <tseng>	yeah..
Feb 05 19:59:24 <esammer>	npmccallum: let's say weekly initially
Feb 05 19:59:33 <klieber>	who do you want bug mails to go to?
Feb 05 19:59:40 <karltk>	npmccallum: at least alongside the releases.
Feb 05 19:59:41 <tseng>	um..
Feb 05 19:59:44 <tseng>	gli-bugs@g.o?
Feb 05 19:59:59 <klieber>	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 <npmccallum>	ok
Feb 05 20:00:23 <esammer>	one more thing before we do QA / wrap up - recruitment / getting involved
Feb 05 20:00:49 <esammer>	karltk mentioned that the actual coders we have for the prototype are ok, which is probably true.
Feb 05 20:01:31 <esammer>	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 <pauldv>	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 <esammer>	pauldv: correct, which is why i'm going to go with karltk
Feb 05 20:02:54 <esammer>	i would like to invite everyone here to go over the design docs and comment, though.
Feb 05 20:03:08 <esammer>	we need (constructive) input.
Feb 05 20:03:12 <klieber>	blue!
Feb 05 20:03:14 <klieber>	oh sorry.
Feb 05 20:03:18 <esammer>	yes, yes, blue
Feb 05 20:03:43 <klieber>	has anyone tested the cvs module yet to see if it works?
Feb 05 20:03:52 <esammer>	klieber: i haven't, no.
Feb 05 20:03:54 <klieber>	also, how do you want to distribute tarballs?
Feb 05 20:04:08 <klieber>	we can use /experimental if you'd like
Feb 05 20:04:21 <klieber>	rather than ~esammer
Feb 05 20:04:23 <spy|lab>	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 <karltk>	klieber: that's probably a good idea.
Feb 05 20:04:36 <esammer>	in this instance, would adding an ebuild for snapshots be ok?
Feb 05 20:04:50 <klieber>	if you do that, I'd rather you not pull off of dev, then.
Feb 05 20:04:52 <karltk>	esammer: can people install the installer?
Feb 05 20:04:57 <klieber>	and use /experimental instead
Feb 05 20:05:00 <esammer>	karltk: heh
Feb 05 20:05:02 <npmccallum>	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 <tseng>	i wouldnt provide an in-tree ebuild
Feb 05 20:05:26 <karltk>	npmccallum: it's going to be quite some time before we can interact with catalyst
Feb 05 20:05:26 <enriQUE_>	is the arch-tempelates going to be DTD's? i think it be neat
Feb 05 20:05:31 <tseng>	at this point or any time soonish
Feb 05 20:05:39 <spy|lab>	karltk: should be able to install, so they could generate a profile with the front-end to use remotely
Feb 05 20:05:59 <esammer>	ok. no ebuild, snapshots in /experiemental?
Feb 05 20:06:14 <esammer>	enriQUE_: we'll get to Q&A in a moment, i promise :)
Feb 05 20:06:17 <karltk>	spy|lab: that's probably a good idea when we have a semi-stable interactive front-end
Feb 05 20:06:27 <klieber>	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 <enriQUE_>	ah, pardon me...
Feb 05 20:06:38 <esammer>	klieber: sounds good.
Feb 05 20:06:41 <esammer>	enriQUE_: no worries
Feb 05 20:06:55 <karltk>	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 <esammer>	ok - so /experimental or d.g.o?
Feb 05 20:08:00 <esammer>	initially
Feb 05 20:08:29 <esammer>	klieber: you're infra, why don't you make the call.
Feb 05 20:08:32 <danarmak>	agreed
Feb 05 20:08:40 <karltk>	either is fine; we need a place in /experimental eventually.
Feb 05 20:08:52 <klieber>	experimental then
Feb 05 20:09:07 <esammer>	 /exp it is
Feb 05 20:09:46 <esammer>	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 <esammer>	(someone wake up tseng) :)
Feb 05 20:10:22 <klieber>	tseng: cookies!

Feb 05 20:10:37 <esammer>	ok. i'll open it up to Q&A. :)
Feb 05 20:10:43 <danarmak>	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 <enriQUE_>	First: my apologies for being eager and abrupting in the team meating :">
Feb 05 20:11:09 <esammer>	enriQUE_: no problem. :)
Feb 05 20:11:30 <enriQUE_>	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 <tseng>	HI!
Feb 05 20:11:56 <esammer>	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 <esammer>	tseng: :)
Feb 05 20:12:10 <tseng>	i guess its open now :)
Feb 05 20:12:11 <esammer>	validated, even
Feb 05 20:12:16 <tseng>	ill eat my cookies
Feb 05 20:12:28 <karltk>	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 <enriQUE_>	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 <danarmak>	ok to ask next question?
Feb 05 20:14:13 <esammer>	danarmak: shoot
Feb 05 20:14:22 <esammer>	enriQUE_: i don't see a problem there.
Feb 05 20:14:22 <karltk>	enriQUE_: hang around here and you'll find plenty of work:)
Feb 05 20:14:28 <danarmak>	well, i'd like to raise the issue of l10n :-)
Feb 05 20:14:51 <danarmak>	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 <danarmak>	are installer frontends to have l10n (localization - display of text in various languages)?
Feb 05 20:15:14 <karltk>	danarmak: _yes_
Feb 05 20:15:16 <esammer>	danarmak: yes.
Feb 05 20:15:23 <danarmak>	ok, i know that part :-)
Feb 05 20:15:29 <[dx]anti>	danarmak, _("yes")
Feb 05 20:15:40 <esammer>	how it will be handled is more an implementation issue, i think.
Feb 05 20:15:41 <danarmak>	i wanted to present the issue for those who weren't here before; will try to make shorter
Feb 05 20:15:42 <karltk>	anti: lol
Feb 05 20:15:48 <spy|lab>	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 <karltk>	spy|lab: you forgot m17n:)
Feb 05 20:16:20 <spy|lab>	karltk: i can't forget something i didn't know
Feb 05 20:16:39 <spy|lab>	oh, i want to push a11y on this
Feb 05 20:16:40 <danarmak>	anyway, the more interesting thing is how much/well frontends can share translations;
Feb 05 20:17:06 <danarmak>	does anyone know the possibilities of l10n for a console FE
Feb 05 20:17:09 <esammer>	danarmak: i believe gettext handles most of the string database stuff. we can use something like that.
Feb 05 20:17:23 <danarmak>	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 <tseng>	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 <tseng>	but i have no details
Feb 05 20:17:40 <danarmak>	tseng: and does it just work? i haven't tried so....
Feb 05 20:17:48 <karltk>	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 <spy|lab>	[dx]anti: go to the homepage, read the docs before you ask anything else =P
Feb 05 20:18:04 <danarmak>	karltk: right.
Feb 05 20:18:29 <karltk>	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 <tseng>	danarmak: i only know it exists in some form, tbh..
Feb 05 20:18:34 <danarmak>	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 <danarmak>	a11y is also an issue, but someone else should talk about that, i don't know anything.
Feb 05 20:19:03 <karltk>	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 <npmccallum>	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 <dams>	plop
Feb 05 20:19:35 <esammer>	there are a number of provisions for l10n and text databases. i don't foresee a problem here.
Feb 05 20:19:50 <danarmak>	esammer: the only problems are with display, not storage
Feb 05 20:19:55 <danarmak>	afaik anyway
Feb 05 20:20:10 <danarmak>	look fex at how kde does things:
Feb 05 20:20:17 <esammer>	danarmak: well, i know it can be done and that's all that's really important right now.
Feb 05 20:20:31 <danarmak>	when using l10n for hebrew, which is right-to-left, it also reverses the direction of widgets like trees...
Feb 05 20:20:38 <danarmak>	so just an idea to think over :-) thanks.
Feb 05 20:21:12 <esammer>	danarmak: absolutely. we will certainly support as many languages as humanly possible with as many UIs as possible.
Feb 05 20:21:14 <npmccallum>	widgets are a long way away, we need API first
Feb 05 20:21:14 <Luke-Jr>	So this is GLIS-based or are you actually going to recreate what I already started?
Feb 05 20:21:16 <karltk>	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 <karltk>	Luke-Jr: we'll reuse all the good ideas.
Feb 05 20:21:45 <spy|lab>	Luke-Jr: check out the design doc and others on the homepage in topic
Feb 05 20:21:48 <npmccallum>	Luke-Jr, we aren't reusing code however
Feb 05 20:21:51 <Luke-Jr>	spy|lab: I did.
Feb 05 20:21:57 <danarmak>	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 <karltk>	Luke-Jr: but as we have different requirements than what GLIS did, we can't reuse much code.
Feb 05 20:23:01 <Luke-Jr>	karltk: Mine wasn't GLIS-based nor compatible.
Feb 05 20:23:07 <klieber>	nor usable
Feb 05 20:23:08 <klieber>	but anyway
Feb 05 20:23:12 <karltk>	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 <Luke-Jr>	klieber: Nor is any project usable until it reaches a certain stage
Feb 05 20:23:42 <spy|lab>	Luke-Jr, klieber: can you please save your arguments for a different time or forum
Feb 05 20:23:59 <karltk>	Luke-Jr: we've mostly abandonded the code from the nine previous installer attempts.
Feb 05 20:24:56 <karltk>	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 <Luke-Jr>	karltk: Based on the docs, it looks like you could possibly be rewriting the one I am working on.
Feb 05 20:25:09 <bion>	is this going to be another "failed" attempt?
Feb 05 20:25:24 <bion>	shouldn't everyone interrested actually be involved?
Feb 05 20:25:42 *	karltk has to leave now.
Feb 05 20:25:44 <tseng>	thats an odd question
Feb 05 20:25:50 <spy|lab>	bye karltk
Feb 05 20:25:55 <esammer>	are there any other questions?
Feb 05 20:26:02 <tseng>	no, we dont expect this attempt to fail, certainly
Feb 05 20:26:03 <Luke-Jr>	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 <karltk>	esammer: will you write up the log and post it to -installer?
Feb 05 20:26:09 <esammer>	karltk: yes
Feb 05 20:26:13 <karltk>	Luke-Jr: where does it live?
Feb 05 20:26:22 <tseng>	bion: we've recruited developers from the 3 successful installer projects to lend ideas/expertise
Feb 05 20:26:28 <Luke-Jr>	karltk: ATM, on my PC.
Feb 05 20:26:37 <Luke-Jr>	karltk: or in the gentoo CVS Attic
Feb 05 20:26:51 <karltk>	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 <bion>	tseng: this is going to be xml based?
Feb 05 20:27:24 <johnm>	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 <tseng>	bion: a bit, its fairly well outlined in the doc
Feb 05 20:27:45 <karltk>	johnm: the only outlook mails with attachments I get are virii anyway.
Feb 05 20:27:52 <bion>	i have read the doc
Feb 05 20:28:41 <spy|lab>	karltk: http://www.gentoo.org/cgi-bin/viewcvs.cgi/users/luke-jr/ingen/?cvsroot=gentoo
Feb 05 20:28:45 <Luke-Jr>	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 <karltk>	Luke-Jr: will do
Feb 05 20:29:02 <esammer>	bion: two of the files can be serialized to xml, but i don't think that makes the instaler "xml based"
Feb 05 20:29:02 <karltk>	spy|lab: thx
Feb 05 20:29:05 <tseng>	bion: we are mostly looking at xml for the stored profiles
Feb 05 20:29:27 <johnm>	karltk: i hate how outlook shows pgp signatures as attachments
Feb 05 20:29:34 <bion>	okay, im stupid, and ask questions in stupid ways
Feb 05 20:29:42 <tseng>	nps.
Feb 05 20:29:45 <bion>	the profiles will be stored in xml?
Feb 05 20:29:52 <tseng>	ideally, yes
Feb 05 20:29:58 <esammer>	bion: yes.
Feb 05 20:29:59 <npmccallum>	bion: only if you so desire
Feb 05 20:30:08 <npmccallum>	the profiles don't have to be stored at all
Feb 05 20:30:30 <[dx]anti>	Hmm what about profiles stored in a database?
Feb 05 20:30:32 <bion>	well, i would only use this installer for installing multiple machines easier
Feb 05 20:30:48 <bion>	so i would no doubtidly need to have stored profiles
Feb 05 20:30:49 <esammer>	[dx]anti: probably not. it is way too much overhead for something like this.
Feb 05 20:31:00 <tseng>	[dx]anti: we were looking at profiles stored on rsync
Feb 05 20:31:07 <esammer>	bion: in taht case, yes.
Feb 05 20:31:15 <tseng>	for a server farm deal
Feb 05 20:31:17 <bion>	yes
Feb 05 20:31:21 <esammer>	bion: out of curiousity, does it matter what format the profiles are in?
Feb 05 20:31:27 <[dx]anti>	esammer, Well I'm thinking about the environment which I work in, hundreds of thousands of servers. Right now we have Solaris doing a similar kickstart install and pulls down build info off a database.
Feb 05 20:31:29 <iggy>	is that a no, or a we don't plan on implementing it, but if someone else wants to...
Feb 05 20:31:50 <--	Luke-Jr has quit (Client Quit)
Feb 05 20:31:52 <[dx]anti>	esammer, I've been trying to push my company into supporting Gentoo linux, right now we only support RedHat. But things like this installer and Gentoo Enterprise are starting to raise some eyebrows.
Feb 05 20:31:59 <esammer>	[dx]anti: i'm sure you could customize the installer to do so, yes.
Feb 05 20:32:00 <bion>	no, but xml would make a php frontend(for example) to reload machines through a request system, extremely easy
Feb 05 20:32:15 -->	Luke-Jr (~luke-jr@198.248.39.176) has joined #gentoo-installer
Feb 05 20:32:18 <esammer>	bion: ah, i see.
Feb 05 20:32:25 <esammer>	bion: then consider it easy! :)
Feb 05 20:32:30 <bion>	heh
Feb 05 20:33:34 *	Luke-Jr pokes xchat
Feb 05 20:33:52 <esammer>	[dx]anti: ideally, you'll be able to extend datasources and things like that to work the way you want.
Feb 05 20:34:09 <esammer>	[dx]anti: but i don't see *us* adding support for mysql or postgres, atm, no.
Feb 05 20:35:17 <[dx]anti>	esammer, *us* being gentoo developers?
Feb 05 20:35:17 <klieber>	[dx]anti: in what case would a database be preferred over flat files wrt this project?
Feb 05 20:35:38 <esammer>	[dx]anti: the -installer team, yes.
Feb 05 20:35:41 <klieber>	[dx]anti: unless you're managing *thousands* of profiles, I don't see the added overhead being worth it
Feb 05 20:35:55 <[dx]anti>	klieber, We do heh
Feb 05 20:36:10 <bion>	will the profiles be able to be loaded from any location(local, nfs,.. possibly ftp or http?)
Feb 05 20:36:19 <esammer>	[dx]anti: that said, it's something we'll make possible with subclasses
Feb 05 20:36:24 <[dx]anti>	klieber, I'm just giving my perspective from where I work hehe
Feb 05 20:36:26 <esammer>	bion: yes
Feb 05 20:36:32 <esammer>	bion: http(s), ftp, rsync, etc.
Feb 05 20:36:38 <[dx]anti>	esammer, yeah
Feb 05 20:37:00 <iggy>	klieber: OT is -enterprise on irc anywhere?
Feb 05 20:37:10 <klieber>	it's not enterprise.
Feb 05 20:37:11 <bion>	is the coding underway? or is the project still in design?
Feb 05 20:37:14 <klieber>	#gentoo-server
Feb 05 20:37:25 <esammer>	[dx]anti: now that i think about it, there would be little to stop someone from adding a subclass the profile loader (or whatever) and have it pull from any datasource you'd like.
Feb 05 20:37:54 <esammer>	bion: this meeting marks the end of the super highlevel design and the beginning of prototype work
Feb 05 20:38:10 <bion>	where will the home of the project be in cvs?
Feb 05 20:38:24 <klieber>	gentoo/src/installer
Feb 05 20:38:28 <esammer>	bion: /gentoo/src/installer
Feb 05 20:39:53 <[dx]anti>	So what language, Python I would imagine?
Feb 05 20:39:59 <esammer>	[dx]anti: yes
Feb 05 20:41:05 <johnm>	esammer: i have a small question If I may, but it's kind of off topic in some respects.
Feb 05 20:41:49 <esammer>	johnm: shoot
Feb 05 20:42:49 <enriQUE_>	Anybody having any view on Mozilla/XUl for GUI frontend?
Feb 05 20:42:56 <johnm>	esammer: Can we make the profiles reusable. in the sense that we can run a seperate profile through a seperate module which will configure the bases system only. the reason i say this is because we can have a daemon style frontend running on the boxes once they're rolled out. and if we so desire using a client tool, we can push profiles out to boxes at different times, and it will make appropriate changes
Feb 05 20:43:09 <johnm>	ie: turn a webserver into a mail server, style thin
Feb 05 20:43:32 <johnm>	of course configuration (maybe a file system snapshot style thing) would have to be given as well and thats between server/client mostly.
Feb 05 20:43:36 <esammer>	johnm: ah, you mean to "diff" two profiles and make changes?
Feb 05 20:43:45 <johnm>	very similar yes.
Feb 05 20:43:54 <npmccallum>	enriQUE_, we are not working on GUIs yet because there is no API
Feb 05 20:44:00 <johnm>	so if you have this running on a network of 10,000 boxes and you want to upgrade them all say
Feb 05 20:44:14 <johnm>	or turn 2 or 3 into different "profile" boxes you can do it from a central location.
Feb 05 20:44:17 <johnm>	this is post-install
Feb 05 20:44:41 *	Luke-Jr thinks that would be a Portage interface...
Feb 05 20:44:57 <johnm>	distributing the configs for said boxes is a slightly different issues, but the framework for the installer sounds like it could handle the bulk of this work anyways.
Feb 05 20:45:04 <esammer>	johnm: this was dicussed briefly. klieber was the one who brought it up. i think it's *possible* but may fall outside the scope of the installer. that is more of a system management issue. now, we might extend the installer in that direction at somepoint, but initially, no.
Feb 05 20:45:12 <johnm>	Luke-Jr: that was the original idea i proposed for portage-ng API. but this is semi-related
Feb 05 20:45:45 <johnm>	esammer: thats alright, I'm not speaking as an initial design point. but simply, in case portage-ng never gets anywhere or so on.
Feb 05 20:46:18 <johnm>	esammer: again, i do think you should also concentrate on the portage-ng point i raised a little as well. with it being the next generation of what is essentially the installers most important foundation work.
Feb 05 20:46:24 <klieber>	johnm: what you just described is (if I"m understanding it correctly) largely what cfengine does/can do.  I'm happy to talk that with you offline if you want.
Feb 05 20:46:25 <spy|lab>	esammer: klieber brought that up? i thought it was me. maybe we both did
Feb 05 20:46:25 <esammer>	johnm: personally, i would like to see such management functionality in some application. if the installer 'migrates' that way in terms of features, i won't prevent it, myself.
Feb 05 20:46:34 <johnm>	esammer: although at this stage it's very much theoretical
Feb 05 20:46:38 <esammer>	spy|lab: ok, you too :)
Feb 05 20:46:44 <enriQUE_>	npmccallum: I meant more in a general term. I'm planning to get into how to develop with XUL as an base...
Feb 05 20:46:54 <johnm>	esammer: my thoughts exactly. it just seems like an appropriate framework
Feb 05 20:47:13 <johnm>	klieber: yeah it is quite similar to cfengine in many respects :)
Feb 05 20:47:17 <esammer>	johnm: right.
Feb 05 20:47:27 <johnm>	klieber: and yeah, i wouldn't mind having a word at some point if thats alright,
Feb 05 20:47:48 <johnm>	klieber: I've used it briefly, but never had the numbers to actually try it on
Feb 05 20:48:01 <npmccallum>	enriQUE_, like I said, we won't even start thinking about GUI until there is API
Feb 05 20:48:05 <esammer>	i think what you're talking about is cfengine + package system integration with network topology awareness. it's neat.
Feb 05 20:48:25 <enriQUE_>	npmccallum: oki doki... :)
Feb 05 20:51:00 <esammer>	are there any other questions before i stop logging and close this up "officially?"