From Fedora Project Wiki
Jun 10 19:59:54 --- kanarip has changed the topic to: Spin SIG Meeting || https://fedoraproject.org/wiki/SIGs/Spins/Agenda#Agenda_for_2008-06-10_18:00_UTC Jun 10 20:00:07 <kanarip> welcome, everyone! Jun 10 20:00:13 <kanarip> who's here? Jun 10 20:00:17 <d3vice> ^AACTION present^A Jun 10 20:00:24 <ChitleshGoorah> ^AACTION is present^A Jun 10 20:00:37 <huff> ^AACTION ^A Jun 10 20:00:55 <lmacken> ^AACTION ^A Jun 10 20:01:03 <kanarip> hmm, i'm looking for jwb to represent rel-eng Jun 10 20:01:06 <kanarip> hold on Jun 10 20:01:32 <jwb> hi Jun 10 20:01:35 <kanarip> there he is ;-) Jun 10 20:01:40 <jwb> sorry i'm late Jun 10 20:01:55 <kanarip> we didn't start yet, just roll-up ;-) Jun 10 20:02:29 <kanarip> so, i've posted a little agenda on -devel and -livecd mailing lists, and it's also in the wiki page in the channel's topic Jun 10 20:02:37 <kanarip> >> https://fedoraproject.org/wiki/SIGs/Spins/Agenda#Agenda_for_2008-06-10_18:00_UTC << Jun 10 20:03:24 <kanarip> i've posted them in no specific order but i think it's better to start with the "how come we miss so many spins in Fedora 9" and "release / compose process" Jun 10 20:04:07 <kanarip> so, with the Fedora 9 release only the Desktop LiveCD and KDE LiveCD made it into the release, while we do have a number of interested people for the other spins as well Jun 10 20:04:21 <ChitleshGoorah> I am for FEL Jun 10 20:04:30 <kanarip> i'm not necessarily looking at what went wrong - something might have just slipped through the cracks... Jun 10 20:04:45 <kanarip> what i am looking for is a way to prevent that from happening *just like that* Jun 10 20:05:13 <kanarip> jwb, i think release engineering is interested in spins joining the alpha/beta release cycle, right? Jun 10 20:05:13 <jwb> for what it's worth, i think it's due in part to the newness of the spins "process" Jun 10 20:05:27 <d3vice> since livecd-tools package install the .ks files, why dont we merge? Jun 10 20:05:28 <jwb> kanarip, that is correct. we'd like to see spins treated as Features Jun 10 20:05:54 <kanarip> jwb, does makes the Beta "Feature Freeze", right? Jun 10 20:06:01 <kanarip> s/does/that/ Jun 10 20:06:18 <kanarip> no more new spins after the Beta freeze is what i'm trying to say Jun 10 20:06:21 <jwb> i believe so Jun 10 20:06:51 <kanarip> that's fair enough Jun 10 20:07:12 <jwb> the interesting part will be if said spins require additional fixes to be included into the "frozen" repos Jun 10 20:07:22 <jwb> but i think that is something we'll have to figure out as we go Jun 10 20:07:44 <kanarip> do we not have a regular tag-as-release process for that during the freezes? Jun 10 20:08:10 <jwb> oh, we do. and for beta it shouldn't be a big deal Jun 10 20:08:26 <jwb> but for RC and final, we get more and more strict on what we take into those Jun 10 20:08:47 <kanarip> right so i think we might just apply the regular "i want/need this included in the release" process Jun 10 20:09:08 <jwb> yep, agreed. and we can address issues as they come up Jun 10 20:09:18 <kanarip> that's cool Jun 10 20:09:28 <kanarip> so more on the release and spin compose process... Jun 10 20:10:12 <kanarip> there's some point where the spin sig need to hand off a couple of kickstarts to release engineering to compose from Jun 10 20:10:37 <kanarip> and then there's the "what is included in the release (mirrored and all that)" and which go to spins.fp.org (only) Jun 10 20:11:14 <jwb> well, part of the reason rel-eng wants to have spins be Features is so that isn't as big of an issue Jun 10 20:11:30 <kanarip> hmm Jun 10 20:11:41 <kanarip> would that mean all finished features would go into the release tree? Jun 10 20:11:42 <jwb> every spin is composed from the Gold repo, which means you can point to the mirrored Gold SRPMs for source obligation Jun 10 20:12:03 <jwb> they should, yes Jun 10 20:12:15 <kanarip> being "the Live/" directory - and thus carried by all mirrors ? Jun 10 20:12:25 <jwb> oh, i see what you are asking Jun 10 20:12:29 <jwb> that i'm not sure of Jun 10 20:12:43 <jwb> was the KDE spin in the Live/ directory for F9? Jun 10 20:12:53 <kanarip> yes Jun 10 20:13:09 <kanarip> there is a process drafted by Jeff Spaleta to determine this-and-that many spins go into Live/ on the mirrors and the others go to spins.fp.o Jun 10 20:13:11 <jwb> interesting Jun 10 20:13:14 <kanarip> lemme dig it up Jun 10 20:13:31 <jwb> does the spins SIG have a big preference as to where things are hosted? Jun 10 20:13:44 <kanarip> https://fedoraproject.org/wiki/JefSpaleta/SpinReleaseProcessAmendments Jun 10 20:13:52 <kanarip> jwb, sorta Jun 10 20:14:05 <kanarip> we're ok with only having a limited number of spins in Live/ Jun 10 20:14:32 <kanarip> we're ok with having most spins as torrents on spins.fp.o (seeded and tracked by fp.o) Jun 10 20:15:10 <kanarip> what we're eager to figure out is how we can accommodate the localized spins ;-) Jun 10 20:15:37 <jwb> heh Jun 10 20:15:47 <kanarip> tracking /and/ master seeding the torrent just has too large a footprint for fp.o Jun 10 20:16:12 <jwb> for localized spins, i think rel-eng would agree that it's too much to host on fp.o Jun 10 20:16:22 <ChitleshGoorah> talking about localized, I don't think that it is useful for FEL as most of the applications are only in english Jun 10 20:16:48 <d3vice> applications can be translated Jun 10 20:16:48 <jwb> ChitleshGoorah, right. this is mostly for localized spins of Live and KDE-Live from my understanding Jun 10 20:16:48 <kanarip> ChitleshGoorah, localization applies to the desktop Jun 10 20:16:55 <ChitleshGoorah> oki Jun 10 20:17:17 <ChitleshGoorah> but in the git, FEL got pt and nl localization Jun 10 20:17:24 <kanarip> yup Jun 10 20:17:32 <kwizart> ! (about localized spin and the %__install_lang feature ) Jun 10 20:17:41 <kanarip> so that the desktop we run these english applications on is localized Jun 10 20:17:58 <kanarip> kwizart Jun 10 20:18:42 <kwizart> are we allowed to use %__install_lang ? for localised spin... i have tested it and it can save around 200Mo if only fr and en are installed for example Jun 10 20:19:18 <kanarip> where does %__install_lang come from? Jun 10 20:19:22 <jwb> %__install_lang is part of kickstart? Jun 10 20:19:23 <kwizart> %pre Jun 10 20:19:24 <kwizart> mkdir -p /etc/rpm Jun 10 20:19:24 <kwizart> echo "%_install_langs en:fr:fr_FR:fr-FR" > /etc/rpm/macros.lang Jun 10 20:19:31 <kwizart> using somethin like this Jun 10 20:19:45 <jwb> kwizart, so where would that be done at? Jun 10 20:19:46 <kanarip> i'm in favor of exploring this until we drop dead Jun 10 20:19:48 <jwb> each package? Jun 10 20:19:56 <kwizart> is is part of %find_lang macros as soon as packages are supportec Jun 10 20:19:57 <kanarip> jwb, once in %pre Jun 10 20:20:04 <kwizart> +d Jun 10 20:20:12 <kanarip> jwb, during compose, that is Jun 10 20:20:19 <jwb> ah Jun 10 20:20:24 <kanarip> right now though i don't think there's any %pre's executed Jun 10 20:20:41 <kanarip> that is; for livecd creation Jun 10 20:21:05 <kanarip> i might be wrong, but like i said, i'm in favor ;-) Jun 10 20:21:20 <kwizart> well i have tested it - and it worked fine... i will send the .ks on the list... but it might be some %include weirdnes Jun 10 20:21:23 <jwb> that sounds interesting Jun 10 20:21:37 <kanarip> kwizart, cool ;-) Jun 10 20:22:27 <kwizart> specially as localised spin requires to have man-pages-fr and others dictionnaries that are deactivated in the %included .ks Jun 10 20:22:29 <d3vice> if i understand right, .iso files will consume a lot of disk space and bandwitdh in fp.org, so what do we do? Jun 10 20:23:08 <kanarip> so, jwb, on the topic of handing off kickstarts and selecting which goes where; we're ok with any number of spins in Live/ and the rest moving to spins.fp.o Jun 10 20:23:15 <kwizart> anyway i will send thoses localized.ks on the ml and suggest some improved localization fo all... Jun 10 20:23:51 <kanarip> d3vice, the .iso files do not necessarily need to live at fp.o Jun 10 20:24:00 <d3vice> ahh, oki Jun 10 20:24:26 <jwb> kanarip, ok good. it will likely stay as it is now, with Live and KDE-Live being hosted on the mirrors, and the rest on spins.fp.o. if one of those spins gets to be quite popular, we can look at hosting it on the mirrors as well Jun 10 20:24:39 <kanarip> a localized spin maintainer or even a maintainer could also be held responsible for seeding the torrent where fp.o only does the tracking... - but that's an entirely new thing to all of us Jun 10 20:25:09 <jwb> yeah, we still need to work out "3rd party hosting of spins" Jun 10 20:26:30 <kanarip> say... if rel-eng composes, generates the .torrent, loads it in a tracker and the product .iso goes to the spin maintainer (with the .torrent) Jun 10 20:26:36 <kanarip> am i missing anything? Jun 10 20:27:11 <jwb> so the .iso and .torrent would be hosted elsewhere and the fp.o tracker would point there? Jun 10 20:27:44 <kanarip> spins.fp.o could have the .torrent, but it wouldn't need to Jun 10 20:28:07 <jwb> i think that's a reasonable approach. i can bring it up at the rel-eng meeting and see what people think Jun 10 20:28:07 <kanarip> and the tracker makes it officially fp.o, so we still have control, the numbers and metrics and statistics... Jun 10 20:28:15 <jwb> right Jun 10 20:28:39 <jwb> one of the concerns might be the extra work generated by a bunch of spins needing to be composed by rel-eng Jun 10 20:28:49 <jwb> we'll see if they have big push backs Jun 10 20:28:51 <d3vice> and the .iso would be served by the .ks maintaner or someone else that wants to help? Jun 10 20:28:54 <kanarip> cool, i'm already excited to know what rel-eng thinks of this approach Jun 10 20:29:18 <kanarip> jwb, right, the amount of work for rel-eng is... tremendous ;-) Jun 10 20:29:25 <jwb> also, it should be noted that testing and QA of spins lies on the spin maintainer. that's probably understood though Jun 10 20:29:44 <kanarip> d3vice, seeded by the localized .ks maintainer, and everyone willing to help, and... the swarm Jun 10 20:29:58 <d3vice> jwb, kanarip, sounds good! Jun 10 20:30:05 <kanarip> jwb, yes, we'll work with QA to determine test cases Jun 10 20:30:14 <jwb> that is good news Jun 10 20:30:26 <kanarip> i like having an upstream for that process ;-) Jun 10 20:30:56 <kanarip> so i think we're fine in that area for now, unless someone else has something to comment? Jun 10 20:31:10 <d3vice> one more quicky Jun 10 20:31:47 <d3vice> spins that link fedora official repos and other 3rd party repos would be ruled out by spins.fp.org ? Jun 10 20:31:47 <kanarip> sure, shoot Jun 10 20:31:57 <kanarip> yes Jun 10 20:31:58 <kwizart> ! Jun 10 20:32:05 <d3vice> ok, just to be sure Jun 10 20:32:19 <kanarip> kwizart? Jun 10 20:32:29 <ChitleshGoorah> +1 Jun 10 20:32:42 <kwizart> how often the spins (either localized or which ones are relevent) can be regenerated? (once by release or more often ?) Jun 10 20:33:08 <kanarip> once by release for every spin that is a feature... "KDE Live", "FEL", "Games" ... Jun 10 20:33:09 <jwb> rel-eng would prefer once per release, at GA time Jun 10 20:33:10 <kwizart> ChitleshGoorah, did you vote for me before knowing what i will say ? Jun 10 20:33:38 <kanarip> localized spins is a work-load issue around GA, so might spread until after GA Jun 10 20:33:45 <ChitleshGoorah> I voted for fedora official repos only Jun 10 20:33:57 <ChitleshGoorah> once by release for every spin +1 Jun 10 20:34:01 <kanarip> that wasn't a vote ChitleshGoorah ;-) Jun 10 20:34:02 <kwizart> okay but we have openssl security issues (maybe also in kernel) Jun 10 20:34:13 <ChitleshGoorah> I mean I agree Jun 10 20:34:32 <kanarip> luckily, live spins are show cases, not continuously running systems Jun 10 20:34:45 <kwizart> and we redistribute them with live spin... (just a thought anyway) Jun 10 20:34:56 <d3vice> kanarip: i like to think we can do a lot more than show cases :) Jun 10 20:34:58 <kwizart> okay eof Jun 10 20:35:08 <kanarip> and if they install, but refuse to yum update, they expose themselves just like they would have without live spins to begin with Jun 10 20:35:37 <kwizart> well updating with yum cosume lot of "persistance" Jun 10 20:35:42 <kanarip> with torrents on spins.fp.o however, we do have a potential of updating spins midst-release cycle Jun 10 20:36:00 <kanarip> i'm not sure though where to draw the line Jun 10 20:36:21 <kwizart> i looking at the livecd-tools commit - we could have persistance on /usr disable ( and only available for /home ) Jun 10 20:36:27 <jwb> there are two big issues with "update" spins Jun 10 20:36:29 <kwizart> disabled Jun 10 20:36:38 <jwb> 1) you have to generate a separate source iso for them Jun 10 20:36:55 <jwb> 2) QA and testing effort is decreased (somewhat) because you aren't using the Gold bits Jun 10 20:37:08 <kanarip> there's 3 too... Jun 10 20:37:12 <kanarip> 3) where does it end? Jun 10 20:37:17 <jwb> ah, that too :) Jun 10 20:37:20 <kanarip> is a serious yum bug bad enough? Jun 10 20:37:53 <kanarip> or do we only update for security exploits? in the kernel? ssl? ekiga? Jun 10 20:38:17 <jwb> it's at that point where i would start pointing people to the Unity project. though i doubt they want to handle update spins for everything Jun 10 20:38:49 <kwizart> does this means that localized redistributed spin later than Gold (using updates) fall into 1 (and thus cannot be redistributed ?) Jun 10 20:39:02 <kanarip> it'd not use updates/ Jun 10 20:39:40 <kwizart> for the f.p version, but what about end-users version ? Jun 10 20:40:14 <kanarip> end-users can just include updates/ Jun 10 20:40:16 <kwizart> or others...that could be in the spin.fedora.org ? Jun 10 20:40:21 <huff> what about a nightly spin? if you want lates and greates use it else use the GOLD tested spin Jun 10 20:40:43 <kanarip> i can do it all Jun 10 20:40:47 <kanarip> in fact, we can do it all Jun 10 20:41:10 <kanarip> if we had the hosting space Jun 10 20:41:18 <kanarip> the processing power, the manpower Jun 10 20:41:34 <kanarip> and we manage to squeeze 36 hours into a day Jun 10 20:41:52 <kanarip> right now though, even releasing updated spins midst-release cycle is too big a burden Jun 10 20:41:59 <kanarip> users however can do what they want Jun 10 20:42:20 <kanarip> that's fair enough, right? Jun 10 20:42:25 <huff> yea just a thought ;) Jun 10 20:42:26 <kwizart> well ok - maybe we could have hald age re-spin for localized livecd like we does for dvd respin... anyway i'm good with Gold only... Jun 10 20:42:40 <kwizart> if it is really asked maybe we could reconsider later... Jun 10 20:42:52 <kanarip> kwizart, that's what i'm thinking ;-) Jun 10 20:43:43 <kanarip> localized spins is similar; it is too big and too much but we might be able to do it anyway Jun 10 20:43:53 <kanarip> but we provide how-to so users can do them themselves Jun 10 20:44:14 <kanarip> and the Germans seemed quite happy with it, so... ;-) Jun 10 20:44:48 <kanarip> so, another topic is the "Drafted policies" that I got little response on Jun 10 20:44:59 <kanarip> those are at http://fedoraproject.org/wiki/SIGs/Spins Jun 10 20:45:11 <ChitleshGoorah> well, just to conclude, I'm the FEL ks maintainer with the help of tnorth Jun 10 20:45:22 <kanarip> some of which need to be renewed now that we know how we are going to align with Rel-Eng Jun 10 20:45:23 <nirik> ^AACTION notes that the Xfce sig meeting should be at 21 UTC... so 2 hours and 15min from now. ;) ^A Jun 10 20:45:38 <kanarip> thanks nirik, my bad ;-) Jun 10 20:45:39 <ChitleshGoorah> but no one "accountable" maintainer, << = me :) Jun 10 20:46:05 <kanarip> i've had word of OK for Games, XFCE and FEL to be composed Jun 10 20:46:14 <kanarip> the Developer Spin however... :/ Jun 10 20:46:27 <kanarip> that'll go into rel-eng's ticket #24 Jun 10 20:47:42 <kanarip> "" Updates to kickstarts are submitted... where? "" Jun 10 20:48:02 <ChitleshGoorah> I'll upload the ks soon on the git Jun 10 20:48:11 <kanarip> there's a point where we as a SIG need to share whatever is in development / to be approved / not yet approved... Jun 10 20:48:26 <ChitleshGoorah> however based on your suggestion, I'm opting for a livecd Jun 10 20:48:28 <ChitleshGoorah> livedvd Jun 10 20:48:45 <kanarip> I think we might use "master" for developments, and branch off for each release Jun 10 20:49:07 <kanarip> that means however that non-approved spin kickstarts go into master as well Jun 10 20:49:31 <kanarip> and they're maintainers or initiators might need access to commit as well Jun 10 20:49:35 <kanarip> any thoughts on that? Jun 10 20:50:39 <d3vice> commit access is easier than sending .ks files to ml :) Jun 10 20:51:00 <jwb> you are using git for your SCM for .ks files? Jun 10 20:51:03 <kanarip> gheghe, i could request the Infrastructure team changes the default branch each time we release ;-)) Jun 10 20:51:25 <kanarip> jwb, hell yeah, and we use automake foo to create RPMs Jun 10 20:51:57 <kanarip> ;-) Jun 10 20:52:18 <jwb> if you are using git, then you can use it as the kernel project does. have one (or a small set) of "leaders" that can pull into the official repository Jun 10 20:52:25 <jwb> they can also do the tagging/branching Jun 10 20:52:33 <kanarip> hmm Jun 10 20:52:39 <kanarip> how does that work... ? Jun 10 20:53:04 <kanarip> have another more public git tree to have maintainers commit to? Jun 10 20:53:14 <kanarip> or is it just a branch authorization thing? Jun 10 20:53:50 <jwb> no... Jun 10 20:54:03 <jwb> you have one tree, on fedorahosted.org i assume? Jun 10 20:54:09 <kanarip> yes Jun 10 20:54:40 <ChitleshGoorah> I think one is enough for about 8 spins + its localisations Jun 10 20:54:53 <jwb> ok. then when a maintainer has a new or updated .ks file, they can send an email asking you to pull from their repo to pick it up Jun 10 20:55:11 <jwb> or you could just use git like CVS, which works too Jun 10 20:55:35 <jwb> you just have to hand more people the "keys" to the repo if you want to use it as a central repository like CVS Jun 10 20:56:19 <kanarip> right, having me pull off another tree makes the maintainer needs a git tree published somewhere... and i don't think many off them can without requesting a tree at fedorahosted.org ;-) Jun 10 20:56:39 <kanarip> i think i'm fine with giving people commit access Jun 10 20:57:09 <kanarip> not often have i seen it go wrong and since i'm a work- or hobbyaholic anyway there's always someone watching Jun 10 20:58:19 <kanarip> so, one piece of advise to the spin maintainers / initiators; thou shall request commit access at https://admin.fedoraproject.org/accounts/group/view/gitspin-kickstarts Jun 10 20:59:37 <kanarip> then there is... https://bugzilla.redhat.com/show_bug.cgi?id=448072 Jun 10 20:59:39 <bugbot_> Bug 448072: medium, medium, ---, Jason Tibbitts, ASSIGNED , Review Request: spin-kickstarts - Kickstarts and templates for creating custom Fedora Spins Jun 10 20:59:45 <kanarip> ;-) Jun 10 20:59:54 <d3vice> err... dumb question, if my status is approved, does it mean I have commit access? Jun 10 21:00:09 <kanarip> d3vice, yes Jun 10 21:00:17 <d3vice> ohh, ok Jun 10 21:00:25 <d3vice> ^AACTION reads git manual^A Jun 10 21:00:44 <kanarip> d3vice, the .git/config file should have ssh://git.fedorahosted.org/git/spin-kickstarts.git Jun 10 21:00:58 <d3vice> cool, thanks Jun 10 21:01:20 <kanarip> d3vice, if you initially cloned the repository with git clone git://, it'll have the wrong URL in [remote "origin"] in .git/config Jun 10 21:01:37 <d3vice> ok, thanks for the heads up! Jun 10 21:03:04 <kanarip> ok, since we're past the hour already... can we wrap it up or does anyone else have something to add? Jun 10 21:03:54 <huff> I wanted to see if there were any comments on a applinace/minimal fedora spin Jun 10 21:04:14 <d3vice> aos? Jun 10 21:04:20 <huff> yea Jun 10 21:04:45 <kanarip> you could do with less of what is being installed now, i guess Jun 10 21:04:51 <d3vice> i read your mail, i think its interesting Jun 10 21:05:22 <d3vice> i'll follow up on it, we'll keep in touch through the ml Jun 10 21:05:39 <huff> sounds good