The meeting had reports on lmza and issues with liveusb building. The haskell and moblin spin proposals were discussed and some questions generated, but voting was deferred. Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-12-28/fedora-meeting... Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-12-28/fedora-meeting... Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-12-28/fedora-meeting...

On Mon, Dec 28, 2009 at 22:58:23 +0000,  Peter Robinson <pbrobinson(a)gmail.com&gt; wrote: > > 1) The reason for the new fedora-mini*.ks files is to slim down the > build. The difference between that and using a standard desktop one is > about 150 meg on a live CD the last time I tested it and when the > Moblin livecd is currently 400 meg that's quite a difference. I've > been working to and planning to work further to get the changes merged > in upstream. There are a number of bugs filed already and in Jan when > I have some more time I'll be following it up with other stuff. Do you think it might be better to remove more stuff from live-base and add it back in to live-desktop where needed? And remove the need for a fedora-mini-base.ks? Or perhaps if the mini ks is still desireable, to base it over of live-base instead of starting from scratch. This would probably help with maintenance down the road.

> 2) The mesa-dri-drivers-experimental is needed for 3D on ATI based > cards otherwise the Moblin interace is unusable with those devices (15 > seconds + to activate a menu) but with luck that should be obsolete > for F-13 That's pretty much what we figured, but there should probably be a deadline where if the graphics supoort is ready, the official spin gets pushed to F14 instead of F13.

> other small devices such as scanners, perl, etc. I originally started > with a fedora-desktop-base file and had about 4 or 5 pages of -blah so > I figured it was going to be easier and neater to start with nothing > and then add what I needed. I've had quite a bit of interest in it > from various areas. The issue with that approach is that if some change is made to add a feature to live-base it isn't going to get included in the mini ks. It might be safer to maintain a long subtraction list.

On Mon, Dec 28, 2009 at 11:08 PM, Bruno Wolff III <bruno(a)wolff.to&gt; wrote: > On Mon, Dec 28, 2009 at 22:58:23 +0000, > Peter Robinson <pbrobinson(a)gmail.com&gt; wrote: >> >> 1) The reason for the new fedora-mini*.ks files is to slim down the >> build. The difference between that and using a standard desktop one is >> about 150 meg on a live CD the last time I tested it and when the >> Moblin livecd is currently 400 meg that's quite a difference. I've >> been working to and planning to work further to get the changes merged >> in upstream. There are a number of bugs filed already and in Jan when >> I have some more time I'll be following it up with other stuff. > > Do you think it might be better to remove more stuff from live-base and > add it back in to live-desktop where needed? And remove the need for > a fedora-mini-base.ks? Or perhaps if the mini ks is still desireable, > to base it over of live-base instead of starting from scratch. This would > probably help with maintenance down the road. I think its 6 to one, half a dozen to the other. I think the desire is still there. By slimming the base and moving it out to the individual desktop .ks files you could be adding duplication and complexity unnecessarily there. I think in the short term from the rather big investigation it will be easier to have a separate one.

Ultimately the work has to be done somewhere. Sometimes by trying to merge it all together you just end up with more of a mess and creating more issues and more work for more people than by having two separate ones and comparing them on occasion. In the not too distant future I suspect there will be more than just Netbooks. At the very least there will be a sugar one as its covers a lot of the ground that Moblin does. There's likely also to be a MID one and support for secondary arch devices too. There's nothing to say it can't disappear in the future. >> 2) The mesa-dri-drivers-experimental is needed for 3D on ATI based >> cards otherwise the Moblin interace is unusable with those devices (15 >> seconds + to activate a menu) but with luck that should be obsolete >> for F-13 > > That's pretty much what we figured, but there should probably be a deadline > where if the graphics supoort is ready, the official spin gets pushed to > F14 instead of F13. Well that would be a question for the X guys not a mere user environment guy like me :-)

>> other small devices such as scanners, perl, etc. I originally started >> with a fedora-desktop-base file and had about 4 or 5 pages of -blah so >> I figured it was going to be easier and neater to start with nothing >> and then add what I needed. I've had quite a bit of interest in it >> from various areas. > > The issue with that approach is that if some change is made to add a > feature to live-base it isn't going to get included in the mini ks. > It might be safer to maintain a long subtraction list. On the flip side of that argument its quite likely also that a feature is added that we don't want and we then have to strip it out in other .ks files adding more work possibly across multiple .ks files or multiple levels of ks files. I'm not sure what the allergic reaction to another -base.ks file is that I'm quite happy to maintain and get rid of if necessary.

>> I think its 6 to one, half a dozen to the other. I think the desire is >> still there. By slimming the base and moving it out to the individual >> desktop .ks files you could be adding duplication and complexity >> unnecessarily there. I think in the short term from the rather big >> investigation it will be easier to have a separate one. >> > > As far as the desire of stripping down the bare minimums of what a > livecd contains goes, here's my take on the problem; > > If fedora-live-base.ks would just be the bare minimum of packages and > settings and scripts to make a LiveCD as such work (along with it's > features), then there would be no need to strip anything off.

> > Should there be a set of packages that any desktop/foo/bar oriented spin > requires, well, then enter fedora-live-desktop.ks or fedora-live-foo.ks. > > We should always remember though, that even though collaboration on > fedora-live-base.ks is a very beautiful thing, in the end it is about > the spins. > > The maintainers should have ultimate control over the contents of the > spin and so if fedora-live-base.ks puts stuff on there we don't need, > then maybe it has to go (even if that means 5 other spins need to add a > package to their list). > > Should something be removed from a group however, it's up to us to > forward such to the people maintaining comps.xml (which is all of us). All of the above sounds reasonable. I have had it on my list for Jan already to go through it all and see what can be merged, changed, fixed etc (I think I mentioned this to you at FUDCon, but possibly not) so with luck most of the issues might just go away. Unfortunately December has been manic and it hasn't got high enough on the ToDo list yet. >> Well that would be a question for the X guys not a mere user >> environment guy like me :-) >> > > List references to the issue as your dependencies, so that people can > help you track it, and other people can make noise about it at meetings > where show-stoppers for various things are addressed (blocker bugs, etc.). I need to dig deeper on this one and do more testing and find out what the plan is for it from a mainline desktop perspective. >>>> other small devices such as scanners, perl, etc. I originally started >>>> with a fedora-desktop-base file and had about 4 or 5 pages of -blah so >>>> I figured it was going to be easier and neater to start with nothing >>>> and then add what I needed. I've had quite a bit of interest in it >>>> from various areas. >>> >>> The issue with that approach is that if some change is made to add a >>> feature to live-base it isn't going to get included in the mini ks. >>> It might be safer to maintain a long subtraction list. >> >> On the flip side of that argument its quite likely also that a feature >> is added that we don't want and we then have to strip it out in other >> .ks files adding more work possibly across multiple .ks files or >> multiple levels of ks files. I'm not sure what the allergic reaction >> to another -base.ks file is that I'm quite happy to maintain and get >> rid of if necessary. >> > > We would like to make sure that issues that make or break a LiveCD in > general are fixed in one location only. Maybe that means splitting up > fedora-live-base.ks, maybe there's another way.