From nman64 at n-man.com Fri Sep 1 04:19:30 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Thu, 31 Aug 2006 23:19:30 -0500 Subject: [fab] db4o and Fedora Core In-Reply-To: <1156863130.2548.19.camel@erato.phig.org> References: <20060828162957.GA7767@nostromo.devel.redhat.com> <1156863130.2548.19.camel@erato.phig.org> Message-ID: <200608312319.34033.nman64@n-man.com> On Tuesday 29 August 2006 09:52, Karsten Wade wrote: > On Mon, 2006-08-28 at 12:29 -0400, Bill Nottingham wrote: > > Max Spevack (mspevack at redhat.com) said: > > > Fedora Advisory Folks, > > > > > > This has been on my plate for a while, and it just slipped through the > > > cracks a bit. Dragging it back up. Please comment as needed. > > > > If it's in an official Fedora repository (Core, Extras), I don't see why > > it couldn't be announced, although I don't think we want to make a habit > > of expecting the board/project leads to do the announcing - it's up to > > the maintainer. > > In general, sure. But I think there is room for project leaders to do > such announcements. For the Board, it should be something very > noteworthy or extraordinary. > I agree. We don't need to make a habit out of announcements as large as when Mono was added. That was a special circumstance due to the long background. Individual common packages do not need such fanfare, and trying to give it to them would wear out the value of special announcements. I generally think the best kind of announcement is one made by the maintainer on fedora-list or similar public forums. If the package is of special interest to a Fedora project or SIG, then the appropriate lead or committee could see to a larger announcement. I don't think we need to add a regular burden of the sort to the Board, though, as it isn't necessary and could detract from other important duties. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- 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 Fri Sep 1 18:22:55 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 1 Sep 2006 14:22:55 -0400 Subject: [fab] [Fwd: cdrtools/cdrecord] In-Reply-To: <44F6C337.3000908@fedoraproject.org> References: <44F6C337.3000908@fedoraproject.org> Message-ID: <20060901182255.GH13335@nostromo.devel.redhat.com> Rahul (sundaram at fedoraproject.org) said: ... At this point, I suspect that since we have the license issues resolved, where to go from here is an issue for the package maintainers, not the board. Bill From blizzard at redhat.com Fri Sep 1 19:31:31 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 01 Sep 2006 15:31:31 -0400 Subject: [fab] Re: kernel modules in fedora In-Reply-To: <44F72561.4040603@redhat.com> References: <44F72561.4040603@redhat.com> Message-ID: <44F88A93.8060404@redhat.com> Tim Burke wrote: >> Fair enough, Jesse. Let me rephrase -- whatever else we do or don't >> do, we need to enable people to do cool stuff with Fedora, not be an >> impediment to them doing it. >> >> Insert all the "as long as it's FOSS, etc." stuff here. >> >> I think there needs to be a place for kernel modules somewhere in the >> "Fedora Universe", that's all I'm saying. >> > The first step is ensuring that the mechanisms are in place to allow > others in the Fedora universe to build, deliver and hook in their > modules. This is what Jon Masters has been providing support for. We > don't need to actually deliver kernel modules ourselves this way, but > neither should we preclude others from doing so. Is Jon's work documented anywhere? --Chris From sundaram at fedoraproject.org Fri Sep 1 19:36:27 2006 From: sundaram at fedoraproject.org (Rahul) Date: Sat, 02 Sep 2006 01:06:27 +0530 Subject: [fab] Re: kernel modules in fedora In-Reply-To: <44F88A93.8060404@redhat.com> References: <44F72561.4040603@redhat.com> <44F88A93.8060404@redhat.com> Message-ID: <44F88BBB.1050600@fedoraproject.org> Christopher Blizzard wrote: > Tim Burke wrote: >>> Fair enough, Jesse. Let me rephrase -- whatever else we do or don't >>> do, we need to enable people to do cool stuff with Fedora, not be an >>> impediment to them doing it. >>> >>> Insert all the "as long as it's FOSS, etc." stuff here. >>> >>> I think there needs to be a place for kernel modules somewhere in the >>> "Fedora Universe", that's all I'm saying. >>> >> The first step is ensuring that the mechanisms are in place to allow >> others in the Fedora universe to build, deliver and hook in their >> modules. This is what Jon Masters has been providing support for. We >> don't need to actually deliver kernel modules ourselves this way, but >> neither should we preclude others from doing so. > > Is Jon's work documented anywhere? > > --Chris > http://www.kerneldrivers.org/ Rahul From bryanlivingston at gmail.com Sat Sep 2 20:43:23 2006 From: bryanlivingston at gmail.com (Bryan Livingston) Date: Sat, 2 Sep 2006 14:43:23 -0600 Subject: [fab] Modern File Heirarchy Message-ID: Do away with the standard unix directory heirarchy. It's archaic, non-intuitive, non-internationalized and dangerous from an application management perspective. This would be a massive change to the entire system, primarily consisting of creating some standard env variables that point to standard directories. Also a switch to application directories would be done. A linux distribution has been built around this idea and has been successfull at working out the technical details. It's called GoboLinux and you can find out more about it here: http://www.gobolinux.org/?page=at_a_glance They have a piece on common conserns about the idea here: http://www.gobolinux.org/index.php?page=doc/articles/clueless This would take big steps in both usability and internationalization, which are both top goals for Fedora. I'm hoping that the Fedora leadership is serious enough about pushing the state of the technology that they will seriously consider such an idea. It will have to happen eventually in my opinion. This is done on the windows world, and is one aspact that makes windows easier to use and more flexible than Fedora. There are 12 env variables on my win xp system that point to directories for various things. -- Bryan Livingston From mattdm at mattdm.org Sat Sep 2 22:20:47 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 2 Sep 2006 18:20:47 -0400 Subject: [fab] Re: Modern File Heirarchy In-Reply-To: References: Message-ID: <20060902222047.GA12498@jadzia.bu.edu> On Sat, Sep 02, 2006 at 02:43:23PM -0600, Bryan Livingston wrote: > Do away with the standard unix directory heirarchy. It's archaic, > non-intuitive, non-internationalized and dangerous from an application > management perspective. No filesystem hierarchy is intuitive. Therefore, until we've got a solution for that, let's not muck around with the perfectly serviceable one we've got. > This is done on the windows world, and is one aspact that makes > windows easier to use and more flexible than Fedora. There are 12 env Actually, it's one of the things that makes Windows a management and security nightmare. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From bryanlivingston at gmail.com Sun Sep 3 00:32:40 2006 From: bryanlivingston at gmail.com (Bryan Livingston) Date: Sat, 2 Sep 2006 18:32:40 -0600 Subject: [fab] Fwd: Modern File Heirarchy In-Reply-To: References: <20060902222047.GA12498@jadzia.bu.edu> Message-ID: ---------- Forwarded message ---------- From: Bryan Livingston Date: Sep 2, 2006 6:28 PM Subject: Re: Modern File Heirarchy To: Discussions about development for the Fedora desktop On 9/2/06, Matthew Miller wrote: > On Sat, Sep 02, 2006 at 02:43:23PM -0600, Bryan Livingston wrote: > > Do away with the standard unix directory heirarchy. It's archaic, > > non-intuitive, non-internationalized and dangerous from an application > > management perspective. > > No filesystem hierarchy is intuitive. Therefore, until we've got a solution > for that, let's not muck around with the perfectly serviceable one we've > got. Directories named with plain english words are easier to understand than things like /etc and /usr. Do you not see that? > > This is done on the windows world, and is one aspact that makes > > windows easier to use and more flexible than Fedora. There are 12 env > > Actually, it's one of the things that makes Windows a management and > security nightmare. I don't see how that is. Having the system directory change from c:\winnt to c:\windows never cost me a single bit of grief, while it did allow for side by side installs. I realize that this idea is pretty drastic and don't expect you to like the idea at first glance. All I'm asking is that you give it some serious thought rather than shoot it down out of arrogance. Bryan -- Bryan Livingston From tiemann at redhat.com Wed Sep 6 20:32:39 2006 From: tiemann at redhat.com (Michael Tiemann) Date: Wed, 06 Sep 2006 16:32:39 -0400 Subject: [fab] Fwd: Modern File Heirarchy In-Reply-To: References: <20060902222047.GA12498@jadzia.bu.edu> Message-ID: <1157574759.4087.85.camel@localhost.localdomain> > Directories named with plain english words are easier to understand As a person who travels the world (and posting from Tokyo right now), let me assure you that there is no such thing as "plain English". M From tiemann at redhat.com Wed Sep 6 20:32:39 2006 From: tiemann at redhat.com (Michael Tiemann) Date: Wed, 06 Sep 2006 16:32:39 -0400 Subject: [fab] Fwd: Modern File Heirarchy In-Reply-To: References: <20060902222047.GA12498@jadzia.bu.edu> Message-ID: <1157574759.4087.85.camel@localhost.localdomain> > Directories named with plain english words are easier to understand As a person who travels the world (and posting from Tokyo right now), let me assure you that there is no such thing as "plain English". M From notting at redhat.com Wed Sep 6 20:40:02 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 6 Sep 2006 16:40:02 -0400 Subject: [fab] Modern File Heirarchy In-Reply-To: References: Message-ID: <20060906204002.GA3243@nostromo.devel.redhat.com> Bryan Livingston (bryanlivingston at gmail.com) said: > Do away with the standard unix directory heirarchy. It's archaic, > non-intuitive, non-internationalized and dangerous from an application > management perspective. OK, why is this *AT ALL* appropriate for the board - what's your purpose here? If you can't convince the project itself, why are you bringing this to an administrative entity? Bill From notting at redhat.com Wed Sep 6 20:40:02 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 6 Sep 2006 16:40:02 -0400 Subject: [fab] Modern File Heirarchy In-Reply-To: References: Message-ID: <20060906204002.GA3243@nostromo.devel.redhat.com> Bryan Livingston (bryanlivingston at gmail.com) said: > Do away with the standard unix directory heirarchy. It's archaic, > non-intuitive, non-internationalized and dangerous from an application > management perspective. OK, why is this *AT ALL* appropriate for the board - what's your purpose here? If you can't convince the project itself, why are you bringing this to an administrative entity? Bill From mmcgrath at fedoraproject.org Wed Sep 6 20:42:54 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 6 Sep 2006 15:42:54 -0500 Subject: [fab] Modern File Heirarchy In-Reply-To: References: Message-ID: <3237e4410609061342g500750d0jbd91689cfa652a62@mail.gmail.com> On 9/2/06, Bryan Livingston wrote: > This is done on the windows world, and is one aspact that makes > windows easier to use and more flexible than Fedora. There are 12 env > variables on my win xp system that point to directories for various > things. I personally like FHS, I find it useful and well thought out and while it takes thought and understanding to use, it is quite flexable. -Mike From mmcgrath at fedoraproject.org Wed Sep 6 20:42:54 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 6 Sep 2006 15:42:54 -0500 Subject: [fab] Modern File Heirarchy In-Reply-To: References: Message-ID: <3237e4410609061342g500750d0jbd91689cfa652a62@mail.gmail.com> On 9/2/06, Bryan Livingston wrote: > This is done on the windows world, and is one aspact that makes > windows easier to use and more flexible than Fedora. There are 12 env > variables on my win xp system that point to directories for various > things. I personally like FHS, I find it useful and well thought out and while it takes thought and understanding to use, it is quite flexable. -Mike From sundaram at fedoraproject.org Wed Sep 6 21:38:04 2006 From: sundaram at fedoraproject.org (Rahul) Date: Thu, 07 Sep 2006 03:08:04 +0530 Subject: [fab] Modern File Heirarchy In-Reply-To: <20060906204002.GA3243@nostromo.devel.redhat.com> References: <20060906204002.GA3243@nostromo.devel.redhat.com> Message-ID: <44FF3FBC.1040406@fedoraproject.org> Bill Nottingham wrote: > Bryan Livingston (bryanlivingston at gmail.com) said: >> Do away with the standard unix directory heirarchy. It's archaic, >> non-intuitive, non-internationalized and dangerous from an application >> management perspective. > > OK, why is this *AT ALL* appropriate for the board - what's your > purpose here? > > If you can't convince the project itself, why are you bringing > this to an administrative entity? > > Bill I think people quite often confuse Fedora Project Board to be a technical decisions team (which I think should be formed by merging FESCo and people from Fedora Core) rather than a administrative team which is partially our fault since we dont have any documents explaining our governance mode, policy and relationship of different teams such as the board and the steering committees. I will get to doing that soon. Rahul From sundaram at fedoraproject.org Wed Sep 6 21:38:04 2006 From: sundaram at fedoraproject.org (Rahul) Date: Thu, 07 Sep 2006 03:08:04 +0530 Subject: [fab] Modern File Heirarchy In-Reply-To: <20060906204002.GA3243@nostromo.devel.redhat.com> References: <20060906204002.GA3243@nostromo.devel.redhat.com> Message-ID: <44FF3FBC.1040406@fedoraproject.org> Bill Nottingham wrote: > Bryan Livingston (bryanlivingston at gmail.com) said: >> Do away with the standard unix directory heirarchy. It's archaic, >> non-intuitive, non-internationalized and dangerous from an application >> management perspective. > > OK, why is this *AT ALL* appropriate for the board - what's your > purpose here? > > If you can't convince the project itself, why are you bringing > this to an administrative entity? > > Bill I think people quite often confuse Fedora Project Board to be a technical decisions team (which I think should be formed by merging FESCo and people from Fedora Core) rather than a administrative team which is partially our fault since we dont have any documents explaining our governance mode, policy and relationship of different teams such as the board and the steering committees. I will get to doing that soon. Rahul From nman64 at n-man.com Thu Sep 7 03:37:04 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Wed, 6 Sep 2006 22:37:04 -0500 Subject: [fab] Fwd: Re: [Fedora-sysadmin-list] ssl cert for admin.fedora.redhat.com Message-ID: <200609062237.08445.nman64@n-man.com> Even if we try to hold off for now, we're eventually going to need certificates for fedoraproject.org, preferably by a CA that is already recognized by the more common browsers. I would personally like to see us get a certificate for "fedoraproject.org" (no subdomain), make "www.fedoraproject.org" a CNAME to "fedoraproject.org", and put all content that we need under SSL within the "https://fedoraproject.org/" namespace, using reverse proxies if necessary, and not on subdomains. People with a great deal of experience with DNS and SSL should understand my technical reasons for this, but it's also the cheaper way to go. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- An embedded message was scrubbed... From: Warren Togami Subject: Re: [Fedora-sysadmin-list] ssl cert for admin.fedora.redhat.com Date: Mon, 28 Aug 2006 13:08:07 -0400 Size: 5234 URL: -------------- 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 Thu Sep 7 07:15:23 2006 From: kwade at redhat.com (Karsten Wade) Date: Thu, 07 Sep 2006 00:15:23 -0700 Subject: [fab] Re: openmotif In-Reply-To: <20060831070128.GC2455@free.fr> References: <20060818090009.GA3558@dudweiler.stuttgart.redhat.com> <44F59405.9020805@redhat.com> <44F59529.70009@math.unl.edu> <200608300950.40630.jkeating@redhat.com> <1156952977.32717.181.camel@dhcp-32-122.ord.redhat.com> <1156969116.32717.230.camel@dhcp-32-122.ord.redhat.com> <20060830214557.GB12462@free.fr> <1156975013.32717.315.camel@dhcp-32-122.ord.redhat.com> <20060831070128.GC2455@free.fr> Message-ID: <1157613323.7220.145.camel@erato.phig.org> On Thu, 2006-08-31 at 09:01 +0200, Patrice Dumas wrote: > It should be announced in the release notes and wherever possible that it > will disappear soon of course. Go ahead and make the addition; we'll make sure to edit etc. http://fedoraproject.org/wiki/Docs/Beats - 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 mmcgrath at fedoraproject.org Thu Sep 7 13:12:34 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 7 Sep 2006 08:12:34 -0500 Subject: [fab] Fwd: Re: [Fedora-sysadmin-list] ssl cert for admin.fedora.redhat.com In-Reply-To: <200609062237.08445.nman64@n-man.com> References: <200609062237.08445.nman64@n-man.com> Message-ID: <3237e4410609070612n7d88bbe1wa8ae6d72dd723dee@mail.gmail.com> On 9/6/06, Patrick W. Barnes wrote: > Even if we try to hold off for now, we're eventually going to need > certificates for fedoraproject.org, preferably by a CA that is already > recognized by the more common browsers. > > I would personally like to see us get a certificate for "fedoraproject.org" > (no subdomain), make "www.fedoraproject.org" a CNAME to "fedoraproject.org", > and put all content that we need under SSL within > the "https://fedoraproject.org/" namespace, using reverse proxies if > necessary, and not on subdomains. People with a great deal of experience > with DNS and SSL should understand my technical reasons for this, but it's > also the cheaper way to go. > > -- > Patrick "The N-Man" Barnes > nman64 at n-man.com > IIRC we were working to do this but we were going to try to use some service like cacert.org instead of a verisign. Personally I don't care what we use but from a technical point of view we can get this up and running as soon as we get the cert. -Mike From mspevack at redhat.com Tue Sep 19 13:52:35 2006 From: mspevack at redhat.com (Max Spevack) Date: Tue, 19 Sep 2006 09:52:35 -0400 (EDT) Subject: [fab] fedora board agenda for today Message-ID: So this list has been very slow lately -- everyone has had their head down in FC6 work, myself included. And a lot of good work is being done. I run rawhide on my laptop, and by and large I think it's very good. But I hope to pick things up a bit today in terms of this list, as we have a Fedora Board meeting. Among the topics that I'd like to discuss: 1) Are we finally done with the list of "official" Projects and Incubators/SIGs? Once so, I also think we need to look at which ones do a good job of being accountable and transparent, and which do not. And work to improve. 2) I'd like to talk with the Board about the status of LiveCD, where we are blocking, where we are in good shape, etc. 3) FC6 status, and some concerns that I have about bug fixes. 4) Upcoming events, focusing particularly on development and engineering. Would like to make sure I have the Board's buy-in. 5) Quick updates/discussion on different projects. Docs, Extras, Legacy, etc. Any other topics that the Board or f-a-b would like to present. Dial in info has been sent to the FPB members privately. --Max -- 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 chitlesh at fedoraproject.org Tue Sep 19 14:09:56 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 19 Sep 2006 16:09:56 +0200 Subject: [fab] fedora board agenda for today In-Reply-To: References: Message-ID: <13dbfe4f0609190709y6fe7ea53y10a10d8e874c2cfd@mail.gmail.com> On 9/19/06, Max Spevack wrote: > 2) I'd like to talk with the Board about the status of LiveCD, where we > are blocking, where we are in good shape, etc. I would like to know more about it :) Fedora Unity did a fairly great job in distributing the livecd built with kadischi! I haven't heard much from Jeremy's involvement since we discussed about it, or is there something I missed ? Greg was working *right now* to get 64 bit hardware, any updates ? Recently, we added grub support on kadischi, and hence kadischi might create ppc livecds, but both JasperHartline and I are uncertain since we both don't have materials to test on and do research on. Right now, I'm working on a GUI for kadischi, perhaps more testers and contributors might be interested to help on. > 3) FC6 status, and some concerns that I have about bug fixes. I want to point out to KDE !! Has anyone looked at it on a Fedora KDE Default install ? Quite scary, huh ? I think it's time to change the old bluecurve style and add a new cool theme ! -- http://clunixchit.blogspot.com From tcallawa at redhat.com Tue Sep 19 14:32:34 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 19 Sep 2006 09:32:34 -0500 Subject: [fab] fedora board agenda for today In-Reply-To: References: Message-ID: <1158676354.6156.6.camel@localhost.localdomain> On Tue, 2006-09-19 at 09:52 -0400, Max Spevack wrote: > So this list has been very slow lately -- everyone has had their head down > in FC6 work, myself included. And a lot of good work is being done. I > run rawhide on my laptop, and by and large I think it's very good. > > But I hope to pick things up a bit today in terms of this list, as we have > a Fedora Board meeting. Max, several items that I'm still waiting on from the board: - NTFS kernel module enablement (OIN covers us here, lets just turn the damned thing on and shut everyone up) - kernel modules outside of the kernel package in Fedora. Vote yes or no so we can move on. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From jwboyer at jdub.homelinux.org Tue Sep 19 15:34:38 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 19 Sep 2006 10:34:38 -0500 Subject: [fab] fedora board agenda for today In-Reply-To: <1158676354.6156.6.camel@localhost.localdomain> References: <1158676354.6156.6.camel@localhost.localdomain> Message-ID: <1158680078.3121.2.camel@zod.rchland.ibm.com> On Tue, 2006-09-19 at 09:32 -0500, Tom 'spot' Callaway wrote: > - kernel modules outside of the kernel package in Fedora. Vote yes or no > so we can move on. This one has been asked about on the list about 4 times now. Would be very good to get an answer. josh From matt at domsch.com Tue Sep 19 16:01:08 2006 From: matt at domsch.com (Matt Domsch) Date: Tue, 19 Sep 2006 11:01:08 -0500 Subject: [fab] fedora board agenda for today In-Reply-To: <1158676354.6156.6.camel@localhost.localdomain> References: <1158676354.6156.6.camel@localhost.localdomain> Message-ID: <20060919160108.GC14504@domsch.com> On Tue, Sep 19, 2006 at 09:32:34AM -0500, Tom 'spot' Callaway wrote: > - kernel modules outside of the kernel package in Fedora. Vote yes or no > so we can move on. FYI, this is the proposal being voted yes/no. http://fedoraproject.org/wiki/Packaging/KernelModules -Matt From sundaram at fedoraproject.org Tue Sep 19 16:03:26 2006 From: sundaram at fedoraproject.org (Rahul) Date: Tue, 19 Sep 2006 21:33:26 +0530 Subject: [fab] fedora board agenda for today In-Reply-To: <20060919160108.GC14504@domsch.com> References: <1158676354.6156.6.camel@localhost.localdomain> <20060919160108.GC14504@domsch.com> Message-ID: <451014CE.5030808@fedoraproject.org> Matt Domsch wrote: > On Tue, Sep 19, 2006 at 09:32:34AM -0500, Tom 'spot' Callaway wrote: >> - kernel modules outside of the kernel package in Fedora. Vote yes or no >> so we can move on. > > FYI, this is the proposal being voted yes/no. > http://fedoraproject.org/wiki/Packaging/KernelModules > IMO, we just need to decide whether to allow modules or not within the board. The exact details and guidelines on how to do them if allowed should be left to FESCo. Rahul From tcallawa at redhat.com Tue Sep 19 16:03:45 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 19 Sep 2006 11:03:45 -0500 Subject: [fab] fedora board agenda for today In-Reply-To: <20060919160108.GC14504@domsch.com> References: <1158676354.6156.6.camel@localhost.localdomain> <20060919160108.GC14504@domsch.com> Message-ID: <1158681825.6156.12.camel@localhost.localdomain> On Tue, 2006-09-19 at 11:01 -0500, Matt Domsch wrote: > On Tue, Sep 19, 2006 at 09:32:34AM -0500, Tom 'spot' Callaway wrote: > > - kernel modules outside of the kernel package in Fedora. Vote yes or no > > so we can move on. > > FYI, this is the proposal being voted yes/no. > http://fedoraproject.org/wiki/Packaging/KernelModules No, actually, it isn't. The Fedora Packaging Committee is very capable of determining how to package kernel modules. ;) The question before the board is simple: Should Fedora include kernel modules outside of the kernel package? If yes, we'll go from there, if no, we'll also go from there. :) ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From sundaram at fedoraproject.org Tue Sep 19 16:06:40 2006 From: sundaram at fedoraproject.org (Rahul) Date: Tue, 19 Sep 2006 21:36:40 +0530 Subject: [fab] fedora board agenda for today In-Reply-To: References: Message-ID: <45101590.9070705@fedoraproject.org> Max Spevack wrote: > So this list has been very slow lately -- everyone has had their head > down in FC6 work, myself included. And a lot of good work is being > done. I run rawhide on my laptop, and by and large I think it's very good. > > But I hope to pick things up a bit today in terms of this list, as we > have a Fedora Board meeting. > > Among the topics that I'd like to discuss: > > 1) Are we finally done with the list of "official" Projects and > Incubators/SIGs? Once so, I also think we need to look at which ones do > a good job of being accountable and transparent, and which do not. And > work to improve. Yes. This is done. http://fedoraproject.org/wiki/Projects http://fedoraproject.org/wiki/SIGs Core as a project is in a pretty weak state compared to others though. There is no weekly meetings or steering committee's for example. > > 2) I'd like to talk with the Board about the status of LiveCD, where we > are blocking, where we are in good shape, etc. > > 3) FC6 status, and some concerns that I have about bug fixes. FC6 test 3 appear broken in several ways. Installer and Xorg related breakages seem rather high in the reports. > > 4) Upcoming events, focusing particularly on development and > engineering. Would like to make sure I have the Board's buy-in. > > 5) Quick updates/discussion on different projects. Docs, Extras, > Legacy, etc. We still need a definite answer from the content services team on RHEL docs relicensing. > > Any other topics that the Board or f-a-b would like to present. NTFS and other FE legal blockers progress. > > Dial in info has been sent to the FPB members privately. > > --Max > Rahul From mspevack at redhat.com Tue Sep 19 19:10:09 2006 From: mspevack at redhat.com (Max Spevack) Date: Tue, 19 Sep 2006 15:10:09 -0400 (EDT) Subject: [fab] kernel modules In-Reply-To: <1158680078.3121.2.camel@zod.rchland.ibm.com> References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> Message-ID: On Tue, 19 Sep 2006, Josh Boyer wrote: > On Tue, 2006-09-19 at 09:32 -0500, Tom 'spot' Callaway wrote: >> - kernel modules outside of the kernel package in Fedora. Vote yes or no >> so we can move on. > > This one has been asked about on the list about 4 times now. Would be > very good to get an answer. The prevailing sentiment is that the engineers most directly impacted by the decision are not in favor of kernel modules, and I think we need to trust the technical expertise of the people who will be doing the work. Therefore, if I had to lay down an opinion, I would say that if Dave Jones (et al) are opposed to kernel modules, then we need to say no. Additionally, if there is a belief that kernel modules would be a Good Thing but we are forced to say no for various reasons (like bug triage as an example) then we need to identify those reasons and act to resolve them, so that we can revisit the issue at a later date, with the answer being "no" until we are ready for it to be "yes". Does that make sense? I'm sure someone out there things I'm wrong. Tell me why, and let's put this issue to bed. --Max From tcallawa at redhat.com Tue Sep 19 19:17:31 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 19 Sep 2006 14:17:31 -0500 Subject: [fab] kernel modules In-Reply-To: References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> Message-ID: <1158693451.6156.22.camel@localhost.localdomain> On Tue, 2006-09-19 at 15:10 -0400, Max Spevack wrote: > On Tue, 19 Sep 2006, Josh Boyer wrote: > > > On Tue, 2006-09-19 at 09:32 -0500, Tom 'spot' Callaway wrote: > >> - kernel modules outside of the kernel package in Fedora. Vote yes or no > >> so we can move on. > > > > This one has been asked about on the list about 4 times now. Would be > > very good to get an answer. > > The prevailing sentiment is that the engineers most directly impacted by > the decision are not in favor of kernel modules, and I think we need to > trust the technical expertise of the people who will be doing the work. > > Therefore, if I had to lay down an opinion, I would say that if Dave Jones > (et al) are opposed to kernel modules, then we need to say no. It's not a matter of opinion. The Fedora Board has some smart technical people. Make a decision and tell us. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From tibbs at math.uh.edu Tue Sep 19 19:18:33 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 19 Sep 2006 14:18:33 -0500 Subject: [fab] kernel modules In-Reply-To: (Max Spevack's message of "Tue, 19 Sep 2006 15:10:09 -0400 (EDT)") References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> Message-ID: >>>>> "MS" == Max Spevack writes: MS> The prevailing sentiment is that the engineers most directly MS> impacted by the decision are not in favor of kernel modules, and I MS> think we need to trust the technical expertise of the people who MS> will be doing the work. While that's true, we have to accept the fact that users will if necessary acquire their kernel modules from somewhere, thus presenting the same problems to the Core kernel developers. The end result is that the user is further inconvenienced and nobody gains anything. (Indeed, the situation could be worse if the source of the modules is less well-maintained than Extras.) - J< From fedora at leemhuis.info Tue Sep 19 19:35:12 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 19 Sep 2006 21:35:12 +0200 Subject: [fab] kernel modules In-Reply-To: References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> Message-ID: <45104670.2030905@leemhuis.info> Max Spevack schrieb: > On Tue, 19 Sep 2006, Josh Boyer wrote: >> On Tue, 2006-09-19 at 09:32 -0500, Tom 'spot' Callaway wrote: >>> - kernel modules outside of the kernel package in Fedora. Vote yes or no >>> so we can move on. >> This one has been asked about on the list about 4 times now. Would be >> very good to get an answer. > The prevailing sentiment is that the engineers most directly impacted by > the decision are not in favor of kernel modules, and I think we need to > trust the technical expertise of the people who will be doing the work. Sorry, but disallowing kmods completely in Extras looks a bit unfair from my point of view: Fedora Extras and especially I invested a lot of work to support kmods in Extras. And before we even started we (jeremy(?)) asked davej (?) if kernel modules are okay for Extras. The answer was yes afaics and we started after that. And now that we have it and now that RHEL has a benefit of it disallow it? I feel like a dump playball now. thx CU thl /me heads off to bed disappointed for today /me should write a more detailed mail on this, but has no time for it now, sorry. From rdieter at math.unl.edu Tue Sep 19 19:36:57 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 19 Sep 2006 14:36:57 -0500 Subject: [fab] kernel modules In-Reply-To: <45104670.2030905@leemhuis.info> References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> <45104670.2030905@leemhuis.info> Message-ID: <451046D9.7080109@math.unl.edu> Thorsten Leemhuis wrote: > > Max Spevack schrieb: >> The prevailing sentiment is that the engineers most directly impacted by >> the decision are not in favor of kernel modules, and I think we need to >> trust the technical expertise of the people who will be doing the work. > > ...disallowing kmods completely in Extras looks a bit unfair > from my point of view: Fedora Extras and especially I invested a lot of > work to support kmods in Extras. I, for one, am 100% *for* allowing kmods. Users absolutely want them, contributors want them (as highlighted by the efforts of many folks including Thorsten). And as pointed out by tibbs, if we (Fedora/Extras) aren't the avenue for folks getting what they want, they'll just turn elsewhere. -- Rex From sundaram at fedoraproject.org Tue Sep 19 19:55:18 2006 From: sundaram at fedoraproject.org (Rahul) Date: Wed, 20 Sep 2006 01:25:18 +0530 Subject: [fab] kernel modules In-Reply-To: References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> Message-ID: <45104B26.8080907@fedoraproject.org> Jason L Tibbitts III wrote: >>>>>> "MS" == Max Spevack writes: > > MS> The prevailing sentiment is that the engineers most directly > MS> impacted by the decision are not in favor of kernel modules, and I > MS> think we need to trust the technical expertise of the people who > MS> will be doing the work. > > While that's true, we have to accept the fact that users will if > necessary acquire their kernel modules from somewhere, thus presenting > the same problems to the Core kernel developers. The end result is > that the user is further inconvenienced and nobody gains anything. > (Indeed, the situation could be worse if the source of the modules is > less well-maintained than Extras.) > > - J< There is certainly a difference between users grabbing packages from third party repositories vs including them in Fedora Extras. If we include anything in the formal Fedora repositories , we need to accept the responsibility to support it properly. If Kernel modules are included in extras, the core kernel team needs to be able to debug any issues and work with them. Though Red Hat has a pretty big kernel team, the number of people who directly deal with kernel bug reports in Fedora is not high. Other than major issues, things are usually fixed by providing an update to the next kernel. Given the fast pace of kernel updates in Fedora Core and the lack of no stable in kernel API/ABI for kernel modules, any extras kernel modules will likely break often. If we are going to hold back changes until we get the kernel modules that we include in Fedora Extras working well with the latest upstream kernel that we intend to provide as a update in Fedora Core, that would very severely restrict or entirely stop us from providing any major kernel updates after a Fedora general release. Dave Jones and others have clearly stated that they have no interest in additional work debugging any issues that might possibly arise from the user using any non-upstream kernel modules even if they are GPL'ed and included in Fedora Extras. Moreover anyone maintaining Fedora Extras So if we do decide to include the modules anyway, we would be left with a situation where Fedora on the whole isnt even willing to support what it provides. On the other hand, if those modules are good enough for the core kernel team to support them, it would make better sense to just include them in the core kernel package instead. Rahul From mspevack at redhat.com Tue Sep 19 19:58:17 2006 From: mspevack at redhat.com (Max Spevack) Date: Tue, 19 Sep 2006 15:58:17 -0400 (EDT) Subject: [fab] kernel modules In-Reply-To: <451046D9.7080109@math.unl.edu> References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> <45104670.2030905@leemhuis.info> <451046D9.7080109@math.unl.edu> Message-ID: On Tue, 19 Sep 2006, Rex Dieter wrote: > Thorsten Leemhuis wrote: >> >> Max Spevack schrieb: > >>> The prevailing sentiment is that the engineers most directly impacted by >>> the decision are not in favor of kernel modules, and I think we need to >>> trust the technical expertise of the people who will be doing the work. >> >> ...disallowing kmods completely in Extras looks a bit unfair >> from my point of view: Fedora Extras and especially I invested a lot of >> work to support kmods in Extras. > > I, for one, am 100% *for* allowing kmods. Users absolutely want them, > contributors want them (as highlighted by the efforts of many folks including > Thorsten). And as pointed out by tibbs, if we (Fedora/Extras) aren't the > avenue for folks getting what they want, they'll just turn elsewhere. Here is my frustration: >From a *philosophical* point of view, I am in favor of kernel modules. >From a *technical* point of view, I hear people tell me a lot of valid reasons why it's a bad idea. I also hear a lot of people say why it's a good idea. People on *both sides* of that argument are very smart. So... if there's smart people on both sides, and compelling arguments on both sides, then I feel like the people who will actually have to do the work should be the ones who tip the scales, since they are the most directly impacted. But, decisions with shades of grey like this are what the Board is meant to handle. And so we shall. Our phone call is in an hour. --Max -- 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 a.badger at gmail.com Tue Sep 19 20:04:28 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 Sep 2006 13:04:28 -0700 Subject: [fab] kernel modules In-Reply-To: References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> Message-ID: <1158696268.2838.38.camel@localhost> On Tue, 2006-09-19 at 15:10 -0400, Max Spevack wrote: > On Tue, 19 Sep 2006, Josh Boyer wrote: > > > On Tue, 2006-09-19 at 09:32 -0500, Tom 'spot' Callaway wrote: > >> - kernel modules outside of the kernel package in Fedora. Vote yes or no > >> so we can move on. > > > > This one has been asked about on the list about 4 times now. Would be > > very good to get an answer. > > The prevailing sentiment is that the engineers most directly impacted by > the decision are not in favor of kernel modules, and I think we need to > trust the technical expertise of the people who will be doing the work. > > Therefore, if I had to lay down an opinion, I would say that if Dave Jones > (et al) are opposed to kernel modules, then we need to say no. > > Additionally, if there is a belief that kernel modules would be a Good > Thing but we are forced to say no for various reasons (like bug triage as > an example) then we need to identify those reasons and act to resolve > them, so that we can revisit the issue at a later date, with the answer > being "no" until we are ready for it to be "yes". > > Does that make sense? I'm sure someone out there things I'm wrong. Tell > me why, and let's put this issue to bed. I think the prevailing sentiment from FESCo would be that kmods should be allowed in some way. The meeting logs with the most relevant comments are here: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060824 The discussion on kmods starts at (10:19:07). Arguments against kmods: * It makes the job of diagnosing kernel bugs harder as there could be extra kmods on top of a stock fedora kernel. * kmods and kernels could go out of sync. Arguments for kmods: * It makes the job of the end-user easier because they need the functionality anyway and will get it from another source if necessary. * It makes the job of the kernel developers easier because they at least know the end-user is using a kmod from fedora-extras (and can ask: "if you rpm -qa |grep kmod does that turn up anything?" whereas a from source kmod would not leave that evidence.) * Fedora is a home for all open source software. Open source kmods are part of that definition. Possible restrictions on kmods: * Statement from upstream about their plans for merging it into the mainstream kernel with evaluation and approval by FESCo. (current process) * Separate but official Fedora repository (proposed by dgilmore) [Note: livna does not satisfy this as 1) livna does not have a config shipped with the OS, 2) our current impression is we can't inform people that livna hosts kmods because of other, legal issues.] * Time limit on kmods to be merged into the mainline kernel or they are removed from the repository (proposed by thl but rejected in the initial kmod proposal as it is bad for end-users) I'm for letting kmods into FE in some form. It will help end-users who have hardware that can benefit from a not-yet-merged driver. We don't have the excuse of it being proprietary software that we can't fix ourselves, can't look at the code to determine what's wrong, or can't get other people in the community to help us deal with. We may need to have restrictions to help the kernel packagers separate issues with the mainline kernel and the kmods but failing to find some solution to allow kmods is a failure on our part to provide an open source solution o our user's needs. -Toshio -------------- 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 matt at domsch.com Tue Sep 19 20:06:49 2006 From: matt at domsch.com (Matt Domsch) Date: Tue, 19 Sep 2006 15:06:49 -0500 Subject: [fab] kernel modules In-Reply-To: References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> Message-ID: <20060919200649.GB16588@domsch.com> On Tue, Sep 19, 2006 at 03:10:09PM -0400, Max Spevack wrote: > On Tue, 19 Sep 2006, Josh Boyer wrote: > > >On Tue, 2006-09-19 at 09:32 -0500, Tom 'spot' Callaway wrote: > >>- kernel modules outside of the kernel package in Fedora. Vote yes or no > >>so we can move on. > > > >This one has been asked about on the list about 4 times now. Would be > >very good to get an answer. > > The prevailing sentiment is that the engineers most directly impacted by > the decision are not in favor of kernel modules, and I think we need to > trust the technical expertise of the people who will be doing the work. > > Therefore, if I had to lay down an opinion, I would say that if Dave Jones > (et al) are opposed to kernel modules, then we need to say no. > > Additionally, if there is a belief that kernel modules would be a Good > Thing but we are forced to say no for various reasons (like bug triage as > an example) then we need to identify those reasons and act to resolve > them, so that we can revisit the issue at a later date, with the answer > being "no" until we are ready for it to be "yes". Do Kernel Modules in Core make any sense? No - they belong in the kernel package. Do Kernel Modules in Extras make sense? Maybe. I'd *much* prefer to say No here, and tell the module developers / Extras maintainer to work with upstream to get it in. However, that takes time (as I learned first-hand getting the ppp_mppe module into the kernel and out of a 3rd party hosted site), during which time end users won't get the functionality at all, or must look elsewhere. The tradeoff to saying "Yes" here is that all Extras kernel module packagers then need to help triage and resolve kernel bugs. It's cleaner for the end users if we do this work. It's extra responsibility for the kernel module packagers, but that's only appropriate. This also helps us move away from the Core vs Extras contributors distinction, if we can get non- at redhat.com people assisting with kernel bug triage and development. If FESCo agrees to include a particular module, then there needs to be enough of a developer/support cabal for it through the life of the release. Fire-and-forget kernel module packagers will suck the life out of this, and force the answer to "no". Do Kernel Modules in Fedora plus Other Free Stuff make sense? Yes, in support of the Other Free Stuff (thinking here about CCRMA and the like). I don't want to force people to diverge too far from the Fedora-provided packages in Core and Extras to enable novel functionality like this which may impact Core in ways Core doesn't want to go or isn't ready to go. Do Kernel Modules in $something-not-free make sense? Yes, and the FPB has no control over those anyhow. The common packaging guidelines go a ways towards helping this. I'll vote yes. -Matt From tibbs at math.uh.edu Tue Sep 19 20:08:14 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 19 Sep 2006 15:08:14 -0500 Subject: [fab] kernel modules In-Reply-To: <45104B26.8080907@fedoraproject.org> (Rahul's message of "Wed, 20 Sep 2006 01:25:18 +0530") References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> <45104B26.8080907@fedoraproject.org> Message-ID: >>>>> "R" == Rahul writes: R> There is certainly a difference between users grabbing packages R> from third party repositories vs including them in Fedora Extras. R> If we include anything in the formal Fedora repositories , we need R> to accept the responsibility to support it properly. Yes, as with any other package. R> If Kernel modules are included in extras, the core kernel team R> needs to be able to debug any issues and work with them. I just don't see why that would be the case. Nobody is asking for the kernel team to find and fix bugs in external modules. - J< From blizzard at redhat.com Tue Sep 19 20:17:25 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 19 Sep 2006 16:17:25 -0400 Subject: [fab] fedora board agenda for today In-Reply-To: <13dbfe4f0609190709y6fe7ea53y10a10d8e874c2cfd@mail.gmail.com> References: <13dbfe4f0609190709y6fe7ea53y10a10d8e874c2cfd@mail.gmail.com> Message-ID: <45105055.7020805@redhat.com> Chitlesh GOORAH wrote: > I would like to know more about it :) > Fedora Unity did a fairly great job in distributing the livecd built > with kadischi! > I haven't heard much from Jeremy's involvement since we discussed > about it, or is there something I missed ? > Greg was working *right now* to get 64 bit hardware, any updates ? > Recently, we added grub support on kadischi, and hence kadischi might > create ppc livecds, but both JasperHartline and I are uncertain since > we both don't have materials to test on and do research on. > Right now, I'm working on a GUI for kadischi, perhaps more testers and > contributors might be interested to help on. There's also David Zeuthen's work which does things differently than kadischi. It's worth looking at. --Chris From sundaram at fedoraproject.org Tue Sep 19 20:21:49 2006 From: sundaram at fedoraproject.org (Rahul) Date: Wed, 20 Sep 2006 01:51:49 +0530 Subject: [fab] kernel modules In-Reply-To: References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> <45104B26.8080907@fedoraproject.org> Message-ID: <4510515D.7020801@fedoraproject.org> Jason L Tibbitts III wrote: > > R> If Kernel modules are included in extras, the core kernel team > R> needs to be able to debug any issues and work with them. > > I just don't see why that would be the case. Nobody is asking for the > kernel team to find and fix bugs in external modules. > The problem is that if bugs are filed against the kernel with third party kernel modules loaded, it might be caused by the additional modules. The core kernel team doesnt want to deal with bug reports tha might be caused by third party modules regardless of whether the source is available or not and the usual response is for them to unload the module and try to reproduce the problem. If Fedora Extras includes kernel modules and the core kernel team would want them to be unloaded first before any bug reports are filed then that looks schizophrenic. Rahul From tibbs at math.uh.edu Tue Sep 19 20:26:27 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 19 Sep 2006 15:26:27 -0500 Subject: [fab] kernel modules In-Reply-To: <4510515D.7020801@fedoraproject.org> (Rahul's message of "Wed, 20 Sep 2006 01:51:49 +0530") References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> <45104B26.8080907@fedoraproject.org> <4510515D.7020801@fedoraproject.org> Message-ID: >>>>> "R" == Rahul writes: R> The problem is that if bugs are filed against the kernel with third R> party kernel modules loaded, it might be caused by the additional R> modules. Which is a problem regardless of whether the modules are in Extras or are in another repository. R> The core kernel team doesnt want to deal with bug reports R> tha might be caused by third party modules regardless of whether R> the source is available or not and the usual response is for them R> to unload the module and try to reproduce the problem. Which should be their response regardless of whether the modules are in Extras or are in another repository. R> If Fedora Extras includes kernel modules and the core kernel team R> would want them to be unloaded first before any bug reports are R> filed then that looks schizophrenic. I don't see why that would be the case. Document that fact more extensively if it makes you feel better. - J< From blizzard at redhat.com Tue Sep 19 20:28:34 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 19 Sep 2006 16:28:34 -0400 Subject: [fab] kernel modules In-Reply-To: <4510515D.7020801@fedoraproject.org> References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> <45104B26.8080907@fedoraproject.org> <4510515D.7020801@fedoraproject.org> Message-ID: <451052F2.8060603@redhat.com> Just for the record, I think that having kernel modules outside of the kernel package is fine. In fact, I think that as a mechanism for people to access software that's too bleeding edge for the mainline kernel, or to use hardware they wouldn't normally be able to use, it's great. Yes, I understand that it might not be the best option (*pound fist* everything must be upstream! *pound fist*) but in the interest of enabling users and giving people more places to participate, it's great. --Chris From mspevack at redhat.com Tue Sep 19 20:33:18 2006 From: mspevack at redhat.com (Max Spevack) Date: Tue, 19 Sep 2006 16:33:18 -0400 (EDT) Subject: [fab] kernel modules In-Reply-To: <451052F2.8060603@redhat.com> References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> <45104B26.8080907@fedoraproject.org> <4510515D.7020801@fedoraproject.org> <451052F2.8060603@redhat.com> Message-ID: On Tue, 19 Sep 2006, Christopher Blizzard wrote: > Just for the record, I think that having kernel modules outside of the kernel > package is fine. In fact, I think that as a mechanism for people to access > software that's too bleeding edge for the mainline kernel, or to use hardware > they wouldn't normally be able to use, it's great. > > Yes, I understand that it might not be the best option (*pound fist* > everything must be upstream! *pound fist*) but in the interest of enabling > users and giving people more places to participate, it's great. Ok, then I pose this: Is there anyone on the 9 person Fedora Board (Rex, Seth, Chris, Jeremy, Bill, Elliot, Rahul, Matt, Paul) who is *against* allowing the kernel modules? If not, the as a Board we need to be willing to defend the decision, and also to work with the folks who are going to be opposed to that decision to help make it more palatable for them. That's probably going to fall mostly on guys like Jeremy and Bill. Just so we have everything out there on the table. --Max -- 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 chitlesh at fedoraproject.org Tue Sep 19 20:36:19 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 19 Sep 2006 22:36:19 +0200 Subject: [fab] fedora board agenda for today In-Reply-To: <45105055.7020805@redhat.com> References: <13dbfe4f0609190709y6fe7ea53y10a10d8e874c2cfd@mail.gmail.com> <45105055.7020805@redhat.com> Message-ID: <13dbfe4f0609191336v7013184ao11a903c1328dc720@mail.gmail.com> On 9/19/06, Christopher Blizzard wrote: > There's also David Zeuthen's work which does things differently than > kadischi. It's worth looking at. Huh ?? Wow, this is really something I missed !! Where ? Is it part of the Fedora Projects ? Chitlesh -- http://clunixchit.blogspot.com From jwboyer at jdub.homelinux.org Tue Sep 19 20:45:13 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 19 Sep 2006 15:45:13 -0500 Subject: [fab] kernel modules In-Reply-To: References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> <45104670.2030905@leemhuis.info> <451046D9.7080109@math.unl.edu> Message-ID: <1158698713.3121.10.camel@zod.rchland.ibm.com> On Tue, 2006-09-19 at 15:58 -0400, Max Spevack wrote: > So... if there's smart people on both sides, and compelling arguments on > both sides, then I feel like the people who will actually have to do the > work should be the ones who tip the scales, since they are the most > directly impacted. Nobody is asking the Core developers to do the work. All they have to do is ask in bugzilla "Do you have any modules from Extras or a third party repository loaded?" And they should be doing that already. So if you're giving it to the people that are going to do the work, then you should be talking to Extras contributors. josh From sundaram at fedoraproject.org Tue Sep 19 20:44:47 2006 From: sundaram at fedoraproject.org (Rahul) Date: Wed, 20 Sep 2006 02:14:47 +0530 Subject: [fab] kernel modules In-Reply-To: References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> <45104B26.8080907@fedoraproject.org> <4510515D.7020801@fedoraproject.org> Message-ID: <451056BF.2060206@fedoraproject.org> Jason L Tibbitts III wrote: >>>>>> "R" == Rahul writes: > > R> The problem is that if bugs are filed against the kernel with third > R> party kernel modules loaded, it might be caused by the additional > R> modules. > > Which is a problem regardless of whether the modules are in Extras or > are in another repository. If anything is included in Fedora, I would as a user expect the project to support them and not be asked to remove them before I file any bug reports. I think thats a very reasonable expectation. > R> If Fedora Extras includes kernel modules and the core kernel team > R> would want them to be unloaded first before any bug reports are > R> filed then that looks schizophrenic. > > I don't see why that would be the case. Document that fact more > extensively if it makes you feel better. > > - J< Lets assume for a moment that users will read the documentation, how are we going to deal with kernel modules in extras frequently being out of sync with the high pace of kernel updates in core? If third party kernel modules included in Fedora Extras are unsupported by the core kernel team and can frequently break it would reflect poorly on the quality of the formal Fedora repositories. If we are going to include them anyway, I would prefer we include them in a separate repository. The repository file description and name should denote its relatively unsupported and potentially frequently breaking status. Rahul From sundaram at fedoraproject.org Tue Sep 19 20:47:35 2006 From: sundaram at fedoraproject.org (Rahul) Date: Wed, 20 Sep 2006 02:17:35 +0530 Subject: [fab] fedora board agenda for today In-Reply-To: <13dbfe4f0609191336v7013184ao11a903c1328dc720@mail.gmail.com> References: <13dbfe4f0609190709y6fe7ea53y10a10d8e874c2cfd@mail.gmail.com> <45105055.7020805@redhat.com> <13dbfe4f0609191336v7013184ao11a903c1328dc720@mail.gmail.com> Message-ID: <45105767.5010602@fedoraproject.org> Chitlesh GOORAH wrote: > On 9/19/06, Christopher Blizzard wrote: >> There's also David Zeuthen's work which does things differently than >> kadischi. It's worth looking at. > > Huh ?? > Wow, this is really something I missed !! > David Zeuthen wanted more work to be done before announcing it. > Where ? > Is it part of the Fedora Projects ? > > Chitlesh It was originally derived out of his work in building images for OLPC. It isnt part of Fedora yet. Rahul From chitlesh at fedoraproject.org Tue Sep 19 20:51:18 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 19 Sep 2006 22:51:18 +0200 Subject: [fab] fedora board agenda for today In-Reply-To: <45105767.5010602@fedoraproject.org> References: <13dbfe4f0609190709y6fe7ea53y10a10d8e874c2cfd@mail.gmail.com> <45105055.7020805@redhat.com> <13dbfe4f0609191336v7013184ao11a903c1328dc720@mail.gmail.com> <45105767.5010602@fedoraproject.org> Message-ID: <13dbfe4f0609191351n1429b193l5d17299424ad7d50@mail.gmail.com> On 9/19/06, Rahul wrote: > It was originally derived out of his work in building images for OLPC. > It isnt part of Fedora yet. > Is there a repository or something so that I can look at ? -- http://clunixchit.blogspot.com From jwboyer at jdub.homelinux.org Tue Sep 19 20:54:59 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 19 Sep 2006 15:54:59 -0500 Subject: [fab] kernel modules In-Reply-To: <451056BF.2060206@fedoraproject.org> References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> <45104B26.8080907@fedoraproject.org> <4510515D.7020801@fedoraproject.org> <451056BF.2060206@fedoraproject.org> Message-ID: <1158699300.3121.17.camel@zod.rchland.ibm.com> On Wed, 2006-09-20 at 02:14 +0530, Rahul wrote: > Jason L Tibbitts III wrote: > >>>>>> "R" == Rahul writes: > > > > R> The problem is that if bugs are filed against the kernel with third > > R> party kernel modules loaded, it might be caused by the additional > > R> modules. > > > > Which is a problem regardless of whether the modules are in Extras or > > are in another repository. > > If anything is included in Fedora, I would as a user expect the project > to support them and not be asked to remove them before I file any bug > reports. I think thats a very reasonable expectation. Fine. There is nothing that says one cannot open a bug report against Extras instead. > Lets assume for a moment that users will read the documentation, > how are we going to deal with kernel modules in extras frequently being > out of sync with the high pace of kernel updates in core? That requires diligence on the part of the packager. It would be the same as if the modules were carried as part of the kernel package itself. The difference being a period of time required for the packager to update the kmod against a newer released kernel. > If third party kernel modules included in Fedora Extras are unsupported > by the core kernel team and can frequently break it would reflect poorly > on the quality of the formal Fedora repositories. > > If we are going to include them anyway, I would prefer we include them > in a separate repository. The repository file description and name > should denote its relatively unsupported and potentially frequently > breaking status. I'm undecided on this, but it seems sane. josh From sundaram at fedoraproject.org Tue Sep 19 20:53:27 2006 From: sundaram at fedoraproject.org (Rahul) Date: Wed, 20 Sep 2006 02:23:27 +0530 Subject: [fab] fedora board agenda for today In-Reply-To: <13dbfe4f0609191351n1429b193l5d17299424ad7d50@mail.gmail.com> References: <13dbfe4f0609190709y6fe7ea53y10a10d8e874c2cfd@mail.gmail.com> <45105055.7020805@redhat.com> <13dbfe4f0609191336v7013184ao11a903c1328dc720@mail.gmail.com> <45105767.5010602@fedoraproject.org> <13dbfe4f0609191351n1429b193l5d17299424ad7d50@mail.gmail.com> Message-ID: <451058C7.5040008@fedoraproject.org> Chitlesh GOORAH wrote: > On 9/19/06, Rahul wrote: >> It was originally derived out of his work in building images for OLPC. >> It isnt part of Fedora yet. >> > Is there a repository or something so that I can look at ? > Here http://gitweb.freedesktop.org/?p=users/david/pilgrim.git;a=summary Rahul From blizzard at redhat.com Tue Sep 19 20:54:47 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 19 Sep 2006 16:54:47 -0400 Subject: [fab] fedora board agenda for today In-Reply-To: <45105767.5010602@fedoraproject.org> References: <13dbfe4f0609190709y6fe7ea53y10a10d8e874c2cfd@mail.gmail.com> <45105055.7020805@redhat.com> <13dbfe4f0609191336v7013184ao11a903c1328dc720@mail.gmail.com> <45105767.5010602@fedoraproject.org> Message-ID: <45105917.7020702@redhat.com> Rahul wrote: > Chitlesh GOORAH wrote: >> On 9/19/06, Christopher Blizzard wrote: >>> There's also David Zeuthen's work which does things differently than >>> kadischi. It's worth looking at. >> >> Huh ?? >> Wow, this is really something I missed !! >> > > David Zeuthen wanted more work to be done before announcing it. Oops. Sorry, David. --Chris From mspevack at redhat.com Tue Sep 19 21:09:20 2006 From: mspevack at redhat.com (Max Spevack) Date: Tue, 19 Sep 2006 17:09:20 -0400 (EDT) Subject: [fab] kernel modules Message-ID: In real time, the Board is discussing this right now. Key points: 1) The Board thinks kernel modules are a fine thing to support. 2) The Board recognizes that it will be a headache for folks like davej, and is sensitive to minimizing that headache, but voting "no" just for that reason isn't sufficient. 3) The Board thinks this is an organizational decision rather than a technical one. Meaning that we're saying +1, but we're not going to mandate certain answers to the technical questions one way or another. Those decisions are best made at a more hands-on level. Any questions? :-) --Max -- 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 chitlesh at fedoraproject.org Tue Sep 19 21:10:44 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 19 Sep 2006 23:10:44 +0200 Subject: [fab] fedora board agenda for today In-Reply-To: <451058C7.5040008@fedoraproject.org> References: <13dbfe4f0609190709y6fe7ea53y10a10d8e874c2cfd@mail.gmail.com> <45105055.7020805@redhat.com> <13dbfe4f0609191336v7013184ao11a903c1328dc720@mail.gmail.com> <45105767.5010602@fedoraproject.org> <13dbfe4f0609191351n1429b193l5d17299424ad7d50@mail.gmail.com> <451058C7.5040008@fedoraproject.org> Message-ID: <13dbfe4f0609191410uf0c6c4bt704859661bd6dbb8@mail.gmail.com> On 9/19/06, Rahul wrote: > Here > > http://gitweb.freedesktop.org/?p=users/david/pilgrim.git;a=summary > > Rahul Thanks Rahul, David Zeuhen, if you are following this list, can you give a summary what you are planning to do in the future in terms of livecd (in the Fedora-livecd list), just in case we are doing the same thing! Chitlesh -- http://clunixchit.blogspot.com From gdk at redhat.com Tue Sep 19 21:28:35 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Tue, 19 Sep 2006 17:28:35 -0400 (EDT) Subject: [fab] kernel modules In-Reply-To: <20060919200649.GB16588@domsch.com> References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> <20060919200649.GB16588@domsch.com> Message-ID: +1 to Matt's analysis here, fwiw. Although I'm guessing you're already voting on it as I type this. :) --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- On Tue, 19 Sep 2006, Matt Domsch wrote: > On Tue, Sep 19, 2006 at 03:10:09PM -0400, Max Spevack wrote: > > On Tue, 19 Sep 2006, Josh Boyer wrote: > > > > >On Tue, 2006-09-19 at 09:32 -0500, Tom 'spot' Callaway wrote: > > >>- kernel modules outside of the kernel package in Fedora. Vote yes or no > > >>so we can move on. > > > > > >This one has been asked about on the list about 4 times now. Would be > > >very good to get an answer. > > > > The prevailing sentiment is that the engineers most directly impacted by > > the decision are not in favor of kernel modules, and I think we need to > > trust the technical expertise of the people who will be doing the work. > > > > Therefore, if I had to lay down an opinion, I would say that if Dave Jones > > (et al) are opposed to kernel modules, then we need to say no. > > > > Additionally, if there is a belief that kernel modules would be a Good > > Thing but we are forced to say no for various reasons (like bug triage as > > an example) then we need to identify those reasons and act to resolve > > them, so that we can revisit the issue at a later date, with the answer > > being "no" until we are ready for it to be "yes". > > > Do Kernel Modules in Core make any sense? No - they belong in the > kernel package. > > Do Kernel Modules in Extras make sense? Maybe. I'd *much* prefer to > say No here, and tell the module developers / Extras maintainer to > work with upstream to get it in. However, that takes time (as I > learned first-hand getting the ppp_mppe module into the kernel and out > of a 3rd party hosted site), during which time end users won't get the > functionality at all, or must look elsewhere. The tradeoff to saying > "Yes" here is that all Extras kernel module packagers then need to > help triage and resolve kernel bugs. It's cleaner for the end users > if we do this work. It's extra responsibility for the kernel module > packagers, but that's only appropriate. > > This also helps us move away from the Core vs Extras contributors > distinction, if we can get non- at redhat.com people assisting with > kernel bug triage and development. If FESCo agrees to include a > particular module, then there needs to be enough of a > developer/support cabal for it through the life of the release. > Fire-and-forget kernel module packagers will suck the life out of > this, and force the answer to "no". > > > Do Kernel Modules in Fedora plus Other Free Stuff make sense? Yes, in > support of the Other Free Stuff (thinking here about CCRMA and the > like). I don't want to force people to diverge too far from the > Fedora-provided packages in Core and Extras to enable novel > functionality like this which may impact Core in ways Core doesn't > want to go or isn't ready to go. > > Do Kernel Modules in $something-not-free make sense? Yes, and the > FPB has no control over those anyhow. The common packaging guidelines > go a ways towards helping this. > > > I'll vote yes. > > -Matt > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > From gdk at redhat.com Tue Sep 19 21:30:55 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Tue, 19 Sep 2006 17:30:55 -0400 (EDT) Subject: [fab] fedora board agenda for today In-Reply-To: <13dbfe4f0609191336v7013184ao11a903c1328dc720@mail.gmail.com> References: <13dbfe4f0609190709y6fe7ea53y10a10d8e874c2cfd@mail.gmail.com> <45105055.7020805@redhat.com> <13dbfe4f0609191336v7013184ao11a903c1328dc720@mail.gmail.com> Message-ID: DAVID ZEUTHEN, WHERE ARE YOU? :) OK, since davidz hasn't made himself visible despite our proddings: he's working on OLPC. He's got some code that does a lot of what our Live CD code does, but in a very different way. We're encouraging him to put the code out there so we can have another codebase for comparison purposes. Now we've really got to poke him. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- On Tue, 19 Sep 2006, Chitlesh GOORAH wrote: > On 9/19/06, Christopher Blizzard wrote: > > There's also David Zeuthen's work which does things differently than > > kadischi. It's worth looking at. > > Huh ?? > Wow, this is really something I missed !! > > Where ? > Is it part of the Fedora Projects ? > > Chitlesh > -- > http://clunixchit.blogspot.com > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > From mspevack at redhat.com Tue Sep 19 21:42:21 2006 From: mspevack at redhat.com (Max Spevack) Date: Tue, 19 Sep 2006 17:42:21 -0400 (EDT) Subject: [fab] fedora board agenda for today In-Reply-To: References: <13dbfe4f0609190709y6fe7ea53y10a10d8e874c2cfd@mail.gmail.com> <45105055.7020805@redhat.com> <13dbfe4f0609191336v7013184ao11a903c1328dc720@mail.gmail.com> Message-ID: He's not on f-a-b list. :-) I just added him though. We need to talk with him offline. --Max On Tue, 19 Sep 2006, Greg DeKoenigsberg wrote: > > DAVID ZEUTHEN, WHERE ARE YOU? :) > > OK, since davidz hasn't made himself visible despite our proddings: he's > working on OLPC. He's got some code that does a lot of what our Live CD > code does, but in a very different way. We're encouraging him to put the > code out there so we can have another codebase for comparison purposes. > > Now we've really got to poke him. > > --g > > ------------------------------------------------------------- > Greg DeKoenigsberg || Fedora Project || fedoraproject.org > Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors > ------------------------------------------------------------- > > On Tue, 19 Sep 2006, Chitlesh GOORAH wrote: > >> On 9/19/06, Christopher Blizzard wrote: >>> There's also David Zeuthen's work which does things differently than >>> kadischi. It's worth looking at. >> >> Huh ?? >> Wow, this is really something I missed !! >> >> Where ? >> Is it part of the Fedora Projects ? >> >> Chitlesh >> -- >> http://clunixchit.blogspot.com >> >> _______________________________________________ >> fedora-advisory-board mailing list >> fedora-advisory-board at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-advisory-board >> > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > -- 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 chitlesh at fedoraproject.org Tue Sep 19 21:42:21 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 19 Sep 2006 23:42:21 +0200 Subject: [fab] fedora board agenda for today In-Reply-To: References: <13dbfe4f0609190709y6fe7ea53y10a10d8e874c2cfd@mail.gmail.com> <45105055.7020805@redhat.com> <13dbfe4f0609191336v7013184ao11a903c1328dc720@mail.gmail.com> Message-ID: <13dbfe4f0609191442u6a858dc3va627510ef6e53060@mail.gmail.com> On 9/19/06, Greg DeKoenigsberg wrote: > working on OLPC. He's got some code that does a lot of what our Live CD > code does, but in a very different way. You mean Live CD code = Kadischi ? :) We're encouraging him to put the > code out there so we can have another codebase for comparison purposes. Yeah, both projects can benefit! -- http://clunixchit.blogspot.com From mmcgrath at fedoraproject.org Tue Sep 19 23:10:25 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 19 Sep 2006 18:10:25 -0500 Subject: [fab] kernel modules In-Reply-To: References: Message-ID: <3237e4410609191610v3bfb12ccn640f270a67279afe@mail.gmail.com> On 9/19/06, Max Spevack wrote: > In real time, the Board is discussing this right now. > > Key points: > > 1) The Board thinks kernel modules are a fine thing to support. > > 2) The Board recognizes that it will be a headache for folks like davej, > and is sensitive to minimizing that headache, but voting "no" just for > that reason isn't sufficient. > > 3) The Board thinks this is an organizational decision rather than a > technical one. Meaning that we're saying +1, but we're not going to > mandate certain answers to the technical questions one way or another. > > Those decisions are best made at a more hands-on level. > > Any questions? :-) > > --Max > Perhaps we should pick some modules that we deem both useful and popular for designing and building a model after. -Mike From skvidal at linux.duke.edu Wed Sep 20 00:43:42 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 19 Sep 2006 20:43:42 -0400 Subject: [fab] kernel modules In-Reply-To: References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> <45104B26.8080907@fedoraproject.org> <4510515D.7020801@fedoraproject.org> <451052F2.8060603@redhat.com> Message-ID: <1158713022.1999.4.camel@cutter> On Tue, 2006-09-19 at 16:33 -0400, Max Spevack wrote: > On Tue, 19 Sep 2006, Christopher Blizzard wrote: > > > Just for the record, I think that having kernel modules outside of the kernel > > package is fine. In fact, I think that as a mechanism for people to access > > software that's too bleeding edge for the mainline kernel, or to use hardware > > they wouldn't normally be able to use, it's great. > > > > Yes, I understand that it might not be the best option (*pound fist* > > everything must be upstream! *pound fist*) but in the interest of enabling > > users and giving people more places to participate, it's great. > > Ok, then I pose this: > > Is there anyone on the 9 person Fedora Board (Rex, Seth, Chris, Jeremy, > Bill, Elliot, Rahul, Matt, Paul) who is *against* allowing the kernel > modules? > > If not, the as a Board we need to be willing to defend the decision, and > also to work with the folks who are going to be opposed to that decision > to help make it more palatable for them. > > That's probably going to fall mostly on guys like Jeremy and Bill. > I'm fine with kernel-modules. -sv From davidz at redhat.com Wed Sep 20 06:18:38 2006 From: davidz at redhat.com (David Zeuthen) Date: Wed, 20 Sep 2006 02:18:38 -0400 Subject: [fab] [Fwd: [Fedora-livecd-list] pilgrim livecd work] Message-ID: <1158733118.26429.88.camel@zelda.fubar.dk> Hi, I was asked to publish some work I did on Live CD's - see attached mail that I just sent to fedora-livecd and fedora-desktop. If there's sufficient interest in this work, I guess the next steps would be to build a community / project around it. However, there's probably some much needed fundamental discussion about direction etc. needed before we can do this. The attached mail and the link to README.fedora outlines some of the ideas I have about that. Feel free to flame etc. :-) David -------------- next part -------------- An embedded message was scrubbed... From: David Zeuthen Subject: [Fedora-livecd-list] pilgrim livecd work Date: Wed, 20 Sep 2006 01:51:28 -0400 Size: 7698 URL: From chitlesh at fedoraproject.org Wed Sep 20 06:51:34 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 20 Sep 2006 08:51:34 +0200 Subject: [fab] [Fwd: [Fedora-livecd-list] pilgrim livecd work] In-Reply-To: <1158733118.26429.88.camel@zelda.fubar.dk> References: <1158733118.26429.88.camel@zelda.fubar.dk> Message-ID: <13dbfe4f0609192351j56ba5f5bo9ca17e9ecb8b7f00@mail.gmail.com> On 9/20/06, David Zeuthen wrote: > Hi, > > I was asked to publish some work I did on Live CD's - see attached mail > that I just sent to fedora-livecd and fedora-desktop. Thanks David, I appreciate the effort :) > If there's sufficient interest in this work, I guess the next steps > would be to build a community / project around it. For example, Kadischi ? :) However, there's > probably some much needed fundamental discussion about direction etc. > needed before we can do this. The attached mail and the link to > README.fedora outlines some of the ideas I have about that. > > Feel free to flame etc. :-) It's true, now we need to discuss how both projects could work together. PS: i'll write more about it later on, - going to sleep. Chitlesh -- http://clunixchit.blogspot.com From jkeating at redhat.com Wed Sep 20 13:49:08 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Sep 2006 09:49:08 -0400 Subject: [fab] kernel modules In-Reply-To: <1158696268.2838.38.camel@localhost> References: <1158696268.2838.38.camel@localhost> Message-ID: <200609200949.09070.jkeating@redhat.com> On Tuesday 19 September 2006 16:04, Toshio Kuratomi wrote: > Arguments against kmods: > * It makes the job of diagnosing kernel bugs harder as there could be > extra kmods on top of a stock fedora kernel. > * kmods and kernels could go out of sync. Wrong. By nature, kmods and kernels will ALWAYS get out of sync. This will prevent security updates from installing on a users system until the kmod developer gets around to rebuilding the module. This is a REALLY poor user experience. Further arguments against kmods include: * no sane way to package them, everything is just a hack * no sane way to manage installation/upgrades. RPM just does not mesh well with the way that kmods need to operate. The way rpm handles kernel is a bit hacky, multiple releases of a package installed at the same time. Throwing addon packages to this in the mix makes the whole RPM system spiral downhill in a hurry. * kmod developers are largely out of the loop in kernel developments and directions of the kernels. This is somewhat solveable but hard to keep up especially if we allow more and more kmods in where the packare is just that a packager, and not a kernel developer. > > Arguments for kmods: > * It makes the job of the end-user easier because they need the > functionality anyway and will get it from another source if necessary. > * It makes the job of the kernel developers easier because they at least > know the end-user is using a kmod from fedora-extras (and can ask: "if > you rpm -qa |grep kmod does that turn up anything?" ?whereas a from > source kmod would not leave that evidence.) Um, lsmod is pretty easy to run. And its quicker than rpm -qa. This argument is bunk. > * Fedora is a home for all open source software. ?Open source kmods are > part of that definition. Yes, however there is no reason why these kmods couldn't live IN the kernel src.rpm and not in separate packages. I'm not against Fedora including kernel modules that aren't in the upstream tree. I'm against including them in standalone packages. These modules will not be available at install time if in separate packages. If we care enough about the module and enough to make it available at install time and as official packages/updates, we should invest the time to get it into the kernel source package so that it is always released at the same time and gets the same attention. The real challenge is making it easier for the community to assist in the kernel development, not in creating subpackages of modules that only makes it more complex and difficult. [snip] -- 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 Sep 20 13:58:25 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Sep 2006 09:58:25 -0400 Subject: [fab] kernel modules In-Reply-To: References: Message-ID: <200609200958.26048.jkeating@redhat.com> On Tuesday 19 September 2006 17:09, Max Spevack wrote: > Any questions? ? please see my post on this from a minute ago. there are two issues that shouldnot be bound together. kernel modules not in upstream trees and kernel module packages. the former does not necessarily require the latter and decisions should not be made with the assumption that it does. -- 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 jwboyer at jdub.homelinux.org Wed Sep 20 14:05:41 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Sep 2006 09:05:41 -0500 Subject: [fab] kernel modules In-Reply-To: <200609200949.09070.jkeating@redhat.com> References: <1158696268.2838.38.camel@localhost> <200609200949.09070.jkeating@redhat.com> Message-ID: <1158761141.3121.31.camel@zod.rchland.ibm.com> On Wed, 2006-09-20 at 09:49 -0400, Jesse Keating wrote: > On Tuesday 19 September 2006 16:04, Toshio Kuratomi wrote: > > Arguments against kmods: > > * It makes the job of diagnosing kernel bugs harder as there could be > > extra kmods on top of a stock fedora kernel. > > * kmods and kernels could go out of sync. > > Wrong. By nature, kmods and kernels will ALWAYS get out of sync. This will > prevent security updates from installing on a users system until the kmod > developer gets around to rebuilding the module. This is a REALLY poor user > experience. Further arguments against kmods include: > * no sane way to package them, everything is just a hack > * no sane way to manage installation/upgrades. RPM just does not mesh well > with the way that kmods need to operate. The way rpm handles kernel is a bit > hacky, multiple releases of a package installed at the same time. Throwing > addon packages to this in the mix makes the whole RPM system spiral downhill > in a hurry. > * kmod developers are largely out of the loop in kernel developments and > directions of the kernels. This is somewhat solveable but hard to keep up > especially if we allow more and more kmods in where the packare is just that > a packager, and not a kernel developer. > > > > > Arguments for kmods: > > * It makes the job of the end-user easier because they need the > > functionality anyway and will get it from another source if necessary. > > * It makes the job of the kernel developers easier because they at least > > know the end-user is using a kmod from fedora-extras (and can ask: "if > > you rpm -qa |grep kmod does that turn up anything?" whereas a from > > source kmod would not leave that evidence.) > > Um, lsmod is pretty easy to run. And its quicker than rpm -qa. This argument > is bunk. > > > * Fedora is a home for all open source software. Open source kmods are > > part of that definition. > > Yes, however there is no reason why these kmods couldn't live IN the kernel > src.rpm and not in separate packages. I'm not against Fedora including Yes, there is. DaveJ said no, and I don't blame him. If it lives IN the kernel src.rpm, then bugs get filed against that and the problem lies back on the Core kernel developers. > released at the same time and gets the same attention. The real challenge is > making it easier for the community to assist in the kernel development, not > in creating subpackages of modules that only makes it more complex and > difficult. Considering the number of people that work on it now, and the things needed to keep in sync, I find that to be just as complex as keeping them in their own package. For example, you do _not_ want to hold up a Core kernel security fix because someone from the community has a driver that needs updating. It's the same damn argument, only now it prevents the security fix from getting out for _everybody_ not just the ones using said module. josh From ville.skytta at iki.fi Wed Sep 20 16:19:52 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 20 Sep 2006 19:19:52 +0300 Subject: [fab] kernel modules In-Reply-To: <200609200949.09070.jkeating@redhat.com> References: <1158696268.2838.38.camel@localhost> <200609200949.09070.jkeating@redhat.com> Message-ID: <1158769192.2902.287.camel@viper.local> On Wed, 2006-09-20 at 09:49 -0400, Jesse Keating wrote: > Wrong. By nature, kmods and kernels will ALWAYS get out of sync. This will > prevent security updates from installing on a users system until the kmod > developer gets around to rebuilding the module. If you're referring to yum's behaviour of denying all available updates if there's one problem somewhere - kmods are pretty much unaffected by that because they're co-installed, not upgraded as usual so lagging behind a bit should not prevent any other updates. And even if they would be affected, that's a problem in yum and needs to be fixed there, no? From sundaram at fedoraproject.org Wed Sep 20 17:58:19 2006 From: sundaram at fedoraproject.org (Rahul) Date: Wed, 20 Sep 2006 23:28:19 +0530 Subject: [fab] Alternative kernels? Message-ID: <4511813B.7010508@fedoraproject.org> Hi So since we decided to allow kernel modules in Fedora Extras now, what about alternative kernels? The immediate need for this is a kernel with Ingo's RT patch set (http://people.redhat.com/mingo/realtime-preempt/) that is used by Planet CCRMA that we are trying to integrate into Fedora. We already discussed this before at https://www.redhat.com/archives/fedora-advisory-board/2006-May/msg00055.html. A quick decision now. Yes/no? Rahul From katzj at redhat.com Wed Sep 20 18:33:38 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Sep 2006 14:33:38 -0400 Subject: [fab] Alternative kernels? In-Reply-To: <4511813B.7010508@fedoraproject.org> References: <4511813B.7010508@fedoraproject.org> Message-ID: <1158777218.12818.12.camel@aglarond.local> On Wed, 2006-09-20 at 23:28 +0530, Rahul wrote: > So since we decided to allow kernel modules in Fedora Extras now, what > about alternative kernels? > > The immediate need for this is a kernel with Ingo's RT patch set > (http://people.redhat.com/mingo/realtime-preempt/) that is used by > Planet CCRMA that we are trying to integrate into Fedora. > > We already discussed this before at > https://www.redhat.com/archives/fedora-advisory-board/2006-May/msg00055.html. > A quick decision now. Yes/no? I'd say no Jeremy From blizzard at redhat.com Wed Sep 20 18:48:02 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 20 Sep 2006 14:48:02 -0400 Subject: [fab] Alternative kernels? In-Reply-To: <1158777218.12818.12.camel@aglarond.local> References: <4511813B.7010508@fedoraproject.org> <1158777218.12818.12.camel@aglarond.local> Message-ID: <45118CE2.6010704@redhat.com> Jeremy Katz wrote: > On Wed, 2006-09-20 at 23:28 +0530, Rahul wrote: >> So since we decided to allow kernel modules in Fedora Extras now, what >> about alternative kernels? >> >> The immediate need for this is a kernel with Ingo's RT patch set >> (http://people.redhat.com/mingo/realtime-preempt/) that is used by >> Planet CCRMA that we are trying to integrate into Fedora. >> >> We already discussed this before at >> https://www.redhat.com/archives/fedora-advisory-board/2006-May/msg00055.html. >> A quick decision now. Yes/no? > > I'd say no > This is that classic problem that it's hard for us to manage > 1 of anything in our trees. I suspect (but correct me if I'm wrong) that Jeremy is actually concerned about the lack of focus on the mainline kernel, or wanting to get the RT patches upstream. I'm happy to enable there to be > 1 kernel, but it's hard because of the way that our packaging systems work. We're doing this right now for OLPC, based on David and Marcelo's work, but I'm not sure what the mechanism is to make sure that the OLPC kernel always wins. --Chris From katzj at redhat.com Wed Sep 20 19:22:02 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Sep 2006 15:22:02 -0400 Subject: [fab] Alternative kernels? In-Reply-To: <45118CE2.6010704@redhat.com> References: <4511813B.7010508@fedoraproject.org> <1158777218.12818.12.camel@aglarond.local> <45118CE2.6010704@redhat.com> Message-ID: <1158780122.12818.24.camel@aglarond.local> On Wed, 2006-09-20 at 14:48 -0400, Christopher Blizzard wrote: > Jeremy Katz wrote: > > On Wed, 2006-09-20 at 23:28 +0530, Rahul wrote: > >> So since we decided to allow kernel modules in Fedora Extras now, what > >> about alternative kernels? > >> > >> The immediate need for this is a kernel with Ingo's RT patch set > >> (http://people.redhat.com/mingo/realtime-preempt/) that is used by > >> Planet CCRMA that we are trying to integrate into Fedora. > >> > >> We already discussed this before at > >> https://www.redhat.com/archives/fedora-advisory-board/2006-May/msg00055.html. > >> A quick decision now. Yes/no? > > > > I'd say no > > This is that classic problem that it's hard for us to manage > 1 of > anything in our trees. I suspect (but correct me if I'm wrong) that > Jeremy is actually concerned about the lack of focus on the mainline > kernel, or wanting to get the RT patches upstream. If we allow arbitrary kernels that are maintained in Extras, how do we make sure that there's actually a consistent set of features provided? And that's ignoring the questions of currency and handling of security errata, which is already hard enough. Additionally, more kernels ==> more pain for kernel module packagers. Now they need to know about even _more_ variants and be able to build against them. These are the things that concern me a lot about more kernels. Lack of focus on the mainline kernel and wanting to focus on getting the patches upstream is more of a secondary concern :) Jeremy From blizzard at redhat.com Wed Sep 20 19:27:10 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 20 Sep 2006 15:27:10 -0400 Subject: [fab] Alternative kernels? In-Reply-To: <1158780122.12818.24.camel@aglarond.local> References: <4511813B.7010508@fedoraproject.org> <1158777218.12818.12.camel@aglarond.local> <45118CE2.6010704@redhat.com> <1158780122.12818.24.camel@aglarond.local> Message-ID: <4511960E.1090307@redhat.com> Jeremy Katz wrote: > If we allow arbitrary kernels that are maintained in Extras, how do we > make sure that there's actually a consistent set of features provided? > And that's ignoring the questions of currency and handling of security > errata, which is already hard enough. In the case of the planet kernel, does it matter? It's for a very specific use. We're not always talking about the general use case. Be it the planet kernel or the OLPC kernel, there's more than one use case here. Sometimes it makes a lot of sense to have a different kind of kernel. > Additionally, more kernels ==> more pain for kernel module packagers. > Now they need to know about even _more_ variants and be able to build > against them. Does it? You're assuming that everyone pays for the pain for everyone else's work. I assume that some of that work will spill over to the kernel packagers that we have today, but it's not going to be all of it. I think that enabling various uses is probably worth the pain, and the mechanisms will work themselves out. Maybe Dave will go a little crazy, but maybe this will help him as well. Maybe other people will be able to step up and be able to actually help him with that work. But we can't even begin to tell that without taking the first step and saying it's OK for other people to enter that space. > These are the things that concern me a lot about more kernels. Lack of > focus on the mainline kernel and wanting to focus on getting the patches > upstream is more of a secondary concern :) :) --Chris From sundaram at fedoraproject.org Wed Sep 20 19:31:09 2006 From: sundaram at fedoraproject.org (Rahul) Date: Thu, 21 Sep 2006 01:01:09 +0530 Subject: [fab] Alternative kernels? In-Reply-To: <1158780122.12818.24.camel@aglarond.local> References: <4511813B.7010508@fedoraproject.org> <1158777218.12818.12.camel@aglarond.local> <45118CE2.6010704@redhat.com> <1158780122.12818.24.camel@aglarond.local> Message-ID: <451196FD.7070305@fedoraproject.org> Jeremy Katz wrote: > On Wed, 2006-09-20 at 14:48 -0400, Christopher Blizzard wrote: >> Jeremy Katz wrote: >>> On Wed, 2006-09-20 at 23:28 +0530, Rahul wrote: >>>> So since we decided to allow kernel modules in Fedora Extras now, what >>>> about alternative kernels? >>>> >>>> The immediate need for this is a kernel with Ingo's RT patch set >>>> (http://people.redhat.com/mingo/realtime-preempt/) that is used by >>>> Planet CCRMA that we are trying to integrate into Fedora. >>>> >>>> We already discussed this before at >>>> https://www.redhat.com/archives/fedora-advisory-board/2006-May/msg00055.html. >>>> A quick decision now. Yes/no? >>> I'd say no >> This is that classic problem that it's hard for us to manage > 1 of >> anything in our trees. I suspect (but correct me if I'm wrong) that >> Jeremy is actually concerned about the lack of focus on the mainline >> kernel, or wanting to get the RT patches upstream. > > If we allow arbitrary kernels that are maintained in Extras, how do we > make sure that there's actually a consistent set of features provided? We dont need to allow arbitrary kernels. Can we allow Planet CCRMA kernel or the OLPC kernel? > And that's ignoring the questions of currency and handling of security > errata, which is already hard enough. Yes. A good maintainer would be required. Fortunately, in both these case we have one. RT patch set is being pushed very heavily upstream by Ingo and is expected to take a few revisions. Rahul From katzj at redhat.com Wed Sep 20 19:38:33 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Sep 2006 15:38:33 -0400 Subject: [fab] Alternative kernels? In-Reply-To: <4511960E.1090307@redhat.com> References: <4511813B.7010508@fedoraproject.org> <1158777218.12818.12.camel@aglarond.local> <45118CE2.6010704@redhat.com> <1158780122.12818.24.camel@aglarond.local> <4511960E.1090307@redhat.com> Message-ID: <1158781113.12818.33.camel@aglarond.local> On Wed, 2006-09-20 at 15:27 -0400, Christopher Blizzard wrote: > Jeremy Katz wrote: > > If we allow arbitrary kernels that are maintained in Extras, how do we > > make sure that there's actually a consistent set of features provided? > > And that's ignoring the questions of currency and handling of security > > errata, which is already hard enough. > > In the case of the planet kernel, does it matter? It's for a very > specific use. We're not always talking about the general use case. Be > it the planet kernel or the OLPC kernel, there's more than one use case > here. Sometimes it makes a lot of sense to have a different kind of kernel. For the PlanetCCRMA case, actually, it _does_ matter. If we add a wireless driver to the main kernel package and it doesn't end up in the Extra CCRMA kernel package, then people using that get less functionality and it's "choose A or B". Which sucks. OLPC being a slimmed down kernel targeted at a specific piece of hardware is an entirely different discussion. > > Additionally, more kernels ==> more pain for kernel module packagers. > > Now they need to know about even _more_ variants and be able to build > > against them. > > Does it? You're assuming that everyone pays for the pain for everyone > else's work. I assume that some of that work will spill over to the > kernel packagers that we have today, but it's not going to be all of it. Read what I said again -- this is about third party module packagers, not davej. Having to guess at what kernels are available to build modules for makes the complexity of the packaging of kernel modules multiply far beyond the insanity it already is. > I think that enabling various uses is probably worth the pain, and the > mechanisms will work themselves out. Maybe Dave will go a little crazy, > but maybe this will help him as well. Maybe other people will be able > to step up and be able to actually help him with that work. But we > can't even begin to tell that without taking the first step and saying > it's OK for other people to enter that space. Frankly, "might"s and "maybe"s aren't really enough here for me. Having a separate kernel doesn't really do anything to enable people to help him... so if they're not doing it now, why are they going to be _more_ willing to do so when we basically say "here, we endorse you having your own playground"? We went down this path for a while with the Xen kernel stuff and the amount of pain was way way way huge. Jeremy From blizzard at redhat.com Wed Sep 20 19:39:55 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 20 Sep 2006 15:39:55 -0400 Subject: [fab] kernel modules In-Reply-To: <200609200949.09070.jkeating@redhat.com> References: <1158696268.2838.38.camel@localhost> <200609200949.09070.jkeating@redhat.com> Message-ID: <4511990B.7010700@redhat.com> Jesse Keating wrote: > Wrong. By nature, kmods and kernels will ALWAYS get out of sync. This will > prevent security updates from installing on a users system until the kmod > developer gets around to rebuilding the module. This is a REALLY poor user > experience. Further arguments against kmods include: I'll draw a correlary for a moment and say that this happens in a lot of places in the OS. If we update a package that has dependencies, and some of the deps have to move, we have that problem today, no? Yes, the kernel is a special case because it's more of a moving target and the lack of internal APIs makes this harder, but it's something that we're at least a little used to, even if it's to a lesser degree. It might be enough to say "hey, if the kernel moves, it moves" and kmod packagers have to follow. > * no sane way to package them, everything is just a hack > * no sane way to manage installation/upgrades. RPM just does not mesh well > with the way that kmods need to operate. The way rpm handles kernel is a bit > hacky, multiple releases of a package installed at the same time. Throwing > addon packages to this in the mix makes the whole RPM system spiral downhill > in a hurry. :P An opportunity to make some changes to RPM that enables this kind of behavior? > * kmod developers are largely out of the loop in kernel developments and > directions of the kernels. This is somewhat solveable but hard to keep up > especially if we allow more and more kmods in where the packare is just that > a packager, and not a kernel developer. Right now there's no chance for them to work together. Set up a kmod mailing list and get everyone on the same page? i.e. if you want to maintain a kmod, get on the list and learn from others. I see this is a chance to teach and bring a community closer together. We just need to have a set of signposts to get people pointed in the right direction. > Yes, however there is no reason why these kmods couldn't live IN the kernel > src.rpm and not in separate packages. I'm not against Fedora including > kernel modules that aren't in the upstream tree. I'm against including them > in standalone packages. These modules will not be available at install time > if in separate packages. If we care enough about the module and enough to > make it available at install time and as official packages/updates, we should > invest the time to get it into the kernel source package so that it is always > released at the same time and gets the same attention. The real challenge is > making it easier for the community to assist in the kernel development, not > in creating subpackages of modules that only makes it more complex and > difficult. > I like the goal here - encouraging external people to participate - but there's stuff that lives outside of the kernel today. The natural reflection for that is separate packages, not addons into the kernel package. Yes, kmod has downsides. But on balance, doesn't the idea of enabling external folks to add kernel modules and participate on an important piece of our story worth the cost? We'll learn as we go, and maybe we'll decide that it totally sucks. (Failure needs to be OK, IMHO. If we're not failing we're not trying.) Or maybe we'll learn that we need to change the way the package system works for the kernel. But right now we can't even figure that out because we're not even willing to try. --Chris From jkeating at redhat.com Wed Sep 20 19:49:29 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Sep 2006 15:49:29 -0400 Subject: [fab] Alternative kernels? In-Reply-To: <1158781113.12818.33.camel@aglarond.local> References: <4511813B.7010508@fedoraproject.org> <4511960E.1090307@redhat.com> <1158781113.12818.33.camel@aglarond.local> Message-ID: <200609201549.29352.jkeating@redhat.com> On Wednesday 20 September 2006 15:38, Jeremy Katz wrote: > Frankly, "might"s and "maybe"s aren't really enough here for me. ?Having > a separate kernel doesn't really do anything to enable people to help > him... so if they're not doing it now, why are they going to be _more_ > willing to do so when we basically say "here, we endorse you having your > own playground"? > > We went down this path for a while with the Xen kernel stuff and the > amount of pain was way way way huge. There is also the fun of 'You added the Extras repo, the PlanetCCRMA repo, and Joe's repo. Each repo has a kernel, you've selected them all. What do you boot by default?' -- 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 jwboyer at jdub.homelinux.org Wed Sep 20 19:52:53 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Sep 2006 14:52:53 -0500 Subject: [fab] Alternative kernels? In-Reply-To: <451196FD.7070305@fedoraproject.org> References: <4511813B.7010508@fedoraproject.org> <1158777218.12818.12.camel@aglarond.local> <45118CE2.6010704@redhat.com> <1158780122.12818.24.camel@aglarond.local> <451196FD.7070305@fedoraproject.org> Message-ID: <1158781973.3121.52.camel@zod.rchland.ibm.com> On Thu, 2006-09-21 at 01:01 +0530, Rahul wrote: > > > > If we allow arbitrary kernels that are maintained in Extras, how do we > > make sure that there's actually a consistent set of features provided? > > We dont need to allow arbitrary kernels. Can we allow Planet CCRMA > kernel or the OLPC kernel? Can we leave OLPC out of this for now? Yay for OLPC, but only a few people have hardware that it could actually be used on. Planet CCRMA is a much more realistic case. > > And that's ignoring the questions of currency and handling of security > > errata, which is already hard enough. > > Yes. A good maintainer would be required. Fortunately, in both these > case we have one. RT patch set is being pushed very heavily upstream by > Ingo and is expected to take a few revisions. Does Ingo want to maintain a kernel _package_ though? josh From jkeating at redhat.com Wed Sep 20 19:53:21 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Sep 2006 15:53:21 -0400 Subject: [fab] kernel modules In-Reply-To: <1158761141.3121.31.camel@zod.rchland.ibm.com> References: <200609200949.09070.jkeating@redhat.com> <1158761141.3121.31.camel@zod.rchland.ibm.com> Message-ID: <200609201553.22104.jkeating@redhat.com> On Wednesday 20 September 2006 10:05, Josh Boyer wrote: > Yes, there is. ?DaveJ said no, and I don't blame him. ?If it lives IN > the kernel src.rpm, then bugs get filed against that and the problem > lies back on the Core kernel developers. Thats the point. If the module isn't good enough, isn't ready, doesn't have upstream committment to track the latest git trees from Linus, then it really has no business being packaged and provided for Fedora releases. Many 3rd party modules that we'd be allowed to package do NOT track daily linus get trees, nor our Fedora update trees. There is no commitment from upstream to keep the module building. We're mostly software packagers here, not driver developers. Do we want to require our kmod packagers to be competent enough to keep the module source building on a daily basis? Fedora wants to stick close to upstream, but in this case, the kernel.org is the upstream. Anything else is forks and branches that aren't part of the upstream. Sounds more like a case for Fedora Unstable or Fedora Bloody Edge Extras. Definitely not something we want in an actual release. > > released at the same time and gets the same attention. ?The real > > challenge is making it easier for the community to assist in the kernel > > development, not in creating subpackages of modules that only makes it > > more complex and difficult. > > Considering the number of people that work on it now, and the things > needed to keep in sync, I find that to be just as complex as keeping > them in their own package. ?For example, you do _not_ want to hold up a > Core kernel security fix because someone from the community has a driver > that needs updating. ?It's the same damn argument, only now it prevents > the security fix from getting out for _everybody_ not just the ones > using said module. See above argument. -- 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 Sep 20 19:56:21 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Sep 2006 15:56:21 -0400 Subject: [fab] kernel modules In-Reply-To: <1158769192.2902.287.camel@viper.local> References: <200609200949.09070.jkeating@redhat.com> <1158769192.2902.287.camel@viper.local> Message-ID: <200609201556.21301.jkeating@redhat.com> On Wednesday 20 September 2006 12:19, Ville Skytt? wrote: > If you're referring to yum's behaviour of denying all available updates > if there's one problem somewhere - kmods are pretty much unaffected by > that because they're co-installed, not upgraded as usual so lagging > behind a bit should not prevent any other updates. ?And even if they > would be affected, that's a problem in yum and needs to be fixed there, > no? And when the module isn't available at all for the new updated kernel? You're not going to boot to that kernel, you'll continue running the bad kernel. It's pretty clear that in most cases, the 3rd party module isn't ready for mainstream use. If it were, it'd be in the upstream kernel sources. I firmly stand by if it isn't ready for upstream, it isn't ready for our userbase. We're allowing for a poor level of end user experience when things break their module and their hardware. It would be better off saying that we can't support their hardware in the mainstream AT ALL rather than create empty promises of support that die off the first time the kernel changes something that breaks the 3rd party module. Upstream vendors for the most part won't be too eager to continually update their modules for a Fedora kernel. I've been there and tried that. RHEL kernels carry weight and get attention. Fedora, not so much. -- 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 Sep 20 19:59:28 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Sep 2006 15:59:28 -0400 Subject: [fab] kernel modules In-Reply-To: <4511990B.7010700@redhat.com> References: <200609200949.09070.jkeating@redhat.com> <4511990B.7010700@redhat.com> Message-ID: <200609201559.28192.jkeating@redhat.com> On Wednesday 20 September 2006 15:39, Christopher Blizzard wrote: > We'll learn as we go, and maybe we'll decide that it totally sucks. > (Failure needs to be OK, IMHO. ?If we're not failing we're not trying.) > ? Or maybe we'll learn that we need to change the way the package system > works for the kernel. ?But right now we can't even figure that out > because we're not even willing to try. We've tried it internally with the gfs modules. The modules were maintained internally with full access to the kernel developers and the build system and all that, and it was _still_ a disaster. An utter failure IMHO. I'm not really interested in trying the same thing over and over expecting different results. -- 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 Sep 20 20:06:38 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Sep 2006 16:06:38 -0400 Subject: [fab] kernel modules In-Reply-To: <200609201559.28192.jkeating@redhat.com> References: <200609200949.09070.jkeating@redhat.com> <4511990B.7010700@redhat.com> <200609201559.28192.jkeating@redhat.com> Message-ID: <20060920200638.GB5120@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > We've tried it internally with the gfs modules. The modules were maintained > internally with full access to the kernel developers and the build system and > all that, and it was _still_ a disaster. An utter failure IMHO. I'm not > really interested in trying the same thing over and over expecting different > results. I'm going to go out on a limb and say when we tried it before it wasn't a priority, so I don't think there was much actual effort given to solving the problem well. Bill From jwboyer at jdub.homelinux.org Wed Sep 20 20:15:43 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Sep 2006 15:15:43 -0500 Subject: [fab] kernel modules In-Reply-To: <200609201553.22104.jkeating@redhat.com> References: <200609200949.09070.jkeating@redhat.com> <1158761141.3121.31.camel@zod.rchland.ibm.com> <200609201553.22104.jkeating@redhat.com> Message-ID: <1158783343.3121.61.camel@zod.rchland.ibm.com> On Wed, 2006-09-20 at 15:53 -0400, Jesse Keating wrote: > > keep the module building. We're mostly software packagers here, not driver > developers. Do we want to require our kmod packagers to be competent enough > to keep the module source building on a daily basis? Fedora wants to stick IMHO, yes. Or at least be willing to work with upstream to resolve conflicts. kmods are not something to be taken lightly, and that should be stressed. > close to upstream, but in this case, the kernel.org is the upstream. > Anything else is forks and branches that aren't part of the upstream. Sounds > more like a case for Fedora Unstable or Fedora Bloody Edge Extras. > Definitely not something we want in an actual release. There are arguments for a separate kernel repository. Call it Fedora Bloody Edge Extras You Better Not Enable This if you'd like. josh From jwboyer at jdub.homelinux.org Wed Sep 20 20:18:14 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Sep 2006 15:18:14 -0500 Subject: [fab] kernel modules In-Reply-To: <200609201556.21301.jkeating@redhat.com> References: <200609200949.09070.jkeating@redhat.com> <1158769192.2902.287.camel@viper.local> <200609201556.21301.jkeating@redhat.com> Message-ID: <1158783494.3121.64.camel@zod.rchland.ibm.com> On Wed, 2006-09-20 at 15:56 -0400, Jesse Keating wrote: > mainstream use. If it were, it'd be in the upstream kernel sources. I > firmly stand by if it isn't ready for upstream, it isn't ready for our > userbase. Then why are squashfs or xen carried in the Fedora kernel[1]? Oh, that's right. Because someone takes time to make them compile on a daily basis. Exactly the thing you're ranting against. josh [1] Yes, I know xen has a motivation for upstream. Squashfs is rumored to as well. That doesn't change the fact that neither are upstream and your "if it isn't ready for upstream.." comment just pissed me off. Feel free to ignore this rant now that you've theoretically read it. From kwade at redhat.com Wed Sep 20 20:41:17 2006 From: kwade at redhat.com (Karsten Wade) Date: Wed, 20 Sep 2006 13:41:17 -0700 Subject: [fab] kernel modules In-Reply-To: <1158696268.2838.38.camel@localhost> References: <1158676354.6156.6.camel@localhost.localdomain> <1158680078.3121.2.camel@zod.rchland.ibm.com> <1158696268.2838.38.camel@localhost> Message-ID: <1158784877.2714.300.camel@erato.phig.org> On Tue, 2006-09-19 at 13:04 -0700, Toshio Kuratomi wrote: > * It makes the job of the kernel developers easier because they at least > know the end-user is using a kmod from fedora-extras (and can ask: "if > you rpm -qa |grep kmod does that turn up anything?" whereas a from > source kmod would not leave that evidence.) If all kernel bugs go through triage first, this can be asked and dealt with before distracting kernel developers. Perhaps we can offer that the primary mission of Bug Triage is kernel bugs, so kernel developers can gain the first and best of this support? Some prioritization so that kernel developers can actually have *all* kernel bugs assigned to bug-triage at fedoraproject.org (or whatever) automatically by bugzilla, and know that is not going to be a bottleneck. - 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 gdk at redhat.com Wed Sep 20 20:42:23 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 20 Sep 2006 16:42:23 -0400 (EDT) Subject: [fab] kernel modules In-Reply-To: <4511990B.7010700@redhat.com> References: <1158696268.2838.38.camel@localhost> <200609200949.09070.jkeating@redhat.com> <4511990B.7010700@redhat.com> Message-ID: On Wed, 20 Sep 2006, Christopher Blizzard wrote: > We'll learn as we go, and maybe we'll decide that it totally sucks. > (Failure needs to be OK, IMHO. If we're not failing we're not trying.) +1 here from me. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From jkeating at redhat.com Wed Sep 20 20:52:34 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Sep 2006 16:52:34 -0400 Subject: [fab] kernel modules In-Reply-To: <1158783494.3121.64.camel@zod.rchland.ibm.com> References: <200609201556.21301.jkeating@redhat.com> <1158783494.3121.64.camel@zod.rchland.ibm.com> Message-ID: <200609201652.35038.jkeating@redhat.com> On Wednesday 20 September 2006 16:18, Josh Boyer wrote: > Then why are squashfs or xen carried in the Fedora kernel[1]? ?Oh, > that's right. ?Because someone takes time to make them compile on a > daily basis. ?Exactly the thing you're ranting against. > > josh > > [1] Yes, I know xen has a motivation for upstream. ?Squashfs is rumored > to as well. ?That doesn't change the fact that neither are upstream and > your "if it isn't ready for upstream.." comment just pissed me off. > Feel free to ignore this rant now that you've theoretically read it. These are the 'not yet upstream' things that would be worth shipping, and there are enough people willing to work with the kernel developers IN the kernel source to maintain the patches and modules. I've said before, it it's not ready for upstream, but ready enough for our userbase, they should be packaged with the kernel srpm to avoid the nightmare that is kmod packages. We need to work on ways to make more things acceptable to be packaged in the kernel srpm rather than further propagate the evils of kmod packages. -- 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 Sep 20 21:34:40 2006 From: sundaram at fedoraproject.org (Rahul) Date: Thu, 21 Sep 2006 03:04:40 +0530 Subject: [fab] Alternative kernels? In-Reply-To: <1158781973.3121.52.camel@zod.rchland.ibm.com> References: <4511813B.7010508@fedoraproject.org> <1158777218.12818.12.camel@aglarond.local> <45118CE2.6010704@redhat.com> <1158780122.12818.24.camel@aglarond.local> <451196FD.7070305@fedoraproject.org> <1158781973.3121.52.camel@zod.rchland.ibm.com> Message-ID: <4511B3F0.6010005@fedoraproject.org> Josh Boyer wrote: > >>> And that's ignoring the questions of currency and handling of security >>> errata, which is already hard enough. >> Yes. A good maintainer would be required. Fortunately, in both these >> case we have one. RT patch set is being pushed very heavily upstream by >> Ingo and is expected to take a few revisions. > > Does Ingo want to maintain a kernel _package_ though? > He doesnt have to. The Planet CCRMA people already do and they are interested to integrating stuff into Fedora Extras. See fedora-music list for details. Rahul From sundaram at fedoraproject.org Thu Sep 21 15:16:57 2006 From: sundaram at fedoraproject.org (Rahul) Date: Thu, 21 Sep 2006 20:46:57 +0530 Subject: [fab] Fedora Core steering committee and public weekly meetings Message-ID: <4512ACE9.7020305@fedoraproject.org> Hi $subject is what would make Fedora Core qualify as a good sub project. Currently there is a lot of active development obviously but there isnt much visibility into the decision making processes and who is involved. My suggestion would be get the release engineering team and a few people preferably some external to Red Hat to be part of the Fedora Core steering committee and hold public weekly meetings in #fedora-devel in a predetermined schedule and post meeting logs etc in a similar fashion to Fedora Ambassadors or FESCo meetings. Comments? Rahul From notting at redhat.com Thu Sep 21 16:39:07 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 Sep 2006 12:39:07 -0400 Subject: [fab] Alternative kernels? In-Reply-To: <4511B3F0.6010005@fedoraproject.org> References: <4511813B.7010508@fedoraproject.org> <1158777218.12818.12.camel@aglarond.local> <45118CE2.6010704@redhat.com> <1158780122.12818.24.camel@aglarond.local> <451196FD.7070305@fedoraproject.org> <1158781973.3121.52.camel@zod.rchland.ibm.com> <4511B3F0.6010005@fedoraproject.org> Message-ID: <20060921163907.GD18249@nostromo.devel.redhat.com> Rahul (sundaram at fedoraproject.org) said: > He doesnt have to. The Planet CCRMA people already do and they are > interested to integrating stuff into Fedora Extras. See fedora-music > list for details. Perhaps a policy of "if you want to maintain an alternative kernel, you have to maintain your own repository" (i.e., not Core/Extras.) Bill From sundaram at fedoraproject.org Thu Sep 21 16:40:54 2006 From: sundaram at fedoraproject.org (Rahul) Date: Thu, 21 Sep 2006 22:10:54 +0530 Subject: [fab] Alternative kernels? In-Reply-To: <20060921163907.GD18249@nostromo.devel.redhat.com> References: <4511813B.7010508@fedoraproject.org> <1158777218.12818.12.camel@aglarond.local> <45118CE2.6010704@redhat.com> <1158780122.12818.24.camel@aglarond.local> <451196FD.7070305@fedoraproject.org> <1158781973.3121.52.camel@zod.rchland.ibm.com> <4511B3F0.6010005@fedoraproject.org> <20060921163907.GD18249@nostromo.devel.redhat.com> Message-ID: <4512C096.8040102@fedoraproject.org> Bill Nottingham wrote: > Rahul (sundaram at fedoraproject.org) said: >> He doesnt have to. The Planet CCRMA people already do and they are >> interested to integrating stuff into Fedora Extras. See fedora-music >> list for details. > > Perhaps a policy of "if you want to maintain an alternative kernel, > you have to maintain your own repository" (i.e., not Core/Extras.) > Integrated into Fedora or a third party repository which we wont touch? Rahul From notting at redhat.com Thu Sep 21 16:41:19 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 Sep 2006 12:41:19 -0400 Subject: [fab] Fedora Core steering committee and public weekly meetings In-Reply-To: <4512ACE9.7020305@fedoraproject.org> References: <4512ACE9.7020305@fedoraproject.org> Message-ID: <20060921164119.GE18249@nostromo.devel.redhat.com> Rahul (sundaram at fedoraproject.org) said: > $subject is what would make Fedora Core qualify as a good sub project. > Currently there is a lot of active development obviously but there isnt > much visibility into the decision making processes and who is involved. > > My suggestion would be get the release engineering team and a few people > preferably some external to Red Hat to be part of the Fedora Core > steering committee and hold public weekly meetings in #fedora-devel in a > predetermined schedule and post meeting logs etc in a similar fashion to > Fedora Ambassadors or FESCo meetings. Well, it currently *has* a committee, we just don't have public meetings or logs. Bill From notting at redhat.com Thu Sep 21 16:42:20 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 Sep 2006 12:42:20 -0400 Subject: [fab] Alternative kernels? In-Reply-To: <4512C096.8040102@fedoraproject.org> References: <4511813B.7010508@fedoraproject.org> <1158777218.12818.12.camel@aglarond.local> <45118CE2.6010704@redhat.com> <1158780122.12818.24.camel@aglarond.local> <451196FD.7070305@fedoraproject.org> <1158781973.3121.52.camel@zod.rchland.ibm.com> <4511B3F0.6010005@fedoraproject.org> <20060921163907.GD18249@nostromo.devel.redhat.com> <4512C096.8040102@fedoraproject.org> Message-ID: <20060921164220.GF18249@nostromo.devel.redhat.com> Rahul (sundaram at fedoraproject.org) said: > >Perhaps a policy of "if you want to maintain an alternative kernel, > >you have to maintain your own repository" (i.e., not Core/Extras.) > > Integrated into Fedora or a third party repository which we wont touch? The latter. I think a repository of *just* alternative kernels would lead to complete update madness. Bill From bpepple at fedoraproject.org Thu Sep 21 16:44:17 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 21 Sep 2006 12:44:17 -0400 Subject: [fab] Fedora Core steering committee and public weekly meetings In-Reply-To: <4512ACE9.7020305@fedoraproject.org> References: <4512ACE9.7020305@fedoraproject.org> Message-ID: <1158857057.6378.1.camel@shuttle.piedmont.com> On Thu, 2006-09-21 at 20:46 +0530, Rahul wrote: > $subject is what would make Fedora Core qualify as a good sub project. > Currently there is a lot of active development obviously but there isnt > much visibility into the decision making processes and who is involved. > > My suggestion would be get the release engineering team and a few people > preferably some external to Red Hat to be part of the Fedora Core > steering committee and hold public weekly meetings in #fedora-devel in a > predetermined schedule and post meeting logs etc in a similar fashion to > Fedora Ambassadors or FESCo meetings. That sounds like a good idea. More transparency in discussions is a good thing in my opinion. /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 blizzard at redhat.com Thu Sep 21 16:56:46 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 21 Sep 2006 12:56:46 -0400 Subject: [fab] Fedora Core steering committee and public weekly meetings In-Reply-To: <20060921164119.GE18249@nostromo.devel.redhat.com> References: <4512ACE9.7020305@fedoraproject.org> <20060921164119.GE18249@nostromo.devel.redhat.com> Message-ID: <4512C44E.3000502@redhat.com> Bill Nottingham wrote: > Well, it currently *has* a committee, we just don't have public meetings > or logs. Only a TRAIL OF BODIES remains in your wake. --Chris From blizzard at redhat.com Thu Sep 21 17:00:37 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 21 Sep 2006 13:00:37 -0400 Subject: [fab] Alternative kernels? In-Reply-To: <20060921164220.GF18249@nostromo.devel.redhat.com> References: <4511813B.7010508@fedoraproject.org> <1158777218.12818.12.camel@aglarond.local> <45118CE2.6010704@redhat.com> <1158780122.12818.24.camel@aglarond.local> <451196FD.7070305@fedoraproject.org> <1158781973.3121.52.camel@zod.rchland.ibm.com> <4511B3F0.6010005@fedoraproject.org> <20060921163907.GD18249@nostromo.devel.redhat.com> <4512C096.8040102@fedoraproject.org> <20060921164220.GF18249@nostromo.devel.redhat.com> Message-ID: <4512C535.1090504@redhat.com> Bill Nottingham wrote: > Rahul (sundaram at fedoraproject.org) said: >>> Perhaps a policy of "if you want to maintain an alternative kernel, >>> you have to maintain your own repository" (i.e., not Core/Extras.) >> Integrated into Fedora or a third party repository which we wont touch? > > The latter. I think a repository of *just* alternative kernels would > lead to complete update madness. This is the kind of thing that David's livecd stuff does pretty well. Basically, if you want this Fedora variant, you build a livecd and install/run from there. --Chris From jwboyer at jdub.homelinux.org Thu Sep 21 17:29:28 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 21 Sep 2006 12:29:28 -0500 Subject: [fab] Fedora Core steering committee and public weekly meetings In-Reply-To: <20060921164119.GE18249@nostromo.devel.redhat.com> References: <4512ACE9.7020305@fedoraproject.org> <20060921164119.GE18249@nostromo.devel.redhat.com> Message-ID: <1158859768.3121.87.camel@zod.rchland.ibm.com> On Thu, 2006-09-21 at 12:41 -0400, Bill Nottingham wrote: > Rahul (sundaram at fedoraproject.org) said: > > $subject is what would make Fedora Core qualify as a good sub project. > > Currently there is a lot of active development obviously but there isnt > > much visibility into the decision making processes and who is involved. > > > > My suggestion would be get the release engineering team and a few people > > preferably some external to Red Hat to be part of the Fedora Core > > steering committee and hold public weekly meetings in #fedora-devel in a > > predetermined schedule and post meeting logs etc in a similar fashion to > > Fedora Ambassadors or FESCo meetings. > > Well, it currently *has* a committee, we just don't have public meetings > or logs. Who is on the committee? And is there any reason they couldn't be public? josh From rdieter at math.unl.edu Thu Sep 21 17:32:21 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 21 Sep 2006 12:32:21 -0500 Subject: [fab] Fedora Core steering committee and public weekly meetings In-Reply-To: <4512C44E.3000502@redhat.com> References: <4512ACE9.7020305@fedoraproject.org> <20060921164119.GE18249@nostromo.devel.redhat.com> <4512C44E.3000502@redhat.com> Message-ID: <4512CCA5.2020106@math.unl.edu> Christopher Blizzard wrote: > Bill Nottingham wrote: >> Well, it currently *has* a committee, we just don't have public meetings >> or logs. > > Only a TRAIL OF BODIES remains in your wake. Yeah, but we want those bodies documented, for posterity, of course. :) -- Rex From notting at redhat.com Thu Sep 21 17:33:22 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 Sep 2006 13:33:22 -0400 Subject: [fab] Fedora Core steering committee and public weekly meetings In-Reply-To: <1158859768.3121.87.camel@zod.rchland.ibm.com> References: <4512ACE9.7020305@fedoraproject.org> <20060921164119.GE18249@nostromo.devel.redhat.com> <1158859768.3121.87.camel@zod.rchland.ibm.com> Message-ID: <20060921173322.GA11716@nostromo.devel.redhat.com> Josh Boyer (jwboyer at jdub.homelinux.org) said: > > Well, it currently *has* a committee, we just don't have public meetings > > or logs. > > Who is on the committee? And is there any reason they couldn't be > public? Erm, s/public // in the original statement. That should answer your question. :) Bill From jwboyer at jdub.homelinux.org Thu Sep 21 17:37:52 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 21 Sep 2006 12:37:52 -0500 Subject: [fab] Fedora Core steering committee and public weekly meetings In-Reply-To: <20060921173322.GA11716@nostromo.devel.redhat.com> References: <4512ACE9.7020305@fedoraproject.org> <20060921164119.GE18249@nostromo.devel.redhat.com> <1158859768.3121.87.camel@zod.rchland.ibm.com> <20060921173322.GA11716@nostromo.devel.redhat.com> Message-ID: <1158860272.3121.89.camel@zod.rchland.ibm.com> On Thu, 2006-09-21 at 13:33 -0400, Bill Nottingham wrote: > Josh Boyer (jwboyer at jdub.homelinux.org) said: > > > Well, it currently *has* a committee, we just don't have public meetings > > > or logs. > > > > Who is on the committee? And is there any reason they couldn't be > > public? > > Erm, s/public // in the original statement. That should answer your question. :) Well, it answers the latter question. The one I'm most interested in is, who is on the committee? josh From notting at redhat.com Thu Sep 21 17:42:26 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 Sep 2006 13:42:26 -0400 Subject: [fab] Fedora Core steering committee and public weekly meetings In-Reply-To: <1158860272.3121.89.camel@zod.rchland.ibm.com> References: <4512ACE9.7020305@fedoraproject.org> <20060921164119.GE18249@nostromo.devel.redhat.com> <1158859768.3121.87.camel@zod.rchland.ibm.com> <20060921173322.GA11716@nostromo.devel.redhat.com> <1158860272.3121.89.camel@zod.rchland.ibm.com> Message-ID: <20060921174226.GB15604@nostromo.devel.redhat.com> Josh Boyer (jwboyer at jdub.homelinux.org) said: > Well, it answers the latter question. The one I'm most interested in > is, who is on the committee? ATM, myself, Jeremy Katz, and Jesse Keating. Bill From jkeating at redhat.com Thu Sep 21 17:50:11 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 21 Sep 2006 13:50:11 -0400 Subject: [fab] Fedora Core steering committee and public weekly meetings In-Reply-To: <20060921174226.GB15604@nostromo.devel.redhat.com> References: <4512ACE9.7020305@fedoraproject.org> <1158860272.3121.89.camel@zod.rchland.ibm.com> <20060921174226.GB15604@nostromo.devel.redhat.com> Message-ID: <200609211350.12017.jkeating@redhat.com> On Thursday 21 September 2006 13:42, Bill Nottingham wrote: > ATM, myself, Jeremy Katz, and Jesse Keating. This is not the cabal you are looking for... We do need a more public Core Technical Board to handle these things. -- 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 Thu Sep 21 17:54:37 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 Sep 2006 13:54:37 -0400 Subject: [fab] Fedora Core steering committee and public weekly meetings In-Reply-To: <200609211350.12017.jkeating@redhat.com> References: <4512ACE9.7020305@fedoraproject.org> <1158860272.3121.89.camel@zod.rchland.ibm.com> <20060921174226.GB15604@nostromo.devel.redhat.com> <200609211350.12017.jkeating@redhat.com> Message-ID: <20060921175437.GA15787@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > This is not the cabal you are looking for... > > We do need a more public Core Technical Board to handle these things. Which things? I.e., what sorts of decisions that have been made do people want documentation of, or what sorts of things are they looking for? Bill From jkeating at redhat.com Thu Sep 21 17:59:55 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 21 Sep 2006 13:59:55 -0400 Subject: [fab] Fedora Core steering committee and public weekly meetings In-Reply-To: <20060921175437.GA15787@nostromo.devel.redhat.com> References: <4512ACE9.7020305@fedoraproject.org> <200609211350.12017.jkeating@redhat.com> <20060921175437.GA15787@nostromo.devel.redhat.com> Message-ID: <200609211359.59395.jkeating@redhat.com> On Thursday 21 September 2006 13:54, Bill Nottingham wrote: > Which things? I.e., what sorts of decisions that have been made do > people want documentation of, or what sorts of things are they looking > for? Discussions regarding schedule slips, criteria for blocker bugs, discussion of proposed blockers and waives when release time comes up, discussion regarding technical aspect of the distro, like tree layout, package sets, feature stuff. There is a fair amount we decide on the fly that could be more open or at least transparent. -- 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 Sep 21 18:02:33 2006 From: sundaram at fedoraproject.org (Rahul) Date: Thu, 21 Sep 2006 23:32:33 +0530 Subject: [fab] Fedora Core steering committee and public weekly meetings In-Reply-To: <200609211359.59395.jkeating@redhat.com> References: <4512ACE9.7020305@fedoraproject.org> <200609211350.12017.jkeating@redhat.com> <20060921175437.GA15787@nostromo.devel.redhat.com> <200609211359.59395.jkeating@redhat.com> Message-ID: <4512D3B9.70801@fedoraproject.org> Jesse Keating wrote: > On Thursday 21 September 2006 13:54, Bill Nottingham wrote: >> Which things? I.e., what sorts of decisions that have been made do >> people want documentation of, or what sorts of things are they looking >> for? > > Discussions regarding schedule slips, criteria for blocker bugs, discussion of > proposed blockers and waives when release time comes up, discussion regarding > technical aspect of the distro, like tree layout, package sets, feature > stuff. There is a fair amount we decide on the fly that could be more open > or at least transparent. Post release critical bug fixes too. Rahul From notting at redhat.com Thu Sep 21 18:06:24 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 Sep 2006 14:06:24 -0400 Subject: [fab] Fedora Core steering committee and public weekly meetings In-Reply-To: <4512D3B9.70801@fedoraproject.org> References: <4512ACE9.7020305@fedoraproject.org> <200609211350.12017.jkeating@redhat.com> <20060921175437.GA15787@nostromo.devel.redhat.com> <200609211359.59395.jkeating@redhat.com> <4512D3B9.70801@fedoraproject.org> Message-ID: <20060921180624.GA16070@nostromo.devel.redhat.com> Rahul (sundaram at fedoraproject.org) said: > Post release critical bug fixes too. So.... this is not done for extras - do we have a committee that disallows extras builds based on schedule timeframe? Should we? Bill From notting at redhat.com Thu Sep 21 18:25:49 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 Sep 2006 14:25:49 -0400 Subject: [fab] Fedora Core steering committee and public weekly meetings In-Reply-To: <200609211359.59395.jkeating@redhat.com> References: <4512ACE9.7020305@fedoraproject.org> <200609211350.12017.jkeating@redhat.com> <20060921175437.GA15787@nostromo.devel.redhat.com> <200609211359.59395.jkeating@redhat.com> Message-ID: <20060921182549.GA16401@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > On Thursday 21 September 2006 13:54, Bill Nottingham wrote: > > Which things? I.e., what sorts of decisions that have been made do > > people want documentation of, or what sorts of things are they looking > > for? > > Discussions regarding schedule slips, criteria for blocker bugs, discussion of > proposed blockers and waives when release time comes up, These things seem to be all release committee things, which, despite your statement of 'this is not the cabal you're looking for', seem to fall squarely into that category. Bill From sundaram at fedoraproject.org Thu Sep 21 18:43:08 2006 From: sundaram at fedoraproject.org (Rahul) Date: Fri, 22 Sep 2006 00:13:08 +0530 Subject: [fab] Fedora Core steering committee and public weekly meetings In-Reply-To: <20060921180624.GA16070@nostromo.devel.redhat.com> References: <4512ACE9.7020305@fedoraproject.org> <200609211350.12017.jkeating@redhat.com> <20060921175437.GA15787@nostromo.devel.redhat.com> <200609211359.59395.jkeating@redhat.com> <4512D3B9.70801@fedoraproject.org> <20060921180624.GA16070@nostromo.devel.redhat.com> Message-ID: <4512DD3C.3000101@fedoraproject.org> Bill Nottingham wrote: > Rahul (sundaram at fedoraproject.org) said: >> Post release critical bug fixes too. > > So.... this is not done for extras - do we have a committee that disallows > extras builds based on schedule timeframe? Should we? > > Bill If we are going to move KDE into extras and I assuming that we are moving with that process immediately post FC6 release, then Fedora Extras on media is a pre requisite to that. Moving off from a rolling release model would mean that the release engineering team (current or expanded) should handle freeze processes in extras too. I have already stated my opinion that I would prefer a technical committee that covers both Fedora Core and Extras and merge FESCo into it. I wanted core to work as a project in a very similar public fashion to other sub projects before that happens as a first step but if we can do all at the same time, then its even better. There are a number of other things that are tied together. Open up core, open up brew or just move into using plague and external build systems, open the compose tool or write a new one, move into a distributed SCM, release live cd's with a hard disk installation feature for those who dont want to download all of Fedora (core+extras) as CD/DVD's and a live cd tool to do variations of it. If the variations are a pure subset of core+extras repository it can be called Fedora , otherwise not. Fedora Project would then initially do one release of the Live CD thing (assuming GNOME here) and let the community do whatever other variations it wants. In this model, KDE wouldnt move over to extras (they wouldnt a extras). We can just change maintainers without a fuss and KDE SIG or whatever can do Fedora KDE live CD's to promote it. In my mind, the governance model should be Fedora Board | FAB(Community issues) Fedora Technical Committee (Packaging committee as a subset) | Sub project Steering Committee's The Board lead with veto power is a non elected position within Red Hat (currently served by Max Spevack). Rest of the board and sub project steering committee's can be elected. FAB, Fedora technical and packaging committee is not. The Board hand picks them. Rahul From jkeating at redhat.com Thu Sep 21 19:15:11 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 21 Sep 2006 15:15:11 -0400 Subject: [fab] Fedora Core steering committee and public weekly meetings In-Reply-To: <20060921182549.GA16401@nostromo.devel.redhat.com> References: <4512ACE9.7020305@fedoraproject.org> <200609211359.59395.jkeating@redhat.com> <20060921182549.GA16401@nostromo.devel.redhat.com> Message-ID: <200609211515.11183.jkeating@redhat.com> On Thursday 21 September 2006 14:25, Bill Nottingham wrote: > These things seem to be all release committee things, which, despite > your statement of 'this is not the cabal you're looking for', seem > to fall squarely into that category. Sorry, that was supposed to be a joke. Sure, these are all release committee things, which I think fall into the perview of a Core Technical board or whathaveyou. I guess I need more sleep before I start making jokes again (: -- 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 davidz at redhat.com Fri Sep 22 06:10:52 2006 From: davidz at redhat.com (David Zeuthen) Date: Fri, 22 Sep 2006 02:10:52 -0400 Subject: [fab] Alternative kernels? In-Reply-To: <45118CE2.6010704@redhat.com> References: <4511813B.7010508@fedoraproject.org> <1158777218.12818.12.camel@aglarond.local> <45118CE2.6010704@redhat.com> Message-ID: <1158905452.2440.224.camel@zelda.fubar.dk> On Wed, 2006-09-20 at 14:48 -0400, Christopher Blizzard wrote: > I'm happy to enable there to be > 1 kernel, but it's hard because of the > way that our packaging systems work. We're doing this right now for > OLPC, based on David and Marcelo's work, but I'm not sure what the > mechanism is to make sure that the OLPC kernel always wins. It's ugly. Basically exclude=kernel for the yum configuration file for the FC repo. That'll break nicely when fedora-release is updated, but then again, one rule for derived distros is that they should provide their own mydistro-release that Provides:fedora-release. Ie. they need to provide their own yum configuration files. Hardly optimal. David From tiemann at redhat.com Wed Sep 27 12:41:57 2006 From: tiemann at redhat.com (Michael Tiemann) Date: Wed, 27 Sep 2006 08:41:57 -0400 Subject: [fab] OpenID: an actually distributed identity system Message-ID: <1159360917.4346.14.camel@localhost.localdomain> I saw OpenID ( http://openid.net/ ) presented and demonstrated at EuroOSCON last week--it looked really cool. My reason for writing this morning is because on another list (grass-dev at grass.itc.it) developers are bemoaning the problem of (1) spam in their bugtracker, and (2) their desire to keep the bugtracker open and not require that users sign up for an account before using the system. I understand there is a similar question being discussed about just how open to make the Fedora Wiki (not the CVS repository, but the Wiki). I, too, hate the fact that I have to manage so many identities on the web, and I, too, wish there were a decent single sign-on for me to use with my favorite websites. I'd like to suggest OpenID as a possible candidate for solving that problem and see whether enough people on this list agree to push it into the Fedora infrastructure. M From sundaram at fedoraproject.org Wed Sep 27 12:53:12 2006 From: sundaram at fedoraproject.org (Rahul) Date: Wed, 27 Sep 2006 18:23:12 +0530 Subject: [fab] OpenID: an actually distributed identity system In-Reply-To: <1159360917.4346.14.camel@localhost.localdomain> References: <1159360917.4346.14.camel@localhost.localdomain> Message-ID: <451A7438.1000909@fedoraproject.org> Michael Tiemann wrote: > I saw OpenID ( http://openid.net/ ) presented and demonstrated at > EuroOSCON last week--it looked really cool. My reason for writing this > morning is because on another list (grass-dev at grass.itc.it) developers > are bemoaning the problem of (1) spam in their bugtracker, and (2) their > desire to keep the bugtracker open and not require that users sign up > for an account before using the system. > > I understand there is a similar question being discussed about just how > open to make the Fedora Wiki (not the CVS repository, but the Wiki). > > I, too, hate the fact that I have to manage so many identities on the > web, and I, too, wish there were a decent single sign-on for me to use > with my favorite websites. I'd like to suggest OpenID as a possible > candidate for solving that problem and see whether enough people on this > list agree to push it into the Fedora infrastructure. > > M Its not the requirement of the CLA itself for the wiki that is a big problem but the process. If it's just a click through method I suspect we wouldnt have any complaints at all. Rahul From skvidal at linux.duke.edu Wed Sep 27 13:01:50 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 27 Sep 2006 09:01:50 -0400 Subject: [fab] OpenID: an actually distributed identity system In-Reply-To: <1159360917.4346.14.camel@localhost.localdomain> References: <1159360917.4346.14.camel@localhost.localdomain> Message-ID: <1159362110.6281.17.camel@cutter> On Wed, 2006-09-27 at 08:41 -0400, Michael Tiemann wrote: > I saw OpenID ( http://openid.net/ ) presented and demonstrated at > EuroOSCON last week--it looked really cool. My reason for writing this > morning is because on another list (grass-dev at grass.itc.it) developers > are bemoaning the problem of (1) spam in their bugtracker, and (2) their > desire to keep the bugtracker open and not require that users sign up > for an account before using the system. > > I understand there is a similar question being discussed about just how > open to make the Fedora Wiki (not the CVS repository, but the Wiki). > > I, too, hate the fact that I have to manage so many identities on the > web, and I, too, wish there were a decent single sign-on for me to use > with my favorite websites. I'd like to suggest OpenID as a possible > candidate for solving that problem and see whether enough people on this > list agree to push it into the Fedora infrastructure. - moinmoin has been 'openid enabled' - but only in 1.5.X - not the version we're using right now - 1.3.X. We should be able to move to it - but it will be an involved process, I'm sure. Not the least of which is getting all the people to now create openid accounts. And this says nothing of the need for the CLA that we require. - mailman - it has been openid enabled but not in the upstream release. Patches are available. - bugzilla appears to be completely out in the cold which means there would be a need for someone to do the programming and, theoretically, submitting the patches upstream. So we'd have to refit a good portion of our infrastructure (some of which also serves @redhat.com not just fedora) and we'd have to get our users to migrate to the new login mechanism. I'm not saying it's impossible but I think we're looking at a development time and migration path that IF we have people willing to undertake it will take greater than a year. -sv From mmcgrath at fedoraproject.org Wed Sep 27 13:06:34 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 27 Sep 2006 08:06:34 -0500 Subject: [fab] OpenID: an actually distributed identity system In-Reply-To: <1159362110.6281.17.camel@cutter> References: <1159360917.4346.14.camel@localhost.localdomain> <1159362110.6281.17.camel@cutter> Message-ID: <3237e4410609270606m12b9aac6oe7b939d0d5889cd4@mail.gmail.com> On 9/27/06, seth vidal wrote: > On Wed, 2006-09-27 at 08:41 -0400, Michael Tiemann wrote: > - moinmoin has been 'openid enabled' - but only in 1.5.X - not the > version we're using right now - 1.3.X. We should be able to move to it - > but it will be an involved process, I'm sure. Not the least of which is > getting all the people to now create openid accounts. And this says > nothing of the need for the CLA that we require. > > - mailman - it has been openid enabled but not in the upstream release. > Patches are available. > > - bugzilla appears to be completely out in the cold which means there > would be a need for someone to do the programming and, theoretically, > submitting the patches upstream. > > So we'd have to refit a good portion of our infrastructure (some of > which also serves @redhat.com not just fedora) and we'd have to get our > users to migrate to the new login mechanism. I'm not saying it's > impossible but I think we're looking at a development time and migration > path that IF we have people willing to undertake it will take greater > than a year. > > -sv > We're re-designing the accounting system right now anyway, we could certainly look into doing something like this. For those that don't know here's the draft page: http://fedoraproject.org/wiki/Infrastructure/AccountSystem2/ -Mike From skvidal at linux.duke.edu Wed Sep 27 13:14:07 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 27 Sep 2006 09:14:07 -0400 Subject: [fab] OpenID: an actually distributed identity system In-Reply-To: <3237e4410609270606m12b9aac6oe7b939d0d5889cd4@mail.gmail.com> References: <1159360917.4346.14.camel@localhost.localdomain> <1159362110.6281.17.camel@cutter> <3237e4410609270606m12b9aac6oe7b939d0d5889cd4@mail.gmail.com> Message-ID: <1159362847.6281.21.camel@cutter> On Wed, 2006-09-27 at 08:06 -0500, Mike McGrath wrote: > On 9/27/06, seth vidal wrote: > > On Wed, 2006-09-27 at 08:41 -0400, Michael Tiemann wrote: > > - moinmoin has been 'openid enabled' - but only in 1.5.X - not the > > version we're using right now - 1.3.X. We should be able to move to it - > > but it will be an involved process, I'm sure. Not the least of which is > > getting all the people to now create openid accounts. And this says > > nothing of the need for the CLA that we require. > > > > - mailman - it has been openid enabled but not in the upstream release. > > Patches are available. > > > > - bugzilla appears to be completely out in the cold which means there > > would be a need for someone to do the programming and, theoretically, > > submitting the patches upstream. > > > > So we'd have to refit a good portion of our infrastructure (some of > > which also serves @redhat.com not just fedora) and we'd have to get our > > users to migrate to the new login mechanism. I'm not saying it's > > impossible but I think we're looking at a development time and migration > > path that IF we have people willing to undertake it will take greater > > than a year. > > > > -sv > > > > We're re-designing the accounting system right now anyway, we could > certainly look into doing something like this. For those that don't > know here's the draft page: > > http://fedoraproject.org/wiki/Infrastructure/AccountSystem2/ > I just don't want anyone getting their hopes up for a quick turnaround. -sv From gdk at redhat.com Wed Sep 27 20:12:41 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 27 Sep 2006 16:12:41 -0400 (EDT) Subject: [fab] OpenID: an actually distributed identity system In-Reply-To: <1159360917.4346.14.camel@localhost.localdomain> References: <1159360917.4346.14.camel@localhost.localdomain> Message-ID: A big +1. In fact: For FC7, I think that creating an OpenID account should be part of Fedora firstboot. Create your Fedora wiki account, your bugzilla account, and your everything-else account in one swell foop. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- On Wed, 27 Sep 2006, Michael Tiemann wrote: > I saw OpenID ( http://openid.net/ ) presented and demonstrated at > EuroOSCON last week--it looked really cool. My reason for writing this > morning is because on another list (grass-dev at grass.itc.it) developers > are bemoaning the problem of (1) spam in their bugtracker, and (2) their > desire to keep the bugtracker open and not require that users sign up > for an account before using the system. > > I understand there is a similar question being discussed about just how > open to make the Fedora Wiki (not the CVS repository, but the Wiki). > > I, too, hate the fact that I have to manage so many identities on the > web, and I, too, wish there were a decent single sign-on for me to use > with my favorite websites. I'd like to suggest OpenID as a possible > candidate for solving that problem and see whether enough people on this > list agree to push it into the Fedora infrastructure. > > M > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > From skvidal at linux.duke.edu Wed Sep 27 21:24:12 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 27 Sep 2006 17:24:12 -0400 Subject: [fab] OpenID: an actually distributed identity system In-Reply-To: References: <1159360917.4346.14.camel@localhost.localdomain> Message-ID: <1159392252.6281.52.camel@cutter> On Wed, 2006-09-27 at 16:12 -0400, Greg DeKoenigsberg wrote: > A big +1. > > In fact: > > For FC7, I think that creating an OpenID account should be part of Fedora > firstboot. Create your Fedora wiki account, your bugzilla account, and > your everything-else account in one swell foop. > I'm pretty sure we can't count on network access for firstboot. However, given how openid works do we want to consider becoming an identity provider as a part of the account system? -sv From notting at redhat.com Wed Sep 27 21:30:50 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 27 Sep 2006 17:30:50 -0400 Subject: [fab] OpenID: an actually distributed identity system In-Reply-To: <1159392252.6281.52.camel@cutter> References: <1159360917.4346.14.camel@localhost.localdomain> <1159392252.6281.52.camel@cutter> Message-ID: <20060927213050.GA16895@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > However, given how openid works do we want to consider becoming an > identity provider as a part of the account system? Everybody gets a fedoraproject.org e-mail w/openid? Bill From gdk at redhat.com Wed Sep 27 21:28:56 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 27 Sep 2006 17:28:56 -0400 (EDT) Subject: [fab] OpenID: an actually distributed identity system In-Reply-To: <1159392252.6281.52.camel@cutter> References: <1159360917.4346.14.camel@localhost.localdomain> <1159392252.6281.52.camel@cutter> Message-ID: On Wed, 27 Sep 2006, seth vidal wrote: > > For FC7, I think that creating an OpenID account should be part of Fedora > > firstboot. Create your Fedora wiki account, your bugzilla account, and > > your everything-else account in one swell foop. > > I'm pretty sure we can't count on network access for firstboot. No, but we can surely figure out how to fail gracefully like RHEL/RHN does. Networked version: "create your openID or enter your openID now." Non-networked version: "don't forget to go to openid.fedoraproject.org." > However, given how openid works do we want to consider becoming an > identity provider as a part of the account system? Absolutely no reason we can't do both. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From skvidal at linux.duke.edu Thu Sep 28 03:24:49 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 27 Sep 2006 23:24:49 -0400 Subject: [fab] OpenID: an actually distributed identity system In-Reply-To: <20060927213050.GA16895@nostromo.devel.redhat.com> References: <1159360917.4346.14.camel@localhost.localdomain> <1159392252.6281.52.camel@cutter> <20060927213050.GA16895@nostromo.devel.redhat.com> Message-ID: <1159413890.6281.56.camel@cutter> On Wed, 2006-09-27 at 17:30 -0400, Bill Nottingham wrote: > seth vidal (skvidal at linux.duke.edu) said: > > However, given how openid works do we want to consider becoming an > > identity provider as a part of the account system? > > Everybody gets a fedoraproject.org e-mail w/openid? > no. everybody who is a member of the fedoraproject can have an openid. -sv From tiemann at redhat.com Fri Sep 29 15:44:51 2006 From: tiemann at redhat.com (Michael Tiemann) Date: Fri, 29 Sep 2006 11:44:51 -0400 Subject: [fab] [Fwd: ebay and open source] Message-ID: <1159544692.5874.7.camel@localhost.localdomain> Seems to me we need to educate eBay... M -------------- next part -------------- An embedded message was scrubbed... From: "Tops Ops" Subject: ebay and open source Date: Thu, 28 Sep 2006 20:04:07 -0700 Size: 7763 URL: From gdk at redhat.com Fri Sep 29 17:07:31 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Fri, 29 Sep 2006 13:07:31 -0400 (EDT) Subject: [fab] [Fwd: ebay and open source] In-Reply-To: <1159544692.5874.7.camel@localhost.localdomain> References: <1159544692.5874.7.camel@localhost.localdomain> Message-ID: I'm sending them a note now -- through their insane customer service matrix. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- On Fri, 29 Sep 2006, Michael Tiemann wrote: > Seems to me we need to educate eBay... > > M > From amaier at redhat.com Fri Sep 29 17:33:30 2006 From: amaier at redhat.com (Alex Maier) Date: Fri, 29 Sep 2006 13:33:30 -0400 Subject: [fab] [Fwd: ebay and open source] In-Reply-To: References: <1159544692.5874.7.camel@localhost.localdomain> Message-ID: <1159551210.5584.18.camel@localhost.localdomain> Just a $0.02 -- I know a case exactly like this one when someones auction has been closed for selling copies of Linux install media. This sucks. On Fri, 2006-09-29 at 13:07 -0400, Greg DeKoenigsberg wrote: > I'm sending them a note now -- through their insane customer service > matrix. > > --g > > ------------------------------------------------------------- > Greg DeKoenigsberg || Fedora Project || fedoraproject.org > Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors > ------------------------------------------------------------- > > On Fri, 29 Sep 2006, Michael Tiemann wrote: > > > Seems to me we need to educate eBay... > > > > M > > > > _______________________________________________ > 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 rdieter at math.unl.edu Fri Sep 29 18:22:23 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 29 Sep 2006 13:22:23 -0500 Subject: [fab] FSF Licensing Audit Status In-Reply-To: <1155594111.5633.33.camel@localhost.localdomain> References: <1155594111.5633.33.camel@localhost.localdomain> Message-ID: <451D645F.2000606@math.unl.edu> Tom Callaway wrote: > THE KNOWN UNKNOWNS (6): > Packages of questionable licenses that need to be blessed or damned by > the FSF: > ####################################################################### > PACKAGE NAME || RPM provided license || Notes > ####################################################################### ... > libc-client-* || U of W Free Fork || Waiting on FSF FYI, libc-client (aka imap, aka uw-imap) license has changed to Apache 2.0 since imap-2006. -- Rex From blizzard at redhat.com Fri Sep 29 18:27:30 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 29 Sep 2006 14:27:30 -0400 Subject: [fab] FSF Licensing Audit Status In-Reply-To: <451D645F.2000606@math.unl.edu> References: <1155594111.5633.33.camel@localhost.localdomain> <451D645F.2000606@math.unl.edu> Message-ID: <451D6592.20604@redhat.com> Rex Dieter wrote: > > FYI, libc-client (aka imap, aka uw-imap) license has changed to Apache > 2.0 since imap-2006. Wait, including pine, etc? From rdieter at math.unl.edu Fri Sep 29 18:34:34 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 29 Sep 2006 13:34:34 -0500 Subject: [fab] FSF Licensing Audit Status In-Reply-To: <451D6592.20604@redhat.com> References: <1155594111.5633.33.camel@localhost.localdomain> <451D645F.2000606@math.unl.edu> <451D6592.20604@redhat.com> Message-ID: <451D673A.9080607@math.unl.edu> Christopher Blizzard wrote: > Rex Dieter wrote: > >> >> FYI, libc-client (aka imap, aka uw-imap) license has changed to Apache >> 2.0 since imap-2006. > > Wait, including pine, etc? For now, at least, just imap, per http://www.washington.edu/imap/ ------------------------ The University of Washington licenses the source code of the UW IMAP toolkit, imap-2006 and later, under the Apache License, Version 2.0. ------------------------ -- Rex From kwade at redhat.com Sat Sep 30 02:47:26 2006 From: kwade at redhat.com (Karsten Wade) Date: Fri, 29 Sep 2006 19:47:26 -0700 Subject: [fab] OpenID: an actually distributed identity system In-Reply-To: <451A7438.1000909@fedoraproject.org> References: <1159360917.4346.14.camel@localhost.localdomain> <451A7438.1000909@fedoraproject.org> Message-ID: <1159584446.19689.82.camel@erato.phig.org> On Wed, 2006-09-27 at 18:23 +0530, Rahul wrote: > Its not the requirement of the CLA itself for the wiki that is a big > problem but the process. If it's just a click through method I suspect > we wouldnt have any complaints at all. The requirement we are meeting with the GPG signing is to provide a higher likelihood that the new account holder is actually who they say they are. No promises, but I bet a valid OpenID would suffice for the proof. The CLA could then be just a click-through. - 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 Sat Sep 30 02:49:06 2006 From: kwade at redhat.com (Karsten Wade) Date: Fri, 29 Sep 2006 19:49:06 -0700 Subject: [fab] FSF Licensing Audit Status In-Reply-To: <451D673A.9080607@math.unl.edu> References: <1155594111.5633.33.camel@localhost.localdomain> <451D645F.2000606@math.unl.edu> <451D6592.20604@redhat.com> <451D673A.9080607@math.unl.edu> Message-ID: <1159584546.19689.84.camel@erato.phig.org> On Fri, 2006-09-29 at 13:34 -0500, Rex Dieter wrote: > Christopher Blizzard wrote: > > Rex Dieter wrote: > > > >> > >> FYI, libc-client (aka imap, aka uw-imap) license has changed to Apache > >> 2.0 since imap-2006. > > > > Wait, including pine, etc? > > For now, at least, just imap, per http://www.washington.edu/imap/ Oh, man, you had Chris excited there for a second. He was all ready to return to his Pine. - 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 matt at domsch.com Sat Sep 30 02:52:39 2006 From: matt at domsch.com (Matt Domsch) Date: Fri, 29 Sep 2006 21:52:39 -0500 Subject: [fab] FSF Licensing Audit Status In-Reply-To: <1159584546.19689.84.camel@erato.phig.org> References: <1155594111.5633.33.camel@localhost.localdomain> <451D645F.2000606@math.unl.edu> <451D6592.20604@redhat.com> <451D673A.9080607@math.unl.edu> <1159584546.19689.84.camel@erato.phig.org> Message-ID: <20060930025239.GA4841@domsch.com> On Fri, Sep 29, 2006 at 07:49:06PM -0700, Karsten Wade wrote: > Oh, man, you had Chris excited there for a second. He was all ready to > return to his Pine. Gotta love mutt with pine keybindings. :-) From skvidal at linux.duke.edu Sat Sep 30 03:12:00 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 29 Sep 2006 23:12:00 -0400 Subject: [fab] OpenID: an actually distributed identity system In-Reply-To: <1159584446.19689.82.camel@erato.phig.org> References: <1159360917.4346.14.camel@localhost.localdomain> <451A7438.1000909@fedoraproject.org> <1159584446.19689.82.camel@erato.phig.org> Message-ID: <1159585920.2153.0.camel@cutter> On Fri, 2006-09-29 at 19:47 -0700, Karsten Wade wrote: > On Wed, 2006-09-27 at 18:23 +0530, Rahul wrote: > > > Its not the requirement of the CLA itself for the wiki that is a big > > problem but the process. If it's just a click through method I suspect > > we wouldnt have any complaints at all. > > The requirement we are meeting with the GPG signing is to provide a > higher likelihood that the new account holder is actually who they say > they are. > > No promises, but I bet a valid OpenID would suffice for the proof. The > CLA could then be just a click-through. > from what I've read there's no cryptographic signature of any type with openid. We might want to make sure that's valid for legal purposes. -sv From stickster at gmail.com Sat Sep 30 13:33:06 2006 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 30 Sep 2006 09:33:06 -0400 Subject: [fab] OpenID: an actually distributed identity system In-Reply-To: <1159585920.2153.0.camel@cutter> References: <1159360917.4346.14.camel@localhost.localdomain> <451A7438.1000909@fedoraproject.org> <1159584446.19689.82.camel@erato.phig.org> <1159585920.2153.0.camel@cutter> Message-ID: <1159623186.15089.40.camel@localhost.localdomain> On Fri, 2006-09-29 at 23:12 -0400, seth vidal wrote: > On Fri, 2006-09-29 at 19:47 -0700, Karsten Wade wrote: > > On Wed, 2006-09-27 at 18:23 +0530, Rahul wrote: > > > > > Its not the requirement of the CLA itself for the wiki that is a big > > > problem but the process. If it's just a click through method I suspect > > > we wouldnt have any complaints at all. > > > > The requirement we are meeting with the GPG signing is to provide a > > higher likelihood that the new account holder is actually who they say > > they are. > > > > No promises, but I bet a valid OpenID would suffice for the proof. The > > CLA could then be just a click-through. > > > > from what I've read there's no cryptographic signature of any type with > openid. > > We might want to make sure that's valid for legal purposes. I believe the OpenID 2.0 standard (now in draft) does include some signature capability from the ID provider to the target site. But Seth is right, the point of OpenID is not to prove that you are who you say you are -- it's to prove that you're the same person who a URL says you are (i.e. the owner). Unless we have a way of trusting the authentication mechanism of the ID provider, that information is not as useful as a GPG signature could be. But on the other hand, right now we don't even require a key to be signed by a mutually trusted third party, so anyone can create an email address and a key, and fraudulently sign the CLA. So I would question that OpenID is really a lower standard than what we have now. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject -------------- 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: