20:43:22 <dgilmore> #startmeeting 20:43:22 <zodbot> Meeting started Fri Mar 4 20:43:22 2011 UTC. The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:43:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:43:27 <dgilmore> #meetingname releng 20:43:27 <zodbot> The meeting name has been set to 'releng' 20:44:02 * nirik is around. 20:44:10 <dgilmore> abadger1999: tibbs: nirik: notting: spot: Oxf13: ping 20:44:16 * spot is around 20:45:14 <dgilmore> lets give a few secs 20:45:22 <dgilmore> i think it should be a quick one 20:46:31 * abadger1999 in another meeting. Half here. 20:46:39 <dgilmore> #info spot, nirik, dgilmore, abadger1999 here 20:46:44 <dgilmore> #topic Alpha 20:46:53 <dgilmore> so alpha is done and staged 20:46:58 <tibbs> I'm actually here, though I don't usually attend releng meetings. 20:47:07 <dgilmore> i still need to get the torrents ready 20:47:21 <dgilmore> tibbs: i just pinged you since you do scm stuff 20:47:34 <dgilmore> feel free to tell me to bugger off if you want 20:47:55 <tibbs> I'm always in this channel anyway.... 20:48:07 <spot> dgilmore: did jsmith ask you about the background issue? 20:48:13 <dgilmore> spot: he did 20:48:22 <dgilmore> spot: turns out its a bug in gnome3 20:48:25 <spot> dgilmore: are we doing anything to resolve that or just not worrying about it 20:48:26 <dgilmore> we cant set it 20:48:42 <dgilmore> spot: gnome doesnt support us setting it 20:48:52 <dgilmore> the package with the right background is there 20:48:58 * spot wonders if they consider that a bug or a feature. :P 20:49:03 <dgilmore> and background is correct on the other desktops 20:49:07 <dgilmore> indeed 20:49:19 <spot> dgilmore: is there a beta blocker for that? 20:49:33 <dgilmore> spot: not sure i assume jsmith filled one 20:49:45 <spot> jsmith: ping, see above 20:50:04 <dgilmore> but i think that it meets the beta blocker criteria 20:50:32 <dgilmore> spot: i know the F14 alpha printed info about being f13 and wasnt considered a alpha blocker 20:50:39 * spot nods 20:50:58 <dgilmore> other than the slip alpha has gone well 20:51:19 <dgilmore> we have had a massive amount of updates that were waiting on it 20:51:51 <dgilmore> does anyone have any feedback on alpha? 20:53:57 * nirik has nothing. Fly and be free alpha. :) 20:54:17 <dgilmore> :) 20:54:25 <dgilmore> #topic ec2 images 20:54:52 <dgilmore> ok so i made a mistake and checked the ec2 kickstart into the spins-kickstarts git repo 20:55:17 <dgilmore> since thats where we pull all our kickstarts from 20:55:48 <dgilmore> as we have spins defined it doesnt fit 20:56:01 <nirik> yeah, so should we make the install media and other stuff go somewhere else? or expand spin-kickstarts to image-kickstarts or something that has them all? 20:56:02 <dgilmore> and i dont know whats the best way to move forward 20:56:14 <dgilmore> nirik: yeah 20:56:37 <dgilmore> maybe just fedora-kickstarts 20:56:48 <nirik> spins sig is supposed to meet next week, perhaps ask there what they would prefer? 20:57:55 <dgilmore> nirik: i kinda think maybe we need to take it to fesco witha recoomendation that offical kickstarts live in a new location. fedora-kickstarts 20:58:07 <dgilmore> that pulls the spins kickstarts from spins-kickstarts 20:58:15 <dgilmore> and leaves the spins sig to look after spins 20:58:42 <dgilmore> but install kickstarts ec2 other clouds etc either live in fedora-kickstarts 20:58:45 <nirik> so this would be shipped as a package and obsolete spins-kickstarts? 20:58:51 <dgilmore> or are pulled from cloud-kickstarts etc 20:58:52 <notting> wouldn't that mean desktop/kde maintainers would need to commit to two places? 20:58:54 <nirik> or just be seperate? 20:59:31 <dgilmore> notting: i was thinking that they would live in spins-kickstarts 20:59:38 <nirik> there's 2 things here: a) the place things pull from to compose, b) the package end users can install to look at and play with ks files. 20:59:42 <dgilmore> and we setup a automated way to pull into fedora-kickstarts 21:00:08 <nirik> that seems like a lot of duplication... 21:00:49 <dgilmore> nirik: it save duplication of commits 21:00:55 <dgilmore> by mnaintainer 21:01:12 <nirik> well, why not just make spins-kickstarts be all the spins and stay as it is now. 21:01:14 <dgilmore> i havent fully come up witha plan 21:01:28 <nirik> and then make a new fedora-kickstarts that has dvd media + ec2 + whatever in it. 21:01:35 <dgilmore> we could do that 21:01:50 <dgilmore> then when comoosing we need to pull multiple git repos 21:02:03 <nirik> true... is that difficult? 21:02:10 <dgilmore> not really 21:02:11 <notting> seems inefficient 21:02:21 <notting> why not just manage ec2 in spin-kickstarts, get it reviewed there, etc/ 21:02:31 <dgilmore> if we can automate the pulling of the kickstarts and clone once id be happy 21:02:52 <dgilmore> notting: there is no way that it will fit into the spins guidelines as they stand 21:03:06 <nirik> but then the dvd/install media is in there now, and it doesn't either. 21:03:26 <dgilmore> another option is to work with the spins sig and redifne their guidelines 21:04:01 * Southern_Gentlem likes to be able to create an updated livecd on the fly 21:04:16 <dgilmore> Southern_Gentlem: that wouldnt stop at all 21:04:22 <dgilmore> in any senario 21:05:18 <dgilmore> http://fedoraproject.org/wiki/Spins_Guidelines 21:05:24 <dgilmore> thats the spins guidelines 21:05:33 <nirik> so, perhaps we should ask spins sig how we can do this/what method they would prefer... 21:05:39 <nirik> really we can make it work a number of ways. 21:06:31 <dgilmore> anyway im open to ideas on how to move forward 21:06:40 <dgilmore> ec2 was a fedora 14 feature 21:06:49 <dgilmore> the cloud sig composed those images 21:07:16 <dgilmore> they want rel-eng to make them for F-15 21:07:29 <dgilmore> im ok doing so 21:07:39 <dgilmore> we can spin them up in koji like we do livecds 21:07:53 <dgilmore> and i have some code i need to grab that will let them be uploaded 21:08:20 <dgilmore> the current kickstart makes a 10gb image 21:08:40 <nirik> pretty good sized... 21:08:47 <nirik> but of course users don't need to download that. ;) 21:08:52 <dgilmore> right 21:09:04 <dgilmore> it never gets uploaded anywhere users grab it 21:09:12 <dgilmore> we upload it to amazon 21:09:20 <dgilmore> and make it available to users there 21:09:30 <dgilmore> its a minimal install 21:09:44 <dgilmore> but apparently we cant upload a sparse image 21:10:26 <dgilmore> i wanted to bring to everyones attention what happened there 21:10:47 <dgilmore> anything anyone wants to add ? 21:11:23 <dgilmore> ok 21:11:26 <dgilmore> moving on 21:11:34 <dgilmore> #topic next week 21:12:46 <dgilmore> so im flying to australia tomorrow for some family stuff 21:12:57 <dgilmore> I need to make the torrents tonight 21:13:09 <dgilmore> and get the early seeders grab them 21:13:20 <dgilmore> evething is staged for alpha 21:13:21 * nirik can grab them and seed when available. 21:14:23 <dgilmore> ill be around to send the announcement and open the flood gates etc 21:14:49 <dgilmore> but once alpha out ill be unavailable for a few days 21:15:04 <dgilmore> nirik: has agreed to do updates pushes 21:15:22 <dgilmore> can people please help with getting tickets handled 21:15:28 * nirik nods. Can start doing them tomorrow. 21:16:33 <dgilmore> thanks nirik 21:16:39 <dgilmore> ok thats its for that 21:16:44 <dgilmore> i have one more topic 21:16:44 <nirik> I see only torrent tickets and 21:16:52 <nirik> export stuff ticket 21:16:55 <dgilmore> yeah 21:17:01 <dgilmore> torrents illd o tonight 21:17:05 <dgilmore> export we do monday 21:17:29 <dgilmore> #topic self service overrides 21:17:48 <dgilmore> this is something id like to work on once F-15 is done 21:18:14 <dgilmore> what im thinking right now is an option in fedpkg 21:18:21 <dgilmore> fedpkg override 21:18:40 <nirik> ok. There was talk of a web app also, but fedpkg might be easier. 21:18:45 <dgilmore> that would talk to a server that records who requested it for what nvr 21:18:55 <dgilmore> allow them to specifiy a life for the override 21:19:00 <dgilmore> defaulting to 24 hours 21:19:32 <dgilmore> the server would then do the tag in koji 21:19:41 <dgilmore> and at the end of its life untag it 21:19:49 <dgilmore> i could see having a web app for it 21:19:55 <dgilmore> to see the current overrides 21:20:12 <dgilmore> and allow requests, extentions etc 21:20:42 <dgilmore> i just wanted to get the idea out there 21:20:45 <nirik> yeah, sounds nifty. Would this be something good to add to the google summer of code? or you want to do it? ;) 21:20:48 <dgilmore> get feedback etc 21:21:08 <dgilmore> we can put it up as a summer of code project 21:21:14 <dgilmore> i hadent thought of that 21:21:17 <nirik> https://fedoraproject.org/wiki/Summer_coding_ideas_for_2011 21:21:37 <dgilmore> ill add it there 21:21:42 <dgilmore> and offer to eb a mentor 21:21:51 <nirik> of course doesn't mean anyone will take it, but you never know. ;) 21:22:03 <dgilmore> right 21:22:32 <dgilmore> most of the tickets releng gets are override requests 21:22:44 <dgilmore> it will make it easier for users 21:22:55 <nirik> yep. 21:23:16 <dgilmore> we need to get scm branch requests automated 21:23:30 <dgilmore> with a admin checkoff that yep its good to go 21:23:41 <dgilmore> and new brnaches just being automatically created 21:24:28 <nirik> the current script does a pretty good job toward that. ;) 21:24:54 <dgilmore> nirik: right 21:25:41 <dgilmore> nirik: i kinda think id like to get the branch requesting out of bugzilla 21:25:55 <tibbs> New package or just new branches? 21:25:57 <nirik> yeah, thats an option too... 21:26:05 <dgilmore> tibbs: both 21:26:19 <tibbs> New package stuff needs to tie to bugzilla somehow anyway. 21:26:33 <tibbs> But branches shouldn't matter, although it's somewhat convenient for recording acks and such. 21:26:54 <dgilmore> tibbs: what im thinking is a webapp that the requester can check branches, put in the bug number, add cc's etc 21:27:20 <dgilmore> tibbs: we could make it check that the package has the needed bugzilla flags etc 21:27:41 <dgilmore> basically take out the user improvisation in branch requests 21:28:07 <tibbs> To be honest, a simple script could do that (and post the result to the bugzilla ticket for processing). 21:28:27 <tibbs> But sure, if someone's there to write it I'll figure out how to adapt to it. 21:29:09 <dgilmore> tibbs: maybe we just add a script to fedora-packager 21:29:27 <dgilmore> one that creates and submits the request for the user 21:29:41 <tibbs> Sure; that shouldn't be hard. 21:29:44 <abadger1999> dgilmore: We've talked about adding that to the packagedb -- just had time problems with doing it and with tibbs's script, it was no longer as necessary. 21:29:57 <tibbs> Though is there any way to tell that a branch is not yet EOL but isn't accepting new branches? 21:30:13 <dgilmore> abadger1999: :) 21:30:18 <dgilmore> tibbs: i dont think so 21:30:34 <abadger1999> not at this time. 21:30:39 <dgilmore> tibbs: we can work out some way to do that 21:30:41 <tibbs> Because that's one thing I have to hardcode and keep updated. 21:31:03 <dgilmore> tibbs: maybe we can get something from bodhi 21:31:03 <tibbs> But otherwise, sure, the processing script made this easy enough on the admin side that most of us don't care to sink more effort into it. 21:31:22 <tibbs> But making it easier for the packagers would be good. 21:31:28 <dgilmore> since bodhi knows when we start pushing updtaes to dist-f15-updates and not dist-f15 21:33:09 <dgilmore> so we might be able to do that and take away the need to manually update that 21:33:24 <dgilmore> anyways thats all i have 21:33:33 <dgilmore> #topic open floor 21:33:42 <dgilmore> anyone habe anything else to add? 21:34:24 * nirik has nothing off hand. 21:35:14 <dgilmore> ok well i guess ill wrap it up 21:35:31 <dgilmore> closing in 30 if there is nothing else 21:36:11 <dgilmore> #endmeeting