From smooge at gmail.com Fri Dec 1 17:17:23 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 1 Dec 2006 10:17:23 -0700 Subject: fun with naming In-Reply-To: <20061130210922.GA28786@nostromo.devel.redhat.com> References: <1164884721.2584.433.camel@erato.phig.org> <80d7e4090611301304v357ddfb9s3777c3e06488d0c1@mail.gmail.com> <20061130210922.GA28786@nostromo.devel.redhat.com> Message-ID: <80d7e4090612010917u68727c3egbf25333172a33790@mail.gmail.com> On 11/30/06, Bill Nottingham wrote: > Stephen John Smoogen (smooge at gmail.com) said: > > Fedora Sausages [You really don't want to see how its made...] > > Snausages! > Or Vienna... But in speaking about our big guy Zod... http://www.sheldoncomics.com/archive/060313.html http://www.sheldoncomics.com/archive/060314.html http://www.sheldoncomics.com/archive/060315.html http://www.sheldoncomics.com/archive/060316.html http://www.sheldoncomics.com/archive/060317.html http://www.sheldoncomics.com/archive/060318.html http://www.sheldoncomics.com/archive/060319.html http://www.sheldoncomics.com/archive/060320.html http://www.sheldoncomics.com/archive/060321.html http://www.sheldoncomics.com/archive/060322.html http://www.sheldoncomics.com/archive/060323.html And the latest.. http://www.sheldoncomics.com/archive/061129.html http://www.sheldoncomics.com/archive/061130.html http://www.sheldoncomics.com/archive/061201.html -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mspevack at redhat.com Fri Dec 1 18:25:14 2006 From: mspevack at redhat.com (Max Spevack) Date: Fri, 1 Dec 2006 13:25:14 -0500 (EST) Subject: Board meeting today Message-ID: We're having a Board meeting today at 5:00 PM Eastern Time. I don't know that we'll take an entire hour, but we've blocked that much time off. Once again we'll be in #fedora-board giving some summaries of our phone call. Things we'll be talking about today: + Jeremy and Jesse have had some great conversations with different engineering managers in the Westford office. I'll ask Jeremy to fill the Board in on that stuff, and we'll talk about what else needs to happen. + If Jesse is around and wants to jump on to talk about how things are going on the pungi/brew front, that would be great also. + Max will share some of his progress, and explain the things that he'll be focusing on for the next little while, which will be more internal-focused to Red Hat than external, at least for a bit. + Get an update about one of the topics that came out of the Fedora Summit, which is the LiveCD plans. We've been playing around with davidz's latest work, and it's good stuff. Jeremy and David have been talking, hopefully share with the Board some of that. + That's probably it. There's a varied list of action items that have accrued over the last couple of weeks. Max's plan is to knock some of that stuff out next week. -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From sundaram at fedoraproject.org Tue Dec 5 00:50:15 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 05 Dec 2006 06:20:15 +0530 Subject: [fab] Re: Licensing audit for Fedora Extras In-Reply-To: <1162234672.7933.206.camel@dhcp-32-122.ord.redhat.com> References: <45464A8A.6080503@fedoraproject.org> <1162234672.7933.206.camel@dhcp-32-122.ord.redhat.com> Message-ID: <4574C247.4090105@fedoraproject.org> Tom 'spot' Callaway wrote: > On Tue, 2006-10-31 at 00:25 +0530, Rahul Sundaram wrote: >> Hi >> >> We discussed earlier the idea of continuing the Free software licensing >> audit* post Fedora Core 6 release that we completed for Fedora Core >> already on Fedora Extras too just to cross check and make sure we are >> only including 100% Free software. >> >> Spot, are we ready to do this now? >> >> Rahul >> >> >> * http://fedoraproject.org/wiki/FreeSoftwareAnalysis > > I'd like to try and get an Aurora release out first. Is there any reason > this can't wait until December? ... and December arrived. Can we do this now? Rahul From tcallawa at redhat.com Tue Dec 5 00:58:31 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 04 Dec 2006 18:58:31 -0600 Subject: [fab] Re: Licensing audit for Fedora Extras In-Reply-To: <4574C247.4090105@fedoraproject.org> References: <45464A8A.6080503@fedoraproject.org> <1162234672.7933.206.camel@dhcp-32-122.ord.redhat.com> <4574C247.4090105@fedoraproject.org> Message-ID: <1165280311.20269.198.camel@localhost.localdomain> On Tue, 2006-12-05 at 06:20 +0530, Rahul Sundaram wrote: > Tom 'spot' Callaway wrote: > > On Tue, 2006-10-31 at 00:25 +0530, Rahul Sundaram wrote: > >> Hi > >> > >> We discussed earlier the idea of continuing the Free software licensing > >> audit* post Fedora Core 6 release that we completed for Fedora Core > >> already on Fedora Extras too just to cross check and make sure we are > >> only including 100% Free software. > >> > >> Spot, are we ready to do this now? > >> > >> Rahul > >> > >> > >> * http://fedoraproject.org/wiki/FreeSoftwareAnalysis > > > > I'd like to try and get an Aurora release out first. Is there any reason > > this can't wait until December? > > ... and December arrived. Can we do this now? January? :) I hate to keep bumping this out, but the audit (even with help) will take up ALL of my free time, and I really want to get Aurora 3 done (it is taking up all of my free time, except for some Zelda while things are building). The FSF will be there in 2007. ~spot From sundaram at fedoraproject.org Tue Dec 5 00:59:35 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 05 Dec 2006 06:29:35 +0530 Subject: [fab] Re: Licensing audit for Fedora Extras In-Reply-To: <1165280311.20269.198.camel@localhost.localdomain> References: <45464A8A.6080503@fedoraproject.org> <1162234672.7933.206.camel@dhcp-32-122.ord.redhat.com> <4574C247.4090105@fedoraproject.org> <1165280311.20269.198.camel@localhost.localdomain> Message-ID: <4574C477.20903@fedoraproject.org> Tom 'spot' Callaway wrote: > > January? :) > > I hate to keep bumping this out, but the audit (even with help) will > take up ALL of my free time, and I really want to get Aurora 3 done (it > is taking up all of my free time, except for some Zelda while things are > building). > > The FSF will be there in 2007. How about something like a open call to fedora-devel list for a catch the culprit kind of analysis? Since Fedora Extras already had license checks in place for every package review, I dont expect much dirt to show up ;-) We would going through a mass review again of all the current Fedora Core packages for the proposed merge too IIUC. Rahul From blizzard at redhat.com Tue Dec 5 13:57:54 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 05 Dec 2006 08:57:54 -0500 Subject: fun with naming In-Reply-To: <80d7e4090612010917u68727c3egbf25333172a33790@mail.gmail.com> References: <1164884721.2584.433.camel@erato.phig.org> <80d7e4090611301304v357ddfb9s3777c3e06488d0c1@mail.gmail.com> <20061130210922.GA28786@nostromo.devel.redhat.com> <80d7e4090612010917u68727c3egbf25333172a33790@mail.gmail.com> Message-ID: <45757AE2.90107@redhat.com> I really think you guys are over-thinking or over-rationalizing things. Just plan Fedora seems fine to me. People get it, it's not complex, and people generally understand what Fedora is. Of the problems that we have, people not separating Fedora from the Project as a whole doesn't seem to be one of them. --Chris From amaier at redhat.com Tue Dec 5 16:47:40 2006 From: amaier at redhat.com (Alex Maier) Date: Tue, 05 Dec 2006 11:47:40 -0500 Subject: fun with naming In-Reply-To: <45757AE2.90107@redhat.com> References: <1164884721.2584.433.camel@erato.phig.org> <80d7e4090611301304v357ddfb9s3777c3e06488d0c1@mail.gmail.com> <20061130210922.GA28786@nostromo.devel.redhat.com> <80d7e4090612010917u68727c3egbf25333172a33790@mail.gmail.com> <45757AE2.90107@redhat.com> Message-ID: <1165337260.5299.27.camel@localhost.localdomain> +1111 a On Tue, 2006-12-05 at 08:57 -0500, Christopher Blizzard wrote: > I really think you guys are over-thinking or over-rationalizing things. > Just plan Fedora seems fine to me. People get it, it's not complex, > and people generally understand what Fedora is. Of the problems that we > have, people not separating Fedora from the Project as a whole doesn't > seem to be one of them. > > --Chris > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board Alex Maier Red Hat---Sr Marketing Specialist 1801 Varsity Dr, Raleigh, NC 27606, USA Direct: +1 919 754 4004 Mobile: +1 919 455 8330 From smooge at gmail.com Tue Dec 5 19:19:02 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 5 Dec 2006 12:19:02 -0700 Subject: [fab] Re: Licensing audit for Fedora Extras In-Reply-To: <1165280311.20269.198.camel@localhost.localdomain> References: <45464A8A.6080503@fedoraproject.org> <1162234672.7933.206.camel@dhcp-32-122.ord.redhat.com> <4574C247.4090105@fedoraproject.org> <1165280311.20269.198.camel@localhost.localdomain> Message-ID: <80d7e4090612051119v673421f7lb8f07d1b555ad9c6@mail.gmail.com> On 12/4/06, Tom 'spot' Callaway wrote: > On Tue, 2006-12-05 at 06:20 +0530, Rahul Sundaram wrote: > > Tom 'spot' Callaway wrote: > > > On Tue, 2006-10-31 at 00:25 +0530, Rahul Sundaram wrote: > > >> Hi > > >> > > >> We discussed earlier the idea of continuing the Free software licensing > > >> audit* post Fedora Core 6 release that we completed for Fedora Core > > >> already on Fedora Extras too just to cross check and make sure we are > > >> only including 100% Free software. > > >> > > >> Spot, are we ready to do this now? > > >> > > >> Rahul > > >> > > >> > > >> * http://fedoraproject.org/wiki/FreeSoftwareAnalysis > > > > > > I'd like to try and get an Aurora release out first. Is there any reason > > > this can't wait until December? > > > > ... and December arrived. Can we do this now? > > January? :) > > I hate to keep bumping this out, but the audit (even with help) will > take up ALL of my free time, and I really want to get Aurora 3 done (it > is taking up all of my free time, except for some Zelda while things are > building). > Ok then I would say the first thing that needs to be done is a document that goes over how a license audit is done. Nothing fancy, but a list of A) Download src package B) Look at spec file C) Look at sourcecode and make sure license is listed in it. D) Look for any dubious licensed code (say file A says its under MIT and file B says its under Apache and file C says its MyLicense 1.5). Use the following egrep expressions to help in doing this: E) Write up a summary of package viewpoints, and send to XYZ for confirmation. F) Upon getting confirmation, and if you have more questions send to joe_foo at fsf.org G) Profit. > The FSF will be there in 2007. > > ~spot > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From smooge at gmail.com Tue Dec 5 19:24:39 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 5 Dec 2006 12:24:39 -0700 Subject: [fab] Re: Licensing audit for Fedora Extras In-Reply-To: <80d7e4090612051119v673421f7lb8f07d1b555ad9c6@mail.gmail.com> References: <45464A8A.6080503@fedoraproject.org> <1162234672.7933.206.camel@dhcp-32-122.ord.redhat.com> <4574C247.4090105@fedoraproject.org> <1165280311.20269.198.camel@localhost.localdomain> <80d7e4090612051119v673421f7lb8f07d1b555ad9c6@mail.gmail.com> Message-ID: <80d7e4090612051124mf274f9fg25acb6f2fbdbf9f5@mail.gmail.com> On 12/5/06, Stephen John Smoogen wrote: > On 12/4/06, Tom 'spot' Callaway wrote: > > On Tue, 2006-12-05 at 06:20 +0530, Rahul Sundaram wrote: > > > Tom 'spot' Callaway wrote: > > > > On Tue, 2006-10-31 at 00:25 +0530, Rahul Sundaram wrote: > > > >> Hi > > > >> > > > >> We discussed earlier the idea of continuing the Free software licensing > > > >> audit* post Fedora Core 6 release that we completed for Fedora Core > > > >> already on Fedora Extras too just to cross check and make sure we are > > > >> only including 100% Free software. > > > >> > > > >> Spot, are we ready to do this now? > > > >> > > > >> Rahul > > > >> > > > >> > > > >> * http://fedoraproject.org/wiki/FreeSoftwareAnalysis > > > > > > > > I'd like to try and get an Aurora release out first. Is there any reason > > > > this can't wait until December? > > > > > > ... and December arrived. Can we do this now? > > > > January? :) > > > > I hate to keep bumping this out, but the audit (even with help) will > > take up ALL of my free time, and I really want to get Aurora 3 done (it > > is taking up all of my free time, except for some Zelda while things are > > building). > > > > Ok then I would say the first thing that needs to be done is a > document that goes over how a license audit is done. Nothing fancy, > but a list of > > A) Download src package > B) Look at spec file > C) Look at sourcecode and make sure license is listed in it. > D) Look for any dubious licensed code (say file A says its under MIT > and file B says its under Apache and file C says its MyLicense 1.5). > Use the following egrep expressions to help in doing this: > E) Write up a summary of package viewpoints, and send to XYZ for confirmation. > F) Upon getting confirmation, and if you have more questions send to > joe_foo at fsf.org > G) Profit. > Sorry I hit send versus "Save Now". The reason for this is to try and make sure you are not the sole blocking point on it in case you get an offer to buy Aurora Linux for Googlebucks from you... or the snow in Illinois traps you in an iceblock for 10,000 years. You may still be the person that reviews the finished package viewpoints and sends them to legal etc.. but it makes sure that if you cash out, the job can be done by someone else. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From tcallawa at redhat.com Tue Dec 5 19:36:34 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 05 Dec 2006 13:36:34 -0600 Subject: [fab] Re: Licensing audit for Fedora Extras In-Reply-To: <80d7e4090612051124mf274f9fg25acb6f2fbdbf9f5@mail.gmail.com> References: <45464A8A.6080503@fedoraproject.org> <1162234672.7933.206.camel@dhcp-32-122.ord.redhat.com> <4574C247.4090105@fedoraproject.org> <1165280311.20269.198.camel@localhost.localdomain> <80d7e4090612051119v673421f7lb8f07d1b555ad9c6@mail.gmail.com> <80d7e4090612051124mf274f9fg25acb6f2fbdbf9f5@mail.gmail.com> Message-ID: <1165347394.20269.312.camel@localhost.localdomain> On Tue, 2006-12-05 at 12:24 -0700, Stephen John Smoogen wrote: > > Ok then I would say the first thing that needs to be done is a > > document that goes over how a license audit is done. Nothing fancy, > > but a list of > > > > A) Download src package > > B) Look at spec file > > C) Look at sourcecode and make sure license is listed in it. > > D) Look for any dubious licensed code (say file A says its under MIT > > and file B says its under Apache and file C says its MyLicense 1.5). > > Use the following egrep expressions to help in doing this: > > E) Write up a summary of package viewpoints, and send to XYZ for confirmation. > > F) Upon getting confirmation, and if you have more questions send to > > joe_foo at fsf.org > > G) Profit. Its more of a process of: A) Download SRPM B) rpm -ivh foo.src.rpm C) rpmbuild -bp path/to/foo.spec D) Note License in foo.spec E) Manually look through all source code in BUILD/foo F) Note actual licensing where it differs from License G) Ensure that license(s) is/are FSF or OSI approved H) If license(s) is/are approved individually, go to H2. Otherwise, go to I. H2) If licenses > 1, ensure they're compatible. If not, flag package in violation. I) If license(s) is not approved: I2) Is the license explicitly marked as bad by FSF, if not goto I3. I3) Ask FSF to review license. > Sorry I hit send versus "Save Now". The reason for this is to try and > make sure you are not the sole blocking point on it in case you get an > offer to buy Aurora Linux for Googlebucks from you... or the snow in > Illinois traps you in an iceblock for 10,000 years. > > You may still be the person that reviews the finished package > viewpoints and sends them to legal etc.. but it makes sure that if you > cash out, the job can be done by someone else. In the unlikely future where I cash out on Linux/SPARC, hopefully the above is a good start. ~spot From kwade at redhat.com Tue Dec 5 19:38:49 2006 From: kwade at redhat.com (Karsten Wade) Date: Tue, 05 Dec 2006 11:38:49 -0800 Subject: fun with naming In-Reply-To: <45757AE2.90107@redhat.com> References: <1164884721.2584.433.camel@erato.phig.org> <80d7e4090611301304v357ddfb9s3777c3e06488d0c1@mail.gmail.com> <20061130210922.GA28786@nostromo.devel.redhat.com> <80d7e4090612010917u68727c3egbf25333172a33790@mail.gmail.com> <45757AE2.90107@redhat.com> Message-ID: <1165347529.24009.111.camel@erato.phig.org> On Tue, 2006-12-05 at 08:57 -0500, Christopher Blizzard wrote: > I really think you guys are over-thinking or over-rationalizing things. Ha! And this from the guy who started it all. I just dragged it into a stand-alone thread. :) > Just plan Fedora seems fine to me. People get it, it's not complex, > and people generally understand what Fedora is. Of the problems that we > have, people not separating Fedora from the Project as a whole doesn't > seem to be one of them. Just so we're clear, you think it is OK and/or preferable to call all these things "Fedora": * The group of packages that are the core set for the distribution * The individual slices of those packages that fulfill certain purposes, such as "server", "desktop", "audio workstation", "OS for OLPC", etc. * Parts of the project that do not directly involve software packages (art, marketing, ambassadors, etc.) * The overall project that houses many, many things, including a Linux distribution As a reminder, the "fun with naming" that you started was about finding a name to easily identify the core set of packages. Even if this name is not used much outside of the project, it might be nice to have a way to refer to that. "Put it into Fedora." "Get it from Fedora." "What is Fedora?" It is the last question that worries me. When the answer is different depending on the audience and the context of the question, then we are in the same Ambiguousland that we've been in all along. Are we happy being there? - Karsten, a Fedoramorph -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Tue Dec 5 20:18:45 2006 From: kwade at redhat.com (Karsten Wade) Date: Tue, 05 Dec 2006 12:18:45 -0800 Subject: [fab] Re: Licensing audit for Fedora Extras In-Reply-To: <1165347394.20269.312.camel@localhost.localdomain> References: <45464A8A.6080503@fedoraproject.org> <1162234672.7933.206.camel@dhcp-32-122.ord.redhat.com> <4574C247.4090105@fedoraproject.org> <1165280311.20269.198.camel@localhost.localdomain> <80d7e4090612051119v673421f7lb8f07d1b555ad9c6@mail.gmail.com> <80d7e4090612051124mf274f9fg25acb6f2fbdbf9f5@mail.gmail.com> <1165347394.20269.312.camel@localhost.localdomain> Message-ID: <1165349925.24009.119.camel@erato.phig.org> On Tue, 2006-12-05 at 13:36 -0600, Tom 'spot' Callaway wrote: > Its more of a process of: > > A) Download SRPM > B) rpm -ivh foo.src.rpm > C) rpmbuild -bp path/to/foo.spec > D) Note License in foo.spec > E) Manually look through all source code in BUILD/foo > F) Note actual licensing where it differs from License > G) Ensure that license(s) is/are FSF or OSI approved For all packages that i) Fedora is the upstream[1] and ii) provide content in /usr/share/doc, we need to ensure that: a. The content is licensed under the OPL only, and b. The OPL is used without restrictions I just found a package that is an example of this; it needs to have the restriction clauses on the OPL removed (I'll file the bug.) [1] Example of where Fedora is upstream is system-config-*; what else? Is that an easy thing to figure out? - Karsten > H) If license(s) is/are approved individually, go to H2. Otherwise, go > to I. > H2) If licenses > 1, ensure they're compatible. If not, flag package in > violation. > I) If license(s) is not approved: > I2) Is the license explicitly marked as bad by FSF, if not goto I3. > I3) Ask FSF to review license. > > > Sorry I hit send versus "Save Now". The reason for this is to try and > > make sure you are not the sole blocking point on it in case you get an > > offer to buy Aurora Linux for Googlebucks from you... or the snow in > > Illinois traps you in an iceblock for 10,000 years. > > > > You may still be the person that reviews the finished package > > viewpoints and sends them to legal etc.. but it makes sure that if you > > cash out, the job can be done by someone else. > > In the unlikely future where I cash out on Linux/SPARC, hopefully the > above is a good start. > > ~spot > > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From blizzard at redhat.com Tue Dec 5 20:22:31 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 05 Dec 2006 15:22:31 -0500 Subject: fun with naming In-Reply-To: <1165347529.24009.111.camel@erato.phig.org> References: <1164884721.2584.433.camel@erato.phig.org> <80d7e4090611301304v357ddfb9s3777c3e06488d0c1@mail.gmail.com> <20061130210922.GA28786@nostromo.devel.redhat.com> <80d7e4090612010917u68727c3egbf25333172a33790@mail.gmail.com> <45757AE2.90107@redhat.com> <1165347529.24009.111.camel@erato.phig.org> Message-ID: <4575D507.7060205@redhat.com> Karsten Wade wrote: > On Tue, 2006-12-05 at 08:57 -0500, Christopher Blizzard wrote: >> I really think you guys are over-thinking or over-rationalizing things. > > Ha! And this from the guy who started it all. I just dragged it into a > stand-alone thread. :) Hey, I give no guarantees of being consistent. :) > Just so we're clear, you think it is OK and/or preferable to call all > these things "Fedora": > > * The group of packages that are the core set for the distribution > * The individual slices of those packages that fulfill certain purposes, > such as "server", "desktop", "audio workstation", "OS for OLPC", etc. > * Parts of the project that do not directly involve software packages > (art, marketing, ambassadors, etc.) > * The overall project that houses many, many things, including a Linux > distribution You're going to hate this but I think the answer is "it depends." I thought that we were talking about the thing-that-we-release. I think that we need to release something called "Fedora 7". There might be a desktop version or a server version, but it's all still based around this one product name. > As a reminder, the "fun with naming" that you started was about finding > a name to easily identify the core set of packages. Even if this name > is not used much outside of the project, it might be nice to have a way > to refer to that. > > "Put it into Fedora." > "Get it from Fedora." > "What is Fedora?" > > It is the last question that worries me. When the answer is different > depending on the audience and the context of the question, then we are > in the same Ambiguousland that we've been in all along. Are we happy > being there? Brands are messy. How you use them doesn't have to be. For example "get it into Fedora" might mean getting into the livecd or might mean getting it into the whole package universe. We could talk about the Fedora Universe to mean all the packages. But I was mostly worried about we release to the world with all the hubub that entails. I really believe that something simple and elegant is a good choice for that, even if there's desktop and server, etc. --Chris From jwboyer at jdub.homelinux.org Tue Dec 5 22:44:30 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 05 Dec 2006 16:44:30 -0600 Subject: [fab] Re: Licensing audit for Fedora Extras In-Reply-To: <1165349925.24009.119.camel@erato.phig.org> References: <45464A8A.6080503@fedoraproject.org> <1162234672.7933.206.camel@dhcp-32-122.ord.redhat.com> <4574C247.4090105@fedoraproject.org> <1165280311.20269.198.camel@localhost.localdomain> <80d7e4090612051119v673421f7lb8f07d1b555ad9c6@mail.gmail.com> <80d7e4090612051124mf274f9fg25acb6f2fbdbf9f5@mail.gmail.com> <1165347394.20269.312.camel@localhost.localdomain> <1165349925.24009.119.camel@erato.phig.org> Message-ID: <1165358670.4044.51.camel@zod.rchland.ibm.com> On Tue, 2006-12-05 at 12:18 -0800, Karsten Wade wrote: > On Tue, 2006-12-05 at 13:36 -0600, Tom 'spot' Callaway wrote: > > > Its more of a process of: > > > > A) Download SRPM > > B) rpm -ivh foo.src.rpm > > C) rpmbuild -bp path/to/foo.spec > > D) Note License in foo.spec > > E) Manually look through all source code in BUILD/foo > > F) Note actual licensing where it differs from License > > G) Ensure that license(s) is/are FSF or OSI approved > > For all packages that i) Fedora is the upstream[1] and ii) provide > content in /usr/share/doc, we need to ensure that: > > a. The content is licensed under the OPL only, and > b. The OPL is used without restrictions Um... why? josh From wtogami at redhat.com Tue Dec 5 23:32:38 2006 From: wtogami at redhat.com (Warren Togami) Date: Tue, 05 Dec 2006 18:32:38 -0500 Subject: Fedora Freedom? Message-ID: <45760196.2080807@redhat.com> I propose that we call the Fedora universe collection "Fedora Freedom". Why? 1) It is more creative than copying "Universe". 2) Freedom describes everything that belongs in that collection. 3) Keeping it a two letter acronym makes it easier to recognize in writing and vocalization than "F7". Joe: What version are you running? Bob: I'm running FF7. The new acronym would not be confusing at all. =) Yes, I am entirely serious about this. I love this name. Let's do it? Warren Togami wtogami at redhat.com From tchung at fedoraproject.org Wed Dec 6 00:06:16 2006 From: tchung at fedoraproject.org (Thomas Chung) Date: Tue, 5 Dec 2006 16:06:16 -0800 Subject: Fedora Freedom? In-Reply-To: <45760196.2080807@redhat.com> References: <45760196.2080807@redhat.com> Message-ID: <369bce3b0612051606g3f676807je1fa885b3eab4977@mail.gmail.com> On 12/5/06, Warren Togami wrote: > I propose that we call the Fedora universe collection "Fedora Freedom". +1 -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From davidz at redhat.com Wed Dec 6 00:50:45 2006 From: davidz at redhat.com (David Zeuthen) Date: Tue, 05 Dec 2006 19:50:45 -0500 Subject: Fedora Freedom? In-Reply-To: <45760196.2080807@redhat.com> References: <45760196.2080807@redhat.com> Message-ID: <1165366245.2485.2.camel@zelda.fubar.dk> On Tue, 2006-12-05 at 18:32 -0500, Warren Togami wrote: > I propose that we call the Fedora universe collection "Fedora Freedom". -1 mainly because it sounds so.. self-righteous. > The new acronym would not be confusing at all. =) FF is commonly used in some circles as an abbreviation for Firefox. David From sundaram at fedoraproject.org Wed Dec 6 00:51:18 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 06 Dec 2006 06:21:18 +0530 Subject: Fedora Freedom? In-Reply-To: <1165366245.2485.2.camel@zelda.fubar.dk> References: <45760196.2080807@redhat.com> <1165366245.2485.2.camel@zelda.fubar.dk> Message-ID: <45761406.5000505@fedoraproject.org> David Zeuthen wrote: > On Tue, 2006-12-05 at 18:32 -0500, Warren Togami wrote: >> I propose that we call the Fedora universe collection "Fedora Freedom". > > -1 mainly because it sounds so.. self-righteous. So does our stand on only including Free software. We can have it both ways. I am not very convinced about the name though. > >> The new acronym would not be confusing at all. =) > > FF is commonly used in some circles as an abbreviation for Firefox. True but the official abbreviation is Fx. http://www.mozilla.org/support/firefox/faq#spell-abbreviate Rahul From smooge at gmail.com Wed Dec 6 03:55:55 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 5 Dec 2006 20:55:55 -0700 Subject: Fedora Freedom? In-Reply-To: <1165366245.2485.2.camel@zelda.fubar.dk> References: <45760196.2080807@redhat.com> <1165366245.2485.2.camel@zelda.fubar.dk> Message-ID: <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> On 12/5/06, David Zeuthen wrote: > On Tue, 2006-12-05 at 18:32 -0500, Warren Togami wrote: > > I propose that we call the Fedora universe collection "Fedora Freedom". > > -1 mainly because it sounds so.. self-righteous. > I agree on that.. for some reason it sounds to me grasping.. I think it would take a Steve Jobs or Mark Shuttleworth to pull it off without sounding pretensious, self-riteous, and fake. And in their case, it would still sound that way, but people would buy it because well SJ/MS hang out with rock stars and fly into space when they want. > > The new acronym would not be confusing at all. =) > > FF is commonly used in some circles as an abbreviation for Firefox. > FireFox and Fantastic Four are what I see FF with > David > > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jkeating at redhat.com Wed Dec 6 05:02:22 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Dec 2006 00:02:22 -0500 Subject: Fedora Freedom? In-Reply-To: <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> References: <45760196.2080807@redhat.com> <1165366245.2485.2.camel@zelda.fubar.dk> <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> Message-ID: <200612060002.28292.jkeating@redhat.com> On Tuesday 05 December 2006 22:55, Stephen John Smoogen wrote: > FireFox and Fantastic Four are what I see FF with don't forget Final Fantasy, and I really hope that Fedora isn't just a Fantasy. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Wed Dec 6 05:13:38 2006 From: wtogami at redhat.com (Warren Togami) Date: Wed, 06 Dec 2006 00:13:38 -0500 Subject: Fedora Freedom? In-Reply-To: <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> References: <45760196.2080807@redhat.com> <1165366245.2485.2.camel@zelda.fubar.dk> <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> Message-ID: <45765182.2030404@redhat.com> Stephen John Smoogen wrote: > On 12/5/06, David Zeuthen wrote: >> On Tue, 2006-12-05 at 18:32 -0500, Warren Togami wrote: >> > I propose that we call the Fedora universe collection "Fedora Freedom". >> >> -1 mainly because it sounds so.. self-righteous. >> > > I agree on that.. for some reason it sounds to me grasping.. I think > it would take a Steve Jobs or Mark Shuttleworth to pull it off without > sounding pretensious, self-riteous, and fake. And in their case, it > would still sound that way, but people would buy it because well SJ/MS > hang out with rock stars and fly into space when they want. > Oh come on. This can't be anywhere near as pretentious as "Masters of the Universe" used by Ubuntu. Fedora is one of the last remaining major defenders of Freedom in FOSS. - Ubuntu ships GPL violating proprietary kernel drivers. - Novell sold their soul to the devil and betrayed the community. The Fedora collection contains everything that is free as in liberty. It is comprised of freedom. So why not call it that? Warren Togami wtogami at redhat.com From davidz at redhat.com Wed Dec 6 05:37:10 2006 From: davidz at redhat.com (David Zeuthen) Date: Wed, 06 Dec 2006 00:37:10 -0500 Subject: Fedora Freedom? In-Reply-To: <45765182.2030404@redhat.com> References: <45760196.2080807@redhat.com> <1165366245.2485.2.camel@zelda.fubar.dk> <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> <45765182.2030404@redhat.com> Message-ID: <1165383430.2485.31.camel@zelda.fubar.dk> On Wed, 2006-12-06 at 00:13 -0500, Warren Togami wrote: > Oh come on. This can't be anywhere near as pretentious as "Masters of > the Universe" used by Ubuntu. At least that's funny and makes me think of He-Man and other things. > Fedora is one of the last remaining major defenders of Freedom in FOSS. > - Ubuntu ships GPL violating proprietary kernel drivers. > - Novell sold their soul to the devil and betrayed the community. > > The Fedora collection contains everything that is free as in liberty. > It is comprised of freedom. So why not call it that? I just think it sounds way too pretentious and self-righteous. Fedora is also about cool things and making the computing experience more fun and enjoyable. Calling it "Fedora Freedom" makes me think of chores and all the homework I neglected to do. Sorry. David From skvidal at linux.duke.edu Wed Dec 6 08:56:49 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 06 Dec 2006 03:56:49 -0500 Subject: Fedora Freedom? In-Reply-To: <1165383430.2485.31.camel@zelda.fubar.dk> References: <45760196.2080807@redhat.com> <1165366245.2485.2.camel@zelda.fubar.dk> <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> <45765182.2030404@redhat.com> <1165383430.2485.31.camel@zelda.fubar.dk> Message-ID: <1165395409.25300.1.camel@cutter> On Wed, 2006-12-06 at 00:37 -0500, David Zeuthen wrote: > On Wed, 2006-12-06 at 00:13 -0500, Warren Togami wrote: > > Oh come on. This can't be anywhere near as pretentious as "Masters of > > the Universe" used by Ubuntu. > > At least that's funny and makes me think of He-Man and other things. > > > Fedora is one of the last remaining major defenders of Freedom in FOSS. > > - Ubuntu ships GPL violating proprietary kernel drivers. > > - Novell sold their soul to the devil and betrayed the community. > > > > The Fedora collection contains everything that is free as in liberty. > > It is comprised of freedom. So why not call it that? > > I just think it sounds way too pretentious and self-righteous. Fedora is > also about cool things and making the computing experience more fun and > enjoyable. Calling it "Fedora Freedom" makes me think of chores and all > the homework I neglected to do. Sorry. > +1. It's pretentious and silly. just call it fedora, move along. It's not like anyone else is going to refer to it any differently. no one is going to say "I run fedora freedom" or even "I run fedora core" most people just say "fedora" now anyway and that's not going to change. -sv From fedora at leemhuis.info Wed Dec 6 09:10:14 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 06 Dec 2006 10:10:14 +0100 Subject: Fedora Freedom? In-Reply-To: <1165395409.25300.1.camel@cutter> References: <45760196.2080807@redhat.com> <1165366245.2485.2.camel@zelda.fubar.dk> <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> <45765182.2030404@redhat.com> <1165383430.2485.31.camel@zelda.fubar.dk> <1165395409.25300.1.camel@cutter> Message-ID: <457688F6.2090005@leemhuis.info> seth vidal schrieb: > On Wed, 2006-12-06 at 00:37 -0500, David Zeuthen wrote: >> On Wed, 2006-12-06 at 00:13 -0500, Warren Togami wrote: >>> Oh come on. This can't be anywhere near as pretentious as "Masters of >>> the Universe" used by Ubuntu. >> At least that's funny and makes me think of He-Man and other things. >>> Fedora is one of the last remaining major defenders of Freedom in FOSS. >>> - Ubuntu ships GPL violating proprietary kernel drivers. >>> - Novell sold their soul to the devil and betrayed the community. >>> >>> The Fedora collection contains everything that is free as in liberty. >>> It is comprised of freedom. So why not call it that? >> I just think it sounds way too pretentious and self-righteous. Fedora is >> also about cool things and making the computing experience more fun and >> enjoyable. Calling it "Fedora Freedom" makes me think of chores and all >> the homework I neglected to do. Sorry. > +1. It's pretentious and silly. +1 > just call it fedora, move along. It's not like anyone else is going to > refer to it any differently. I still don't like the plain "Fedora" variant. BTW, why don't we simply continue to call the package-universe "Fedora Core" (with the difference that it's now located in the Fedora Extras framework and the Extras Packages are now to be found under the name Core, too)? > [...] CU thl From chitlesh at fedoraproject.org Wed Dec 6 12:45:48 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 6 Dec 2006 13:45:48 +0100 Subject: Fedora Freedom? In-Reply-To: <1165395409.25300.1.camel@cutter> References: <45760196.2080807@redhat.com> <1165366245.2485.2.camel@zelda.fubar.dk> <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> <45765182.2030404@redhat.com> <1165383430.2485.31.camel@zelda.fubar.dk> <1165395409.25300.1.camel@cutter> Message-ID: <13dbfe4f0612060445w32c34593r22c243b788febdfa@mail.gmail.com> On 12/6/06, seth vidal wrote: > just call it fedora, move along. It's not like anyone else is going to > refer to it any differently. > > no one is going to say "I run fedora freedom" or even "I run fedora > core" most people just say "fedora" now anyway and that's not going to > change. +1 -- http://clunixchit.blogspot.com From wtogami at redhat.com Wed Dec 6 14:03:57 2006 From: wtogami at redhat.com (Warren Togami) Date: Wed, 06 Dec 2006 09:03:57 -0500 Subject: Fedora Freedom? In-Reply-To: <13dbfe4f0612060445w32c34593r22c243b788febdfa@mail.gmail.com> References: <45760196.2080807@redhat.com> <1165366245.2485.2.camel@zelda.fubar.dk> <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> <45765182.2030404@redhat.com> <1165383430.2485.31.camel@zelda.fubar.dk> <1165395409.25300.1.camel@cutter> <13dbfe4f0612060445w32c34593r22c243b788febdfa@mail.gmail.com> Message-ID: <4576CDCD.8020302@redhat.com> Oops. I realize that FF could also mean "Freedom Fries". And that was awfully pretentious. I see what you mean. Warren Togami wtogami at redhat.com From bpepple at fedoraproject.org Wed Dec 6 15:35:06 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 06 Dec 2006 10:35:06 -0500 Subject: Fedora Freedom? In-Reply-To: <1165395409.25300.1.camel@cutter> References: <45760196.2080807@redhat.com> <1165366245.2485.2.camel@zelda.fubar.dk> <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> <45765182.2030404@redhat.com> <1165383430.2485.31.camel@zelda.fubar.dk> <1165395409.25300.1.camel@cutter> Message-ID: <1165419306.11233.3.camel@Chuck> On Wed, 2006-12-06 at 03:56 -0500, seth vidal wrote: > just call it fedora, move along. It's not like anyone else is going to > refer to it any differently. > > no one is going to say "I run fedora freedom" or even "I run fedora > core" most people just say "fedora" now anyway and that's not going to > change. +1. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From max at spevack.org Wed Dec 6 15:52:53 2006 From: max at spevack.org (Max Spevack) Date: Wed, 6 Dec 2006 10:52:53 -0500 (EST) Subject: Fedora Freedom? In-Reply-To: <457688F6.2090005@leemhuis.info> References: <45760196.2080807@redhat.com> <1165366245.2485.2.camel@zelda.fubar.dk> <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> <45765182.2030404@redhat.com> <1165383430.2485.31.camel@zelda.fubar.dk> <1165395409.25300.1.camel@cutter> <457688F6.2090005@leemhuis.info> Message-ID: >> just call it fedora, move along. It's not like anyone else is going to >> refer to it any differently. I like the idea of just calling it "Fedora" as well. Only drawback is that Fedora is such an overloaded name. But it's also the shortest, and least confusing. > BTW, why don't we simply continue to call the package-universe "Fedora > Core" (with the difference that it's now located in the Fedora Extras > framework and the Extras Packages are now to be found under the name > Core, too)? I don't know, I think that we want to stop having something called "Core" altogther, even if the future "Core" bears no resemblance to the old "Core". --Max From blizzard at redhat.com Wed Dec 6 17:33:09 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 06 Dec 2006 12:33:09 -0500 Subject: Fedora Freedom? In-Reply-To: <1165395409.25300.1.camel@cutter> References: <45760196.2080807@redhat.com> <1165366245.2485.2.camel@zelda.fubar.dk> <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> <45765182.2030404@redhat.com> <1165383430.2485.31.camel@zelda.fubar.dk> <1165395409.25300.1.camel@cutter> Message-ID: <4576FED5.7050909@redhat.com> seth vidal wrote: > > +1. It's pretentious and silly. > > just call it fedora, move along. It's not like anyone else is going to > refer to it any differently. > > no one is going to say "I run fedora freedom" or even "I run fedora > core" most people just say "fedora" now anyway and that's not going to > change. However! I have a fantasy t-shirt that has the Fedora symbol on the front and on the back it says "It's about the freedom, stupid." But putting it in the name? I would just let it stand on its own. --Chris From skvidal at linux.duke.edu Wed Dec 6 17:38:00 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 06 Dec 2006 12:38:00 -0500 Subject: Fedora Freedom? In-Reply-To: <4576FED5.7050909@redhat.com> References: <45760196.2080807@redhat.com> <1165366245.2485.2.camel@zelda.fubar.dk> <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> <45765182.2030404@redhat.com> <1165383430.2485.31.camel@zelda.fubar.dk> <1165395409.25300.1.camel@cutter> <4576FED5.7050909@redhat.com> Message-ID: <1165426680.25300.20.camel@cutter> On Wed, 2006-12-06 at 12:33 -0500, Christopher Blizzard wrote: > seth vidal wrote: > > > > +1. It's pretentious and silly. > > > > just call it fedora, move along. It's not like anyone else is going to > > refer to it any differently. > > > > no one is going to say "I run fedora freedom" or even "I run fedora > > core" most people just say "fedora" now anyway and that's not going to > > change. > > However! I have a fantasy t-shirt that has the Fedora symbol on the > front and on the back it says "It's about the freedom, stupid." But > putting it in the name? I would just let it stand on its own. > See I think a fedora tshirt with the hot chick from Final Fantasy X would be cool, too. -sv From gdk at redhat.com Wed Dec 6 17:38:00 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 6 Dec 2006 12:38:00 -0500 (EST) Subject: Fedora Freedom? In-Reply-To: <4576FED5.7050909@redhat.com> References: <45760196.2080807@redhat.com> <1165366245.2485.2.camel@zelda.fubar.dk> <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> <45765182.2030404@redhat.com> <1165383430.2485.31.camel@zelda.fubar.dk> <1165395409.25300.1.camel@cutter> <4576FED5.7050909@redhat.com> Message-ID: My fantasy T-shirt says: Freedom, Bitches. --g On Wed, 6 Dec 2006, Christopher Blizzard wrote: > seth vidal wrote: >> >> +1. It's pretentious and silly. >> >> just call it fedora, move along. It's not like anyone else is going to >> refer to it any differently. >> >> no one is going to say "I run fedora freedom" or even "I run fedora >> core" most people just say "fedora" now anyway and that's not going to >> change. > > However! I have a fantasy t-shirt that has the Fedora symbol on the front > and on the back it says "It's about the freedom, stupid." But putting it in > the name? I would just let it stand on its own. > > --Chris > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > -- ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From kwade at redhat.com Wed Dec 6 17:49:49 2006 From: kwade at redhat.com (Karsten Wade) Date: Wed, 06 Dec 2006 09:49:49 -0800 Subject: [fab] Re: Licensing audit for Fedora Extras In-Reply-To: <1165358670.4044.51.camel@zod.rchland.ibm.com> References: <45464A8A.6080503@fedoraproject.org> <1162234672.7933.206.camel@dhcp-32-122.ord.redhat.com> <4574C247.4090105@fedoraproject.org> <1165280311.20269.198.camel@localhost.localdomain> <80d7e4090612051119v673421f7lb8f07d1b555ad9c6@mail.gmail.com> <80d7e4090612051124mf274f9fg25acb6f2fbdbf9f5@mail.gmail.com> <1165347394.20269.312.camel@localhost.localdomain> <1165349925.24009.119.camel@erato.phig.org> <1165358670.4044.51.camel@zod.rchland.ibm.com> Message-ID: <1165427389.24009.214.camel@erato.phig.org> On Tue, 2006-12-05 at 16:44 -0600, Josh Boyer wrote: > On Tue, 2006-12-05 at 12:18 -0800, Karsten Wade wrote: > > > > For all packages that i) Fedora is the upstream[1] and ii) provide > > content in /usr/share/doc, we need to ensure that: > > > > a. The content is licensed under the OPL only, and > > b. The OPL is used without restrictions > > Um... why? Because the only open source license Fedora uses for content/documentation is the OPL without options. http://fedoraproject.org/wiki/Legal/Licenses/ http://fedoraproject.org/wiki/DocsProject/Licensing/FAQ When we did the relicensing earlier this year, we forgot to check packages where we are the upstream. - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Wed Dec 6 17:53:53 2006 From: kwade at redhat.com (Karsten Wade) Date: Wed, 06 Dec 2006 09:53:53 -0800 Subject: fun with naming In-Reply-To: <4575D507.7060205@redhat.com> References: <1164884721.2584.433.camel@erato.phig.org> <80d7e4090611301304v357ddfb9s3777c3e06488d0c1@mail.gmail.com> <20061130210922.GA28786@nostromo.devel.redhat.com> <80d7e4090612010917u68727c3egbf25333172a33790@mail.gmail.com> <45757AE2.90107@redhat.com> <1165347529.24009.111.camel@erato.phig.org> <4575D507.7060205@redhat.com> Message-ID: <1165427633.24009.219.camel@erato.phig.org> On Tue, 2006-12-05 at 15:22 -0500, Christopher Blizzard wrote: > You're going to hate this but I think the answer is "it depends." I > thought that we were talking about the thing-that-we-release. I think > that we need to release something called "Fedora 7". There might be a > desktop version or a server version, but it's all still based around > this one product name. [snip other examples] I got into this thread not to come up with cute names the world could appreciate, but to help _ourselves_. For the world-facing, I 100% agree that "Fedora 7" sounds best, although I sort of like the look of F*7. :) I'm worried that we won't be able to tell amongst ourselves what we are talking about when we say, "Get it into Fedora" etc. We could let this take care of itself organically, and then teach everyone the meaning of the terms that arise. Or we could pick an array of words to cover "all packages", "alternate packages", "server version", etc. :) - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Wed Dec 6 17:53:17 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 6 Dec 2006 12:53:17 -0500 Subject: Fedora Freedom? In-Reply-To: <1165395409.25300.1.camel@cutter> References: <45760196.2080807@redhat.com> <1165366245.2485.2.camel@zelda.fubar.dk> <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> <45765182.2030404@redhat.com> <1165383430.2485.31.camel@zelda.fubar.dk> <1165395409.25300.1.camel@cutter> Message-ID: <20061206175317.GG30810@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > no one is going to say "I run fedora freedom" or even "I run fedora > core" most people just say "fedora" now anyway and that's not going to > change. Aw, but think of the fun we could have! Musical interludes during the install... "Freedom's just another word for nothing left to lose..." Wait, no, that's not quite it. "Freedom... you've gotta give for what you take" Hm, better... "I was born a rich man?s son I had everything that money could buy But freedom - I had none I?ve been lookin? for freedom I?ve been lookin? so long I?ve been lookin? for freedom Still the search goes on" THAT'S IT! Fedora Freedom. Hey, at least we'll have Dirk Nowitzki's seal of approval. Bill From blizzard at redhat.com Wed Dec 6 17:59:27 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 06 Dec 2006 12:59:27 -0500 Subject: Fedora Freedom? In-Reply-To: References: <45760196.2080807@redhat.com> <1165366245.2485.2.camel@zelda.fubar.dk> <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> <45765182.2030404@redhat.com> <1165383430.2485.31.camel@zelda.fubar.dk> <1165395409.25300.1.camel@cutter> <4576FED5.7050909@redhat.com> Message-ID: <457704FF.6040600@redhat.com> Greg Dekoenigsberg wrote: > > My fantasy T-shirt says: Freedom, Bitches. Yes, and - The "F" is for Freedom, Bitches. --Chris > > --g > > On Wed, 6 Dec 2006, Christopher Blizzard wrote: > >> seth vidal wrote: >>> >>> +1. It's pretentious and silly. >>> >>> just call it fedora, move along. It's not like anyone else is going to >>> refer to it any differently. >>> >>> no one is going to say "I run fedora freedom" or even "I run fedora >>> core" most people just say "fedora" now anyway and that's not going to >>> change. >> >> However! I have a fantasy t-shirt that has the Fedora symbol on the >> front and on the back it says "It's about the freedom, stupid." But >> putting it in the name? I would just let it stand on its own. >> >> --Chris >> >> _______________________________________________ >> fedora-advisory-board mailing list >> fedora-advisory-board at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-advisory-board >> > From jwboyer at jdub.homelinux.org Wed Dec 6 18:44:56 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 06 Dec 2006 12:44:56 -0600 Subject: [fab] Re: Licensing audit for Fedora Extras In-Reply-To: <1165427389.24009.214.camel@erato.phig.org> References: <45464A8A.6080503@fedoraproject.org> <1162234672.7933.206.camel@dhcp-32-122.ord.redhat.com> <4574C247.4090105@fedoraproject.org> <1165280311.20269.198.camel@localhost.localdomain> <80d7e4090612051119v673421f7lb8f07d1b555ad9c6@mail.gmail.com> <80d7e4090612051124mf274f9fg25acb6f2fbdbf9f5@mail.gmail.com> <1165347394.20269.312.camel@localhost.localdomain> <1165349925.24009.119.camel@erato.phig.org> <1165358670.4044.51.camel@zod.rchland.ibm.com> <1165427389.24009.214.camel@erato.phig.org> Message-ID: <1165430696.24220.3.camel@zod.rchland.ibm.com> On Wed, 2006-12-06 at 09:49 -0800, Karsten Wade wrote: > On Tue, 2006-12-05 at 16:44 -0600, Josh Boyer wrote: > > On Tue, 2006-12-05 at 12:18 -0800, Karsten Wade wrote: > > > > > > For all packages that i) Fedora is the upstream[1] and ii) provide > > > content in /usr/share/doc, we need to ensure that: > > > > > > a. The content is licensed under the OPL only, and > > > b. The OPL is used without restrictions > > > > Um... why? > > Because the only open source license Fedora uses for > content/documentation is the OPL without options. > > http://fedoraproject.org/wiki/Legal/Licenses/ > http://fedoraproject.org/wiki/DocsProject/Licensing/FAQ > > When we did the relicensing earlier this year, we forgot to check > packages where we are the upstream. Ah, I had misread your original email and thought you meant that OPL was the license that had to be used for the entire package, not just the content under /usr/share/doc. Sorry for the noise. josh From andreas.bierfert at lowlatency.de Fri Dec 8 10:19:01 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Fri, 8 Dec 2006 11:19:01 +0100 Subject: Fedora Freedom? In-Reply-To: <45760196.2080807@redhat.com> References: <45760196.2080807@redhat.com> Message-ID: <20061208111901.4815e917@alkaid.a.lan> On Tue, 05 Dec 2006 18:32:38 -0500 Warren Togami wrote: > I propose that we call the Fedora universe collection "Fedora Freedom". -1 Just reminds me to much of Freedom Fries which I dearly hate. Fedora +1 - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Christian.Iseli at licr.org Mon Dec 11 10:06:44 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Mon, 11 Dec 2006 11:06:44 +0100 Subject: Fedora Freedom? In-Reply-To: <1165395409.25300.1.camel@cutter> References: <45760196.2080807@redhat.com> <1165366245.2485.2.camel@zelda.fubar.dk> <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> <45765182.2030404@redhat.com> <1165383430.2485.31.camel@zelda.fubar.dk> <1165395409.25300.1.camel@cutter> Message-ID: <20061211110644.6edf5aaa@ludwig-alpha.unil.ch> On Wed, 06 Dec 2006 03:56:49 -0500, seth vidal wrote: > no one is going to say "I run fedora freedom" or even "I run fedora > core" most people just say "fedora" now anyway and that's not going to > change. +1 C From tchung at fedoraproject.org Mon Dec 11 17:10:22 2006 From: tchung at fedoraproject.org (Thomas Chung) Date: Mon, 11 Dec 2006 09:10:22 -0800 Subject: Meeting minutes of the FAD In-Reply-To: <1165830792.9335.1.camel@Amilo-GK.homenet.local> References: <1165830792.9335.1.camel@Amilo-GK.homenet.local> Message-ID: <369bce3b0612110910y7b74bf2ei541adb8e9fa44862@mail.gmail.com> > -------- Weitergeleitete Nachricht -------- > > Von: Thorsten Leemhuis > > An: Gerold Kassube > > Kopie: Fedora-Ambassadors , > > Discussions on expanding the Fedora user base > > > > Betreff: Re: Meeting minutes of the FAD > > Datum: Sat, 09 Dec 2006 21:39:27 +0100 > >... > > "dying Fedora Weekly Reports" -- that would be sad, I liked the idea, > > the format and the content a lot, but I have no time to help there :-/ . > > Why can't we merge fedoranews.org and the weekly reports? That would be > > a step in the right direction. Sure, the stuff from fedoranews.org can > > write about nvidia, ati or 3rd party add-on repos. But most of the stuff > > that written there currently isn't like that and would be fine for > > fedoraproject.org afaics. fedoranews.org could continue with reporting > > the stuff that is forbidden for fedoraproject.org (as a add-on or > > something like that). And ahte weekly reports need to be annouced > > properly... Thorsten, What do you recommend? Shutdown Fedora Weekly Reports or Fedora Weekly News? Fedora Weekly Reports already have its own section in Fedora Weekly News. Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From fedora at leemhuis.info Mon Dec 11 17:51:26 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 11 Dec 2006 18:51:26 +0100 Subject: Meeting minutes of the FAD In-Reply-To: <369bce3b0612110910y7b74bf2ei541adb8e9fa44862@mail.gmail.com> References: <1165830792.9335.1.camel@Amilo-GK.homenet.local> <369bce3b0612110910y7b74bf2ei541adb8e9fa44862@mail.gmail.com> Message-ID: <457D9A9E.3080609@leemhuis.info> Thomas Chung schrieb: >> -------- Weitergeleitete Nachricht -------- >>> Von: Thorsten Leemhuis >>> An: Gerold Kassube >>> Kopie: Fedora-Ambassadors , >>> Discussions on expanding the Fedora user base >>> >>> Betreff: Re: Meeting minutes of the FAD >>> Datum: Sat, 09 Dec 2006 21:39:27 +0100 >>> ... >>> "dying Fedora Weekly Reports" -- that would be sad, I liked the idea, >>> the format and the content a lot, but I have no time to help there :-/ . >>> Why can't we merge fedoranews.org and the weekly reports? That would be >>> a step in the right direction. Sure, the stuff from fedoranews.org can >>> write about nvidia, ati or 3rd party add-on repos. But most of the stuff >>> that written there currently isn't like that and would be fine for >>> fedoraproject.org afaics. fedoranews.org could continue with reporting >>> the stuff that is forbidden for fedoraproject.org (as a add-on or >>> something like that). And ahte weekly reports need to be annouced >>> properly... > What do you recommend? > Shutdown Fedora Weekly Reports or Fedora Weekly News? > Fedora Weekly Reports already have its own section in Fedora Weekly News. Well, I'm not to involved in the whole Weekly{Reports,News} business to much, but if you ask, here is a braindump: - a weekly report really is a nice thing to have - two is IMHO one to much for most people (one that enhances the first one with the stuff the first one can't mention is something else; but that would need a bit of coordination) - I'd like to see the reports realized within the Fedora project as that helps getting people involved - most of the stuff from Fedora Weekly News can afaics be mentioned on fedoraproject.org - the weekly reports as they looked like in the beginning helped a lot to get a quick overview of what the other sub-project work on if you are only active in parts of the project; the weekly news don't get that far into the details - the weekly reports lost momentum; maybe it's to late to re-activate the idea; starting something new (with a new name?) might be better - the weekly news get announced on fedora-annouce-list (good) and got from there even to lwn.net and other websites (even better); the weekly reports (nearly?) never got that much glory (bad) So a merge of the two under a new name might be the best. I'm willing to help getting it filled with informations from Extras-land for two or even three months if I have to (I did the same for the Weekly Reports in the beginning, but lost interest as the reports newer got properly annouced while the weekly news got attention), but would like to hand that job over to someone else after that... CU thl From fedora at leemhuis.info Mon Dec 11 18:12:13 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 11 Dec 2006 19:12:13 +0100 Subject: Fedora 7 planing Message-ID: <457D9F7D.8030007@leemhuis.info> Hi, in last weeks FESCo meeting the topic "FC7 schedule" came up. I did take a look at some historical schedules and I got the impression that there are normally four (sometimes five and seldom more) weeks between each test release or between test3 and final. That means: If we aim for a release in late March/early April(?) we would need to release the first beta in early January afaics -- at least if we want to continue as we did in the past. Well, that quite soon. Shouldn't we start planing the first test-release slowly? And, btw, who is actually going to drive this? The core cabal is in still in question -- or do we plan to change that soon? Or do we want to set an interim solution in place to slowly try the new Fedora-world-order a bit -- e.g. a mix between core cabal and FESCo? CU thl (?) -- I think we should target early March, then we'll hit mid-April probably ;-) From mspevack at redhat.com Mon Dec 11 20:17:21 2006 From: mspevack at redhat.com (Max Spevack) Date: Mon, 11 Dec 2006 15:17:21 -0500 (EST) Subject: Fedora Board meeting Tuesday 12/12 Message-ID: at 10:00 AM Easter, 15:00 GMT. chat/logs from #fedora-board as we've been doing for the last while. Topics: - What is the leadership structure of the new world order of Fedora going to look like? There was a long thread on FAB about this -- let's talk for a bit about what sort of stuff bubbled up in that thread. Are there any points we can begin to agree on, and work from there. - Is the ball moving on version control stuff since the Fedora Summit? I know Jesse continues to work on pungi, but I haven't seen (or just haven't been looking in the right place) a lot of follow up about the distributed version control. Where are we with that, etc? - What's new with LiveCD this week? - What other important Summit topics have been left without much progress? Are we moving on all the important stuff? - If needed, the *final* RPM discussion. Seth has been eager to come to a close on this. I've been getting questions about it also. Corbet (hi Jon!) is looking to write something about this on LWN -- in short, answers are needed. I told Seth that I'd work on taking the notes and conversations that we have spread throughout various inboxes and get something consolidated. Basically if anyone wants to scream one last time, tomorrow is the moment. -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From jkeating at redhat.com Mon Dec 11 20:25:00 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 Dec 2006 15:25:00 -0500 Subject: Fedora Board meeting Tuesday 12/12 In-Reply-To: References: Message-ID: <200612111525.01107.jkeating@redhat.com> On Monday 11 December 2006 15:17, Max Spevack wrote: > - Is the ball moving on version control stuff since the Fedora Summit? ?I > know Jesse continues to work on pungi, but I haven't seen (or just haven't > been looking in the right place) a lot of follow up about the distributed > version control. ?Where are we with that, etc? I thought this was supposed to take a backburner. It was noted that CVS _has_ some ACL stuff in place so that we can keep set permissions at a module level (does this include release branch, since these aren't really "branches"?) and that we don't _need_ a new SCM to accomplish the merger of core<->extras. Personally I think a new distributed SCM would make things like downstream distributions (olpc, etc..) easier, ditto secondary arches. There were strong concerns though of changing too much too quickly and not accomplishing the major goal(s) of the merger. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Mon Dec 11 20:24:35 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 11 Dec 2006 15:24:35 -0500 Subject: Fedora Board meeting Tuesday 12/12 In-Reply-To: References: Message-ID: <457DBE83.60806@redhat.com> Max Spevack wrote: > > - Is the ball moving on version control stuff since the Fedora Summit? > I know Jesse continues to work on pungi, but I haven't seen (or just > haven't been looking in the right place) a lot of follow up about the > distributed version control. Where are we with that, etc? What happened to the board mandate for a time limited fedora-scm SIG? Was the mailing list created? Warren Togami wtogami at redhat.com From mspevack at redhat.com Mon Dec 11 20:24:56 2006 From: mspevack at redhat.com (Max Spevack) Date: Mon, 11 Dec 2006 15:24:56 -0500 (EST) Subject: Fedora 7 planing In-Reply-To: <457D9F7D.8030007@leemhuis.info> References: <457D9F7D.8030007@leemhuis.info> Message-ID: On Mon, 11 Dec 2006, Thorsten Leemhuis wrote: > in last weeks FESCo meeting the topic "FC7 schedule" came up. I did take > a look at some historical schedules and I got the impression that there > are normally four (sometimes five and seldom more) weeks between each > test release or between test3 and final. > > That means: If we aim for a release in late March/early April(?) we > would need to release the first beta in early January afaics -- at least > if we want to continue as we did in the past. Well, that quite soon. > Shouldn't we start planing the first test-release slowly? And, btw, who > is actually going to drive this? The core cabal is in still in question > -- or do we plan to change that soon? Or do we want to set an interim > solution in place to slowly try the new Fedora-world-order a bit -- e.g. > a mix between core cabal and FESCo? > > CU thl > > (?) -- I think we should target early March, then we'll hit mid-April > probably ;-) We released Zod on October 24th. 6 months out from that is April 24th. The Red Hat Summit for 2007 is on May 8th, and I think it is *critical* that we have Fedora 7 done in time for that, so that every person who shows up at the Summit gets a Fedora 7 DVD along with all of their other stuff, and so that we can make a HUGE DEAL out of everything we've accomplished in Fedora at the Summit. So that means we need to be done with enough time to put a nice bow around Fedora and get the DVDs made before the Summit. I like the idea of April 9th, April 16th at the absolute latest. Given our tendency to slip our release dates, if those dates are *HARD* and that means we have to pick a date toward the end of March to guarantee we make the April one, that's fine. --Max From mspevack at redhat.com Mon Dec 11 20:26:02 2006 From: mspevack at redhat.com (Max Spevack) Date: Mon, 11 Dec 2006 15:26:02 -0500 (EST) Subject: Fedora Board meeting Tuesday 12/12 In-Reply-To: <200612111525.01107.jkeating@redhat.com> References: <200612111525.01107.jkeating@redhat.com> Message-ID: On Mon, 11 Dec 2006, Jesse Keating wrote: > On Monday 11 December 2006 15:17, Max Spevack wrote: >> - Is the ball moving on version control stuff since the Fedora Summit? ?I >> know Jesse continues to work on pungi, but I haven't seen (or just haven't >> been looking in the right place) a lot of follow up about the distributed >> version control. ?Where are we with that, etc? > > I thought this was supposed to take a backburner. It was noted that CVS _has_ > some ACL stuff in place so that we can keep set permissions at a module level > (does this include release branch, since these aren't really "branches"?) and > that we don't _need_ a new SCM to accomplish the merger of core<->extras. And if the answer is back burner for now, that's fine. I just want to make sure it is consciously on the backburner as opposed to forgotten. :-) > Personally I think a new distributed SCM would make things like > downstream distributions (olpc, etc..) easier, ditto secondary arches. > There were strong concerns though of changing too much too quickly and > not accomplishing the major goal(s) of the merger. *nod* --Max From blizzard at redhat.com Tue Dec 12 02:37:13 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 11 Dec 2006 21:37:13 -0500 Subject: Fedora Board meeting Tuesday 12/12 In-Reply-To: <200612111525.01107.jkeating@redhat.com> References: <200612111525.01107.jkeating@redhat.com> Message-ID: <457E15D9.5080708@redhat.com> Jesse Keating wrote: > On Monday 11 December 2006 15:17, Max Spevack wrote: >> - Is the ball moving on version control stuff since the Fedora Summit? I >> know Jesse continues to work on pungi, but I haven't seen (or just haven't >> been looking in the right place) a lot of follow up about the distributed >> version control. Where are we with that, etc? > > I thought this was supposed to take a backburner. It was noted that CVS _has_ > some ACL stuff in place so that we can keep set permissions at a module level > (does this include release branch, since these aren't really "branches"?) and > that we don't _need_ a new SCM to accomplish the merger of core<->extras. Back burner to what, exactly? What's it waiting on (other than testing and feedback?) --Chris From jkeating at redhat.com Tue Dec 12 02:55:43 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 Dec 2006 21:55:43 -0500 Subject: Fedora Board meeting Tuesday 12/12 In-Reply-To: <457E15D9.5080708@redhat.com> References: <200612111525.01107.jkeating@redhat.com> <457E15D9.5080708@redhat.com> Message-ID: <200612112155.46503.jkeating@redhat.com> On Monday 11 December 2006 21:37, Christopher Blizzard wrote: > Back burner to what, exactly? ?What's it waiting on (other than testing > and feedback?) A backburner to the rest of the infrastructure work that needs doing. New build system, lots of package moves, new push scripts, new tree composing software, new update tool, etc... What its waiting on is yes, testing, feedback, some more development of scripts such as the unique tagging script, the branching scripts, the import script, etc... I honestly didn't get much feedback on the proof of concept, so I'm really flying "blind" if you will. Getting feedback means making some people pay attention to it and look at it, people that are busy with other things, which may or may not be more important. I've been more focused on pungi myself rather than putting time into the dist-git proof of concept. While I'd like to continue the SCM work, I think a tool to compose our distribution is a bit more important for me to work on at this point. This shouldn't stop anybody else from working on a proof of concept or enhancing the existing ones. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at fedoraproject.org Tue Dec 12 04:28:27 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 11 Dec 2006 22:28:27 -0600 Subject: Fedora Board meeting Tuesday 12/12 In-Reply-To: <200612112155.46503.jkeating@redhat.com> References: <200612111525.01107.jkeating@redhat.com> <457E15D9.5080708@redhat.com> <200612112155.46503.jkeating@redhat.com> Message-ID: <3237e4410612112028i5095eb2x1f94f21a065d0a0c@mail.gmail.com> On 12/11/06, Jesse Keating wrote: > On Monday 11 December 2006 21:37, Christopher Blizzard wrote: > > Back burner to what, exactly? What's it waiting on (other than testing > > and feedback?) > I honestly didn't get much feedback on the proof of concept, so I'm really > flying "blind" if you will. Getting feedback means making some people pay > attention to it and look at it, people that are busy with other things, which > may or may not be more important. I've been more focused on pungi myself > rather than putting time into the dist-git proof of concept. While I'd like > to continue the SCM work, I think a tool to compose our distribution is a bit > more important for me to work on at this point. This shouldn't stop anybody > else from working on a proof of concept or enhancing the existing ones. I had the same issue with my subversion proof of concept a few months back. Is it safe or dangerous to assume that lack of interest means that people just don't care as long as it works? -Mike From katzj at redhat.com Tue Dec 12 04:33:44 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 11 Dec 2006 23:33:44 -0500 Subject: Fedora Board meeting Tuesday 12/12 In-Reply-To: <3237e4410612112028i5095eb2x1f94f21a065d0a0c@mail.gmail.com> References: <200612111525.01107.jkeating@redhat.com> <457E15D9.5080708@redhat.com> <200612112155.46503.jkeating@redhat.com> <3237e4410612112028i5095eb2x1f94f21a065d0a0c@mail.gmail.com> Message-ID: <1165898024.2555.52.camel@aglarond.local> On Mon, 2006-12-11 at 22:28 -0600, Mike McGrath wrote: > On 12/11/06, Jesse Keating wrote: > > On Monday 11 December 2006 21:37, Christopher Blizzard wrote: > > > Back burner to what, exactly? What's it waiting on (other than testing > > > and feedback?) > > I honestly didn't get much feedback on the proof of concept, so I'm really > > flying "blind" if you will. Getting feedback means making some people pay > > attention to it and look at it, people that are busy with other things, which > > may or may not be more important. I've been more focused on pungi myself > > rather than putting time into the dist-git proof of concept. While I'd like > > to continue the SCM work, I think a tool to compose our distribution is a bit > > more important for me to work on at this point. This shouldn't stop anybody > > else from working on a proof of concept or enhancing the existing ones. > > I had the same issue with my subversion proof of concept a few months > back. Is it safe or dangerous to assume that lack of interest means > that people just don't care as long as it works? More likely, people are "happy enough" with CVS (warts and all) to not want to invest the time and effort on alternatives. I really feel pretty strongly that if we're going to switch, there needs to be bigger investigation into what work people are trying to do, how they accomplish it and how we can make things _better_ rather than just switching SCMs for nominal amounts of tool improvement. Jeremy From notting at redhat.com Tue Dec 12 05:25:54 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 12 Dec 2006 00:25:54 -0500 Subject: Fedora Board meeting Tuesday 12/12 In-Reply-To: <3237e4410612112028i5095eb2x1f94f21a065d0a0c@mail.gmail.com> References: <200612111525.01107.jkeating@redhat.com> <457E15D9.5080708@redhat.com> <200612112155.46503.jkeating@redhat.com> <3237e4410612112028i5095eb2x1f94f21a065d0a0c@mail.gmail.com> Message-ID: <20061212052554.GA11776@nostromo.devel.redhat.com> Mike McGrath (mmcgrath at fedoraproject.org) said: > I had the same issue with my subversion proof of concept a few months > back. Is it safe or dangerous to assume that lack of interest means > that people just don't care as long as it works? Generally, with things like SCMs or build systems, no one is going to switch until it's "live" and they have to - they worry about getting their stuff packaged and can manage to migrate when they have to. I recall when we initally did the CVS migration internally - we went from a few feeble 'hm, works for me, I suppose' to 'OMG WHAT DID YOU DO' as soon as we made it live. Bill From fedora at leemhuis.info Tue Dec 12 06:12:24 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 12 Dec 2006 07:12:24 +0100 Subject: Fedora 7 planing In-Reply-To: References: <457D9F7D.8030007@leemhuis.info> Message-ID: <457E4848.2050806@leemhuis.info> Max Spevack schrieb: > On Mon, 11 Dec 2006, Thorsten Leemhuis wrote: >> in last weeks FESCo meeting the topic "FC7 schedule" came up. I did take >> a look at some historical schedules and I got the impression that there >> are normally four (sometimes five and seldom more) weeks between each >> test release or between test3 and final. >> >> That means: If we aim for a release in late March/early April(?) we >> would need to release the first beta in early January afaics -- at least >> if we want to continue as we did in the past. Well, that quite soon. >> Shouldn't we start planing the first test-release slowly? And, btw, who >> is actually going to drive this? The core cabal is in still in question >> -- or do we plan to change that soon? Or do we want to set an interim >> solution in place to slowly try the new Fedora-world-order a bit -- e.g. >> a mix between core cabal and FESCo? >> >> (?) -- I think we should target early March, then we'll hit mid-April ^^^^^ Sorry, that was no stupid joke, this was really a typo. I meant late March, too (it to late for early March in any case). >> probably ;-) > > We released Zod on October 24th. 6 months out from that is April 24th. > > The Red Hat Summit for 2007 is on May 8th, and I think it is *critical* > that we have Fedora 7 done in time for that, so that every person who > shows up at the Summit gets a Fedora 7 DVD along with all of their other > stuff, and so that we can make a HUGE DEAL out of everything we've > accomplished in Fedora at the Summit. > > So that means we need to be done with enough time to put a nice bow around > Fedora and get the DVDs made before the Summit. > > I like the idea of April 9th, April 16th at the absolute latest. > > Given our tendency to slip our release dates, if those dates are *HARD* > and that means we have to pick a date toward the end of March to guarantee > we make the April one, that's fine. +1 With 4 weeks for each test cycle that would mean: January 02 -- Test 1 January 30 -- Test 2 February 27 -- Test 3 March 27 -- Final Release January 02 is probably to hard to reach, so we should cut one cycle from four to three weeks. Which one? test3 maybe? CU thl From dwmw2 at infradead.org Tue Dec 12 10:33:13 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 12 Dec 2006 10:33:13 +0000 Subject: Fedora Board meeting Tuesday 12/12 In-Reply-To: <1165898024.2555.52.camel@aglarond.local> References: <200612111525.01107.jkeating@redhat.com> <457E15D9.5080708@redhat.com> <200612112155.46503.jkeating@redhat.com> <3237e4410612112028i5095eb2x1f94f21a065d0a0c@mail.gmail.com> <1165898024.2555.52.camel@aglarond.local> Message-ID: <1165919593.5253.612.camel@pmac.infradead.org> On Mon, 2006-12-11 at 23:33 -0500, Jeremy Katz wrote: > More likely, people are "happy enough" with CVS (warts and all) to not > want to invest the time and effort on alternatives. That's certainly the case. CVS isn't wonderful but it does the job well enough -- and it's certainly better using CVS than trying to learn something new. I could perhaps manage a switch to git -- but even that I'm not convinced of the need for. And anything else would certainly be a retrograde step, I think. After all I'm bad enough at typing 'cvs diff' in git repositories already -- I don't want to add another gratuitous new version control system into the mix. > I really feel pretty strongly that if we're going to switch, there needs > to be bigger investigation into what work people are trying to do, how > they accomplish it and how we can make things _better_ rather than just > switching SCMs for nominal amounts of tool improvement. I agree strongly with the above. If a switch is proposed, I'd like to see a very clear list of the improvements it promises. -- dwmw2 From dwmw2 at infradead.org Tue Dec 12 11:05:00 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 12 Dec 2006 11:05:00 +0000 Subject: Fedora Board meeting Tuesday 12/12 In-Reply-To: <200612111525.01107.jkeating@redhat.com> References: <200612111525.01107.jkeating@redhat.com> Message-ID: <1165921500.5253.616.camel@pmac.infradead.org> On Mon, 2006-12-11 at 15:25 -0500, Jesse Keating wrote: > > Personally I think a new distributed SCM would make things like downstream > distributions (olpc, etc..) easier, ditto secondary arches. There were > strong concerns though of changing too much too quickly and not accomplishing > the major goal(s) of the merger. Would anyone shoot me for mentioning cvsup? :) -- dwmw2 From jkeating at redhat.com Tue Dec 12 13:55:02 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 Dec 2006 08:55:02 -0500 Subject: Fedora Board meeting Tuesday 12/12 In-Reply-To: <1165919593.5253.612.camel@pmac.infradead.org> References: <1165898024.2555.52.camel@aglarond.local> <1165919593.5253.612.camel@pmac.infradead.org> Message-ID: <200612120855.06128.jkeating@redhat.com> On Tuesday 12 December 2006 05:33, David Woodhouse wrote: > I agree strongly with the above. If a switch is proposed, I'd like to > see a very clear list of the improvements it promises. Right now, these improvements are all really around downstream projects, such as secondary arches. With a scm like git or hg it becomes much easier to clone/pull changes from upstream and integrate them (sometimes automatically) with changes from downstream. No games to play with cvs version files, just a clone, or a pull/merge and you've got your own repo to play with that your own buildsystem could build from. Theoretically it would make things like OLPC easier to get off the ground as your own repo can move quicker and the upstream repo can easily pull/merge your changes in when they are ready. It also makes some of the management a bit easier, making release "branch" dirs, making branchdirs based on a given tag (impossible with cvs I'm told) and a few other things. The problem is that none of this is really that visible to the people just using Fedora, and all of these things can be accomplished without any changes to workflow. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wwoods at redhat.com Tue Dec 12 15:46:08 2006 From: wwoods at redhat.com (Will Woods) Date: Tue, 12 Dec 2006 15:46:08 +0000 Subject: Fedora 7 planing In-Reply-To: <457E4848.2050806@leemhuis.info> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> Message-ID: <1165938368.13183.11.camel@metroid.rdu.redhat.com> On Tue, 2006-12-12 at 07:12 +0100, Thorsten Leemhuis wrote: > With 4 weeks for each test cycle that would mean: > > January 02 -- Test 1 > January 30 -- Test 2 > February 27 -- Test 3 > March 27 -- Final Release > > January 02 is probably to hard to reach, so we should cut one cycle from > four to three weeks. Which one? test3 maybe? If you have to cut a week from one cycle, I'd make it Test1. Test1 is the most likely to be broken in some unanticipated way, so it would be a good idea to plan for a (slightly) quicker followup release to that one. Also, I'd like to have a full 4 weeks after the No-Foolin' Seriously-Guys This-Is-It Feature Freeze (Test3) to make sure we've got the kinks worked out. Does that sound reasonable? -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Dec 12 16:01:03 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 Dec 2006 11:01:03 -0500 Subject: Fedora 7 planing In-Reply-To: <1165938368.13183.11.camel@metroid.rdu.redhat.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <1165938368.13183.11.camel@metroid.rdu.redhat.com> Message-ID: <200612121101.03525.jkeating@redhat.com> On Tuesday 12 December 2006 10:46, Will Woods wrote: > If you have to cut a week from one cycle, I'd make it Test1. Test1 is > the most likely to be broken in some unanticipated way, so it would be a > good idea to plan for a (slightly) quicker followup release to that one. > > Also, I'd like to have a full 4 weeks after the No-Foolin' > Seriously-Guys This-Is-It Feature Freeze (Test3) to make sure we've got > the kinks worked out. > > Does that sound reasonable? Seems reasonable. I also want to do much more often mini-freeze releases, much like the FC6-Pre thing we did. Perhaps torrent only, fully installable, perhaps even with a LiveCD. I notice we get far more testing on the Test release rather than the daily rawhide stuff, so if we give people more chances for a consistant CD/DVD set to install from we might get more return on our fixes from the test releases. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mspevack at redhat.com Tue Dec 12 22:37:25 2006 From: mspevack at redhat.com (Max Spevack) Date: Tue, 12 Dec 2006 17:37:25 -0500 (EST) Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <457E4848.2050806@leemhuis.info> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> Message-ID: On Tue, 12 Dec 2006, Thorsten Leemhuis wrote: > January 02 is probably to hard to reach, so we should cut one cycle from > four to three weeks. Which one? test3 maybe? We talked about this in the Board meeting this morning. Here was the proposal we came up with (modified for a Tuesday release, not a Monday release), working backward: RH Summit May 9-11 Release April 24 (exactly 6 months after FC6) Gold April 17 Test3 March 27 Test2 February 27 FudCon February 9-11 (including hackfest) Test1 January 30 Not a lot of slip time in there (at least, not with the RH Summit as a target). Comments? -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From mspevack at redhat.com Tue Dec 12 22:40:40 2006 From: mspevack at redhat.com (Max Spevack) Date: Tue, 12 Dec 2006 17:40:40 -0500 (EST) Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> Message-ID: On Tue, 12 Dec 2006, Max Spevack wrote: > On Tue, 12 Dec 2006, Thorsten Leemhuis wrote: > >> January 02 is probably to hard to reach, so we should cut one cycle from >> four to three weeks. Which one? test3 maybe? > > We talked about this in the Board meeting this morning. > > Here was the proposal we came up with (modified for a Tuesday release, not a > Monday release), working backward: > > RH Summit May 9-11 > Release April 24 (exactly 6 months after FC6) > Gold April 17 > Test3 March 27 > Test2 February 27 > FudCon February 9-11 (including hackfest) > Test1 January 30 > > Not a lot of slip time in there (at least, not with the RH Summit as a > target). > > Comments? For example, Jesse, if you want to work in some mini-freezes, it should be pretty reasonable for you to take a schedule like this and just decide when you want them, right? --Max From luis at tieguy.org Tue Dec 12 22:47:47 2006 From: luis at tieguy.org (Luis Villa) Date: Tue, 12 Dec 2006 17:47:47 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> Message-ID: <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> On 12/12/06, Max Spevack wrote: > On Tue, 12 Dec 2006, Thorsten Leemhuis wrote: > > > January 02 is probably to hard to reach, so we should cut one cycle from > > four to three weeks. Which one? test3 maybe? > > We talked about this in the Board meeting this morning. > > Here was the proposal we came up with (modified for a Tuesday release, not > a Monday release), working backward: > > RH Summit May 9-11 > Release April 24 (exactly 6 months after FC6) > Gold April 17 > Test3 March 27 > Test2 February 27 > FudCon February 9-11 (including hackfest) > Test1 January 30 > > Not a lot of slip time in there (at least, not with the RH Summit as a > target). > > Comments? [long-ish time reader, first-time poster... see bottom for list intro.] Has Fedora, the community, actively post-mortemed past slips? If so, what were the most likely causes of past slips, and what steps are you taking to avoid them this time around? If not, it seems like, given the particularly hard deadline for this release, this is a good thing to talk about now, rather than later :) For what it is worth, my sense as an outsider is that past releases have lacked discipline about flagging and backing out problematic features, and have failed to aggressively seek community quality assurance early in the process, which has led to slips. But obviously those are very much external impressions that should be taken with a grain of salt, particularly given that my biases are very much in favor of very early and aggressive QA. Luis Introduction bits, shamelessly plagiarized from my introduction to the now-defunct fedora-advisors-list: Dramatic Life Story: Hi, I'm Luis Villa. Most of you may know me from such runaway successes as 'Bugmaster[1]', 'Bugmaster II: Evolution', 'Bugmaster III: GNOME 2.0', and perhaps from less noted work such as 'Bugmaster IV', in which your hero had his ass handed to him by Novell Linux Desktop. I had a permanent role in 'All My Monkeys[2]' as Louie, the lovable but moronic zookeeper, but left after the management decided to take the show more upscale and downplay my character. I've also played a recurring role in 'Days of Our GNOME Foundation Board[3]' as Dr. Luis Villa, IV, muckraker and all-around scoundrel, but with a heart of gold. My head^wsculpted likeness is in the GNOME Planet Walk of Fame[4]. I spent a year as Sr. Geek in Residence at Harvard Law School's Berkman Center for Internet and Society, and am now in my first year as a law school at Columbia Law School, where I intend to study intellectual property law and other areas of law related to online, voluntary communities. Dramatic (by which I meant two-timing) Technical Story: While I am admittedly right ATM an Ubuntu user ;) I'm a fairly long-time Red Hat user (from the Donnie Barnes Is Something Like A Foreign Language release- 5.1? 5.0? up until a few days after Novell bought SUSE.) Dramatic (by which I mean boring) reason for being on this list: Obviously I have a lot of community background, and I know a lot of the Red Hat and Fedora team and am good friends with them. I'm interested in helping advise Fedora not just because I want to help them out, but also because I firmly believe that having successful Linux distros that are truly community-centric is a must for the continue health and success of Free Software. [1] http://tieguy.org/talks/LCA-2005-paper-html/ [2] http:///www.ximian.com/ [2] http://mail.gnome.org/archives/foundation-announce/2004-December/msg00004.html [3] http://planet.gnome.org/ From gdk at redhat.com Tue Dec 12 22:45:50 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Tue, 12 Dec 2006 17:45:50 -0500 (EST) Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> Message-ID: On Tue, 12 Dec 2006, Max Spevack wrote: > On Tue, 12 Dec 2006, Thorsten Leemhuis wrote: > >> January 02 is probably to hard to reach, so we should cut one cycle from >> four to three weeks. Which one? test3 maybe? > > We talked about this in the Board meeting this morning. > > Here was the proposal we came up with (modified for a Tuesday release, not a > Monday release), working backward: > > RH Summit May 9-11 > Release April 24 (exactly 6 months after FC6) > Gold April 17 > Test3 March 27 > Test2 February 27 > FudCon February 9-11 (including hackfest) > Test1 January 30 > > Not a lot of slip time in there (at least, not with the RH Summit as a > target). > > Comments? Yeah, right now it's looking like FUDCon will be February 2-4. Full details to be announced early next week. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From jkeating at redhat.com Tue Dec 12 22:53:50 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 Dec 2006 17:53:50 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: References: <457D9F7D.8030007@leemhuis.info> Message-ID: <200612121753.50715.jkeating@redhat.com> On Tuesday 12 December 2006 17:40, Max Spevack wrote: > > RH Summit?????May 9-11 > > Release???????April 24 (exactly 6 months after FC6) > > Gold??????????April 17 > > Test3?????????March 27 > > Test2?????????February 27 > > FudCon????????February 9-11 (including hackfest) > > Test1?????????January 30 > > > > Not a lot of slip time in there (at least, not with the RH Summit as a > > target). > > > > Comments? Are these the release dates or the freeze dates? I see both "Gold" and "Release" listed, which makes me think these are freeze dates, but I could be wrong. > For example, Jesse, if you want to work in some mini-freezes, it should be > pretty reasonable for you to take a schedule like this and just decide > when you want them, right? Yes. I feel that the mini-freezes might be less structured and more based upon significant changes or features or bugfixes that we want to get exposure on before the next scheduled test release. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at fedoraproject.org Tue Dec 12 23:01:33 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 12 Dec 2006 17:01:33 -0600 Subject: Metrics: RFC In-Reply-To: <456C8EEC.3030502@redhat.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> <3237e4410611220750g3e28adafxefcda19ff086fd56@mail.gmail.com> <20061122161109.GB29804@domsch.com> <456477D1.5090603@redhat.com> <45647833.7090908@redhat.com> <456C896C.7070606@fedoraproject.org> <456C8EEC.3030502@redhat.com> Message-ID: <3237e4410612121501n607c11cfkf372da0777d5cf1c@mail.gmail.com> Attempting to restart thread. I suggest we get something in infrastructure and rawhide asap. I'm thinking an RPM to send stuff to us and integration with firstboot. All good and dandy but we'll have to have people actually implement it. Any volunteers? -Mike From davej at redhat.com Tue Dec 12 23:02:56 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 12 Dec 2006 18:02:56 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> Message-ID: <20061212230256.GM2140@redhat.com> On Tue, Dec 12, 2006 at 05:47:47PM -0500, Luis Villa wrote: > Has Fedora, the community, actively post-mortemed past slips? If so, > what were the most likely causes of past slips, and what steps are you > taking to avoid them this time around? I recall at least 2-3 issues last time around. * Xen being horked and taking forever to get working. Not particularly easy to fix given we're at times dependant upon an unresponsive upstream. * Trademark braindamage. Not much we can do here either, other than pick sane upstream sources. * Discovery of late breaking nasty bugs (Like the ext3-went-boom bug) Whilst we'd all like it if this weren't to repeat itself ever again, it can't be ruled out. Sometimes things just fall out of testing late in the cycle, and right before release is when we really stress things as much as possible. There were probably other slip reasons too, but they're the ones still fresh in my mind. Oh, and there was the 'not really test4, but sort of' release that was needed because test3, well.. stunk. There were a number of really nasty bugs in that which meant it wouldn't even install for quite a few people. How that one got out the building alive is anyones guess. Our internal testing procedures have hopefully improved since then though, and with the livecd on the horizon, we should see some of the 'it doesnt boot' bugs a lot sooner if we do daily spins of that iso and push it out with the daily rawhide push. > Dramatic (by which I mean boring) reason for being on this list: > Obviously I have a lot of community background, and I know a lot of > the Red Hat and Fedora team and am good friends with them. I'm > interested in helping advise Fedora not just because I want to help > them out, but also because I firmly believe that having successful > Linux distros that are truly community-centric is a must for the > continue health and success of Free Software. Good to have you around, we value your input :-) Dave -- http://www.codemonkey.org.uk From jkeating at redhat.com Tue Dec 12 23:09:41 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 Dec 2006 18:09:41 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <20061212230256.GM2140@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> Message-ID: <200612121809.41313.jkeating@redhat.com> On Tuesday 12 December 2006 18:02, Dave Jones wrote: > Oh, and there was the 'not really test4, but sort of' release that > was needed because test3, well.. stunk. ? There were a number of really > nasty bugs in that which meant it wouldn't even install for quite a > few people. How that one got out the building alive is anyones guess. > Our internal testing procedures have hopefully improved since then though, > and with the livecd on the horizon, we should see some of the > 'it doesnt boot' bugs a lot sooner if we do daily spins of that iso > and push it out with the daily rawhide push. Well, I couldn't duplicate these problems on any of the systems I was doing validation on. Unfortunately we were hoping that more people were actually trying to install rawhide more often than they were, instead of just doing yum updates. I plan on using mini-freezes and more snapshot iso releases to aid in this, so that more people are trying the install that way rather than just yum update. Hopefully we'll catch more braindead stuff this way. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Tue Dec 12 23:12:15 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 12 Dec 2006 18:12:15 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> Message-ID: <20061212231215.GB23764@nostromo.devel.redhat.com> Greg Dekoenigsberg (gdk at redhat.com) said: > Yeah, right now it's looking like FUDCon will be February 2-4. Full > details to be announced early next week. It changed? Bill From luis at tieguy.org Tue Dec 12 23:47:38 2006 From: luis at tieguy.org (Luis Villa) Date: Tue, 12 Dec 2006 18:47:38 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> Message-ID: <2cb10c440612121547h19be0caajb38ed259c67b448c@mail.gmail.com> On 12/12/06, Luis Villa wrote: > Introduction bits, shamelessly plagiarized from my introduction to the > now-defunct fedora-advisors-list: And in response to an off-list question, that is Luis pronounced like Jerry Lewis. Luis From jwboyer at jdub.homelinux.org Wed Dec 13 01:32:02 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 12 Dec 2006 19:32:02 -0600 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <200612121809.41313.jkeating@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <200612121809.41313.jkeating@redhat.com> Message-ID: <1165973522.4812.12.camel@vader.jdub.homelinux.org> On Tue, 2006-12-12 at 18:09 -0500, Jesse Keating wrote: > On Tuesday 12 December 2006 18:02, Dave Jones wrote: > > Oh, and there was the 'not really test4, but sort of' release that > > was needed because test3, well.. stunk. There were a number of really > > nasty bugs in that which meant it wouldn't even install for quite a > > few people. How that one got out the building alive is anyones guess. > > Our internal testing procedures have hopefully improved since then though, > > and with the livecd on the horizon, we should see some of the > > 'it doesnt boot' bugs a lot sooner if we do daily spins of that iso > > and push it out with the daily rawhide push. > > Well, I couldn't duplicate these problems on any of the systems I was doing > validation on. Unfortunately we were hoping that more people were actually > trying to install rawhide more often than they were, instead of just doing > yum updates. I plan on using mini-freezes and more snapshot iso releases to > aid in this, so that more people are trying the install that way rather than > just yum update. Hopefully we'll catch more braindead stuff this way. Bit of a chicken/egg problem, but I intend to try every test release via a xen instance if it's possible. As this technology moves forward, I think it's going to become more and more common for people to use virtual machines for initial testing. Not many folks have spare machines laying around and xen, kvm, openvz, vmware, $virt-tech-of-the-day make it "easy" to test some of the new shiny stuff while keeping their machines stable. josh From davej at redhat.com Wed Dec 13 01:52:46 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 12 Dec 2006 20:52:46 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <1165973522.4812.12.camel@vader.jdub.homelinux.org> References: <457D9F7D.8030007@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <200612121809.41313.jkeating@redhat.com> <1165973522.4812.12.camel@vader.jdub.homelinux.org> Message-ID: <20061213015246.GO2140@redhat.com> On Tue, Dec 12, 2006 at 07:32:02PM -0600, Josh Boyer wrote: > Bit of a chicken/egg problem, but I intend to try every test release via > a xen instance if it's possible. As this technology moves forward, I > think it's going to become more and more common for people to use > virtual machines for initial testing. Not many folks have spare > machines laying around and xen, kvm, openvz, vmware, > $virt-tech-of-the-day make it "easy" to test some of the new shiny stuff > while keeping their machines stable. That's not a panacea though, the majority of "doesnt boot/install" problems we saw affected bare-metal, and the Xen variants are different enough in some cases that they make a difference. Dave -- http://www.codemonkey.org.uk From luis at tieguy.org Wed Dec 13 03:48:54 2006 From: luis at tieguy.org (Luis Villa) Date: Tue, 12 Dec 2006 22:48:54 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <20061212230256.GM2140@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> Message-ID: <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> NB: Most of this email will probably seem obvious, since everyone here is experienced and intelligent. I offer it on the off chance that it isn't obvious, and in the hope that it will spur everyone to ask questions and think critically about assumptions Fedora may have carried over from RH that should be examined in light of the different goals a community project has from an enterprise operating system. On 12/12/06, Dave Jones wrote: > On Tue, Dec 12, 2006 at 05:47:47PM -0500, Luis Villa wrote: > > > Has Fedora, the community, actively post-mortemed past slips? If so, > > what were the most likely causes of past slips, and what steps are you > > taking to avoid them this time around? > > I recall at least 2-3 issues last time around. > > * Xen being horked and taking forever to get working. > Not particularly easy to fix given we're at times dependant upon > an unresponsive upstream. So what would the plan be for a similar problem in the FC7 schedule? Lets call this 'feature X'. Possible options would be: (0) Prevent feature X from going into distro trunk until feature X was actually ready-ish, such that there was never risk of delay from feature X. (1) back feature X out completely, or at least to the FC6 state. (2) admit that feature X will not work in FC7. (3) delay FC7. In my ideal development world, one aims for (0) as much as possible; In GNOME, we'd typically do (1); it seems like in FC6 with Zen you chose (3). I would have suggested in the Xen case that you should have done (2), since I presume Xen is too tightly tied to the kernel to allow for (0) or (1). Why did you do (3) instead? Commitment to feature based releases over time-based releases? Some other reason? Focusing on the future, what is Fedora's plan for the Feature X (which will almost inevitably occur) in FC7? (0)? (1)? (2)? (3)? None of the above? [Note that (3) doesn't seem to be an option, given the hard deadline, which suggests FC needs to assess 0-2 and set policies for how to choose between 0, 1, and 2.] I'd also note that (3) makes a ton of sense in an enterprise OS context, where you've made hard commitments to customers about feature lists, so that 0/1 (and particularly 2) are not options. This is the kind of thing where Fedora can be (should be?) different from internal RH engineering processes, I think. But that is an explicit policy choice- to be time-based, and not feature-based- that Fedora's leadership should explicitly think about and choose. > * Trademark braindamage. > Not much we can do here either, other than pick sane upstream sources. Agreed that it seems that 0,1, and 2 aren't really options in this situation, so I agree you probably had to do (3) here, given the situation. (I assume this is Firefox? Or something else?) Since it is specifically external legal liability that prevents (2), that suggests being as proactive as possible about all *legal* issues in order to avoid delays. Understanding that perfect foresight is impossible, who is in charge of assessing legal issues and being the best humanly possible lookout for legal icebergs? What are they doing right now to help meet this proposed schedule? Perhaps similarly, I assume you might have other sorts of 'hard' commitments which prevent doing (2) in other cases- marketing commitments, perhaps, or... dunno? Is there a rubric for assessing which things fall into (2)(OK to ship with them broken) and which things fall into (3)(must delay?) Again, this is a Fedora leadership policy choice that (it seems to be) should be done explicitly, and done now, so that everything is more predictable and smooth at the end of the cycle. (It is probably already done, but as the naive outsider I don't know about it :), in which case the question is 'why didn't it catch the trademark and Xen things'.) > * Discovery of late breaking nasty bugs (Like the ext3-went-boom bug) > Whilst we'd all like it if this weren't to repeat itself ever again, > it can't be ruled out. Sometimes things just fall out of testing late > in the cycle, and right before release is when we really stress things > as much as possible. Probably again a naive question, but why were changes to something as critical as the file system being made late enough in the game to delay the release? Aren't there freezes for such things? This sounds like a good candidate for option (0)- prevent it from getting into the tree in the first place by testing it in a branch, or not accepting code churn in critical subsystems further out from release. Probably more usefully, if for some reason you can't have earlier freezes for critical, complex subsystems, who is in charge of encouraging early stress testing? Is there someone whose job it is to evangelize widespread testing? > Oh, and there was the 'not really test4, but sort of' release that > was needed because test3, well.. stunk. There were a number of really > nasty bugs in that which meant it wouldn't even install for quite a > few people. How that one got out the building alive is anyones guess. 'How that one got out of the building' sounds like a really critical question to answer. Maybe *the* critical question to answer if you're seriously planning on getting FC7 out on time. I think from your comments about increased testing, you have a better answer than you let on here, but it seems like it would be a good idea to make it explicit and figure out what the policy is for the future. Probably you already have, and I'm just making everyone slog through it again, but just in case... :) On 12/12/06, Jesse Keating wrote: > Unfortunately we were hoping that more people were actually > trying to install rawhide more often than they were, instead of just doing > yum updates. So that's one answer to 'how did that one get out of the building' :) Again, then, who is in charge of evangelizing such testing during FC7? So, yeah... it sounds like some more post-morteming might be needed, and some work on policy. More questions that you could ask, besides 'why did it go wrong last time?' would be things like how does Fedora define a showstopper? What are the most-preferred/least-preferred methods for coping with a showstopper? For a given problem, who gets to choose between those methods? Who is in charge of proactively finding showstoppers as early as possible? Who is in charge of creating communities of people who find showstoppers as early as possible? What methods can be put in place to prevent showstoppers from getting into the trunk in the first place? Some of these questions are obviously already answered, or being answered- for example, I know the work on revision control systems will make it easier to keep things out of the trunk, and to revert to working versions if they do break. But the more *explicit* Fedora is about answering these questions and making policy about them now, instead of towards the end of a cycle, the better the chances of getting Fedora out on time in the future. HTH- Luis From riel at redhat.com Wed Dec 13 03:52:29 2006 From: riel at redhat.com (Rik van Riel) Date: Tue, 12 Dec 2006 22:52:29 -0500 Subject: Fedora Freedom? In-Reply-To: <20061208111901.4815e917@alkaid.a.lan> References: <45760196.2080807@redhat.com> <20061208111901.4815e917@alkaid.a.lan> Message-ID: <457F78FD.9030801@redhat.com> Andreas Bierfert wrote: > On Tue, 05 Dec 2006 18:32:38 -0500 > Warren Togami wrote: > >> I propose that we call the Fedora universe collection "Fedora Freedom". > -1 > > Just reminds me to much of Freedom Fries which I dearly hate. > > Fedora > +1 +1 on Fedora FU is just not a friendly acronym :) -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. From tibbs at math.uh.edu Wed Dec 13 04:53:19 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Dec 2006 22:53:19 -0600 Subject: Fedora Freedom? In-Reply-To: <457F78FD.9030801@redhat.com> References: <45760196.2080807@redhat.com> <20061208111901.4815e917@alkaid.a.lan> <457F78FD.9030801@redhat.com> Message-ID: >>>>> "RvR" == Rik van Riel writes: RvR> FU is just not a friendly acronym :) You might very well think that; I couldn't possibly comment. - J< From davej at redhat.com Wed Dec 13 05:30:44 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 13 Dec 2006 00:30:44 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> Message-ID: <20061213053044.GR2140@redhat.com> On Tue, Dec 12, 2006 at 10:48:54PM -0500, Luis Villa wrote: > > * Xen being horked and taking forever to get working. > > Not particularly easy to fix given we're at times dependant upon > > an unresponsive upstream. > > (0) Prevent feature X from going into distro trunk until feature X was > actually ready-ish, such that there was never risk of delay from > feature X. > (1) back feature X out completely, or at least to the FC6 state. > (2) admit that feature X will not work in FC7. > (3) delay FC7. > > I would have suggested in the Xen case that you should have done (2), > since I presume Xen is too tightly tied to the kernel to allow for (0) > or (1). Why did you do (3) instead? Commitment to feature based > releases over time-based releases? Some other reason? It was deemed "must have" functionality for a number of reasons. Two obvious ones being: 1. dropping it would be a regression vs FC5. 2. It's a major line item for RHEL5, and Fedora is supposedly where stuff like this gets beaten into shape first. > Focusing on the future, what is Fedora's plan for the Feature X (which > will almost inevitably occur) in FC7? (0)? (1)? (2)? (3)? None of the > above? [Note that (3) doesn't seem to be an option, given the hard > deadline, which suggests FC needs to assess 0-2 and set policies for > how to choose between 0, 1, and 2.] Right now, as far as Xen goes, I'm sitting on the fence waiting to see where things land. With most of our virtualisation team tied up in hammering out RHEL5, and Xensource sitting on their thumbs wrt pushing stuff upstream, I'm not optimistic at all that anything notable will happen. The grim meathook future currently looks like this: * Xensource's Xen tree is based on 2.6.16 (Yes, sixteen) * FC6 has a 2.6.18 kernel and a rebase of Xen that Red Hat did. * kernel.org current stable is .19 We can't move to this as an FC6 update until we get Xen in shape. Juan mentioned that he's going to jump on this soon, but its probably at least a weeks work. * devel/ is current on the road toward .20rc1, and hasn't got Xen applied at all (zillions of rejects). I find it hard to talk about Xen in person without cursing. Really. > I'd also note that (3) makes a ton of sense in an enterprise OS > context, where you've made hard commitments to customers about feature > lists, so that 0/1 (and particularly 2) are not options. This is the > kind of thing where Fedora can be (should be?) different from internal > RH engineering processes, I think. But that is an explicit policy > choice- to be time-based, and not feature-based- that Fedora's > leadership should explicitly think about and choose. tbh, I agree with you. Fedora should not be hostage to RHEL feature requirements. Merging Xen was the single biggest headache I've faced in kernel maintainence in the last 3.5 years. Even NPTL against the RHL 2.4 kernels was a walk in the park compared to this fiasco. > > * Trademark braindamage. > > Not much we can do here either, other than pick sane upstream sources. > Agreed that it seems that 0,1, and 2 aren't really options in this > situation, so I agree you probably had to do (3) here, given the > situation. (I assume this is Firefox? Or something else?) Someone else. I'm not sure if it's public, so I probably shouldn't say anything more (though its probably not hard to figure out). > Since it is specifically external legal liability that prevents (2), > that suggests being as proactive as possible about all *legal* issues > in order to avoid delays. Understanding that perfect foresight is > impossible, who is in charge of assessing legal issues and being the > best humanly possible lookout for legal icebergs? What are they doing > right now to help meet this proposed schedule? Red Hat legal is pretty much the gatekeeper for such issues. > > * Discovery of late breaking nasty bugs (Like the ext3-went-boom bug) > > Whilst we'd all like it if this weren't to repeat itself ever again, > > it can't be ruled out. Sometimes things just fall out of testing late > > in the cycle, and right before release is when we really stress things > > as much as possible. > > Probably again a naive question, but why were changes to something as > critical as the file system being made late enough in the game to > delay the release? The bug in question had been there for months. It turned out that it only affected filesystems made with 1K block sizes, which isn't the default, but we didn't know that at first. As this was a corner case, it unsurprisingly didn't get a great deal of testing. > Probably more usefully, if for some reason you can't have earlier > freezes for critical, complex subsystems, who is in charge of > encouraging early stress testing? Is there someone whose job it is to > evangelize widespread testing? That'll be Will Woods , Fedora QA lead. > > Oh, and there was the 'not really test4, but sort of' release that > > was needed because test3, well.. stunk. There were a number of really > > nasty bugs in that which meant it wouldn't even install for quite a > > few people. How that one got out the building alive is anyones guess. > > 'How that one got out of the building' sounds like a really critical > question to answer. Maybe *the* critical question to answer if you're > seriously planning on getting FC7 out on time. I think from your > comments about increased testing, you have a better answer than you > let on here, but it seems like it would be a good idea to make it > explicit and figure out what the policy is for the future. Probably > you already have, and I'm just making everyone slog through it again, > but just in case... :) Towards the end of FC6 dev cycle, we did a few things differently to improve things. * bi-weekly status meetings. Just a half hour concall to make sure everyone knew the state of the onion. * Will started hashing out test plans. * Some process documentation got put on the wiki. * I believe there are weekly(?) test team irc meetings. Something else that should see the light of day at some point will be the eventual opening of our internal QA test harnesses (along with some of the tests that we put a RHEL release through). Getting stuff like this into the hands of eager wannabe testers is going to be really useful. > More questions that you could ask, besides 'why did it go wrong last > time?' would be things like how does Fedora define a showstopper? Basically 'blocking' criteria is something like.. * large class of machines doesn't boot * really common machine doesn't boot * installer falls over really easily with no workaround * common network cards don't work (preventing updates). It's spelled out a lot better than my feeble memory can remember somewhere on the fedoraproject.org wiki. Good questions. I snipped some of them that I felt others could answer better than I could, but I hope the above helps. Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Wed Dec 13 05:52:06 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Dec 2006 06:52:06 +0100 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> Message-ID: <457F9506.4090602@leemhuis.info> On 12.12.2006 23:37, Max Spevack wrote: > On Tue, 12 Dec 2006, Thorsten Leemhuis wrote: >> January 02 is probably to hard to reach, so we should cut one cycle from >> four to three weeks. Which one? test3 maybe? > We talked about this in the Board meeting this morning. thx > Here was the proposal we came up with (modified for a Tuesday release, not > a Monday release), working backward: > > RH Summit May 9-11 > Release April 24 (exactly 6 months after FC6) BTW, that sounds as we stick to the 6 month release cycle again. I thought there was some consensus from the last discussion that a long term foreseeable release cycle (such as the one from Gnome) is a good thing and that we want to aim for Early/Mid April and Early/Mid October. The above now is nearly late April (without slipping). So do people simply dislike the "long term foreseeable release cycle" or was it simply forgotten again? Or could the board simply discuss this once? > Gold April 17 > Test3 March 27 > Test2 February 27 > FudCon February 9-11 (including hackfest) > Test1 January 30 > > Not a lot of slip time in there (at least, not with the RH Summit as a > target). Agreed, I would feel much more comfortable if we would have two weeks puffer. CU thl From fedora at leemhuis.info Wed Dec 13 05:56:55 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Dec 2006 06:56:55 +0100 Subject: Fedora 7 planing In-Reply-To: <1165938368.13183.11.camel@metroid.rdu.redhat.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <1165938368.13183.11.camel@metroid.rdu.redhat.com> Message-ID: <457F9627.4020905@leemhuis.info> On 12.12.2006 16:46, Will Woods wrote: > On Tue, 2006-12-12 at 07:12 +0100, Thorsten Leemhuis wrote: >> With 4 weeks for each test cycle that would mean: >> January 02 -- Test 1 >> January 30 -- Test 2 >> February 27 -- Test 3 >> March 27 -- Final Release >> January 02 is probably to hard to reach, so we should cut one cycle from >> four to three weeks. Which one? test3 maybe? > If you have to cut a week from one cycle, I'd make it Test1. Test1 is > the most likely to be broken in some unanticipated way, so it would be a > good idea to plan for a (slightly) quicker followup release to that one. > > Also, I'd like to have a full 4 weeks after the No-Foolin' > Seriously-Guys This-Is-It Feature Freeze (Test3) to make sure we've got > the kinks worked out. > > Does that sound reasonable? Well, yes and no. I as a outsider got the impression that the freeze after test3 is to long and to much people don't take it serious. *Maybe* it would be better if test3 (or name it rc1?) would really be a hard freeze. Something like "hey guys, test3 is really close to final; get you shit in place by test3, there is not much time left after it to fix stuff." Well, as I said, that what it looks to me as an outsider. CU thl From fedora at leemhuis.info Wed Dec 13 06:02:49 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Dec 2006 07:02:49 +0100 Subject: Fedora Foo (was Re: Fedora Freedom?) In-Reply-To: <457F78FD.9030801@redhat.com> References: <45760196.2080807@redhat.com> <20061208111901.4815e917@alkaid.a.lan> <457F78FD.9030801@redhat.com> Message-ID: <457F9789.5030006@leemhuis.info> On 13.12.2006 04:52, Rik van Riel wrote: > Andreas Bierfert wrote: >> On Tue, 05 Dec 2006 18:32:38 -0500 >> Warren Togami wrote: >>> I propose that we call the Fedora universe collection "Fedora Freedom". >> -1 >> Just reminds me to much of Freedom Fries which I dearly hate. >> Fedora >> +1 > +1 on Fedora That seems to be the consensus (and was agreed on by the board afaics). But I'd really like to see a semi-official name for our internal discussions as the generic name "Fedora" often it to unclear what we are talking about (the Project? the packages mix of what was formally known as Core and Extras? Something else?). Suggestions? Fedora Packages? Fedora Package Universe? Cu thl From fedora at leemhuis.info Wed Dec 13 07:35:51 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Dec 2006 08:35:51 +0100 Subject: Xen delaying FC6 (Was: Re: fedora 7 schedule (was Re: Fedora 7 planing)) In-Reply-To: <20061212230256.GM2140@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> Message-ID: <457FAD57.9020505@leemhuis.info> On 13.12.2006 00:02, Dave Jones wrote: > On Tue, Dec 12, 2006 at 05:47:47PM -0500, Luis Villa wrote: > > Has Fedora, the community, actively post-mortemed past slips? If so, > > what were the most likely causes of past slips, and what steps are you > > taking to avoid them this time around? > I recall at least 2-3 issues last time around. > * Xen being horked and taking forever to get working. > Not particularly easy to fix given we're at times dependant upon > an unresponsive upstream. [...] I feels your pain dave. But there seems to be some mis-function in the internal red hat workflow shortly before the FC6 release afaics when I look at a xen kernel bug that was part of the reasons for the last delay. I'm talking about https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211097 (yes, I reported that) The whole thing in detail: - Release was planed for 19 Oct 2006 at that time - On Oct 14 2006 (that's a Saturday) the Xen patchset in the kernel got a major update - It seems not even teh xen-maintainers tried if xen was still working after that update: The xen update required newer xen userland bits, too, but those were not pushed; that remained unnoticed until Oct 17 2006. See the bug for some details. It got and quickly fixed then, but this was one of the reasons why the release got delayed yet again https://www.redhat.com/archives/fedora-announce-list/2006-October/msg00006.html The whole issue looked extremely unprofessional to me as it happened quite shortly before the release. What do we do to prevent such damage in the future? CU thl From sundaram at fedoraproject.org Wed Dec 13 08:17:34 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 Dec 2006 13:47:34 +0530 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <20061213053044.GR2140@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <20061213053044.GR2140@redhat.com> Message-ID: <457FB71E.8010903@fedoraproject.org> Dave Jones wrote: > > Towards the end of FC6 dev cycle, we did a few things differently > to improve things. > * bi-weekly status meetings. Just a half hour concall to make > sure everyone knew the state of the onion. > * Will started hashing out test plans. > * Some process documentation got put on the wiki. > * I believe there are weekly(?) test team irc meetings. http://fedoraproject.org/wiki/QA has the release criteria, weekly QA meetings and the test suite roadmap. Rahul From luis at tieguy.org Wed Dec 13 12:43:03 2006 From: luis at tieguy.org (Luis Villa) Date: Wed, 13 Dec 2006 07:43:03 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <20061213053044.GR2140@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <20061213053044.GR2140@redhat.com> Message-ID: <2cb10c440612130443o1b2ec4d9p9d208c9a68c84b6f@mail.gmail.com> On 12/13/06, Dave Jones wrote: > On Tue, Dec 12, 2006 at 10:48:54PM -0500, Luis Villa wrote: > > > > * Xen being horked and taking forever to get working. > > > Not particularly easy to fix given we're at times dependant upon > > > an unresponsive upstream. > > > > (0) Prevent feature X from going into distro trunk until feature X was > > actually ready-ish, such that there was never risk of delay from > > feature X. > > (1) back feature X out completely, or at least to the FC6 state. > > (2) admit that feature X will not work in FC7. > > (3) delay FC7. > > > > I would have suggested in the Xen case that you should have done (2), > > since I presume Xen is too tightly tied to the kernel to allow for (0) > > or (1). Why did you do (3) instead? Commitment to feature based > > releases over time-based releases? Some other reason? > > It was deemed "must have" functionality for a number of reasons. > Two obvious ones being: > 1. dropping it would be a regression vs FC5. > 2. It's a major line item for RHEL5, and Fedora is supposedly > where stuff like this gets beaten into shape first. (1) makes sense, though in that case there is an obvious question about 'why was that last, broken patchset allowed in so late?' As far as (2) goes, I thought Fedora was an independent project? > > Focusing on the future, what is Fedora's plan for the Feature X (which > > will almost inevitably occur) in FC7? (0)? (1)? (2)? (3)? None of the > > above? [Note that (3) doesn't seem to be an option, given the hard > > deadline, which suggests FC needs to assess 0-2 and set policies for > > how to choose between 0, 1, and 2.] > > Right now, as far as Xen goes, I'm sitting on the fence waiting to see > where things land. With most of our virtualisation team tied up in > hammering out RHEL5, and Xensource sitting on their thumbs wrt pushing > stuff upstream, I'm not optimistic at all that anything notable will happen. > The grim meathook future currently looks like this: > > * Xensource's Xen tree is based on 2.6.16 (Yes, sixteen) > * FC6 has a 2.6.18 kernel and a rebase of Xen that Red Hat did. > * kernel.org current stable is .19 > We can't move to this as an FC6 update until we get Xen in shape. > Juan mentioned that he's going to jump on this soon, but its probably > at least a weeks work. > * devel/ is current on the road toward .20rc1, and hasn't got Xen > applied at all (zillions of rejects). > > I find it hard to talk about Xen in person without cursing. Really. That makes the question even more pressing, then. Assume Xen is horribly broken come April 23rd. What will Fedora do? What process will the board go through to make that decision? The earlier you know what that process is, the better you can plan. > > I'd also note that (3) makes a ton of sense in an enterprise OS > > context, where you've made hard commitments to customers about feature > > lists, so that 0/1 (and particularly 2) are not options. This is the > > kind of thing where Fedora can be (should be?) different from internal > > RH engineering processes, I think. But that is an explicit policy > > choice- to be time-based, and not feature-based- that Fedora's > > leadership should explicitly think about and choose. > > tbh, I agree with you. Fedora should not be hostage to RHEL feature requirements. > Merging Xen was the single biggest headache I've faced in kernel maintainence > in the last 3.5 years. Even NPTL against the RHL 2.4 kernels was a walk > in the park compared to this fiasco. So whose responsibility is it to make that call? (Or alternately, to public admit that that call can't be made?) Again, the earlier the policy is decided on, the better for everyone. > > Since it is specifically external legal liability that prevents (2), > > that suggests being as proactive as possible about all *legal* issues > > in order to avoid delays. Understanding that perfect foresight is > > impossible, who is in charge of assessing legal issues and being the > > best humanly possible lookout for legal icebergs? What are they doing > > right now to help meet this proposed schedule? > > Red Hat legal is pretty much the gatekeeper for such issues. Gatekeepers are by definition stationary and deal with problems that come to them :) Who from Fedora is responsible for pushing RH legal to work proactively on this kind of thing, or alternately, responsible for finding such problems and bringing them to RH legal ASAP? > > > * Discovery of late breaking nasty bugs (Like the ext3-went-boom bug) > > > Whilst we'd all like it if this weren't to repeat itself ever again, > > > it can't be ruled out. Sometimes things just fall out of testing late > > > in the cycle, and right before release is when we really stress things > > > as much as possible. > > > > Probably again a naive question, but why were changes to something as > > critical as the file system being made late enough in the game to > > delay the release? > > The bug in question had been there for months. It turned out that > it only affected filesystems made with 1K block sizes, which isn't the > default, but we didn't know that at first. As this was a corner case, > it unsurprisingly didn't get a great deal of testing. Ah. Sucky. Admittedly no good way to deal with that, sort of begging for lots of testing, which I realize is hard (despite my other questions :) > > Probably more usefully, if for some reason you can't have earlier > > freezes for critical, complex subsystems, who is in charge of > > encouraging early stress testing? Is there someone whose job it is to > > evangelize widespread testing? > > That'll be Will Woods , Fedora QA lead. Oh, great, glad there is an answer to that. (/me waves at Will if he is on this list.) > Towards the end of FC6 dev cycle, we did a few things differently > to improve things. > * bi-weekly status meetings. Just a half hour concall to make > sure everyone knew the state of the onion. Does Will have the power in these meetings to change priorities and direct engineering resources towards the end of a cycle? e.g., during the FC7 meetings, what will happen if he screams about Xen? :) > * Will started hashing out test plans. > * Some process documentation got put on the wiki. > * I believe there are weekly(?) test team irc meetings. > > Something else that should see the light of day at some point will be > the eventual opening of our internal QA test harnesses (along with > some of the tests that we put a RHEL release through). > Getting stuff like this into the hands of eager wannabe testers > is going to be really useful. Yeah, sounds like it. > > More questions that you could ask, besides 'why did it go wrong last > > time?' would be things like how does Fedora define a showstopper? > > Basically 'blocking' criteria is something like.. > * large class of machines doesn't boot > * really common machine doesn't boot > * installer falls over really easily with no workaround > * common network cards don't work (preventing updates). > > It's spelled out a lot better than my feeble memory can remember > somewhere on the fedoraproject.org wiki. > > Good questions. I snipped some of them that I felt others could > answer better than I could, but I hope the above helps. Hope it at least starts discussion- that is all I can hope to do. Luis (everyone wish me luck on my Torts exam tomorrow.) From davej at redhat.com Wed Dec 13 14:23:22 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 13 Dec 2006 09:23:22 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <2cb10c440612130443o1b2ec4d9p9d208c9a68c84b6f@mail.gmail.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <20061213053044.GR2140@redhat.com> <2cb10c440612130443o1b2ec4d9p9d208c9a68c84b6f@mail.gmail.com> Message-ID: <20061213142322.GU2140@redhat.com> On Wed, Dec 13, 2006 at 07:43:03AM -0500, Luis Villa wrote: > > > I would have suggested in the Xen case that you should have done (2), > > > since I presume Xen is too tightly tied to the kernel to allow for (0) > > > or (1). Why did you do (3) instead? Commitment to feature based > > > releases over time-based releases? Some other reason? > > > > It was deemed "must have" functionality for a number of reasons. > > Two obvious ones being: > > 1. dropping it would be a regression vs FC5. > > 2. It's a major line item for RHEL5, and Fedora is supposedly > > where stuff like this gets beaten into shape first. > > (1) makes sense, though in that case there is an obvious question > about 'why was that last, broken patchset allowed in so late?' It wasn't. It was perpetually busted for months. > As far as (2) goes, I thought Fedora was an independent project? For the most part. However sometimes there is crossover, especially on big-ticket items like Xen. > > I find it hard to talk about Xen in person without cursing. Really. > > That makes the question even more pressing, then. Assume Xen is > horribly broken come April 23rd. What will Fedora do? What process > will the board go through to make that decision? The earlier you know > what that process is, the better you can plan. My vote is to drop it like a stone, and move on. Others may have differing opinions, but I'm tired of being screwed by an upstream that frankly, doesn't care about open source. Upstream kernel.org seems to be heading on a different path to virtualisation anyway (KVM for full-virt and lhype for paravirt). KVM is merged already, lhype needs a *lot* more work to get feature parity with xen, but is feasible by the time we get to thinking about RHEL6. > > tbh, I agree with you. Fedora should not be hostage to RHEL feature requirements. > > Merging Xen was the single biggest headache I've faced in kernel maintainence > > in the last 3.5 years. Even NPTL against the RHL 2.4 kernels was a walk > > in the park compared to this fiasco. > > So whose responsibility is it to make that call? (Or alternately, to > public admit that that call can't be made?) Again, the earlier the > policy is decided on, the better for everyone. Somewhere in rh engineering mgmt. Xen was a 'must have' for RHEL5. (Probably at least in part because Novl shipped same, and we needed feature parity). Just dropping this into RHEL5 without putting it into Fedora would've sacrificed a *lot* of testing. I'm not justifying that it's the right thing to do, but there are forces at play here pulling Fedora in two different directions. > > > Since it is specifically external legal liability that prevents (2), > > > that suggests being as proactive as possible about all *legal* issues > > > in order to avoid delays. Understanding that perfect foresight is > > > impossible, who is in charge of assessing legal issues and being the > > > best humanly possible lookout for legal icebergs? What are they doing > > > right now to help meet this proposed schedule? > > > > Red Hat legal is pretty much the gatekeeper for such issues. > > Gatekeepers are by definition stationary and deal with problems that > come to them :) Who from Fedora is responsible for pushing RH legal to > work proactively on this kind of thing, or alternately, responsible > for finding such problems and bringing them to RH legal ASAP? Max & Greg I guess ? > > Towards the end of FC6 dev cycle, we did a few things differently > > to improve things. > > * bi-weekly status meetings. Just a half hour concall to make > > sure everyone knew the state of the onion. > > Does Will have the power in these meetings to change priorities and > direct engineering resources towards the end of a cycle? e.g., during > the FC7 meetings, what will happen if he screams about Xen? :) iirc, Will joined rh just after half-way through the FC6 cycle, so FC7 will be his first real 'trial by fire'. He did cope admirably being thrown in at the deep end at during FC6 though, so I'm sure he'll pull the fire alarm if needed. > Luis (everyone wish me luck on my Torts exam tomorrow.) Now that's an exam I could get behind. http://www.strongbowinn.com/tortes.htm Good luck :) Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Dec 13 14:27:14 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 13 Dec 2006 09:27:14 -0500 Subject: Xen delaying FC6 (Was: Re: fedora 7 schedule (was Re: Fedora 7 planing)) In-Reply-To: <457FAD57.9020505@leemhuis.info> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <457FAD57.9020505@leemhuis.info> Message-ID: <20061213142714.GV2140@redhat.com> On Wed, Dec 13, 2006 at 08:35:51AM +0100, Thorsten Leemhuis wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211097 > > The whole thing in detail: > > - Release was planed for 19 Oct 2006 at that time > - On Oct 14 2006 (that's a Saturday) the Xen patchset in the kernel got > a major update > - It seems not even teh xen-maintainers tried if xen was still working > after that update: The xen update required newer xen userland bits, too, > but those were not pushed; that remained unnoticed until Oct 17 2006. > See the bug for some details. It got and quickly fixed then, but this > was one of the reasons why the release got delayed yet again > https://www.redhat.com/archives/fedora-announce-list/2006-October/msg00006.html > The whole issue looked extremely unprofessional to me as it happened > quite shortly before the release. What do we do to prevent such damage > in the future? I don't have the answers to this. I've tried to have as little to do with the clusterfuck that is Xen as possible (at least in part because I'm *buried alive* in bare-metal bugs without looking at virt bugs). Perhaps someone else remembers exactly what happened, but looking at the bug and your timeline, yes, something did go horribly wrong somewhere that should again, have been caught before it even got pushed out to rawhide. Dave -- http://www.codemonkey.org.uk From gdk at redhat.com Wed Dec 13 14:31:14 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 13 Dec 2006 09:31:14 -0500 (EST) Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <20061212231215.GB23764@nostromo.devel.redhat.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <20061212231215.GB23764@nostromo.devel.redhat.com> Message-ID: On Tue, 12 Dec 2006, Bill Nottingham wrote: > Greg Dekoenigsberg (gdk at redhat.com) said: >> Yeah, right now it's looking like FUDCon will be February 2-4. Full >> details to be announced early next week. > > It changed? Yep. The venue was not clear 9-11, but it was for 2-4, which was the secondary date I gave to the folks at BU. > Bill > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > -- ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From gdk at redhat.com Wed Dec 13 14:38:48 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 13 Dec 2006 09:38:48 -0500 (EST) Subject: Fedora Foo (was Re: Fedora Freedom?) In-Reply-To: <457F9789.5030006@leemhuis.info> References: <45760196.2080807@redhat.com> <20061208111901.4815e917@alkaid.a.lan> <457F78FD.9030801@redhat.com> <457F9789.5030006@leemhuis.info> Message-ID: On Wed, 13 Dec 2006, Thorsten Leemhuis wrote: > That seems to be the consensus (and was agreed on by the board afaics). But > I'd really like to see a semi-official name for our internal discussions as > the generic name "Fedora" often it to unclear what we are talking about (the > Project? the packages mix of what was formally known as Core and Extras? > Something else?). > > Suggestions? Fedora Packages? Fedora Package Universe? I will continue to use "Fedora Star". --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From gdk at redhat.com Wed Dec 13 14:50:42 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 13 Dec 2006 09:50:42 -0500 (EST) Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <2cb10c440612130443o1b2ec4d9p9d208c9a68c84b6f@mail.gmail.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <20061213053044.GR2140@redhat.com> <2cb10c440612130443o1b2ec4d9p9d208c9a68c84b6f@mail.gmail.com> Message-ID: On Wed, 13 Dec 2006, Luis Villa wrote: > Luis (everyone wish me luck on my Torts exam tomorrow.) Ooo! I recommend a walnut raspberry tort. I'm sure that will wow the judges. My wife has some recipes she'd be glad to share. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From skvidal at linux.duke.edu Wed Dec 13 15:04:27 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 13 Dec 2006 10:04:27 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> Message-ID: <1166022267.31669.3.camel@cutter> On Tue, 2006-12-12 at 22:48 -0500, Luis Villa wrote: > NB: Most of this email will probably seem obvious, since everyone here > is experienced and intelligent. I offer it on the off chance that it > isn't obvious, and in the hope that it will spur everyone to ask > questions and think critically about assumptions Fedora may have > carried over from RH that should be examined in light of the different > goals a community project has from an enterprise operating system. > > On 12/12/06, Dave Jones wrote: > > On Tue, Dec 12, 2006 at 05:47:47PM -0500, Luis Villa wrote: > > > > > Has Fedora, the community, actively post-mortemed past slips? If so, > > > what were the most likely causes of past slips, and what steps are you > > > taking to avoid them this time around? > > > > I recall at least 2-3 issues last time around. > > > > * Xen being horked and taking forever to get working. > > Not particularly easy to fix given we're at times dependant upon > > an unresponsive upstream. > > So what would the plan be for a similar problem in the FC7 schedule? > Lets call this 'feature X'. Possible options would be: > (0) Prevent feature X from going into distro trunk until feature X was > actually ready-ish, such that there was never risk of delay from > feature X. > (1) back feature X out completely, or at least to the FC6 state. > (2) admit that feature X will not work in FC7. > (3) delay FC7. > > In my ideal development world, one aims for (0) as much as possible; > In GNOME, we'd typically do (1); it seems like in FC6 with Zen you > chose (3). > Cutting out a couple of the cases b/c I wanted to suggest something that sets fedora development apart from gnome development, for example. For a big part fedora doesn't control the feature set of the upstream package. If two of our guiding principles are: 1. run upstream and 2. run newest versions then we're being pushed ahead by things that are not entirely w/i our control. In gnome if feature X is not stabilized there's some room to say, "ok, not that one, walk it back, we have to release." but fedora is hard-pressed to make the same demand of gnome or kde or firefox. I'm not saying that we cannot do some amount of damage control but if the choice is: 1. patch out some feature (and therefore OWN that fork) 2. ship the newer, broken one 3. ship the older one None of those options are terribly good. And so the 4th option which no one loves is: 4. slip and hope that we can get the newer one fixed. Does that sum up a lot of what happens when fedora slips a release? -sv From jkeating at redhat.com Wed Dec 13 15:20:22 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Dec 2006 10:20:22 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <20061213142322.GU2140@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <2cb10c440612130443o1b2ec4d9p9d208c9a68c84b6f@mail.gmail.com> <20061213142322.GU2140@redhat.com> Message-ID: <200612131020.22728.jkeating@redhat.com> On Wednesday 13 December 2006 09:23, Dave Jones wrote: > iirc, Will joined rh just after half-way through the FC6 cycle, > so FC7 will be his first real 'trial by fire'. ?He did cope admirably > being thrown in at the deep end at during FC6 though, so I'm sure > he'll pull the fire alarm if needed. Well, he was with Red Hat prior to this, however his role as Fedora QA didn't start until then. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at fedoraproject.org Wed Dec 13 15:18:55 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 13 Dec 2006 09:18:55 -0600 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <1166022267.31669.3.camel@cutter> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <1166022267.31669.3.camel@cutter> Message-ID: <3237e4410612130718x6522e168p6d0ea5831a3e810d@mail.gmail.com> On 12/13/06, seth vidal wrote: > And so the 4th option which no one loves is: > 4. slip and hope that we can get the newer one fixed. > > Does that sum up a lot of what happens when fedora slips a release? > The fact is we need to plan on being flexible. Rigid rules will not work with our current release methods. As long as we're smart about what's going on during the test cycles we'll be in good shape. I think it would also be good to give 2 or 3 people veto power during the test freezes so that if feature X will cause a huge issue there's not a time-wasting argument about whether or not it gets in. It'll just have to wait until a later release or an update. -Mike From jkeating at redhat.com Wed Dec 13 15:23:41 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Dec 2006 10:23:41 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <1166022267.31669.3.camel@cutter> References: <457D9F7D.8030007@leemhuis.info> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <1166022267.31669.3.camel@cutter> Message-ID: <200612131023.41340.jkeating@redhat.com> On Wednesday 13 December 2006 10:04, seth vidal wrote: > Does that sum up a lot of what happens when fedora slips a release? Yes. Its a very damned if you do, damned if you don't situation. If you fork, you're damned to maintain your fork for N period of time, which nobody wants to do, plus you're damned because you didn't ship the latest version of Foo and the community hates you for it, and you're holding software hostage, and blah blah blah. However, if you just ship latest version of Foo, well then you're damned because you don't care about end users and you're holding software hostage, and blah blah blah. If we slip and try to put pressure on getting things fixed upstream, or at least a patch that is acceptable upstream even if they don't release with it yet, then we are still shipping close to or the latest of Foo, _and_ it maybe even works, plus we know our patch is going upstream so that we don't have to maintain our own fork for N period of time. But then we suck because we delayed the release and we're holding software hostage, and blah blah blah. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From luis at tieguy.org Wed Dec 13 15:24:00 2006 From: luis at tieguy.org (Luis Villa) Date: Wed, 13 Dec 2006 10:24:00 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <3237e4410612130718x6522e168p6d0ea5831a3e810d@mail.gmail.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <1166022267.31669.3.camel@cutter> <3237e4410612130718x6522e168p6d0ea5831a3e810d@mail.gmail.com> Message-ID: <2cb10c440612130724y759efc5dq94e85215b3e98947@mail.gmail.com> On 12/13/06, Mike McGrath wrote: > On 12/13/06, seth vidal wrote: > > And so the 4th option which no one loves is: > > 4. slip and hope that we can get the newer one fixed. > > > > Does that sum up a lot of what happens when fedora slips a release? > > > > The fact is we need to plan on being flexible. Rigid rules will not > work with our current release methods. As long as we're smart about > what's going on during the test cycles we'll be in good shape. I > think it would also be good to give 2 or 3 people veto power during > the test freezes so that if feature X will cause a huge issue there's > not a time-wasting argument about whether or not it gets in. To be clear, I'm not arguing for inflexible rules, I'm arguing for the group to discuss *goals* and flexible standards now, and appoint owners/deciders, so that when the deciders have to decide under pressure at the end of the cycle, their decision is quick, efficient, and reasonably matches up with the policies and goals of the larger group- i.e., it is as close to correct as one can get under the circumstances. Luis From luis at tieguy.org Wed Dec 13 15:24:41 2006 From: luis at tieguy.org (Luis Villa) Date: Wed, 13 Dec 2006 10:24:41 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <200612131023.41340.jkeating@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <1166022267.31669.3.camel@cutter> <200612131023.41340.jkeating@redhat.com> Message-ID: <2cb10c440612130724x41f8d82q8b427236b640ef05@mail.gmail.com> On 12/13/06, Jesse Keating wrote: > But then we suck because we > delayed the release and we're holding software hostage, and blah blah blah. If the policy is clear and predictable ahead of time instead of ad hoc, you'll get a lot less flak. Luis (yes, I'm procrastinating ;) From katzj at redhat.com Wed Dec 13 15:24:54 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 13 Dec 2006 10:24:54 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <457F9506.4090602@leemhuis.info> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <457F9506.4090602@leemhuis.info> Message-ID: <1166023494.2505.3.camel@aglarond.local> On Wed, 2006-12-13 at 06:52 +0100, Thorsten Leemhuis wrote: > On 12.12.2006 23:37, Max Spevack wrote: > > Here was the proposal we came up with (modified for a Tuesday release, not > > a Monday release), working backward: > > > > RH Summit May 9-11 > > Release April 24 (exactly 6 months after FC6) > > BTW, that sounds as we stick to the 6 month release cycle again. I > thought there was some consensus from the last discussion that a long > term foreseeable release cycle (such as the one from Gnome) is a good > thing and that we want to aim for Early/Mid April and Early/Mid October. > The above now is nearly late April (without slipping). > > So do people simply dislike the "long term foreseeable release cycle" or > was it simply forgotten again? Or could the board simply discuss this once? The problem is that I fundamentally don't see a way to pull in the current schedule (note: these are release dates, not the freeze dates, so the freeze ends up more early/mid April). For better or worse, the winter holiday season really messes with trying to play a little faster/looser with things for this time around. Jeremy From katzj at redhat.com Wed Dec 13 15:32:37 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 13 Dec 2006 10:32:37 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <2cb10c440612130443o1b2ec4d9p9d208c9a68c84b6f@mail.gmail.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <20061213053044.GR2140@redhat.com> <2cb10c440612130443o1b2ec4d9p9d208c9a68c84b6f@mail.gmail.com> Message-ID: <1166023957.2505.8.camel@aglarond.local> On Wed, 2006-12-13 at 07:43 -0500, Luis Villa wrote: > > > Since it is specifically external legal liability that prevents (2), > > > that suggests being as proactive as possible about all *legal* issues > > > in order to avoid delays. Understanding that perfect foresight is > > > impossible, who is in charge of assessing legal issues and being the > > > best humanly possible lookout for legal icebergs? What are they doing > > > right now to help meet this proposed schedule? > > > > Red Hat legal is pretty much the gatekeeper for such issues. > > Gatekeepers are by definition stationary and deal with problems that > come to them :) Who from Fedora is responsible for pushing RH legal to > work proactively on this kind of thing, or alternately, responsible > for finding such problems and bringing them to RH legal ASAP? We're actually very proactive here. A lot of it filters down to points like checking at package review and ongoing bits from individual package maintainers[1]. In this specific case, it wasn't something that could have been discovered sooner. There's not really anything that could have made it apparent sooner that I can see. Jeremy [1] With the breadth of things considered Fedora, it would be an impossible job to shackle one person with keeping track of all of it. From hp at redhat.com Wed Dec 13 15:47:24 2006 From: hp at redhat.com (Havoc Pennington) Date: Wed, 13 Dec 2006 10:47:24 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <1166022267.31669.3.camel@cutter> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <1166022267.31669.3.camel@cutter> Message-ID: <4580208C.4000608@redhat.com> Hi, As historical context, when I was proposing the "time-based release" thing for GNOME the idea was based on Red Hat Linux, which had a strict 6-month time-based cycle. Part of my logic was that GNOME was becoming more and more like a Linux distribution, in that it was a lot of independently-released modules without true central coordination. Because of this, time-based was the only way to guarantee getting a release out; there would never happen to be a time where all the upstreams were in sync. The rules surrounding time-based releases, both as we had them back in the Red Hat Linux days and as they are in GNOME today, are designed to deal with this. One of the important rules is that anything that goes on the to-be-released branch must be basically usable (dogfoodable, within a few bugfixes of shippable). For Red Hat Linux we usually phrased this rule as "you can't put any beta versions into the tree, only final released versions" The original mail goes into this a bit more: http://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html I was avoiding mention of Red Hat Linux back then since there were some political tensions it might have poked, but the idea was based on Red Hat Linux processes. seth vidal wrote: > > Cutting out a couple of the cases b/c I wanted to suggest something that > sets fedora development apart from gnome development, for example. > > For a big part fedora doesn't control the feature set of the upstream > package. If two of our guiding principles are: 1. run upstream and 2. > run newest versions then we're being pushed ahead by things that are not > entirely w/i our control. > > In gnome if feature X is not stabilized there's some room to say, "ok, > not that one, walk it back, we have to release." but fedora is > hard-pressed to make the same demand of gnome or kde or firefox. > > I'm not saying that we cannot do some amount of damage control but if > the choice is: > 1. patch out some feature (and therefore OWN that fork) > 2. ship the newer, broken one > 3. ship the older one > > None of those options are terribly good. Both the GNOME and the historical Red Hat Linux take on this would usually be 3, ship the older one. 1 or 4 were only done for business-type reasons such as "we really need NPTL for a customer" but those reasons are now supposed to be for RHEL, in fact part of the idea of Fedora was/is to get rid of them. 3 is the only one that is guaranteed to ship a stable product without causing a delay. 1 can also ship stable product without a delay, but only if you know you can assign someone to do the work in a finite timeframe. If 1 becomes "hope someone patches the feature" then 1 can mean delay. 4 almost invariably means delay. Since some package in the distribution will always be in the "not ready" situation, the only way to ship the whole distribution on time is to commit to either 3) or a variant of 1/4 in which some specific person is tasked with resolving a well-known specific problem in finite time sufficiently far in advance. If you're willing to choose 4) ever, you will almost always be late for one reason or another. > And so the 4th option which no one loves is: > 4. slip and hope that we can get the newer one fixed. > > Does that sum up a lot of what happens when fedora slips a release? > Havoc From katzj at redhat.com Wed Dec 13 15:50:29 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 13 Dec 2006 10:50:29 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <4580208C.4000608@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <1166022267.31669.3.camel@cutter> <4580208C.4000608@redhat.com> Message-ID: <1166025029.2505.21.camel@aglarond.local> On Wed, 2006-12-13 at 10:47 -0500, Havoc Pennington wrote: > > I'm not saying that we cannot do some amount of damage control but if > > the choice is: > > 1. patch out some feature (and therefore OWN that fork) > > 2. ship the newer, broken one > > 3. ship the older one > > > > None of those options are terribly good. > > Both the GNOME and the historical Red Hat Linux take on this would > usually be 3, ship the older one. 1 or 4 were only done for > business-type reasons such as "we really need NPTL for a customer" but > those reasons are now supposed to be for RHEL, in fact part of the idea > of Fedora was/is to get rid of them. > > 3 is the only one that is guaranteed to ship a stable product without > causing a delay. 1 can also ship stable product without a delay, but > only if you know you can assign someone to do the work in a finite > timeframe. If 1 becomes "hope someone patches the feature" then 1 can > mean delay. 4 almost invariably means delay. When we're talking about the kernel, though, 3 _isn't_ guaranteed to be a stable product ;) If you go back to a previous kernel release, then perhaps you've just lost all the security improvements. Or lost the ability to support hardware that's been released in the intervening six months since Fn-1. Jeremy From davej at redhat.com Wed Dec 13 15:59:53 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 13 Dec 2006 10:59:53 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <1166025029.2505.21.camel@aglarond.local> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <1166022267.31669.3.camel@cutter> <4580208C.4000608@redhat.com> <1166025029.2505.21.camel@aglarond.local> Message-ID: <20061213155953.GD2140@redhat.com> On Wed, Dec 13, 2006 at 10:50:29AM -0500, Jeremy Katz wrote: > > 3 is the only one that is guaranteed to ship a stable product without > > causing a delay. 1 can also ship stable product without a delay, but > > only if you know you can assign someone to do the work in a finite > > timeframe. If 1 becomes "hope someone patches the feature" then 1 can > > mean delay. 4 almost invariably means delay. > > When we're talking about the kernel, though, 3 _isn't_ guaranteed to be > a stable product ;) If you go back to a previous kernel release, then > perhaps you've just lost all the security improvements. Or lost the > ability to support hardware that's been released in the intervening six > months since Fn-1. There's also the knock-on problem with all the interdependant pieces. Roll back the kernel, and oops, now you might need to roll back udev, hal, wireless-tools, alsa-lib, etc, etc. This is less of a problem than it used to be, but its still a problem occasionally. Dave -- http://www.codemonkey.org.uk From luis at tieguy.org Wed Dec 13 16:05:24 2006 From: luis at tieguy.org (Luis Villa) Date: Wed, 13 Dec 2006 11:05:24 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <1166023957.2505.8.camel@aglarond.local> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <20061213053044.GR2140@redhat.com> <2cb10c440612130443o1b2ec4d9p9d208c9a68c84b6f@mail.gmail.com> <1166023957.2505.8.camel@aglarond.local> Message-ID: <2cb10c440612130805nd681264i5af4d52091fe9e52@mail.gmail.com> On 12/13/06, Jeremy Katz wrote: > On Wed, 2006-12-13 at 07:43 -0500, Luis Villa wrote: > > > > Since it is specifically external legal liability that prevents (2), > > > > that suggests being as proactive as possible about all *legal* issues > > > > in order to avoid delays. Understanding that perfect foresight is > > > > impossible, who is in charge of assessing legal issues and being the > > > > best humanly possible lookout for legal icebergs? What are they doing > > > > right now to help meet this proposed schedule? > > > > > > Red Hat legal is pretty much the gatekeeper for such issues. > > > > Gatekeepers are by definition stationary and deal with problems that > > come to them :) Who from Fedora is responsible for pushing RH legal to > > work proactively on this kind of thing, or alternately, responsible > > for finding such problems and bringing them to RH legal ASAP? > > We're actually very proactive here. A lot of it filters down to points > like checking at package review and ongoing bits from individual package > maintainers[1]. In this specific case, it wasn't something that could > have been discovered sooner. There's not really anything that could > have made it apparent sooner that I can see. Okeydokey. Great to hear. Luis From hp at redhat.com Wed Dec 13 16:13:04 2006 From: hp at redhat.com (Havoc Pennington) Date: Wed, 13 Dec 2006 11:13:04 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <1166025029.2505.21.camel@aglarond.local> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <1166022267.31669.3.camel@cutter> <4580208C.4000608@redhat.com> <1166025029.2505.21.camel@aglarond.local> Message-ID: <45802690.5010807@redhat.com> Jeremy Katz wrote: >> 3 is the only one that is guaranteed to ship a stable product without >> causing a delay. 1 can also ship stable product without a delay, but >> only if you know you can assign someone to do the work in a finite >> timeframe. If 1 becomes "hope someone patches the feature" then 1 can >> mean delay. 4 almost invariably means delay. > > When we're talking about the kernel, though, 3 _isn't_ guaranteed to be > a stable product ;) If you go back to a previous kernel release, then > perhaps you've just lost all the security improvements. Or lost the > ability to support hardware that's been released in the intervening six > months since Fn-1. Right, which is why most large pieces of software have a stable and unstable branch... You could always have a "special kernel exception" - better to have one package that can screw you, instead of hundreds... Havoc From skvidal at linux.duke.edu Wed Dec 13 16:16:56 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 13 Dec 2006 11:16:56 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <45802690.5010807@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <1166022267.31669.3.camel@cutter> <4580208C.4000608@redhat.com> <1166025029.2505.21.camel@aglarond.local> <45802690.5010807@redhat.com> Message-ID: <1166026616.31669.11.camel@cutter> On Wed, 2006-12-13 at 11:13 -0500, Havoc Pennington wrote: > Jeremy Katz wrote: > >> 3 is the only one that is guaranteed to ship a stable product without > >> causing a delay. 1 can also ship stable product without a delay, but > >> only if you know you can assign someone to do the work in a finite > >> timeframe. If 1 becomes "hope someone patches the feature" then 1 can > >> mean delay. 4 almost invariably means delay. > > > > When we're talking about the kernel, though, 3 _isn't_ guaranteed to be > > a stable product ;) If you go back to a previous kernel release, then > > perhaps you've just lost all the security improvements. Or lost the > > ability to support hardware that's been released in the intervening six > > months since Fn-1. > > Right, which is why most large pieces of software have a stable and > unstable branch... > > You could always have a "special kernel exception" - better to have one > package that can screw you, instead of hundreds... > What are the packages that cause slips? We've had a couple of slips on almost every release, right? What are the causes? -sv From jkeating at redhat.com Wed Dec 13 16:21:21 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Dec 2006 11:21:21 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <1166026616.31669.11.camel@cutter> References: <457D9F7D.8030007@leemhuis.info> <45802690.5010807@redhat.com> <1166026616.31669.11.camel@cutter> Message-ID: <200612131121.21252.jkeating@redhat.com> On Wednesday 13 December 2006 11:16, seth vidal wrote: > What are the packages that cause slips? We've had a couple of slips on > almost every release, right? What are the causes? Kernel, kernel(xen), anaconda, buildsystem/tree build tool, random broken package, multilib failures, Legal issues these are just a few off the top of my head. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Wed Dec 13 16:33:36 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 Dec 2006 22:03:36 +0530 Subject: Fedora release lifecyle Message-ID: <45802B60.8020309@fedoraproject.org> Hi The current proposal (http://fedoraproject.org/wiki/FedoraSummit/ReleaseProcess) of changing the Fedora lifecycle to support release N until N+2 is releases or approximately 13+ months is pretty good but I am wondering if we can go a bit further. My suggestion would be look at a differentiated life cyle between Fedora server and desktop variants in the upcoming release or have a policy as follows First six months - Feature additions, bug and security fixes six months Next six months - Only bug and security fixes Next six months - Only critical security fixes* For reference, here is what some other distributions do. Couldnt find proper information for many other distributions. OpenSUSE 2 years http://en.opensuse.org/SUSE_Linux_Lifetime Mandriva 12 months for desktop. 18 months for base and 24 months for server. http://www.mandriva.com/en/security/productlifetime Ubuntu 18 months of security only updates for regular releases. http://www.ubuntu.com/ubuntu/ [*] https://www.redhat.com/archives/fedora-security-list/2006-October/msg00006.html Rahul From davej at redhat.com Wed Dec 13 16:56:23 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 13 Dec 2006 11:56:23 -0500 Subject: Fedora release lifecyle In-Reply-To: <45802B60.8020309@fedoraproject.org> References: <45802B60.8020309@fedoraproject.org> Message-ID: <20061213165623.GB18194@redhat.com> On Wed, Dec 13, 2006 at 10:03:36PM +0530, Rahul Sundaram wrote: > Hi > > > The current proposal > (http://fedoraproject.org/wiki/FedoraSummit/ReleaseProcess) of changing > the Fedora lifecycle to support release N until N+2 is releases or > approximately 13+ months is pretty good but I am wondering if we can go > a bit further. My suggestion would be look at a differentiated life > cyle between Fedora server and desktop variants in the upcoming release > or have a policy as follows > > First six months - Feature additions, bug and security fixes six months > Next six months - Only bug and security fixes > Next six months - Only critical security fixes* regardless of how clear you state this policy, you'll still get people filing non-security bugs in the last six months. Even processing those incoming bugs takes time, and WONTFIX'ing those leaves people just as jaded as telling them "Upgrade to FCn+1". Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Wed Dec 13 16:56:49 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Dec 2006 17:56:49 +0100 Subject: Fedora release lifecyle In-Reply-To: <45802B60.8020309@fedoraproject.org> References: <45802B60.8020309@fedoraproject.org> Message-ID: <458030D1.4070206@leemhuis.info> Rahul Sundaram schrieb: > The current proposal > (http://fedoraproject.org/wiki/FedoraSummit/ReleaseProcess) of changing > the Fedora lifecycle to support release N until N+2 is releases or > approximately 13+ months is pretty good but I am wondering if we can go > a bit further. My suggestion would be look at a differentiated life > cyle between Fedora server and desktop variants in the upcoming release > or have a policy as follows > > First six months - Feature additions, bug and security fixes six months > Next six months - Only bug and security fixes > Next six months - Only critical security fixes* My vote: For all releases with even number: First six months - Feature additions, bug and security fixes next six months - Only bug and security fixes next twelve months - Only critical security fixes EOL For all releases with uneven number: First six months - Feature additions, bug and security fixes next seven months - Only bug and security fixes EOL Such a theme would be helpful for users from hosting companies that run FC on their machines. Other variants (support only each third release for longer periods; support the releases with uneven numbers only for 7 month in general, ... ) are thinkable, too. CU thl From notting at redhat.com Wed Dec 13 17:32:05 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 13 Dec 2006 12:32:05 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <2cb10c440612130443o1b2ec4d9p9d208c9a68c84b6f@mail.gmail.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <20061213053044.GR2140@redhat.com> <2cb10c440612130443o1b2ec4d9p9d208c9a68c84b6f@mail.gmail.com> Message-ID: <20061213173205.GD1729@nostromo.devel.redhat.com> Luis Villa (luis at tieguy.org) said: > >1. dropping it would be a regression vs FC5. > >2. It's a major line item for RHEL5, and Fedora is supposedly > > where stuff like this gets beaten into shape first. > > (1) makes sense, though in that case there is an obvious question > about 'why was that last, broken patchset allowed in so late?' It was broken for a while. Generally, with upstream Xen based on 2.6.16, and Fedora based on upstream-current, you have to pick which one you're going to break - you either freeze upstream kernel, or freeze Xen and fix it up. Going with the upstream kernel is the right choice, but then you get into the Xen-screws-you problem. > As far as (2) goes, I thought Fedora was an independent project? We are responsible to our various downstream distributions, whether they be OLPC, RHEL, or others. We certainly could be (and probably should be) more independent. > >I find it hard to talk about Xen in person without cursing. Really. > > That makes the question even more pressing, then. Assume Xen is > horribly broken come April 23rd. What will Fedora do? What process > will the board go through to make that decision? The earlier you know > what that process is, the better you can plan. Kill it. STAB STAB STAB. *Ahem*. > >tbh, I agree with you. Fedora should not be hostage to RHEL feature > >requirements. > >Merging Xen was the single biggest headache I've faced in kernel > >maintainence > >in the last 3.5 years. Even NPTL against the RHL 2.4 kernels was a walk > >in the park compared to this fiasco. > > So whose responsibility is it to make that call? (Or alternately, to > public admit that that call can't be made?) Again, the earlier the > policy is decided on, the better for everyone. For FC6, we had bi-weekly status meetings consisting of the QA lead, the rel-eng lead, heads of areas of concentration (kernel, desktop, etc), and random interested parties. I suspect it comes down to that group. > Does Will have the power in these meetings to change priorities and > direct engineering resources towards the end of a cycle? e.g., during > the FC7 meetings, what will happen if he screams about Xen? :) No. Actually, that's one of the issues with Fedora at the moment - since it's engineered as a general part of everyone's schedule, but not specifically scheduled, it's very hard to retask engineers with 'do this for Fedora.' Bill From dwmw2 at infradead.org Wed Dec 13 17:40:06 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 13 Dec 2006 17:40:06 +0000 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <20061213173205.GD1729@nostromo.devel.redhat.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <20061213053044.GR2140@redhat.com> <2cb10c440612130443o1b2ec4d9p9d208c9a68c84b6f@mail.gmail.com> <20061213173205.GD1729@nostromo.devel.redhat.com> Message-ID: <1166031606.5253.755.camel@pmac.infradead.org> On Wed, 2006-12-13 at 12:32 -0500, Bill Nottingham wrote: > We are responsible to our various downstream distributions, whether > they be OLPC, RHEL, or others. YDL? CentOS? :) -- dwmw2 From fedora at leemhuis.info Wed Dec 13 18:56:05 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Dec 2006 19:56:05 +0100 Subject: mailing-list reorganisation Message-ID: <45804CC5.3090201@leemhuis.info> Hi All, we discussed the "to many mailinglists" problem now and then in the past. Most of us are annoyed by it, so here is a proposed cleanup. Comments? == Remove == === fedora-packaging-list === Packaging is important to all package maintainers. Everyone should get involved in the discussions and at least see the topics being discussed, thus do it directly on fedora-maintainers. Use a special tag like "[packaging]" to mark them if needed. === fedora-buildsys-list === It's quite a quiet list -- maybe we should leave it open for now until the plague/brew and VCS stuff is worked out, and then simply continue on fedora-devel. === fedora-extras-list === We should get rid of it when core merges with extras. Discuss the stuff on fedora-devel in the future. === fedora-test-list === A lot of people don't get the difference between fedora-devel and fedora-test list. And testing is a crucial part of the devel process, thus lets drop the test-list. == New == === fedora-project-list == We until now have no real list where Ambassadors, packagers, programmers, art-people and other contributors can talk to each other about general stuff that's important to the project as a whole without getting lost in the noise or scared away with "this is off topic on this list" calls. fedora-advisory-board somehow is this list, but it's moderated and thus even some project contributors that are not subscribed feel excluded (bad). /!\ Note: I'm not sure is this really is a good idea, but I more and more think we need a list where we can discuss the project as a whole especially with people that are not yet contributors == Not sure == There are some list where I'm not sure if they are still useful: fedora-desktop-list, fedora-games-list. = EOF= Just my 2 cent. Did I miss anything? Do people want greater changes? Less changes? or is everyone happy with the current situation? CU thl From dennis at ausil.us Wed Dec 13 19:32:25 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 13 Dec 2006 13:32:25 -0600 Subject: mailing-list reorganisation In-Reply-To: <45804CC5.3090201@leemhuis.info> References: <45804CC5.3090201@leemhuis.info> Message-ID: <200612131332.26176.dennis@ausil.us> On Wednesday 13 December 2006 12:56, Thorsten Leemhuis wrote: > Hi All, > > we discussed the "to many mailinglists" problem now and then in the > past. Most of us are annoyed by it, so here is a proposed cleanup. > Comments? > Lets look at all the fedora related lists and see what is needed or not needed. i took this list from http://www.redhat.com/mailman/listinfo and am re-organising a little fedora-advisory-board fedora-advisory-board-readonly fedora-board-list Should we merge the board-list to fab list? fedora-announce-list Fedora-maintainers-announce Fedora-directory-announce Fedora-legacy-announce Lets merge all the announge lists to one. If need be people can filter Fedora-package-announce Lets keep this one seperate its likely to have a largish volume Fedora-maintainers Fedora-maintainers-readonly it can be nice to have a quietish list for discussion fedora-devel-list fedora-devel-java-list Fedora-perl-devel-list Fedora-r-devel-list Fedora-directory-devel fedora-test-list fedora-extras-list Fedora-relnotes-content Fedora-packaging merge all the devel lists into one Fedora-package-review this is a high volume devel list that noise should be kept of the main devel list fedora-cvs-commits fedora-extras-commits Fedora-eclipse-commits Fedora-directory-commits lets merge all cvs commits to one list. i can always filter ones i dont want out. fedora-list Fedora-de-list Fedora-es-list Fedora-fr-list Fedora-ja-list Fedora-users-br Lets be consistent with names i think its fair to have list for different langages. Fedora-docs-br Fedora-docs-commits fedora-docs-list fedora-dsco-list is there even a dsco? i had not heard of them until looking at the list Fedora-edu-br Fedora-education-list We could do more on education issues in other countries Fedora-trans-ar Fedora-trans-bn Fedora-trans-bn_in Fedora-trans-el Fedora-trans-hi Fedora-trans-ja Fedora-trans-list Fedora-i18n-list Do we really need a translation list and a i18n list? Fedora-ia64-list We may want more arch specific lists though alot of it just belongs in devel Fedora-art-list Fedora-buildsys-list * this could be infrastructure but is used for much more than just fedora. Fedora-laptop-list * perhaps this should be in devel fedora-triage-list * Perhaps this should be in devel Fedora-marketing-list Fedora-mentors-list Fedora-music-list Fedora-security-list fedora-selinux-list Fedora-xen fedora-legacy-list Fedora-infrastructure-list Fedora-directory-users Fedora-desktop-list Fedora-games-list Fedora-websites-list Fedora-women-list specifc projects need there own communication means just my 2c -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From rdieter at math.unl.edu Wed Dec 13 19:36:11 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 13 Dec 2006 13:36:11 -0600 Subject: mailing-list reorganisation In-Reply-To: <200612131332.26176.dennis@ausil.us> References: <45804CC5.3090201@leemhuis.info> <200612131332.26176.dennis@ausil.us> Message-ID: <4580562B.4050900@math.unl.edu> Dennis Gilmore wrote: > Lets look at all the fedora related lists and see what is needed or not > needed. i took this list from http://www.redhat.com/mailman/listinfo and am > re-organising a little > > fedora-advisory-board > fedora-advisory-board-readonly > fedora-board-list > Should we merge the board-list to fab list? No, board-list is a private, non-public list for board-members only. . (: -- Rex From notting at redhat.com Wed Dec 13 19:38:05 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 13 Dec 2006 14:38:05 -0500 Subject: mailing-list reorganisation In-Reply-To: <200612131332.26176.dennis@ausil.us> References: <45804CC5.3090201@leemhuis.info> <200612131332.26176.dennis@ausil.us> Message-ID: <20061213193805.GA4585@nostromo.devel.redhat.com> Dennis Gilmore (dennis at ausil.us) said: > fedora-advisory-board > fedora-advisory-board-readonly > fedora-board-list > Should we merge the board-list to fab list? No. > fedora-announce-list > Fedora-maintainers-announce > Fedora-directory-announce > Fedora-legacy-announce > Lets merge all the announge lists to one. If need be people can filter I have no idea what maintainers-announce is for, but it's unlikely that it's the same purpose as fedora-announce. > fedora-devel-list > fedora-devel-java-list > Fedora-perl-devel-list > Fedora-r-devel-list > Fedora-directory-devel > fedora-test-list > fedora-extras-list > Fedora-relnotes-content > Fedora-packaging > merge all the devel lists into one Why? Shouldn't separate SIGs, such as perl or java, have their own list? Moreover, the directory server list is the *upstream* development list - it shouldn't be merged. > fedora-cvs-commits > fedora-extras-commits > Fedora-eclipse-commits > Fedora-directory-commits > lets merge all cvs commits to one list. i can always filter ones i dont want > out. Again, you want to separate upstream lists (directory) from Fedora lists. > Fedora-trans-ar > Fedora-trans-bn > Fedora-trans-bn_in > Fedora-trans-el > Fedora-trans-hi > Fedora-trans-ja > Fedora-trans-list > Fedora-i18n-list > Do we really need a translation list and a i18n list? One is i18n, one is l10n. Bill From sundaram at fedoraproject.org Wed Dec 13 19:35:55 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 14 Dec 2006 01:05:55 +0530 Subject: mailing-list reorganisation In-Reply-To: <45804CC5.3090201@leemhuis.info> References: <45804CC5.3090201@leemhuis.info> Message-ID: <4580561B.5090705@fedoraproject.org> Thorsten Leemhuis wrote: > Hi All, > > we discussed the "to many mailinglists" problem now and then in the > past. Most of us are annoyed by it, so here is a proposed cleanup. Comments? > > == Remove == > > === fedora-packaging-list === > > Packaging is important to all package maintainers. Everyone should get > involved in the discussions and at least see the topics being discussed, > thus do it directly on fedora-maintainers. Use a special tag like > "[packaging]" to mark them if needed. > > === fedora-buildsys-list === > > It's quite a quiet list -- maybe we should leave it open for now until > the plague/brew and VCS stuff is worked out, and then simply continue on > fedora-devel. > > === fedora-extras-list === > > We should get rid of it when core merges with extras. Discuss the stuff > on fedora-devel in the future. > > === fedora-test-list === > > A lot of people don't get the difference between fedora-devel and > fedora-test list. And testing is a crucial part of the devel process, > thus lets drop the test-list. > We have plans to post automated test suite results to the fedora-test list on a daily basis once it is setup. I am not sure whether the traffic for a merged list would be in a approachable level. Rahul From chitlesh at fedoraproject.org Wed Dec 13 19:54:40 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 13 Dec 2006 20:54:40 +0100 Subject: mailing-list reorganisation In-Reply-To: <45804CC5.3090201@leemhuis.info> References: <45804CC5.3090201@leemhuis.info> Message-ID: <13dbfe4f0612131154p577ac112t5bc50ee3fade67af@mail.gmail.com> On 12/13/06, Thorsten Leemhuis wrote: > === fedora-project-list == > > We until now have no real list where Ambassadors, packagers, > programmers, art-people and other contributors can talk to each other > about general stuff that's important to the project as a whole without > getting lost in the noise or scared away with "this is off topic on this > list" calls. fedora-advisory-board somehow is this list, but it's > moderated and thus even some project contributors that are not > subscribed feel excluded (bad). Having a fedora-project-list is pretty a good idea. Bringing closer Fedora contributors is always a good idea and something to promote. Perhaps, in order not to disturb the contributing atmosphere, one could sign CLA before subscribing to this list. chitlesh -- http://clunixchit.blogspot.com From fedora at leemhuis.info Wed Dec 13 19:56:40 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Dec 2006 20:56:40 +0100 Subject: mailing-list reorganisation In-Reply-To: <4580561B.5090705@fedoraproject.org> References: <45804CC5.3090201@leemhuis.info> <4580561B.5090705@fedoraproject.org> Message-ID: <45805AF8.5040006@leemhuis.info> Rahul Sundaram schrieb: > Thorsten Leemhuis wrote: >> we discussed the "to many mailinglists" problem now and then in the >> past. Most of us are annoyed by it, so here is a proposed cleanup. Comments? >> >> == Remove == >> >> === fedora-packaging-list === >> >> Packaging is important to all package maintainers. Everyone should get >> involved in the discussions and at least see the topics being discussed, >> thus do it directly on fedora-maintainers. Use a special tag like >> "[packaging]" to mark them if needed. >> >> === fedora-buildsys-list === >> >> It's quite a quiet list -- maybe we should leave it open for now until >> the plague/brew and VCS stuff is worked out, and then simply continue on >> fedora-devel. >> >> === fedora-extras-list === >> >> We should get rid of it when core merges with extras. Discuss the stuff >> on fedora-devel in the future. >> >> === fedora-test-list === >> >> A lot of people don't get the difference between fedora-devel and >> fedora-test list. And testing is a crucial part of the devel process, >> thus lets drop the test-list. > We have plans to post automated test suite results to the fedora-test > list on a daily basis once it is setup. I am not sure whether the > traffic for a merged list would be in a approachable level. Maybe automatic test could get still get send there if they are high volume. If not send them to fedora-devel with a unique tag -- people can route them to /dev/null if they want. But let's get rid of the separation between devel and testing for the other stuff as it complicates things to much and confuses things. Cu thk From notting at redhat.com Wed Dec 13 19:58:22 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 13 Dec 2006 14:58:22 -0500 Subject: Fedora release lifecyle In-Reply-To: <458030D1.4070206@leemhuis.info> References: <45802B60.8020309@fedoraproject.org> <458030D1.4070206@leemhuis.info> Message-ID: <20061213195822.GA4896@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > My vote: > > For all releases with even number: > First six months - Feature additions, bug and security fixes > next six months - Only bug and security fixes > next twelve months - Only critical security fixes > EOL > > For all releases with uneven number: > First six months - Feature additions, bug and security fixes > next seven months - Only bug and security fixes > EOL > > Such a theme would be helpful for users from hosting companies that run > FC on their machines. Gack. Is this really what we're trying to accomplish? This all goes back to what is Fedora. It is not all things to all people - I truly feel if you want multiple years of maintenance, you should be looking at things like RHEL (or other prominent enterprise linux distributions.) Bill From jkeating at redhat.com Wed Dec 13 20:09:30 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Dec 2006 15:09:30 -0500 Subject: Fedora release lifecyle In-Reply-To: <20061213195822.GA4896@nostromo.devel.redhat.com> References: <45802B60.8020309@fedoraproject.org> <458030D1.4070206@leemhuis.info> <20061213195822.GA4896@nostromo.devel.redhat.com> Message-ID: <200612131509.30760.jkeating@redhat.com> On Wednesday 13 December 2006 14:58, Bill Nottingham wrote: > Gack. Is this really what we're trying to accomplish? This all > goes back to what is Fedora. It is not all things to all people - I > truly feel if you want multiple years of maintenance, you should be > looking at things like RHEL (or other prominent enterprise linux > distributions.) +1. 13 months I think is a great middle ground. Anything longer and you're really talking about a different product and really hampering the ability to get new things into new releases. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Dec 13 20:07:41 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Dec 2006 21:07:41 +0100 Subject: mailing-list reorganisation In-Reply-To: <20061213193805.GA4585@nostromo.devel.redhat.com> References: <45804CC5.3090201@leemhuis.info> <200612131332.26176.dennis@ausil.us> <20061213193805.GA4585@nostromo.devel.redhat.com> Message-ID: <45805D8D.2010901@leemhuis.info> Bill Nottingham schrieb: > Dennis Gilmore (dennis at ausil.us) said: >> fedora-announce-list >> Fedora-maintainers-announce >> Fedora-directory-announce >> Fedora-legacy-announce >> Lets merge all the announge lists to one. If need be people can filter > I have no idea what maintainers-announce is for, Extras has some contributors that simply don't want to discuss stuff / read fedora-maintainers. But they still want to and need to get the results from discussions and decisions. Thus Fedora-maintainers-announce was created to send out this important informations to all the maintainers -- e.g. planed mass rebuilds, policy changes and stuff like that. CU thl From wwoods at redhat.com Wed Dec 13 20:11:32 2006 From: wwoods at redhat.com (Will Woods) Date: Wed, 13 Dec 2006 15:11:32 -0500 Subject: mailing-list reorganisation In-Reply-To: <200612131332.26176.dennis@ausil.us> References: <45804CC5.3090201@leemhuis.info> <200612131332.26176.dennis@ausil.us> Message-ID: <1166040692.17143.26.camel@metroid.rdu.redhat.com> On Wed, 2006-12-13 at 13:32 -0600, Dennis Gilmore wrote: > fedora-devel-list > fedora-devel-java-list > Fedora-perl-devel-list > Fedora-r-devel-list > Fedora-directory-devel > fedora-test-list > fedora-extras-list > Fedora-relnotes-content > Fedora-packaging > merge all the devel lists into one fedora-test-list isn't really a devel list, I think. Development and testing are heavily interrelated but they aren't the same. > fedora-triage-list * Perhaps this should be in devel fedora-triage-list could be folded into wherever Fedora QA discussions go. Currently that's fedora-test-list. I feel like there should be at least one list exclusively for QA stuff - both for discussion, and for automated test reports / updates announcements / etc. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dennis at ausil.us Wed Dec 13 20:11:28 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 13 Dec 2006 14:11:28 -0600 Subject: mailing-list reorganisation In-Reply-To: <20061213193805.GA4585@nostromo.devel.redhat.com> References: <45804CC5.3090201@leemhuis.info> <200612131332.26176.dennis@ausil.us> <20061213193805.GA4585@nostromo.devel.redhat.com> Message-ID: <200612131411.28400.dennis@ausil.us> On Wednesday 13 December 2006 13:38, Bill Nottingham wrote: > Dennis Gilmore (dennis at ausil.us) said: > > fedora-advisory-board > > fedora-advisory-board-readonly > > fedora-board-list > > Should we merge the board-list to fab list? > > No. thats fine. i was not sure of its use > > fedora-announce-list > > Fedora-maintainers-announce > > Fedora-directory-announce > > Fedora-legacy-announce > > Lets merge all the announge lists to one. If need be people can filter > > I have no idea what maintainers-announce is for, but it's unlikely > that it's the same purpose as fedora-announce. maintainers-announce says its for * Freeze Notices * Mass Rebuild Notices * Major Policy Changes that effect package maintainers nothing has ever been posted to it > > fedora-devel-list > > fedora-devel-java-list > > Fedora-perl-devel-list > > Fedora-r-devel-list > > Fedora-directory-devel > > fedora-test-list > > fedora-extras-list > > Fedora-relnotes-content > > Fedora-packaging > > merge all the devel lists into one > > Why? Shouldn't separate SIGs, such as perl or java, have their own > list? Moreover, the directory server list is the *upstream* development > list - it shouldn't be merged. directory server i can see as separate. the sigs while not affecting everyone. someone other than a sig member could have valid input. I feel it would help keep development focused and centralised. I am probably wrong. it could bring too much noise > > fedora-cvs-commits > > fedora-extras-commits > > Fedora-eclipse-commits > > Fedora-directory-commits > > lets merge all cvs commits to one list. i can always filter ones i dont > > want out. > > Again, you want to separate upstream lists (directory) from Fedora > lists. :) thats fair > > > Fedora-trans-ar > > Fedora-trans-bn > > Fedora-trans-bn_in > > Fedora-trans-el > > Fedora-trans-hi > > Fedora-trans-ja > > Fedora-trans-list > > Fedora-i18n-list > > Do we really need a translation list and a i18n list? > > One is i18n, one is l10n. ok i can buy that. -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From wwoods at redhat.com Wed Dec 13 20:18:28 2006 From: wwoods at redhat.com (Will Woods) Date: Wed, 13 Dec 2006 15:18:28 -0500 Subject: mailing-list reorganisation In-Reply-To: <45805AF8.5040006@leemhuis.info> References: <45804CC5.3090201@leemhuis.info> <4580561B.5090705@fedoraproject.org> <45805AF8.5040006@leemhuis.info> Message-ID: <1166041108.17143.34.camel@metroid.rdu.redhat.com> On Wed, 2006-12-13 at 20:56 +0100, Thorsten Leemhuis wrote: > Rahul Sundaram schrieb: > > Thorsten Leemhuis wrote: > >> A lot of people don't get the difference between fedora-devel and > >> fedora-test list. And testing is a crucial part of the devel process, > >> thus lets drop the test-list. > > We have plans to post automated test suite results to the fedora-test > > list on a daily basis once it is setup. I am not sure whether the > > traffic for a merged list would be in a approachable level. > > Maybe automatic test could get still get send there if they are high > volume. If not send them to fedora-devel with a unique tag -- people can > route them to /dev/null if they want. Is the package update announcements considered "high volume" already? Even if it's not, we're planning to add a lot more automated reports. I think this will quickly become a problem for people. > But let's get rid of the separation between devel and testing for the > other stuff as it complicates things to much and confuses things. Well, maybe you're right - devel and test reporting *should* be on the same list. When something breaks, it should be reported to (and discussed with) the developers. That makes sense. But I still think we need a separate list for the automated reports. This also means that all discussion of QA tools, test documentation, and stuff like that will end up on fedora-devel. Is that what we want? -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Wed Dec 13 20:18:40 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Dec 2006 21:18:40 +0100 Subject: mailing-list reorganisation In-Reply-To: <1166040692.17143.26.camel@metroid.rdu.redhat.com> References: <45804CC5.3090201@leemhuis.info> <200612131332.26176.dennis@ausil.us> <1166040692.17143.26.camel@metroid.rdu.redhat.com> Message-ID: <45806020.9090302@leemhuis.info> Will Woods schrieb: > On Wed, 2006-12-13 at 13:32 -0600, Dennis Gilmore wrote: >> fedora-devel-list >> fedora-devel-java-list >> Fedora-perl-devel-list >> Fedora-r-devel-list >> Fedora-directory-devel >> fedora-test-list >> fedora-extras-list >> Fedora-relnotes-content >> Fedora-packaging >> merge all the devel lists into one > > fedora-test-list isn't really a devel list, I think. Development and > testing are heavily interrelated but they aren't the same. Much agreed to "heavily interrelated". >> fedora-triage-list * Perhaps this should be in devel > fedora-triage-list could be folded into wherever Fedora QA discussions > go. Currently that's fedora-test-list. > > I feel like there should be at least one list exclusively for QA stuff - > both for discussion, and for automated test reports / updates > announcements / etc. I'd suggest to simply rename fedora-triage-list to fedora-qa-list and merge fedora-test into fedora-devel. Cu thl From fedora at leemhuis.info Wed Dec 13 20:20:15 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Dec 2006 21:20:15 +0100 Subject: mailing-list reorganisation In-Reply-To: <13dbfe4f0612131154p577ac112t5bc50ee3fade67af@mail.gmail.com> References: <45804CC5.3090201@leemhuis.info> <13dbfe4f0612131154p577ac112t5bc50ee3fade67af@mail.gmail.com> Message-ID: <4580607F.2090306@leemhuis.info> Chitlesh GOORAH schrieb: > On 12/13/06, Thorsten Leemhuis wrote: >> === fedora-project-list == >> We until now have no real list where Ambassadors, packagers, >> programmers, art-people and other contributors can talk to each other >> about general stuff that's important to the project as a whole without >> getting lost in the noise or scared away with "this is off topic on this >> list" calls. fedora-advisory-board somehow is this list, but it's >> moderated and thus even some project contributors that are not >> subscribed feel excluded (bad). > Having a fedora-project-list is pretty a good idea. Bringing closer > Fedora contributors is always a good idea and something to promote. > > Perhaps, in order not to disturb the contributing atmosphere, one > could sign CLA before subscribing to this list. I considered that in the beginning, too, but I'm against it now. There are sometimes people that don't want or simply can't sign the CLA, but nevertheless might be important to have on board for such a list. CU thl From jkeating at redhat.com Wed Dec 13 20:31:47 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Dec 2006 15:31:47 -0500 Subject: mailing-list reorganisation In-Reply-To: <45805D8D.2010901@leemhuis.info> References: <45804CC5.3090201@leemhuis.info> <20061213193805.GA4585@nostromo.devel.redhat.com> <45805D8D.2010901@leemhuis.info> Message-ID: <200612131531.47601.jkeating@redhat.com> On Wednesday 13 December 2006 15:07, Thorsten Leemhuis wrote: > Extras has some contributors that simply don't want to discuss stuff / > read fedora-maintainers. But they still want to and need to get the > results from discussions and decisions. Thus Fedora-maintainers-announce > ?was created to send out this important informations to all the > maintainers -- e.g. planed mass rebuilds, policy changes and stuff like > that. Which I think is utterly silly and I am very against having Yet More Mailing Lists, and more games with reply-to, more cross posting, etc... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Dec 13 20:33:46 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Dec 2006 15:33:46 -0500 Subject: mailing-list reorganisation In-Reply-To: <1166041108.17143.34.camel@metroid.rdu.redhat.com> References: <45804CC5.3090201@leemhuis.info> <45805AF8.5040006@leemhuis.info> <1166041108.17143.34.camel@metroid.rdu.redhat.com> Message-ID: <200612131533.47143.jkeating@redhat.com> On Wednesday 13 December 2006 15:18, Will Woods wrote: > Is the package update announcements considered "high volume" already? > Even if it's not, we're planning to add a lot more automated reports. I > think this will quickly become a problem for people. We enabled 'Topics' in fedora-package-announce. Any subscriber can 'subscribe' to particular topics of F-P-A. Currently the only topics are FC4, FC5, and FC6 updates. We can add more topics later. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dmalcolm at redhat.com Wed Dec 13 20:49:06 2006 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 13 Dec 2006 15:49:06 -0500 Subject: Defining high-level objectives for a release? Re: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> Message-ID: <1166042946.25310.20.camel@cassandra.boston.redhat.com> On Tue, 2006-12-12 at 17:37 -0500, Max Spevack wrote: > On Tue, 12 Dec 2006, Thorsten Leemhuis wrote: > > > January 02 is probably to hard to reach, so we should cut one cycle from > > four to three weeks. Which one? test3 maybe? > > We talked about this in the Board meeting this morning. > > Here was the proposal we came up with (modified for a Tuesday release, not > a Monday release), working backward: > > RH Summit May 9-11 > Release April 24 (exactly 6 months after FC6) > Gold April 17 > Test3 March 27 > Test2 February 27 > FudCon February 9-11 (including hackfest) > Test1 January 30 > > Not a lot of slip time in there (at least, not with the RH Summit as a > target). > The reverse-chronological list above defines some dates for releases of things that might be called "deliverables". These deliverables are currently all software trees. Is it possible to add the high-level objectives for what a release might contain as the first deliverable? - integrate Core and Extras - orbital laser integrated into GUI control system - integrate lobby-buddy [1] throughout the distro - reduce the bootup time - attempt to fix system services - enhanced, integrated bling for the desktop - static analysis for the whole distro or whatever... (currently the only thing I know of for F7 is the first one) We'd then put time in at the top of the schedule to try to define these high-level themes for F7. So the list of deliverables (in forward chronological order) might look like this: - Jan 1st: roadmap for release (features, high-priority bugs, fallback plans in case things aren't going to land in time) - [ Period of time where development happens, testers try to figure out how to test things, and rawhide eats people's branes ] - January 30: Test1 - February 27: Test2 - April 17: Gold - April 24: Release - party - May 7th: post-mortem report (feeding into the roadmap for the next release) IMHO the only way we can get whole-distribution improvements rather than incremental changes here and there is to try to define and aim for them at the start of a development cycle. Thoughts? Dave [1] https://www.redhat.com/archives/fedora-devel-list/2006-December/msg00032.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at leemhuis.info Wed Dec 13 20:54:37 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Dec 2006 21:54:37 +0100 Subject: mailing-list reorganisation In-Reply-To: <200612131531.47601.jkeating@redhat.com> References: <45804CC5.3090201@leemhuis.info> <20061213193805.GA4585@nostromo.devel.redhat.com> <45805D8D.2010901@leemhuis.info> <200612131531.47601.jkeating@redhat.com> Message-ID: <4580688D.9070101@leemhuis.info> Jesse Keating schrieb: > On Wednesday 13 December 2006 15:07, Thorsten Leemhuis wrote: >> Extras has some contributors that simply don't want to discuss stuff / >> read fedora-maintainers. But they still want to and need to get the >> results from discussions and decisions. Thus Fedora-maintainers-announce >> was created to send out this important informations to all the >> maintainers -- e.g. planed mass rebuilds, policy changes and stuff like >> that. > Which I think is utterly silly "--verbose" please, because saying just "foo is utterly silly" is utterly silly ;-) I'm really interested in contributors that want to contribute even if they don't want to read and participate in the latest flamewar^wdiscussion between maintainers. We really need way to get important informations to those (?). I propose a mailinglist. Jesse, what do you propose? I'm more than happy if you have a better solution. But no solution is bad. > and I am very against having Yet More Mailing > Lists, and more games with reply-to, more cross posting, etc... I agree that this should be the target. But we always need to make adjustments. And yes, we made errors in the past. But standing still is not the answer. Learning from them and maybe trying something better is the way forward. Sure, we'll do errors again. That's part of the game as far as I see it. CU thl (?) -- there were even red hat employees that unsubscripted from fedora-maintainers iirc From dmalcolm at redhat.com Wed Dec 13 20:56:03 2006 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 13 Dec 2006 15:56:03 -0500 Subject: Defining high-level objectives for a release? Re: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <1166042946.25310.20.camel@cassandra.boston.redhat.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <1166042946.25310.20.camel@cassandra.boston.redhat.com> Message-ID: <1166043363.8524.8.camel@cassandra.boston.redhat.com> [apologies for the HTML email, ran afoul of a bug in an old version of evolution; hopefully this one will come through as text] On Tue, 2006-12-12 at 17:37 -0500, Max Spevack wrote: > On Tue, 12 Dec 2006, Thorsten Leemhuis wrote: > > > January 02 is probably to hard to reach, so we should cut one cycle from > > four to three weeks. Which one? test3 maybe? > > We talked about this in the Board meeting this morning. > > Here was the proposal we came up with (modified for a Tuesday release, not > a Monday release), working backward: > > RH Summit May 9-11 > Release April 24 (exactly 6 months after FC6) > Gold April 17 > Test3 March 27 > Test2 February 27 > FudCon February 9-11 (including hackfest) > Test1 January 30 > > Not a lot of slip time in there (at least, not with the RH Summit as a > target). > The reverse-chronological list above defines some dates for releases of things that might be called "deliverables". These deliverables are currently all software trees. Is it possible to add the high-level objectives for what a release might contain as the first deliverable? - integrate Core and Extras - orbital laser integrated into GUI control system - integrate lobby-buddy [1] throughout the distro - reduce the bootup time - attempt to fix system services - enhanced, integrated bling for the desktop - static analysis for the whole distro or whatever... (currently the only thing I know of for F7 is the first one) We'd then put time in at the top of the schedule to try to define these high-level themes for F7. So the list of deliverables (in forward chronological order) might look like this: - Jan 1st: roadmap for release (features, high-priority bugs, fallback plans in case things aren't going to land in time) - [ Period of time where development happens, testers try to figure out how to test things, and rawhide eats people's branes ] - January 30: Test1 - February 27: Test2 - April 17: Gold - April 24: Release - party - May 7th: post-mortem report (feeding into the roadmap for the next release) IMHO the only way we can get whole-distribution improvements rather than incremental changes here and there is to try to define and aim for them at the start of a development cycle. Thoughts? Dave [1] https://www.redhat.com/archives/fedora-devel-list/2006-December/msg00032.html From jkeating at redhat.com Wed Dec 13 20:59:46 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Dec 2006 15:59:46 -0500 Subject: mailing-list reorganisation In-Reply-To: <4580688D.9070101@leemhuis.info> References: <45804CC5.3090201@leemhuis.info> <200612131531.47601.jkeating@redhat.com> <4580688D.9070101@leemhuis.info> Message-ID: <200612131559.46798.jkeating@redhat.com> On Wednesday 13 December 2006 15:54, Thorsten Leemhuis wrote: > "--verbose" please, because saying just "foo is utterly silly" is > utterly silly ;-) > > I'm really interested in contributors that want to contribute even if > they don't want to read and participate in the latest > flamewar^wdiscussion between maintainers. We really need way to get > important informations to those (?). I propose a mailinglist. Jesse, > what do you propose? I'm more than happy if you have a better solution. > But no solution is bad. Enforce ontopic-ness of maintainers-list. Don't fragment it even more. If you're a maintainer, you're signing up to pay attention to some of this stuff, so pay attention. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wwoods at redhat.com Wed Dec 13 21:07:45 2006 From: wwoods at redhat.com (Will Woods) Date: Wed, 13 Dec 2006 16:07:45 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <2cb10c440612130443o1b2ec4d9p9d208c9a68c84b6f@mail.gmail.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <20061213053044.GR2140@redhat.com> <2cb10c440612130443o1b2ec4d9p9d208c9a68c84b6f@mail.gmail.com> Message-ID: <1166044065.17143.77.camel@metroid.rdu.redhat.com> On Wed, 2006-12-13 at 07:43 -0500, Luis Villa wrote: > On 12/13/06, Dave Jones wrote: > > On Tue, Dec 12, 2006 at 10:48:54PM -0500, Luis Villa wrote: > > > Probably more usefully, if for some reason you can't have earlier > > > freezes for critical, complex subsystems, who is in charge of > > > encouraging early stress testing? Is there someone whose job it is to > > > evangelize widespread testing? > > > > That'll be Will Woods , Fedora QA lead. > > Oh, great, glad there is an answer to that. (/me waves at Will if he > is on this list.) Howdy! It's good to meet you. > > Towards the end of FC6 dev cycle, we did a few things differently > > to improve things. > > * bi-weekly status meetings. Just a half hour concall to make > > sure everyone knew the state of the onion. > > Does Will have the power in these meetings to change priorities and > direct engineering resources towards the end of a cycle? e.g., during > the FC7 meetings, what will happen if he screams about Xen? :) Luckily for me, the people involved in the FC6 status meetings are all reasonable folk, so it was never necessary for me to scream about Xen being broken. It seemed we were all in agreement on what was OK and what needed love, and efforts were directed in the appropriate direction. In the end, though, I think Max has said that I have the power to press the Big Red Button on a release if something is absolutely broken beyond repair. > > * Will started hashing out test plans. > > * Some process documentation got put on the wiki. > > * I believe there are weekly(?) test team irc meetings. Yes indeed! The next one is at 1700UTC (Noon EST) tomorrow (Dec. 14): http://fedoraproject.org/wiki/QA/Meetings/20061214 > > Something else that should see the light of day at some point will be > > the eventual opening of our internal QA test harnesses (along with > > some of the tests that we put a RHEL release through). > > Getting stuff like this into the hands of eager wannabe testers > > is going to be really useful. > > Yeah, sounds like it. We're working hard at this stuff - the automated test tools are currently hosted at https://testing.108.redhat.com/ if you wanted to poke around. The new updates system should have hooks to run automated tests, and we will be maintaining a repo of contributed tests that the update system will pull from. There's all sorts of fun work going on here. > > > More questions that you could ask, besides 'why did it go wrong last > > > time?' would be things like how does Fedora define a showstopper? > > > > Basically 'blocking' criteria is something like.. > > * large class of machines doesn't boot > > * really common machine doesn't boot > > * installer falls over really easily with no workaround > > * common network cards don't work (preventing updates). > > > > It's spelled out a lot better than my feeble memory can remember > > somewhere on the fedoraproject.org wiki. http://fedoraproject.org/wiki/QA/ReleaseCriteria was the set of criteria proposed during FC6. For the most part, we managed to stick to it, but you'll notice it doesn't include anything about new features in the release (e.g. Xen in FC6). We had publicly committed to delivering Xen, though, so it had to work. The tree testing matrix required a Xen install: http://fedoraproject.org/wiki/QA/TreeTestingTemplate The real problem here was that we were already committed to delivering Xen, so we had no choice but to hammer on it until it was fixed. > That makes the question even more pressing, then. Assume Xen is > horribly broken come April 23rd. What will Fedora do? What process > will the board go through to make that decision? The earlier you know > what that process is, the better you can plan. Well, I think we need to add something to the Release Criteria about major features for a new release. I assume there will be two basic categories of features: some features that will be required (i.e. we will block until it works - stuff like SELinux, new GNOME releases, etc.) and some others that we plan to include, but may drop if we can't get it in a reasonable state for release (maybe Xen would have gone here in the past). We'll need some planning meetings to figure out the feature list and put the features into those two categories - I think there are normally meetings to decide on the feature list, so that's just a couple extra bits to discuss there. So then the Release Criteria just need to say that Required features must work before release, and other features need to be "sufficiently stable" to be included. Probably "sufficiently stable" will be need to be better defined, but basically it means "The release team thinks it's OK, and the testing/development community have tried it and aren't complaining." So then we know which features we slip for, and which ones we can either drop or release-note ("Feature X is b0rken. It'll be fixed by an update Real Soon Now. Really.") Does that make sense? Would that cover most cases? -w p.s. It's great to have you around - I'd love it if you could pop into a QA meeting or #fedora-testing sometime and we could discuss these things further. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wwoods at redhat.com Wed Dec 13 21:16:27 2006 From: wwoods at redhat.com (Will Woods) Date: Wed, 13 Dec 2006 16:16:27 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <20061212230256.GM2140@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> Message-ID: <1166044587.17143.81.camel@metroid.rdu.redhat.com> On Tue, 2006-12-12 at 18:02 -0500, Dave Jones wrote: > Oh, and there was the 'not really test4, but sort of' release that > was needed because test3, well.. stunk. There were a number of really > nasty bugs in that which meant it wouldn't even install for quite a > few people. How that one got out the building alive is anyones guess. Sorry! I'm supposed to keep that from happening, but I was in Rome on my honeymoon when that was released. I told the wife "I need to bring an x86_64 workstation for testing!" but nooooo, she just wouldn't listen.. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From blizzard at redhat.com Wed Dec 13 21:26:46 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 13 Dec 2006 16:26:46 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <20061213053044.GR2140@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <20061213053044.GR2140@redhat.com> Message-ID: <45807016.2060400@redhat.com> Dave Jones wrote: > tbh, I agree with you. Fedora should not be hostage to RHEL feature requirements. > Merging Xen was the single biggest headache I've faced in kernel maintainence > in the last 3.5 years. Even NPTL against the RHL 2.4 kernels was a walk > in the park compared to this fiasco. I agree with this statement in principal, but from I put on my Fedora (hat?) I see that Red Hat is still our largest contributor, and will be for the time being. So we do make some sacrifices to help out The Company. But wrt this particular issue, I see it largely as a question of support. Talking with Brian Stevens, Stein and Tim B they brought up the suggestion of breaking it out into its own rpm and making it Red Hat's responsibility - not yours. Keep things moving and if supporting Xen is really important then these guys will step up to the plate and carry it themselves. I think that from the standpoint of supporting existing Fedora users and for our next release it really does become a question of whether or not Red-Hat-the-Company steps up to support it. They certainly can't make it _your_ problem without backing you with the proper resources to handle it. --Chris From blizzard at redhat.com Wed Dec 13 21:29:02 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 13 Dec 2006 16:29:02 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <20061213053044.GR2140@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <20061213053044.GR2140@redhat.com> Message-ID: <4580709E.3060300@redhat.com> Oh, another note that I would like to point out. Xen is one of the few places where we've really got a lot of users. So supporting them turns out to be important. Lots of biz users and ISVs who want to deliver on Xen turn to us because, frankly, we're the best on the block at the moment in terms of getting the technology into people's hands. So we have to consider that while not a huge number of people are using it, it's at least one of our positions of strength - something we should probably defend. --Chris From smooge at gmail.com Wed Dec 13 21:33:42 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 13 Dec 2006 14:33:42 -0700 Subject: Fedora Board meeting Tuesday 12/12 In-Reply-To: <20061212052554.GA11776@nostromo.devel.redhat.com> References: <200612111525.01107.jkeating@redhat.com> <457E15D9.5080708@redhat.com> <200612112155.46503.jkeating@redhat.com> <3237e4410612112028i5095eb2x1f94f21a065d0a0c@mail.gmail.com> <20061212052554.GA11776@nostromo.devel.redhat.com> Message-ID: <80d7e4090612131333n69a84f47r937532e215861768@mail.gmail.com> On 12/11/06, Bill Nottingham wrote: > Mike McGrath (mmcgrath at fedoraproject.org) said: > > I had the same issue with my subversion proof of concept a few months > > back. Is it safe or dangerous to assume that lack of interest means > > that people just don't care as long as it works? > > Generally, with things like SCMs or build systems, no one is going > to switch until it's "live" and they have to - they worry about getting > their stuff packaged and can manage to migrate when they have to. > I recall when we initally did the CVS migration internally - we > went from a few feeble 'hm, works for me, I suppose' to 'OMG WHAT DID > YOU DO' as soon as we made it live. > I remember that being the case with pretty much every developer push. Updating porkchop, changes to build tools, etc etc. In herding cats, you only get a reaction after you have changed the litter or food. Before then it doesnt work, UNLESS its a shiny, wobbly ball that gets their attention and they want to chase it. Getting people to change to a new SCM is not shiney and wobbly enough.. its more like them finding out that the cat litter has gone from dry to crystals. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From sundaram at fedoraproject.org Wed Dec 13 21:30:36 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 14 Dec 2006 03:00:36 +0530 Subject: Fedora release lifecyle In-Reply-To: <200612131509.30760.jkeating@redhat.com> References: <45802B60.8020309@fedoraproject.org> <458030D1.4070206@leemhuis.info> <20061213195822.GA4896@nostromo.devel.redhat.com> <200612131509.30760.jkeating@redhat.com> Message-ID: <458070FC.8010209@fedoraproject.org> Jesse Keating wrote: > On Wednesday 13 December 2006 14:58, Bill Nottingham wrote: >> Gack. Is this really what we're trying to accomplish? This all >> goes back to what is Fedora. It is not all things to all people - I >> truly feel if you want multiple years of maintenance, you should be >> looking at things like RHEL (or other prominent enterprise linux >> distributions.) > > +1. 13 months I think is a great middle ground. Anything longer and you're > really talking about a different product and really hampering the ability to > get new things into new releases. > I am sure there is a lot of room between 13 months and 7 years. If you see the plan about only critical security fixes, thats about 20 updates an year or just about *10 updates* for 6 months. Again see https://www.redhat.com/archives/fedora-security-list/2006-October/msg00006.html. For a desktop variant an year worth of updates might be good enough but does anyone really think we should have a server variant the same way instead of putting out a dozen more updates and extending the life cycle? Rahul From jkeating at redhat.com Wed Dec 13 21:42:42 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Dec 2006 16:42:42 -0500 Subject: Fedora release lifecyle In-Reply-To: <458070FC.8010209@fedoraproject.org> References: <45802B60.8020309@fedoraproject.org> <200612131509.30760.jkeating@redhat.com> <458070FC.8010209@fedoraproject.org> Message-ID: <200612131642.45697.jkeating@redhat.com> On Wednesday 13 December 2006 16:30, Rahul Sundaram wrote: > I am sure there is a lot of room between 13 months and 7 years. If you > see the plan about only critical security fixes, thats about 20 updates > an year or just about *10 updates* for 6 months. Again see > https://www.redhat.com/archives/fedora-security-list/2006-October/msg00006. >html. For a desktop variant an year worth of updates might be good enough > but does anyone really think we should have a server variant the same way > instead of putting out a dozen more updates and extending the life cycle? Its difficult to do just critical updates unless you're doing backports, and then its much more engineering time to make those 10 updates. Look, lets be honest here. Fedora isn't all that great of a distro for a stable server. We don't do backports, we play with new technology, we've got a fast paced development cycle, etc... Lets not try to be something we aren't. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Wed Dec 13 21:42:37 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 13 Dec 2006 16:42:37 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <45807016.2060400@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <20061213053044.GR2140@redhat.com> <45807016.2060400@redhat.com> Message-ID: <20061213214237.GB2418@redhat.com> On Wed, Dec 13, 2006 at 04:26:46PM -0500, Christopher Blizzard wrote: > But wrt this particular issue, I see it largely as a question of > support. Talking with Brian Stevens, Stein and Tim B they brought up > the suggestion of breaking it out into its own rpm and making it Red > Hat's responsibility - not yours. Keep things moving and if supporting > Xen is really important then these guys will step up to the plate and > carry it themselves. That does seem sensible. In fact, at one stage, we *did* do things this way. There was a separate kernel-xen package, and I never had to worry about it. Concerns grew however about fixes going into one kernel package but not the other. > They certainly can't make it _your_ problem without backing you with the > proper resources to handle it. I'd have loved to have heard that 18 months ago. We might fix this issue, but I want to be sure it doesn't happen again. When the next "must have" half-baked not-upstream feature comes along, I'm seriously going to be pushing back a lot harder than I have done in the past. Dave -- http://www.codemonkey.org.uk From blizzard at redhat.com Wed Dec 13 21:44:03 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 13 Dec 2006 16:44:03 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <20061213214237.GB2418@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <2cb10c440612121447o29e7daefn1c4f96517a011e6e@mail.gmail.com> <20061212230256.GM2140@redhat.com> <2cb10c440612121948o25c2171bp349f46ad4883145f@mail.gmail.com> <20061213053044.GR2140@redhat.com> <45807016.2060400@redhat.com> <20061213214237.GB2418@redhat.com> Message-ID: <45807423.7020704@redhat.com> Dave Jones wrote: > That does seem sensible. In fact, at one stage, we *did* do things this way. > There was a separate kernel-xen package, and I never had to worry about it. > Concerns grew however about fixes going into one kernel package but not > the other. I think these guys are willing to work on it. I would suggest talking to them about it if it's a major concern (sounds like it is to me!) > > > They certainly can't make it _your_ problem without backing you with the > > proper resources to handle it. > > I'd have loved to have heard that 18 months ago. > We might fix this issue, but I want to be sure it doesn't happen again. > When the next "must have" half-baked not-upstream feature comes along, > I'm seriously going to be pushing back a lot harder than I have done in the past. > Sounds fine to me. But just make sure it's "I don't have the bandwith to do this, you're going to have to help me" not "Xen sucks, get it out." Xen _might_ suck because it's not upstream, but I don't think that's the problem we're really dealing with here. Just a guess, though. --Chris From jkeating at redhat.com Wed Dec 13 22:06:42 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Dec 2006 17:06:42 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <45807016.2060400@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <20061213053044.GR2140@redhat.com> <45807016.2060400@redhat.com> Message-ID: <200612131706.42804.jkeating@redhat.com> On Wednesday 13 December 2006 16:26, Christopher Blizzard wrote: > But wrt this particular issue, I see it largely as a question of > support. ?Talking with Brian Stevens, Stein and Tim B they brought up > the suggestion of breaking it out into its own rpm and making it Red > Hat's responsibility - not yours. ?Keep things moving and if supporting > Xen is really important then these guys will step up to the plate and > carry it themselves. Right, because this worked so wonderfully for the gfs1 modules... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Dec 13 22:07:47 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Dec 2006 17:07:47 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <45807423.7020704@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <20061213214237.GB2418@redhat.com> <45807423.7020704@redhat.com> Message-ID: <200612131707.47749.jkeating@redhat.com> On Wednesday 13 December 2006 16:44, Christopher Blizzard wrote: > Sounds fine to me. ?But just make sure it's "I don't have the bandwith > to do this, you're going to have to help me" not "Xen sucks, get it > out." ?Xen _might_ suck because it's not upstream, but I don't think > that's the problem we're really dealing with here. ?Just a guess, though. Its more of a 'xen upstream doesn't care about newer kernels nor Fedora, so we have to do all the work ourselves, and um -ENOTIME' However if the xen stuff were in upstream kernel, there is a much higher chance it would be working before the upstream kernel made upstream releases and then we wouldn't have this problem. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Wed Dec 13 22:06:21 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 13 Dec 2006 17:06:21 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <200612131706.42804.jkeating@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <20061213053044.GR2140@redhat.com> <45807016.2060400@redhat.com> <200612131706.42804.jkeating@redhat.com> Message-ID: <20061213220621.GA6646@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > Right, because this worked so wonderfully for the gfs1 modules... Basically, if you want Xen, you get Xen. kmods not included. I mean, it's not like we really keep kmods up to date for rawhide anyway. Bill From sundaram at fedoraproject.org Wed Dec 13 22:04:28 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 14 Dec 2006 03:34:28 +0530 Subject: Fedora release lifecyle In-Reply-To: <200612131642.45697.jkeating@redhat.com> References: <45802B60.8020309@fedoraproject.org> <200612131509.30760.jkeating@redhat.com> <458070FC.8010209@fedoraproject.org> <200612131642.45697.jkeating@redhat.com> Message-ID: <458078EC.6010209@fedoraproject.org> Jesse Keating wrote: > Look, lets be honest here. Fedora isn't all that great of a distro for a > stable server. We don't do backports, we play with new technology, we've got > a fast paced development cycle, etc... Lets not try to be something we > aren't. We already do 9% backports in a Fedora release according to the stats I read at http://www.redhat.com/f/summitfiles/presentation/May31/Security/Cox_Management.pdf (Refer page 12: Fedora Policy). A fact paced development cycle can continue along a extended post release updates lifecycle. Distributions in a similar circle have already managed to do this as a I posted earlier for comparison. We will have the advantage of leveraging community input more through the planned merge of core and extras so resource spreading out existing resources thin becomes less of a concern. If we are not planning on having Fedora as a stable server, we should not release a server variant. If we are going to do desktop and server variants, we should put some incrementally more effort into actually have something useful in each of these variants rather than just a different bunch of packages and stop going back and forth on what we are trying to do. I do agree that we should find some middle ground but I dont we have that already with the existing plan. Rahul From davej at redhat.com Wed Dec 13 22:14:08 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 13 Dec 2006 17:14:08 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <200612131707.47749.jkeating@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <20061213214237.GB2418@redhat.com> <45807423.7020704@redhat.com> <200612131707.47749.jkeating@redhat.com> Message-ID: <20061213221408.GG2418@redhat.com> On Wed, Dec 13, 2006 at 05:07:47PM -0500, Jesse Keating wrote: > On Wednesday 13 December 2006 16:44, Christopher Blizzard wrote: > > Sounds fine to me. ?But just make sure it's "I don't have the bandwith > > to do this, you're going to have to help me" not "Xen sucks, get it > > out." ?Xen _might_ suck because it's not upstream, but I don't think > > that's the problem we're really dealing with here. ?Just a guess, though. > > Its more of a 'xen upstream doesn't care about newer kernels nor Fedora, so we > have to do all the work ourselves, and um -ENOTIME' However if the xen stuff > were in upstream kernel, there is a much higher chance it would be working > before the upstream kernel made upstream releases and then we wouldn't have > this problem. Right. It's a bottleneck. I'm prevented from rebasing until the Xen team has found the cycles to bring the necessary bits up to speed. When this happens basically I have to go find something else to do. Dave -- http://www.codemonkey.org.uk From notting at redhat.com Wed Dec 13 22:13:38 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 13 Dec 2006 17:13:38 -0500 Subject: Fedora release lifecyle In-Reply-To: <458078EC.6010209@fedoraproject.org> References: <45802B60.8020309@fedoraproject.org> <200612131509.30760.jkeating@redhat.com> <458070FC.8010209@fedoraproject.org> <200612131642.45697.jkeating@redhat.com> <458078EC.6010209@fedoraproject.org> Message-ID: <20061213221338.GB6646@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > If we are not planning on having Fedora as a stable server, we should > not release a server variant. If we are going to do desktop and server > variants, we should put some incrementally more effort into actually > have something useful in each of these variants rather than just a > different bunch of packages and stop going back and forth on what we are > trying to do. So, the only differentiation that's possible for a Server is the lifecycle? I don't buy that. How about 'starts services XYZ by default that don't start on the desktop' (think: mdadm, etc.). 'Easily installs in a minimal fashion.' 'Doesn't always boot in runlevel 3'. If the only thing that our Fedora 'server' users want is for us to maintain it longer, that means perhaps we're *already* hitting that market well and don't need to make changes. Bill From jkeating at redhat.com Wed Dec 13 22:22:03 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Dec 2006 17:22:03 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <20061213220621.GA6646@nostromo.devel.redhat.com> References: <457D9F7D.8030007@leemhuis.info> <200612131706.42804.jkeating@redhat.com> <20061213220621.GA6646@nostromo.devel.redhat.com> Message-ID: <200612131722.03708.jkeating@redhat.com> On Wednesday 13 December 2006 17:06, Bill Nottingham wrote: > Basically, if you want Xen, you get Xen. kmods not included. > > I mean, it's not like we really keep kmods up to date for rawhide > anyway. And what about released products? How often are the gfs1 kmods actually not broken in FC5? Once per month, if that? Perhaps I'm not seeing what is being proposed. The xen kernel can't languish because if we rebase the kernel, we may have to rebase userland beyond what an old kernel can handle. Boom there goes Xen. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Dec 13 22:23:41 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Dec 2006 17:23:41 -0500 Subject: Fedora release lifecyle In-Reply-To: <458078EC.6010209@fedoraproject.org> References: <45802B60.8020309@fedoraproject.org> <200612131642.45697.jkeating@redhat.com> <458078EC.6010209@fedoraproject.org> Message-ID: <200612131723.41857.jkeating@redhat.com> On Wednesday 13 December 2006 17:04, Rahul Sundaram wrote: > If we are not planning on having Fedora as a stable server, we should > not release a server variant. If we are going to do desktop and server > variants, we should put some incrementally more effort into actually > have something useful in each of these variants rather than just a > different bunch of packages and stop going back and forth on what we are > trying to do. I do agree that we should find some middle ground but I > dont we have that already with the existing plan. A server spin isn't necessarily for somebody to go out and base critical apps on the spin. It's a way of composing the distro that might make sense for somebody doing server like tasks, and looking at Fedora as a precursor to the next RHEL. And see Bill's email that just came in (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Wed Dec 13 22:27:53 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 13 Dec 2006 17:27:53 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <200612131722.03708.jkeating@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <200612131706.42804.jkeating@redhat.com> <20061213220621.GA6646@nostromo.devel.redhat.com> <200612131722.03708.jkeating@redhat.com> Message-ID: <20061213222753.GK2418@redhat.com> On Wed, Dec 13, 2006 at 05:22:03PM -0500, Jesse Keating wrote: > On Wednesday 13 December 2006 17:06, Bill Nottingham wrote: > > Basically, if you want Xen, you get Xen. kmods not included. > > > > I mean, it's not like we really keep kmods up to date for rawhide > > anyway. > > And what about released products? How often are the gfs1 kmods actually not > broken in FC5? Once per month, if that? The difference is, kernel-xen actually has users. I don't think anyone seriously cares about GFS1. > Perhaps I'm not seeing what is being proposed. The xen kernel can't languish > because if we rebase the kernel, we may have to rebase userland beyond what > an old kernel can handle. Boom there goes Xen. Good point. I don't have an answer for this. Dave -- http://www.codemonkey.org.uk From dwmw2 at infradead.org Wed Dec 13 22:35:33 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 13 Dec 2006 22:35:33 +0000 Subject: Fedora release lifecyle In-Reply-To: <200612131642.45697.jkeating@redhat.com> References: <45802B60.8020309@fedoraproject.org> <200612131509.30760.jkeating@redhat.com> <458070FC.8010209@fedoraproject.org> <200612131642.45697.jkeating@redhat.com> Message-ID: <1166049333.5253.802.camel@pmac.infradead.org> On Wed, 2006-12-13 at 16:42 -0500, Jesse Keating wrote: > Look, lets be honest here. Fedora isn't all that great of a distro for a > stable server. We don't do backports, we play with new technology, we've got > a fast paced development cycle, etc... Lets not try to be something we > aren't. Actually I find that ideal for a mail server. I _want_ to keep Exim, SpamAssassin and ClamAV up to date. All my servers run Fedora. -- dwmw2 From blizzard at redhat.com Wed Dec 13 22:37:48 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 13 Dec 2006 17:37:48 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <20061213222753.GK2418@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <200612131706.42804.jkeating@redhat.com> <20061213220621.GA6646@nostromo.devel.redhat.com> <200612131722.03708.jkeating@redhat.com> <20061213222753.GK2418@redhat.com> Message-ID: <458080BC.3020704@redhat.com> Dave Jones wrote: > On Wed, Dec 13, 2006 at 05:22:03PM -0500, Jesse Keating wrote: > > On Wednesday 13 December 2006 17:06, Bill Nottingham wrote: > > > Basically, if you want Xen, you get Xen. kmods not included. > > > > > > I mean, it's not like we really keep kmods up to date for rawhide > > > anyway. > > > > And what about released products? How often are the gfs1 kmods actually not > > broken in FC5? Once per month, if that? > > The difference is, kernel-xen actually has users. > I don't think anyone seriously cares about GFS1. > > > Perhaps I'm not seeing what is being proposed. The xen kernel can't languish > > because if we rebase the kernel, we may have to rebase userland beyond what > > an old kernel can handle. Boom there goes Xen. > > Good point. I don't have an answer for this. > > Dave > Once again, I think that's up to the Virt team inside of Red Hat to own. And it's not like that's going to happen in a vacuum. You're going to talk to the virt team before you rebase something, right? This isn't supposed to be them following us without them knowing where we're going. We're going to make this a conversation, right? --Chris From davej at redhat.com Wed Dec 13 22:51:37 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 13 Dec 2006 17:51:37 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <458080BC.3020704@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <200612131706.42804.jkeating@redhat.com> <20061213220621.GA6646@nostromo.devel.redhat.com> <200612131722.03708.jkeating@redhat.com> <20061213222753.GK2418@redhat.com> <458080BC.3020704@redhat.com> Message-ID: <20061213225137.GM2418@redhat.com> On Wed, Dec 13, 2006 at 05:37:48PM -0500, Christopher Blizzard wrote: > > > Perhaps I'm not seeing what is being proposed. The xen kernel can't languish > > > because if we rebase the kernel, we may have to rebase userland beyond what > > > an old kernel can handle. Boom there goes Xen. > > > > Good point. I don't have an answer for this. > > Once again, I think that's up to the Virt team inside of Red Hat to own. > And it's not like that's going to happen in a vacuum. You're going to > talk to the virt team before you rebase something, right? This isn't > supposed to be them following us without them knowing where we're going. > We're going to make this a conversation, right? Of course. But that doesn't really change the situation any from what we have now if I'm going to be sitting on my hands waiting for them to get their house in order before I can push out updates. Dave -- http://www.codemonkey.org.uk From notting at redhat.com Thu Dec 14 01:26:03 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 13 Dec 2006 20:26:03 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <20061213222753.GK2418@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <200612131706.42804.jkeating@redhat.com> <20061213220621.GA6646@nostromo.devel.redhat.com> <200612131722.03708.jkeating@redhat.com> <20061213222753.GK2418@redhat.com> Message-ID: <20061214012603.GA9381@nostromo.devel.redhat.com> Dave Jones (davej at redhat.com) said: > > Perhaps I'm not seeing what is being proposed. The xen kernel can't languish > > because if we rebase the kernel, we may have to rebase userland beyond what > > an old kernel can handle. Boom there goes Xen. > > Good point. I don't have an answer for this. I don't know of anything we've added that's required a new enough kernel to that extent between releases. I know we have stuff that won't run, say, 2.6.9 on FC6, but I think 2.6.17, for example, works. Bill From jkeating at redhat.com Thu Dec 14 01:57:22 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Dec 2006 20:57:22 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <20061214012603.GA9381@nostromo.devel.redhat.com> References: <457D9F7D.8030007@leemhuis.info> <20061213222753.GK2418@redhat.com> <20061214012603.GA9381@nostromo.devel.redhat.com> Message-ID: <200612132057.22655.jkeating@redhat.com> On Wednesday 13 December 2006 20:26, Bill Nottingham wrote: > I don't know of anything we've added that's required a new enough kernel > to that extent between releases. I know we have stuff that won't run, say, > 2.6.9 on FC6, but I think 2.6.17, for example, works. Trying to deal with kmods when you have two alternative different versioned kernels is going to be... fun. Even more fun than kmods themselves. Thus far, Extras does allow for kmods, against my very vocal yelling, so if we're going to go down the path of alternative kernels it's something we need to consider. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Thu Dec 14 05:20:05 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 14 Dec 2006 10:50:05 +0530 Subject: Fedora release lifecyle In-Reply-To: <20061213221338.GB6646@nostromo.devel.redhat.com> References: <45802B60.8020309@fedoraproject.org> <200612131509.30760.jkeating@redhat.com> <458070FC.8010209@fedoraproject.org> <200612131642.45697.jkeating@redhat.com> <458078EC.6010209@fedoraproject.org> <20061213221338.GB6646@nostromo.devel.redhat.com> Message-ID: <4580DF05.6080208@fedoraproject.org> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >> If we are not planning on having Fedora as a stable server, we should >> not release a server variant. If we are going to do desktop and server >> variants, we should put some incrementally more effort into actually >> have something useful in each of these variants rather than just a >> different bunch of packages and stop going back and forth on what we are >> trying to do. > > So, the only differentiation that's possible for a Server is the lifecycle? > I don't buy that. There are various other ways to differentiate a server variant but extending the life cycle is in many cases much needed. It expands the scope of the variant being more useful than just a precursor of RHEL. I think we should atleast seriously consider serving that need. Giving that we already do backports, the merge of core and extras and the critical security fixes only policy for the last six months I suggested it does appear doable. Rahul From fedora at leemhuis.info Thu Dec 14 05:59:59 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 14 Dec 2006 06:59:59 +0100 Subject: fedora-maintainers-annouce (was: Re: mailing-list reorganisation) In-Reply-To: <200612131559.46798.jkeating@redhat.com> References: <45804CC5.3090201@leemhuis.info> <200612131531.47601.jkeating@redhat.com> <4580688D.9070101@leemhuis.info> <200612131559.46798.jkeating@redhat.com> Message-ID: <4580E85F.8030305@leemhuis.info> On 13.12.2006 21:59, Jesse Keating wrote: > On Wednesday 13 December 2006 15:54, Thorsten Leemhuis wrote: >> "--verbose" please, because saying just "foo is utterly silly" is >> utterly silly ;-) >> I'm really interested in contributors that want to contribute even if >> they don't want to read and participate in the latest >> flamewar^wdiscussion between maintainers. We really need way to get >> important informations to those (?). I propose a mailinglist. Jesse, >> what do you propose? I'm more than happy if you have a better solution. >> But no solution is bad. > Enforce ontopic-ness of maintainers-list. That would certainly help to get the mailing list to work better. But that does not change the problem at hand. > Don't fragment it even more. If > you're a maintainer, you're signing up to pay attention to some of this > stuff, so pay attention. No. No. No. I know that Extras has contributors that *only want the results*, not the discussions (seems I have to repeat myself here). There are for Example some upstream maintainers (I'd like to have more of them!) involved as {co-,}maintainers in Extras. They get a lot of mails already and they will get annoyed if we force yet another 50 mails/month on them that they are not interested in. So we need a different solution to get the important informations to them (less then 5 mails/month). I still fail to see an alternative to fedora-maintainers-annouce. Jesse, do you have one for those people? Or don't you want upstream maintainers more involved? CU thl From smooge at gmail.com Thu Dec 14 06:00:32 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 13 Dec 2006 23:00:32 -0700 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <458080BC.3020704@redhat.com> References: <457D9F7D.8030007@leemhuis.info> <200612131706.42804.jkeating@redhat.com> <20061213220621.GA6646@nostromo.devel.redhat.com> <200612131722.03708.jkeating@redhat.com> <20061213222753.GK2418@redhat.com> <458080BC.3020704@redhat.com> Message-ID: <80d7e4090612132200l6956222cjdced4d742f14db17@mail.gmail.com> On 12/13/06, Christopher Blizzard wrote: > Dave Jones wrote: > > On Wed, Dec 13, 2006 at 05:22:03PM -0500, Jesse Keating wrote: > > > On Wednesday 13 December 2006 17:06, Bill Nottingham wrote: > > > > Basically, if you want Xen, you get Xen. kmods not included. > > > > > > > > I mean, it's not like we really keep kmods up to date for rawhide > > > > anyway. > > > > > > And what about released products? How often are the gfs1 kmods actually not > > > broken in FC5? Once per month, if that? > > > > The difference is, kernel-xen actually has users. > > I don't think anyone seriously cares about GFS1. > > > > > Perhaps I'm not seeing what is being proposed. The xen kernel can't languish > > > because if we rebase the kernel, we may have to rebase userland beyond what > > > an old kernel can handle. Boom there goes Xen. > > > > Good point. I don't have an answer for this. > > > > Dave > > > > Once again, I think that's up to the Virt team inside of Red Hat to own. > And it's not like that's going to happen in a vacuum. You're going to > talk to the virt team before you rebase something, right? This isn't > supposed to be them following us without them knowing where we're going. > We're going to make this a conversation, right? > It would be nice to see someone from the Virt team answering on a FAB conversation. If they answer on fedora-devel ones I don't know.. because I don't know anyone on the virt team. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From smooge at gmail.com Thu Dec 14 06:26:40 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 13 Dec 2006 23:26:40 -0700 Subject: Fedora release lifecyle In-Reply-To: <4580DF05.6080208@fedoraproject.org> References: <45802B60.8020309@fedoraproject.org> <200612131509.30760.jkeating@redhat.com> <458070FC.8010209@fedoraproject.org> <200612131642.45697.jkeating@redhat.com> <458078EC.6010209@fedoraproject.org> <20061213221338.GB6646@nostromo.devel.redhat.com> <4580DF05.6080208@fedoraproject.org> Message-ID: <80d7e4090612132226r66127638sad0a1d9ac83bce21@mail.gmail.com> On 12/13/06, Rahul Sundaram wrote: > Bill Nottingham wrote: > > Rahul Sundaram (sundaram at fedoraproject.org) said: > >> If we are not planning on having Fedora as a stable server, we should > >> not release a server variant. If we are going to do desktop and server > >> variants, we should put some incrementally more effort into actually > >> have something useful in each of these variants rather than just a > >> different bunch of packages and stop going back and forth on what we are > >> trying to do. > > > > So, the only differentiation that's possible for a Server is the lifecycle? > > I don't buy that. > > There are various other ways to differentiate a server variant but > extending the life cycle is in many cases much needed. It expands the > scope of the variant being more useful than just a precursor of RHEL. I > think we should atleast seriously consider serving that need. Giving > that we already do backports, the merge of core and extras and the > critical security fixes only policy for the last six months I suggested > it does appear doable. > The question that needs to be answered is who is the customer and what are they going to pay for this? Payment does not need to be cash, but it would help. The reason is that someone is going to have to pay for the engineering, qa, documentation, bandwidth, etc. The past has shown that Legacy gets volunteers who are interested in certain packages and/or releases. Once that release is up, they are no longer interested as they have usually transitioned their stuff to Centos, Ubuntu, etc. There are people who want longer release times, but I have not seen that want translated into either cash or volunteer time. My opinion is that while I would like to see 18 months of support, I am already getting 4 free boons from Red Hat: 1) regularly compiled and tested bits called Fedora X (versus just rawhide), 2) 11-13 months of security updates and some enhancement updates, 3) source code for their RHEL which people can get compiled bits from Centos/Whitebox/EatAtJoesLinux, and 4) source code for security updates for RHEL for 7 years (where you can get the compiled bits from EatAtJoes Enterprise Linux). For anything more than that.. I need to supply something to the bargain. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jwboyer at jdub.homelinux.org Thu Dec 14 13:19:15 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 14 Dec 2006 07:19:15 -0600 Subject: Fedora release lifecyle In-Reply-To: <1166049333.5253.802.camel@pmac.infradead.org> References: <45802B60.8020309@fedoraproject.org> <200612131509.30760.jkeating@redhat.com> <458070FC.8010209@fedoraproject.org> <200612131642.45697.jkeating@redhat.com> <1166049333.5253.802.camel@pmac.infradead.org> Message-ID: <1166102355.6110.2.camel@zod.rchland.ibm.com> On Wed, 2006-12-13 at 22:35 +0000, David Woodhouse wrote: > On Wed, 2006-12-13 at 16:42 -0500, Jesse Keating wrote: > > Look, lets be honest here. Fedora isn't all that great of a distro for a > > stable server. We don't do backports, we play with new technology, we've got > > a fast paced development cycle, etc... Lets not try to be something we > > aren't. > > Actually I find that ideal for a mail server. I _want_ to keep Exim, > SpamAssassin and ClamAV up to date. All my servers run Fedora. As do mine. Fedora as a server is fine for quite a few people and use cases. josh From jkeating at redhat.com Thu Dec 14 14:13:06 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Dec 2006 09:13:06 -0500 Subject: fedora-maintainers-annouce (was: Re: mailing-list reorganisation) In-Reply-To: <4580E85F.8030305@leemhuis.info> References: <45804CC5.3090201@leemhuis.info> <200612131559.46798.jkeating@redhat.com> <4580E85F.8030305@leemhuis.info> Message-ID: <200612140913.06462.jkeating@redhat.com> On Thursday 14 December 2006 00:59, Thorsten Leemhuis wrote: > No. No. No. I know that Extras has contributors that *only want the > results*, not the discussions (seems I have to repeat myself here). > There are for Example some upstream maintainers (I'd like to have more > of them!) involved as {co-,}maintainers in Extras. They get a lot of > mails already and they will get annoyed if we force yet another 50 > mails/month on them that they are not interested in. So we need a > different solution to get the important informations to them (less then > 5 mails/month). I still fail to see an alternative to > fedora-maintainers-annouce. Jesse, do you have one for those people? Or > don't you want upstream maintainers more involved? I don't feel that it is healthy to grow a community of packagers that don't get involved in these discussions. At times we need to get the input/discussion from ALL the packagers/maintainers involved, and we just can't do that if we have a bunch that just don't care. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Thu Dec 14 15:05:20 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 14 Dec 2006 10:05:20 -0500 Subject: fedora-maintainers-annouce In-Reply-To: <200612140913.06462.jkeating@redhat.com> References: <45804CC5.3090201@leemhuis.info> <200612131559.46798.jkeating@redhat.com> <4580E85F.8030305@leemhuis.info> <200612140913.06462.jkeating@redhat.com> Message-ID: <45816830.1080408@redhat.com> Jesse Keating wrote: > On Thursday 14 December 2006 00:59, Thorsten Leemhuis wrote: >> No. No. No. I know that Extras has contributors that *only want the >> results*, not the discussions (seems I have to repeat myself here). >> There are for Example some upstream maintainers (I'd like to have more >> of them!) involved as {co-,}maintainers in Extras. They get a lot of >> mails already and they will get annoyed if we force yet another 50 >> mails/month on them that they are not interested in. So we need a >> different solution to get the important informations to them (less then >> 5 mails/month). I still fail to see an alternative to >> fedora-maintainers-annouce. Jesse, do you have one for those people? Or >> don't you want upstream maintainers more involved? > > I don't feel that it is healthy to grow a community of packagers that don't > get involved in these discussions. At times we need to get the > input/discussion from ALL the packagers/maintainers involved, and we just > can't do that if we have a bunch that just don't care. You have the freedom to disagree. However, FESCo decided that they would do this for Extras owners. This is not the first case where one of my ideas for a list was resisted with "we don't need more lists". Past examples like fedora-perl-devel-list have proven to be beneficial. fedora-maintainers-announce is a narrowly defined list for a specific rare task. I strongly believe it be helpful for this narrow purpose, and it should be given a chance to prove itself. The list has already been created for weeks now. Just I haven't had time to launch it. FESCo made this decision, and FESCo is going ahead with it, for the project under FESCo's jurisdiction. Warren Togami wtogami at redhat.com From jkeating at redhat.com Thu Dec 14 15:47:17 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Dec 2006 10:47:17 -0500 Subject: fedora-maintainers-annouce In-Reply-To: <45816830.1080408@redhat.com> References: <45804CC5.3090201@leemhuis.info> <200612140913.06462.jkeating@redhat.com> <45816830.1080408@redhat.com> Message-ID: <200612141047.17709.jkeating@redhat.com> On Thursday 14 December 2006 10:05, Warren Togami wrote: > The list has already been created for weeks now. ?Just I haven't had > time to launch it. ?FESCo made this decision, and FESCo is going ahead > with it, for the project under FESCo's jurisdiction. No, it isn't. maintainers-list is for ALL fedora maintainers, not just Extras. I strongly do _not_ want to force all the Red Hat engineers to go subscribe to Yet Another List, it has been hard enough to get them on maintainers, I don't want to tell them now they have to be on TWO lists. This is why I'm so adamant about this, it is _NOT_ just FESCO. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Thu Dec 14 16:05:42 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 14 Dec 2006 11:05:42 -0500 Subject: fedora-maintainers-annouce In-Reply-To: <200612141047.17709.jkeating@redhat.com> References: <45804CC5.3090201@leemhuis.info> <200612140913.06462.jkeating@redhat.com> <45816830.1080408@redhat.com> <200612141047.17709.jkeating@redhat.com> Message-ID: <45817656.5070500@redhat.com> Jesse Keating wrote: > On Thursday 14 December 2006 10:05, Warren Togami wrote: >> The list has already been created for weeks now. Just I haven't had >> time to launch it. FESCo made this decision, and FESCo is going ahead >> with it, for the project under FESCo's jurisdiction. > > No, it isn't. maintainers-list is for ALL fedora maintainers, not just > Extras. I strongly do _not_ want to force all the Red Hat engineers to go > subscribe to Yet Another List, it has been hard enough to get them on > maintainers, I don't want to tell them now they have to be on TWO lists. > This is why I'm so adamant about this, it is _NOT_ just FESCO. The belief that all *VOLUNTEERS* can be expected to follow a discussion list like fedora-maintainers and not miss important announcements is just plain wrong. We will NEVER win if we truly expect this to happen. RH engineers is a different story. It is at least possible for their management to expect them to follow as part of their job. fedora-maintainers-announce is going forward, to be subscribed with folks in Extras owners.list. If you have a problem with this, then it would require FPB to veto FESCO's decision. Warren Togami wtogami at redhat.com From jkeating at redhat.com Thu Dec 14 16:53:02 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Dec 2006 11:53:02 -0500 Subject: fedora-maintainers-annouce In-Reply-To: <45817656.5070500@redhat.com> References: <45804CC5.3090201@leemhuis.info> <200612141047.17709.jkeating@redhat.com> <45817656.5070500@redhat.com> Message-ID: <200612141153.02981.jkeating@redhat.com> On Thursday 14 December 2006 11:05, Warren Togami wrote: > The belief that all *VOLUNTEERS* can be expected to follow a discussion > list like fedora-maintainers and not miss important announcements is > just plain wrong. ?We will NEVER win if we truly expect this to happen. > > RH engineers is a different story. ?It is at least possible for their > management to expect them to follow as part of their job. > > fedora-maintainers-announce is going forward, to be subscribed with > folks in Extras owners.list. > > If you have a problem with this, then it would require FPB to veto > FESCO's decision. If you're that hell bent on it, the suggestion I have is to subscribe maintainers-list to maintainers-announce so that if people want it all, they just subscribe to -list rather than both. People who just want announcements (and miss out entirely in the ability to drive the direction of Fedora) can sub to -announce. I still don't like more lists, but... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From smooge at gmail.com Thu Dec 14 19:21:53 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 14 Dec 2006 12:21:53 -0700 Subject: Fedora release lifecyle In-Reply-To: <1166102355.6110.2.camel@zod.rchland.ibm.com> References: <45802B60.8020309@fedoraproject.org> <200612131509.30760.jkeating@redhat.com> <458070FC.8010209@fedoraproject.org> <200612131642.45697.jkeating@redhat.com> <1166049333.5253.802.camel@pmac.infradead.org> <1166102355.6110.2.camel@zod.rchland.ibm.com> Message-ID: <80d7e4090612141121p4a0141e9ub23bd078c67122fa@mail.gmail.com> On 12/14/06, Josh Boyer wrote: > On Wed, 2006-12-13 at 22:35 +0000, David Woodhouse wrote: > > On Wed, 2006-12-13 at 16:42 -0500, Jesse Keating wrote: > > > Look, lets be honest here. Fedora isn't all that great of a distro for a > > > stable server. We don't do backports, we play with new technology, we've got > > > a fast paced development cycle, etc... Lets not try to be something we > > > aren't. > > > > Actually I find that ideal for a mail server. I _want_ to keep Exim, > > SpamAssassin and ClamAV up to date. All my servers run Fedora. > > As do mine. Fedora as a server is fine for quite a few people and use > cases. > Fedora is a good server operating system where you have control of the hardware, only have a certain number of servers you are going to maintain, need cutting edge software, and/or have the staff to upgrade servers on a 6 month cycle. The reason I say a 6 month cycle is that for an enterprise it takes about 2-3 months after an OS before it is usually considered 'known' enough to be put in mass production for servers/desktops. That leaves about 6 (now 10 months) before you have to upgrade again. Doing 1-10 servers by yourself is doable. Trying to do a 500+ servers that some genius thought FC-5 would be perfect on because it had stuff RHEL-4 didnt.. is a nightmare. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mmcgrath at fedoraproject.org Thu Dec 14 20:35:37 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 14 Dec 2006 14:35:37 -0600 Subject: SCM Sig Message-ID: <3237e4410612141235o3e7a432ay7693184a01c455f1@mail.gmail.com> We need a one time SIG to discuss the future of our version control systems (CVS, SVN, mercurial, git?) Interested parties please add approperate information to the SIG page: http://fedoraproject.org/wiki/Infrastructure/SCMSig (GIT and mercurial users especially requested) We will be sending out the initial meeting notes in 1 week. -Mike From wwoods at redhat.com Fri Dec 15 19:26:43 2006 From: wwoods at redhat.com (Will Woods) Date: Fri, 15 Dec 2006 19:26:43 +0000 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> Message-ID: <1166210803.17143.85.camel@metroid.rdu.redhat.com> On Tue, 2006-12-12 at 17:37 -0500, Max Spevack wrote: > Here was the proposal we came up with (modified for a Tuesday release, not > a Monday release), working backward: > > RH Summit May 9-11 > Release April 24 (exactly 6 months after FC6) > Gold April 17 > Test3 March 27 > Test2 February 27 > FudCon February 9-11 (including hackfest) > Test1 January 30 This question came up during yesterday's Fedora QA meeting - does this schedule take into account the release dates of major projects like GNOME? I know the GNOME 2.18.0 release is scheduled for March 14, which should be fine. Still - was this schedule aligned against any others? If so, which ones? -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Fri Dec 15 19:38:22 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 15 Dec 2006 14:38:22 -0500 Subject: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <1166210803.17143.85.camel@metroid.rdu.redhat.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <1166210803.17143.85.camel@metroid.rdu.redhat.com> Message-ID: <20061215193822.GA29549@nostromo.devel.redhat.com> Will Woods (wwoods at redhat.com) said: > I know the GNOME 2.18.0 release is scheduled for March 14, which should > be fine. Still - was this schedule aligned against any others? No. Bill From chitlesh at fedoraproject.org Sat Dec 16 17:06:41 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sat, 16 Dec 2006 18:06:41 +0100 Subject: [fab] [Fedora-marketing-list] suse/opensuse contributors For Fedora ? (fwd) In-Reply-To: References: Message-ID: <13dbfe4f0612160906t2fb9ee77g99b6c1be301353be@mail.gmail.com> On 11/7/06, Greg Dekoenigsberg wrote: > > Maybe something worth discussing specifically next week: the status of > KDE. Shall we now ? :) Chitlesh -- http://clunixchit.blogspot.com From sundaram at fedoraproject.org Sun Dec 17 11:07:54 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 17 Dec 2006 16:37:54 +0530 Subject: Fedora release lifecyle In-Reply-To: <80d7e4090612132226r66127638sad0a1d9ac83bce21@mail.gmail.com> References: <45802B60.8020309@fedoraproject.org> <200612131509.30760.jkeating@redhat.com> <458070FC.8010209@fedoraproject.org> <200612131642.45697.jkeating@redhat.com> <458078EC.6010209@fedoraproject.org> <20061213221338.GB6646@nostromo.devel.redhat.com> <4580DF05.6080208@fedoraproject.org> <80d7e4090612132226r66127638sad0a1d9ac83bce21@mail.gmail.com> Message-ID: <4585250A.6040101@fedoraproject.org> Stephen John Smoogen wrote: > > The question that needs to be answered is who is the customer and what > are they going to pay for this? Payment does not need to be cash, but > it would help. The reason is that someone is going to have to pay for > the engineering, qa, documentation, bandwidth, etc. > > The past has shown that Legacy gets volunteers who are interested in > certain packages and/or releases. Once that release is up, they are no > longer interested as they have usually transitioned their stuff to > Centos, Ubuntu, etc. > > There are people who want longer release times, but I have not seen > that want translated into either cash or volunteer time. My opinion is > that while I would like to see 18 months of support, I am already > getting 4 free boons from Red Hat: 1) regularly compiled and tested > bits called Fedora X (versus just rawhide), 2) 11-13 months of > security updates and some enhancement updates, 3) source code for > their RHEL which people can get compiled bits from > Centos/Whitebox/EatAtJoesLinux, and 4) source code for security > updates for RHEL for 7 years (where you can get the compiled bits from > EatAtJoes Enterprise Linux). > > For anything more than that.. I need to supply something to the bargain. 3) and 4) while beneficial is irrelevant if you would consider Fedora as a independent distribution. I am not bargaining. I consider 18 months as a good balance and I am putting up a RFE on that. That's generally considered a contribution by itself. If you would consider the current effort as a merge between core,extras and legacy, we need to look at letting open the possibility of a longer lifecycle since the lower barrier to entry aided by the focus on a single infrastructure might help us get more volunteers involved now. Rahul From jkeating at redhat.com Sun Dec 17 12:51:00 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 17 Dec 2006 07:51:00 -0500 Subject: Fedora release lifecyle In-Reply-To: <4585250A.6040101@fedoraproject.org> References: <45802B60.8020309@fedoraproject.org> <80d7e4090612132226r66127638sad0a1d9ac83bce21@mail.gmail.com> <4585250A.6040101@fedoraproject.org> Message-ID: <200612170751.03400.jkeating@redhat.com> On Sunday 17 December 2006 06:07, Rahul Sundaram wrote: > If you would consider the current effort as a merge between core,extras > and legacy, we need to look at letting open the possibility of a longer > lifecycle since the lower barrier to entry aided by the focus on a > single infrastructure might help us get more volunteers involved now. I wouldn't count on that. When newer versions are available, the mass majority of your userbase is going to flock to those newer versions, leaving the older versions behind. By and large the people would care about versions more than 13 months old are going to be the same people who have no time to contribute anything toward them. You'd be asking maintainers to care about four (five or six if you count EPEL) different branches of their software, many of these maintainers are volunteers. That's a huge commitment to make, especially if they're not getting paid for it. I think the experiment of longer lifespan has been tried, and it failed. 13 months is a great place to make our new line, and anything more is better suited by other products. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwade at redhat.com Sun Dec 17 19:48:04 2006 From: kwade at redhat.com (Karsten Wade) Date: Sun, 17 Dec 2006 11:48:04 -0800 Subject: mailing-list reorganisation In-Reply-To: <200612131332.26176.dennis@ausil.us> References: <45804CC5.3090201@leemhuis.info> <200612131332.26176.dennis@ausil.us> Message-ID: <1166384885.30044.181.camel@erato.phig.org> On Wed, 2006-12-13 at 13:32 -0600, Dennis Gilmore wrote: > Fedora-docs-br > Fedora-docs-commits > fedora-docs-list > fedora-dsco-list > is there even a dsco? i had not heard of them until looking at the list The Fedora Documentation Steering Committee (FDSCo) uses f-dsco-l for administrivia. We've discussed merging it back into f-docs-l, and we'll handle that decision. The Brazilian team has had enough going in their native language to justify the creation of a stand-alone list. We encourage the creation of documentation in native languages, to be later translated. - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Sun Dec 17 19:58:19 2006 From: kwade at redhat.com (Karsten Wade) Date: Sun, 17 Dec 2006 11:58:19 -0800 Subject: mailing-list reorganisation In-Reply-To: <45804CC5.3090201@leemhuis.info> References: <45804CC5.3090201@leemhuis.info> Message-ID: <1166385499.30044.189.camel@erato.phig.org> On Wed, 2006-12-13 at 19:56 +0100, Thorsten Leemhuis wrote: > === fedora-project-list == +1 Good idea for all the right reasons. If anything on that list gets too detailed by subject, it can be pushed down to the appropriate list. We have been suffering without a single location to discuss the overall project as a project. - Karsten, who _doesn't_ want to have to read all of f-devel-l and f-maintainers to know what is going on around here. -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Mon Dec 18 17:45:05 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 18 Dec 2006 18:45:05 +0100 Subject: Defining high-level objectives for a release? Re: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <1166043363.8524.8.camel@cassandra.boston.redhat.com> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <1166042946.25310.20.camel@cassandra.boston.redhat.com> <1166043363.8524.8.camel@cassandra.boston.redhat.com> Message-ID: <4586D3A1.2020902@leemhuis.info> Hi all! No one replied to this mail, so I'll bite (albeit a bit late) David Malcolm schrieb: > On Tue, 2006-12-12 at 17:37 -0500, Max Spevack wrote: >> On Tue, 12 Dec 2006, Thorsten Leemhuis wrote: >>> January 02 is probably to hard to reach, so we should cut one cycle from >>> four to three weeks. Which one? test3 maybe? >> We talked about this in the Board meeting this morning. >> Here was the proposal we came up with (modified for a Tuesday release, not >> a Monday release), working backward: >>[...] > The reverse-chronological list above defines some dates for releases of > things that might be called "deliverables". These deliverables are > currently all software trees. > > Is it possible to add the high-level objectives for what a release might > contain as the first deliverable? > - integrate Core and Extras >[...] > - static analysis for the whole distro > or whatever... (currently the only thing I know of for F7 is the first > one) > [...] > IMHO the only way we can get whole-distribution improvements rather than > incremental changes here and there is to try to define and aim for them > at the start of a development cycle. I like the idea of setting clear goals/roadmaps with target dates for certain features (even if they get delayed/and or even pushed back to one release later if that's needed). I think that might help getting some real improvements realized and the community integrated better -- we currently often do some improvements "here and there" (as you wrote above) in Fedora, but there is no "big picture/goal" visible :-( (at least I can't see one) But it might be a bit late for F7 to really use this scheme. Only some rough stuff should be put together IMHO, e.g. "integrate Core and Extras by test2". Then let's start properly with F8: First week of May -> lean back and look at F7; get some fresh air, look at what worked good, what needs to be improved for the next round Second week of May -> set some goals for F8/a new Fedora Summit -- work out a release date, a roadmap with features that are planed to be impelmented for test[123] and final (think like David mentioned in his mail like "integrate lobby-buddy [1] throughout the distro", "reduce the bootup time", "attempt to fix system services" .... Cu thl From notting at redhat.com Mon Dec 18 18:40:47 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 18 Dec 2006 13:40:47 -0500 Subject: Defining high-level objectives for a release? Re: fedora 7 schedule (was Re: Fedora 7 planing) In-Reply-To: <4586D3A1.2020902@leemhuis.info> References: <457D9F7D.8030007@leemhuis.info> <457E4848.2050806@leemhuis.info> <1166042946.25310.20.camel@cassandra.boston.redhat.com> <1166043363.8524.8.camel@cassandra.boston.redhat.com> <4586D3A1.2020902@leemhuis.info> Message-ID: <20061218184047.GC11276@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > First week of May -> lean back and look at F7; get some fresh air, look > at what worked good, what needs to be improved for the next round > Second week of May -> set some goals for F8/a new Fedora Summit -- work > out a release date, a roadmap with features that are planed to be > impelmented for test[123] and final (think like David mentioned in his > mail like "integrate lobby-buddy [1] throughout the distro", "reduce > the bootup time", "attempt to fix system services" .... Nah, it's never too late to start that. More later. :) Bill From blizzard at redhat.com Tue Dec 19 05:46:49 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 19 Dec 2006 00:46:49 -0500 Subject: 5k packages? Message-ID: <45877CC9.8030608@redhat.com> I just noticed that we passed through the 5k packages mark in extras. Kinda neat - seems to be continuing to slowly grow. :D --Chris From notting at redhat.com Tue Dec 19 05:59:05 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Dec 2006 00:59:05 -0500 Subject: F7 Plan (draft) Message-ID: <20061219055905.GC19172@nostromo.devel.redhat.com> Hey, F7 needs a plan. So here's one. It's not in taskjuggler or MrProject. Nor does it have pretty gantt charts. Those can be added by those that care about such things. Section the First: Schedule Simple stuff. These are availability dates. Freeze dates are minus-1 week. Test1: January 30 Test2: February 27 Test3: March 26 GA: April 24 Special dates: Test2 Freeze == FEATURE FREEZE. If a Feature(tm, see below) of the release is not in a testable state at this point, it goes out. Test2 Freeze == STRING FREEZE. Gotta give the translators something to go with. We know there may be small bits that come later, but the intent is to be frozen at this date. Section the Second: Features (tm) Obviously, there are features that we'd like to have for a release. Here's what we've got, and how it fits in to the schedule. These are the 'defined' features of the release. Sure, there will be other stuff that is part of upstream projects, but this is what we're Trying To Do for F7. Mini-FAQ: Q: How did you come up with this? A: Stuff that's been talked about in one place or another, stuff that I've heard floating around, and stuff that I've made up. Q: Why is there names by these things. How did my name get there? A: Features(tm) need Names Of Accountable People. In other words, these are the people that we come to harass about the state of Features if they don't land. If your name is here, it's because you've mentioned working on it, or you seemed logical. Features without accountable people may be dropped. Q: Hey, you didn't list a date for that feature! A: If not stated, all features must be Testable by test 2, or risk eviction. All features must be fully functional by test 3, or risk eviction. Q: I've got this great feature idea! A: OK. Are you going to work on it? Can you cajole/force someone else to be Accountable? Then we'll add it! (This is going on the wiki eventually, of course.) Q: Who decides what gets evicted, or what may land post-freeze? A: The Committee! TBD, but logical names would be, in no particular order, Will Woods (QA), Jesse Keating (rel-eng), Dave Jones (kernel), Jonathan Blandford (desktop), Rex Dieter (KDE), Bill Nottingham (random bastard), Jeremy Katz (random bastard). Anyways, in no particular order, the feature list... 1. Build System for merged core and extras Accountable: Jesse Keating Important dates: Needs DONE by Test 2. Needs to be TESTABLE by test 1. Welcome to our short runway. More info: http://fedoraproject.org/wiki/FedoraSummit/NewBuildSystem 2. Merge Core and Extras in source control Accountable: Jesse Keating, EVERYONE Important dates: Leaf packages may start to be moved at . All packages WILL be moved by Test 2, gating on feature #1. Reviews will take place, there will be an automated system to determine what needs review. 3. Use Pungi for tree building Accountable: Jesse Keating Must be nearly fully functional by Test 2, as it is a prereq of later features. 4. A Fedora Desktop spin of F7 Accountable: Jesse Keating (rel-eng), Jonathan Blandford, the Fedora Desktop SIG (what, you say there isn't one?) One of our release targets. Needs defined by Test 2. Test 1 can be an old-style tree. 5. A Fedora Server spin of F7 Accountable: Jesse Keating (rel-eng), YOUR NAME HERE! Another one of our release targets. Needs defined by Test 2. 6. A Fedora KDE spin of F7 Accountable: Rex Dieter Like Fedora Desktop, but with KDE. 7. Fast User Switching Accountable: David Zeuthen We want the ability to easily and quickly switch between user sessions, without logging out. More info: http://fedoraproject.org/wiki/Desktop/FastUserSwitching 8. Rock Solid Wireless Accountable: Dan Williams, Dave Jones For every wireless card we support, we should have working, tested support - it comes up on boot, it associates, it works with WEP and WPA, all out of the box. A requisite for hitting the laptop market. Drive fixes through NM, wpa_supplicant, kernel. 9. Wireless Firmware Accountable: Fedora-legal, me! For every wireless card we support and can get firmware to, we should work to make it included so things work out of the box. 10. Boot and shutdown speedup Accountable: me!, David Zeuthen, YOUR NAME HERE We do enough Stupid Stuff that we can make easy improvements to startup and shutdown time without large systemic changes. Includes: tagging of scripts that don't need shut down, profiling of boot, potential changes to how we organize disk blocks, and more. Does Not Include: init system changes 11. Init system work Accountable: YOUR NAME HERE Evaluate: upstart, launchd, initng. Compare, contrast, benchmark. Define usage cases, see what fits what, and what is useful. Lots of research. Not much code. 12. rpm/yum enhancements Accountable: Jeremy Katz, Paul Nasrat, Seth Vidal We feel the need for speed. Profile the rpm/python/yum stack. Find the hotspots. Fix them. 13. LobbyBuddy Accountable: Greg DeKoenigsberg Given your locale and timezone, determine where you are, and who your elected representative is. Allow you to easily send them information about how the laws should be changed with respect to patents and other important issues. If it determines you do not have a duly elected representative, offer a special initiative to lobby foreign representative to install a new regime. (I'M KIDDING!) 14. MP3Buddy Accountable: Greg DeKoenigsberg Detect the usage of MP3 without appropriate support. Explain to the user why Freedom Isn't Free, but offer to point them to a site where they can obtain legal MP3 support (or other codecs for which legal support exists.) 15. RandR 1.2 Accountable: Adam Jackson RandR 1.2 is the new black. Even if you don't know you want it, you want it. Potential exists for a backport to the code we will be using, but there are no guarantees. 16. KVM virtualization support Accountable: Dan Berrange, Daniel Veillard Get KVM support, including QEMU, into virt-manager and libvirt. Make it so the same tools can use KVM and Xen. Integrate networking support so the same networking can be used for Xen, KVM, and maybe baremetal. Special bonus: lhype? 17. Fix the dictionary problem Accountable: Caolan McNamara, Chris Aillon, Jeremy Katz, AND YOU Split out hunspell. Make FF use it. Make OO.o use it. Split out the dictionaries. Write an aspell compat layer for those dictionaries. Woo, only one set of dictionaries for the distro! More info: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207571 18. Move to using libata for PATA support Accountable: Dave Jones, Peter Jones, potentially other Joneses Make upgrades seamless, because not booting is bad. Must be done by TEST 1. 19. Move to syslog-ng Accountable: YOUR NAME HERE Hey, people ask for this. Evaluate it, package it, make sure there are no regressions. 20. Improved firewire support Accountable: Kristian H?gsberg Make it sane/supportable/etc. 21. Real-time kernel Accountable: Ingo Molnar, Dave Jones Because fake-time kernels are so last year 22. Tickless kernel support Accountable: Ingo Molnar, Dave Jones Saving power is good, mmkay? 23. Fix wakeups across the distribution Accountable: me, EVERYONE Because, without this, having a tickless kernel is pointless. 24. Encrpyted filesystems Accountable: YOUR NAME HERE Encfs, fuse, eCryptfs - Evaluate. Choose. Implement. Deploy. 25. LiveCD Accountable: David Zeuthen, Jeremy Katz, Jesse Keating Get LiveCDs built and shipped as part of the release process. Make them installable. Section the Third: Additions, Constructive Criticism, and Bellyaching Got more? Let me know! Got quibbles with me dropping stuff in your (or your people's) lap? Let me know! From davej at redhat.com Tue Dec 19 06:36:05 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 19 Dec 2006 01:36:05 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061219055905.GC19172@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> Message-ID: <20061219063605.GF31146@redhat.com> On Tue, Dec 19, 2006 at 12:59:05AM -0500, Bill Nottingham wrote: > Hey, F7 needs a plan. So here's one Nice work. Hannibal Smith would be proud. > 2. Merge Core and Extras in source control > Accountable: Jesse Keating, EVERYONE > > Important dates: Leaf packages may start to be moved at . > All packages WILL be moved by Test 2, gating on feature #1. Reviews will > take place, there will be an automated system to determine what needs > review. slight tangential thing: Something that will be needed at some point is an external variant of qabot (for outsiders, we have an irc bot internally that allows things like.. /m qabot whoowns kernel kernel is owned by Dave Jones This would make a nice 'easy' project for a community member wanting to contribute to Fedora. It's been a gripe of mine for a while that no equivalent existed for extras. Now, I guess the issue is being forced. > 4. A Fedora Desktop spin of F7 > Accountable: Jesse Keating (rel-eng), Jonathan Blandford, the Fedora > Desktop SIG (what, you say there isn't one?) > > One of our release targets. Needs defined by Test 2. Test 1 can > be an old-style tree. > > 5. A Fedora Server spin of F7 > Accountable: Jesse Keating (rel-eng), YOUR NAME HERE! > > Another one of our release targets. Needs defined by Test 2. I'm prepared to step up and lend a hand defining this if Jesse feels overwhelmed (I note he has a number of the big ticket items). > 8. Rock Solid Wireless > Accountable: Dan Williams, Dave Jones > > For every wireless card we support, we should have working, tested > support - it comes up on boot, it associates, it works with WEP and > WPA, all out of the box. A requisite for hitting the laptop market. > Drive fixes through NM, wpa_supplicant, kernel. Yes. One thing needed for this will be at least one of every piece of hardware we care about, are we even close to this today ? > 9. Wireless Firmware > Accountable: Fedora-legal, me! > For every wireless card we support and can get firmware to, we should > work to make it included so things work out of the box. Oh yes. bring. it. > 10. Boot and shutdown speedup > Accountable: me!, David Zeuthen, YOUR NAME HERE > > We do enough Stupid Stuff that we can make easy improvements to startup > and shutdown time without large systemic changes. Includes: tagging of > scripts that don't need shut down, profiling of boot, potential changes > to how we organize disk blocks, and more. I'll have at least a partial involvement with this when I get around to integrating danpb's systemtap profiling goodness into the kernel rpm. Plus I love watching a good trainwreck :) > 16. KVM virtualization support > Accountable: Dan Berrange, Daniel Veillard > > Get KVM support, including QEMU, into virt-manager and libvirt. Make > it so the same tools can use KVM and Xen. Integrate networking support > so the same networking can be used for Xen, KVM, and maybe baremetal. > Special bonus: lhype? lhype may take quite a while. I'm optimistically thinking we can squeeze 2.6.21 into FC7. I expect .20 to land say, mid to end of January. given where lhype is today though, that's still not going to be a huge improvement, so at best we can hope for a 'tech preview' type thing that may be useful for people actually hacking on it. I fear we may actually have to support Xen for at least one more Fedora release. > 18. Move to using libata for PATA support > Accountable: Dave Jones, Peter Jones, potentially other Joneses Jeff Garzik and Alan Cox can be honorary Joneses if they lend a hand where needbe :) > Make upgrades seamless, because not booting is bad. Must be done > by TEST 1. This is the #1 things that makes me worry about meeting test1 on time. Worse case scenario, we can reenable the old PATA drivers rather than slip though, and then try again for test2. Still gives me the creeps though, but then again, it's only been a week so far, so all the scary looking bug reports may all disappear by test1. The xmas break doesn't make it any easier :-/ Worse yet, pretty much everything blocks on this. > 20. Improved firewire support > Accountable: Kristian H?gsberg > > Make it sane/supportable/etc. Can't really be any worse than the current situation, so what the hell. And it's going upstream eventually. > 21. Real-time kernel > Accountable: Ingo Molnar, Dave Jones > Because fake-time kernels are so last year Scary. Invasive. Bits going upstream periodically. Not convinced this is a good idea for us to carry with all the other huge stuff we have that we're trying to shed. Right now for eg, all the big stuff is busted to hell. Tux, Xen, signed modules etc. > 22. Tickless kernel support > Accountable: Ingo Molnar, Dave Jones > > Saving power is good, mmkay? Indeedy. Hopefully Ingo can whack the remaining oddnesses and this will get upstream real soon. > 23. Fix wakeups across the distribution > Accountable: me, EVERYONE > > Because, without this, having a tickless kernel is pointless. Yes++ Arjan had a useful tracking bug on this problem. I recommend using it (or making a new one) so that interested parties can subscribe to it. > 25. LiveCD > Accountable: David Zeuthen, Jeremy Katz, Jesse Keating > > Get LiveCDs built and shipped as part of the release process. Make > them installable. > > Section the Third: Additions, Constructive Criticism, and Bellyaching > > Got more? Let me know! 26. Nouveau. Accountable: Me, Ajax. Because binary drivers are the suck, and pimping rev-eng efforts like this should be what distros should be advocating instead of whining about how they 'need' to ship binary drivers for their cracktastic desktop effects. Lets lead by example by showcasing this work, even if its rough around the edges. We can always improve on it more later. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Tue Dec 19 07:16:08 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 19 Dec 2006 02:16:08 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061219063605.GF31146@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <20061219063605.GF31146@redhat.com> Message-ID: <20061219071608.GA25461@redhat.com> On Tue, Dec 19, 2006 at 01:36:05AM -0500, Dave Jones wrote: > On Tue, Dec 19, 2006 at 12:59:05AM -0500, Bill Nottingham wrote: > > Hey, F7 needs a plan. So here's one > > Nice work. Hannibal Smith would be proud. Something just occured to me. This should probably be on the wiki after an initial pass of comments on this list. Dave -- http://www.codemonkey.org.uk From skvidal at linux.duke.edu Tue Dec 19 11:24:30 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 19 Dec 2006 06:24:30 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061219055905.GC19172@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> Message-ID: <1166527470.19477.13.camel@cutter> On Tue, 2006-12-19 at 00:59 -0500, Bill Nottingham wrote: > 12. rpm/yum enhancements > Accountable: Jeremy Katz, Paul Nasrat, Seth Vidal > > We feel the need for speed. Profile the rpm/python/yum stack. Find the > hotspots. Fix them. We've got a couple of obvious things but at least one of them will require changing what is in the repository data. > > 19. Move to syslog-ng > Accountable: YOUR NAME HERE > > Hey, people ask for this. Evaluate it, package it, make sure there > are no regressions. I've emailed Jose Oliveira about syslog-ng 2.0 in extras development and when/if it will be there. We aren't interested in preserving someone's settings from syslog, right? -sv From skvidal at linux.duke.edu Tue Dec 19 14:14:14 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 19 Dec 2006 09:14:14 -0500 Subject: F7 Plan (draft) In-Reply-To: <1166527470.19477.13.camel@cutter> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <1166527470.19477.13.camel@cutter> Message-ID: <1166537654.19477.41.camel@cutter> On Tue, 2006-12-19 at 06:24 -0500, seth vidal wrote: > On Tue, 2006-12-19 at 00:59 -0500, Bill Nottingham wrote: > > > 12. rpm/yum enhancements > > Accountable: Jeremy Katz, Paul Nasrat, Seth Vidal > > > > We feel the need for speed. Profile the rpm/python/yum stack. Find the > > hotspots. Fix them. > > We've got a couple of obvious things but at least one of them will > require changing what is in the repository data. > > > > 19. Move to syslog-ng > > Accountable: YOUR NAME HERE > > > > Hey, people ask for this. Evaluate it, package it, make sure there > > are no regressions. > > I've emailed Jose Oliveira about syslog-ng 2.0 in extras development and > when/if it will be there. We aren't interested in preserving someone's > settings from syslog, right? > According to Jpo, Peter Vrabec a red hat person is working on switching out sysklogd for syslog-ng. Can someone inside the fence ping Peter about this? -sv From matt at domsch.com Tue Dec 19 14:47:04 2006 From: matt at domsch.com (Matt Domsch) Date: Tue, 19 Dec 2006 08:47:04 -0600 Subject: 5k packages? In-Reply-To: <45877CC9.8030608@redhat.com> References: <45877CC9.8030608@redhat.com> Message-ID: <20061219144703.GA15354@domsch.com> On Tue, Dec 19, 2006 at 12:46:49AM -0500, Christopher Blizzard wrote: > I just noticed that we passed through the 5k packages mark in extras. > Kinda neat - seems to be continuing to slowly grow. :D well, 2500 (exactly) SRPMS, but yes, quite an accomplishment. -Matt From luis at tieguy.org Tue Dec 19 14:53:04 2006 From: luis at tieguy.org (Luis Villa) Date: Tue, 19 Dec 2006 09:53:04 -0500 Subject: 5k packages? In-Reply-To: <20061219144703.GA15354@domsch.com> References: <45877CC9.8030608@redhat.com> <20061219144703.GA15354@domsch.com> Message-ID: <2cb10c440612190653h658ee36cx3a1bc1c7fe2c66a9@mail.gmail.com> On 12/19/06, Matt Domsch wrote: > On Tue, Dec 19, 2006 at 12:46:49AM -0500, Christopher Blizzard wrote: > > I just noticed that we passed through the 5k packages mark in extras. > > Kinda neat - seems to be continuing to slowly grow. :D > > well, 2500 (exactly) SRPMS, but yes, quite an accomplishment. I know this is sort of a bogus stat, but has anyone considered graphing this growth against the growth of debian and opensuse? One of the big criticisms of fedora/RH was always that, compared to debian and suse, there were many fewer centrally packaged programs which could be relied upon to cleanly install and run, so it seems like showing that Fedora is growing in this respect would be a nice marketing point. Luis From jkeating at redhat.com Tue Dec 19 15:25:49 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 Dec 2006 10:25:49 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061219055905.GC19172@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> Message-ID: <200612191025.52265.jkeating@redhat.com> On Tuesday 19 December 2006 00:59, Bill Nottingham wrote: > Q: Why is there names by these things. How did my name get there? {snip} > Accountable: Jesse Keating {repeat many times} All I want for Christmas is a few clones... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Tue Dec 19 15:31:43 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 19 Dec 2006 10:31:43 -0500 Subject: F7 Plan (draft) In-Reply-To: <200612191025.52265.jkeating@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <200612191025.52265.jkeating@redhat.com> Message-ID: <20061219153143.GH25461@redhat.com> On Tue, Dec 19, 2006 at 10:25:49AM -0500, Jesse Keating wrote: > On Tuesday 19 December 2006 00:59, Bill Nottingham wrote: > > Q: Why is there names by these things. How did my name get there? > > {snip} > > > Accountable: Jesse Keating > > {repeat many times} > > All I want for Christmas is a few clones... We were going to keep it a secret, but the codename for F7 is also going to be "Jesse Keating". It's the logical progression from Zod. Dave -- http://www.codemonkey.org.uk From dennis at ausil.us Tue Dec 19 15:37:05 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 19 Dec 2006 09:37:05 -0600 Subject: 5k packages? In-Reply-To: <2cb10c440612190653h658ee36cx3a1bc1c7fe2c66a9@mail.gmail.com> References: <45877CC9.8030608@redhat.com> <20061219144703.GA15354@domsch.com> <2cb10c440612190653h658ee36cx3a1bc1c7fe2c66a9@mail.gmail.com> Message-ID: <200612190937.06541.dennis@ausil.us> On Tuesday 19 December 2006 08:53, Luis Villa wrote: > On 12/19/06, Matt Domsch wrote: > > On Tue, Dec 19, 2006 at 12:46:49AM -0500, Christopher Blizzard wrote: > > > I just noticed that we passed through the 5k packages mark in extras. > > > Kinda neat - seems to be continuing to slowly grow. :D > > > > well, 2500 (exactly) SRPMS, but yes, quite an accomplishment. > > I know this is sort of a bogus stat, but has anyone considered > graphing this growth against the growth of debian and opensuse? One of > the big criticisms of fedora/RH was always that, compared to debian > and suse, there were many fewer centrally packaged programs which > could be relied upon to cleanly install and run, so it seems like > showing that Fedora is growing in this respect would be a nice > marketing point. > > Luis One thing that needs consideration in the comparison is that debain splits things up in to the smallest possible binary package. We do not do that. the fairest comparison is to look at the Sources. by my count Fedora (core+extras) has ~3600 SRPMS by a count in #suse 3015 src.rpm, 54 nosrc.rpm (not sure what a nosrc.rpm is but i guess proprietary stuff) Debian im still looking to find numbers. -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From notting at redhat.com Tue Dec 19 17:09:16 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Dec 2006 12:09:16 -0500 Subject: F7 Plan (draft) In-Reply-To: <1166527470.19477.13.camel@cutter> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <1166527470.19477.13.camel@cutter> Message-ID: <20061219170916.GA25507@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > We've got a couple of obvious things but at least one of them will > require changing what is in the repository data. Hm, is this using raw sqlite? I'd like to avoid this, if possible. > > 19. Move to syslog-ng > > Accountable: YOUR NAME HERE > > > > Hey, people ask for this. Evaluate it, package it, make sure there > > are no regressions. > > I've emailed Jose Oliveira about syslog-ng 2.0 in extras development and > when/if it will be there. We aren't interested in preserving someone's > settings from syslog, right? If it's dead simple to migrate, it might be nice to handle automatically; if it's not, I wouldn't worry too much. Bill From notting at redhat.com Tue Dec 19 17:19:58 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Dec 2006 12:19:58 -0500 Subject: Fedora Board meeting, Tuesday 12/19 Message-ID: <20061219171958.GA26469@nostromo.devel.redhat.com> at 5PM Eastern, 2200 UTC. chat/logs from #fedora-board as we've been doing for the last while. Might be sparsely attended due to holidays. Topics: - rpm post-mortem? - F7 progress - other things as suggested or brought up Bill From skvidal at linux.duke.edu Tue Dec 19 17:29:54 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 19 Dec 2006 12:29:54 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061219170916.GA25507@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <1166527470.19477.13.camel@cutter> <20061219170916.GA25507@nostromo.devel.redhat.com> Message-ID: <1166549394.19477.87.camel@cutter> On Tue, 2006-12-19 at 12:09 -0500, Bill Nottingham wrote: > seth vidal (skvidal at linux.duke.edu) said: > > We've got a couple of obvious things but at least one of them will > > require changing what is in the repository data. > > Hm, is this using raw sqlite? I'd like to avoid this, if possible. why? It's how we're going to make a big dent in yum's startup time. -sv From notting at redhat.com Tue Dec 19 17:33:56 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Dec 2006 12:33:56 -0500 Subject: F7 Plan (draft) In-Reply-To: <1166549394.19477.87.camel@cutter> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <1166527470.19477.13.camel@cutter> <20061219170916.GA25507@nostromo.devel.redhat.com> <1166549394.19477.87.camel@cutter> Message-ID: <20061219173356.GA26854@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > > Hm, is this using raw sqlite? I'd like to avoid this, if possible. > > why? It's how we're going to make a big dent in yum's startup time. Just to avoid changing the repository format too many times. While it is part of iterative development, it's the sort of thing we'd like to keep stable. Bill From skvidal at linux.duke.edu Tue Dec 19 17:46:45 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 19 Dec 2006 12:46:45 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061219173356.GA26854@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <1166527470.19477.13.camel@cutter> <20061219170916.GA25507@nostromo.devel.redhat.com> <1166549394.19477.87.camel@cutter> <20061219173356.GA26854@nostromo.devel.redhat.com> Message-ID: <1166550405.19477.93.camel@cutter> On Tue, 2006-12-19 at 12:33 -0500, Bill Nottingham wrote: > seth vidal (skvidal at linux.duke.edu) said: > > > Hm, is this using raw sqlite? I'd like to avoid this, if possible. > > > > why? It's how we're going to make a big dent in yum's startup time. > > Just to avoid changing the repository format too many times. While it > is part of iterative development, it's the sort of thing we'd like > to keep stable. > It wouldn't be removing the other format. Just adding this format as a step on the way. Also yum would be able to handle both .xml files and the .db files - it would just be much faster hitting the db files. Otherwise I'm not sure what else we can do to make the metadata importing much faster. -sv From notting at redhat.com Tue Dec 19 18:00:22 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Dec 2006 13:00:22 -0500 Subject: F7 Plan (draft) In-Reply-To: <1166550405.19477.93.camel@cutter> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <1166527470.19477.13.camel@cutter> <20061219170916.GA25507@nostromo.devel.redhat.com> <1166549394.19477.87.camel@cutter> <20061219173356.GA26854@nostromo.devel.redhat.com> <1166550405.19477.93.camel@cutter> Message-ID: <20061219180022.GA27272@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > It wouldn't be removing the other format. Just adding this format as a > step on the way. Also yum would be able to handle both .xml files and > the .db files - it would just be much faster hitting the db files. > > Otherwise I'm not sure what else we can do to make the metadata > importing much faster. (getting wildly off topic) So, how about moving the process from the user's view (yum/pirut) to behind the scene (updatesd) - what if we rearchitect things so that updatesd does all the heavy lifting, and pirut/yum just call into that? Bill From skvidal at linux.duke.edu Tue Dec 19 18:08:04 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 19 Dec 2006 13:08:04 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061219180022.GA27272@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <1166527470.19477.13.camel@cutter> <20061219170916.GA25507@nostromo.devel.redhat.com> <1166549394.19477.87.camel@cutter> <20061219173356.GA26854@nostromo.devel.redhat.com> <1166550405.19477.93.camel@cutter> <20061219180022.GA27272@nostromo.devel.redhat.com> Message-ID: <1166551684.19477.95.camel@cutter> On Tue, 2006-12-19 at 13:00 -0500, Bill Nottingham wrote: > seth vidal (skvidal at linux.duke.edu) said: > > It wouldn't be removing the other format. Just adding this format as a > > step on the way. Also yum would be able to handle both .xml files and > > the .db files - it would just be much faster hitting the db files. > > > > Otherwise I'm not sure what else we can do to make the metadata > > importing much faster. > > (getting wildly off topic) > > So, how about moving the process from the user's view (yum/pirut) > to behind the scene (updatesd) - what if we rearchitect things so > that updatesd does all the heavy lifting, and pirut/yum just > call into that? won't help. You still have the sleep time while updatesd does what it does. Remember the olpc boxes. it took 5-6 minutes to do that - and updatesd works for crap on systems not connected to the network all the time. -sv From sundaram at fedoraproject.org Tue Dec 19 18:06:38 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 19 Dec 2006 23:36:38 +0530 Subject: F7 Plan (draft) In-Reply-To: <20061219055905.GC19172@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> Message-ID: <45882A2E.5030402@fedoraproject.org> Bill Nottingham wrote: > 4. A Fedora Desktop spin of F7 > Accountable: Jesse Keating (rel-eng), Jonathan Blandford, the Fedora > Desktop SIG (what, you say there isn't one?) > > One of our release targets. Needs defined by Test 2. Test 1 can > be an old-style tree. > > 5. A Fedora Server spin of F7 > Accountable: Jesse Keating (rel-eng), YOUR NAME HERE! > > Another one of our release targets. Needs defined by Test 2. Is there any specific plans for the desktop and server? The only new feature is I see listed is fast user switching. What other differences are there besides the set of packages? Are all these variants single CD's each? > 6. A Fedora KDE spin of F7 > Accountable: Rex Dieter > > Like Fedora Desktop, but with KDE. Have we thought about having a DVD/CD set of *all* packages? That would be useful for many places whether bandwidth or network access is constrained. The GNOME spin is called "Fedora Desktop" while the KDE one is called "Fedora KDE". Might consider more consistent branding. Speaking about KDE, are we looking at KDE 4? > 10. Boot and shutdown speedup > Accountable: me!, David Zeuthen, YOUR NAME HERE > > We do enough Stupid Stuff that we can make easy improvements to startup > and shutdown time without large systemic changes. Includes: tagging of > scripts that don't need shut down, profiling of boot, potential changes > to how we organize disk blocks, and more. Can we look at splitting up packages more during the mass review process? There were many discussions in fedora-devel list and bugzilla reports filed a while back. > 14. MP3Buddy > Accountable: Greg DeKoenigsberg > > Detect the usage of MP3 without appropriate support. Explain to the user > why Freedom Isn't Free, but offer to point them to a site where they can > obtain legal MP3 support (or other codecs for which legal support > exists.) I think we might be able to go a bit further than this. There is something similar described in https://launchpad.net/distros/ubuntu/+spec/easy-codec-installation Also it would be useful to look having a good client similar to bug-buddy but system wide for reporting bugs. Are we planning to have a new bugzilla instance at fedoraproject.org? > 21. Real-time kernel > Accountable: Ingo Molnar, Dave Jones > > Because fake-time kernels are so last year Is the motivation behind this the integration of Planet CCRMA? Are we going to start allowing alternative kernel like this into Fedora? Rahul From notting at redhat.com Tue Dec 19 18:10:35 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Dec 2006 13:10:35 -0500 Subject: F7 Plan (draft) In-Reply-To: <45882A2E.5030402@fedoraproject.org> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45882A2E.5030402@fedoraproject.org> Message-ID: <20061219181035.GB27272@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > >Another one of our release targets. Needs defined by Test 2. > > Is there any specific plans for the desktop and server? The only new > feature is I see listed is fast user switching. What other differences > are there besides the set of packages? Are all these variants single > CD's each? TBD. That's why there are people to do it. > >6. A Fedora KDE spin of F7 > >Accountable: Rex Dieter > > > >Like Fedora Desktop, but with KDE. > > Have we thought about having a DVD/CD set of *all* packages? That would > be useful for many places whether bandwidth or network access is > constrained. The Fedora 5-DVD Speical Edition Directors Cut with Added Footage? > The GNOME spin is called "Fedora Desktop" while the KDE > one is called "Fedora KDE". Might consider more consistent branding. > Speaking about KDE, are we looking at KDE 4? /me points at Rex. AFAIK, KDE4 is still a ways off. > >10. Boot and shutdown speedup > >Accountable: me!, David Zeuthen, YOUR NAME HERE > > > >We do enough Stupid Stuff that we can make easy improvements to startup > >and shutdown time without large systemic changes. Includes: tagging of > >scripts that don't need shut down, profiling of boot, potential changes > >to how we organize disk blocks, and more. > > Can we look at splitting up packages more during the mass review > process? There were many discussions in fedora-devel list and bugzilla > reports filed a while back. Not sure how that applies to this feature, but it's possible. However, 'splitting up packages' isn't really a feature without some sort of guidelines as to what we're trying to do. I mean, we could build a separate subpackage for each binary in coreutils if we wanted to. > Also it would be useful to look having a good client similar to > bug-buddy but system wide for reporting bugs. Are we planning to have a > new bugzilla instance at fedoraproject.org? Not currently, no. > >21. Real-time kernel > >Accountable: Ingo Molnar, Dave Jones > > > >Because fake-time kernels are so last year > > Is the motivation behind this the integration of Planet CCRMA? Are we > going to start allowing alternative kernel like this into Fedora? It's just an idea at this point. Considering what DaveJ said about its upstream status, it's likely to fall off the list. Bill From rdieter at math.unl.edu Tue Dec 19 18:16:55 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 19 Dec 2006 12:16:55 -0600 Subject: F7 Plan (draft) In-Reply-To: <20061219181035.GB27272@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45882A2E.5030402@fedoraproject.org> <20061219181035.GB27272@nostromo.devel.redhat.com> Message-ID: <45882C97.1020501@math.unl.edu> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >> The GNOME spin is called "Fedora Desktop" while the KDE >> one is called "Fedora KDE". Might consider more consistent branding. >> Speaking about KDE, are we looking at KDE 4? > > /me points at Rex. AFAIK, KDE4 is still a ways off. Yep, too far away, they don't even have any target dates set for KDE4 yet. -- Rex From jkeating at redhat.com Tue Dec 19 18:20:17 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 Dec 2006 13:20:17 -0500 Subject: F7 Plan (draft) In-Reply-To: <45882A2E.5030402@fedoraproject.org> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45882A2E.5030402@fedoraproject.org> Message-ID: <200612191320.17957.jkeating@redhat.com> On Tuesday 19 December 2006 13:06, Rahul Sundaram wrote: > > 5. A Fedora Server spin of F7 > > Accountable: Jesse Keating (rel-eng), YOUR NAME HERE! > > > > Another one of our release targets. Needs defined by Test 2. > > Is there any specific plans for the desktop and server? None yet. Welcome to the planning phase. > The only new > feature is I see listed is fast user switching. ?What other differences > are there besides the set of packages? That's most likely going to be the only set. Until such time as we have metadata outside the package for what services get started, etc.. the only difference we'll easily be able to make is what packages get included. > Are all these variants single > CD's each? Very difficult to do with the Desktop CDs, given that openoffice.org + translations is larger than a CD itself. For server, sure it would be nice to fit on a single CD. > > 6. A Fedora KDE spin of F7 > > Accountable: Rex Dieter > > > > Like Fedora Desktop, but with KDE. > > Have we thought about having a DVD/CD set of *all* packages? Somebody could do that. Given everything else that's on my plate, I'd rather not. > That would > be useful for many places whether bandwidth or network access is > constrained. ? Burn a DVD set of the tree itself, ship it somewhere to "seed" the mirror, go from there. > The GNOME spin is called "Fedora Desktop" while the KDE > one is called "Fedora KDE". Might consider more consistent branding. These are just generic made up names tossed out, not final marketing terms. Don't read too much into them. > Speaking about KDE, are we looking at KDE 4? Schedule doesn't mesh well. > > 10. Boot and shutdown speedup > > Accountable: me!, David Zeuthen, YOUR NAME HERE > > > > We do enough Stupid Stuff that we can make easy improvements to startup > > and shutdown time without large systemic changes. Includes: tagging of > > scripts that don't need shut down, profiling of boot, potential changes > > to how we organize disk blocks, and more. > > Can we look at splitting up packages more during the mass review > process? There were many discussions in fedora-devel list and bugzilla > reports filed a while back. I'd rather go for least change possible to get past the review. Much easier to consume rather than massive amounts of change. We have a ton on our plate as it is, lets not add more. [snip] >Are we planning to have a > new bugzilla instance at fedoraproject.org? I hope not, not until we can have bugzillas talk to eachother for cloning bugs, moving bugs around, etc... > > 21. Real-time kernel > > Accountable: Ingo Molnar, Dave Jones > > > > Because fake-time kernels are so last year > > Is the motivation behind this the integration of Planet CCRMA? Are we > going to start allowing alternative kernel like this into Fedora? Alternative kernels == doom. Its going to be bad enough if we have to do a standalone xen kernel that moves at a different pace than the other kernels. kmods blow up. Userland changes become harder to make. Security flaws... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From smooge at gmail.com Tue Dec 19 19:05:01 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 19 Dec 2006 12:05:01 -0700 Subject: 5k packages? In-Reply-To: <2cb10c440612190653h658ee36cx3a1bc1c7fe2c66a9@mail.gmail.com> References: <45877CC9.8030608@redhat.com> <20061219144703.GA15354@domsch.com> <2cb10c440612190653h658ee36cx3a1bc1c7fe2c66a9@mail.gmail.com> Message-ID: <80d7e4090612191105o13f6e336ld9fda56f3d25da57@mail.gmail.com> On 12/19/06, Luis Villa wrote: > On 12/19/06, Matt Domsch wrote: > > On Tue, Dec 19, 2006 at 12:46:49AM -0500, Christopher Blizzard wrote: > > > I just noticed that we passed through the 5k packages mark in extras. > > > Kinda neat - seems to be continuing to slowly grow. :D > > > > well, 2500 (exactly) SRPMS, but yes, quite an accomplishment. > > I know this is sort of a bogus stat, but has anyone considered > graphing this growth against the growth of debian and opensuse? One of > the big criticisms of fedora/RH was always that, compared to debian > and suse, there were many fewer centrally packaged programs which > could be relied upon to cleanly install and run, so it seems like > showing that Fedora is growing in this respect would be a nice > marketing point. > Personally I think it would be a very bogus stat as one thing I have heard over and over again is that Fedora Extras is not to be a dumping ground. Quality is always important over quantity, and the people who make the biggest case for this have been burned in the past by other Cookers/Extras/etc. However, these are subjective like what is a good wine and hard to graph without making it a "My Flag is bigger than yours.." vs "Oh well my Flag has better values than yours" type debate. The items I have heard over and over for Extras is that People who package up something should not just be someone who knows how to do some tar commands, but should be taking responsibility for the care and maintenance of the package. They should know the code well enough to be able to patch it or at least get a working patch from the maintainer on a problem. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From tchung at fedoraproject.org Tue Dec 19 19:13:05 2006 From: tchung at fedoraproject.org (Thomas Chung) Date: Tue, 19 Dec 2006 11:13:05 -0800 Subject: Fwd: Fedora backing the LPI events in South Africa In-Reply-To: <1166554992.3212.12.camel@localhost.localdomain> References: <1166554992.3212.12.camel@localhost.localdomain> Message-ID: <369bce3b0612191113s7a2c2541n9b44170fd124dc2e@mail.gmail.com> ---------- Forwarded message ---------- From: Daniam Henriques Date: Dec 19, 2006 11:03 AM Subject: Fedora backing the LPI events in South Africa To: tchung at fedoraproject.org Hi Thomas, Recently I read an article on one of South Africa's leading OSS websites (www.tectonic.co.za) related to the The Shuttleworth Foundation and how from February 2007 they will stop being the South African affiliate of the Linux Professional Institute (LPI). As mentioned in the Article The Meraka Open Source Centre (http://www.meraka.org.za) have been in contact with the LPI. I was wondering what you thought of Fedora perhaps getting involved in such an initiative along with the Meraka Open Source Centre? It would take financial backing on Fedora's part though, as The Shuttleworth Foundation's role was to pay a percentage of all the applicants exam costs, thus making it more accessible to all. I have attached the article below from you to read. The LPI events have always been very successful I was part of the very first "Mass LPI" certification event in Johannesburg and we had over 300 people all writing the LPI certification exams on the same day. http://www.tectonic.co.za/view.php?id=1287 Let me know what you think, I would be more than happy to work along with the Meraka Open Source Centre and provide you with more information related to how Fedora might become involved. -- Regards, Daniam Henriques Lead Ambassador Fedora Project South Africa www.fedoraproject.org ---------- Forwarded message ---------- Are we interested in an initiative with LPI in South Africa? If we do, please contact him. Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung -------------- next part -------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFiDdw1/0NY1f8OvcRAv1iAJ9KC1kKzMw0eXRpC/hKpY8x6P4W1wCdGOo3 bwV6+UvPV5W4q8RvN+g/tAc= =rkr5 -----END PGP SIGNATURE----- From chitlesh at fedoraproject.org Tue Dec 19 19:20:02 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 19 Dec 2006 20:20:02 +0100 Subject: Fedora backing the LPI events in South Africa In-Reply-To: <369bce3b0612191113s7a2c2541n9b44170fd124dc2e@mail.gmail.com> References: <1166554992.3212.12.camel@localhost.localdomain> <369bce3b0612191113s7a2c2541n9b44170fd124dc2e@mail.gmail.com> Message-ID: <13dbfe4f0612191120y68233d0br3d46dd933f7916d0@mail.gmail.com> On 12/19/06, Thomas Chung wrote: > > Recently I read an article on one of South Africa's leading OSS websites > (www.tectonic.co.za) related to the The Shuttleworth Foundation and how > from February 2007 they will stop being the South African affiliate of > the Linux Professional Institute (LPI). Surely taking over would be a great marketing strategy for fedora, but however in terms of money, Max ? In other hand RH can sponsor Fedora to ? - since RH already gives certifications and that would also market their certifications. Chitlesh -- http://clunixchit.blogspot.com From blizzard at redhat.com Tue Dec 19 19:45:40 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 19 Dec 2006 14:45:40 -0500 Subject: Fedora Board meeting, Tuesday 12/19 In-Reply-To: <20061219171958.GA26469@nostromo.devel.redhat.com> References: <20061219171958.GA26469@nostromo.devel.redhat.com> Message-ID: <45884164.8070105@redhat.com> Bill Nottingham wrote: > at 5PM Eastern, 2200 UTC. > > chat/logs from #fedora-board as we've been doing for the last while. > > Might be sparsely attended due to holidays. > > Topics: > - rpm post-mortem? > - F7 progress > - other things as suggested or brought up > Still 888-hello-rh #44436? --Chris From sundaram at fedoraproject.org Tue Dec 19 19:49:55 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 20 Dec 2006 01:19:55 +0530 Subject: Fedora backing the LPI events in South Africa In-Reply-To: <13dbfe4f0612191120y68233d0br3d46dd933f7916d0@mail.gmail.com> References: <1166554992.3212.12.camel@localhost.localdomain> <369bce3b0612191113s7a2c2541n9b44170fd124dc2e@mail.gmail.com> <13dbfe4f0612191120y68233d0br3d46dd933f7916d0@mail.gmail.com> Message-ID: <45884263.1040109@fedoraproject.org> Chitlesh GOORAH wrote: > On 12/19/06, Thomas Chung wrote: >> >> Recently I read an article on one of South Africa's leading OSS websites >> (www.tectonic.co.za) related to the The Shuttleworth Foundation and how >> from February 2007 they will stop being the South African affiliate of >> the Linux Professional Institute (LPI). > > Surely taking over would be a great marketing strategy for fedora, but > however in terms of money, Max ? Why do you think that it would be good marketing? Fedora doesnt offer any certification programs. Combine that with the fast pace of Fedora releases and new LPI policy (see http://linuxboxadmin.com/articles/lpi-policy.php for some details), I would be wary of investing in this without evaluating the benefits if any. > In other hand RH can sponsor Fedora to ? - since RH already gives > certifications and that would also market their certifications. While Novell and recently Ubuntu has gone in with a LPI+ additional module strategy of certification which is based on traditional QA style exams, RHCE is a practical lab based one. Having different approaches here between Fedora and RHEL isnt appealing. Rahul From blizzard at redhat.com Tue Dec 19 20:23:58 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 19 Dec 2006 15:23:58 -0500 Subject: 5k packages? In-Reply-To: <80d7e4090612191105o13f6e336ld9fda56f3d25da57@mail.gmail.com> References: <45877CC9.8030608@redhat.com> <20061219144703.GA15354@domsch.com> <2cb10c440612190653h658ee36cx3a1bc1c7fe2c66a9@mail.gmail.com> <80d7e4090612191105o13f6e336ld9fda56f3d25da57@mail.gmail.com> Message-ID: <45884A5E.2090404@redhat.com> Stephen John Smoogen wrote: > Personally I think it would be a very bogus stat as one thing I have > heard over and over again is that Fedora Extras is not to be a dumping > ground. Quality is always important over quantity, and the people who > make the biggest case for this have been burned in the past by other > Cookers/Extras/etc. However, these are subjective like what is a good > wine and hard to graph without making it a "My Flag is bigger than > yours.." vs "Oh well my Flag has better values than yours" type > debate. > I don't think there's a dichotomy here. It does measure at least one thing: a growing community of contributors. Regarding your assertion of quality, to quote someone else "it's true: the long tail is full of crap" but your crap might be someone else's useful tool. In this case, breadth is more important than depth. If we were worried about depth, we would try to be the upstream for everything and that's not our stated or intended goal. > The items I have heard over and over for Extras is that People who > package up something should not just be someone who knows how to do > some tar commands, but should be taking responsibility for the care > and maintenance of the package. They should know the code well enough > to be able to patch it or at least get a working patch from the > maintainer on a problem. > People have different skill sets. That's true and we're not going to find a someone like Dave Jones is to the kernel for any particular package. If something is critical, we staff for it. If someone out there in the community is passionate about something or wants to own it and can measure up to our base packaging and maintenance guidelines, we let them get in the driver's seat. This is about community building and building our breadth, not being perfect every single time. --Chris From blizzard at redhat.com Tue Dec 19 22:22:36 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 19 Dec 2006 17:22:36 -0500 Subject: 5k packages? In-Reply-To: <45877CC9.8030608@redhat.com> References: <45877CC9.8030608@redhat.com> Message-ID: <4588662C.3090309@redhat.com> How many source packages do we have in core? I have no idea right now. --Chris From blizzard at redhat.com Tue Dec 19 22:25:25 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 19 Dec 2006 17:25:25 -0500 Subject: 5k packages? In-Reply-To: <200612190937.06541.dennis@ausil.us> References: <45877CC9.8030608@redhat.com> <20061219144703.GA15354@domsch.com> <2cb10c440612190653h658ee36cx3a1bc1c7fe2c66a9@mail.gmail.com> <200612190937.06541.dennis@ausil.us> Message-ID: <458866D5.4040407@redhat.com> Dennis Gilmore wrote: > One thing that needs consideration in the comparison is that debain splits > things up in to the smallest possible binary package. We do not do that. > the fairest comparison is to look at the Sources. > by my count Fedora (core+extras) has ~3600 SRPMS > by a count in #suse 3015 src.rpm, 54 nosrc.rpm (not sure what a nosrc.rpm is > but i guess proprietary stuff) > > Debian im still looking to find numbers. > > According to this (from cjb): http://glibc-bsd.alioth.debian.org/NOTES 5912 total source packages in unstable 157 total source packages in unreleased (includes kfreebsd specific, already removed from sid) 5495 sid source packages in unstable 112 sid source packages in unreleased ------------------------------------------- 5607 sid source packages of approx. 6800 So we're making a lot of progress, assuming this is correct. --Chris From notting at redhat.com Tue Dec 19 22:40:40 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Dec 2006 17:40:40 -0500 Subject: 5k packages? In-Reply-To: <4588662C.3090309@redhat.com> References: <45877CC9.8030608@redhat.com> <4588662C.3090309@redhat.com> Message-ID: <20061219224040.GA31333@nostromo.devel.redhat.com> Christopher Blizzard (blizzard at redhat.com) said: > How many source packages do we have in core? I have no idea right now. 1164, according to rawhide. Bill From blizzard at redhat.com Tue Dec 19 23:10:56 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 19 Dec 2006 18:10:56 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061219055905.GC19172@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> Message-ID: <45887180.9030101@redhat.com> Bill Nottingham wrote: > 3. Use Pungi for tree building > Accountable: Jesse Keating > > Must be nearly fully functional by Test 2, as it is a prereq of later > features. > Does this include being able to replace pilgrim for what we're using for OLPC today? No is a fine answer, but I'm just trying to plan. > 4. A Fedora Desktop spin of F7 > Accountable: Jesse Keating (rel-eng), Jonathan Blandford, the Fedora > Desktop SIG (what, you say there isn't one?) Are we keeping track of informed, responsible and consulted as well? :D I can probably throw my hat into consulted and possibly responsible, depending on what needs to happen. > 8. Rock Solid Wireless > Accountable: Dan Williams, Dave Jones > > For every wireless card we support, we should have working, tested > support - it comes up on boot, it associates, it works with WEP and > WPA, all out of the box. A requisite for hitting the laptop market. > Drive fixes through NM, wpa_supplicant, kernel. I can't give up Dan for this, I'm sorry. Unless he does it under the radar, which is likely given the way that Dan works... > 9. Wireless Firmware > Accountable: Fedora-legal, me! > > For every wireless card we support and can get firmware to, we should > work to make it included so things work out of the box. > Technical note: I have the ipw3945 working with suspend on this laptop with a bunch of pm shell hacks which I should post somewhere. > 10. Boot and shutdown speedup > Accountable: me!, David Zeuthen, YOUR NAME HERE > > We do enough Stupid Stuff that we can make easy improvements to startup > and shutdown time without large systemic changes. Includes: tagging of > scripts that don't need shut down, profiling of boot, potential changes > to how we organize disk blocks, and more. I am accountable as well - we need this for OLPC really bad and I will contribute where I can. We're also building a bunch of automated timing and performance tests for OLPC that I'm sure we can apply to Fedora as a whole. I will try to collect these tools from the wonderful and cheerful Chris Ball and try and get us using them as well. Does this include David's new service activation code or not? I'm hot for that for OLPC and I want to figure out what it's going to take to get that merged upstream so we can start using it. It gets rid of a huge amount of what we have to do for 11 (init system changes.) > > Does Not Include: init system changes > > 11. Init system work > Accountable: YOUR NAME HERE > > Evaluate: upstart, launchd, initng. Compare, contrast, benchmark. Define > usage cases, see what fits what, and what is useful. Lots of research. > Not much code. For OLPC I'm going to try to get rid of as much of init as I can. I'm serious about a 30 second startup in the next couple of months and will hack where I need to. > 15. RandR 1.2 > Accountable: Adam Jackson > > RandR 1.2 is the new black. Even if you don't know you want it, you > want it. Potential exists for a backport to the code we will be using, > but there are no guarantees. Needed for OLPC so it will land pretty early I suspect. > 21. Real-time kernel > Accountable: Ingo Molnar, Dave Jones > > Because fake-time kernels are so last year Would love to have for OLPC. We're already hitting apps that can't keep up without some real time support. > 22. Tickless kernel support > Accountable: Ingo Molnar, Dave Jones Required for OLPC. We're going to have to take some form of this. Add me to the list. > > Saving power is good, mmkay? > > 23. Fix wakeups across the distribution > Accountable: me, EVERYONE Same here. --Chris From davej at redhat.com Tue Dec 19 23:50:20 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 19 Dec 2006 18:50:20 -0500 Subject: F7 Plan (draft) In-Reply-To: <45887180.9030101@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45887180.9030101@redhat.com> Message-ID: <20061219235020.GD31335@redhat.com> On Tue, Dec 19, 2006 at 06:10:56PM -0500, Christopher Blizzard wrote: > > 21. Real-time kernel > > Accountable: Ingo Molnar, Dave Jones > > > > Because fake-time kernels are so last year > > Would love to have for OLPC. We're already hitting apps that can't keep > up without some real time support. Details ? The -rt stuff isn't a silver bullet. If apps are doing dumb things, they need to be fixed instead of hoping some kernel tweaks will 'fix' them. Dave -- http://www.codemonkey.org.uk From sundaram at fedoraproject.org Tue Dec 19 23:55:04 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 20 Dec 2006 05:25:04 +0530 Subject: F7 Plan (draft) In-Reply-To: <200612191320.17957.jkeating@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45882A2E.5030402@fedoraproject.org> <200612191320.17957.jkeating@redhat.com> Message-ID: <45887BD8.9070607@fedoraproject.org> Jesse Keating wrote: >> Are all these variants single >> CD's each? > > Very difficult to do with the Desktop CDs, given that openoffice.org + > translations is larger than a CD itself. For server, sure it would be nice > to fit on a single CD. I think it is feasible to have both the GNOME and KDE variants fit into single CD's even with openoffice.org. There are even several Fedora based ones at http://fedoraproject.org/wiki/DerivedDistributions/ > > Somebody could do that. Given everything else that's on my plate, I'd rather > not. > >> That would >> be useful for many places whether bandwidth or network access is >> constrained. > > Burn a DVD set of the tree itself, ship it somewhere to "seed" the mirror, go > from there. I suspect it is far more easier to having it part of the formal releases . It is just a dump of all packages. Since we are going to move away from a rolling release model even for the current Fedora Extras, this shouldnt require much more additional work. > Alternative kernels == doom. Its going to be bad enough if we have to do a > standalone xen kernel that moves at a different pace than the other kernels. > kmods blow up. Userland changes become harder to make. Security flaws... We do already have alternative kernels like the one for Xen. Real time is just going to another one on top. Rahul From notting at redhat.com Wed Dec 20 02:52:58 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Dec 2006 21:52:58 -0500 Subject: F7 Plan (draft) In-Reply-To: <45887BD8.9070607@fedoraproject.org> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45882A2E.5030402@fedoraproject.org> <200612191320.17957.jkeating@redhat.com> <45887BD8.9070607@fedoraproject.org> Message-ID: <20061220025258.GB1823@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > I think it is feasible to have both the GNOME and KDE variants fit into > single CD's even with openoffice.org. There are even several Fedora > based ones at http://fedoraproject.org/wiki/DerivedDistributions/ On a live CD, with trimmed packages? Yes. On a CD of packages, *with langpacks*? No. It just does not fit - it's 719MB. > >Burn a DVD set of the tree itself, ship it somewhere to "seed" the mirror, > >go from there. > > I suspect it is far more easier to having it part of the formal releases > . It is just a dump of all packages. Since we are going to move away > from a rolling release model even for the current Fedora Extras, this > shouldnt require much more additional work. The issue is that what sort of defaults do you use - the desktop? The server? Do you really want to a third set of integration? > >Alternative kernels == doom. Its going to be bad enough if we have to do > >a standalone xen kernel that moves at a different pace than the other > >kernels. kmods blow up. Userland changes become harder to make. > >Security flaws... > > We do already have alternative kernels like the one for Xen. Real time > is just going to another one on top. But Xen is a large maintenance headache. RT adds on to this, *while changing core kernel code*. I'm hereby withdrawing this as a feature. :) Bill From notting at redhat.com Wed Dec 20 02:58:56 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Dec 2006 21:58:56 -0500 Subject: F7 Plan (draft) In-Reply-To: <45887180.9030101@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45887180.9030101@redhat.com> Message-ID: <20061220025856.GC1823@nostromo.devel.redhat.com> Christopher Blizzard (blizzard at redhat.com) said: > Does this include being able to replace pilgrim for what we're using for > OLPC today? No is a fine answer, but I'm just trying to plan. Not sure. Jesse? > >4. A Fedora Desktop spin of F7 > >Accountable: Jesse Keating (rel-eng), Jonathan Blandford, the Fedora > > Desktop SIG (what, you say there isn't one?) > > Are we keeping track of informed, responsible and consulted as well? :D > I can probably throw my hat into consulted and possibly responsible, > depending on what needs to happen. Not particularly. Accountable decides Responsible (and in many cases may be the same), informed and consulted are 'use your judgement, don't be silly.' That being said, I am trolling for people who want to be involved in determining what goes in a Desktop or Server spin. Initially, might just consist of a package set and a service profile. > >8. Rock Solid Wireless > >Accountable: Dan Williams, Dave Jones > > > >For every wireless card we support, we should have working, tested > >support - it comes up on boot, it associates, it works with WEP and > >WPA, all out of the box. A requisite for hitting the laptop market. > >Drive fixes through NM, wpa_supplicant, kernel. > > I can't give up Dan for this, I'm sorry. Unless he does it under the > radar, which is likely given the way that Dan works... Boo. OK, need to find someone with deep wpa_supplicant and NM juju. > Does this include David's new service activation code or not? I'm hot > for that for OLPC and I want to figure out what it's going to take to > get that merged upstream so we can start using it. It gets rid of a > huge amount of what we have to do for 11 (init system changes.) Maybe. I see it having an issue in that you're going to end up with each daemon having multiple start paths (service activation for desktop things like 'print this job', and 'share these files', and 'normal' startup for 'run this webserver' and 'run this print server'). Moreover, we run into the problem of breaking anyone trying to run 'upstream' cups or whatever if we don't do this right. > >11. Init system work > >Accountable: YOUR NAME HERE > > > >Evaluate: upstart, launchd, initng. Compare, contrast, benchmark. Define > >usage cases, see what fits what, and what is useful. Lots of research. > >Not much code. > > For OLPC I'm going to try to get rid of as much of init as I can. I'm > serious about a 30 second startup in the next couple of months and will > hack where I need to. Right. For general purpose, I suspect we're going to need to go to something else eventually, but I'd like a non-biased review of what's out there now, and I know I don't have the time to do it. Bill From jkeating at redhat.com Wed Dec 20 15:22:09 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Dec 2006 10:22:09 -0500 Subject: F7 Plan (draft) In-Reply-To: <45887BD8.9070607@fedoraproject.org> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <200612191320.17957.jkeating@redhat.com> <45887BD8.9070607@fedoraproject.org> Message-ID: <200612201022.12726.jkeating@redhat.com> On Tuesday 19 December 2006 18:55, Rahul Sundaram wrote: > > Very difficult to do with the Desktop CDs, given that openoffice.org + > > translations is larger than a CD itself. ?For server, sure it would be > > nice to fit on a single CD. > > I think it is feasible to have both the GNOME and KDE variants fit into > single CD's even with openoffice.org. There are even several Fedora > based ones at http://fedoraproject.org/wiki/DerivedDistributions/ Not with translations. And before you suggest we drop translations, or drop OO.org, that could be done by anybody in the community. However the Fedora releases the Fedora projects puts forth and mirrors across the world would be suitable for use across the world, with the package set we deem is integral to a Desktop OS, which would IMHO include Openoffice, and its translations. > > Somebody could do that. ?Given everything else that's on my plate, I'd > > rather not. > > > >> That would > >> be useful for many places whether bandwidth or network access is > >> constrained. ? > > > > Burn a DVD set of the tree itself, ship it somewhere to "seed" the > > mirror, go from there. > > I suspect it is far more easier to having it part of the formal releases > . It is just a dump of all packages. Since we are going to move away > from a rolling release model even for the current Fedora Extras, this > shouldnt require much more additional work. However its duplicating a massive amount of data into an iso format, and then asking the mirror system to mirror that. Rather intrusive. > > Alternative kernels == doom. ?Its going to be bad enough if we have to do > > a standalone xen kernel that moves at a different pace than the other > > kernels. kmods blow up. ?Userland changes become harder to make. > > ?Security flaws... > > We do already have alternative kernels like the one for Xen. Real time > is just going to another one on top. Xen is not an alternative kernel (yet). Its built from the same kernel src.rpm and always kept to the same version. Alternative kernels brings to mind having different kernel versions built from different kernel src.rpms, with different kernel-devels and debuginfo and.... Also, Xen isn't really a shining example. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Dec 20 15:21:35 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 20 Dec 2006 16:21:35 +0100 Subject: kernels in the packaging universe (was: Re: F7 Plan (draft)) In-Reply-To: <20061220025258.GB1823@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45882A2E.5030402@fedoraproject.org> <200612191320.17957.jkeating@redhat.com> <45887BD8.9070607@fedoraproject.org> <20061220025258.GB1823@nostromo.devel.redhat.com> Message-ID: <458954FF.2080307@leemhuis.info> Bill Nottingham schrieb: > Rahul Sundaram (sundaram at fedoraproject.org) said: >>> Alternative kernels == doom. Its going to be bad enough if we have to do >>> a standalone xen kernel that moves at a different pace than the other >>> kernels. kmods blow up. Userland changes become harder to make. >>> Security flaws... >> We do already have alternative kernels like the one for Xen. Real time >> is just going to another one on top. > But Xen is a large maintenance headache. RT adds on to this, *while > changing core kernel code*. I'm hereby withdrawing this as a feature. :) Well, I was against kernels in Extras in the past, too, and I agree that maintaining them would be a large maintenance headache. But I more and more think we should have a (semi-)official place for alternate kernel-images (say RT, OpenVZ, OLPC, PS3, Vserver, Xen, Vanilla [would be cool for debugging bugs to check if they are fedora-specific], mm, latest-linus,...) in Fedora-land somewhere with a big, fat warning sign: - Use at your own risk - no guarantees for security updates - be aware that these kernels might miss features like Xen, tux, foo or bar that are in the main kernel package - no precompiled kmods are available CU thl From jkeating at redhat.com Wed Dec 20 15:25:55 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Dec 2006 10:25:55 -0500 Subject: F7 Plan (draft) In-Reply-To: <45887180.9030101@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45887180.9030101@redhat.com> Message-ID: <200612201025.56142.jkeating@redhat.com> On Tuesday 19 December 2006 18:10, Christopher Blizzard wrote: > Bill Nottingham wrote: > > 3. Use Pungi for tree building > > Accountable: Jesse Keating > > > > Must be nearly fully functional by Test 2, as it is a prereq of later > > features. > > Does this include being able to replace pilgrim for what we're using for > OLPC today? ?No is a fine answer, but I'm just trying to plan. I'm going to say probably not. I have enough on my plate to get F7 out the door, and I really pictured pungi to be a tool to create the CD/DVD/Install Tree for Fedora releases. Adding more functionality or different outputs will make the code more and more complex, and make it more difficult to flow with anaconda and distribution changes. Perhaps part of pungi could be used by pilgrim, pungi provides a pypungi python object, with a gather class for finding, depsolving, and downloading packages from given repos provided a package manifest. That might be useful to pilgrim. > > 4. A Fedora Desktop spin of F7 > > Accountable: Jesse Keating (rel-eng), Jonathan Blandford, the Fedora > > ? Desktop SIG (what, you say there isn't one?) > > Are we keeping track of informed, responsible and consulted as well? ?:D > ? I can probably throw my hat into consulted and possibly responsible, > depending on what needs to happen. Ah, RACI. I plan on driving the planning for these different spins through the Wiki, making it easier for folks to be consulted and informed. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gdk at redhat.com Wed Dec 20 15:27:24 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 20 Dec 2006 10:27:24 -0500 (EST) Subject: kernels in the packaging universe (was: Re: F7 Plan (draft)) In-Reply-To: <458954FF.2080307@leemhuis.info> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45882A2E.5030402@fedoraproject.org> <200612191320.17957.jkeating@redhat.com> <45887BD8.9070607@fedoraproject.org> <20061220025258.GB1823@nostromo.devel.redhat.com> <458954FF.2080307@leemhuis.info> Message-ID: On Wed, 20 Dec 2006, Thorsten Leemhuis wrote: > Well, I was against kernels in Extras in the past, too, and I agree that > maintaining them would be a large maintenance headache. But I more and > more think we should have a (semi-)official place for alternate > kernel-images (say RT, OpenVZ, OLPC, PS3, Vserver, Xen, Vanilla [would > be cool for debugging bugs to check if they are fedora-specific], mm, > latest-linus,...) in Fedora-land somewhere with a big, fat warning sign: > - Use at your own risk > - no guarantees for security updates > - be aware that these kernels might miss features like Xen, tux, foo or > bar that are in the main kernel package > - no precompiled kmods are available A tentative +1. The problem: no caveat is ever clear enough for some people. But I don't think that's a reason to ignore alternative kernels entirely. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From davej at redhat.com Wed Dec 20 15:42:00 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 10:42:00 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061220025258.GB1823@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45882A2E.5030402@fedoraproject.org> <200612191320.17957.jkeating@redhat.com> <45887BD8.9070607@fedoraproject.org> <20061220025258.GB1823@nostromo.devel.redhat.com> Message-ID: <20061220154200.GH31335@redhat.com> On Tue, Dec 19, 2006 at 09:52:58PM -0500, Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: > > I think it is feasible to have both the GNOME and KDE variants fit into > > single CD's even with openoffice.org. There are even several Fedora > > based ones at http://fedoraproject.org/wiki/DerivedDistributions/ > > On a live CD, with trimmed packages? Yes. > > On a CD of packages, *with langpacks*? No. It just does not fit - it's > 719MB. One langpack & language per live-cd ? Dave -- http://www.codemonkey.org.uk From jkeating at redhat.com Wed Dec 20 15:55:57 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Dec 2006 10:55:57 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061220154200.GH31335@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <20061220025258.GB1823@nostromo.devel.redhat.com> <20061220154200.GH31335@redhat.com> Message-ID: <200612201055.57456.jkeating@redhat.com> On Wednesday 20 December 2006 10:42, Dave Jones wrote: > One langpack & language per live-cd ? That's something an ambassador or whathaveyou in the area to do, but not something we're going to want to ask our mirrors to host. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Wed Dec 20 15:53:50 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 10:53:50 -0500 Subject: kernels in the packaging universe (was: Re: F7 Plan (draft)) In-Reply-To: <458954FF.2080307@leemhuis.info> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45882A2E.5030402@fedoraproject.org> <200612191320.17957.jkeating@redhat.com> <45887BD8.9070607@fedoraproject.org> <20061220025258.GB1823@nostromo.devel.redhat.com> <458954FF.2080307@leemhuis.info> Message-ID: <20061220155350.GI31335@redhat.com> On Wed, Dec 20, 2006 at 04:21:35PM +0100, Thorsten Leemhuis wrote: > Well, I was against kernels in Extras in the past, too, and I agree that > maintaining them would be a large maintenance headache. But I more and > more think we should have a (semi-)official place for alternate > kernel-images (say RT, OpenVZ, OLPC, PS3, Vserver, Xen, Vanilla [would > be cool for debugging bugs to check if they are fedora-specific], mm, > latest-linus,...) in Fedora-land somewhere with a big, fat warning sign: > - Use at your own risk > - no guarantees for security updates This alone should be enough to be a nail in this coffin. We have a really good track record for security updates in Fedora, despite it being advertised that its going to be a best-effort attempt, no guarantees, yadayada.. This would be a huge step backwards. > - be aware that these kernels might miss features like Xen, tux, foo or > bar that are in the main kernel package > - no precompiled kmods are available You can add all the warning signs you want, but there's a fatal flaw. PEOPLE DON'T FSCKING READ THEM. kernel.org bugzilla has this when you try to file a new bug.. "NO BINARY MODULES or other tainted kernels. Do not file bugs here if you have any binary kernel modules loaded, reproduce without that module first. NVIDIA users - THIS MEANS YOU!" Guess how many bug reports get filed there tainted with nvidia.ko ? And this was just the most recent example that popped into my head. For a Fedora specific example: We get no end of requests to add driver xyz to the kernel, regardless of how many times we state our "upstream first" policy. To go through the examples you gave: RT : This needs to be upstream. And bits of it are going that way all the time. OpenVZ: Needs to go upstream. These folks have been somewhat quiet of late. OLPC: This is already available somewhere on laptop.org, and being in extras isn't really of any value to people not running an olpc. PS3: The PPC64 kernel will support this out of the box. VServer: upstream. Xen: Needs a bullet in the head. Vanilla: Probably the only alternative kernel that actually makes sense. mm: Seriously bad idea. Seriously. Bad. Idea. The last one ate peoples data. We cannot allow things like this into extras, even as an experiment, even with a gazillion warnings that people will ignore. Merging something into a vendor kernel is a *commitment* to the end user that you will continue to provide this feature, and that you will be responsive in fixing any problems that may arise. Just keeping things working is a *lot* of work. I'm currently overwhelmed trying to get Tux, signed modules and Xen working again in rawhide. To the point I've given up and have asked for others help in getting them back on track. Hows this going to work out for extras packages when the packager can't get it together? Based upon the majority of bugs I've encountered in extras packages, I have next to zero faith that anything will be done about bugs that get filed against extras-kernels, eventually ending up with "Oh I know, I'll bug the Fedora kernel maintainers". Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Dec 20 15:54:59 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 10:54:59 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061220025856.GC1823@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45887180.9030101@redhat.com> <20061220025856.GC1823@nostromo.devel.redhat.com> Message-ID: <20061220155459.GJ31335@redhat.com> On Tue, Dec 19, 2006 at 09:58:56PM -0500, Bill Nottingham wrote: > > >For every wireless card we support, we should have working, tested > > >support - it comes up on boot, it associates, it works with WEP and > > >WPA, all out of the box. A requisite for hitting the laptop market. > > >Drive fixes through NM, wpa_supplicant, kernel. > > > > I can't give up Dan for this, I'm sorry. Unless he does it under the > > radar, which is likely given the way that Dan works... > > Boo. OK, need to find someone with deep wpa_supplicant and NM juju. Maybe we can rescue caillon from firefox-errata hell. Doubtful, but maybe. Dave -- http://www.codemonkey.org.uk From dwmw2 at infradead.org Wed Dec 20 16:00:54 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 20 Dec 2006 16:00:54 +0000 Subject: kernels in the packaging universe (was: Re: F7 Plan (draft)) In-Reply-To: <20061220155350.GI31335@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45882A2E.5030402@fedoraproject.org> <200612191320.17957.jkeating@redhat.com> <45887BD8.9070607@fedoraproject.org> <20061220025258.GB1823@nostromo.devel.redhat.com> <458954FF.2080307@leemhuis.info> <20061220155350.GI31335@redhat.com> Message-ID: <1166630454.25827.229.camel@pmac.infradead.org> On Wed, 2006-12-20 at 10:53 -0500, Dave Jones wrote: > PS3: The PPC64 kernel will support this out of the box. Real soon now. They aren't available here until March, but one has been sent from Japan and should arrive this week. There's basic support for it in 2.6.20 and I've started merging the one or two bits which missed the 2.6.20 cutoff, like support for big-endian OHCI. Once it's fully working in rawhide I'll look at the possibility of doing an FC6-based release for it. -- dwmw2 From tburke at redhat.com Wed Dec 20 16:12:21 2006 From: tburke at redhat.com (Tim Burke) Date: Wed, 20 Dec 2006 11:12:21 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061219055905.GC19172@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> Message-ID: <458960E5.7030903@redhat.com> Bill Nottingham wrote: > 4. A Fedora Desktop spin of F7 > Accountable: Jesse Keating (rel-eng), Jonathan Blandford, the Fedora > Desktop SIG (what, you say there isn't one?) > > One of our release targets. Needs defined by Test 2. Test 1 can > be an old-style tree. > > 5. A Fedora Server spin of F7 > Accountable: Jesse Keating (rel-eng), YOUR NAME HERE! > > Another one of our release targets. Needs defined by Test 2. > > Do you picture a different kernel variant for client vs server? From gdk at redhat.com Wed Dec 20 16:15:03 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 20 Dec 2006 11:15:03 -0500 (EST) Subject: F7 Plan (draft) In-Reply-To: <458960E5.7030903@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <458960E5.7030903@redhat.com> Message-ID: On Wed, 20 Dec 2006, Tim Burke wrote: > Bill Nottingham wrote: >> 4. A Fedora Desktop spin of F7 >> Accountable: Jesse Keating (rel-eng), Jonathan Blandford, the Fedora >> Desktop SIG (what, you say there isn't one?) >> >> One of our release targets. Needs defined by Test 2. Test 1 can >> be an old-style tree. >> >> 5. A Fedora Server spin of F7 >> Accountable: Jesse Keating (rel-eng), YOUR NAME HERE! >> >> Another one of our release targets. Needs defined by Test 2. >> >> > Do you picture a different kernel variant for client vs server? I certainly didn't -- but maybe we should consider it. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From tburke at redhat.com Wed Dec 20 16:22:52 2006 From: tburke at redhat.com (Tim Burke) Date: Wed, 20 Dec 2006 11:22:52 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061219055905.GC19172@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> Message-ID: <4589635C.4080702@redhat.com> Bill Nottingham wrote: > 21. Real-time kernel > Accountable: Ingo Molnar, Dave Jones > > Because fake-time kernels are so last year > > I don't think we are prepared to *responsibly* deliver the realtime kernel in FC7. Consider that there have been infinite threads on the trauma Xen has introduced. Such as a zillion patches, often out of sync, etc. Well, currently the realtime kernel is also a zillion patches - many of which conflict with Xen. afaik, we were not intending to have someone on the realtime space who is constantly keeping up to date with the Fedora rebasing etc (like Juan does for Xen). Sure, Ingo frequently rebases to upstream, but not against the Fedora variants. I just don't want realtime to slow down Fedora. Now, when enough of realtime is in upstream that its a manageable patch set, thats a different story... but that may be FC8. Things like Xen which are a major integration challenge make much more sense in Fedora. There are installer, system startup, networking, yada, yada to sort out. In contrast, realtime is primarily "just a kernel". So the same integration challenges do not exist (knock on wood). There is already an existing upstream community around the -rt patchset. Based on this, we may not want to fragment the audience. Mind you, I'm not trying to holdback RT from Fedora. I just don't think its mainstreamed enough to fit responsibly. I welcome opinions though. From jkeating at redhat.com Wed Dec 20 16:29:19 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Dec 2006 11:29:19 -0500 Subject: F7 Plan (draft) In-Reply-To: <458960E5.7030903@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <458960E5.7030903@redhat.com> Message-ID: <200612201129.22725.jkeating@redhat.com> On Wednesday 20 December 2006 11:12, Tim Burke wrote: > Do you picture a different kernel variant for client vs server? Oh please god no. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tburke at redhat.com Wed Dec 20 16:32:03 2006 From: tburke at redhat.com (Tim Burke) Date: Wed, 20 Dec 2006 11:32:03 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061219055905.GC19172@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> Message-ID: <45896583.30405@redhat.com> Bill Nottingham wrote: > Got more? Let me know! > > What about laptop suspend/resume. I thought that was a never-ending saga. Ditto for ipv6. I thought there was an initial flare-up of activity late in FC6 which didn't come to fruition because it was too late. From gdk at redhat.com Wed Dec 20 16:28:16 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 20 Dec 2006 11:28:16 -0500 (EST) Subject: F7 Plan (draft) In-Reply-To: <4589635C.4080702@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <4589635C.4080702@redhat.com> Message-ID: On Wed, 20 Dec 2006, Tim Burke wrote: > Things like Xen which are a major integration challenge make much more sense > in Fedora. There are installer, system startup, networking, yada, yada to > sort out. In contrast, realtime is primarily "just a kernel". So the same > integration challenges do not exist (knock on wood). There is already an > existing upstream community around the -rt patchset. Based on this, we may > not want to fragment the audience. > > Mind you, I'm not trying to holdback RT from Fedora. I just don't think its > mainstreamed enough to fit responsibly. I welcome opinions though. There is increasing interest in the Fedora community re: offering multiple pre-built kernels -- with lots and lots of caveats. Perhaps the RT kernel is one of these. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From jkeating at redhat.com Wed Dec 20 16:30:43 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Dec 2006 11:30:43 -0500 Subject: F7 Plan (draft) In-Reply-To: <4589635C.4080702@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <4589635C.4080702@redhat.com> Message-ID: <200612201130.43492.jkeating@redhat.com> On Wednesday 20 December 2006 11:22, Tim Burke wrote: > I don't think we are prepared to *responsibly* deliver the realtime > kernel in FC7. ?Consider that there have been infinite threads on the > trauma Xen has introduced. ?Such as a zillion patches, often out of > sync, etc. ?Well, currently the realtime kernel is also a zillion > patches - many of which conflict with Xen. > > afaik, we were not intending to have someone on the realtime space who > is constantly keeping up to date with the Fedora rebasing etc (like Juan > does for Xen). Sure, Ingo frequently rebases to upstream, but not > against the Fedora variants. ?I just don't want realtime to slow down > Fedora. ?Now, when enough of realtime is in upstream that its a > manageable patch set, thats a different story... but that may be FC8. > > Things like Xen which are a major integration challenge make much more > sense in Fedora. ?There are installer, system startup, networking, yada, > yada to sort out. ?In contrast, realtime is primarily "just a kernel". ? > So the same integration challenges do not exist (knock on wood). ?There > is already an existing upstream community around the -rt patchset. ? > Based on this, we may not want to fragment the audience. > > Mind you, I'm not trying to holdback RT from Fedora. ?I just don't think > its mainstreamed enough to fit responsibly. ?I welcome opinions though. I honestly think that we can no longer deliver _anything_ significant in the Fedora kernels that isn't upstream. So "delivering RT in Fedora 7" would be equivalent to doing the work necessary to get the bits into the upstream kernel, which Fedora would pick up. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Dec 20 16:32:21 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 20 Dec 2006 17:32:21 +0100 Subject: kernels in the packaging universe In-Reply-To: <20061220155350.GI31335@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45882A2E.5030402@fedoraproject.org> <200612191320.17957.jkeating@redhat.com> <45887BD8.9070607@fedoraproject.org> <20061220025258.GB1823@nostromo.devel.redhat.com> <458954FF.2080307@leemhuis.info> <20061220155350.GI31335@redhat.com> Message-ID: <45896595.3020504@leemhuis.info> Dave Jones schrieb: > On Wed, Dec 20, 2006 at 04:21:35PM +0100, Thorsten Leemhuis wrote: > > [...] with a big, fat warning sign: > > - Use at your own risk > > - no guarantees for security updates > This alone should be enough to be a nail in this coffin. That's why I said "(semi-)official". I didn't mean to put those into what's currently know as Core or Extras. > > - be aware that these kernels might miss features like Xen, tux, foo or > > bar that are in the main kernel package > > - no precompiled kmods are available > You can add all the warning signs you want, but there's a fatal flaw. > PEOPLE DON'T FSCKING READ THEM. Sure, I think we all know that. > [...] > To go through the examples you gave: BTW, sure, I also thing we all also know that upstream is the best place and that in an ideal world we would ship only one Fedora kernel per arch that can do everything: Xen, kdump, kexec, PAE, non-PAE, foo, bar, baz > RT : This needs to be upstream. And bits of it are going that way all > the time. Ingo provides yum-able kernels for some weeks now and it seems to have improved testing a lot, which should help getting it fixed and upstream. Why not have a highlyexperimental.download.fedoraproject.org for stuff like that? > [...] > Vanilla: Probably the only alternative kernel that actually makes sense. Well, I'd say "that makes most sense", especially as we could tell out users then "try that kernel; if it's broken, too, report the problem to upstream please". > mm: Seriously bad idea. Seriously. Bad. Idea. The last one ate peoples > data. We cannot allow things like this into extras, even as an experiment, > even with a gazillion warnings that people will ignore. Well, I think it would improve testing and that's what kernel-developers normally want. I for example hit some cases where I would have used that kernel to test if a bug I hit is solved in it. I was to lame to compile a kernel myself so I was no help. > [...] CU thl From gdk at redhat.com Wed Dec 20 16:32:30 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 20 Dec 2006 11:32:30 -0500 (EST) Subject: kernels in the packaging universe In-Reply-To: <45896595.3020504@leemhuis.info> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45882A2E.5030402@fedoraproject.org> <200612191320.17957.jkeating@redhat.com> <45887BD8.9070607@fedoraproject.org> <20061220025258.GB1823@nostromo.devel.redhat.com> <458954FF.2080307@leemhuis.info> <20061220155350.GI31335@redhat.com> <45896595.3020504@leemhuis.info> Message-ID: On Wed, 20 Dec 2006, Thorsten Leemhuis wrote: > Ingo provides yum-able kernels for some weeks now and it seems to have > improved testing a lot, which should help getting it fixed and upstream. > Why not have a highlyexperimental.download.fedoraproject.org > for stuff like that? We could call it fedora-unstable. ;-) Seriously. We could. And maybe should. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From sundaram at fedoraproject.org Wed Dec 20 16:40:25 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 20 Dec 2006 22:10:25 +0530 Subject: kernels in the packaging universe In-Reply-To: References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45882A2E.5030402@fedoraproject.org> <200612191320.17957.jkeating@redhat.com> <45887BD8.9070607@fedoraproject.org> <20061220025258.GB1823@nostromo.devel.redhat.com> <458954FF.2080307@leemhuis.info> <20061220155350.GI31335@redhat.com> <45896595.3020504@leemhuis.info> Message-ID: <45896779.6030401@fedoraproject.org> Greg Dekoenigsberg wrote: > On Wed, 20 Dec 2006, Thorsten Leemhuis wrote: > >> Ingo provides yum-able kernels for some weeks now and it seems to have >> improved testing a lot, which should help getting it fixed and upstream. >> Why not have a highlyexperimental.download.fedoraproject.org >> for stuff like that? > > We could call it fedora-unstable. ;-) > > Seriously. We could. And maybe should. "unstable" in the Debian land is the equivalent of Fedora "rawhide" There is enough confusion as to the differences between Debian testing and Fedora updates-testing. Lets not add more. If it is experimental, let's call it just that. Rahul From davidz at redhat.com Wed Dec 20 16:43:01 2006 From: davidz at redhat.com (David Zeuthen) Date: Wed, 20 Dec 2006 11:43:01 -0500 Subject: F7 Plan (draft) In-Reply-To: <200612201025.56142.jkeating@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45887180.9030101@redhat.com> <200612201025.56142.jkeating@redhat.com> Message-ID: <1166632981.2470.30.camel@zelda.fubar.dk> On Wed, 2006-12-20 at 10:25 -0500, Jesse Keating wrote: > > Does this include being able to replace pilgrim for what we're using for > > OLPC today? No is a fine answer, but I'm just trying to plan. > > I'm going to say probably not. I have enough on my plate to get F7 out the > door, and I really pictured pungi to be a tool to create the CD/DVD/Install > Tree for Fedora releases. Adding more functionality or different outputs > will make the code more and more complex, and make it more difficult to flow > with anaconda and distribution changes. Perhaps part of pungi could be used > by pilgrim, pungi provides a pypungi python object, with a gather class for > finding, depsolving, and downloading packages from given repos provided a > package manifest. That might be useful to pilgrim. We really really want to do daily livecd spins of our Desktop variant not at least because they're extremely useful for testing rawhide. One upcoming livecd feature is the ability to PXE boot the livecd image, (wget the .iso file) and run the system entirely from RAM. That is a feature that the QA guys here at Red Hat is very interested in and it's not very hard to do. And I think all that this entails is just running the livecd build tools pointing at the repositories that is the output of the daily compose. I've got the livecd tools end of this covered, am going to submit it to Extras real soon now. I'd be surprised if it would be hard to plug into the daily compose. David From tburke at redhat.com Wed Dec 20 16:45:50 2006 From: tburke at redhat.com (Tim Burke) Date: Wed, 20 Dec 2006 11:45:50 -0500 Subject: F7 Plan (draft) In-Reply-To: <200612201129.22725.jkeating@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <458960E5.7030903@redhat.com> <200612201129.22725.jkeating@redhat.com> Message-ID: <458968BE.8050304@redhat.com> Jesse Keating wrote: > On Wednesday 20 December 2006 11:12, Tim Burke wrote: > >> Do you picture a different kernel variant for client vs server? >> > > Oh please god no. > > good answer From tburke at redhat.com Wed Dec 20 16:51:16 2006 From: tburke at redhat.com (Tim Burke) Date: Wed, 20 Dec 2006 11:51:16 -0500 Subject: F7 Plan (draft) In-Reply-To: <200612201130.43492.jkeating@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <4589635C.4080702@redhat.com> <200612201130.43492.jkeating@redhat.com> Message-ID: <45896A04.6020102@redhat.com> As far as the realtime kernel is concerned... perhaps it would be sufficient for the fedora wiki to simply refer people here: http://rt.wiki.kernel.org/index.php/Main_Page I'm working w/ Ingo to get his yum repo kernel pointers there. Seriously, that is the main realtime kernel playground so I don't see Fedora value-add in this particular case, at this point in its development. From davej at redhat.com Wed Dec 20 17:02:43 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 12:02:43 -0500 Subject: kernels in the packaging universe In-Reply-To: <45896779.6030401@fedoraproject.org> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45882A2E.5030402@fedoraproject.org> <200612191320.17957.jkeating@redhat.com> <45887BD8.9070607@fedoraproject.org> <20061220025258.GB1823@nostromo.devel.redhat.com> <458954FF.2080307@leemhuis.info> <20061220155350.GI31335@redhat.com> <45896595.3020504@leemhuis.info> <45896779.6030401@fedoraproject.org> Message-ID: <20061220170243.GN31335@redhat.com> On Wed, Dec 20, 2006 at 10:10:25PM +0530, Rahul Sundaram wrote: > Greg Dekoenigsberg wrote: > > On Wed, 20 Dec 2006, Thorsten Leemhuis wrote: > > > >> Ingo provides yum-able kernels for some weeks now and it seems to have > >> improved testing a lot, which should help getting it fixed and upstream. > >> Why not have a highlyexperimental.download.fedoraproject.org > >> for stuff like that? > > > > We could call it fedora-unstable. ;-) > > > > Seriously. We could. And maybe should. > > "unstable" in the Debian land is the equivalent of Fedora "rawhide" > There is enough confusion as to the differences between Debian testing > and Fedora updates-testing. Lets not add more. If it is experimental, > let's call it just that. Confusion is the key word here. Whats the difference between "development" and "experimental" ? Dave -- http://www.codemonkey.org.uk From jkeating at redhat.com Wed Dec 20 17:08:25 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Dec 2006 12:08:25 -0500 Subject: F7 Plan (draft) In-Reply-To: <1166632981.2470.30.camel@zelda.fubar.dk> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <200612201025.56142.jkeating@redhat.com> <1166632981.2470.30.camel@zelda.fubar.dk> Message-ID: <200612201208.25522.jkeating@redhat.com> On Wednesday 20 December 2006 11:43, David Zeuthen wrote: > We really really want to do daily livecd spins of our Desktop variant > not at least because they're extremely useful for testing rawhide. One > upcoming livecd feature is the ability to PXE boot the livecd image, > (wget the .iso file) and run the system entirely from RAM. That is a > feature that the QA guys here at Red Hat is very interested in and it's > not very hard to do. > > And I think all that this entails is just running the livecd build tools > pointing at the repositories that is the output of the daily compose. > I've got the livecd tools end of this covered, am going to submit it to > Extras real soon now. I'd be surprised if it would be hard to plug into > the daily compose. Doing LiveCDs daily or every couple of days is indeed on my roadmap for F7. But making pungi create the images used by OLPC and replace what happens there is not. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Wed Dec 20 17:06:41 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 20 Dec 2006 17:06:41 +0000 Subject: F7 Plan (draft) In-Reply-To: <45896583.30405@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896583.30405@redhat.com> Message-ID: <1166634401.25827.261.camel@pmac.infradead.org> On Wed, 2006-12-20 at 11:32 -0500, Tim Burke wrote: > What about laptop suspend/resume. I thought that was a never-ending > saga. It's been working nicely on my Apple PowerBook for a long time :) > Ditto for ipv6. I thought there was an initial flare-up of activity > late in FC6 which didn't come to fruition because it was too late. I'm not sure how you define 'come to fruition' in this context. IPv6 has been working nicely in almost all the important cases (apache, exim, ftpd, imap, ssh, anything core like that) for years. The only notable exception is Squid.? We had a flurry of activity recently where we filed bugs for all the _trivial_ things like the fact that our talk client and server aren't IPv6-enabled, that the esoteric option for hcidump to spew the packets it receives over the network (and receive them from the network) wasn't IPv6-capable, etc. A whole bunch of those got fixed; some aren't yet fixed. I suppose that you could say it "didn't come to fruition" because the job isn't entirely done -- there is still at least one trivial bug in some esoteric program which only supports IPv4 and not IPv6. (In fact there's more than one). But that turn of phrase seems a little pessimistic. It is a good idea to have someone 'own' the overall IPv6 support in the distribution though -- I nominate Peter. :) -- dwmw2 ? Well, postfix has been known to do random stupid things when presented with a domain with IPv6-only primary MX, but in my experience postfix tends to do random stupid things anyway so I don't count that :) From fedora at leemhuis.info Wed Dec 20 17:07:42 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 20 Dec 2006 18:07:42 +0100 Subject: mailing-list reorganisation, round 2 Message-ID: <45896DDE.3080102@leemhuis.info> Hi All, second round in the process to solve the "we have to many mailinglists" problem (first round starts at https://www.redhat.com/archives/fedora-advisory-board/2006-December/msg00104.html ; diff against first proposal: http://www.fedoraproject.org/wiki/ThorstenLeemhuis/MailingListReorganization?action=diff&rev2=2&rev1=1 ). Comments? If I some "yeah, I tend to like it" I'll post it to the relevant mailing lists asking people to comment before we realize it. == Remove == === fedora-packaging-list === Packaging is important to all package maintainers. Everyone should get involved and see the discussions and at least see the topics being discussed, thus do it directly on fedora-maintainers. Use a special tag like "[packaging]" to mark them if there really is a need to differentiate. === fedora-buildsys-list === It's quite a quiet list -- maybe we should leave it open for now until the plague/brew stuff is worked out, and then simply continue on fedora-devel, fedora-maintainers or fedora-infrastructure === fedora-extras-list === Well, it seems the "Core packages gets merged into the Extras framework" is nearly official. Discuss the stuff that was on fedora-extras-list until now on fedora-devel in the future. === fedora-test-list === A lot of people don't get the difference between fedora-devel and fedora-test list. And testing is a crucial part of the devel process, thus lets drop the test-list. == Rename == === fedora-qa-list == Rename fedora-triage-list to fedora-qa-list and use it for wwoods efforts and his recruits. == New == === fedora-project-list == We until now have no real list where Ambassadors, packagers, programmers, art-people and other contributors can talk to each other about general stuff that's important to the project as a whole without getting lost in the noise or scared away with "this is off topic on this list" calls. fedora-advisory-board somehow is this list, but it's moderated and thus even some project contributors that are not subscribed feel excluded (bad). /!\ Note: I'm not sure is this really is a good idea, but I more and more think we need a list where we can discuss the project as a whole especially with people that are not yet contributors == Not sure == There are some list where I'm not sure if they are still useful: fedora-desktop-list, fedora-games-list, several of the fedora-devel-foo lists = EOF= Just my 2 cent, but we really should discuss how to proceed with the mailing lists in the merged Fedora world sooner or later. CU thl From sundaram at fedoraproject.org Wed Dec 20 17:24:58 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 20 Dec 2006 22:54:58 +0530 Subject: kernels in the packaging universe In-Reply-To: <20061220170243.GN31335@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45882A2E.5030402@fedoraproject.org> <200612191320.17957.jkeating@redhat.com> <45887BD8.9070607@fedoraproject.org> <20061220025258.GB1823@nostromo.devel.redhat.com> <458954FF.2080307@leemhuis.info> <20061220155350.GI31335@redhat.com> <45896595.3020504@leemhuis.info> <45896779.6030401@fedoraproject.org> <20061220170243.GN31335@redhat.com> Message-ID: <458971EA.50506@fedoraproject.org> Dave Jones wrote: > On Wed, Dec 20, 2006 at 10:10:25PM +0530, Rahul Sundaram wrote: > > Greg Dekoenigsberg wrote: > > > On Wed, 20 Dec 2006, Thorsten Leemhuis wrote: > > > > > >> Ingo provides yum-able kernels for some weeks now and it seems to have > > >> improved testing a lot, which should help getting it fixed and upstream. > > >> Why not have a highlyexperimental.download.fedoraproject.org > > >> for stuff like that? > > > > > > We could call it fedora-unstable. ;-) > > > > > > Seriously. We could. And maybe should. > > > > "unstable" in the Debian land is the equivalent of Fedora "rawhide" > > There is enough confusion as to the differences between Debian testing > > and Fedora updates-testing. Lets not add more. If it is experimental, > > let's call it just that. > > Confusion is the key word here. Whats the difference between > "development" and "experimental" ? Development = Precursor to general releases. Experimental = Add on for general releases. No security guarantees. Might not stay in sync. Staging ground for innovative but very risky changes. Rahul From davej at redhat.com Wed Dec 20 17:38:11 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 12:38:11 -0500 Subject: kernels in the packaging universe In-Reply-To: <458971EA.50506@fedoraproject.org> References: <200612191320.17957.jkeating@redhat.com> <45887BD8.9070607@fedoraproject.org> <20061220025258.GB1823@nostromo.devel.redhat.com> <458954FF.2080307@leemhuis.info> <20061220155350.GI31335@redhat.com> <45896595.3020504@leemhuis.info> <45896779.6030401@fedoraproject.org> <20061220170243.GN31335@redhat.com> <458971EA.50506@fedoraproject.org> Message-ID: <20061220173811.GO31335@redhat.com> On Wed, Dec 20, 2006 at 10:54:58PM +0530, Rahul Sundaram wrote: > Dave Jones wrote: > > On Wed, Dec 20, 2006 at 10:10:25PM +0530, Rahul Sundaram wrote: > > > Greg Dekoenigsberg wrote: > > > > On Wed, 20 Dec 2006, Thorsten Leemhuis wrote: > > > > > > > >> Ingo provides yum-able kernels for some weeks now and it seems to have > > > >> improved testing a lot, which should help getting it fixed and upstream. > > > >> Why not have a highlyexperimental.download.fedoraproject.org > > > >> for stuff like that? > > > > > > > > We could call it fedora-unstable. ;-) > > > > > > > > Seriously. We could. And maybe should. > > > > > > "unstable" in the Debian land is the equivalent of Fedora "rawhide" > > > There is enough confusion as to the differences between Debian testing > > > and Fedora updates-testing. Lets not add more. If it is experimental, > > > let's call it just that. > > > > Confusion is the key word here. Whats the difference between > > "development" and "experimental" ? > > Development = Precursor to general releases. > Experimental = Add on for general releases. No security guarantees. > Might not stay in sync. Staging ground for innovative but very risky > changes. But development also contains bleeding edge packages. Asides from "Add on for general releases", your criteria match what rawhide is today. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Dec 20 17:40:01 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 12:40:01 -0500 Subject: F7 Plan (draft) In-Reply-To: References: <20061219055905.GC19172@nostromo.devel.redhat.com> <458960E5.7030903@redhat.com> Message-ID: <20061220174001.GP31335@redhat.com> On Wed, Dec 20, 2006 at 11:15:03AM -0500, Greg Dekoenigsberg wrote: > On Wed, 20 Dec 2006, Tim Burke wrote: > > >> 5. A Fedora Server spin of F7 > >> Accountable: Jesse Keating (rel-eng), YOUR NAME HERE! > >> > >> Another one of our release targets. Needs defined by Test 2. > >> > > Do you picture a different kernel variant for client vs server? > > I certainly didn't -- but maybe we should consider it. It's not really necessary as most of the things that make a difference can be controlled by sysctls. Most obvious one being the default disk IO elevator. Separate /etc/sysctl.conf's makes a lot more sense than a separate kernel image. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Dec 20 17:44:08 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 12:44:08 -0500 Subject: F7 Plan (draft) In-Reply-To: References: <20061219055905.GC19172@nostromo.devel.redhat.com> <4589635C.4080702@redhat.com> Message-ID: <20061220174408.GQ31335@redhat.com> On Wed, Dec 20, 2006 at 11:28:16AM -0500, Greg Dekoenigsberg wrote: > On Wed, 20 Dec 2006, Tim Burke wrote: > > > Things like Xen which are a major integration challenge make much more sense > > in Fedora. There are installer, system startup, networking, yada, yada to > > sort out. In contrast, realtime is primarily "just a kernel". So the same > > integration challenges do not exist (knock on wood). There is already an > > existing upstream community around the -rt patchset. Based on this, we may > > not want to fragment the audience. > > > > Mind you, I'm not trying to holdback RT from Fedora. I just don't think its > > mainstreamed enough to fit responsibly. I welcome opinions though. > > There is increasing interest in the Fedora community re: offering multiple > pre-built kernels -- with lots and lots of caveats. Perhaps the RT kernel > is one of these. Whilst Red Hat's medical coverage fully covers "mental health" issues, I'd really rather not proceed down this avenue. We can't support *one* kernel properly. On what planet does it make sense to throw more variants in the mix ? This whole idea stinks of doom so bad. Dave -- http://www.codemonkey.org.uk From jkeating at redhat.com Wed Dec 20 17:47:34 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Dec 2006 12:47:34 -0500 Subject: kernels in the packaging universe In-Reply-To: <45896779.6030401@fedoraproject.org> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896779.6030401@fedoraproject.org> Message-ID: <200612201247.38338.jkeating@redhat.com> On Wednesday 20 December 2006 11:40, Rahul Sundaram wrote: > If it is experimental, > let's call it just that. Some of these things are not 'experimental' as in "If it works, it may be included". Some of these things will never be included, so to call them experimental is not right. How about dontuse. Pretty clear right? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Wed Dec 20 17:45:48 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 12:45:48 -0500 Subject: F7 Plan (draft) In-Reply-To: <200612201130.43492.jkeating@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <4589635C.4080702@redhat.com> <200612201130.43492.jkeating@redhat.com> Message-ID: <20061220174548.GR31335@redhat.com> On Wed, Dec 20, 2006 at 11:30:43AM -0500, Jesse Keating wrote: > On Wednesday 20 December 2006 11:22, Tim Burke wrote: > > I don't think we are prepared to *responsibly* deliver the realtime > > kernel in FC7. ?Consider that there have been infinite threads on the > > trauma Xen has introduced. ?Such as a zillion patches, often out of > > sync, etc. ?Well, currently the realtime kernel is also a zillion > > patches - many of which conflict with Xen. > > > > afaik, we were not intending to have someone on the realtime space who > > is constantly keeping up to date with the Fedora rebasing etc (like Juan > > does for Xen). Sure, Ingo frequently rebases to upstream, but not > > against the Fedora variants. ?I just don't want realtime to slow down > > Fedora. ?Now, when enough of realtime is in upstream that its a > > manageable patch set, thats a different story... but that may be FC8. > > > > Things like Xen which are a major integration challenge make much more > > sense in Fedora. ?There are installer, system startup, networking, yada, > > yada to sort out. ?In contrast, realtime is primarily "just a kernel". ? > > So the same integration challenges do not exist (knock on wood). ?There > > is already an existing upstream community around the -rt patchset. ? > > Based on this, we may not want to fragment the audience. > > > > Mind you, I'm not trying to holdback RT from Fedora. ?I just don't think > > its mainstreamed enough to fit responsibly. ?I welcome opinions though. > > I honestly think that we can no longer deliver _anything_ significant in the > Fedora kernels that isn't upstream. Right. Remember that original Fedora goal "Be close to upstream" ? We need to get back on track to that ASAP, not deviate further away. And shovelling things into separate RPMs is not the right answer to the current problem Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Dec 20 17:49:32 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 12:49:32 -0500 Subject: F7 Plan (draft) In-Reply-To: <45896583.30405@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896583.30405@redhat.com> Message-ID: <20061220174932.GS31335@redhat.com> On Wed, Dec 20, 2006 at 11:32:03AM -0500, Tim Burke wrote: > Bill Nottingham wrote: > > Got more? Let me know! > > > > > What about laptop suspend/resume. I thought that was a never-ending saga. Most of it is on the userspace side. We still need video driver help on some chipsets, and different pm-utils rules for different combinations etc. Slowly but surely this stuff is moving towards HAL. DavidZ and Richard Hughes have been doing a bunch of work on this. Oh and then there's the 'system wide power management' thing rather than having it per-user session as it is right now. I'm not at one with the details on that, but I heard mumblings of PolicyKit the last time it was brought up, and don't know how far along that is. >From the kernel side: there's talk of moving some of the video mode setting from the X drivers to the kernel. This has been discussed for about three years now. No-one seems to actually be doing the work. There's also still a few hundred drivers that lack suspend/resume callbacks. Summary: lots to do. various bits in various states of repair.. Dave -- http://www.codemonkey.org.uk From tcallawa at redhat.com Wed Dec 20 17:51:35 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 20 Dec 2006 11:51:35 -0600 Subject: kernels in the packaging universe In-Reply-To: <200612201247.38338.jkeating@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> Message-ID: <1166637095.5069.75.camel@localhost.localdomain> On Wed, 2006-12-20 at 12:47 -0500, Jesse Keating wrote: > On Wednesday 20 December 2006 11:40, Rahul Sundaram wrote: > > If it is experimental, > > let's call it just that. > > Some of these things are not 'experimental' as in "If it works, it may be > included". Some of these things will never be included, so to call them > experimental is not right. > > How about dontuse. Pretty clear right? Personally, I'm voting for "don't bother". This is a bad idea. We're encouraging fragmentation, and discouraging the proper upstream path. If specific open source groups want to do pre-upstream testing of kernel packages, let them make their own unofficial repos. We'll link to them in our wiki. ~spot From dwmw2 at infradead.org Wed Dec 20 17:55:19 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 20 Dec 2006 17:55:19 +0000 Subject: kernels in the packaging universe In-Reply-To: <1166637095.5069.75.camel@localhost.localdomain> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> Message-ID: <1166637319.25827.272.camel@pmac.infradead.org> On Wed, 2006-12-20 at 11:51 -0600, Tom 'spot' Callaway wrote: > Personally, I'm voting for "don't bother". > > This is a bad idea. We're encouraging fragmentation, and discouraging > the proper upstream path. Absolutely. > If specific open source groups want to do > pre-upstream testing of kernel packages, let them make their own > unofficial repos. We'll link to them in our wiki. If we must. I think it's better to stick to "if it isn't upstream, it doesn't exist" though. We should make it clear we don't want _any_ kmod packages in the new combined Core+Extras too. -- dwmw2 From smooge at gmail.com Wed Dec 20 17:58:12 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 20 Dec 2006 10:58:12 -0700 Subject: F7 Plan (draft) In-Reply-To: <20061219235020.GD31335@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45887180.9030101@redhat.com> <20061219235020.GD31335@redhat.com> Message-ID: <80d7e4090612200958t5a8d17eer1059edd0be99e978@mail.gmail.com> On 12/19/06, Dave Jones wrote: > On Tue, Dec 19, 2006 at 06:10:56PM -0500, Christopher Blizzard wrote: > > > 21. Real-time kernel > > > Accountable: Ingo Molnar, Dave Jones > > > > > > Because fake-time kernels are so last year > > > > Would love to have for OLPC. We're already hitting apps that can't keep > > up without some real time support. > > Details ? The -rt stuff isn't a silver bullet. If apps are doing > dumb things, they need to be fixed instead of hoping some kernel > tweaks will 'fix' them. > A patch to the kernel profiling that says "Application [fill in data here] is doing dumb thing. Don't expect the kernel to fix." -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From davej at redhat.com Wed Dec 20 17:58:43 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 12:58:43 -0500 Subject: kernels in the packaging universe In-Reply-To: <1166637095.5069.75.camel@localhost.localdomain> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> Message-ID: <20061220175843.GT31335@redhat.com> On Wed, Dec 20, 2006 at 11:51:35AM -0600, Tom 'spot' Callaway wrote: > On Wed, 2006-12-20 at 12:47 -0500, Jesse Keating wrote: > > On Wednesday 20 December 2006 11:40, Rahul Sundaram wrote: > > > If it is experimental, > > > let's call it just that. > > > > Some of these things are not 'experimental' as in "If it works, it may be > > included". Some of these things will never be included, so to call them > > experimental is not right. > > > > How about dontuse. Pretty clear right? > > Personally, I'm voting for "don't bother". > > This is a bad idea. We're encouraging fragmentation, and discouraging > the proper upstream path. If specific open source groups want to do > pre-upstream testing of kernel packages, let them make their own > unofficial repos. We'll link to them in our wiki. Hallelujah. Preach on brother spot. Until your post, I felt like I was in one of those movies where I wake up and I'm the only person left alive. Except in this movie, I was the only one who hadn't lost his mind. Dave -- http://www.codemonkey.org.uk From rdieter at math.unl.edu Wed Dec 20 17:59:20 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Dec 2006 11:59:20 -0600 Subject: kernels in the packaging universe In-Reply-To: <1166637319.25827.272.camel@pmac.infradead.org> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> <1166637319.25827.272.camel@pmac.infradead.org> Message-ID: <458979F8.1020008@math.unl.edu> David Woodhouse wrote: > On Wed, 2006-12-20 at 11:51 -0600, Tom 'spot' Callaway wrote: >> Personally, I'm voting for "don't bother". >> >> This is a bad idea. We're encouraging fragmentation, and discouraging >> the proper upstream path. > > Absolutely. > >> If specific open source groups want to do >> pre-upstream testing of kernel packages, let them make their own >> unofficial repos. We'll link to them in our wiki. > > If we must. I think it's better to stick to "if it isn't upstream, it > doesn't exist" though. > > We should make it clear we don't want _any_ kmod packages in the new > combined Core+Extras too. If by "We", you really mean "you", then you'd be correct. FESCo, currently anyway, still allows kmods in limited cases. -- Rex From smooge at gmail.com Wed Dec 20 18:11:41 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 20 Dec 2006 11:11:41 -0700 Subject: kernels in the packaging universe In-Reply-To: <200612201247.38338.jkeating@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> Message-ID: <80d7e4090612201011o53c2836fq890aa9edd790a298@mail.gmail.com> On 12/20/06, Jesse Keating wrote: > On Wednesday 20 December 2006 11:40, Rahul Sundaram wrote: > > If it is experimental, > > let's call it just that. > > Some of these things are not 'experimental' as in "If it works, it may be > included". Some of these things will never be included, so to call them > experimental is not right. > > How about dontuse. Pretty clear right? > How about Fedora-Crap. The Fedora Crap repository comes with an absolute guarentee that you will be freely laughed at on mailling lists and IRC channels when asking for package issues. Bugzilla entries will automatically forwarded to a mailling list where contests on the best way of mocking your problems. Problems on issues will only get a serious look at (for a guarenteed 45 minutes) after a 250.00 paypal payment has been cleared. ** Note Looked At means that someone looked at the ticket, and if they found it interesting tried an answer/fix without the prerequisite mocking, sarcasm, and general tones of condescension. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jkeating at redhat.com Wed Dec 20 18:21:48 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Dec 2006 13:21:48 -0500 Subject: kernels in the packaging universe In-Reply-To: <1166637319.25827.272.camel@pmac.infradead.org> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <1166637095.5069.75.camel@localhost.localdomain> <1166637319.25827.272.camel@pmac.infradead.org> Message-ID: <200612201321.48675.jkeating@redhat.com> On Wednesday 20 December 2006 12:55, David Woodhouse wrote: > We should make it clear we don't want _any_ kmod packages in the new > combined Core+Extras too. +1. I was successful of ridding core of these stupid things. I REALLY don't want to see them come back in the merged land. I certainly don't want to include them in any of the spins I do. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Dec 20 18:22:11 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Dec 2006 13:22:11 -0500 Subject: kernels in the packaging universe In-Reply-To: <1166637095.5069.75.camel@localhost.localdomain> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> Message-ID: <200612201322.11518.jkeating@redhat.com> On Wednesday 20 December 2006 12:51, Tom 'spot' Callaway wrote: > Personally, I'm voting for "don't bother". > > This is a bad idea. We're encouraging fragmentation, and discouraging > the proper upstream path. If specific open source groups want to do > pre-upstream testing of kernel packages, let them make their own > unofficial repos. We'll link to them in our wiki. Sure, that's my preference too. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tburke at redhat.com Wed Dec 20 18:42:37 2006 From: tburke at redhat.com (Tim Burke) Date: Wed, 20 Dec 2006 13:42:37 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061220174001.GP31335@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <458960E5.7030903@redhat.com> <20061220174001.GP31335@redhat.com> Message-ID: <4589841D.1050309@redhat.com> Dave Jones wrote: > On Wed, Dec 20, 2006 at 11:15:03AM -0500, Greg Dekoenigsberg wrote: > > On Wed, 20 Dec 2006, Tim Burke wrote: > > > > >> 5. A Fedora Server spin of F7 > > >> Accountable: Jesse Keating (rel-eng), YOUR NAME HERE! > > >> > > >> Another one of our release targets. Needs defined by Test 2. > > >> > > > Do you picture a different kernel variant for client vs server? > > > > I certainly didn't -- but maybe we should consider it. > > It's not really necessary as most of the things that make a difference > can be controlled by sysctls. Most obvious one being the default > disk IO elevator. > > Separate /etc/sysctl.conf's makes a lot more sense than a separate > kernel image. > > Agreed that sysctls are far better than different kernel builds. Having said that.. what is the mechanism to actually set different knobs on a client distro vs a server distro? For example would that just consist of a bunch of lines spread around random init scripts, or should there be something like a "profile" file with sysctl settings, ie, one for desktop, other for server. Heck, if you can do that, why not have an NFS server, database server, web server separate profiles too. From tburke at redhat.com Wed Dec 20 18:43:27 2006 From: tburke at redhat.com (Tim Burke) Date: Wed, 20 Dec 2006 13:43:27 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061220174408.GQ31335@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <4589635C.4080702@redhat.com> <20061220174408.GQ31335@redhat.com> Message-ID: <4589844F.8060306@redhat.com> Dave Jones wrote: > > Whilst Red Hat's medical coverage fully covers "mental health" issues, > I'd really rather not proceed down this avenue. > > We can't support *one* kernel properly. On what planet does it make sense > to throw more variants in the mix ? > > This whole idea stinks of doom so bad. > > +1 From dwmw2 at infradead.org Wed Dec 20 18:49:33 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 20 Dec 2006 18:49:33 +0000 Subject: kernels in the packaging universe In-Reply-To: <458979F8.1020008@math.unl.edu> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> <1166637319.25827.272.camel@pmac.infradead.org> <458979F8.1020008@math.unl.edu> Message-ID: <1166640573.25827.276.camel@pmac.infradead.org> On Wed, 2006-12-20 at 11:59 -0600, Rex Dieter wrote: > If by "We", you really mean "you", then you'd be correct. FESCo, > currently anyway, still allows kmods in limited cases. If by 'limited' we mean cases where DaveJ, Jesse and I _all_ agree that it's a good idea, I'm fine with that policy continuing in the combined Fedora :) -- dwmw2 From davej at redhat.com Wed Dec 20 19:00:40 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 14:00:40 -0500 Subject: kernels in the packaging universe In-Reply-To: <458979F8.1020008@math.unl.edu> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> <1166637319.25827.272.camel@pmac.infradead.org> <458979F8.1020008@math.unl.edu> Message-ID: <20061220190040.GC3248@redhat.com> On Wed, Dec 20, 2006 at 11:59:20AM -0600, Rex Dieter wrote: > David Woodhouse wrote: > > On Wed, 2006-12-20 at 11:51 -0600, Tom 'spot' Callaway wrote: > > If we must. I think it's better to stick to "if it isn't upstream, it > > doesn't exist" though. > > > > We should make it clear we don't want _any_ kmod packages in the new > > combined Core+Extras too. > > If by "We", you really mean "you", then you'd be correct. FESCo, > currently anyway, still allows kmods in limited cases. Which was a mistake IMO. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Dec 20 19:02:48 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 14:02:48 -0500 Subject: F7 Plan (draft) In-Reply-To: <4589841D.1050309@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <458960E5.7030903@redhat.com> <20061220174001.GP31335@redhat.com> <4589841D.1050309@redhat.com> Message-ID: <20061220190248.GD3248@redhat.com> On Wed, Dec 20, 2006 at 01:42:37PM -0500, Tim Burke wrote: > Agreed that sysctls are far better than different kernel builds. Having > said that.. what is the mechanism to actually set different knobs on a > client distro vs a server distro? For example would that just consist > of a bunch of lines spread around random init scripts, or should there > be something like a "profile" file with sysctl settings, ie, one for > desktop, other for server. Heck, if you can do that, why not have an > NFS server, database server, web server separate profiles too. What happens when your webserver is also your NFS server ? Which do you choose? :) For the most part these things are near identical anyway, so it's mostly a non problem. Dave -- http://www.codemonkey.org.uk From gdk at redhat.com Wed Dec 20 19:06:39 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 20 Dec 2006 14:06:39 -0500 (EST) Subject: kernels in the packaging universe In-Reply-To: <20061220190040.GC3248@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> <1166637319.25827.272.camel@pmac.infradead.org> <458979F8.1020008@math.unl.edu> <20061220190040.GC3248@redhat.com> Message-ID: On Wed, 20 Dec 2006, Dave Jones wrote: > > If by "We", you really mean "you", then you'd be correct. FESCo, > > currently anyway, still allows kmods in limited cases. > > Which was a mistake IMO. Why? To the best of my knowledge, the problem you have with kmods/alternate kernels is that people complain when they break, and they fill bugzilla with bugs that don't make sense -- because people don't understand that they're running funky kernels. Right? Are there any other reasons not to package these alternate kernels? Because that's a valid reason. But it also gives us something to shoot for: better reporting tools. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From jkeating at redhat.com Wed Dec 20 19:17:49 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Dec 2006 14:17:49 -0500 Subject: kernels in the packaging universe In-Reply-To: References: <20061219055905.GC19172@nostromo.devel.redhat.com> <20061220190040.GC3248@redhat.com> Message-ID: <200612201417.49276.jkeating@redhat.com> On Wednesday 20 December 2006 14:06, Greg Dekoenigsberg wrote: > Right? ?Are there any other reasons not to package these alternate > kernels? rpm completely fails as a method to track and deploy these things correctly. We've got HUGE ass workarounds that make packaging a complete nightmare. Add to that kmods will _always_ lag behind the kernel, by the very nature that they have to be built _after_ the kernel lands in a buildroot. Those are some technical reasons. There are many philosophical reasons too. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Wed Dec 20 19:20:08 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Dec 2006 13:20:08 -0600 Subject: kernels in the packaging universe In-Reply-To: <1166640573.25827.276.camel@pmac.infradead.org> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> <1166637319.25827.272.camel@pmac.infradead.org> <458979F8.1020008@math.unl.edu> <1166640573.25827.276.camel@pmac.infradead.org> Message-ID: <45898CE8.1050209@math.unl.edu> David Woodhouse wrote: > On Wed, 2006-12-20 at 11:59 -0600, Rex Dieter wrote: >> If by "We", you really mean "you", then you'd be correct. FESCo, >> currently anyway, still allows kmods in limited cases. > > If by 'limited' we mean cases where DaveJ, Jesse and I _all_ agree that > it's a good idea, I'm fine with that policy continuing in the combined > Fedora :) Tell ya what, I'll consider giving Jesse (et-al) veto power over all kmods the day http://bugzilla.redhat.com/170335 is fixed. deal? -- Rex From davej at redhat.com Wed Dec 20 19:24:59 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 14:24:59 -0500 Subject: kernels in the packaging universe In-Reply-To: <45898CE8.1050209@math.unl.edu> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> <1166637319.25827.272.camel@pmac.infradead.org> <458979F8.1020008@math.unl.edu> <1166640573.25827.276.camel@pmac.infradead.org> <45898CE8.1050209@math.unl.edu> Message-ID: <20061220192459.GF3248@redhat.com> On Wed, Dec 20, 2006 at 01:20:08PM -0600, Rex Dieter wrote: > David Woodhouse wrote: > > On Wed, 2006-12-20 at 11:59 -0600, Rex Dieter wrote: > >> If by "We", you really mean "you", then you'd be correct. FESCo, > >> currently anyway, still allows kmods in limited cases. > > > > If by 'limited' we mean cases where DaveJ, Jesse and I _all_ agree that > > it's a good idea, I'm fine with that policy continuing in the combined > > Fedora :) > > Tell ya what, I'll consider giving Jesse (et-al) veto power over all > kmods the day > http://bugzilla.redhat.com/170335 > is fixed. deal? Given this has absolutely nothing to do with the discussion at hand, I'm assuming you typoed the bug number. Dave -- http://www.codemonkey.org.uk From rdieter at math.unl.edu Wed Dec 20 19:26:51 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Dec 2006 13:26:51 -0600 Subject: kernels in the packaging universe In-Reply-To: <20061220192459.GF3248@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> <1166637319.25827.272.camel@pmac.infradead.org> <458979F8.1020008@math.unl.edu> <1166640573.25827.276.camel@pmac.infradead.org> <45898CE8.1050209@math.unl.edu> <20061220192459.GF3248@redhat.com> Message-ID: <45898E7B.30105@math.unl.edu> Dave Jones wrote: > On Wed, Dec 20, 2006 at 01:20:08PM -0600, Rex Dieter wrote: > > David Woodhouse wrote: > > > On Wed, 2006-12-20 at 11:59 -0600, Rex Dieter wrote: > > >> If by "We", you really mean "you", then you'd be correct. FESCo, > > >> currently anyway, still allows kmods in limited cases. > > > > > > If by 'limited' we mean cases where DaveJ, Jesse and I _all_ agree that > > > it's a good idea, I'm fine with that policy continuing in the combined > > > Fedora :) > > > > Tell ya what, I'll consider giving Jesse (et-al) veto power over all > > kmods the day > > http://bugzilla.redhat.com/170335 > > is fixed. deal? > > Given this has absolutely nothing to do with the discussion at hand, > I'm assuming you typoed the bug number. No typo, I'm damn serious. -- Rex From davej at redhat.com Wed Dec 20 19:38:41 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 14:38:41 -0500 Subject: kernels in the packaging universe In-Reply-To: References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> <1166637319.25827.272.camel@pmac.infradead.org> <458979F8.1020008@math.unl.edu> <20061220190040.GC3248@redhat.com> Message-ID: <20061220193841.GG3248@redhat.com> On Wed, Dec 20, 2006 at 02:06:39PM -0500, Greg Dekoenigsberg wrote: > To the best of my knowledge, the problem you have with kmods/alternate > kernels is that people complain when they break, and they fill bugzilla > with bugs that don't make sense -- because people don't understand that > they're running funky kernels. > > Right? Are there any other reasons not to package these alternate > kernels? > > Because that's a valid reason. But it also gives us something to shoot > for: better reporting tools. The bugzilla issue is the #1 reason. I don't want to do another round-trip in bugzilla where I have to ask.. "Now try and repeat this issue without kmod-blah loaded". This has always been a problem for users who choose to build their own addons, but offering prebuilt binaries makes it easier, and hence more of a problem. It's as big a problem as the nvidia & ati modules. In fact worse, because we actually endorse these by their prescence in extras. There's usually good reason that code isn't accepted upstream. Quite often that reason is "driver xyz is a steaming shitpile". As a result, I refuse to look into any bug until out-of-tree drivers are removed from the equation. And if users refuse to try without that driver, I'll close it CANTFIX. Kernel bugs in Fedora are _out of control_. And yet it seems we're determined to do whatever we can to make the situation even more unmanagable. If these drivers are important enough to be in Fedora, they're important enough to get beaten into shape to survive an upstream code review and subsequent inclusion there. Packaging them into RPMS doesn't achieve this. At all. Any comments about "increased testing" are pointless, because they typically find superficial bugs that are usually easily fixed. Fundamental problems are typically only found by code review. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Dec 20 19:41:10 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 14:41:10 -0500 Subject: kernels in the packaging universe In-Reply-To: <45898E7B.30105@math.unl.edu> References: <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> <1166637319.25827.272.camel@pmac.infradead.org> <458979F8.1020008@math.unl.edu> <1166640573.25827.276.camel@pmac.infradead.org> <45898CE8.1050209@math.unl.edu> <20061220192459.GF3248@redhat.com> <45898E7B.30105@math.unl.edu> Message-ID: <20061220194110.GI3248@redhat.com> On Wed, Dec 20, 2006 at 01:26:51PM -0600, Rex Dieter wrote: > Dave Jones wrote: > > On Wed, Dec 20, 2006 at 01:20:08PM -0600, Rex Dieter wrote: > > > David Woodhouse wrote: > > > > On Wed, 2006-12-20 at 11:59 -0600, Rex Dieter wrote: > > > >> If by "We", you really mean "you", then you'd be correct. FESCo, > > > >> currently anyway, still allows kmods in limited cases. > > > > > > > > If by 'limited' we mean cases where DaveJ, Jesse and I _all_ agree that > > > > it's a good idea, I'm fine with that policy continuing in the combined > > > > Fedora :) > > > > > > Tell ya what, I'll consider giving Jesse (et-al) veto power over all > > > kmods the day > > > http://bugzilla.redhat.com/170335 > > > is fixed. deal? > > > > Given this has absolutely nothing to do with the discussion at hand, > > I'm assuming you typoed the bug number. > > No typo, I'm damn serious. So enlighten me. What does this have to do with what's being discussed ? To me it seems to be nothing other than axe-grinding. Dave -- http://www.codemonkey.org.uk From skvidal at linux.duke.edu Wed Dec 20 19:44:46 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 20 Dec 2006 14:44:46 -0500 Subject: F7 Plan (draft) In-Reply-To: <4589844F.8060306@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <4589635C.4080702@redhat.com> <20061220174408.GQ31335@redhat.com> <4589844F.8060306@redhat.com> Message-ID: <1166643886.28129.22.camel@cutter> On Wed, 2006-12-20 at 13:43 -0500, Tim Burke wrote: > Dave Jones wrote: > > > > Whilst Red Hat's medical coverage fully covers "mental health" issues, > > I'd really rather not proceed down this avenue. > > > > We can't support *one* kernel properly. On what planet does it make sense > > to throw more variants in the mix ? > > > > This whole idea stinks of doom so bad. > > > > > +1 > +1 -sv From rdieter at math.unl.edu Wed Dec 20 19:43:15 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Dec 2006 13:43:15 -0600 Subject: kernels in the packaging universe In-Reply-To: <20061220193841.GG3248@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> <1166637319.25827.272.camel@pmac.infradead.org> <458979F8.1020008@math.unl.edu> <20061220190040.GC3248@redhat.com> <20061220193841.GG3248@redhat.com> Message-ID: <45899253.7010508@math.unl.edu> Dave Jones wrote: > On Wed, Dec 20, 2006 at 02:06:39PM -0500, Greg Dekoenigsberg wrote: > > > To the best of my knowledge, the problem you have with kmods/alternate > > kernels is that people complain when they break, and they fill bugzilla > > with bugs that don't make sense -- because people don't understand that > > they're running funky kernels. > > > > Right? Are there any other reasons not to package these alternate > > kernels? > > > > Because that's a valid reason. But it also gives us something to shoot > > for: better reporting tools. > > The bugzilla issue is the #1 reason. > I don't want to do another round-trip in bugzilla where I have to ask.. > > "Now try and repeat this issue without kmod-blah loaded". Personally, I consider this more of a bug triaging failure. kernel bugs should only be accepted/allowed *only* if from verifiably taint-free kernels. Everything else -> closed/INVALID. -- Rex From skvidal at linux.duke.edu Wed Dec 20 19:46:15 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 20 Dec 2006 14:46:15 -0500 Subject: kernels in the packaging universe In-Reply-To: <45899253.7010508@math.unl.edu> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> <1166637319.25827.272.camel@pmac.infradead.org> <458979F8.1020008@math.unl.edu> <20061220190040.GC3248@redhat.com> <20061220193841.GG3248@redhat.com> <45899253.7010508@math.unl.edu> Message-ID: <1166643975.28129.24.camel@cutter> On Wed, 2006-12-20 at 13:43 -0600, Rex Dieter wrote: > Dave Jones wrote: > > On Wed, Dec 20, 2006 at 02:06:39PM -0500, Greg Dekoenigsberg wrote: > > > > > To the best of my knowledge, the problem you have with kmods/alternate > > > kernels is that people complain when they break, and they fill bugzilla > > > with bugs that don't make sense -- because people don't understand that > > > they're running funky kernels. > > > > > > Right? Are there any other reasons not to package these alternate > > > kernels? > > > > > > Because that's a valid reason. But it also gives us something to shoot > > > for: better reporting tools. > > > > The bugzilla issue is the #1 reason. > > I don't want to do another round-trip in bugzilla where I have to ask.. > > > > "Now try and repeat this issue without kmod-blah loaded". > > Personally, I consider this more of a bug triaging failure. kernel bugs > should only be accepted/allowed *only* if from verifiably taint-free > kernels. Everything else -> closed/INVALID. > but a gpl kernel module won't taint. -sv From rdieter at math.unl.edu Wed Dec 20 19:46:43 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Dec 2006 13:46:43 -0600 Subject: kernels in the packaging universe In-Reply-To: <20061220194110.GI3248@redhat.com> References: <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> <1166637319.25827.272.camel@pmac.infradead.org> <458979F8.1020008@math.unl.edu> <1166640573.25827.276.camel@pmac.infradead.org> <45898CE8.1050209@math.unl.edu> <20061220192459.GF3248@redhat.com> <45898E7B.30105@math.unl.edu> <20061220194110.GI3248@redhat.com> Message-ID: <45899323.1050809@math.unl.edu> Dave Jones wrote: > On Wed, Dec 20, 2006 at 01:26:51PM -0600, Rex Dieter wrote: > > > > Tell ya what, I'll consider giving Jesse (et-al) veto power over all > > > > kmods the day > > > > http://bugzilla.redhat.com/170335 > > > > is fixed. deal? > > > Given this has absolutely nothing to do with the discussion at hand, > > > I'm assuming you typoed the bug number. > > No typo, I'm damn serious. > So enlighten me. What does this have to do with what's being discussed ? > To me it seems to be nothing other than axe-grinding. Yep, call it what you want, but I call it compromise. I'm willing to bend to give you what you want, if you kick/poke/cajole gtk's maintainer to fix what I want. -- Rex From davej at redhat.com Wed Dec 20 19:54:15 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 14:54:15 -0500 Subject: kernels in the packaging universe In-Reply-To: <1166643975.28129.24.camel@cutter> References: <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> <1166637319.25827.272.camel@pmac.infradead.org> <458979F8.1020008@math.unl.edu> <20061220190040.GC3248@redhat.com> <20061220193841.GG3248@redhat.com> <45899253.7010508@math.unl.edu> <1166643975.28129.24.camel@cutter> Message-ID: <20061220195415.GA17349@redhat.com> On Wed, Dec 20, 2006 at 02:46:15PM -0500, seth vidal wrote: > On Wed, 2006-12-20 at 13:43 -0600, Rex Dieter wrote: > > Dave Jones wrote: > > > On Wed, Dec 20, 2006 at 02:06:39PM -0500, Greg Dekoenigsberg wrote: > > > > > > > To the best of my knowledge, the problem you have with kmods/alternate > > > > kernels is that people complain when they break, and they fill bugzilla > > > > with bugs that don't make sense -- because people don't understand that > > > > they're running funky kernels. > > > > > > > > Right? Are there any other reasons not to package these alternate > > > > kernels? > > > > > > > > Because that's a valid reason. But it also gives us something to shoot > > > > for: better reporting tools. > > > > > > The bugzilla issue is the #1 reason. > > > I don't want to do another round-trip in bugzilla where I have to ask.. > > > > > > "Now try and repeat this issue without kmod-blah loaded". > > > > Personally, I consider this more of a bug triaging failure. kernel bugs > > should only be accepted/allowed *only* if from verifiably taint-free > > kernels. Everything else -> closed/INVALID. > > > > but a gpl kernel module won't taint. Right. And here's another shocker.. People lie. It's hard to find words to describe how you feel when you find yourself in a situation like.. * "Hey kernel is broken because blah" * Do you have 3rd party modules loaded ? * No * Much investigation happens. Lots of head scratching. * Weeks later.. "Oh, the problem doesn't happen if I rmmod foo.ko" * Fedora kernels don't ship foo.ko. I hate you so much right now. This has happened with far more regularity than I'd like. Dave -- http://www.codemonkey.org.uk From notting at redhat.com Wed Dec 20 19:59:16 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Dec 2006 14:59:16 -0500 Subject: F7 Plan (draft) In-Reply-To: <4589841D.1050309@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <458960E5.7030903@redhat.com> <20061220174001.GP31335@redhat.com> <4589841D.1050309@redhat.com> Message-ID: <20061220195916.GA13660@nostromo.devel.redhat.com> Tim Burke (tburke at redhat.com) said: > Agreed that sysctls are far better than different kernel builds. Having > said that.. what is the mechanism to actually set different knobs on a > client distro vs a server distro? TBD, and probably on my plate. Bill From notting at redhat.com Wed Dec 20 20:02:43 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Dec 2006 15:02:43 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061220174548.GR31335@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <4589635C.4080702@redhat.com> <200612201130.43492.jkeating@redhat.com> <20061220174548.GR31335@redhat.com> Message-ID: <20061220200243.GB13660@nostromo.devel.redhat.com> Dave Jones (davej at redhat.com) said: > > I honestly think that we can no longer deliver _anything_ significant in the > > Fedora kernels that isn't upstream. > > Right. Remember that original Fedora goal "Be close to upstream" ? > We need to get back on track to that ASAP, not deviate further away. > And shovelling things into separate RPMs is not the right answer to the > current problem I think the rough limit to things we can have that aren't upstream are things like "driver in -mm that is on its way to Linus", or "thing like Xen *with associated headcount to keep it in shape reliably, because we can't yank it out from our userbase now that we put it in" We can't really put all this on Dave. Bill From notting at redhat.com Wed Dec 20 20:04:02 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Dec 2006 15:04:02 -0500 Subject: F7 Plan (draft) In-Reply-To: <45896583.30405@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896583.30405@redhat.com> Message-ID: <20061220200402.GC13660@nostromo.devel.redhat.com> Tim Burke (tburke at redhat.com) said: > Bill Nottingham wrote: > >Got more? Let me know! > > What about laptop suspend/resume. I thought that was a never-ending saga. Sort of. It's been working for me fine for quite a while, and hibernate works on my desktop too. We can catch regressions if they're filed, and maybe spend a day or two doing smoketesting later in the cycle. > Ditto for ipv6. I thought there was an initial flare-up of activity > late in FC6 which didn't come to fruition because it was too late. It's in anaconda for configuration, and I believe everything that's 'important' works. Bill From jkeating at redhat.com Wed Dec 20 20:18:08 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Dec 2006 15:18:08 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061220200243.GB13660@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <20061220174548.GR31335@redhat.com> <20061220200243.GB13660@nostromo.devel.redhat.com> Message-ID: <200612201518.11362.jkeating@redhat.com> On Wednesday 20 December 2006 15:02, Bill Nottingham wrote: > "thing like Xen *with associated headcount to keep it in shape > reliably, because we can't yank it out from our userbase now that > we put it in" We can't really put all this on Dave. And what happens when that headcount no longer cares about Fedora? See rawhide. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Wed Dec 20 20:22:10 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Dec 2006 15:22:10 -0500 Subject: F7 Plan (draft) In-Reply-To: <200612201518.11362.jkeating@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <20061220174548.GR31335@redhat.com> <20061220200243.GB13660@nostromo.devel.redhat.com> <200612201518.11362.jkeating@redhat.com> Message-ID: <20061220202210.GA14244@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > On Wednesday 20 December 2006 15:02, Bill Nottingham wrote: > > "thing like Xen *with associated headcount to keep it in shape > > reliably, because we can't yank it out from our userbase now that > > we put it in" We can't really put all this on Dave. > > And what happens when that headcount no longer cares about Fedora? See > rawhide. They're headcount. They're made to care. :P Bill From jkeating at redhat.com Wed Dec 20 20:37:17 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Dec 2006 15:37:17 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061220202210.GA14244@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <200612201518.11362.jkeating@redhat.com> <20061220202210.GA14244@nostromo.devel.redhat.com> Message-ID: <200612201537.17907.jkeating@redhat.com> On Wednesday 20 December 2006 15:22, Bill Nottingham wrote: > They're headcount. They're made to care. :P So then why is Xen completely and utterly broken on rawhide, with no hope on the horizon? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gdk at redhat.com Wed Dec 20 20:31:21 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 20 Dec 2006 15:31:21 -0500 (EST) Subject: kernels in the packaging universe In-Reply-To: <20061220195415.GA17349@redhat.com> References: <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> <1166637319.25827.272.camel@pmac.infradead.org> <458979F8.1020008@math.unl.edu> <20061220190040.GC3248@redhat.com> <20061220193841.GG3248@redhat.com> <45899253.7010508@math.unl.edu> <1166643975.28129.24.camel@cutter> <20061220195415.GA17349@redhat.com> Message-ID: On Wed, 20 Dec 2006, Dave Jones wrote: > People lie. > > It's hard to find words to describe how you feel when you find yourself > in a situation like.. > > * "Hey kernel is broken because blah" > > * Do you have 3rd party modules loaded ? > > * No > > * Much investigation happens. Lots of head scratching. > > * Weeks later.. > > "Oh, the problem doesn't happen if I rmmod foo.ko" > > * Fedora kernels don't ship foo.ko. I hate you so much right now. Which makes this, to some degree, a tools problem. If one of the fundamental problems with the Fedora kernel is "way too many shitty bugs filed," then it seems to me that one solution might be to disallow the filing of kernel bugs without the output of 'kernel-debug-script'. And what does kernel-debug-script do? Well, I guess it lists the exact kernel version and all loaded modules, and maybe it also dumps the results of lshal, and maybe it does all kinds of other stuff. We should be using simple tools to remove the guesswork from the equation wherever possible. Maybe that kind of tool should be added to The List of 25. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From davej at redhat.com Wed Dec 20 20:42:53 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 15:42:53 -0500 Subject: kernels in the packaging universe In-Reply-To: References: <1166637095.5069.75.camel@localhost.localdomain> <1166637319.25827.272.camel@pmac.infradead.org> <458979F8.1020008@math.unl.edu> <20061220190040.GC3248@redhat.com> <20061220193841.GG3248@redhat.com> <45899253.7010508@math.unl.edu> <1166643975.28129.24.camel@cutter> <20061220195415.GA17349@redhat.com> Message-ID: <20061220204253.GJ3248@redhat.com> On Wed, Dec 20, 2006 at 03:31:21PM -0500, Greg Dekoenigsberg wrote: > > * Fedora kernels don't ship foo.ko. I hate you so much right now. > Which makes this, to some degree, a tools problem. > > If one of the fundamental problems with the Fedora kernel is "way too many > shitty bugs filed," then it seems to me that one solution might be to > disallow the filing of kernel bugs without the output of > 'kernel-debug-script'. What happens if the bug they want to file is "Fedora kernel doesn't boot" ? Before you answer "we could make exceptions for that case", we've had scenarios like the one I describe where 3rd party modules prevent booting due to busted initrds. The kernel the user is running is not necessarily the one they're having problems with. Dave -- http://www.codemonkey.org.uk From notting at redhat.com Wed Dec 20 20:45:42 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Dec 2006 15:45:42 -0500 Subject: F7 Plan (draft) In-Reply-To: <200612201537.17907.jkeating@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <200612201518.11362.jkeating@redhat.com> <20061220202210.GA14244@nostromo.devel.redhat.com> <200612201537.17907.jkeating@redhat.com> Message-ID: <20061220204542.GB14543@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > > They're headcount. They're made to care. :P > > So then why is Xen completely and utterly broken on rawhide, with no hope on > the horizon? The headcount *tasked to Fedora* may or may not be there now - that's what I'm saying is a prerequisite for keeping Xen in. Bill From katzj at redhat.com Wed Dec 20 20:48:29 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Dec 2006 15:48:29 -0500 Subject: F7 Plan (draft) In-Reply-To: <200612201537.17907.jkeating@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <200612201518.11362.jkeating@redhat.com> <20061220202210.GA14244@nostromo.devel.redhat.com> <200612201537.17907.jkeating@redhat.com> Message-ID: <1166647709.10717.44.camel@aglarond.local> On Wed, 2006-12-20 at 15:37 -0500, Jesse Keating wrote: > On Wednesday 20 December 2006 15:22, Bill Nottingham wrote: > > They're headcount. They're made to care. :P > > So then why is Xen completely and utterly broken on rawhide, with no hope on > the horizon? To be fair, this isn't because it's not being worked on -- it's just that it's a huge chunk of work to get it back to working. But Juan is continuing to move forward and make progress Jeremy From jkeating at redhat.com Wed Dec 20 21:04:27 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Dec 2006 16:04:27 -0500 Subject: F7 Plan (draft) In-Reply-To: <1166647709.10717.44.camel@aglarond.local> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <200612201537.17907.jkeating@redhat.com> <1166647709.10717.44.camel@aglarond.local> Message-ID: <200612201604.27603.jkeating@redhat.com> On Wednesday 20 December 2006 15:48, Jeremy Katz wrote: > > So then why is Xen completely and utterly broken on rawhide, with no hope > > on the horizon? > > To be fair, this isn't because it's not being worked on -- it's just > that it's a huge chunk of work to get it back to working. ?But Juan is > continuing to move forward and make progress True. However if we were waiting for Xen to work again, we'd be holding up further kernel development, for something that the Fedora userbase at large may not care about. With KVM upstream, and lhype having far more of a chance than Xen, how much does our userbase really care about Xen when there are better (or at least more accepted) replacements? (yes, I'm off into lala land here) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Wed Dec 20 21:03:14 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Dec 2006 16:03:14 -0500 Subject: F7 Plan (draft) In-Reply-To: <200612201604.27603.jkeating@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <200612201537.17907.jkeating@redhat.com> <1166647709.10717.44.camel@aglarond.local> <200612201604.27603.jkeating@redhat.com> Message-ID: <20061220210314.GA14902@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > True. However if we were waiting for Xen to work again, we'd be holding up > further kernel development, for something that the Fedora userbase at large > may not care about. With KVM upstream, and lhype having far more of a chance > than Xen, how much does our userbase really care about Xen when there are > better (or at least more accepted) replacements? > > (yes, I'm off into lala land here) That implies KVM and lhype are working in Fedora. Which they aren't, at the moment. Bill From jkeating at redhat.com Wed Dec 20 21:10:32 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Dec 2006 16:10:32 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061220210314.GA14902@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <200612201604.27603.jkeating@redhat.com> <20061220210314.GA14902@nostromo.devel.redhat.com> Message-ID: <200612201610.33027.jkeating@redhat.com> On Wednesday 20 December 2006 16:03, Bill Nottingham wrote: > That implies KVM and lhype are working in Fedora. Which they aren't, > at the moment. Having just watched Jeremy boot the next LiveCD test in KVM on his rawhide box, I'd say its working a heck of a lot better than Xen. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Wed Dec 20 21:13:13 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 16:13:13 -0500 Subject: F7 Plan (draft) In-Reply-To: <1166647709.10717.44.camel@aglarond.local> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <200612201518.11362.jkeating@redhat.com> <20061220202210.GA14244@nostromo.devel.redhat.com> <200612201537.17907.jkeating@redhat.com> <1166647709.10717.44.camel@aglarond.local> Message-ID: <20061220211313.GL3248@redhat.com> On Wed, Dec 20, 2006 at 03:48:29PM -0500, Jeremy Katz wrote: > On Wed, 2006-12-20 at 15:37 -0500, Jesse Keating wrote: > > On Wednesday 20 December 2006 15:22, Bill Nottingham wrote: > > > They're headcount. They're made to care. :P > > > > So then why is Xen completely and utterly broken on rawhide, with no hope on > > the horizon? > > To be fair, this isn't because it's not being worked on -- it's just > that it's a huge chunk of work to get it back to working. But Juan is > continuing to move forward and make progress However, we've now got a situation brewing for updates. FC6 is now bottlenecking on Xen for 2.6.19[*]. By the time that gets done, 2.6.20 will be released, and the cycle repeats. We've lost our ability to track upstream quickly for updates. Dave [*] Yes, there's other stuff that still needs fixing for FC6 anyway, but that's small potatoes in comparison. -- http://www.codemonkey.org.uk From davej at redhat.com Wed Dec 20 21:14:23 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 16:14:23 -0500 Subject: F7 Plan (draft) In-Reply-To: <200612201610.33027.jkeating@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <200612201604.27603.jkeating@redhat.com> <20061220210314.GA14902@nostromo.devel.redhat.com> <200612201610.33027.jkeating@redhat.com> Message-ID: <20061220211423.GM3248@redhat.com> On Wed, Dec 20, 2006 at 04:10:32PM -0500, Jesse Keating wrote: > On Wednesday 20 December 2006 16:03, Bill Nottingham wrote: > > That implies KVM and lhype are working in Fedora. Which they aren't, > > at the moment. > > Having just watched Jeremy boot the next LiveCD test in KVM on his rawhide > box, I'd say its working a heck of a lot better than Xen. We're still boned for paravirt though, which some may argue, is the more interesting case (given not everyone has a CPU with the right knobs). Dave -- http://www.codemonkey.org.uk From katzj at redhat.com Wed Dec 20 21:12:54 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Dec 2006 16:12:54 -0500 Subject: F7 Plan (draft) In-Reply-To: <200612201610.33027.jkeating@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <200612201604.27603.jkeating@redhat.com> <20061220210314.GA14902@nostromo.devel.redhat.com> <200612201610.33027.jkeating@redhat.com> Message-ID: <1166649174.10717.55.camel@aglarond.local> On Wed, 2006-12-20 at 16:10 -0500, Jesse Keating wrote: > On Wednesday 20 December 2006 16:03, Bill Nottingham wrote: > > That implies KVM and lhype are working in Fedora. Which they aren't, > > at the moment. > > Having just watched Jeremy boot the next LiveCD test in KVM on his rawhide > box, I'd say its working a heck of a lot better than Xen. Really? I can do the *EXACT SAME THING* on FC6 with Xen. Except that I can do it with a graphical set of tools to handle domain creation, monitoring, etc. And get better performance. And not have to hack the tools to even get it to that point[1] ;-) Jeremy [1] Granted, this may be because I've previously hacked on the Xen tools. From katzj at redhat.com Wed Dec 20 21:13:00 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Dec 2006 16:13:00 -0500 Subject: F7 Plan (draft) In-Reply-To: <200612201604.27603.jkeating@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <200612201537.17907.jkeating@redhat.com> <1166647709.10717.44.camel@aglarond.local> <200612201604.27603.jkeating@redhat.com> Message-ID: <1166649180.10717.57.camel@aglarond.local> On Wed, 2006-12-20 at 16:04 -0500, Jesse Keating wrote: > On Wednesday 20 December 2006 15:48, Jeremy Katz wrote: > > > So then why is Xen completely and utterly broken on rawhide, with no hope > > > on the horizon? > > > > To be fair, this isn't because it's not being worked on -- it's just > > that it's a huge chunk of work to get it back to working. But Juan is > > continuing to move forward and make progress > > True. However if we were waiting for Xen to work again, we'd be holding up > further kernel development, for something that the Fedora userbase at large > may not care about. There's a pretty large segment of the Fedora userbase that cares about and is actively using Xen. And pretty much the largest contingent of Xen users are using it on Fedora. Unfortunately, this is an area where we've made commitments to users that we think it's important and I'm not sure that we can just drop it on the cutting room floor. > With KVM upstream, and lhype having far more of a chance > than Xen, how much does our userbase really care about Xen when there are > better (or at least more accepted) replacements? If they actually were to a point where they provided equivalent functionality, then it'd be something to talk about. But right now, they're just not there. It's like saying that we should stop shipping our current desktop environments for the one I started in my basement last week ;-) KVM is only _just_ upstream and isn't anywhere near as mature as Xen for fully virt (and it is _only_ fully virt). There's no support for SMP, a lot of real mode stuff has no chance of working[1], no work has been done on performance at all, the OS coverage is definitely less, there isn't a framework for paravirt drivers, etc. Also, our toolset currently has zero support for it. I expect that all of these will improve over time, but it's just not a point where it's a drop-in replacement for Xen's fully virt capabilities. As for lhype, it's just as not upstream as Xen and yet isn't nearly as mature in terms of having tools, OS integration, performance, SMP, etc. Jeremy From jkeating at redhat.com Wed Dec 20 21:43:04 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Dec 2006 16:43:04 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061219055905.GC19172@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> Message-ID: <200612201643.04700.jkeating@redhat.com> On Tuesday 19 December 2006 00:59, Bill Nottingham wrote: > Got more? Let me know! Fedora Update Tool Rewrite Accountable: Luke Macken Important dates: Needs TESTABLE by Test2, Done by Test3 or Final. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Wed Dec 20 21:49:27 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Dec 2006 16:49:27 -0500 Subject: mailing-list reorganisation, round 2 In-Reply-To: <45896DDE.3080102@leemhuis.info> References: <45896DDE.3080102@leemhuis.info> Message-ID: <20061220214927.GB15241@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > second round in the process to solve the "we have to many mailinglists" > problem (first round starts at > https://www.redhat.com/archives/fedora-advisory-board/2006-December/msg00104.html > ; diff against first proposal: > http://www.fedoraproject.org/wiki/ThorstenLeemhuis/MailingListReorganization?action=diff&rev2=2&rev1=1 > ). Comments? If I some "yeah, I tend to like it" I'll post it to the > relevant mailing lists asking people to comment before we realize it. One thing that will need done here is some fairly serious wiki editing and cleanup - fedora-extras-* is sprinkled pretty heavily throughout it. (We require that people sign up for extras-commits?) Bill From jkeating at redhat.com Wed Dec 20 22:02:34 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Dec 2006 17:02:34 -0500 Subject: mailing-list reorganisation, round 2 In-Reply-To: <45896DDE.3080102@leemhuis.info> References: <45896DDE.3080102@leemhuis.info> Message-ID: <200612201702.34712.jkeating@redhat.com> On Wednesday 20 December 2006 12:07, Thorsten Leemhuis wrote: > === fedora-extras-list === > > Well, it seems the "Core packages gets merged into the Extras framework" > is nearly official. Discuss the stuff that was on fedora-extras-list > until now on fedora-devel in the future. Well, mock, plague, pungi, and potentially br^W new Fedora Buildsystem Software use this list as their 'upstream' mailing list. We'd rather not use fedora-devel as these pieces of software have users outside of Fedora, that will probably not be interested in sifting through tonnes of Fedora specific mail. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From matt at domsch.com Wed Dec 20 22:42:49 2006 From: matt at domsch.com (Matt Domsch) Date: Wed, 20 Dec 2006 16:42:49 -0600 Subject: mailing-list reorganisation, round 2 In-Reply-To: <200612201702.34712.jkeating@redhat.com> References: <45896DDE.3080102@leemhuis.info> <200612201702.34712.jkeating@redhat.com> Message-ID: <20061220224249.GA10246@domsch.com> On Wed, Dec 20, 2006 at 05:02:34PM -0500, Jesse Keating wrote: > On Wednesday 20 December 2006 12:07, Thorsten Leemhuis wrote: > > === fedora-extras-list === > > > > Well, it seems the "Core packages gets merged into the Extras framework" > > is nearly official. Discuss the stuff that was on fedora-extras-list > > until now on fedora-devel in the future. > > Well, mock, plague, pungi, and potentially br^W new Fedora Buildsystem > Software use this list as their 'upstream' mailing list. We'd rather not use > fedora-devel as these pieces of software have users outside of Fedora, that > will probably not be interested in sifting through tonnes of Fedora specific > mail. You mean keep fedora-buildsys-list for all this, right? From jkeating at redhat.com Wed Dec 20 22:57:46 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Dec 2006 17:57:46 -0500 Subject: mailing-list reorganisation, round 2 In-Reply-To: <20061220224249.GA10246@domsch.com> References: <45896DDE.3080102@leemhuis.info> <200612201702.34712.jkeating@redhat.com> <20061220224249.GA10246@domsch.com> Message-ID: <200612201757.47161.jkeating@redhat.com> On Wednesday 20 December 2006 17:42, Matt Domsch wrote: > You mean keep fedora-buildsys-list for all this, right? Yes, please, I'm asking for this list to be kept, and not removed. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From matt at domsch.com Thu Dec 21 01:47:06 2006 From: matt at domsch.com (Matt Domsch) Date: Wed, 20 Dec 2006 19:47:06 -0600 Subject: F7 Plan (draft) In-Reply-To: <20061220211423.GM3248@redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <200612201604.27603.jkeating@redhat.com> <20061220210314.GA14902@nostromo.devel.redhat.com> <200612201610.33027.jkeating@redhat.com> <20061220211423.GM3248@redhat.com> Message-ID: <20061221014706.GA2964@domsch.com> On Wed, Dec 20, 2006 at 04:14:23PM -0500, Dave Jones wrote: > On Wed, Dec 20, 2006 at 04:10:32PM -0500, Jesse Keating wrote: > > On Wednesday 20 December 2006 16:03, Bill Nottingham wrote: > > > That implies KVM and lhype are working in Fedora. Which they aren't, > > > at the moment. > > > > Having just watched Jeremy boot the next LiveCD test in KVM on his rawhide > > box, I'd say its working a heck of a lot better than Xen. > > We're still boned for paravirt though, which some may argue, is > the more interesting case (given not everyone has a CPU with the right knobs). Given that those CPUs have only been available from Intel or AMD for a few *months* (~6), indeed, relatively few are in the hands of users. Not to mention the performance hit from fully-virt at this point. It'd be like announcing we were going to only produce Blu-Ray DVDs from now on. >From where can we get additional resources to help with the Xen-in-Fedora merging, or is it the case that adding more people to an already late project just makes it later? In that case, what/how can we offload Juan or whomever so they can focus? -Matt From davej at redhat.com Thu Dec 21 02:06:43 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 21:06:43 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061221014706.GA2964@domsch.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <200612201604.27603.jkeating@redhat.com> <20061220210314.GA14902@nostromo.devel.redhat.com> <200612201610.33027.jkeating@redhat.com> <20061220211423.GM3248@redhat.com> <20061221014706.GA2964@domsch.com> Message-ID: <20061221020643.GA29027@redhat.com> On Wed, Dec 20, 2006 at 07:47:06PM -0600, Matt Domsch wrote: > On Wed, Dec 20, 2006 at 04:14:23PM -0500, Dave Jones wrote: > > On Wed, Dec 20, 2006 at 04:10:32PM -0500, Jesse Keating wrote: > > > On Wednesday 20 December 2006 16:03, Bill Nottingham wrote: > > > > That implies KVM and lhype are working in Fedora. Which they aren't, > > > > at the moment. > > > > > > Having just watched Jeremy boot the next LiveCD test in KVM on his rawhide > > > box, I'd say its working a heck of a lot better than Xen. > > > > We're still boned for paravirt though, which some may argue, is > > the more interesting case (given not everyone has a CPU with the right knobs). > > Given that those CPUs have only been available from Intel or AMD for a > few *months* (~6), indeed, relatively few are in the hands of users. > Not to mention the performance hit from fully-virt at this point. > It'd be like announcing we were going to only produce Blu-Ray DVDs > from now on. > > >From where can we get additional resources to help with the > Xen-in-Fedora merging, or is it the case that adding more people to an > already late project just makes it later? In that case, what/how can we > offload Juan or whomever so they can focus? The ramp-up time alone for that role is sufficient to put off most people. It's really, really unfun work. Xen needed to get upstream months ago, but there's been near zero movement on that front. Chris Wright has been trying to bend it to fit on top of the paravirt stuff in the .19 kernel, so maybe there's hope yet, but personally, I'm fairly jaded over the whole thing by now. By the time Xen gets upstream people will have moved on to the next fad. (Which is one reason I'm pushing back hard on requests like "merge -rt"). Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Thu Dec 21 06:50:17 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 21 Dec 2006 07:50:17 +0100 Subject: What do we want to archive with Fedora? Message-ID: <458A2EA9.8050508@leemhuis.info> Hi, the current "alternate kernels"(?) and the "never ending story: we don't want kmods in Fedora" discussions slightly annoy me a bit and makes me wondering: "What do we want to archive with Fedora"? Or, to be more precise: "What's more important, giving the users what they want, giving them what we think is right for them or what we think is political the correctest?" Sure, the answer is "something in between". But where exactly? I fully understand why kernel-developers like dwmw2 and davej don't want kmods or alternative kernels (BTW, those two are doing a great job for Fedora and upstream; thx guys!). But it's something some people want/think they need(?). Heck, those people are probably even willing to put work into it to get it into Fedora(?) -- so do we really want to forbid it? I might be wrong, but I don't think that's the way to get the community involved properly. CU thl (?) -- just in case anybody is wondering: no, I do not want different kernel for our desktop and server spins, too. That makes no sense afaics. (?) -- and understandable desire giving the fact that there are a lot of kernel-drivers out there that are not upstream (talking only about open-source drivers here, I don't want the proprietary crap in Fedora, too). Sure that sucks, and it would be best if all those modules would go directly upstream, but is it our task to enforce it? Sure, we should encourage it, but do we have to produce a worse product due to the missing not-yet-upstream stuff just to put load on the driver authors to make them send there modules upstream? If the answer is yes: why don't we obey our own rules and have tux in our kernels for ages? It will never go upstream afaics. (?) -- no, those kernels and kmods should IMHO never be that import to get part of our main products (e.g. what's know as Fedora Core now and what will be "Fedora Server", "Fedora Desktop Gnome", "Fedora Desktop KDE" and "Fedora Directors Cut, Extra long" in the future). They should remain add ons mostly supported by the community-members that wants them. Well, maybe some might get included in special Editions like "Fedora Soundstudio" that might want to use a RT-Kernel or "Fedora FSF GNU/Linux" with a kernel that has all the firmware parts removed. From jkeating at redhat.com Thu Dec 21 13:42:39 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 21 Dec 2006 08:42:39 -0500 Subject: What do we want to archive with Fedora? In-Reply-To: <458A2EA9.8050508@leemhuis.info> References: <458A2EA9.8050508@leemhuis.info> Message-ID: <200612210842.42835.jkeating@redhat.com> On Thursday 21 December 2006 01:50, Thorsten Leemhuis wrote: > But it's something some people want/think they need(?). Heck, those > people are probably even willing to put work into it to get it into > Fedora(?) -- so do we really want to forbid it? I might be wrong, but I > don't think that's the way to get the community involved properly. I honestly feel that we'd be doing them a disservice by packaging them up for them. Its vendors like us that are in the position to apply pressure to these driver authors to get their stuff beat into shape and merged upstream. If we package up the drivers, whats the motivation for the driver author to get his stuff upstream? Fedora users have access to the driver, Fedora folks are doing the work to keep the driver working, why should they bother? Why should the go through the review to make the driver better? We have to take advantage of our position as the gateway to our users. We set the bar to a specific point if the hardware / software developer wants to get their hardware / software into the hands of our users. If we lower the bar for hardware vendors, why would they ever aspire to the higher bar? The path of least resistance always wins, so _we_ win by not lowering the bar into our users, but perhaps making the path to upstream kernel easier, by assisting with the review, with the changes suggested, etc... whatever we can do to make the software go upstream quicker, THATS how we win. As to why Tux is in our kenrel? Historical reasons / customers that want/need it. Yep, its a rhelism, much like Xen was. Should it be pulled? If Fedora wasn't the direct upstream of RHEL, I'd say yes. However RHEL pays a lot of the Fedora bills, so I'm inclined to indulge them a little bit here and there. Should Red Hat have headcount to ensure that Tux keeps working with the new upstream kernels (and that headcount be somebody OTHER than DaveJ)? Sure! Can that happen tomorrow? Most likely not. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From luis at tieguy.org Thu Dec 21 14:32:54 2006 From: luis at tieguy.org (Luis Villa) Date: Thu, 21 Dec 2006 09:32:54 -0500 Subject: F7 Plan (draft) In-Reply-To: <20061219055905.GC19172@nostromo.devel.redhat.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> Message-ID: <2cb10c440612210632n3afc2377se627c18fb104bd9@mail.gmail.com> On 12/19/06, Bill Nottingham wrote: > Another one of our release targets. Needs defined by Test 2. If the release is date (Red Hat Summit) defined, what does 'release target' mean? > More info: http://fedoraproject.org/wiki/Desktop/FastUserSwitching I might suggest that Ubuntu's templated feature specs are something to look at as inspiration for future planning: https://launchpad.net/distros/ubuntu/+spec/dash-as-bin-sh https://wiki.ubuntu.com/DashAsBinSh I'd combine them into one page instead of two, but having rationale, people, priorities, use cases, etc., in one place seems very nice to have. > 13. LobbyBuddy > Accountable: Greg DeKoenigsberg > > Given your locale and timezone, determine where you are, and who your > elected representative is. Allow you to easily send them information > about how the laws should be changed with respect to patents and other > important issues. If it determines you do not have a duly elected > representative, offer a special initiative to lobby foreign representative > to install a new regime. (I'M KIDDING!) Greg, we should chat about user education at some point. I have a sense that many of our newer users wouldn't even know what they were lobbying for or why. Luis From gdk at redhat.com Thu Dec 21 16:27:18 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Thu, 21 Dec 2006 11:27:18 -0500 (EST) Subject: F7 Plan (draft) In-Reply-To: <2cb10c440612210632n3afc2377se627c18fb104bd9@mail.gmail.com> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <2cb10c440612210632n3afc2377se627c18fb104bd9@mail.gmail.com> Message-ID: On Thu, 21 Dec 2006, Luis Villa wrote: >> 13. LobbyBuddy >> Accountable: Greg DeKoenigsberg >> >> Given your locale and timezone, determine where you are, and who your >> elected representative is. Allow you to easily send them information >> about how the laws should be changed with respect to patents and other >> important issues. If it determines you do not have a duly elected >> representative, offer a special initiative to lobby foreign representative >> to install a new regime. (I'M KIDDING!) > > Greg, we should chat about user education at some point. I have a > sense that many of our newer users wouldn't even know what they were > lobbying for or why. This feature was mostly a joke. :) But it relates to feature #12, which is deadly earnest: a better way of catching specific "application not found" kinds of errors, Stating Our Position, and Providing An Alternative. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From notting at redhat.com Thu Dec 21 16:56:06 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 Dec 2006 11:56:06 -0500 Subject: What do we want to archive with Fedora? In-Reply-To: <458A2EA9.8050508@leemhuis.info> References: <458A2EA9.8050508@leemhuis.info> Message-ID: <20061221165606.GC24540@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > But it's something some people want/think they need(?). Heck, those > people are probably even willing to put work into it to get it into > Fedora(?) -- so do we really want to forbid it? I might be wrong, but I > don't think that's the way to get the community involved properly. Here's what I want to see - I don't want to hear 'people are probably even willing' - I want to see 'people are doing it'. If a RT kernel is what they want, start a RT kernel repo for Fedora on their webspace, and work to keep it up to date. If a module for their usbfrobozz is what they need, step up, put it in Extras, and start dealing with the hassles of keeping it up to date across updates and development. I'll admit - the way Fedora is developed right now, we don't have resources to throw towards projects we're not *actively* interested in for the next release; it's why on the proposed feature list that I need *names* for everything. The kind of community we're set up for is less of responding to 'you should do that' and more of 'hey, I did this, what do you think?' Bill (*) I'm not against having kmod packages in Extras, but I think we need to warn prospective users about what they're getting into. From rdieter at math.unl.edu Thu Dec 21 17:08:47 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 21 Dec 2006 11:08:47 -0600 Subject: apology to Matthias In-Reply-To: <45899323.1050809@math.unl.edu> References: <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> <1166637319.25827.272.camel@pmac.infradead.org> <458979F8.1020008@math.unl.edu> <1166640573.25827.276.camel@pmac.infradead.org> <45898CE8.1050209@math.unl.edu> <20061220192459.GF3248@redhat.com> <45898E7B.30105@math.unl.edu> <20061220194110.GI3248@redhat.com> <45899323.1050809@math.unl.edu> Message-ID: <458ABF9F.2030708@math.unl.edu> Rex Dieter wrote: > Yep, call it what you want, but I call it compromise. I'm willing to > bend to give you what you want, if you kick/poke/cajole gtk's maintainer > to fix what I want. I'd like to extend my apologies to Matthias (gtk). I in no way meant to slight or offend in any way. I do want to make it clear that if it is wrong to ask for help get old bugs some love, I don't want to be right. -- Rex From fche at redhat.com Thu Dec 7 02:58:51 2006 From: fche at redhat.com (Frank Ch. Eigler) Date: 06 Dec 2006 21:58:51 -0500 Subject: Fedora Freedom? In-Reply-To: <20061206175317.GG30810@nostromo.devel.redhat.com> References: <45760196.2080807@redhat.com> <1165366245.2485.2.camel@zelda.fubar.dk> <80d7e4090612051955kf4750b1t56f59e011bfaeda6@mail.gmail.com> <45765182.2030404@redhat.com> <1165383430.2485.31.camel@zelda.fubar.dk> <1165395409.25300.1.camel@cutter> <20061206175317.GG30810@nostromo.devel.redhat.com> Message-ID: Bill Nottingham writes: > [...] > "Freedom's just another word for nothing left to lose..." > Wait, no, that's not quite it. > "Freedom... you've gotta give for what you take" > [...] "Freedom costs a buck oh five." - FChE From Axel.Thimm at ATrpms.net Tue Dec 19 15:59:25 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 19 Dec 2006 16:59:25 +0100 Subject: 5k packages? In-Reply-To: <200612190937.06541.dennis@ausil.us> References: <45877CC9.8030608@redhat.com> <20061219144703.GA15354@domsch.com> <2cb10c440612190653h658ee36cx3a1bc1c7fe2c66a9@mail.gmail.com> <200612190937.06541.dennis@ausil.us> Message-ID: <20061219155925.GJ19154@neu.nirvana> On Tue, Dec 19, 2006 at 09:37:05AM -0600, Dennis Gilmore wrote: > On Tuesday 19 December 2006 08:53, Luis Villa wrote: > > On 12/19/06, Matt Domsch wrote: > > > On Tue, Dec 19, 2006 at 12:46:49AM -0500, Christopher Blizzard wrote: > > > > I just noticed that we passed through the 5k packages mark in extras. > > > > Kinda neat - seems to be continuing to slowly grow. :D > > > > > > well, 2500 (exactly) SRPMS, but yes, quite an accomplishment. > > > > I know this is sort of a bogus stat, but has anyone considered > > graphing this growth against the growth of debian and opensuse? One of > > the big criticisms of fedora/RH was always that, compared to debian > > and suse, there were many fewer centrally packaged programs which > > could be relied upon to cleanly install and run, so it seems like > > showing that Fedora is growing in this respect would be a nice > > marketing point. > > > > Luis > One thing that needs consideration in the comparison is that debain splits > things up in to the smallest possible binary package. We do not do that. > the fairest comparison is to look at the Sources. > by my count Fedora (core+extras) has ~3600 SRPMS > by a count in #suse 3015 src.rpm, 54 nosrc.rpm (not sure what a nosrc.rpm is > but i guess proprietary stuff) It's a src.rpm w/o (some) Sources. E.g. it's supposed to be used when you are not allowed to ship sources at all or modified sources. It isn't though any SuSE proprietary mechanism in rpm, it is available in Fedora, too, just not used. :) > Debian im still looking to find numbers. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Thu Dec 21 17:41:08 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 21 Dec 2006 23:11:08 +0530 Subject: 5k packages? In-Reply-To: <20061219155925.GJ19154@neu.nirvana> References: <45877CC9.8030608@redhat.com> <20061219144703.GA15354@domsch.com> <2cb10c440612190653h658ee36cx3a1bc1c7fe2c66a9@mail.gmail.com> <200612190937.06541.dennis@ausil.us> <20061219155925.GJ19154@neu.nirvana> Message-ID: <458AC734.90709@fedoraproject.org> Axel Thimm wrote: > It's a src.rpm w/o (some) Sources. E.g. it's supposed to be used when > you are not allowed to ship sources at all or modified sources. > > It isn't though any SuSE proprietary mechanism in rpm, it is available > in Fedora, too, just not used. :) > I think you misread what he said. He was referring to exactly the same thing as you. Rahul From fedora at leemhuis.info Thu Dec 21 17:51:24 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 21 Dec 2006 18:51:24 +0100 Subject: What do we want to archive with Fedora? In-Reply-To: <20061221165606.GC24540@nostromo.devel.redhat.com> References: <458A2EA9.8050508@leemhuis.info> <20061221165606.GC24540@nostromo.devel.redhat.com> Message-ID: <458AC99C.9030807@leemhuis.info> Bill Nottingham schrieb: > Thorsten Leemhuis (fedora at leemhuis.info) said: >> But it's something some people want/think they need(?). Heck, those >> people are probably even willing to put work into it to get it into >> Fedora(?) -- so do we really want to forbid it? I might be wrong, but I >> don't think that's the way to get the community involved properly. > Here's what I want to see - I don't want to hear 'people are probably > even willing' - I want to see 'people are doing it'. If a RT kernel is > what they want, start a RT kernel repo for Fedora on their webspace, and > work to keep it up to date. If a module for their usbfrobozz is what > they need, step up, put it in Extras, and start dealing with the hassles > of keeping it up to date across updates and development. And I want to do it the scope of the Fedora-project to get the people involved that way into the project. Currently we scare them often away with out behavior. Maybe some kind of experimental area would he a good idea. The Respins (and Live-CD-Betas) could live there, too. > I'll admit - the way Fedora is developed right now, we don't have > resources to throw towards projects we're not *actively* interested > in for the next release; Did I mention already that an we could need a experimental area? > it's why on the proposed feature list that > I need *names* for everything. Sure; btw, thx for it, I like it! > [...] > (*) I'm not against having kmod packages in Extras, but I think we > need to warn prospective users about what they're getting into. I more and more tend to think we should move the kmods and the kernels into some seperate add-on-repo. CU thl From Axel.Thimm at ATrpms.net Thu Dec 21 18:13:09 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 21 Dec 2006 19:13:09 +0100 Subject: 5k packages? In-Reply-To: <458AC734.90709@fedoraproject.org> References: <45877CC9.8030608@redhat.com> <20061219144703.GA15354@domsch.com> <2cb10c440612190653h658ee36cx3a1bc1c7fe2c66a9@mail.gmail.com> <200612190937.06541.dennis@ausil.us> <20061219155925.GJ19154@neu.nirvana> <458AC734.90709@fedoraproject.org> Message-ID: <20061221181309.GC29595@neu.nirvana> On Thu, Dec 21, 2006 at 11:11:08PM +0530, Rahul Sundaram wrote: > Axel Thimm wrote: > On Tue, Dec 19, 2006 at 09:37:05AM -0600, Dennis Gilmore wrote: > > 54 nosrc.rpm (not sure what a nosrc.rpm is but i guess proprietary > > stuff) > >It's a src.rpm w/o (some) Sources. E.g. it's supposed to be used > >when you are not allowed to ship sources at all or modified > >sources. > > > >It isn't though any SuSE proprietary mechanism in rpm, it is > >available in Fedora, too, just not used. :) > > I think you misread what he said. He was referring to exactly the same > thing as you. So you mean all I did was rephrasing "not sure what a nosrc.rpm is"? ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Thu Dec 21 18:15:48 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 21 Dec 2006 23:45:48 +0530 Subject: 5k packages? In-Reply-To: <20061221181309.GC29595@neu.nirvana> References: <45877CC9.8030608@redhat.com> <20061219144703.GA15354@domsch.com> <2cb10c440612190653h658ee36cx3a1bc1c7fe2c66a9@mail.gmail.com> <200612190937.06541.dennis@ausil.us> <20061219155925.GJ19154@neu.nirvana> <458AC734.90709@fedoraproject.org> <20061221181309.GC29595@neu.nirvana> Message-ID: <458ACF54.8070506@fedoraproject.org> Axel Thimm wrote: > > So you mean all I did was rephrasing "not sure what a nosrc.rpm is"? ;) > Just the latter part. Rahul From jwboyer at jdub.homelinux.org Sat Dec 23 16:06:36 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 23 Dec 2006 10:06:36 -0600 Subject: kernels in the packaging universe In-Reply-To: <1166637319.25827.272.camel@pmac.infradead.org> References: <20061219055905.GC19172@nostromo.devel.redhat.com> <45896779.6030401@fedoraproject.org> <200612201247.38338.jkeating@redhat.com> <1166637095.5069.75.camel@localhost.localdomain> <1166637319.25827.272.camel@pmac.infradead.org> Message-ID: <20061223160635.GA14996@yoda.jdub.homelinux.org> On Wed, Dec 20, 2006 at 05:55:19PM +0000, David Woodhouse wrote: > On Wed, 2006-12-20 at 11:51 -0600, Tom 'spot' Callaway wrote: > > Personally, I'm voting for "don't bother". > > > > This is a bad idea. We're encouraging fragmentation, and discouraging > > the proper upstream path. > > Absolutely. +1 > > If specific open source groups want to do > > pre-upstream testing of kernel packages, let them make their own > > unofficial repos. We'll link to them in our wiki. > > If we must. I think it's better to stick to "if it isn't upstream, it > doesn't exist" though. +1 > We should make it clear we don't want _any_ kmod packages in the new > combined Core+Extras too. Um, no. We've been over this before. Changing the location of code in a SCM doesn't change any of the previous discussions. I don't particularly like it, but *shrug*. josh From jwboyer at jdub.homelinux.org Sat Dec 23 16:17:07 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 23 Dec 2006 10:17:07 -0600 Subject: What do we want to archive with Fedora? In-Reply-To: <458AC99C.9030807@leemhuis.info> References: <458A2EA9.8050508@leemhuis.info> <20061221165606.GC24540@nostromo.devel.redhat.com> <458AC99C.9030807@leemhuis.info> Message-ID: <20061223161707.GB14996@yoda.jdub.homelinux.org> On Thu, Dec 21, 2006 at 06:51:24PM +0100, Thorsten Leemhuis wrote: > Bill Nottingham schrieb: > > (*) I'm not against having kmod packages in Extras, but I think we > > need to warn prospective users about what they're getting into. > > I more and more tend to think we should move the kmods and the kernels > into some seperate add-on-repo. With not that much arm twisting I would probably agree with this. I'd want to see the details first. josh From tibbs at math.uh.edu Sat Dec 23 18:56:07 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 23 Dec 2006 12:56:07 -0600 Subject: What do we want to archive with Fedora? In-Reply-To: <458AC99C.9030807@leemhuis.info> References: <458A2EA9.8050508@leemhuis.info> <20061221165606.GC24540@nostromo.devel.redhat.com> <458AC99C.9030807@leemhuis.info> Message-ID: >>>>> "TL" == Thorsten Leemhuis writes: TL> I more and more tend to think we should move the kmods and the TL> kernels into some seperate add-on-repo. If they're successfully banned from the merged Core+Extras, that's what will happen anyway. It still won't help the kernel developers; their problems will persist as long as anyone loads any module not in the base kernel RPM. BTW, to touch on a topic from the last FESCo meeting, this would be an example where it could be considered reasonable for a package to add a repository. - J< From sundaram at fedoraproject.org Sat Dec 23 18:56:09 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 24 Dec 2006 00:26:09 +0530 Subject: What do we want to archive with Fedora? In-Reply-To: References: <458A2EA9.8050508@leemhuis.info> <20061221165606.GC24540@nostromo.devel.redhat.com> <458AC99C.9030807@leemhuis.info> Message-ID: <458D7BC9.7050106@fedoraproject.org> Jason L Tibbitts III wrote: >>>>>> "TL" == Thorsten Leemhuis writes: > > TL> I more and more tend to think we should move the kmods and the > TL> kernels into some seperate add-on-repo. > > If they're successfully banned from the merged Core+Extras, that's > what will happen anyway. It still won't help the kernel developers; > their problems will persist as long as anyone loads any module not in > the base kernel RPM. > > BTW, to touch on a topic from the last FESCo meeting, this would be an > example where it could be considered reasonable for a package to add a > repository. The potential legal liability issues with doing so is a blocker to this. We dont the resources to cross check every now and then. Rahul From max at spevack.org Sat Dec 23 19:29:07 2006 From: max at spevack.org (Max Spevack) Date: Sat, 23 Dec 2006 14:29:07 -0500 (EST) Subject: happy holidays fedora Message-ID: Well, Davidz's LiveCD announcement is a perfect present for Fedora as the holiday season kicks into gear. I know we're a worldwide group, but a lot of Fedora folks are going to be taking some vacation in the coming week or so. Just thought I'd send a quick email thanking everyone for all the hard work and leadership that you've given Fedora in the past year. We've gotten a lot of good work done, and I think that as a group Fedora continues to accomplish its goals the "right way". So thank you all for your contributions and efforts. They are incredibly valued and appreciated. --Max -- Max Spevack + http://spevack.org + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From tibbs at math.uh.edu Sat Dec 23 19:50:13 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 23 Dec 2006 13:50:13 -0600 Subject: What do we want to archive with Fedora? In-Reply-To: <458D7BC9.7050106@fedoraproject.org> References: <458A2EA9.8050508@leemhuis.info> <20061221165606.GC24540@nostromo.devel.redhat.com> <458AC99C.9030807@leemhuis.info> <458D7BC9.7050106@fedoraproject.org> Message-ID: >>>>> "RS" == Rahul Sundaram writes: RS> The potential legal liability issues with doing so is a blocker to RS> this. We dont the resources to cross check every now and then. I suppose you are making the assumption that said repository would be outside the project. I suppose I can't blame you for making that assumption, but I will, however, respectfully request that you not put words in my mouth, as that assumption was neither implicit nor explicit in what I wrote and I did not see that assumption in what Thorsten wrote, either. - J< From sundaram at fedoraproject.org Sat Dec 23 19:53:03 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 24 Dec 2006 01:23:03 +0530 Subject: What do we want to archive with Fedora? In-Reply-To: References: <458A2EA9.8050508@leemhuis.info> <20061221165606.GC24540@nostromo.devel.redhat.com> <458AC99C.9030807@leemhuis.info> <458D7BC9.7050106@fedoraproject.org> Message-ID: <458D891F.6080107@fedoraproject.org> Jason L Tibbitts III wrote: >>>>>> "RS" == Rahul Sundaram writes: > > RS> The potential legal liability issues with doing so is a blocker to > RS> this. We dont the resources to cross check every now and then. > > I suppose you are making the assumption that said repository would be > outside the project. I suppose I can't blame you for making that > assumption, but I will, however, respectfully request that you not put > words in my mouth, as that assumption was neither implicit nor > explicit in what I wrote and I did not see that assumption in what > Thorsten wrote, either. Thorsten's idea of a add on repository within the project was clear to me. However letting other packages (besides fedora-release) add additional repositories looks entirely different. Why would you want to ever allow that? Rahul From tibbs at math.uh.edu Sat Dec 23 20:45:53 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 23 Dec 2006 14:45:53 -0600 Subject: What do we want to archive with Fedora? In-Reply-To: <458D891F.6080107@fedoraproject.org> References: <458A2EA9.8050508@leemhuis.info> <20061221165606.GC24540@nostromo.devel.redhat.com> <458AC99C.9030807@leemhuis.info> <458D7BC9.7050106@fedoraproject.org> <458D891F.6080107@fedoraproject.org> Message-ID: >>>>> "RS" == Rahul Sundaram writes: RS> Thorsten's idea of a add on repository within the project was RS> clear to me. However letting other packages (besides RS> fedora-release) add additional repositories looks entirely RS> different. Why would you want to ever allow that? Firstly, I'll point out that my phrasing was carefully chosen: "this would be an example where it could be considered reasonable for a package to add a repository." Note that "it could be considered reasonable" implies very little about my opinion; I'm just trying to bring up points for discussion. However, let me lay out an example: We put kernel modules in an separate repository internal to the project (so there are no legal issues here to worry about). We want to make the repository available, but not enabled or even installed by default. There are a few choices: 1) Require that users manually add a file to /etc/yum.repos.d. 2) Require that users fetch a package from the web to add the repository: rpm -ivh http://whatever 3) Put the repository definition in a package in the Fedora repository, so that it can be installed with yum. Note that only #3 gets the repository installed and manageable through our package system with all of the security guarantees that a package signed with the Fedora keys gives. I suppose it's possible that the package in #2 could be signed with the Fedora key, or that the key could be imported via some other method, but then my understanding is that rpm doesn't check keys at install time. Perhaps the procedure could be complicated a bit to give the benefits of proper key retrieval; I'm not sure. Now, what's the difference between putting the repository in the fedora-release package and putting it in this mythical other package? Well, it's another layer of stuff the user has to do in order to get that repository on the system, which could potentially alleviate some of the concerns of the people who don't want modules at all. In that package you could do additional things like, say, add some boot messages or some display on the GDM login screen indicating that the unsupported module repository was enabled. Let your imagination run wild. - J< From sundaram at fedoraproject.org Mon Dec 25 00:44:56 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 25 Dec 2006 06:14:56 +0530 Subject: What do we want to archive with Fedora? In-Reply-To: References: <458A2EA9.8050508@leemhuis.info> <20061221165606.GC24540@nostromo.devel.redhat.com> <458AC99C.9030807@leemhuis.info> <458D7BC9.7050106@fedoraproject.org> <458D891F.6080107@fedoraproject.org> Message-ID: <458F1F08.3050606@fedoraproject.org> Jason L Tibbitts III wrote: > Now, what's the difference between putting the repository in the > fedora-release package and putting it in this mythical other package? Control. If random packages start adding repositories on their own, we wouldnt be able to do control their outcome. Rahul From tibbs at math.uh.edu Mon Dec 25 18:36:59 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 25 Dec 2006 12:36:59 -0600 Subject: What do we want to archive with Fedora? In-Reply-To: <458F1F08.3050606@fedoraproject.org> References: <458A2EA9.8050508@leemhuis.info> <20061221165606.GC24540@nostromo.devel.redhat.com> <458AC99C.9030807@leemhuis.info> <458D7BC9.7050106@fedoraproject.org> <458D891F.6080107@fedoraproject.org> <458F1F08.3050606@fedoraproject.org> Message-ID: >>>>> "RS" == Rahul Sundaram writes: RS> Control. If random packages start adding repositories on their RS> own, we wouldnt be able to do control their outcome. Has anyone proposed or advocated "random packages" adding repositories? It's just incredibly difficult to have any reasonable discussion with someone who extracts one sentence from a carefully-written message, infers some meaning that was not in the original, and then uses that as a counter-argument to the entire subject under discussion. But I suppose it's worked, because I give up. - J< From sundaram at fedoraproject.org Tue Dec 26 05:31:41 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 26 Dec 2006 11:01:41 +0530 Subject: What do we want to archive with Fedora? In-Reply-To: References: <458A2EA9.8050508@leemhuis.info> <20061221165606.GC24540@nostromo.devel.redhat.com> <458AC99C.9030807@leemhuis.info> <458D7BC9.7050106@fedoraproject.org> <458D891F.6080107@fedoraproject.org> <458F1F08.3050606@fedoraproject.org> Message-ID: <4590B3BD.1040209@fedoraproject.org> Jason L Tibbitts III wrote: >>>>>> "RS" == Rahul Sundaram writes: > > RS> Control. If random packages start adding repositories on their > RS> own, we wouldnt be able to do control their outcome. > > Has anyone proposed or advocated "random packages" adding > repositories? What *exactly* are you proposing then? Do explain rather than spend time in rhetoric questions. Rahul From fedora at leemhuis.info Tue Dec 26 11:23:15 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 26 Dec 2006 12:23:15 +0100 Subject: What do we want to archive with Fedora? In-Reply-To: References: <458A2EA9.8050508@leemhuis.info> <20061221165606.GC24540@nostromo.devel.redhat.com> <458AC99C.9030807@leemhuis.info> <458D7BC9.7050106@fedoraproject.org> <458D891F.6080107@fedoraproject.org> <458F1F08.3050606@fedoraproject.org> Message-ID: <45910623.2050609@leemhuis.info> Jason L Tibbitts III schrieb: >>>>>> "RS" == Rahul Sundaram writes: > RS> Control. If random packages start adding repositories on their > RS> own, we wouldnt be able to do control their outcome. > Has anyone proposed or advocated "random packages" adding > repositories? > It's just incredibly difficult to have any reasonable discussion with > someone who extracts one sentence from a carefully-written message, > infers some meaning that was not in the original, and then uses that > as a counter-argument to the entire subject under discussion. > But I suppose it's worked, because I give up. I more and more get the feeling that this mailing list sometimes does not work really well(?). Seems especially community members seem to get frustrated by the discussions here afaics and thus don't participate anymore (?). Maybe it's in parts the usual "discussions on mailing lists don't work to well" problem, but it seems it's way more problematic on this list -- this sub-thread is a good example. Tibbs description above matches it quite well. I'd even take it one step further: "It's just incredibly difficult to have any reasonable discussion on FAB if people extract some parts (that are often not that important details or only slightly related to the whole thing) from a carefully-written message, forcing the initial poster into a endless discussions around it, while the initial topic and the problem that lies behind it gets forgotten or ignored totally." We need to change something. But I don't know exactly what to change. CU thl (?) -- okay, yes, sometimes it works and is productive, but often it feels like wasted time (?) -- leaving the problem aside that certain important community contributors think they cannot even post to the list because they were not invited; I thus dislike the FAB-list more and more and think we should have 95% of the discussions we had here in the past on a open fedora-project-list in the future where everyone gets allowed to subscribe and post. If that becomes a problem over time due to to much noise let only contributors (cla_done) subscribe there and create a fedora-project-list-readonly for the rest of the world; members of the latter should still be able to post to the mailinglist if a moderator acks their post. From max at spevack.org Thu Dec 28 19:03:48 2006 From: max at spevack.org (Max Spevack) Date: Thu, 28 Dec 2006 14:03:48 -0500 (EST) Subject: What do we want to archive with Fedora? In-Reply-To: <45910623.2050609@leemhuis.info> References: <458A2EA9.8050508@leemhuis.info> <20061221165606.GC24540@nostromo.devel.redhat.com> <458AC99C.9030807@leemhuis.info> <458D7BC9.7050106@fedoraproject.org> <458D891F.6080107@fedoraproject.org> <458F1F08.3050606@fedoraproject.org> <45910623.2050609@leemhuis.info> Message-ID: On Tue, 26 Dec 2006, Thorsten Leemhuis wrote: > leaving the problem aside that certain important community contributors > think they cannot even post to the list because they were not invited; I > thus dislike the FAB-list more and more and think we should have 95% of > the discussions we had here in the past on a open fedora-project-list in > the future where everyone gets allowed to subscribe and post. If that > becomes a problem over time due to to much noise let only contributors > (cla_done) subscribe there and create a fedora-project-list-readonly for > the rest of the world; members of the latter should still be able to > post to the mailinglist if a moderator acks their post. Thorsten, I think this part of your note is easily remedied. I have no problem with: 1) changing FAB to open subscription with confirmation 2) putting the current "read only" folks onto the full list, since (1) obviates the need for f-a-b-readonly 3) re-messaging the purpose of FAB, and also the new subscription policy The people who are most active on the list will still be, and it will likely get some other good people talking. I'll make these changes once I'm back to Raleigh, and we'll see how it goes. Hope everyone has a happy new year. -- Max Spevack + http://spevack.org + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From fedora at leemhuis.info Sat Dec 30 12:45:00 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 30 Dec 2006 13:45:00 +0100 Subject: What do we want to archive with Fedora? In-Reply-To: References: <458A2EA9.8050508@leemhuis.info> <20061221165606.GC24540@nostromo.devel.redhat.com> <458AC99C.9030807@leemhuis.info> <458D7BC9.7050106@fedoraproject.org> <458D891F.6080107@fedoraproject.org> <458F1F08.3050606@fedoraproject.org> <45910623.2050609@leemhuis.info> Message-ID: <45965F4C.1060504@leemhuis.info> Max Spevack schrieb: > On Tue, 26 Dec 2006, Thorsten Leemhuis wrote: >> leaving the problem aside that certain important community contributors >> think they cannot even post to the list because they were not invited; I >> thus dislike the FAB-list more and more and think we should have 95% of >> the discussions we had here in the past on a open fedora-project-list in >> the future where everyone gets allowed to subscribe and post. If that >> becomes a problem over time due to to much noise let only contributors >> (cla_done) subscribe there and create a fedora-project-list-readonly for >> the rest of the world; members of the latter should still be able to >> post to the mailinglist if a moderator acks their post. > [...] > I have no problem with: > 1) changing FAB to open subscription with confirmation > 2) putting the current "read only" folks onto the full list, since (1) > obviates the need for f-a-b-readonly > 3) re-messaging the purpose of FAB, and also the new subscription policy > The people who are most active on the list will still be, and it will > likely get some other good people talking. Well, in that case I think then we should rename fab to "fedora-project-list" to make it really obvious "this is the list where the project in general and its goals are being discussed". Alternative would be to create the fedora-project-list and discuss 90% of the things we discussed here until now on that list in the future. Then we could still use FAB for what it was planed for when it got created: discussions between the Fedora Project Boards and the leaders or important contributors from Extras, Ambassadors, Infrastructure... The question is: do we really need such a list? Happy new year everyone. CU thl