diff options
Diffstat (limited to 'installer/meeting-logs/2004/20040912_log.txt')
| -rw-r--r-- | installer/meeting-logs/2004/20040912_log.txt | 364 |
1 files changed, 364 insertions, 0 deletions
diff --git a/installer/meeting-logs/2004/20040912_log.txt b/installer/meeting-logs/2004/20040912_log.txt new file mode 100644 index 0000000..4cef497 --- /dev/null +++ b/installer/meeting-logs/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. |