Added old installer meeting logs.

3 files changed, 1022 insertions, 0 deletions

diff --git a/installer/meetings/2004/20040205_log.txt b/installer/meetings/2004/20040205_log.txt
new file mode 100644
index 0000000..c91f434
--- /dev/null
+++ b/installer/meetings/2004/20040205_log.txt
@@ -0,0 +1,509 @@
+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?"
diff --git a/installer/meetings/2004/20040715_log.txt b/installer/meetings/2004/20040715_log.txt
new file mode 100644
index 0000000..80f129e
--- /dev/null
+++ b/installer/meetings/2004/20040715_log.txt
@@ -0,0 +1,149 @@
+Jul 15 19:02:04 <homer> [homer@tux]$ date -u
+Jul 15 19:02:04 <homer> Thu Jul  8 19:03:27 UTC 2004
+Jul 15 19:02:11 <homer> :PP
+Jul 15 19:03:25 <cshields> :)
+Jul 15 19:03:36 <cshields> let me track down samyron
+Jul 15 19:04:45 <cshields> who else is around?
+Jul 15 19:04:47 <cshields> esammer?
+Jul 15 19:04:51 <cshields> spyderous?
+Jul 15 19:06:19 ! samyron [~scott@lateralus.ussg.indiana.edu] has joined #gentoo-installer
+Jul 15 19:06:20 <homer> don't worry, i can wait
+Jul 15 19:06:28 <samyron> sorry guys, was in the lab, lost track of time
+Jul 15 19:07:14 <esammer_> pong
+Jul 15 19:08:39 <cshields> esammer_, just a ping on the meeting
+Jul 15 19:08:41 <esammer_> i'm working like crazy at the moment, but i'm here
+Jul 15 19:08:51 <esammer_> cshields: yea, no problem.
+Jul 15 19:09:20 <codeman> i'm lurking at work as well
+Jul 15 19:12:04 <samyron> anyone other than the people who spoke already(homer, esammer_ and codeman), ya here?
+Jul 15 19:13:58 <cshields> so who is in charge of the meeting?
+Jul 15 19:14:20 <esammer_> i believe samyron was the one who called it, correct?
+Jul 15 19:14:22 <samyron> yeah
+Jul 15 19:14:24 <samyron> it was me
+Jul 15 19:14:30 <cshields> you're the man now, dog!
+Jul 15 19:14:41 <esammer_> on the other hand, i think if npm, spy, tseng, and klieber are not here, it might be worth waiting
+Jul 15 19:14:50 <cshields> true..
+Jul 15 19:14:59 <samyron> yeah
+Jul 15 19:15:13 <cshields> klieber is here, you just have to kick him a few times before he squeals
+Jul 15 19:15:18 <esammer_> heh
+Jul 15 19:16:28 <samyron> basically, i want to talk about: What we've done thus far, what needs to get done in the short term, and what long term projects are.
+Jul 15 19:16:45 <samyron> IIRC, there hasn't been a cvs commit in a while
+Jul 15 19:17:47 <esammer_> samyron: yes. where we are is rather simple and what is left to do is also easy to define (relatively speaking)
+Jul 15 19:18:54 <esammer_> we've completed a basic design, implemented profile objects, controller skeleton, utility functions and classes, and done research into some of the more difficult topics such as partitioning.
+Jul 15 19:18:59 <samyron> basically, from what I can see, we're stuck on the partitioning
+Jul 15 19:19:11 <samyron> here is an idea
+Jul 15 19:19:22 <codeman> we can try to work around it
+Jul 15 19:19:26 <samyron> because we're currently 'stuck' on partitioning.. lets back burner it for now. I know it's important
+Jul 15 19:19:27 <samyron> but
+Jul 15 19:19:35 <samyron> we can always partition by hand, then start the installer
+Jul 15 19:19:38 <samyron> not optimal
+Jul 15 19:19:42 <samyron> but it WOULD work for now
+Jul 15 19:19:50 <esammer_> samyron: this is true.
+Jul 15 19:19:51 <codeman> and it would allow us to test other things
+Jul 15 19:19:56 <samyron> codeman: exactly
+Jul 15 19:20:04 <samyron> so basically, let's figure out what else we NEED to do
+Jul 15 19:20:07 <samyron> to get SOMETHING working
+Jul 15 19:20:11 <samyron> w/o the partitioning
+Jul 15 19:20:47 <esammer_> we need to finish the controller with networking setup, routing setup, misc file generation (/etc/hosts, /etc/conf.d/*, etc...)
+Jul 15 19:21:22 <samyron> ok
+Jul 15 19:21:25 <samyron> that's a start
+Jul 15 19:21:37 <samyron> (now there is something to do)
+Jul 15 19:21:52 <samyron> Other things that I consider important: a way to download the profile from a given URI
+Jul 15 19:21:59 <samyron> that should be simple
+Jul 15 19:23:50 <samyron> some sort of profile generator would also be nice, we can probably use "dialog" for that
+Jul 15 19:24:17 <esammer_> right. cshields also was thinking of / working on a php web based profile generator which could be neat.
+Jul 15 19:24:19 <codeman> we can just make  that by hand
+Jul 15 19:24:21 <esammer_> (sorry - phone rang)
+Jul 15 19:24:25 <samyron> no prob
+Jul 15 19:24:28 <esammer_> codeman: or that, yea. :)
+Jul 15 19:24:36 <samyron> codeman: yeah, that's not a problem
+Jul 15 19:24:42 <homer> i can, easily, do a profile generator via web, PHP
+Jul 15 19:24:49 <codeman> it would be nice if someone could throw up a complete sample profile to CVS
+Jul 15 19:24:56 <esammer_> samyron: in short, i agree with what you're saying.
+Jul 15 19:25:11 <esammer_> codeman: that may be good, yes. i can probably work that up.
+Jul 15 19:25:54 <samyron> codeman: alright
+Jul 15 19:26:00 <samyron> codeman: i have a good profile
+Jul 15 19:26:19 <esammer_> samyron: maybe check it in as sample_profile.xml or something
+Jul 15 19:26:29 ! Netsplit niven.freenode.net <-> irc.freenode.net quits: mathiaz
+Jul 15 19:26:29 <samyron> esammer_: alright, not a problem
+Jul 15 19:26:31 ! cshields [~cshields@cshields.developer.gentoo] has quit [Read error: 104 (Connection reset by peer)]
+Jul 15 19:26:46 ! cshields [~cshields@cshields.developer.gentoo] has joined #gentoo-installer
+Jul 15 19:26:52 <cshields> ugh..  sorry
+Jul 15 19:26:57 <esammer_> ;)
+Jul 15 19:27:08 <esammer_>  /kick cshields "Get a real connection, sucka"
+Jul 15 19:27:09 <cshields> esammer, yeah..  I can work up a php interface anytime.
+Jul 15 19:27:19 <codeman> there were a bunch of little mistakes/typos i found when going through the code, who should i send those to?
+Jul 15 19:27:35 <esammer_> codeman: file a bug at bugs.gentoo.org (the GLI module)
+Jul 15 19:27:52 <codeman> i've done that b4.
+Jul 15 19:28:36 <esammer_> :( i haven't been tending to those bugs as i should. ::raises right hand:: i swear to get on the ball abotu those bugs.
+Jul 15 19:28:46 <samyron> hehe
+Jul 15 19:28:53 <samyron> not a huge problem at the moment
+Jul 15 19:29:53 <samyron> at the moment, GLIInstallProfile is pretty much done
+Jul 15 19:29:57 <samyron> except for the partitioning
+Jul 15 19:30:02 <samyron> but we'll get to that when we do
+Jul 15 19:30:16 <samyron> There are a few things in there that might need to be in GLIClientConfiguration
+Jul 15 19:30:24 <samyron> such as set_dns_servers_post
+Jul 15 19:30:33 <samyron> (I might have already taken that out)
+Jul 15 19:31:34 <samyron> We also need something to "drive" the installer
+Jul 15 19:31:48 <samyron> something to open a profile, use it to create a template, etc
+Jul 15 19:31:58 <esammer_> samyron: that should be relatively simple (which was hte idea)
+Jul 15 19:32:13 <samyron> esammer_: yep, definately, but it's still something that needs to be done :-)
+Jul 15 19:32:14 ! cshields [~cshields@cshields.developer.gentoo] has quit [Connection reset by peer]
+Jul 15 19:32:17 <samyron> or at least started
+Jul 15 19:32:19 <esammer_> samyron: yes
+Jul 15 19:32:23 <samyron> so we can start to test various parts of the installer
+Jul 15 19:34:10 <codeman> i have really stupid test scripts i can send to someone to build off of
+Jul 15 19:34:43 ! cshields [~cshields@cshields.developer.gentoo] has joined #gentoo-installer
+Jul 15 19:34:44 <samyron> i'll have quite a bit of time this weekend(my girlfriend is going to be out of town)
+Jul 15 19:34:48 <samyron> so feel free to send me stuff
+Jul 15 19:34:50 <samyron> samyron@gentoo.org
+Jul 15 19:35:29 <codeman> k, will do when i get home tonight
+Jul 15 19:36:49 <samyron> *thinks*
+Jul 15 19:38:37 <samyron> anything anyone want to bring up?
+Jul 15 19:38:38 <samyron> issues?
+Jul 15 19:38:39 <samyron> ideas?
+Jul 15 19:38:42 <samyron> requests?
+Jul 15 19:38:50 <codeman> what else can i do to help?
+Jul 15 19:39:03 ! mathiaz [~mathiaz@207.35.88.98] has joined #gentoo-installer
+Jul 15 19:39:12 <samyron> at this point, anything  you want, if we need it done
+Jul 15 19:39:13 <homer> i want to work with the php profile generator
+Jul 15 19:39:20 <esammer_> unfortunately, i'm too wrapped up in work to really think about it, but i'm quite sure there's other stuff we should discuss... my feeling is more feedback and contributions would be helpful.
+Jul 15 19:39:55 <samyron> homer, codeman: feel free to email me at ANY time to bring up an idea or whatever
+Jul 15 19:39:56 <esammer_> homer: speak with cshields - he was working something out that i'm sure you can get in on
+Jul 15 19:41:31 ! cshields [~cshields@cshields.developer.gentoo] has quit [Read error: 104 (Connection reset by peer)]
+Jul 15 19:41:52 <samyron> cshields is having some trouble with gnomemeeting
+Jul 15 19:44:12 <homer> i need to learn more english :S
+Jul 15 19:44:46 <samyron> it's not that hard :-)
+Jul 15 19:44:47 <samyron> lol
+Jul 15 19:45:04 <samyron> actually, english is a bitch, as i'm learning (and I'm from the USA... studying for the GRE's)
+Jul 15 19:45:26 <codeman> only the chinese do well on the english part of the GREs
+Jul 15 19:45:40 <samyron> yeah, because they memorize all of the words...
+Jul 15 19:45:43 <codeman> they study
+Jul 15 19:45:57 <homer> what is GRE??
+Jul 15 19:46:10 <samyron> graduate record exam... to get into graduate school
+Jul 15 19:49:28 ! mathiaz [~mathiaz@207.35.88.98] has left #gentoo-installer ["Leaving"]
+Jul 15 19:50:18 ! mathiaz [~mathiaz@207.35.88.98] has joined #gentoo-installer
+Jul 15 19:52:30 <samyron> well, this meeting was short, but i think it was a bit productive
+Jul 15 19:52:35 <samyron> know i know what areas need work
+Jul 15 19:52:43 <samyron> and what area we can avoid, for now
+Jul 15 19:53:13 <codeman> how much work does the kernel config need?
+Jul 15 19:53:37 <codeman> iirc, the kernel modules was being a pain
+Jul 15 19:53:47 <homer> yes
+Jul 15 19:54:10 <samyron> codeman: what do you mean?
+Jul 15 19:54:47 <codeman> well i couldn't test it, but it didn't look close to done
+Jul 15 19:57:39 <homer> i will speak with cshields, bye
+Jul 15 19:57:47 <homer> good luck
+Jul 15 19:57:47 ! homer [~homer@173.Red-80-32-161.pooles.rima-tde.net] has quit ["Leaving"]
+Jul 15 19:58:23 <samyron> codeman: test it in what?
+Jul 15 19:59:47 <codeman> my test scripts
+Jul 15 19:59:53 <samyron> ah
+Jul 15 20:05:13 <klieber> sorry I missed the meeting folks.  I had a work meeting that pre-empted it
+Jul 15 20:05:27 <samyron> klieber: no prob
+Jul 15 20:05:35 <samyron> klieber: any ideas, suggestions, requests?
+Jul 15 20:05:39 <klieber> read the backlog -- we can provide hosting stuffs for testing/developing that php profile generator as needed
+Jul 15 20:06:17 <samyron> k
+Jul 15 20:06:17 <klieber> also, we kind of have GSX Server up and running to where we can provide VMWare environments to folks for testing purposes
+Jul 15 20:06:21 <samyron> cool cool
+Jul 15 20:06:36 * samyron was playing w/ the GSX server w/ jrinkovs
+Jul 15 20:06:38 <klieber> samyron: I stress the "kind of" because you need to beat on jrinkovs to get it fully working.
+Jul 15 20:06:55 <samyron> lol
+Jul 15 20:06:56 <samyron> ok
\ No newline at end of file
diff --git a/installer/meetings/2004/20040912_log.txt b/installer/meetings/2004/20040912_log.txt
new file mode 100644
index 0000000..4cef497
--- /dev/null
+++ b/installer/meetings/2004/20040912_log.txt
@@ -0,0 +1,364 @@
+18:22:45<         esammer@> the reason for this meeting is to discuss current status, releng integration efforts, live cd requirements, and a release date
+18:23:14! samyron [scott@uc-bloom-184-200.dmisinetworks.net] has joined #gentoo-installer
+18:23:20<        agaffney > there's one
+18:23:35<         esammer@> samyron: we're starting now
+18:23:38<            zhen > i have to be out by 3:30, so if we could do the releng stuff relatively soon, that would be great
+18:23:43<         samyron > esammer: sorry, lost track of time!
+18:23:48<         esammer@> samyron: no problem
+18:23:55<         esammer@> ok, let's start with releng
+18:24:17<         esammer@> so, zhen and beejay have been lurking around offering help from releng
+18:24:18<         samyron > k]
+18:24:26<            zhen > yup
+18:24:58<         esammer@> the idea is that we should coordinate for the purposes of releases and live cd work.
+18:24:59<            zhen > esammer: would you like me to talk about the integration efforts and livecd requirements?
+18:25:08<         esammer@> zhen: that would be great, yea.
+18:25:11<         codeman > is dialog on the livecd?
+18:25:20<            zhen > codeman: yes, it should be
+18:25:31<            zhen > codeman: and if it is not, we can always add it
+18:25:32<         codeman > k.  i know python is as well
+18:25:41<         esammer@> zhen: also, if you could let us know what releng is aiming for (your perspective) that would be great too.
+18:25:52<            zhen > python is not on the livecd and we would like to keep it that way for size constraints
+18:25:58<            zhen > esammer: sure
+18:26:13<         codeman > i've run python from the universal livecds b4
+18:26:20<         samyron > yeah, python is on 2002.4
+18:26:22<         samyron > er
+18:26:23<         samyron > 2004.2
+18:26:30<            zhen > integration of the installer project should not be difficult
+18:26:48<         esammer@> ok. zhen has the floor, so let's save questions for the end.
+18:26:52<            zhen > if it is packaged up as an ebuild, we should have no problem sticking it on the livecd
+18:27:30<            zhen > we can provide an X LiveCD, standard CLI livecd, and anything else that you need
+18:28:24<            zhen > so to sum it up, releng is flexible to do whatever the installer project requires of us
+18:29:01<            zhen > questions?
+18:29:41<         samyron > zhen: where do you want the installer to start and where would you like it to end.. meaning.. you boot off of the cd.. what "step" should it start at... and what "step" should it end at?
+18:29:44<         esammer@> ok. sounds good. so, live cd requirements are obviously an issue. the only problem i foresee is being able to run teh installer prior to unpacking hte stage.
+18:30:17<         esammer@> (the python issue, i mean)
+18:30:36<            zhen > samyron: up to you folks. depending on how we package our cds, execution time would change
+18:30:39<            zhen > s/change
+18:30:44<         samyron > k
+18:31:01<         codeman > how would you have space for X on a liveCD?
+18:31:01<            zhen > samyron: for example, the minimal cd should probably go to a prompt first because experienced users might pick that one for its small size
+18:31:19<         samyron > sounds good to me
+18:31:23<            zhen > and a universal cd would probably have it start automactically
+18:31:52<         klieber > we also need to support both guided and automatic installations from the liveCD.  We can't just assume everyone wants a guided install
+18:32:10<            zhen > klieber: yup
+18:32:20<         samyron > klieber: already thought of that
+18:32:26<         klieber > samyron: great
+18:32:29<         samyron > klieber: that's pretty much already built into the backend
+18:32:41<            zhen > codeman: we can do kde on the cd in 240 MB :)
+18:32:49<            zhen > and that is w/o our space reductions we are undertaking right now
+18:32:52<         klieber > samyron: true -- I'm just saying the front-end needs to provide a method for selecting which install to use.
+18:33:00<         samyron > ah, ok
+18:33:02<         klieber > including the universal CD
+18:33:12<         samyron > simple enough:-)
+18:33:16<         klieber > graet
+18:33:20<         klieber > great, even.
+18:34:18! hadfield [~hadfield@S0106002018892b9c.vc.shawcable.net] has quit [Remote closed the connection]
+18:34:39<            zhen > any other questions?
+18:34:48<         codeman > how far along would we have to be before converting this project to an ebuild?
+18:34:52<         esammer@> ok, so we need to figure out exactly when and how the installer should be run from teh live cds. the only other thing is that we need to figure out the requirements in terms of libraries and utilities that need to be available for the installer.
+18:35:13! hadfield [~hadfield@S0106002018892b9c.vc.shawcable.net] has joined #gentoo-installer
+18:35:17<         samyron > i propose we do it the 'slackware' way
+18:35:19<         esammer@> we don't have to figure out these things now, but at least we have a point of contact and communication open
+18:35:25<            zhen > yup :)
+18:35:28<         samyron > kick them to a prompt and in the motd, we say "Type 'setup' to run the installer."
+18:35:49<         esammer@> samyron: right. our options are open.
+18:35:50<         variant > I think just typeing "installer" at any point should launch the isntaller
+18:36:06* samyron likes that idea
+18:36:11<         samyron > cause then we can have cmd line options
+18:36:18<         variant > allso a boot prompt for "command line install" or "automated installer"
+18:36:21<       spyderous > that doesn't really work for an automated one, though. maybe it should check for existence of some kickstart-like file
+18:36:22<         codeman > setup/installer/install all should run the installer
+18:36:25<         samyron > installer --config /etc/gliconfig.xml --profile /etc/myprofile.xml
+18:36:34<         klieber > spyderous: yeah, good idea.
+18:36:38<         samyron > very good idea
+18:36:39<         samyron > then
+18:36:45<         esammer@> spyderous: we may need a special live cd for automated installs
+18:36:46<         samyron > we have to *standardize* on a filename/location
+18:37:00<         esammer@> spyderous: something that probes for files or network locations or whatever
+18:37:06<          Method > keep the entrypoint high :) can't boot right into the installer or anything like that
+18:37:07<            zhen > the installer should check for the presence of a usb key or something to grab the config from
+18:37:11<            zhen > or floppy
+18:37:32<       spyderous > the very first thing on it should ask whether you wanna load a kickstart from somewhere
+18:37:41<         klieber > (including network)
+18:37:58<         samyron > klieber: already done:-)
+18:37:58<          Method > erm
+18:38:01<         klieber > although....actually, coudln't that be part of the install?
+18:38:06<          Method > isn't that the only place you can load a kickstart from?
+18:38:10<         klieber > wait...nm
+18:38:24<         klieber > Method: no -- you can store it locally on the install media
+18:38:31<          Method > oh right
+18:38:35<          Method > at which point it shouldn't even ask
+18:38:37<          Method > it should just do it
+18:38:43<         samyron > while i was testing some stuff.. i was having it pull the profile from "https://...../config.xml"
+18:38:55<         klieber > cool
+18:39:00<         samyron > and it was working well
+18:39:05<            zhen > sweet
+18:39:13<         klieber > we could also control some of this via kernel boot params, no?
+18:39:20<         samyron > http(s)|rsync|file are all supported
+18:39:25<         samyron > klieber: good idea
+18:39:27<         klieber > red hat uses that to control init levels, fedx
+18:39:31<         klieber > fex, even...
+18:39:43<          Method > samyron: no tftp? gah, dark ages
+18:39:43<         esammer@> klieber: i was thinking the same
+18:39:53<         samyron > er, ftp too
+18:39:54<         samyron > sorry
+18:39:55<         codeman > like boot:  gentoo automatic-install?
+18:39:56<         samyron > forgot about that one
+18:40:13<         klieber > codeman: that, plus location of the file
+18:40:24<         esammer@> Method: there will be PXE / netboot at some later date which should work with tftp
+18:40:40<            zhen > esammer: has any of your team looked into the knoppix-like installation method of dumping the livecd contents to the HD?
+18:40:48<         codeman > at that point you haven't mounted any devices or network or anything.. there'd be no way to verify the file's existance.
+18:40:57<         esammer@> zhen: we haven't but that is probably a good idea
+18:41:21<            zhen > zhen: that would be a nice and easy feature to implement early 2005
+18:41:27<            zhen > er, esammer rather
+18:41:42<         esammer@> zhen: yep
+18:42:21<         esammer@> ok. is there anything else regarding releng / live cd?
+18:42:32<            zhen > not from my end
+18:42:36<         codeman > what about parted?
+18:42:48* codeman has not checked
+18:42:56<            zhen > what about it?
+18:43:12<         codeman > we use pyparted i think for partitioning stuff at the moment
+18:43:36<         esammer@> codeman: this has been discussed to some degree. parted doesn't work for all archs. it's a bit of a contraversial issue. :)
+18:44:08<         codeman > ah. ok.
+18:44:23<         esammer@> we can talk about that outside of this meeting
+18:44:43<         esammer@> codeman: but it is a valid concern
+18:44:49<         esammer@> anything else folks?
+18:44:59<         klieber > a date?
+18:45:00<         codeman > are we going to need a separate release for each arch?
+18:45:03<         klieber > for the release?
+18:45:51<         esammer@> codeman: hopefully not.
+18:45:51! cokehabit_ [George@dsl-80-43-81-29.access.uk.tiscali.com] has joined #gentoo-installer
+18:45:56<      cokehabit_ > sorry im late
+18:45:56<         esammer@> ok - release date.
+18:46:21<         esammer@> so zhen - when does 2005.0 go "gold?"
+18:46:24<            zhen > well
+18:46:28<            zhen > not sure yet, 2005 is not planned
+18:46:33<            zhen > we have some other stuff to sort out
+18:46:43<         esammer@> zhen: oh. what release were we aiming for?
+18:47:10<            zhen > esammer: anything 2005
+18:47:17<            zhen > after 2004.3 we will plan out 2005
+18:47:22<         klieber > can we just set an internal date for Dec 31st?
+18:47:25<            zhen > we might be changing up release cycles
+18:47:28<         klieber > or is that too agressive?
+18:48:00<         codeman > i'd say Dec 31st for a non-partitioning release?
+18:48:01<         esammer@> well, let's do this - let's talk about status and how far we are from our goals. that should dictate release date and what's feasible.
+18:48:13<         samyron > esammer: good idea
+18:48:39<         klieber > can we talk about the partitioning?  'cause I think that's going to affect the rest of the decision making process.
+18:49:14<           tseng@> also, does the current code exclude adding lvm, raid or whatever
+18:49:25<         esammer@> ok, but quickly as partitioning can turn into an all day discussion if we're not careful.
+18:49:25<           tseng@> at a later date.
+18:49:42<         esammer@> tseng: no. it should be possible to add support for it.
+18:49:52<           tseng@> wonderful.
+18:49:53<         klieber > esammer: specifically, I'd like to suggest that, if we can get an arch-specific installer out sooner, then we should
+18:49:59<        agaffney > was npmccallum's detect_devices.py script ever to the point where it would detect *everything*?
+18:50:21<         esammer@> agaffney: i honestly don't recall. i have the feeling that the answer is no.
+18:50:32<         klieber > i.e. if the hold-up on the partitioning stuff is non-x86 arches, then we should slip that feature to something post 1.0
+18:50:47<        agaffney > looking at the code, it appears it still only detects ide/scsi (and scsi emulating) devices
+18:51:22<         esammer@> klieber: the hold up is non-x86 archs, or more specifically, that it's difficult to handle them all in a generic way.
+18:51:41<         klieber > esammer: then I'd push for making 1.0 x86-specific
+18:51:53<         codeman > there's a lot more besides detecting the devices.  that code works pretty well afaik.
+18:52:02! seemant [~trinity@seemant.developer.gentoo] has joined #gentoo-installer
+18:52:03<         samyron > the good news is that x86 and amd64 = almost identical :-)
+18:52:06<         esammer@> so here are our choices - have an x86 specific installer OR leave out partitioning and have multiple archs
+18:52:15<         klieber > can we do both?
+18:52:24<         samyron > i'm confident that we can
+18:52:27<         klieber > if x86, do partitioning, else fail to manual?
+18:52:42! brad[] [~brad@209.161.229.122] has joined #gentoo-installer
+18:52:52<         samyron > i was thinking about, for the time being, handling partitioning in a 'hack' way
+18:52:53! cokehabit_ is now known as cokehabit
+18:52:55<         samyron > just dump them to cfdisk
+18:53:00<         samyron > cfdisk = pretty easy to use
+18:53:12<           tseng@> id love that
+18:53:18<         esammer@> cfdisk does not work on all archs either
+18:53:19<         codeman > but then you run into the issue of your automatic install all of a sudden sitting at a prompt
+18:53:28<         samyron > esammer: but it works beautifully on x86
+18:53:29<        agaffney > samyron: what about non-CLI installers?
+18:54:04<         klieber > let's not get too mired in the details. Are we comfortable with an x86-specific installer for 1.0?  (with an option of failing to manual partitioning for non-x86?)
+18:54:04<         samyron > agaffney: for the time being, i'm not worried about those as much, there is still a lot left to do on the backend side.. and i know that i don't have any time to spend writing anything not CLI.. unless you want too :-)
+18:54:10<         esammer@> klieber: the problem is after manual, how to get them back to where they left off
+18:54:31<         klieber > esammer: ok, if that's a problem, then I'd say ignore it.  x86 only, period.
+18:54:31<         samyron > esammer: easy
+18:54:36<         klieber > at least until 1.5/2.0
+18:55:00<         codeman > esammer: we have run_bash for that.
+18:55:03<         samyron > esammer: the installer has a 'spawn_bash()' function.. which will dump the user to a bash shell
+18:55:09<         codeman > s/run/spawn
+18:55:11<         samyron > when he/she types 'exit' the installer picks up where it was before
+18:55:20<         esammer@> ok. good.
+18:55:41<         klieber > so, are we OK with that model?
+18:55:57<         esammer@> so that's it - if x86, we'll partition automatically if we can, otherwise to a bash prompt they go
+18:56:04<         klieber > yay
+18:56:17<         codeman > sounds good
+18:57:17<         variant > what other architectures does parted support (if any)?
+18:57:18<         klieber > so, that brings us back to the discussion about dates
+18:57:31<         klieber > variant: I assume it supports amd64
+18:57:31<         esammer@> klieber: no. please, status first.
+18:57:35! cokehabit [George@dsl-80-43-81-29.access.uk.tiscali.com] has left #gentoo-installer ["Leaving"]
+18:57:38<         klieber > esammer: sorry, that's what I meant.
+18:58:31<         esammer@> ok. i'm going to turn this over to samyron and codeman as they've been working on the majority of the core code these days. scott - can you talk about the current status of the code and what's left / unstable?
+18:58:34! brad[] [~brad@209.161.229.122] has quit [Remote closed the connection]
+18:58:34<         codeman > well using my hacked scripts i was able to setup this laptop with only 3 breaks where i had to drop to bash to fix something.
+18:59:03<         codeman > samyron can start w/ the config/controller
+18:59:18* esammer kicks samyron's chair
+18:59:59<         samyron > ok
+19:00:08<         samyron > *clears throat*
+19:00:10! brad[] [~brad@209.161.229.122] has joined #gentoo-installer
+19:00:36<         samyron > the client configuration is what 'configs' the client controller
+19:00:51<         samyron > the client controller is going to provide all of the API to talk to the frontend (which we NEED to talk about)
+19:02:10<         codeman > the client controller basically sets up the network, and all of the stuff that doesn't actually effect the new environment
+19:02:22<         samyron > so far, the controller does the following things: sets up the ftp,http&rsync proxy, loads kernel modules, sets the root password, sets up the networking, and enables ssh(if the user wants), and downloads/cp's the install profile that the user wants
+19:02:44<         samyron > (sorry for that delay, I had to look at the src to remember everything it does :-))
+19:03:03<         samyron > i've done some pretty simple testing, and it seems to be pretty stable thus far
+19:03:24<         codeman > then the FE would execute the start function in the controller, which would call the appropriate arch-template
+19:03:56<         samyron > what's currently not done: the arch templates
+19:03:59<         codeman > and the install would always no matter what be automated from that point on (am i correct in this samyron?)
+19:04:17<         samyron > i'm still not 100% comfortable with how they're being implemented(even though it was my design)
+19:04:21<         samyron > something just doesn't feel right yet
+19:04:30<         samyron > codeman: correct
+19:04:34<         samyron > basically
+19:04:43<         samyron > once the backend starts, it's all automated
+19:04:56<         samyron > the user has no more intervention, UNLESS, the installer runs 'spawn_bash' for some reason
+19:05:11<         samyron > which might happen, due to unimplemented parts of the install, but this is to be avoided AT ALL COSTS
+19:05:52<         samyron > *thinks*
+19:05:55<         samyron > any questions?
+19:06:06<        agaffney > can the client controller part be bypassed?
+19:06:21<        agaffney > for example, if the user is installing in a chroot from within another install?
+19:06:38<         samyron > agaffney: not at the moment, but this can be added
+19:06:39<        agaffney > in that case, you wouldn't want the installer to set up networking, load kernel modules, etc.
+19:06:44<         samyron > agaffney: rather simply
+19:06:48! spyderous_ [~spyderous@spyderous.developer.gentoo] has joined #gentoo-installer
+19:06:49! spyderous [~spyderous@spyderous.developer.gentoo] has quit [Read error: 104 (Connection reset by peer)]
+19:07:00<        agaffney > samyron: just wanted to throw that out there
+19:07:08! spyderous_ is now known as spyderous
+19:07:18<         samyron > agaffney: k, good idea, esp for testing
+19:08:04<         codeman > yup
+19:08:26<         samyron > any other questions?
+19:09:00<         esammer@> samyron: so teh problem is that we need to review the arch template stuff?
+19:09:15<         samyron > yeah.. right now i'm doing something *kinda* hacked
+19:09:21<         samyron > like
+19:09:24<         codeman > samyron: anything specific you don't like?
+19:09:24<         samyron > i have a generic template class
+19:09:40<         samyron > and this provides all methods that aren't arch specific
+19:10:05<         samyron > then, each arch template will be a subclass of this class and define all arch specific methods
+19:10:08<        agaffney > something like Portage's cascaded profiles?
+19:10:08<         samyron > (like partitioning)
+19:10:21<         samyron > agaffney: i have no clue about portage's cascaded profiles :-)
+19:10:29<         samyron > now... this solutions works
+19:10:32<         samyron > and i think it'll work great
+19:10:39<         samyron > does it 'feel' right to you guys?
+19:10:42<         samyron > if so, i'll stick w/ it
+19:10:57<         codeman > hrm
+19:11:10<         esammer@> samyron: so the short answer is that it doesn't seem to be a natural design and needs to be looked at but it does work.
+19:11:12* codeman thinks about how the manual is set up
+19:11:25<        agaffney > samyron: it sounds exactly like Portage's cascaded profiles and if the Portage guys do it, it must be good!
+19:11:38<         samyron > esammer: yeah...
+19:11:45<         samyron > one thing i thought of doing
+19:11:49<         codeman > that structure would be similar to calling an arch template which would grab the generic functions and then do the arch-specific stuff on its own
+19:11:50<         samyron > was creating some sort of 'scripting language'
+19:11:56<         samyron > but i think that'd be more difficult than what it's worth
+19:12:08<           tseng@> ebuilds are scripted
+19:12:08<         esammer@> ok. let's not get into specific details now.
+19:12:11<           tseng@> its bash..
+19:12:15<         samyron > k
+19:12:58<         esammer@> samyron: given what we have and the possibility that it might be reworked, how far from a end to end installer do you feel we are?
+19:13:13<         samyron > well..
+19:13:15<         samyron > minus testing
+19:13:23<         samyron > and a notification system
+19:13:41<         samyron > we are probably about 70% done
+19:13:42<         samyron > meaning
+19:13:49<         samyron > w/ some simple scripts, we'd be able to get an install finished
+19:13:58<         codeman > the majority of the work still is the FE-BE interfacing and notification stuff.
+19:14:14<         esammer@> notifications i can handle in a very short amount of time.
+19:14:17<         samyron > k
+19:14:21<         samyron > output would also be ugly
+19:14:38<         samyron > but i'm not too worried about that
+19:14:54<         samyron > we really are close
+19:15:08<         esammer@> ok. this all sounds good.
+19:15:09<         samyron > and i'm trying my hardest to balance school & work and this installer
+19:15:15<         samyron > so i apologize if my work slows
+19:15:18<         samyron > but it shouldn't stop
+19:15:24<         klieber > would it make sense to have a public beta period, btw?
+19:15:26<         esammer@> samyron: that's understandable
+19:15:28<         klieber > before we stick this on a livecd?
+19:15:33<         esammer@> klieber: yes, i think so
+19:15:47<         codeman > so can we increase our status to mega-super-alpha?
+19:16:01<         esammer@> codeman: officially, i think so.
+19:16:22<         codeman > once we get a scripted complete install i suggest switching to a version # :)
+19:16:44<         codeman > with a bunch of 0's
+19:16:44<        agaffney > 0.0.1-mega-super-alpha :)
+19:16:50<         samyron > lol
+19:16:56<         esammer@> ok. so, the question - can we be tested and working for 2005.0?
+19:17:06* agaffney doesn't think that would be a valid Portage accepted version number...
+19:17:10<         samyron > esammer: i'm pretty confident
+19:17:16<         samyron > esammer: it's really coming down to polishing
+19:17:21<         esammer@> samyron: i am as well. codeman?
+19:17:30<         codeman > we can do it
+19:17:39* codeman is optimistic
+19:17:40<         esammer@> well, i think that says it.
+19:17:42<         samyron > esammer: it's coming down to getting stuff like 'install_cron' put in the arch template
+19:17:47<         samyron > esammer: which i'm sure you know takes about 30 seconds
+19:17:54<         esammer@> samyron: right.
+19:18:04<         codeman > grub is going to be a pain
+19:18:12<         codeman > it isn't too multi-arch friendly
+19:19:05<         esammer@> well, that's a detail we'll work out
+19:19:15<         codeman > i'm just saying it will take time
+19:19:26<         klieber > I'd suggest a staged plan of supporting arches, btw.  x86 (and maybe amd64) first, then add 1-2 more next release, 1-2 more after that, etc.
+19:19:38<         klieber > also, not being supported will probably motivate some of the arch folks to help out and get their arch supported.
+19:19:50<         esammer@> klieber: yes. that is probably a good idea.
+19:19:51<         codeman > oo, i like that
+19:20:13<         esammer@> some things are easier to handle than others. portage masks a lot of difficulty from us.
+19:20:20<         samyron > we're trying to make it as easy as possible for other arch people to help out
+19:20:20<         samyron > meaning
+19:20:32<       spyderous > we might wanna add ppc after amd64, that'd give us a decent coverage of different arch types
+19:20:37<         samyron > all they need to do is fill in a few methods in their arch template
+19:20:41<         samyron > and then it'll be done
+19:21:11<         esammer@> so, let's wrap it up on that note... unless there's any questions (that are not specific implementation details that don't pertain to everyone)
+19:21:40<         klieber > oh, documentation
+19:21:49<         klieber > that's going to be a huge part of making this installer a success
+19:21:56<         klieber > (telling people how to use it)
+19:22:02<         klieber > who's doing it?
+19:22:18<         samyron > no one yet
+19:22:19<         esammer@> a good question.
+19:22:25<         esammer@> a good answer.
+19:22:25<         samyron > we're still changing out mind a lot
+19:22:33<         samyron > and a lot of things aren't definate
+19:22:35<         klieber > samyron: is the XML stuff finalized yet?
+19:22:39<        agaffney > are you talking about API documentation or end-user docs?
+19:22:45<         klieber > agaffney: primarily end-user docs
+19:22:50<         klieber > the API stuff can come later, imo
+19:22:53<         samyron > klieber: getting close
+19:23:00<         klieber > samyron: ok, that's where we can start I suppose.
+19:23:04<         samyron > klieber: k
+19:23:19<         samyron > i guess since i know that... since i did it.. i'll write that documentation
+19:23:25<         klieber > heh
+19:23:33<         samyron > :-)
+19:23:59<         esammer@> so, we'll sucker someone to work on end user docs as things solidify
+19:24:20<         codeman > there were many volunteers we asked to show up to the meeting
+19:24:21<         klieber > I don't want this to end up like webapp-config
+19:24:33<         klieber > i.e. great product, but nobody knows how to use it.
+19:24:47<           tseng@> klieber, the man page isnt that bad
+19:24:54<           tseng@> i figured it out np
+19:25:07<         klieber > tseng: the man page didn't exist last I checked, so at least that's an improvement
+19:25:12* agaffney is scared of webapp-config
+19:25:20<           tseng@> sorry for OT
+19:25:22<         esammer@> ok. on topic or we're done.
+19:25:29* klieber slaps himself
+19:25:31<         esammer@> heh ;)
+19:25:38* agaffney sidesteps
+19:25:50<         samyron > i'll bbiab.. got to do a few things around here
+19:25:54<         klieber > so we're shooting for EOY?
+19:26:00<         samyron > klieber: yessir
+19:26:02<         esammer@> klieber: yep
+19:26:08<           tseng@> exciting.
+19:26:09<         klieber > or do we want to shoot for a public beta by the end of november?
+19:26:31! samyron is now known as samyron|gone
+19:26:54<       spyderous > i've gotta run, unfortunately. enjoy the rest of the meeting.
+19:27:07<         esammer@> spyderous: thanks for coming
+19:27:17<       spyderous > it was my pleasure.
+19:27:25! spyderous [~spyderous@spyderous.developer.gentoo] has quit ["Client exiting"]
+19:27:59<         esammer@> klieber: a public beta would be cool, yea.
+19:28:10<         klieber > can we do that by end of november?
+19:28:10<         esammer@> we'll have to play it by ear, i think.
+19:28:16<         klieber > that's ~3 months
+19:28:23<         esammer@> klieber: i think it's possible, yes.
+19:28:30<         klieber > cool deal neal
+19:29:35<         esammer@> ok folks. thanks for coming. if someone can send a log to the list, i'd appreciate it.