From mmcgrath at fedoraproject.org Fri Feb 2 02:23:12 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 1 Feb 2007 20:23:12 -0600 Subject: FUDCon hotel info In-Reply-To: References: Message-ID: <3237e4410702011823j10d4516fub6c077febee4a7da@mail.gmail.com> Are we all just going to meet downstairs in the morning and take cabs? What time? -Mike From kevin at tummy.com Fri Feb 2 02:30:08 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Thu, 1 Feb 2007 19:30:08 -0700 Subject: FUDCon hotel info In-Reply-To: <3237e4410702011823j10d4516fub6c077febee4a7da@mail.gmail.com> References: <3237e4410702011823j10d4516fub6c077febee4a7da@mail.gmail.com> Message-ID: <20070201193008.65c47396@ningauble.scrye.com> On Thu, 1 Feb 2007 20:23:12 -0600 "Mike McGrath" wrote: > Are we all just going to meet downstairs in the morning and take cabs? > What time? I'm at the Doubletree... I would be happy to share a cab with anyone who is also staying there. Interested parties should drop me a private email. > -Mike kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Fri Feb 2 02:40:26 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 01 Feb 2007 20:40:26 -0600 Subject: FUDCon hotel info In-Reply-To: <3237e4410702011823j10d4516fub6c077febee4a7da@mail.gmail.com> References: <3237e4410702011823j10d4516fub6c077febee4a7da@mail.gmail.com> Message-ID: >>>>> "MM" == Mike McGrath writes: MM> Are we all just going to meet downstairs in the morning and take MM> cabs? What time? I suppose it should be around 7:30, but I'm unfamiliar with Boston and don't know how long it takes to get to the venue. Is there any point in lugging a laptop? I wonder if bpepple will want the one I brought for him on Friday or not until the hackfest. - J< From stickster at gmail.com Fri Feb 2 03:54:17 2007 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 01 Feb 2007 22:54:17 -0500 Subject: FUDCon hotel info In-Reply-To: <3237e4410702011823j10d4516fub6c077febee4a7da@mail.gmail.com> References: <3237e4410702011823j10d4516fub6c077febee4a7da@mail.gmail.com> Message-ID: <1170388457.24783.12.camel@localhost.localdomain> On Thu, 2007-02-01 at 20:23 -0600, Mike McGrath wrote: > Are we all just going to meet downstairs in the morning and take cabs? > What time? I think a bunch of us are meeting Max and Greg in the lobby to leave at 7:30 to help set up. This supposed bunch is primarily made up of "people who have no idea where the hell we're going." I'll be there. -- 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: From notting at redhat.com Fri Feb 2 05:04:33 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 2 Feb 2007 00:04:33 -0500 Subject: FUDCon hotel info In-Reply-To: <1170388457.24783.12.camel@localhost.localdomain> References: <3237e4410702011823j10d4516fub6c077febee4a7da@mail.gmail.com> <1170388457.24783.12.camel@localhost.localdomain> Message-ID: <20070202050433.GB4403@nostromo.devel.redhat.com> Paul W. Frields (stickster at gmail.com) said: > > Are we all just going to meet downstairs in the morning and take cabs? > > What time? > > I think a bunch of us are meeting Max and Greg in the lobby to leave at > 7:30 to help set up. This supposed bunch is primarily made up of > "people who have no idea where the hell we're going." I'll be there. AFAIK, we're taking the T. Across the plaza to the T stop, outbound on the B train, BU East stop (or so they tell me). Bill From chitlesh at fedoraproject.org Mon Feb 5 10:36:15 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 5 Feb 2007 11:36:15 +0100 Subject: Announcing FUDCon Brussels2007 Message-ID: <13dbfe4f0702050236ia67f372oa988309cf1426cbf@mail.gmail.com> Hello there, As many of you, have heard about Fedora's presence in FOSDEM2007. We are now annoncing another FUDCon in 2007 which will be held there at FOSDEM, Brussels Belgium. Location and Date * Brussels, Belgium * Feb 24-25, 2007 Attendance is free. * room H2214 - http://fedoraproject.org/wiki/FedoraEvents/FOSDEM2007 (list of Fedora FOSDEM team) - http://fedoraproject.org/wiki/FUDCon/FUDConBrussels2007 I've the pleasure to invite you and join forces to talk about your beloved OS and how to work and improve it. MaxSpevack and TomTromey are travelling from US to be among us as well. ThomasCanniot will sing to us the great work achieved by the French Community and what they are planning to do in the near future. He will also talk about the infrastructure given to local teams and how they made use of it. We have many colleagues from the Fedora Engineering Team to show you what they are doing and planning to do. The complete Fedora Schedule can be found here: - http://www.fosdem.org/2007/schedule/devroom/centosfedora We will also be at the Fedora booth and invite you to come and share your ideas and experience to us. Look forward to seeing you & the other speakers later in the month! ChitleshGoorah and the Fedora FOSDEM team -- http://clunixchit.blogspot.com From chitlesh at fedoraproject.org Tue Feb 6 11:12:25 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 6 Feb 2007 12:12:25 +0100 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] Message-ID: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> Hello fedora people :) Well I'm forwarding this mail to this mailing list, in search for concrete opinions about cooperation between fedora and opensuse from the Fedora Engineering Team or Fedora Ambassadors. Suggestions are welcome, however flame wars aren't :) I've already accepted at least the meeting :) regards, Chitlesh Goorah ---------- Forwarded message ---------- From: Adrian Schr?ter To: Chitlesh GOORAH Date: Tue, 6 Feb 2007 10:03:46 +0100 Subject: Fedora & openSUSE meeting / cooperation ? Hello Chitlesh, I have heard that Fedora will be also on the FOSDEM 2007 like openSUSE is. What do you think when we do a meeting there, either in small or large group, to discuss ways and possibilities how we can cooperate ? I do see fields like a common customer hardware database or our openSUSE build service, which does support Fedora builds as well as discussion points. But there are for sure more fields where we could maybe cooperate in a way which gives us a win-win situation. Do you have interest in such a discussion ? bye adrian -- Adrian Schroeter Technical Project Manager for openSUSE project SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany -- http://clunixchit.blogspot.com From chitlesh at fedoraproject.org Tue Feb 6 12:17:19 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 6 Feb 2007 13:17:19 +0100 Subject: [Ambassadors] [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <1170763547.3462.2.camel@Amilo-GK.homenet.local> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <1170763547.3462.2.camel@Amilo-GK.homenet.local> Message-ID: <13dbfe4f0702060417p787761b2wdc834f49f305572a@mail.gmail.com> On 2/6/07, Gerold Kassube wrote: > Chitlesh, > > I'm not really sure if you remember the issue we've had last year at > Linuxtag ... Hello Gerold, Yes, I know that fedora issue very well :) > Florian and me are talking with Adrian about this issue and we planed > there a "seperate meeting at the University of Basel" which never comes > up till today ... Good to hear that you guys know him and that he can be trusted. > If wanted I participate that meeting and I personally think it's > important for us/all ... Thanks for the support Gerold. Chitlesh -- http://clunixchit.blogspot.com From blizzard at redhat.com Tue Feb 6 15:24:28 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 06 Feb 2007 10:24:28 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> Message-ID: <45C89DAC.605@redhat.com> Chitlesh GOORAH wrote: > Hello fedora people :) > > Well I'm forwarding this mail to this mailing list, in search for > concrete opinions about cooperation between fedora and opensuse from > the Fedora Engineering Team or Fedora Ambassadors. > > Suggestions are welcome, however flame wars aren't :) > > I've already accepted at least the meeting :) > > regards, > Chitlesh Goorah > > ---------- Forwarded message ---------- > From: Adrian Schr?ter > To: Chitlesh GOORAH > Date: Tue, 6 Feb 2007 10:03:46 +0100 > Subject: Fedora & openSUSE meeting / cooperation ? > > Hello Chitlesh, > > I have heard that Fedora will be also on the FOSDEM 2007 like openSUSE is. > > What do you think when we do a meeting there, either in small or large > group, > to discuss ways and possibilities how we can cooperate ? > > I do see fields like a common customer hardware database or our openSUSE > build > service, which does support Fedora builds as well as discussion points. But > there are for sure more fields where we could maybe cooperate in a way > which > gives us a win-win situation. > The build service isn't particularly interesting, mostly because the model we're moving towards is to move as much outside of the firewall as much as possible. It's kind of odd, actually, any time I run into any of the suse folks, all they want to talk about is the build service. Not a lot of value there, imho? Re: a customer hardware database, that's kind of a misnomer. In our case, it's not customers, it's a community-driven hardware database that should be used to figure out if something is well supported. We've only started that path and have a long way to go. If the conversation with the opensuse folks want to discuss, that's fine. The more information we have (as long as it's tied to the software versions being used!) the better. --Chris From fedora at leemhuis.info Tue Feb 6 15:36:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 06 Feb 2007 16:36:26 +0100 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> Message-ID: <45C8A07A.6010201@leemhuis.info> /me wonders if this crossposting will work -- some mail will probably hit only one list, some only the other, as both are moderated iirc :-( Hi, Chitlesh GOORAH schrieb: > > Well I'm forwarding this mail to this mailing list, in search for > concrete opinions about cooperation between fedora and opensuse from > the Fedora Engineering Team or Fedora Ambassadors. Find my 2 cent below. > Suggestions are welcome, however flame wars aren't :) Well, you wanted to hear opinions, so you get some. ;-) > I've already accepted at least the meeting :) Good idea in general, but I'd say you first should make sure that at least Max or Spot (or some other people from the Board or FESCo) are there -- that's only fair to Adrian. > ---------- Forwarded message ---------- > From: Adrian Schr?ter > To: Chitlesh GOORAH > Date: Tue, 6 Feb 2007 10:03:46 +0100 > Subject: Fedora & openSUSE meeting / cooperation ? > [...] > I do see fields like a common customer hardware database As I wrote on fedora-devel (without getting an real answer from the LHCP guys): I think that such a task really needs to be cross-distribution, so I like the idea to cooperate, but I think we should try to get more Distributions (Ubuntu, Gentoo, ...) into the boat. > or our openSUSE build > service, which does support Fedora builds Well, I don't like the idea to much -- it's might be cute for some ideas like setting up a "let's create a KDE4beta-repo for FC6" (which is not that hard to do with mock and some webspace), but I think the concept leads to a "set up a lot of different repos for different things" -- that IMHO might quickly result in a lot of inter-repo-incompatibilities, and that what I'd would like to avoid. And I don't see any advantages for us using it (but maybe I missed something). > [...] Cu thl From luis at tieguy.org Tue Feb 6 15:50:04 2007 From: luis at tieguy.org (Luis Villa) Date: Tue, 6 Feb 2007 10:50:04 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <45C89DAC.605@redhat.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <45C89DAC.605@redhat.com> Message-ID: <2cb10c440702060750i576140dax15f58966e06abade@mail.gmail.com> On 2/6/07, Christopher Blizzard wrote: > The build service isn't particularly interesting, mostly because the > model we're moving towards is to move as much outside of the firewall as > much as possible. It's kind of odd, actually, any time I run into any > of the suse folks, all they want to talk about is the build service. > Not a lot of value there, imho? It behooves all of us to make linux software easier to install- as easy as xpis in mozilla, or app bundles in osx. Once you do that, developers can focus more on development and less on packaging, users can more reliably get newer/better versions with less pain, etc. The build service is a very kludgy solution to this, but for users and non-distro developers it is a step in the right direction if it gets used. It gives them value, even if there is very little value in it for the distros. (I can rant on about this at great length; probably best not to get me started ;) Luis From blizzard at redhat.com Tue Feb 6 16:10:35 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 06 Feb 2007 11:10:35 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <2cb10c440702060750i576140dax15f58966e06abade@mail.gmail.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <45C89DAC.605@redhat.com> <2cb10c440702060750i576140dax15f58966e06abade@mail.gmail.com> Message-ID: <45C8A87B.5050909@redhat.com> Luis Villa wrote: > On 2/6/07, Christopher Blizzard wrote: >> The build service isn't particularly interesting, mostly because the >> model we're moving towards is to move as much outside of the firewall as >> much as possible. It's kind of odd, actually, any time I run into any >> of the suse folks, all they want to talk about is the build service. >> Not a lot of value there, imho? > > It behooves all of us to make linux software easier to install- as > easy as xpis in mozilla, or app bundles in osx. Once you do that, > developers can focus more on development and less on packaging, users > can more reliably get newer/better versions with less pain, etc. > > The build service is a very kludgy solution to this, but for users and > non-distro developers it is a step in the right direction if it gets > used. It gives them value, even if there is very little value in it > for the distros. > > (I can rant on about this at great length; probably best not to get me > started ;) I see them as somewhat separate things. To your first point - making things easier to install, I happen to completely agree, and it's one of the reasons why I'm driving down the path of using bundles instead of rpm or deb packages in olpc. This much to the chagrin of people who are heavily invested in rpm and similar technologies. I'm approaching this from the standpoint of "make it easier to find software that's interesting and be able to give it to others" as opposed to "making it easier and more convenient to make an rpm." --Chris From luis at tieguy.org Tue Feb 6 16:14:16 2007 From: luis at tieguy.org (Luis Villa) Date: Tue, 6 Feb 2007 11:14:16 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <45C8A87B.5050909@redhat.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <45C89DAC.605@redhat.com> <2cb10c440702060750i576140dax15f58966e06abade@mail.gmail.com> <45C8A87B.5050909@redhat.com> Message-ID: <2cb10c440702060814w4c480d14s1236facf11a3c4f8@mail.gmail.com> On 2/6/07, Christopher Blizzard wrote: > Luis Villa wrote: > > On 2/6/07, Christopher Blizzard wrote: > >> The build service isn't particularly interesting, mostly because the > >> model we're moving towards is to move as much outside of the firewall as > >> much as possible. It's kind of odd, actually, any time I run into any > >> of the suse folks, all they want to talk about is the build service. > >> Not a lot of value there, imho? > > > > It behooves all of us to make linux software easier to install- as > > easy as xpis in mozilla, or app bundles in osx. Once you do that, > > developers can focus more on development and less on packaging, users > > can more reliably get newer/better versions with less pain, etc. > > > > The build service is a very kludgy solution to this, but for users and > > non-distro developers it is a step in the right direction if it gets > > used. It gives them value, even if there is very little value in it > > for the distros. > > > > (I can rant on about this at great length; probably best not to get me > > started ;) > > I see them as somewhat separate things. To your first point - making > things easier to install, I happen to completely agree, and it's one of > the reasons why I'm driving down the path of using bundles instead of > rpm or deb packages in olpc. This much to the chagrin of people who are > heavily invested in rpm and similar technologies. > > I'm approaching this from the standpoint of "make it easier to find > software that's interesting and be able to give it to others" as opposed > to "making it easier and more convenient to make an rpm." I agree that the first approach is a vastly superior one which should be prioritized given finite resources, but that is a very big problem space with a lot of barriers preventing a solution. Given that, I don't think you should so casually dismiss the second approach in the meantime- I think as an intermediate bandaid it possibly has quite a bit of value. Luis (who sometimes wonders if web + xpi means we should have moved the whole desktop to mozilla/xulrunner two years ago) From blizzard at redhat.com Tue Feb 6 16:32:08 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 06 Feb 2007 11:32:08 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <2cb10c440702060814w4c480d14s1236facf11a3c4f8@mail.gmail.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <45C89DAC.605@redhat.com> <2cb10c440702060750i576140dax15f58966e06abade@mail.gmail.com> <45C8A87B.5050909@redhat.com> <2cb10c440702060814w4c480d14s1236facf11a3c4f8@mail.gmail.com> Message-ID: <45C8AD88.1030504@redhat.com> Luis Villa wrote: >> I see them as somewhat separate things. To your first point - making >> things easier to install, I happen to completely agree, and it's one of >> the reasons why I'm driving down the path of using bundles instead of >> rpm or deb packages in olpc. This much to the chagrin of people who are >> heavily invested in rpm and similar technologies. >> >> I'm approaching this from the standpoint of "make it easier to find >> software that's interesting and be able to give it to others" as opposed >> to "making it easier and more convenient to make an rpm." > > I agree that the first approach is a vastly superior one which should > be prioritized given finite resources, but that is a very big problem > space with a lot of barriers preventing a solution. Given that, I > don't think you should so casually dismiss the second approach in the > meantime- I think as an intermediate bandaid it possibly has quite a > bit of value. We're trying to make it pretty easy. We have a bunch of tools that lets you build an rpm locally, a "local build service" if you want to play rhetorical games. How we allow third parties be able to distribute and let other people know that they have compatible software is a different issue. That's the kind of thing that I've been pushing us towards as well. The pieces that Jesse and others are working on are the beginnings of that. Our current system of centralized distribution _and_ information about what's available seems to make that harder. i.e. the only way that people can find software that's compatible with Fedora is to find it in Fedora's repositories. It's something that has scaled well for us with free software, but that makes it hard for other people who are producing - dare I say it? - non-free software, which can have great value. > > Luis (who sometimes wonders if web + xpi means we should have moved > the whole desktop to mozilla/xulrunner two years ago) There's a huge amount to be learned from what Mozilla is doing, and I know I'm personally applying it. But it's hard for others to see it. They don't quite have the inside view that I have had to both projects. What's worked, what hasn't, what are the key success factors, etc. I'm trying to prove out some of using olpc as a mechanism, but it's slow going. --Chris From luis at tieguy.org Tue Feb 6 16:37:42 2007 From: luis at tieguy.org (Luis Villa) Date: Tue, 6 Feb 2007 11:37:42 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <45C8AD88.1030504@redhat.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <45C89DAC.605@redhat.com> <2cb10c440702060750i576140dax15f58966e06abade@mail.gmail.com> <45C8A87B.5050909@redhat.com> <2cb10c440702060814w4c480d14s1236facf11a3c4f8@mail.gmail.com> <45C8AD88.1030504@redhat.com> Message-ID: <2cb10c440702060837g69617d6h9cdf6b8dcbe2107f@mail.gmail.com> On 2/6/07, Christopher Blizzard wrote: > Luis Villa wrote: > >> I see them as somewhat separate things. To your first point - making > >> things easier to install, I happen to completely agree, and it's one of > >> the reasons why I'm driving down the path of using bundles instead of > >> rpm or deb packages in olpc. This much to the chagrin of people who are > >> heavily invested in rpm and similar technologies. > >> > >> I'm approaching this from the standpoint of "make it easier to find > >> software that's interesting and be able to give it to others" as opposed > >> to "making it easier and more convenient to make an rpm." > > > > I agree that the first approach is a vastly superior one which should > > be prioritized given finite resources, but that is a very big problem > > space with a lot of barriers preventing a solution. Given that, I > > don't think you should so casually dismiss the second approach in the > > meantime- I think as an intermediate bandaid it possibly has quite a > > bit of value. > > We're trying to make it pretty easy. We have a bunch of tools that lets > you build an rpm locally, a "local build service" if you want to play > rhetorical games. How we allow third parties be able to distribute and > let other people know that they have compatible software is a different > issue. That's the kind of thing that I've been pushing us towards as > well. The pieces that Jesse and others are working on are the > beginnings of that. Ah, I may be missing information on what jesse and others are doing- pointers? > Our current system of centralized distribution _and_ information about > what's available seems to make that harder. i.e. the only way that > people can find software that's compatible with Fedora is to find it in > Fedora's repositories. It's something that has scaled well for us with > free software, It makes it hard for people who are producing free software as well, since even if you can guarantee that all of your software is available on all distros, it is impossible to quickly get bugfixes and new versions out to users on all distros. I think this is the problem suse's build system is trying to fix- release one tarball, upload it to their system, *poof*, you've got builds for everything that you can point your users at. The current system is release one tarball, wait days or months for distros to pick it up, and in the meantime apologize to your users for their inability to get their software on distro X. > > Luis (who sometimes wonders if web + xpi means we should have moved > > the whole desktop to mozilla/xulrunner two years ago) > > There's a huge amount to be learned from what Mozilla is doing, and I > know I'm personally applying it. But it's hard for others to see it. > They don't quite have the inside view that I have had to both projects. > What's worked, what hasn't, what are the key success factors, etc. > I'm trying to prove out some of using olpc as a mechanism, but it's slow > going. I would love to talk with you about this at some point; I'm currently drafting a blog post which basically says that not working with mozilla was GNOME's biggest mistake of the post-2.0 era. (A mistake that I played a significant role in, I might add :/ Luis From blizzard at redhat.com Tue Feb 6 17:20:41 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 06 Feb 2007 12:20:41 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <2cb10c440702060837g69617d6h9cdf6b8dcbe2107f@mail.gmail.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <45C89DAC.605@redhat.com> <2cb10c440702060750i576140dax15f58966e06abade@mail.gmail.com> <45C8A87B.5050909@redhat.com> <2cb10c440702060814w4c480d14s1236facf11a3c4f8@mail.gmail.com> <45C8AD88.1030504@redhat.com> <2cb10c440702060837g69617d6h9cdf6b8dcbe2107f@mail.gmail.com> Message-ID: <45C8B8E9.6080305@redhat.com> Luis Villa wrote: >> We're trying to make it pretty easy. We have a bunch of tools that lets >> you build an rpm locally, a "local build service" if you want to play >> rhetorical games. How we allow third parties be able to distribute and >> let other people know that they have compatible software is a different >> issue. That's the kind of thing that I've been pushing us towards as >> well. The pieces that Jesse and others are working on are the >> beginnings of that. > > Ah, I may be missing information on what jesse and others are doing- > pointers? Lots of tools that already exist - mock, plague, next pungi, which will let you compose your own distribution. Not the same goal as the build service (upload once, build for everyone) but can handle a lot of that. i.e. it contains configs all the way back to Red Hat 7.3, iirc. Wouldn't be too hard to point those at suse configs or whatever. Debian/Ubuntu is harder, of course, but probably not impossible. Also, thomasvs might have a bunch of tools for this. I think that he's revived mach (as opposed to mock.) > I would love to talk with you about this at some point; I'm currently > drafting a blog post which basically says that not working with > mozilla was GNOME's biggest mistake of the post-2.0 era. (A mistake > that I played a significant role in, I might add :/ Yeah, that's an entirely different discussion - one that I come down on both sides of from time to time. i.e. Havoc thinks we should have done a GNOME browser and worked with the Firefox folks to call it Firefox. They didn't want to do that, so we ended up with a pretty poorly integrated browser experience on Linux. But I don't think that's what you're talking about. I want to replicate parts of that model for GNOME and Fedora, but not integration with firefox so much as learning how they distribute and promote the software they have. --Chris From fedora at leemhuis.info Tue Feb 6 18:15:16 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 06 Feb 2007 19:15:16 +0100 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <2cb10c440702060837g69617d6h9cdf6b8dcbe2107f@mail.gmail.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <45C89DAC.605@redhat.com> <2cb10c440702060750i576140dax15f58966e06abade@mail.gmail.com> <45C8A87B.5050909@redhat.com> <2cb10c440702060814w4c480d14s1236facf11a3c4f8@mail.gmail.com> <45C8AD88.1030504@redhat.com> <2cb10c440702060837g69617d6h9cdf6b8dcbe2107f@mail.gmail.com> Message-ID: <45C8C5B4.1050008@leemhuis.info> Luis Villa schrieb: > On 2/6/07, Christopher Blizzard wrote: >> Luis Villa wrote: > [...] >> Our current system of centralized distribution _and_ information about >> what's available seems to make that harder. i.e. the only way that >> people can find software that's compatible with Fedora is to find it in >> Fedora's repositories. It's something that has scaled well for us with >> free software, > It makes it hard for people who are producing free software as well, > since even if you can guarantee that all of your software is available > on all distros, it is impossible to quickly get bugfixes and new > versions out to users on all distros. I think the answer should be: as upstream maintainer get involved or at least in contact with the distributions. That's why I'd like to see upstream maintainers as co-maintainers in Fedora if possible. Another possible solution: all (important) software agrees to use a similar, time based release scheme. E.g. everyone releases a stable version twice a year (March and September) and applies only bugfixes to the stable versions, while the devel stuff gets into the devel repo. The distributions could then push the updates to the stable distribution and the devel version to their devel tree, that gets a release in April and October. In other words: let the whole world aligns to the gnome release model and its foreseeable schedule > I think this is the problem > suse's build system is trying to fix- release one tarball, upload it > to their system, *poof*, you've got builds for everything that you can > point your users at. And I tend to think: that's not possible (or very very hard). The software packages in our distribution often has heavy inter-dependencies. So if you update one, then chances are high to break something else. Just take Firefox (galeon, liferia, yelp, several more use exactly the firefox version for which it was build), or gaim (some plugins like otr, libnotify) for example (there are a lot more), that are used by several other packages. Then there are situations where one bug in packages foo and bar gets fixed with a update of package baz, but another one introduced in package foobar (the recent gtk2 update for FC6 for example, that broke drag and drop in thunderbird and firefox). Read: a lot of PITA, which I remember from the pre-Extras days (when you had to mix repos for add-on stuff), that still happens now and then these days in 3rd pary add-on repos that ship stuff Fedora can't ship. So IMHO the the distributor has to make sure people get what they want. My preferred solution for now would be two have different update channels: One that gets only "Security fixes and crucial bug fixes" (so more careful then Fedora Core currently), one that gets new versions of most package (rolling release, similar like Extras was, so a bit more bold then Fedora Core currently), while the crucial new stuff (new python for example) gets developed in the devel repository. Just my 2 cent. CU thl From blizzard at redhat.com Tue Feb 6 18:45:14 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 06 Feb 2007 13:45:14 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <45C8C5B4.1050008@leemhuis.info> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <45C89DAC.605@redhat.com> <2cb10c440702060750i576140dax15f58966e06abade@mail.gmail.com> <45C8A87B.5050909@redhat.com> <2cb10c440702060814w4c480d14s1236facf11a3c4f8@mail.gmail.com> <45C8AD88.1030504@redhat.com> <2cb10c440702060837g69617d6h9cdf6b8dcbe2107f@mail.gmail.com> <45C8C5B4.1050008@leemhuis.info> Message-ID: <45C8CCBA.2020209@redhat.com> Thorsten Leemhuis wrote: > I think the answer should be: as upstream maintainer get involved or at > least in contact with the distributions. That's why I'd like to see > upstream maintainers as co-maintainers in Fedora if possible. I agree with that model especially in the case of components that are important to everyone else. i.e. gtk, gstreamer, the kernel, glibc, etc. But the farther down the stack the less important that becomes. For me it's a measure of how interdependent the various parts are. > > Another possible solution: all (important) software agrees to > use a similar, time based release scheme. E.g. everyone releases a > stable version twice a year (March and September) and applies only > bugfixes to the stable versions, while the devel stuff gets into the > devel repo. The distributions could then push the updates to the stable > distribution and the devel version to their devel tree, that gets a > release in April and October. In other words: let the whole world aligns > to the gnome release model and its foreseeable schedule Heh, I would love that, too! But the number of items that are part of a particular release each increase the risk of that release slipping. Isn't this similar to the model that they have used in debian? If so, I fear for the kittens[*]. > And I tend to think: that's not possible (or very very hard). The > software packages in our distribution often has heavy > inter-dependencies. So if you update one, then chances are high to break > something else. Just take Firefox (galeon, liferia, yelp, several more > use exactly the firefox version for which it was build), or gaim (some > plugins like otr, libnotify) for example (there are a lot more), that > are used by several other packages. It's hard, sure. Isn't this also what Ximian used to do before they were eaten by the giant N? I remember a discussion of a database driven app that would create your spec files on the fly, etc, no matter what you were using. Not sure how it worked, either. I guess Luis can relay some of that if he chooses. > Then there are situations where one bug in packages foo and bar gets > fixed with a update of package baz, but another one introduced in > package foobar (the recent gtk2 update for FC6 for example, that broke > drag and drop in thunderbird and firefox). Read: a lot of PITA, which I > remember from the pre-Extras days (when you had to mix repos for add-on > stuff), that still happens now and then these days in 3rd pary add-on > repos that ship stuff Fedora can't ship. > > So IMHO the the distributor has to make sure people get what they want. > My preferred solution for now would be two have different update > channels: One that gets only "Security fixes and crucial bug fixes" (so > more careful then Fedora Core currently), one that gets new versions of > most package (rolling release, similar like Extras was, so a bit more > bold then Fedora Core currently), while the crucial new stuff (new > python for example) gets developed in the devel repository. > You've just described the RHEL/Fedora split quite effectively. --Chris * http://www.flickr.com/photos/christopherblizzard/376867422/ From luis at tieguy.org Tue Feb 6 18:51:48 2007 From: luis at tieguy.org (Luis Villa) Date: Tue, 6 Feb 2007 13:51:48 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <45C8CCBA.2020209@redhat.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <45C89DAC.605@redhat.com> <2cb10c440702060750i576140dax15f58966e06abade@mail.gmail.com> <45C8A87B.5050909@redhat.com> <2cb10c440702060814w4c480d14s1236facf11a3c4f8@mail.gmail.com> <45C8AD88.1030504@redhat.com> <2cb10c440702060837g69617d6h9cdf6b8dcbe2107f@mail.gmail.com> <45C8C5B4.1050008@leemhuis.info> <45C8CCBA.2020209@redhat.com> Message-ID: <2cb10c440702061051o3565f323sa0193746f35a362e@mail.gmail.com> On 2/6/07, Thorsten Leemhuis wrote: > I think the answer should be: as upstream maintainer get involved or at > least in contact with the distributions. That's why I'd like to see > upstream maintainers as co-maintainers in Fedora if possible. > > Another possible solution: all (important) software agrees to > use a similar, time based release scheme. E.g. everyone releases a > stable version twice a year (March and September) and applies only > bugfixes to the stable versions, while the devel stuff gets into the > devel repo. The distributions could then push the updates to the stable > distribution and the devel version to their devel tree, that gets a > release in April and October. In other words: let the whole world aligns > to the gnome release model and its foreseeable schedule Both of those are equally dreamy. The whole point of what opensuse is trying to do is make it so that people can do it once, distribute it over a large number of platforms. Having the maintainer of the package also be a co-maintainer in every distribution they want to distribute something through is insane, and just the kind of totally bullshit hoops that we must eliminate if we actually want linux to become a first-class platform. [This is only true if your vision of the future of Linux includes multiple distros; if your vision is that there is only the One True Distro, then yes, having upstream also be co-maintainers in the One True Distro makes sense. This is basically Canonical's vision. In some ways it makes sense- we gain a lot of efficiencies by having One True Kernel which everyone else forks from; why not have One True Distro that everyone else forks from. Of course, putting it in the hands of a proprietary tool makes me get violent.] On 2/6/07, Christopher Blizzard wrote: > > And I tend to think: that's not possible (or very very hard). The > > software packages in our distribution often has heavy > > inter-dependencies. So if you update one, then chances are high to break > > something else. Just take Firefox (galeon, liferia, yelp, several more > > use exactly the firefox version for which it was build), or gaim (some > > plugins like otr, libnotify) for example (there are a lot more), that > > are used by several other packages. > > It's hard, sure. Isn't this also what Ximian used to do before they > were eaten by the giant N? I remember a discussion of a database driven > app that would create your spec files on the fly, etc, no matter what > you were using. Not sure how it worked, either. I guess Luis can relay > some of that if he chooses. It was the only way to do what we did, so we didn't have much choice in the matter. Implementation details aren't all that important, but basically it had a sort of meta-spec file and worked its way down from there roughly as you describe. I'd imagine opensuse's build farm does something similar, though AFAIK the two tools do not share any code or even common developers. It was of course wildly popular, because it solved exactly the problem we're discussing here, which is a very real problem for users. Luis From tchung at fedoraproject.org Tue Feb 6 18:57:02 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Tue, 6 Feb 2007 10:57:02 -0800 Subject: kqemu is now GPLv2 Message-ID: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> Good news. Fabrice Bellard, the creator of qemu is now releasing kqemu under GPLv2. Previously it was released with propriety license. http://fabrice.bellard.free.fr/qemu/kqemu-changelog.html Cheers! -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From jkeating at redhat.com Tue Feb 6 19:07:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Feb 2007 14:07:41 -0500 Subject: kqemu is now GPLv2 In-Reply-To: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> Message-ID: <200702061407.41272.jkeating@redhat.com> On Tuesday 06 February 2007 13:57, Thomas Chung wrote: > Good news. > Fabrice Bellard, the creator of qemu is now releasing kqemu under GPLv2. > Previously it was released with propriety license. > http://fabrice.bellard.free.fr/qemu/kqemu-changelog.html > Cheers! Good, now he can get it upstream so that I won't feel like punching kittens when somebody asks why we don't ship it in Fedora. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Feb 6 19:14:24 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 06 Feb 2007 20:14:24 +0100 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <45C8CCBA.2020209@redhat.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <45C89DAC.605@redhat.com> <2cb10c440702060750i576140dax15f58966e06abade@mail.gmail.com> <45C8A87B.5050909@redhat.com> <2cb10c440702060814w4c480d14s1236facf11a3c4f8@mail.gmail.com> <45C8AD88.1030504@redhat.com> <2cb10c440702060837g69617d6h9cdf6b8dcbe2107f@mail.gmail.com> <45C8C5B4.1050008@leemhuis.info> <45C8CCBA.2020209@redhat.com> Message-ID: <45C8D390.7090306@leemhuis.info> Christopher Blizzard schrieb: > Thorsten Leemhuis wrote: > [...] >> So IMHO the the distributor has to make sure people get what they want. >> My preferred solution for now would be two have different update >> channels: One that gets only "Security fixes and crucial bug fixes" (so >> more careful then Fedora Core currently), one that gets new versions of >> most package (rolling release, similar like Extras was, so a bit more >> bold then Fedora Core currently), while the crucial new stuff (new >> python for example) gets developed in the devel repository. > > You've just described the RHEL/Fedora split quite effectively. Hmmm, I tend to disagree a bit -- the difference between a more carefully maintained Fedora and RHEL is that you have to wait 18 - 24 months to get new stuff with a new RHEL. That's fine and great for Enterprise, it's to slow for most home users afaics. So I think all the following use-cases would find users, and the mix should make everyone happy: - RHEL/CentOS -> seven years of support, only important updates, new stuff if you want round about all 18 months - Fedora, stable updates channel -> only important updates, get new stuff once a year (if you skip a release) or all six months (if you want) - Fedora, bold updates channel -> get most new stuff all the time, test stuff out before it hits the stable updates channel while getting the really new stuff all six months - Fedora, development -> get new stuff constantly CU thl From blizzard at redhat.com Tue Feb 6 19:20:41 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 06 Feb 2007 14:20:41 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <2cb10c440702061051o3565f323sa0193746f35a362e@mail.gmail.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <45C89DAC.605@redhat.com> <2cb10c440702060750i576140dax15f58966e06abade@mail.gmail.com> <45C8A87B.5050909@redhat.com> <2cb10c440702060814w4c480d14s1236facf11a3c4f8@mail.gmail.com> <45C8AD88.1030504@redhat.com> <2cb10c440702060837g69617d6h9cdf6b8dcbe2107f@mail.gmail.com> <45C8C5B4.1050008@leemhuis.info> <45C8CCBA.2020209@redhat.com> <2cb10c440702061051o3565f323sa0193746f35a362e@mail.gmail.com> Message-ID: <45C8D509.3040507@redhat.com> Luis Villa wrote: > Both of those are equally dreamy. The whole point of what opensuse is > trying to do is make it so that people can do it once, distribute it > over a large number of platforms. Having the maintainer of the package > also be a co-maintainer in every distribution they want to distribute > something through is insane, and just the kind of totally bullshit > hoops that we must eliminate if we actually want linux to become a > first-class platform. Agreed. Part of my underlying thinking of bundles is that they can represent the lowest common denominator for _desktop_ functionality. i.e. they support the gtk2 API/ABI, service activation via dbus, self describing mime files anything else they carry around themselves. Also adding support to debian/suse/fedora desktop and then we can actually create a pretty portable package. We need better build tools to make this happen, and I need to prove the idea out through OLPC, but it's a good start for a real roadmap to success. > > [This is only true if your vision of the future of Linux includes > multiple distros; if your vision is that there is only the One True > Distro, then yes, having upstream also be co-maintainers in the One > True Distro makes sense. This is basically Canonical's vision. In some > ways it makes sense- we gain a lot of efficiencies by having One True > Kernel which everyone else forks from; why not have One True Distro > that everyone else forks from. Of course, putting it in the hands of a > proprietary tool makes me get violent.] I haven't been particular shy about the fact that I want Fedora to become that base. But I've wanted to do it by moving us to an open model (core/extras merge) by providing superior tools (VCS discussions and the future of RPM) by improving our support for hardware, in particular laptops (smolt/LHCS) and doing so in an honest an open manner. I will not coerce people into working with us. It should just be the natural place to do so. A lot of this is based around trust. I still work at Red Hat and in Fedora because of all the companies that are out there who work in open source and free software, it's the one that has found its values and has stuck with them through and through. And we've been doing it for years. I just want to make sure that we take it to the next level. What have we learned in the past and how can we improve what we're doing when moving into the future while sticking with our core values intact? It's something we don't do enough of, especially given that we have something that works pretty well today. But pretty well won't cut it given that Apple has raised the level of the experience that we need to meet, and sometimes that means doing something different. Inertia tends to be my greatest enemy these days, and I find that surprising. But I digress. > It was the only way to do what we did, so we didn't have much choice > in the matter. Implementation details aren't all that important, but > basically it had a sort of meta-spec file and worked its way down from > there roughly as you describe. I'd imagine opensuse's build farm does > something similar, though AFAIK the two tools do not share any code or > even common developers. > > It was of course wildly popular, because it solved exactly the problem > we're discussing here, which is a very real problem for users. Right. But doesn't that seem to you like it's wedging into a system that's fundamentally broken for your use case? Think about the amount of work you're going through to wedge yourself into a set of tools that don't even create great experiences for users in the first place. It's a tough question: do you try to be compatible with everyone and create something that's pretty bad to get buy in or do you step out in front of the train and do something completely new where you have to sell everyone on the goodness of the new model? That's why I'm going out there to prove instead of just talking it up all the time. Always better to show than to talk. --Chris From blizzard at redhat.com Tue Feb 6 19:23:25 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 06 Feb 2007 14:23:25 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <45C8D390.7090306@leemhuis.info> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <45C89DAC.605@redhat.com> <2cb10c440702060750i576140dax15f58966e06abade@mail.gmail.com> <45C8A87B.5050909@redhat.com> <2cb10c440702060814w4c480d14s1236facf11a3c4f8@mail.gmail.com> <45C8AD88.1030504@redhat.com> <2cb10c440702060837g69617d6h9cdf6b8dcbe2107f@mail.gmail.com> <45C8C5B4.1050008@leemhuis.info> <45C8CCBA.2020209@redhat.com> <45C8D390.7090306@leemhuis.info> Message-ID: <45C8D5AD.2050500@redhat.com> Thorsten Leemhuis wrote: > - RHEL/CentOS -> seven years of support, only important updates, new > stuff if you want round about all 18 months > - Fedora, stable updates channel -> only important updates, get new > stuff once a year (if you skip a release) or all six months (if you want) > - Fedora, bold updates channel -> get most new stuff all the time, test > stuff out before it hits the stable updates channel while getting the > really new stuff all six months > - Fedora, development -> get new stuff constantly I want to be pretty careful here to say that I think that's a good idea, but I'm not sure if it's going to work well. Legacy was trying to do parts of this, right? The problem was that it didn't get a lot of attention. Debian stable is supposed to do this as well but I don't know anyone that actually runs debian stable. Stable updates are something that most programmers/community find, well, boring. And it's hard to build a community around that. Once again, I'm not saying that it's a bad idea, it's just hard. So I'll redirect the question a bit and ask: what's the incentive to get people to care about a stable updates channel vs. what we do today? --Chris From luis at tieguy.org Tue Feb 6 19:30:18 2007 From: luis at tieguy.org (Luis Villa) Date: Tue, 6 Feb 2007 14:30:18 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <45C8D509.3040507@redhat.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <2cb10c440702060750i576140dax15f58966e06abade@mail.gmail.com> <45C8A87B.5050909@redhat.com> <2cb10c440702060814w4c480d14s1236facf11a3c4f8@mail.gmail.com> <45C8AD88.1030504@redhat.com> <2cb10c440702060837g69617d6h9cdf6b8dcbe2107f@mail.gmail.com> <45C8C5B4.1050008@leemhuis.info> <45C8CCBA.2020209@redhat.com> <2cb10c440702061051o3565f323sa0193746f35a362e@mail.gmail.com> <45C8D509.3040507@redhat.com> Message-ID: <2cb10c440702061130u1b4fe754qa935019c618b5715@mail.gmail.com> On 2/6/07, Christopher Blizzard wrote: > Luis Villa wrote: > > Both of those are equally dreamy. The whole point of what opensuse is > > trying to do is make it so that people can do it once, distribute it > > over a large number of platforms. Having the maintainer of the package > > also be a co-maintainer in every distribution they want to distribute > > something through is insane, and just the kind of totally bullshit > > hoops that we must eliminate if we actually want linux to become a > > first-class platform. > > Agreed. Part of my underlying thinking of bundles is that they can > represent the lowest common denominator for _desktop_ functionality. > i.e. they support the gtk2 API/ABI, service activation via dbus, self > describing mime files anything else they carry around themselves. Also > adding support to debian/suse/fedora desktop and then we can actually > create a pretty portable package. We need better build tools to make > this happen, and I need to prove the idea out through OLPC, but it's a > good start for a real roadmap to success. I wish you good luck and godspeed. ;) > > [This is only true if your vision of the future of Linux includes > > multiple distros; if your vision is that there is only the One True > > Distro, then yes, having upstream also be co-maintainers in the One > > True Distro makes sense. This is basically Canonical's vision. In some > > ways it makes sense- we gain a lot of efficiencies by having One True > > Kernel which everyone else forks from; why not have One True Distro > > that everyone else forks from. Of course, putting it in the hands of a > > proprietary tool makes me get violent.] > > I haven't been particular shy about the fact that I want Fedora to > become that base. To be perfectly honest, I don't think Red Hat/Fedora will ever earn enough trust to be that base, or at least, will never unless it works to actively piss off Red Hat and comes out the other side relatively unscathed. And I *like* Red Hat- like you I wouldn't work for them otherwise. > > It was the only way to do what we did, so we didn't have much choice > > in the matter. Implementation details aren't all that important, but > > basically it had a sort of meta-spec file and worked its way down from > > there roughly as you describe. I'd imagine opensuse's build farm does > > something similar, though AFAIK the two tools do not share any code or > > even common developers. > > > > It was of course wildly popular, because it solved exactly the problem > > we're discussing here, which is a very real problem for users. > > Right. But doesn't that seem to you like it's wedging into a system > that's fundamentally broken for your use case? It is *very* broken, but not *fundamentally* broken, otherwise we wouldn't have been able to do it. Would solving it another, less broken way be better? Absolutely. But Ximian was the proof that it could be done the horrible, broken way; opensuse is trying to resurrect that (and I think has a reasonable chance of doing it), and as of yet no one has actually proven that it can be meaningfully done in the non-horrible, beautiful way. Until then, working code (no matter how ugly and godawful) tends to trumps pipe dreams. Luis From jkeating at redhat.com Tue Feb 6 19:30:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Feb 2007 14:30:40 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <45C8D5AD.2050500@redhat.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <45C8D390.7090306@leemhuis.info> <45C8D5AD.2050500@redhat.com> Message-ID: <200702061430.40313.jkeating@redhat.com> On Tuesday 06 February 2007 14:23, Christopher Blizzard wrote: > I'll redirect the question a bit and ask: what's the incentive to get > people to care about a stable updates channel vs. what we do today? Money. Unless one is making their living off of doing this grunt work, I don't think there is going to be many people beating down our doors to do the work. Either it's in money we're paying them, or money they're saving by not buying RHEL. -- 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 laroche at redhat.com Tue Feb 6 19:35:54 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 6 Feb 2007 20:35:54 +0100 Subject: kqemu is now GPLv2 In-Reply-To: <200702061407.41272.jkeating@redhat.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061407.41272.jkeating@redhat.com> Message-ID: <20070206193554.GA26132@dudweiler.stuttgart.redhat.com> On Tue, Feb 06, 2007 at 02:07:41PM -0500, Jesse Keating wrote: > On Tuesday 06 February 2007 13:57, Thomas Chung wrote: > > Good news. > > Fabrice Bellard, the creator of qemu is now releasing kqemu under GPLv2. > > Previously it was released with propriety license. > > http://fabrice.bellard.free.fr/qemu/kqemu-changelog.html > > Cheers! > > Good, now he can get it upstream so that I won't feel like punching kittens > when somebody asks why we don't ship it in Fedora. Fabrice did give an ok to package the old kqemu for Fedora, just didn't want to see it offered for Red Hat's enterprise offerings. The Fedora rules about what licenses we ship as been the barrier for inclusion. Very nice to see the kqemu module GPL and see how further steps with virtualization can be done for qemu in the future. regards, Florian La Roche From jkeating at redhat.com Tue Feb 6 19:42:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Feb 2007 14:42:45 -0500 Subject: kqemu is now GPLv2 In-Reply-To: <20070206193554.GA26132@dudweiler.stuttgart.redhat.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061407.41272.jkeating@redhat.com> <20070206193554.GA26132@dudweiler.stuttgart.redhat.com> Message-ID: <200702061442.45880.jkeating@redhat.com> On Tuesday 06 February 2007 14:35, Florian La Roche wrote: > Fabrice did give an ok to package the old kqemu for Fedora, just didn't > want to see it offered for Red Hat's enterprise offerings. The Fedora rules > about what licenses we ship as been the barrier for inclusion. Yes, I know it has, but all external kmods make me want to punch kittens. That and the craptastic hacks we have to do to support them. When we move to the unified tree of packages, I really don't want to hold kernel updates up for all the extra kmods to be built against it, but if I don't the repo will not be clean. This will be a serious problem, one of the reasons I was very very very against allowing external kmods in Fedora. -- 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 blizzard at redhat.com Tue Feb 6 19:53:58 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 06 Feb 2007 14:53:58 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <200702061430.40313.jkeating@redhat.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <45C8D390.7090306@leemhuis.info> <45C8D5AD.2050500@redhat.com> <200702061430.40313.jkeating@redhat.com> Message-ID: <45C8DCD6.9000407@redhat.com> Jesse Keating wrote: > On Tuesday 06 February 2007 14:23, Christopher Blizzard wrote: >> I'll redirect the question a bit and ask: what's the incentive to get >> people to care about a stable updates channel vs. what we do today? > > Money. Unless one is making their living off of doing this grunt work, I > don't think there is going to be many people beating down our doors to do the > work. Either it's in money we're paying them, or money they're saving by not > buying RHEL. > Ladies and gentleman, I give you the RHEL value proposition. --Chris From blizzard at redhat.com Tue Feb 6 19:59:33 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 06 Feb 2007 14:59:33 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <2cb10c440702061130u1b4fe754qa935019c618b5715@mail.gmail.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <2cb10c440702060750i576140dax15f58966e06abade@mail.gmail.com> <45C8A87B.5050909@redhat.com> <2cb10c440702060814w4c480d14s1236facf11a3c4f8@mail.gmail.com> <45C8AD88.1030504@redhat.com> <2cb10c440702060837g69617d6h9cdf6b8dcbe2107f@mail.gmail.com> <45C8C5B4.1050008@leemhuis.info> <45C8CCBA.2020209@redhat.com> <2cb10c440702061051o3565f323sa0193746f35a362e@mail.gmail.com> <45C8D509.3040507@redhat.com> <2cb10c440702061130u1b4fe754qa935019c618b5715@mail.gmail.com> Message-ID: <45C8DE25.5040403@redhat.com> Luis Villa wrote: > > To be perfectly honest, I don't think Red Hat/Fedora will ever earn > enough trust to be that base, or at least, will never unless it works > to actively piss off Red Hat and comes out the other side relatively > unscathed. And I *like* Red Hat- like you I wouldn't work for them > otherwise. We'll see. We do have a commercial interest in Fedora, and it spills out from time to time. (*cough* Xen *cough*) But it also means we get a lot of engineers looking at interesting problems. I think that we've made a lot of progress with building a community that cares and is involved on a day to day basis with the success of the project, and that happened entirely outside of Red Hat. I look at things like FESCO and the explosion of Extras and I feel hope for the future. And even if we don't end up being that base, setting up the tools will at least vastly improve our user and developer experience and productively that it's worth it to do it just for that reason. But it's still not my primary reason for wanting to do it. >> Right. But doesn't that seem to you like it's wedging into a system >> that's fundamentally broken for your use case? > > It is *very* broken, but not *fundamentally* broken, otherwise we > wouldn't have been able to do it. Would solving it another, less > broken way be better? Absolutely. Point taken. But very broken is often not enough reason for someone to move it seems. When do you get to the point of diminishing returns? > But Ximian was the proof that it could be done the horrible, broken > way; opensuse is trying to resurrect that (and I think has a > reasonable chance of doing it), and as of yet no one has actually > proven that it can be meaningfully done in the non-horrible, beautiful > way. Until then, working code (no matter how ugly and godawful) tends > to trumps pipe dreams. I wish them luck! --Chris From fedora at leemhuis.info Tue Feb 6 19:59:43 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 06 Feb 2007 20:59:43 +0100 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <45C8D5AD.2050500@redhat.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <45C89DAC.605@redhat.com> <2cb10c440702060750i576140dax15f58966e06abade@mail.gmail.com> <45C8A87B.5050909@redhat.com> <2cb10c440702060814w4c480d14s1236facf11a3c4f8@mail.gmail.com> <45C8AD88.1030504@redhat.com> <2cb10c440702060837g69617d6h9cdf6b8dcbe2107f@mail.gmail.com> <45C8C5B4.1050008@leemhuis.info> <45C8CCBA.2020209@redhat.com> <45C8D390.7090306@leemhuis.info> <45C8D5AD.2050500@redhat.com> Message-ID: <45C8DE2F.7080505@leemhuis.info> Christopher Blizzard schrieb: > Thorsten Leemhuis wrote: >> - RHEL/CentOS -> seven years of support, only important updates, new >> stuff if you want round about all 18 months >> - Fedora, stable updates channel -> only important updates, get new >> stuff once a year (if you skip a release) or all six months (if you want) >> - Fedora, bold updates channel -> get most new stuff all the time, test >> stuff out before it hits the stable updates channel while getting the >> really new stuff all six months >> - Fedora, development -> get new stuff constantly > I want to be pretty careful here to say that I think that's a good idea, > but I'm not sure if it's going to work well. Legacy was trying to do > parts of this, right? [...] Not really. We support Fedora thirteen months currently (at least afaik, as that decision from the Fedora Summit was never announced officially iirc). Above example does not go beyond those 13 months, so this has nothing to do with Legacy -- its more about maintaining two sorts of update channels for the latest released distro (e.g. 6 and a half month). Two channels is what we are doing in parts already with "updates" and "updates-testing", but there packages get moved from the later to the former sooner or later. Anyway, yes, sure, maintaining two set of update channels makes of course more work. But I'd say as long as the current maintainers *continue* (they have to do that currently) to do the security fixes and important bugfixes for the stable channel then I'm optimistic that we get some of the Extras contributors and even some of the Core maintainers to maintain their packages in a updates-bold channel; that often should be nothing more then rebuilding packages from devel. That could lead to a better tested packages in the distro that gets released from said devel tree later, and gives people a chance to get involved in interesting areas (like a firefox2 in the updates bold channel for FC6, which is for good reasons not shipped a updates-proper for FC6). CU thl From fedora at leemhuis.info Tue Feb 6 20:05:11 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 06 Feb 2007 21:05:11 +0100 Subject: kqemu is now GPLv2 In-Reply-To: <200702061442.45880.jkeating@redhat.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061407.41272.jkeating@redhat.com> <20070206193554.GA26132@dudweiler.stuttgart.redhat.com> <200702061442.45880.jkeating@redhat.com> Message-ID: <45C8DF77.5020808@leemhuis.info> Jesse Keating schrieb: > On Tuesday 06 February 2007 14:35, Florian La Roche wrote: >> Fabrice did give an ok to package the old kqemu for Fedora, just didn't >> want to see it offered for Red Hat's enterprise offerings. The Fedora rules >> about what licenses we ship as been the barrier for inclusion. > Yes, I know it has, but all external kmods make me want to punch kittens. > That and the craptastic hacks we have to do to support them. Well, yes, they are problematic. But don't do harm to kittens -- it's not their fault ;-) > When we move to the unified tree of packages, I really don't want to hold > kernel updates up for all the extra kmods to be built against it, but if I > don't the repo will not be clean. This will be a serious problem, one of the > reasons I was very very very against allowing external kmods in Fedora. Nevertheless a lot of people want them. I think we should provide a solution for them. I'm willing to maintain a special repo for them, but I'd like to do that (and some other things) under the hood of the Fedora Project. I actually wrote something up about it with more details during my flight to Boston. But I need to look over it before posting it. CU thl From jkeating at redhat.com Tue Feb 6 20:18:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Feb 2007 15:18:08 -0500 Subject: kqemu is now GPLv2 In-Reply-To: <45C8DF77.5020808@leemhuis.info> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061442.45880.jkeating@redhat.com> <45C8DF77.5020808@leemhuis.info> Message-ID: <200702061518.08255.jkeating@redhat.com> On Tuesday 06 February 2007 15:05, Thorsten Leemhuis wrote: > Nevertheless a lot of people want them. I think we should provide a > solution for them. I'm willing to maintain a special repo for them, but > I'd like to do that (and some other things) under the hood of the Fedora > Project. I actually wrote something up about it with more details during > my flight to Boston. But I need to look over it before posting it. In doing so, you create the inevitable lag between updated kernel and updated out of kernel modules. Sometimes that lag can be quite long if Dave does a rebase and the external mod isn't ready to go up to the next kernel version. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Feb 6 20:27:03 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 06 Feb 2007 21:27:03 +0100 Subject: kqemu is now GPLv2 In-Reply-To: <200702061518.08255.jkeating@redhat.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061442.45880.jkeating@redhat.com> <45C8DF77.5020808@leemhuis.info> <200702061518.08255.jkeating@redhat.com> Message-ID: <45C8E497.1050001@leemhuis.info> Jesse Keating schrieb: > On Tuesday 06 February 2007 15:05, Thorsten Leemhuis wrote: >> Nevertheless a lot of people want them. I think we should provide a >> solution for them. I'm willing to maintain a special repo for them, but >> I'd like to do that (and some other things) under the hood of the Fedora >> Project. I actually wrote something up about it with more details during >> my flight to Boston. But I need to look over it before posting it. > In doing so, you create the inevitable lag between updated kernel and updated > out of kernel modules. Sometimes that lag can be quite long if Dave does a > rebase and the external mod isn't ready to go up to the next kernel version. I'm of course aware of that -- but that can happen with the current kmod stuff in Extras, too. Cu thl From jwboyer at jdub.homelinux.org Tue Feb 6 19:54:30 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 6 Feb 2007 13:54:30 -0600 Subject: kqemu is now GPLv2 In-Reply-To: <200702061442.45880.jkeating@redhat.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061407.41272.jkeating@redhat.com> <20070206193554.GA26132@dudweiler.stuttgart.redhat.com> <200702061442.45880.jkeating@redhat.com> Message-ID: <20070206195430.GB6262@yoda.jdub.homelinux.org> On Tue, Feb 06, 2007 at 02:42:45PM -0500, Jesse Keating wrote: > On Tuesday 06 February 2007 14:35, Florian La Roche wrote: > > Fabrice did give an ok to package the old kqemu for Fedora, just didn't > > want to see it offered for Red Hat's enterprise offerings. The Fedora rules > > about what licenses we ship as been the barrier for inclusion. > > Yes, I know it has, but all external kmods make me want to punch kittens. > That and the craptastic hacks we have to do to support them. > > When we move to the unified tree of packages, I really don't want to hold > kernel updates up for all the extra kmods to be built against it, but if I > don't the repo will not be clean. This will be a serious problem, one of the > reasons I was very very very against allowing external kmods in Fedora. To be fair, not all of us were aware of the grand plans to merge when kmods were first introduced. It can be worked on. Nothing is immune from change. josh From jkeating at redhat.com Tue Feb 6 20:35:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Feb 2007 15:35:28 -0500 Subject: kqemu is now GPLv2 In-Reply-To: <45C8E497.1050001@leemhuis.info> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061518.08255.jkeating@redhat.com> <45C8E497.1050001@leemhuis.info> Message-ID: <200702061535.28711.jkeating@redhat.com> On Tuesday 06 February 2007 15:27, Thorsten Leemhuis wrote: > I'm of course aware of that -- but that can happen with the current kmod > stuff in Extras, too. All the more reason to not do external kmods as a part of "Fedora". If "Fedora" cares enough about a module that we want to ship it and make it officially available to our users, it needs to be in the kernel package, and DaveJ needs to approve that. Otherwise they should NOT go into Fedora _at_ _all_ as we can't reasonable deliver timely updates without breaking the repository. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Tue Feb 6 22:09:35 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 06 Feb 2007 22:09:35 +0000 Subject: kqemu is now GPLv2 In-Reply-To: <45C8DF77.5020808@leemhuis.info> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061407.41272.jkeating@redhat.com> <20070206193554.GA26132@dudweiler.stuttgart.redhat.com> <200702061442.45880.jkeating@redhat.com> <45C8DF77.5020808@leemhuis.info> Message-ID: <1170799775.29759.969.camel@pmac.infradead.org> On Tue, 2007-02-06 at 21:05 +0100, Thorsten Leemhuis wrote: > Nevertheless a lot of people want them. I think we should provide a > solution for them. I'm willing to maintain a special repo for them, but > I'd like to do that (and some other things) under the hood of the Fedora > Project. We could call it Fedora Flagellation. As long as every normal person can treat it like ATrpms, I suspect we can be persuaded not to care what you do. -- dwmw2 From Axel.Thimm at ATrpms.net Wed Feb 7 00:09:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 7 Feb 2007 01:09:47 +0100 Subject: kqemu is now GPLv2 In-Reply-To: <1170799775.29759.969.camel@pmac.infradead.org> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061407.41272.jkeating@redhat.com> <20070206193554.GA26132@dudweiler.stuttgart.redhat.com> <200702061442.45880.jkeating@redhat.com> <45C8DF77.5020808@leemhuis.info> <1170799775.29759.969.camel@pmac.infradead.org> Message-ID: <20070207000947.GA4594@neu.nirvana> On Tue, Feb 06, 2007 at 10:09:35PM +0000, David Woodhouse wrote: > On Tue, 2007-02-06 at 21:05 +0100, Thorsten Leemhuis wrote: > > Nevertheless a lot of people want them. I think we should provide > > a solution for them. I'm willing to maintain a special repo for > > them, but I'd like to do that (and some other things) under the > > hood of the Fedora Project. > > We could call it Fedora Flagellation. > > As long as every normal person can treat it like ATrpms, I suspect > we can be persuaded not to care what you do. I wonder if the implicit flame against a supporter of Fedora was really neccessary. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Wed Feb 7 00:13:31 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 07 Feb 2007 00:13:31 +0000 Subject: kqemu is now GPLv2 In-Reply-To: <20070207000947.GA4594@neu.nirvana> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061407.41272.jkeating@redhat.com> <20070206193554.GA26132@dudweiler.stuttgart.redhat.com> <200702061442.45880.jkeating@redhat.com> <45C8DF77.5020808@leemhuis.info> <1170799775.29759.969.camel@pmac.infradead.org> <20070207000947.GA4594@neu.nirvana> Message-ID: <1170807211.29759.1074.camel@pmac.infradead.org> On Wed, 2007-02-07 at 01:09 +0100, Axel Thimm wrote: > > As long as every normal person can treat it like ATrpms, I suspect > > we can be persuaded not to care what you do. > > I wonder if the implicit flame against a supporter of Fedora was really > neccessary. It wasn't a flame; people who use such external repositories don't get much support. If someone comes to me with a bunch of packages from somewhere other than Core, Extras and Livna and I suspect that might be part of their problem then I'm likely to be very disinclined to help. Is that really a contentious observation? ATrpms just happened to be the first one which came to mind. -- dwmw2 From jwboyer at jdub.homelinux.org Wed Feb 7 01:28:25 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 6 Feb 2007 19:28:25 -0600 Subject: kqemu is now GPLv2 In-Reply-To: <1170807211.29759.1074.camel@pmac.infradead.org> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061407.41272.jkeating@redhat.com> <20070206193554.GA26132@dudweiler.stuttgart.redhat.com> <200702061442.45880.jkeating@redhat.com> <45C8DF77.5020808@leemhuis.info> <1170799775.29759.969.camel@pmac.infradead.org> <20070207000947.GA4594@neu.nirvana> <1170807211.29759.1074.camel@pmac.infradead.org> Message-ID: <20070207012824.GA8713@yoda.jdub.homelinux.org> On Wed, Feb 07, 2007 at 12:13:31AM +0000, David Woodhouse wrote: > On Wed, 2007-02-07 at 01:09 +0100, Axel Thimm wrote: > > > As long as every normal person can treat it like ATrpms, I suspect > > > we can be persuaded not to care what you do. > > > > I wonder if the implicit flame against a supporter of Fedora was really > > neccessary. > > It wasn't a flame; people who use such external repositories don't get > much support. If someone comes to me with a bunch of packages from > somewhere other than Core, Extras and Livna and I suspect that might be > part of their problem then I'm likely to be very disinclined to help. > Is that really a contentious observation? Livna is not officially part of the Fedora project. And they carry kmods. josh From mspevack at redhat.com Wed Feb 7 03:01:52 2007 From: mspevack at redhat.com (Max Spevack) Date: Tue, 6 Feb 2007 22:01:52 -0500 (EST) Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> Message-ID: On Tue, 6 Feb 2007, Chitlesh GOORAH wrote: > I've already accepted at least the meeting :) I haven't read the rest of the thread yet, but if they want to have a meeting at FOSDEM, I'm obviously happy to be a part of that. I'll be there, and the main reason why I'm going is to have a chance to meet folks (both in Fedora and other distros) who I wouldn't otherwise have a chance to talk to in person. Good job, Chitlesh, for taking the initiative to accept their invitation. See you in a few weeks, 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 andreas.bierfert at lowlatency.de Wed Feb 7 08:15:38 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Wed, 7 Feb 2007 09:15:38 +0100 Subject: kqemu is now GPLv2 In-Reply-To: <200702061535.28711.jkeating@redhat.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061518.08255.jkeating@redhat.com> <45C8E497.1050001@leemhuis.info> <200702061535.28711.jkeating@redhat.com> Message-ID: <20070207091538.667b54f7@alkaid.a.lan> On Tue, 6 Feb 2007 15:35:28 -0500 Jesse Keating wrote: > All the more reason to not do external kmods as a part of "Fedora". > If "Fedora" cares enough about a module that we want to ship it and make it > officially available to our users, it needs to be in the kernel package, and > DaveJ needs to approve that. Otherwise they should NOT go into Fedora _at_ > _all_ as we can't reasonable deliver timely updates without breaking the > repository. Maybe we should just follow a different approach for kmods then? Why not do something like a module manager (I heard some other distros have that ;) )? With it people could easily build their modules themselves but have them integrated via rpm so their filesystems don't go into nirvana after a couple of system upgrades. If you make it easy (and graphical) enough I suspect that people would be ok with it for external module stuff. That would solve the problems of repo inconsistency but still give users what they want... - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From matt at domsch.com Wed Feb 7 13:24:41 2007 From: matt at domsch.com (Matt Domsch) Date: Wed, 7 Feb 2007 07:24:41 -0600 Subject: kqemu is now GPLv2 In-Reply-To: <20070207091538.667b54f7@alkaid.a.lan> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061518.08255.jkeating@redhat.com> <45C8E497.1050001@leemhuis.info> <200702061535.28711.jkeating@redhat.com> <20070207091538.667b54f7@alkaid.a.lan> Message-ID: <20070207132440.GA9305@domsch.com> On Wed, Feb 07, 2007 at 09:15:38AM +0100, Andreas Bierfert wrote: > On Tue, 6 Feb 2007 15:35:28 -0500 > Jesse Keating wrote: > > > All the more reason to not do external kmods as a part of "Fedora". > > If "Fedora" cares enough about a module that we want to ship it and make it > > officially available to our users, it needs to be in the kernel package, and > > DaveJ needs to approve that. Otherwise they should NOT go into Fedora _at_ > > _all_ as we can't reasonable deliver timely updates without breaking the > > repository. > > Maybe we should just follow a different approach for kmods then? Why not do > something like a module manager (I heard some other distros have that ;) )? > With it people could easily build their modules themselves but have them > integrated via rpm so their filesystems don't go into nirvana after a couple of > system upgrades. If you make it easy (and graphical) enough I suspect that > people would be ok with it for external module stuff. That would solve the > problems of repo inconsistency but still give users what they want... At FUDCon, several of us (Jeremy, Thorsten, Jon Masters, and I) discussed adding a clean method into /sbin/installkernel to allow tools like DKMS to hook at that point and rebuild kernel modules if necessary (and if possible). Right now the DKMS autoinstaller runs as a service at reboot time, which is really too late for some things. So, if you've got module source, and a compiler, and if the source builds and works for your new kernel version, you'll be ok. Lots of ifs, but better than absolutely nothing. -Matt From jkeating at redhat.com Wed Feb 7 14:28:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Feb 2007 09:28:14 -0500 Subject: kqemu is now GPLv2 In-Reply-To: <20070207091538.667b54f7@alkaid.a.lan> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061535.28711.jkeating@redhat.com> <20070207091538.667b54f7@alkaid.a.lan> Message-ID: <200702070928.14924.jkeating@redhat.com> On Wednesday 07 February 2007 03:15, Andreas Bierfert wrote: > Maybe we should just follow a different approach for kmods then? Why not do > something like a module manager (I heard some other distros have that ;) )? > With it people could easily build their modules themselves but have them > integrated via rpm so their filesystems don't go into nirvana after a > couple of system upgrades. If you make it easy (and graphical) enough I > suspect that people would be ok with it for external module stuff. That > would solve the problems of repo inconsistency but still give users what > they want... And when they don't rebuild cleanly? Then what? The user is left holding the bag of a broken system should they ever reboot to that new kernel. I am entirely unconvinced that out of tree kernel modules adds any value over the long run. It may work for a kernel or two, but it will lag, it will break, and somebody will get blamed for it, more often than not, it will be us for moving the kernel too fast, or not caring enough about external modules to hold back updates, or, or, or... Out of tree modules _will_ lead to poor user experiences and I do _not_ want the Fedora name attached to _any_ of them. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From matt at domsch.com Wed Feb 7 14:42:35 2007 From: matt at domsch.com (Matt Domsch) Date: Wed, 7 Feb 2007 08:42:35 -0600 Subject: kqemu is now GPLv2 In-Reply-To: <200702070928.14924.jkeating@redhat.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061535.28711.jkeating@redhat.com> <20070207091538.667b54f7@alkaid.a.lan> <200702070928.14924.jkeating@redhat.com> Message-ID: <20070207144235.GB9305@domsch.com> On Wed, Feb 07, 2007 at 09:28:14AM -0500, Jesse Keating wrote: > On Wednesday 07 February 2007 03:15, Andreas Bierfert wrote: > > Maybe we should just follow a different approach for kmods then? Why not do > > something like a module manager (I heard some other distros have that ;) )? > > With it people could easily build their modules themselves but have them > > integrated via rpm so their filesystems don't go into nirvana after a > > couple of system upgrades. If you make it easy (and graphical) enough I > > suspect that people would be ok with it for external module stuff. That > > would solve the problems of repo inconsistency but still give users what > > they want... > > And when they don't rebuild cleanly? Then what? The user is left holding the > bag of a broken system should they ever reboot to that new kernel. > > I am entirely unconvinced that out of tree kernel modules adds any value over > the long run. It may work for a kernel or two, but it will lag, it will > break, and somebody will get blamed for it, more often than not, it will be > us for moving the kernel too fast, or not caring enough about external > modules to hold back updates, or, or, or... Out of tree modules _will_ lead > to poor user experiences and I do _not_ want the Fedora name attached to > _any_ of them. #1: I agree, I really want all kernel modules in the Fedora kernel. No question. For this I push very hard, and where I have influence (or can hack the driver code myself), it gets into upstream. We're not backing down from that stance. #2: For the subset of kernel modules where #1 isn't (yet) reality, we need to strive for #1. In the mean time, having not-yet-merged-upstream-but-in-progress kernel modules available can demonstrate both the value and the bug-freeness of the new code. (e.g. 1000 people have been running it for a month, and no new bug reports have been filed in the last 3 weeks). Here, tools like kmods and DKMS may provide some benefit. It's the same as with updates-testing. It needs to exist, even if we don't necessarily want all mainstream users using it. -Matt From jkeating at redhat.com Wed Feb 7 14:52:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Feb 2007 09:52:21 -0500 Subject: kqemu is now GPLv2 In-Reply-To: <20070207144235.GB9305@domsch.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702070928.14924.jkeating@redhat.com> <20070207144235.GB9305@domsch.com> Message-ID: <200702070952.21841.jkeating@redhat.com> On Wednesday 07 February 2007 09:42, Matt Domsch wrote: > Here, tools like kmods > ?and DKMS may provide some benefit. ?It's the same as with > ?updates-testing. ?It needs to exist, even if we don't necessarily > ?want all mainstream users using it. I agree. Let it exist outside the Fedora namespace though. -- 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 andreas.bierfert at lowlatency.de Wed Feb 7 16:05:16 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Wed, 7 Feb 2007 17:05:16 +0100 Subject: kqemu is now GPLv2 In-Reply-To: <200702070928.14924.jkeating@redhat.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061535.28711.jkeating@redhat.com> <20070207091538.667b54f7@alkaid.a.lan> <200702070928.14924.jkeating@redhat.com> Message-ID: <20070207170516.12eef5f7@alkaid.a.lan> On Wed, 7 Feb 2007 09:28:14 -0500 Jesse Keating wrote: > On Wednesday 07 February 2007 03:15, Andreas Bierfert wrote: > > Maybe we should just follow a different approach for kmods then? Why not do > > something like a module manager (I heard some other distros have that ;) )? > > With it people could easily build their modules themselves but have them > > integrated via rpm so their filesystems don't go into nirvana after a > > couple of system upgrades. If you make it easy (and graphical) enough I > > suspect that people would be ok with it for external module stuff. That > > would solve the problems of repo inconsistency but still give users what > > they want... > > And when they don't rebuild cleanly? Then what? The user is left holding > the bag of a broken system should they ever reboot to that new kernel. Yes, but maybe then the user should be given the choice to either reboot the system with the new kernel (but missing module(s)) or stick with the old till the module rebuilds. And to be honest: If a system goes into nirvana because one of these modules is missing then I wonder how the system got installed in the first place... > I am entirely unconvinced that out of tree kernel modules adds any value over > the long run. It may work for a kernel or two, but it will lag, it will > break, and somebody will get blamed for it, more often than not, it will be > us for moving the kernel too fast, or not caring enough about external > modules to hold back updates, or, or, or... Out of tree modules _will_ lead > to poor user experiences and I do _not_ want the Fedora name attached to > _any_ of them. Maybe out of tree kernel modules lead to these things and having an idealistic view of moving everything into the upstream kernel is something I am fine with but the problem is this: modules exist outside the kernel tree for various reasons and they will exists no matter how hard we try to get everything we want into the upstream kernel. To me the most important thing in fedora is user experience and having modules for e.g. hardware available clearly is one of the most basic and important things. If the modules are free in the fedora sense why should we keep our users away from them? What I am suggesting is just that we add an option to deliver a out of tree fedora kmod management tool so that the user user experience does not suffer but we also solve the infrastructure problems we face and could face. In a sense they then still will be second class fedora 'packages' and I think that is a clear sign for upstream and users to work on an integration to the kernel (add big red bold fancy 3D letters to state this ;) ). Maybe what I am trying to say is just this (regarding free modules): Support and endorse out of tree modules to get integrated into the upstream kernel and where possible support upstream to reach that goal. If that is not possible or not desirable for some reason try to convince people to still do it but also give users a chance to use the module via our magic management tool. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From andreas.bierfert at lowlatency.de Wed Feb 7 16:08:30 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Wed, 7 Feb 2007 17:08:30 +0100 Subject: kqemu is now GPLv2 In-Reply-To: <20070207132440.GA9305@domsch.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061518.08255.jkeating@redhat.com> <45C8E497.1050001@leemhuis.info> <200702061535.28711.jkeating@redhat.com> <20070207091538.667b54f7@alkaid.a.lan> <20070207132440.GA9305@domsch.com> Message-ID: <20070207170830.3a540653@alkaid.a.lan> On Wed, 7 Feb 2007 07:24:41 -0600 Matt Domsch wrote: > At FUDCon, several of us (Jeremy, Thorsten, Jon Masters, and I) > discussed adding a clean method into /sbin/installkernel to allow > tools like DKMS to hook at that point and rebuild kernel modules if > necessary (and if possible). Right now the DKMS autoinstaller runs as > a service at reboot time, which is really too late for some things. > So, if you've got module source, and a compiler, and if the source > builds and works for your new kernel version, you'll be ok. Lots of > ifs, but better than absolutely nothing. That sound like a good plan to me. I think with some effort some of the ifs could probably be sorted out into something usable. Is there a plan who is working on this and is there a way to contribute? I would really like to test this and get something going... - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Wed Feb 7 16:19:17 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Feb 2007 10:19:17 -0600 Subject: kqemu is now GPLv2 In-Reply-To: <20070207170516.12eef5f7@alkaid.a.lan> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061535.28711.jkeating@redhat.com> <20070207091538.667b54f7@alkaid.a.lan> <200702070928.14924.jkeating@redhat.com> <20070207170516.12eef5f7@alkaid.a.lan> Message-ID: >>>>> "AB" == Andreas Bierfert writes: AB> And to be honest: If a system goes into nirvana because one of AB> these modules is missing then I wonder how the system got AB> installed in the first place... Think about driver disks. I have CentOS machines which will have no disks at all after a reboot to a new kernel due to lack of RAID controller drivers (Areca, specifically). - J< From davej at redhat.com Wed Feb 7 16:23:32 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 7 Feb 2007 11:23:32 -0500 Subject: kqemu is now GPLv2 In-Reply-To: <20070207170516.12eef5f7@alkaid.a.lan> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061535.28711.jkeating@redhat.com> <20070207091538.667b54f7@alkaid.a.lan> <200702070928.14924.jkeating@redhat.com> <20070207170516.12eef5f7@alkaid.a.lan> Message-ID: <20070207162332.GA15687@redhat.com> On Wed, Feb 07, 2007 at 05:05:16PM +0100, Andreas Bierfert wrote: > To me the most important thing in fedora is user > experience and having modules for e.g. hardware available clearly is one of the > most basic and important things. I'm tired of hearing this 'user experience' as an excuse for this. What about the user experience when they hit a bug in the kernel, and can't upgrade to a fixed version because their module doesn't work on the new one? What about the user experience when they file bugs and the Fedora kernel team refuses to look at them unless the module is removed (which they don't want to do?) What about the user experience when equivalent functionality (but different/incompatible) is merged upstream ? What about the user experience when someone hoses their initrd, and their system doesn't boot any more? This part of the boot process is _really_ fragile, so some bogus module can break this unintentionally very easily. See the disaster from FC3 era when livna shipped a horked nvidia module. (That particular event cost me a lot of hours over ~2-3 months, chasing a bug that a) I couldn't fix and b) wasn't even caused by anything I did, so yes, I'm somewhat jaded by external modules) improving "user experience" is not an excuse for doing this whilst people conveniently ignore the parts that *ruin* user experience for others. > If the modules are free in the fedora sense > why should we keep our users away from them? How about increased workload for the kernel team for one? I don't see anyone doing much to improve *my* user experience. > In a sense they then still will be second > class fedora 'packages' This doesn't work. People take the attitude "You shipped it, you support it". We had this fiasco with RHEL3 when we shipped a 'kernel-unsupported' package. > and I think that is a clear sign for upstream and users > to work on an integration to the kernel (add big red bold fancy 3D letters to > state this ;) ). Or it could be seen as a clear sign "Why do I need to bother getting it upstream, it's in the distros". Lack of integration is a bargaining chip. Imagine if we'd taken the same stance with Xen, maybe it'd be upstream by now. > Support and endorse out of tree modules to get integrated into the upstream > kernel and where possible support upstream to reach that goal. 'where possible' basically comes down to "magic up some extra engineers" because unless someone with kernel knowledge is explicitly affected by it, this won't happen. The number of cases that this _has_ happened, has been very low. The only one that jumps to mind is bcm43xx when dwmw2 cared about it until it got upstream, fixing it where it broke for him, and interacting with the upstream. > If that is not > possible or not desirable for some reason try to convince people to still do it > but also give users a chance to use the module via our magic management tool. I'm not a big fan of 'magic'. Dave -- http://www.codemonkey.org.uk From smooge at gmail.com Wed Feb 7 19:15:43 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 7 Feb 2007 12:15:43 -0700 Subject: kqemu is now GPLv2 In-Reply-To: <20070207162332.GA15687@redhat.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061535.28711.jkeating@redhat.com> <20070207091538.667b54f7@alkaid.a.lan> <200702070928.14924.jkeating@redhat.com> <20070207170516.12eef5f7@alkaid.a.lan> <20070207162332.GA15687@redhat.com> Message-ID: <80d7e4090702071115s3f6e491cr88772a4a825bca0a@mail.gmail.com> On 2/7/07, Dave Jones wrote: > On Wed, Feb 07, 2007 at 05:05:16PM +0100, Andreas Bierfert wrote: > > > To me the most important thing in fedora is user > > experience and having modules for e.g. hardware available clearly is one of the > > most basic and important things. > > I'm tired of hearing this 'user experience' as an excuse for this. > What about the user experience when they hit a bug in the kernel, and can't > upgrade to a fixed version because their module doesn't work on the new one? > What about the user experience when they file bugs and the Fedora kernel > team refuses to look at them unless the module is removed (which they don't want to do?) > What about the user experience when equivalent functionality (but different/incompatible) > is merged upstream ? > What about the user experience when someone hoses their initrd, and their > system doesn't boot any more? This part of the boot process is _really_ fragile, > so some bogus module can break this unintentionally very easily. > See the disaster from FC3 era when livna shipped a horked nvidia module. > (That particular event cost me a lot of hours over ~2-3 months, chasing a bug > that a) I couldn't fix and b) wasn't even caused by anything I did, so yes, > I'm somewhat jaded by external modules) > Ok users are going to complain, not use, and rant about how bad Fedora is because: A) the kernel doesn't have the modules for their hardware and tells users to use get their favorite module pushed upstream. B) the kernel keeps breaking out-of-stream modules from other repos [since the only way to enforce a pure upstream kernel will be to drop all dkms/kmod/etc from the new combined core+extras repository] FAB gets to choose which one and let people know thats how its going to be from then on. People who do not like choice A or choice B can 1) Suck-it-up and fix the problems on non-fedora lists/groups that arise. 2) Find a distro that is better for their needs. 3) Continue to complain, but know that they are silently put into spam filters of core Fedora people. > improving "user experience" is not an excuse for doing this whilst people > conveniently ignore the parts that *ruin* user experience for others. > > > If the modules are free in the fedora sense > > why should we keep our users away from them? > > How about increased workload for the kernel team for one? > I don't see anyone doing much to improve *my* user experience. > Welcome to customer support and working in a service industry :). -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From notting at redhat.com Wed Feb 7 19:29:10 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Feb 2007 14:29:10 -0500 Subject: kqemu is now GPLv2 In-Reply-To: <20070207132440.GA9305@domsch.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061518.08255.jkeating@redhat.com> <45C8E497.1050001@leemhuis.info> <200702061535.28711.jkeating@redhat.com> <20070207091538.667b54f7@alkaid.a.lan> <20070207132440.GA9305@domsch.com> Message-ID: <20070207192909.GC24204@nostromo.devel.redhat.com> Matt Domsch (matt at domsch.com) said: > At FUDCon, several of us (Jeremy, Thorsten, Jon Masters, and I) > discussed adding a clean method into /sbin/installkernel to allow > tools like DKMS to hook at that point and rebuild kernel modules if > necessary (and if possible). Right now the DKMS autoinstaller runs as > a service at reboot time, which is really too late for some things. > So, if you've got module source, and a compiler, and if the source > builds and works for your new kernel version, you'll be ok. Lots of > ifs, but better than absolutely nothing. Have the kernel module packages be 'source' with dependencies on gcc, etc.; then, via triggers, they can automatically rebuild and copy for any kernel. Bill, trigger-happy... From tcallawa at redhat.com Wed Feb 7 20:10:52 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 07 Feb 2007 14:10:52 -0600 Subject: kqemu is now GPLv2 In-Reply-To: <20070207192909.GC24204@nostromo.devel.redhat.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061518.08255.jkeating@redhat.com> <45C8E497.1050001@leemhuis.info> <200702061535.28711.jkeating@redhat.com> <20070207091538.667b54f7@alkaid.a.lan> <20070207132440.GA9305@domsch.com> <20070207192909.GC24204@nostromo.devel.redhat.com> Message-ID: <1170879052.4802.12.camel@dhcp-32-109.ord.redhat.com> On Wed, 2007-02-07 at 14:29 -0500, Bill Nottingham wrote: > Matt Domsch (matt at domsch.com) said: > > At FUDCon, several of us (Jeremy, Thorsten, Jon Masters, and I) > > discussed adding a clean method into /sbin/installkernel to allow > > tools like DKMS to hook at that point and rebuild kernel modules if > > necessary (and if possible). Right now the DKMS autoinstaller runs as > > a service at reboot time, which is really too late for some things. > > So, if you've got module source, and a compiler, and if the source > > builds and works for your new kernel version, you'll be ok. Lots of > > ifs, but better than absolutely nothing. > > Have the kernel module packages be 'source' with dependencies on gcc, > etc.; then, via triggers, they can automatically rebuild and copy for > any kernel. Eww. For what its worth, I'm strongly opposed to any "solution" that requires end-users to have toolchains installed. ~spot From tibbs at math.uh.edu Wed Feb 7 20:25:16 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Feb 2007 14:25:16 -0600 Subject: kqemu is now GPLv2 In-Reply-To: <1170879052.4802.12.camel@dhcp-32-109.ord.redhat.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061518.08255.jkeating@redhat.com> <45C8E497.1050001@leemhuis.info> <200702061535.28711.jkeating@redhat.com> <20070207091538.667b54f7@alkaid.a.lan> <20070207132440.GA9305@domsch.com> <20070207192909.GC24204@nostromo.devel.redhat.com> <1170879052.4802.12.camel@dhcp-32-109.ord.redhat.com> Message-ID: >>>>> "TC" == Tom 'spot' Callaway writes: TC> For what its worth, I'm strongly opposed to any "solution" that TC> requires end-users to have toolchains installed. Well, the currently favored solution of telling them to go away certainly meets that. Personally I favor DKMS (and the attendant toolchain requirement) in an outside repository. And big freaking warnings plastered all over everything saying that you should expect your system to lose drivers when the kernel is updated. Not optimal, but at least it allows me to actually use my hardware. But note that this still doesn't save davej's sanity, because it doesn't matter what repo the kernel modules are in. The bugs still get reported against the kernel. The bottom line is that all we can do is keep this stuff out of Fedora; it's still going to come from somewhere. Our choice is whether or not to work with the people who want to provide these things externally. - J< From andreas.bierfert at lowlatency.de Thu Feb 8 09:50:51 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 8 Feb 2007 10:50:51 +0100 (CET) Subject: kqemu is now GPLv2 In-Reply-To: References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061535.28711.jkeating@redhat.com> <20070207091538.667b54f7@alkaid.a.lan> <200702070928.14924.jkeating@redhat.com> <20070207170516.12eef5f7@alkaid.a.lan> Message-ID: <1595.137.120.176.150.1170928251.squirrel@heapsort.de> On Wed, February 7, 2007 5:19 pm, Jason L Tibbitts III said: > Think about driver disks. I have CentOS machines which will have no > disks at all after a reboot to a new kernel due to lack of RAID > controller drivers (Areca, specifically). Well but the thing is: Without the drivers you would not be able to use the system at all and I guess if they happen to brake it is easier to stick with the old working kernel till drivers are fixed then to do nothing. Sure I am aware of the security implications this might have but then again using external modules is not something we endorse and people should be warned about also in a security sense. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred From chitlesh at fedoraproject.org Thu Feb 8 10:08:49 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 8 Feb 2007 11:08:49 +0100 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> Message-ID: <13dbfe4f0702080208g1df78710s4c08852276512ffa@mail.gmail.com> On 2/7/07, Max Spevack wrote: > Good job, Chitlesh, for taking the initiative to accept their invitation. > > See you in a few weeks, Thanks Max. Now that everyone gave their opinions, what are the items you (FAB) want to bring forward? - marketing ? - better compatibilities [src.rpm,...]? - KDE ? - [...] regards, Chitlesh -- http://clunixchit.blogspot.com From andreas.bierfert at lowlatency.de Thu Feb 8 10:20:31 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 8 Feb 2007 11:20:31 +0100 (CET) Subject: kqemu is now GPLv2 In-Reply-To: <20070207162332.GA15687@redhat.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702061535.28711.jkeating@redhat.com> <20070207091538.667b54f7@alkaid.a.lan> <200702070928.14924.jkeating@redhat.com> <20070207170516.12eef5f7@alkaid.a.lan> <20070207162332.GA15687@redhat.com> Message-ID: <1692.137.120.176.150.1170930031.squirrel@heapsort.de> On Wed, February 7, 2007 5:23 pm, Dave Jones said: > I'm tired of hearing this 'user experience' as an excuse for this. > What about the user experience when they hit a bug in the kernel, and > can't > upgrade to a fixed version because their module doesn't work on the new > one? > What about the user experience when they file bugs and the Fedora kernel > team refuses to look at them unless the module is removed (which they > don't want to do?) > What about the user experience when equivalent functionality (but > different/incompatible) > is merged upstream ? Well interesting to call the an excuse. It seems to me that always when this discussion comes up we get to the point where people say this is an excuse and try to finish the topic. I don't think it is an excuse and you certainly don't have to tell me what could go wrong... I might not be a kernel guru but I have been using RHL for a long time and worked with external modules and I know what can go wrong. The thing is this: All the questions you bring forward are valid! These are things that can go wrong. The point is: A lot of systems don't work or don't quiet work because of this. I just had one of these cases a couple of days ago where a wlan driver was missing for a system... If we would have had a way to install this out of tree module there would be one fedora box more out there. This might not be a justification but look at the bigger pictures: Why block all attempts to get something going? Why not think together about the ifs and whats and define a clear process on how support and issues will be dealt with. > What about the user experience when someone hoses their initrd, and their > system doesn't boot any more? This part of the boot process is _really_ > fragile, > so some bogus module can break this unintentionally very easily. > See the disaster from FC3 era when livna shipped a horked nvidia module. > (That particular event cost me a lot of hours over ~2-3 months, chasing a > bug > that a) I couldn't fix and b) wasn't even caused by anything I did, so > yes, > I'm somewhat jaded by external modules) Yes I remember this and that is why I think we need to find a solution which will avoid such issues and if it would be great to have someone like you helping with the planning. Keeping this out of Fedora will just lead to more situations like this because 3rd party repos will do it anyway. Building something under the fedora hood will give us the chance to at least push it in the direction we want. > > If the modules are free in the fedora sense > > why should we keep our users away from them? > > How about increased workload for the kernel team for one? > I don't see anyone doing much to improve *my* user experience. > > > In a sense they then still will be second > > class fedora 'packages' > > This doesn't work. People take the attitude "You shipped it, you support > it". > We had this fiasco with RHEL3 when we shipped a 'kernel-unsupported' > package. Well first of all the RHEL audience is somewhat different then the Fedora audience and if it we find a clear definition for what we support on this matter and what we don't and make clear that people understand it. > Or it could be seen as a clear sign "Why do I need to bother getting it > upstream, it's in the distros". Lack of integration is a bargaining chip. > Imagine if we'd taken the same stance with Xen, maybe it'd be upstream by > now. Actually I was going to bring up the Xen part to rant about it ;). I think things here can probably go into both directions. It is sad that Xen still is not part of the upstream kernel but I guess with KVM in the upstream tree the Xen team will have no other choice as to integrate it before people get used to other approaches and forget about Xen. It will be interesting to see if the Xen folks react now. If they do I would say it could be the example we can bring up at other upstream modules and to stick with the original topic: I guess the addition of KVM is one of the reasons why kqemu is GPLed now. Anyway this does however not mean that we should ignore the stuff that is out there. > 'where possible' basically comes down to "magic up some extra engineers" > because unless someone with kernel knowledge is explicitly affected by it, > this won't happen. The number of cases that this _has_ happened, has > been very low. The only one that jumps to mind is bcm43xx when dwmw2 > cared about it until it got upstream, fixing it where it broke for him, > and interacting with the upstream. It was dwmw2? :D Than thanks had one of these a while back an not knowingly profited from that. What do you mean with "magic up some extra engineers"? I think if someone puts up a kernel module for review he/she should at least have some basic kernel knowledge and know what he/she is doing. I am no expert but if you look at the kernel source and some articles on the web fixing stuff or at least analyze and report it is in most cases not that difficult. Remember we are talking about free modules for which we have the source code. > I'm not a big fan of 'magic'. Hm, thats sad I always liked it ;) Well just something that came up while going over my reply: We always talk about why certain things should be merged upstream. To me this is in the same line as questions like why do we patch the kernel. Not in a Xen regard where is serves as an extension but we also strip stuff from it that is there in the original kernel. People could ask why we do that as well as that stuff is upstream. Sorry if that is to much of topic but not everything that is upstream is something we ship as well... - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred From jkeating at redhat.com Thu Feb 8 13:32:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Feb 2007 08:32:49 -0500 Subject: kqemu is now GPLv2 In-Reply-To: <1595.137.120.176.150.1170928251.squirrel@heapsort.de> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <1595.137.120.176.150.1170928251.squirrel@heapsort.de> Message-ID: <200702080832.49840.jkeating@redhat.com> On Thursday 08 February 2007 04:50, Andreas Bierfert wrote: > then again using external modules is not something we endorse If it is not something we endorse, they should not exist _at_ _all_ in _any_ official Fedora repository. -- 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 Thu Feb 8 13:40:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Feb 2007 08:40:57 -0500 Subject: kqemu is now GPLv2 In-Reply-To: <1692.137.120.176.150.1170930031.squirrel@heapsort.de> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <20070207162332.GA15687@redhat.com> <1692.137.120.176.150.1170930031.squirrel@heapsort.de> Message-ID: <200702080840.57974.jkeating@redhat.com> On Thursday 08 February 2007 05:20, Andreas Bierfert wrote: > Yes I remember this and that is why I think we need to find a solution > which will avoid such issues and if it would be great to have someone like > you helping with the planning. Keeping this out of Fedora will just lead > to more situations like this because 3rd party repos will do it anyway. > Building something under the fedora hood will give us the chance to at > least push it in the direction we want. The direction we want is upstream. Period. Anything short of that is a shortcut that vendors / authors can take and be happy with it and never try to get it upstream. Yes, it is hard to get stuff upstream because your stuff has to not suck, and somepeople don't want to hear that. But frankly, if your stuff sucks too much to go upstream, I really don't want it on Fedora users's systems either. We as Fedora don't have to rule the world, we don't have to have every computer installed with Fedora. What we _do_ have to do is be a responsible distribution and do what's best for our users over time, and that is making it extremely clear to kernel module developers, get it upstream, or count Fedora out. > > > ?> If the modules are free in the fedora sense > > ?> why should we keep our users away from them? > > > > How about increased workload for the kernel team for one? > > I don't see anyone doing much to improve *my* user experience. > > > > ?> In a sense they then still will be second > > ?> class fedora 'packages' > > > > This doesn't work. ?People take the attitude "You shipped it, you support > > it". > > We had this fiasco with RHEL3 when we shipped a 'kernel-unsupported' > > package. > > Well first of all the RHEL audience is somewhat different then the Fedora > audience and if it we find a clear definition for what we support on this > matter and what we don't and make clear that people understand it. Riiiiight. With RHEL, people are signing contracts that clearly state what their support level is. Nothing like this exists with Fedora, nor should it ever. It would be _extremely_ difficult to try and define something like this. The very simple answer is "If it didn't come from an Official Fedora repo, we will NOT care about it." Since we don't care about out of kernel modules for the support side of things, simple answer, no out of tree modules in an official Fedora repo. -- 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 andreas.bierfert at lowlatency.de Thu Feb 8 16:29:36 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 8 Feb 2007 17:29:36 +0100 Subject: kqemu is now GPLv2 In-Reply-To: <200702080840.57974.jkeating@redhat.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <20070207162332.GA15687@redhat.com> <1692.137.120.176.150.1170930031.squirrel@heapsort.de> <200702080840.57974.jkeating@redhat.com> Message-ID: <20070208172936.68c35069@alkaid.a.lan> On Thu, 8 Feb 2007 08:40:57 -0500 Jesse Keating wrote: > The direction we want is upstream. Period. Anything short of that is a > shortcut that vendors / authors can take and be happy with it and never try > to get it upstream. Yes, it is hard to get stuff upstream because your stuff > has to not suck, and somepeople don't want to hear that. But frankly, if > your stuff sucks too much to go upstream, I really don't want it on Fedora > users's systems either. We as Fedora don't have to rule the world, we don't > have to have every computer installed with Fedora. What we _do_ have to do > is be a responsible distribution and do what's best for our users over time, > and that is making it extremely clear to kernel module developers, get it > upstream, or count Fedora out. So stop right there please: Could you rephrase this to "The direction I want is upstream. Period." It is not the direction I want to see things going at least not without a s/Period// and I think for that matter we do have discussions and some form of democracy here +). > > Well first of all the RHEL audience is somewhat different then the Fedora > > audience and if it we find a clear definition for what we support on this > > matter and what we don't and make clear that people understand it. > > Riiiiight. With RHEL, people are signing contracts that clearly state what > their support level is. Nothing like this exists with Fedora, nor should it > ever. It would be _extremely_ difficult to try and define something like > this. The very simple answer is "If it didn't come from an Official Fedora > repo, we will NOT care about it." Since we don't care about out of kernel > modules for the support side of things, simple answer, no out of tree modules > in an official Fedora repo. If we cut the last two sentences I totally agree. I mean that raises the questions what we actually do deliver as end user support for fedora things and if we should better document that nobody will guarantee support for anything in Fedora. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Feb 8 16:38:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Feb 2007 11:38:44 -0500 Subject: kqemu is now GPLv2 In-Reply-To: <20070208172936.68c35069@alkaid.a.lan> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702080840.57974.jkeating@redhat.com> <20070208172936.68c35069@alkaid.a.lan> Message-ID: <200702081138.44664.jkeating@redhat.com> On Thursday 08 February 2007 11:29, Andreas Bierfert wrote: > If we cut the last two sentences I totally agree. I mean that raises the > questions what we actually do deliver as end user support for fedora things > and if we should better document that nobody will guarantee support for > anything in Fedora. In case you missed it, the Fedora Project doesn't guarantee nor provide any "support" for anything in Fedora. -- 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 andreas.bierfert at lowlatency.de Thu Feb 8 16:47:13 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 8 Feb 2007 17:47:13 +0100 Subject: kqemu is now GPLv2 In-Reply-To: <200702081138.44664.jkeating@redhat.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702080840.57974.jkeating@redhat.com> <20070208172936.68c35069@alkaid.a.lan> <200702081138.44664.jkeating@redhat.com> Message-ID: <20070208174713.2d9c115b@alkaid.a.lan> On Thu, 8 Feb 2007 11:38:44 -0500 Jesse Keating wrote: > In case you missed it, the Fedora Project doesn't guarantee nor provide > any "support" for anything in Fedora. I did not but I suspect that users will because the big red letters are missing. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From andreas.bierfert at lowlatency.de Thu Feb 8 17:09:04 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 8 Feb 2007 18:09:04 +0100 Subject: kqemu is now GPLv2 In-Reply-To: <200702080832.49840.jkeating@redhat.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <1595.137.120.176.150.1170928251.squirrel@heapsort.de> <200702080832.49840.jkeating@redhat.com> Message-ID: <20070208180904.35f55acc@alkaid.a.lan> On Thu, 8 Feb 2007 08:32:49 -0500 Jesse Keating wrote: > On Thursday 08 February 2007 04:50, Andreas Bierfert wrote: > > then again using external modules is not something we endorse > > If it is not something we endorse, they should not exist _at_ _all_ in _any_ > official Fedora repository. Hm well maybe endorse is not a good choice of words here. First let us set something straight about my position on this before this just ends up as a non constructive flame discussion: 1. I do not like out of tree kernel modules. 2. We should try everything possible to get out of tree modules upstream. 3. We should try to find a (hopefully) interim solution that allows fedora users to use out of tree modules in an easy and user friendly way. You agree with me in 1 and 2 you made that clear and even if a lot of packaging folks don't say anything here or agree with you I think a lot of users do not. Why is it so hard to start thinking of an _adequate_ way to solve this problem where 1&2 is just one part to the solution and 3 is also part of it? To give you one example: We all do very much dislike (avoiding the word hate) the graphics drivers from nvidia and ati but I would guess that these two are the among the most downloaded packages from e.g. livna because it is what people use free or not. These are prominent non-free kmods of course. If we would provide a way to at least give users a chance to get the free ones via standard fedora distribution ways (like the DKMS stuff as one example) we could eliminate one aspect that currently is missing for end users. I know that this is can not easily be solved as the long discussions showed before even the current kmod spec was used but if we work _together_ now to find a solution all people could live with especially regarding bugs against fedora packages which originate from out of tree modules. How can we do this? I think what has been proposed so far is actually not such a bad idea if worked on and constructively commented by people like you. How about we taint the kernel if one of the out of tree modules is installed so it is easy to tell in case of 'false' bug reports etc.? There are so many things that could be done and (provided it is not in python [darn now I disqualified myself again]) I and a lot of other people from the community (before somebody asks community includes RH folks) would be happy to help with. I know this is not an easy topic to talk about and sorry that I as a little unknown guy which happens to be in FESCo finally decided to stick up for what I think is bringing it up but I think the topic deserves more then just a Period. It not against you nor any other RH folks it is for Fedora. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Thu Feb 8 17:33:46 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 8 Feb 2007 12:33:46 -0500 Subject: kqemu is now GPLv2 In-Reply-To: <20070208180904.35f55acc@alkaid.a.lan> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <1595.137.120.176.150.1170928251.squirrel@heapsort.de> <200702080832.49840.jkeating@redhat.com> <20070208180904.35f55acc@alkaid.a.lan> Message-ID: <20070208173346.GB14352@redhat.com> On Thu, Feb 08, 2007 at 06:09:04PM +0100, Andreas Bierfert wrote: > How can we do this? I think what has been proposed so far is actually not such > a bad idea if worked on and constructively commented by people like you. How > about we taint the kernel if one of the out of tree modules is installed so it > is easy to tell in case of 'false' bug reports etc.? tainting is only useful if the bug is an oops. This makes up a tiny fraction (probably <10%) of bug reports we get against the kernel. Dave -- http://www.codemonkey.org.uk From jkeating at redhat.com Thu Feb 8 17:55:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Feb 2007 12:55:51 -0500 Subject: kqemu is now GPLv2 In-Reply-To: <20070208180904.35f55acc@alkaid.a.lan> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702080832.49840.jkeating@redhat.com> <20070208180904.35f55acc@alkaid.a.lan> Message-ID: <200702081255.54903.jkeating@redhat.com> On Thursday 08 February 2007 12:09, Andreas Bierfert wrote: > If we would provide a way to at least give users a chance to get the free > ones via standard fedora distribution ways (like the DKMS stuff as one > example) we could eliminate one aspect that currently is missing for end > users. I know that this is can not easily be solved as the long discussions > showed before even the current kmod spec was used but if we work _together_ > now to find a solution all people could live with especially regarding bugs > against fedora packages which originate from out of tree modules. I don't want to see this, as I don't want external kernel modules to be seen at all as an acceptable scenario, be it temporary or permanent. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Thu Feb 8 20:18:47 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 08 Feb 2007 15:18:47 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <13dbfe4f0702080208g1df78710s4c08852276512ffa@mail.gmail.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <13dbfe4f0702080208g1df78710s4c08852276512ffa@mail.gmail.com> Message-ID: <45CB85A7.3020602@redhat.com> Chitlesh GOORAH wrote: > > Now that everyone gave their opinions, what are the items you (FAB) > want to bring forward? > - marketing ? > - better compatibilities [src.rpm,...]? > - KDE ? I don't seem to be overly negative, but what is a concrete example of a possible way to cooperate in a meaningful way? Warren Togami wtogami at redhat.com From chitlesh at fedoraproject.org Thu Feb 8 20:49:06 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 8 Feb 2007 21:49:06 +0100 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <45CB85A7.3020602@redhat.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <13dbfe4f0702080208g1df78710s4c08852276512ffa@mail.gmail.com> <45CB85A7.3020602@redhat.com> Message-ID: <13dbfe4f0702081249t4cd025c3qb91930f533f6a573@mail.gmail.com> On 2/8/07, Warren Togami wrote: > I don't seem to be overly negative, but what is a concrete example of a > possible way to cooperate in a meaningful way? I don't know. I just feel that if we meet them, we should talk as a fedora ambassador/contributor who was supposed to represent the whole fedora team. And this team should at least warned/informed us about what is best for it :) Now, knowing the fact that most of fedora people who will be there might only be a fedora contributor with little power and contribution experience, it would be best that "each" fedora project at least say something in respect of cooperation. People on the ground should at least be properly prepared by actual facts and not personal facts. It is the first time, that I have so many responsibilities towards the fedora project. I just want to be supported by the Fedora team for the best of Fedora. With the merge, we all see a strong fedora community, but there are many areas within the fedora project where we still have to work. This F7 release is a BIG step for both RH and community, let's help fedora ambassadors do their work properly. Let's now show that we the fedora project are definitely strong (and not strong in public reviews articles only). I just don't want to see a one-man show from the fedora project during the opensuse meeting regards, Chitlesh -- http://clunixchit.blogspot.com From mmcgrath at fedoraproject.org Thu Feb 8 21:49:03 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 8 Feb 2007 15:49:03 -0600 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <45CB85A7.3020602@redhat.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <13dbfe4f0702080208g1df78710s4c08852276512ffa@mail.gmail.com> <45CB85A7.3020602@redhat.com> Message-ID: <3237e4410702081349g4ccac746j87edf2f3d34acc3b@mail.gmail.com> On 2/8/07, Warren Togami wrote: > Chitlesh GOORAH wrote: > > > > Now that everyone gave their opinions, what are the items you (FAB) > > want to bring forward? > > - marketing ? > > - better compatibilities [src.rpm,...]? > > - KDE ? > > I don't seem to be overly negative, but what is a concrete example of a > possible way to cooperate in a meaningful way? > "Nasa spent over a million dollars developing a pen that would write in space. The soviets solved the same problem... by using a pencil" Probably not true but the message is valid. They're doing very similar things that we are and we both could have lots to learn from eachother if communications are there. Pride seems to be the biggest wall between us. -Mike From tcallawa at redhat.com Thu Feb 8 21:54:59 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 08 Feb 2007 15:54:59 -0600 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <3237e4410702081349g4ccac746j87edf2f3d34acc3b@mail.gmail.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <13dbfe4f0702080208g1df78710s4c08852276512ffa@mail.gmail.com> <45CB85A7.3020602@redhat.com> <3237e4410702081349g4ccac746j87edf2f3d34acc3b@mail.gmail.com> Message-ID: <1170971699.19100.2.camel@dhcp-32-109.ord.redhat.com> On Thu, 2007-02-08 at 15:49 -0600, Mike McGrath wrote: > On 2/8/07, Warren Togami wrote: > > Chitlesh GOORAH wrote: > > > > > > Now that everyone gave their opinions, what are the items you (FAB) > > > want to bring forward? > > > - marketing ? > > > - better compatibilities [src.rpm,...]? > > > - KDE ? > > > > I don't seem to be overly negative, but what is a concrete example of a > > possible way to cooperate in a meaningful way? > > > > "Nasa spent over a million dollars developing a pen that would write > in space. The soviets solved the same problem... by using a pencil" > > Probably not true but the message is valid. They're doing very > similar things that we are and we both could have lots to learn from > eachother if communications are there. Pride seems to be the biggest > wall between us. I'm willing to sit down and listen to what they have to say, but I wonder if the ideological differences between our parents (Red Hat, Novell) will keep us from breaking real ground together. Or, let me put it this way: If they have tangible ideas on how we could work together, I'd be interested in hearing them. If anyone in Fedora has tangible ideas on how we could benefit from working with OpenSuSE, I'd be interested in hearing them (and willing to present them in person). If they just want us to publicly endorse them and be their "friend", then I'm not sure there's much interest in doing that. ~spot From skvidal at linux.duke.edu Thu Feb 8 21:57:23 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 08 Feb 2007 16:57:23 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <3237e4410702081349g4ccac746j87edf2f3d34acc3b@mail.gmail.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <13dbfe4f0702080208g1df78710s4c08852276512ffa@mail.gmail.com> <45CB85A7.3020602@redhat.com> <3237e4410702081349g4ccac746j87edf2f3d34acc3b@mail.gmail.com> Message-ID: <1170971843.1451.240.camel@cutter> On Thu, 2007-02-08 at 15:49 -0600, Mike McGrath wrote: > On 2/8/07, Warren Togami wrote: > > Chitlesh GOORAH wrote: > > > > > > Now that everyone gave their opinions, what are the items you (FAB) > > > want to bring forward? > > > - marketing ? > > > - better compatibilities [src.rpm,...]? > > > - KDE ? > > > > I don't seem to be overly negative, but what is a concrete example of a > > possible way to cooperate in a meaningful way? > > > > "Nasa spent over a million dollars developing a pen that would write > in space. The soviets solved the same problem... by using a pencil" > > Probably not true but the message is valid. They're doing very > similar things that we are and we both could have lots to learn from > eachother if communications are there. Pride seems to be the biggest > wall between us. > The folks working on suse's rpm at the lsb packaging meeting were very cool and worth talking to. We had similar problems and, if nothing else, commiserated well and laughed about user requests. Ditto with the Ubuntu people there. more importantly, we're not negotiating over nuclear weapons, here. It's just to talk about whatever and maybe to meet some people. If we go and absolutely nothing beneficial happens we are out absolutely nothing beside a little bit of time. -sv From luis at tieguy.org Thu Feb 8 21:59:36 2007 From: luis at tieguy.org (Luis Villa) Date: Thu, 8 Feb 2007 16:59:36 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <1170971699.19100.2.camel@dhcp-32-109.ord.redhat.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <13dbfe4f0702080208g1df78710s4c08852276512ffa@mail.gmail.com> <45CB85A7.3020602@redhat.com> <3237e4410702081349g4ccac746j87edf2f3d34acc3b@mail.gmail.com> <1170971699.19100.2.camel@dhcp-32-109.ord.redhat.com> Message-ID: <2cb10c440702081359k3d9c47f1w13380b72cf4b0180@mail.gmail.com> On 2/8/07, Tom 'spot' Callaway wrote: > I'm willing to sit down and listen to what they have to say, but I > wonder if the ideological differences between our parents (Red Hat, > Novell) will keep us from breaking real ground together. If nothing else, both projects have a vested interest in appearing independent from those parents. Meeting and finding common ground (where the parent companies have difficulty doing that) might be valuable if for no other reason than it would demonstrate independence. Luis From notting at redhat.com Thu Feb 8 21:59:44 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 8 Feb 2007 16:59:44 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <1170971843.1451.240.camel@cutter> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <13dbfe4f0702080208g1df78710s4c08852276512ffa@mail.gmail.com> <45CB85A7.3020602@redhat.com> <3237e4410702081349g4ccac746j87edf2f3d34acc3b@mail.gmail.com> <1170971843.1451.240.camel@cutter> Message-ID: <20070208215944.GA13287@nostromo.devel.redhat.com> > more importantly, we're not negotiating over nuclear weapons, here. So, disarming the orbital laser is *NOT* part of the agenda? Bill From skvidal at linux.duke.edu Thu Feb 8 22:04:24 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 08 Feb 2007 17:04:24 -0500 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <20070208215944.GA13287@nostromo.devel.redhat.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <13dbfe4f0702080208g1df78710s4c08852276512ffa@mail.gmail.com> <45CB85A7.3020602@redhat.com> <3237e4410702081349g4ccac746j87edf2f3d34acc3b@mail.gmail.com> <1170971843.1451.240.camel@cutter> <20070208215944.GA13287@nostromo.devel.redhat.com> Message-ID: <1170972264.1451.242.camel@cutter> On Thu, 2007-02-08 at 16:59 -0500, Bill Nottingham wrote: > > more importantly, we're not negotiating over nuclear weapons, here. > > So, disarming the orbital laser is *NOT* part of the agenda? > I think we should probably not bring up the orbital laser at all. not unless they want to talk about their non-aggression treaty with the molemen. and I bet they don't want talk about that at all. -sv From Axel.Thimm at ATrpms.net Thu Feb 8 22:23:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Feb 2007 23:23:13 +0100 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> Message-ID: <20070208222313.GA11018@neu.nirvana> On Tue, Feb 06, 2007 at 12:12:25PM +0100, Chitlesh GOORAH wrote: > Hello fedora people :) > > Well I'm forwarding this mail to this mailing list, in search for > concrete opinions about cooperation between fedora and opensuse from > the Fedora Engineering Team or Fedora Ambassadors. > > Suggestions are welcome, however flame wars aren't :) > > I've already accepted at least the meeting :) I think it would be nice to prepare an agenda of the topics that either side is interested in discussing. Maybe starting with a small intro by both groups (I wonder how much the opensuse <-> Novell SuSE relationship is or isn't similar to the Fedora <-> RHEL/Red Hat. I also wonder why the opensuse folks offer a build service for producing Fedora packages, and if anyone is using it). If the topics are known beforehand you can get better input from the various Fedora groups to use at the meeting. > regards, > Chitlesh Goorah > > ---------- Forwarded message ---------- > From: Adrian Schr?ter > To: Chitlesh GOORAH > Date: Tue, 6 Feb 2007 10:03:46 +0100 > Subject: Fedora & openSUSE meeting / cooperation ? > > Hello Chitlesh, > > I have heard that Fedora will be also on the FOSDEM 2007 like openSUSE is. > > What do you think when we do a meeting there, either in small or large > group, > to discuss ways and possibilities how we can cooperate ? > > I do see fields like a common customer hardware database or our openSUSE > build > service, which does support Fedora builds as well as discussion points. But > there are for sure more fields where we could maybe cooperate in a way which > gives us a win-win situation. > > Do you have interest in such a discussion ? > > bye > adrian > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Feb 8 23:00:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 9 Feb 2007 00:00:06 +0100 Subject: external kernel modules (was: kqemu is now GPLv2) In-Reply-To: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> Message-ID: <20070208230006.GB11018@neu.nirvana> On Tue, Feb 06, 2007 at 10:57:02AM -0800, Thomas Chung wrote: > Good news. > Fabrice Bellard, the creator of qemu is now releasing kqemu under GPLv2. > Previously it was released with propriety license. > http://fabrice.bellard.free.fr/qemu/kqemu-changelog.html > Cheers! I have packaged it at ATrpms: http://atrpms.net/name/kqemu/ Other than being useful per se, take it as a demonstration of what the technology around external packaging can offer. No need to wait for upstream vanilla and/or kernel rpm to add it, people needing it including developers at Fedora/RH in matters of virtualization can make use of it immediately. kernel modules packaged outside the kernel have been splitting the developer community of Fedora for some time now, and even the supporters are split in three camps, two binary rpms providing solutions (kmdls and kmods) and one on-the-fly-user-build solution (dkms). I don't want to go too much into political details, e.g. whether Fedora needs to pressure authors to submit to the kernel or not, and if they do submit, how often they should etc. I'm more interested in the technical issues ATM. Just as a fact sheet disarming some of the arguments against kmdls: o scales well: One person can support 11 kernels (it was 17 until 01.01.2007 when ATrpms dropped RHL7.3-FC4 support) for several kmdls for several years now in his spare time. o negligible buildsystem size: In ATrpms' buildsystem support for kmdls took about 100-150 lines of sh, it will not be more for any other buildsystem o very small lead-time: new kmdls for new kernels are in the repo usually less than an hour after a kernel update is made known to me - if the support were in the same build environment this could boil down to minutes and become part of a kernel package release. o "rolling kernel upgrade": No, kmdls cannot do that, but can achieve a similar goal: no reboots for updating non-core parts of the kernel. If parts of the kernel like wireless drivers are officially maintained as kmdls instead of being part of the kernel we wouldn't need to ask for kernel updates whenever a driver needs updating. If the kernel itself doesn't need that often to be swapped this means less reboots and larger uptimes. An existing example are the 1.2.0 and 1.2.1 ipw2200 drivers at ATrpms. Users can switch to and from them w/o a reboot. Another is the fuse kernel module bug (bug #221420) fixed on-the-fly with a kmdl. Of course the main problems remain, but are more social/political ones: o kernel package developers lose control over what the user has installed kernel-wise, it can make debugging more difficult if the user chooses not to mention that he's not using the plain kernel rpm. But better to have th user install foo-kmdl, then foce him to make install in foo and have a non-unistallable, non-packaged foo mangled in the kernel. o kernel module authors may become lazy and not submit (as often) to the kernel. But sometimes this is even not wanted: For example the lm_sensors project can submit to 2.6, but not 2.4 anymore, so they ship kmdls only for 2.4. RHEL3 is feature-frozen, no kqemu will make it in the kernel there, but kmdls for it are available in the URL above. So in fact I think that some of the (political) arguments against kmdls even have a part in favour. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Fri Feb 9 03:44:44 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 8 Feb 2007 21:44:44 -0600 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <1170971699.19100.2.camel@dhcp-32-109.ord.redhat.com> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <13dbfe4f0702080208g1df78710s4c08852276512ffa@mail.gmail.com> <45CB85A7.3020602@redhat.com> <3237e4410702081349g4ccac746j87edf2f3d34acc3b@mail.gmail.com> <1170971699.19100.2.camel@dhcp-32-109.ord.redhat.com> Message-ID: <20070209034443.GD13072@yoda.jdub.homelinux.org> On Thu, Feb 08, 2007 at 03:54:59PM -0600, Tom 'spot' Callaway wrote: > On Thu, 2007-02-08 at 15:49 -0600, Mike McGrath wrote: > > Probably not true but the message is valid. They're doing very > > similar things that we are and we both could have lots to learn from > > eachother if communications are there. Pride seems to be the biggest > > wall between us. There's another potential wall. > I'm willing to sit down and listen to what they have to say, but I > wonder if the ideological differences between our parents (Red Hat, > Novell) will keep us from breaking real ground together. > > Or, let me put it this way: > > If they have tangible ideas on how we could work together, I'd be > interested in hearing them. > > If anyone in Fedora has tangible ideas on how we could benefit from > working with OpenSuSE, I'd be interested in hearing them (and willing to > present them in person). Talking is fine. I have a question for them. It's very pointed, but also pretty important if we're going head down the path of working with them. How is OpenSuSE ensuring that the changes they integrate into their projects are not encumbered by patents given their parent's deal with Microsoft? I realize this is larger than just OpenSuSE. However, given the proximity they have to that issue, it would be good to hear if/what they're doing about it. josh From david at lovesunix.net Fri Feb 9 04:43:42 2007 From: david at lovesunix.net (David Nielsen) Date: Fri, 09 Feb 2007 05:43:42 +0100 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <20070209034443.GD13072@yoda.jdub.homelinux.org> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <13dbfe4f0702080208g1df78710s4c08852276512ffa@mail.gmail.com> <45CB85A7.3020602@redhat.com> <3237e4410702081349g4ccac746j87edf2f3d34acc3b@mail.gmail.com> <1170971699.19100.2.camel@dhcp-32-109.ord.redhat.com> <20070209034443.GD13072@yoda.jdub.homelinux.org> Message-ID: <1170996222.18892.40.camel@dawkins> tor, 08 02 2007 kl. 21:44 -0600, skrev Josh Boyer: > How is OpenSuSE ensuring that the changes they integrate into their projects > are not encumbered by patents given their parent's deal with Microsoft? That one is quite easy, the patent deal only covers the respective companies customers/users, Microsoft could still sue Novell for infringing on patents and vice virsa. So they pretty much have to show the same care as the rest of us or face being at the wrong end of the MS patent cannon. - David Nielsen -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- 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 jwboyer at jdub.homelinux.org Fri Feb 9 05:01:30 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 08 Feb 2007 23:01:30 -0600 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <1170996222.18892.40.camel@dawkins> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <13dbfe4f0702080208g1df78710s4c08852276512ffa@mail.gmail.com> <45CB85A7.3020602@redhat.com> <3237e4410702081349g4ccac746j87edf2f3d34acc3b@mail.gmail.com> <1170971699.19100.2.camel@dhcp-32-109.ord.redhat.com> <20070209034443.GD13072@yoda.jdub.homelinux.org> <1170996222.18892.40.camel@dawkins> Message-ID: <1170997290.3244.2.camel@vader.jdub.homelinux.org> On Fri, 2007-02-09 at 05:43 +0100, David Nielsen wrote: > tor, 08 02 2007 kl. 21:44 -0600, skrev Josh Boyer: > > > How is OpenSuSE ensuring that the changes they integrate into their projects > > are not encumbered by patents given their parent's deal with Microsoft? > > That one is quite easy, the patent deal only covers the respective > companies customers/users, Microsoft could still sue Novell for > infringing on patents and vice virsa. So they pretty much have to show > the same care as the rest of us or face being at the wrong end of the MS > patent cannon. Yes. The potential outcome wasn't my question. What they are doing to actively avoid that is what I asked. E.g. what processes do they follow, etc. josh From david at lovesunix.net Fri Feb 9 05:09:45 2007 From: david at lovesunix.net (David Nielsen) Date: Fri, 09 Feb 2007 06:09:45 +0100 Subject: [Fwd: Fedora & openSUSE meeting / cooperation ?] In-Reply-To: <1170997290.3244.2.camel@vader.jdub.homelinux.org> References: <13dbfe4f0702060312o46f51a8eu8c16afb3e53ff5a6@mail.gmail.com> <13dbfe4f0702080208g1df78710s4c08852276512ffa@mail.gmail.com> <45CB85A7.3020602@redhat.com> <3237e4410702081349g4ccac746j87edf2f3d34acc3b@mail.gmail.com> <1170971699.19100.2.camel@dhcp-32-109.ord.redhat.com> <20070209034443.GD13072@yoda.jdub.homelinux.org> <1170996222.18892.40.camel@dawkins> <1170997290.3244.2.camel@vader.jdub.homelinux.org> Message-ID: <1170997786.18892.43.camel@dawkins> tor, 08 02 2007 kl. 23:01 -0600, skrev Josh Boyer: > On Fri, 2007-02-09 at 05:43 +0100, David Nielsen wrote: > > tor, 08 02 2007 kl. 21:44 -0600, skrev Josh Boyer: > > > > > How is OpenSuSE ensuring that the changes they integrate into their projects > > > are not encumbered by patents given their parent's deal with Microsoft? > > > > That one is quite easy, the patent deal only covers the respective > > companies customers/users, Microsoft could still sue Novell for > > infringing on patents and vice virsa. So they pretty much have to show > > the same care as the rest of us or face being at the wrong end of the MS > > patent cannon. > > Yes. The potential outcome wasn't my question. What they are doing to > actively avoid that is what I asked. E.g. what processes do they > follow, etc. Since they run the same risks as we do I assume they do the same kind of prevention as we do. Never the less it would be good to know their review process, we might be able to learn from each other. - David Nielsen -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- 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 jwboyer at jdub.homelinux.org Fri Feb 9 04:17:05 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 08 Feb 2007 22:17:05 -0600 Subject: kqemu is now GPLv2 In-Reply-To: <200702081138.44664.jkeating@redhat.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702080840.57974.jkeating@redhat.com> <20070208172936.68c35069@alkaid.a.lan> <200702081138.44664.jkeating@redhat.com> Message-ID: <1170994625.27450.4.camel@vader.jdub.homelinux.org> On Thu, 2007-02-08 at 11:38 -0500, Jesse Keating wrote: > On Thursday 08 February 2007 11:29, Andreas Bierfert wrote: > > If we cut the last two sentences I totally agree. I mean that raises the > > questions what we actually do deliver as end user support for fedora things > > and if we should better document that nobody will guarantee support for > > anything in Fedora. > > In case you missed it, the Fedora Project doesn't guarantee nor provide > any "support" for anything in Fedora. You need to revise the front page of fedoraproject.org then. Quote: "The Fedora Project is a Red Hat sponsored and community supported open source project." There's even a section on help and support in the FAQ. We provide support all the damn time. We just don't guarantee problem resolution or turn-around time. josh From jkeating at redhat.com Fri Feb 9 13:24:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 9 Feb 2007 08:24:06 -0500 Subject: kqemu is now GPLv2 In-Reply-To: <1170994625.27450.4.camel@vader.jdub.homelinux.org> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702081138.44664.jkeating@redhat.com> <1170994625.27450.4.camel@vader.jdub.homelinux.org> Message-ID: <200702090824.06831.jkeating@redhat.com> On Thursday 08 February 2007 23:17, Josh Boyer wrote: > You need to revise the front page of fedoraproject.org then. ?Quote: > > "The Fedora Project is a Red Hat sponsored and community supported open > source project." > > There's even a section on help and support in the FAQ. > > We provide support all the damn time. ?We just don't guarantee problem > resolution or turn-around time. You're right, we do need to change it. The term "support" is very overloaded, and should probably be avoided. -- 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 stickster at gmail.com Fri Feb 9 21:03:54 2007 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 09 Feb 2007 16:03:54 -0500 Subject: kqemu is now GPLv2 In-Reply-To: <200702090824.06831.jkeating@redhat.com> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702081138.44664.jkeating@redhat.com> <1170994625.27450.4.camel@vader.jdub.homelinux.org> <200702090824.06831.jkeating@redhat.com> Message-ID: <1171055034.3765.18.camel@localhost.localdomain> On Fri, 2007-02-09 at 08:24 -0500, Jesse Keating wrote: > On Thursday 08 February 2007 23:17, Josh Boyer wrote: > > You need to revise the front page of fedoraproject.org then. Quote: > > > > "The Fedora Project is a Red Hat sponsored and community supported open > > source project." > > > > There's even a section on help and support in the FAQ. > > > > We provide support all the damn time. We just don't guarantee problem > > resolution or turn-around time. > > You're right, we do need to change it. The term "support" is very overloaded, > and should probably be avoided. "Maintained" seems to suffer the same problem of implying a guarantee... what about "backed," "sustained," or "assisted"? The latter might make it sound like we help Fedora down the hall to the bathroom. I personally like the words "buttressed" and "girded." ;-) -- 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: From jkeating at redhat.com Fri Feb 9 21:11:07 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 9 Feb 2007 16:11:07 -0500 Subject: kqemu is now GPLv2 In-Reply-To: <1171055034.3765.18.camel@localhost.localdomain> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702090824.06831.jkeating@redhat.com> <1171055034.3765.18.camel@localhost.localdomain> Message-ID: <200702091611.07644.jkeating@redhat.com> On Friday 09 February 2007 16:03, Paul W. Frields wrote: > "girded." ;-) I AM BENDER. PLEASE INSERT GIRDER. -- 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 david at lovesunix.net Fri Feb 9 21:56:55 2007 From: david at lovesunix.net (David Nielsen) Date: Fri, 09 Feb 2007 22:56:55 +0100 Subject: kqemu is now GPLv2 In-Reply-To: <1171055034.3765.18.camel@localhost.localdomain> References: <369bce3b0702061057m78a9fe26h71f31c1ea10ebe7f@mail.gmail.com> <200702081138.44664.jkeating@redhat.com> <1170994625.27450.4.camel@vader.jdub.homelinux.org> <200702090824.06831.jkeating@redhat.com> <1171055034.3765.18.camel@localhost.localdomain> Message-ID: <1171058215.7465.10.camel@dawkins> fre, 09 02 2007 kl. 16:03 -0500, skrev Paul W. Frields: > On Fri, 2007-02-09 at 08:24 -0500, Jesse Keating wrote: > > On Thursday 08 February 2007 23:17, Josh Boyer wrote: > > > You need to revise the front page of fedoraproject.org then. Quote: > > > > > > "The Fedora Project is a Red Hat sponsored and community supported open > > > source project." > > > > > > There's even a section on help and support in the FAQ. > > > > > > We provide support all the damn time. We just don't guarantee problem > > > resolution or turn-around time. > > > > You're right, we do need to change it. The term "support" is very overloaded, > > and should probably be avoided. > > "Maintained" seems to suffer the same problem of implying a guarantee... > what about "backed," "sustained," or "assisted"? The latter might make > it sound like we help Fedora down the hall to the bathroom. I > personally like the words "buttressed" and "girded." ;-) It's "loved" good and hard for 13 months, then we move on to younger and better looking Fedoras. - David -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- 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 mspevack at redhat.com Mon Feb 12 12:37:29 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 12 Feb 2007 07:37:29 -0500 (EST) Subject: Changes to fedora-advisory-board list Message-ID: When the Fedora Advisory Board mailing list was first set up, it was put together in this way: 1) Archives 100% open to all 2) Non member posting is moderated 3) Member posting is non-moderated 4) Membership is by "approval". 5) People who want to lurk by not post could subscribe to fedora-advisory-board-readonly I've heard from a few people that this has been a source of confusion, and that people who otherwise want to participate on fedora-advisory-board aren't doing so, because they don't realize that we *want* them to participate. So, I've made some changes to the fedora-advisory-board list, effective this morning. Membership is now "confirm via email" rather than "moderater approved" so basically list subscription is now the same as all other Fedora lists. Still, fedora-advisory-board is the place where we like to have some of the higher-level decision making begin, but with the assumption that it will be pushed off to other lists as appropriate. This decision also has the potential to lead to increased traffic on the list. Let's keep the traffic on-topic and high in signal, versus noise. The list's job will be to police its own. *** NOTE *** I will kill off the fedora-advisory-board-readonly list on March 1. Folks who are on that list (and therefore reading this message) are encouraged to subscribe directly to fedora-advisory-board. Let me know if you have any questions. Thanks, 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 mspevack at redhat.com Mon Feb 12 12:45:14 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 12 Feb 2007 13:45:14 +0100 Subject: Changes to fedora-advisory-board list Message-ID: <000901c74ea3$a4315240$ba00000a@grecom.local> When the Fedora Advisory Board mailing list was first set up, it was put together in this way: 1) Archives 100% open to all 2) Non member posting is moderated 3) Member posting is non-moderated 4) Membership is by "approval". 5) People who want to lurk by not post could subscribe to fedora-advisory-board-readonly I've heard from a few people that this has been a source of confusion, and that people who otherwise want to participate on fedora-advisory-board aren't doing so, because they don't realize that we *want* them to participate. So, I've made some changes to the fedora-advisory-board list, effective this morning. Membership is now "confirm via email" rather than "moderater approved" so basically list subscription is now the same as all other Fedora lists. Still, fedora-advisory-board is the place where we like to have some of the higher-level decision making begin, but with the assumption that it will be pushed off to other lists as appropriate. This decision also has the potential to lead to increased traffic on the list. Let's keep the traffic on-topic and high in signal, versus noise. The list's job will be to police its own. *** NOTE *** I will kill off the fedora-advisory-board-readonly list on March 1. Folks who are on that list (and therefore reading this message) are encouraged to subscribe directly to fedora-advisory-board. Let me know if you have any questions. Thanks, 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 -- fedora-announce-list mailing list fedora-announce-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list From mspevack at redhat.com Mon Feb 12 12:45:14 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 12 Feb 2007 13:45:14 +0100 Subject: Changes to fedora-advisory-board list Message-ID: <000001c74ea3$a42a2650$ba00000a@grecom.local> When the Fedora Advisory Board mailing list was first set up, it was put together in this way: 1) Archives 100% open to all 2) Non member posting is moderated 3) Member posting is non-moderated 4) Membership is by "approval". 5) People who want to lurk by not post could subscribe to fedora-advisory-board-readonly I've heard from a few people that this has been a source of confusion, and that people who otherwise want to participate on fedora-advisory-board aren't doing so, because they don't realize that we *want* them to participate. So, I've made some changes to the fedora-advisory-board list, effective this morning. Membership is now "confirm via email" rather than "moderater approved" so basically list subscription is now the same as all other Fedora lists. Still, fedora-advisory-board is the place where we like to have some of the higher-level decision making begin, but with the assumption that it will be pushed off to other lists as appropriate. This decision also has the potential to lead to increased traffic on the list. Let's keep the traffic on-topic and high in signal, versus noise. The list's job will be to police its own. *** NOTE *** I will kill off the fedora-advisory-board-readonly list on March 1. Folks who are on that list (and therefore reading this message) are encouraged to subscribe directly to fedora-advisory-board. Let me know if you have any questions. Thanks, 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 -- fedora-announce-list mailing list fedora-announce-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list From mspevack at redhat.com Tue Feb 13 00:17:35 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 12 Feb 2007 19:17:35 -0500 (EST) Subject: fedora board meeting tuesday Message-ID: We have a Fedora Board meeting on Tuesday at 10:00 AM eastern time, 15:00 GMT. We will be in #fedora-meeting -- as that is the new IRC channel for meetings! The agenda is short, but will take the whole time. 1) Fedora 7 update, including spins, timeline, deadlines, etc. We'll be able to do our pseudo-realtime notes for this. 2) Update on some of the legal issues that have been going on, which will probably not be logged in channel. --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 rdieter at math.unl.edu Wed Feb 14 13:26:19 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 14 Feb 2007 07:26:19 -0600 Subject: akademy sponsorship Message-ID: <45D30DFB.2070800@math.unl.edu> To the powers-that-be with purse-strings, I'm planning an attending the 2007 KDE Contributors Conference, http://akademy2007.kde.org/ and give a presentation on the F7 KDE spin. KDE e.V.(1) recently put out a call for companies and individuals soliciting donations for the event, http://dot.kde.org/1171382220/ http://akademy2007.kde.org/sponsors/ Fedora(2) should seriously consider sponsoring the event. -- Rex (1) KDE e.V. will likely help fund my attendance of the event, so Fedora's sponsorship is more than a worthy cause. (2) or Red Hat, I'm not picky. From mspevack at redhat.com Wed Feb 14 16:00:13 2007 From: mspevack at redhat.com (Max Spevack) Date: Wed, 14 Feb 2007 11:00:13 -0500 (EST) Subject: akademy sponsorship In-Reply-To: <45D30DFB.2070800@math.unl.edu> References: <45D30DFB.2070800@math.unl.edu> Message-ID: On Wed, 14 Feb 2007, Rex Dieter wrote: > Fedora(2) should seriously consider sponsoring the event. I'll take this up with Rex off-list. we should be able to do something. --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 Wed Feb 14 16:06:12 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 14 Feb 2007 17:06:12 +0100 Subject: akademy sponsorship In-Reply-To: <45D30DFB.2070800@math.unl.edu> References: <45D30DFB.2070800@math.unl.edu> Message-ID: <13dbfe4f0702140806o63c0086aid4fd5615dccc9028@mail.gmail.com> On 2/14/07, Rex Dieter wrote: > To the powers-that-be with purse-strings, > > I'm planning an attending the 2007 KDE Contributors Conference, > http://akademy2007.kde.org/ > and give a presentation on the F7 KDE spin. That's great. At that time, F7 will already be released and the fedora-kde sig should be writing its next roadmap. Akademy2007 is just perfectly scheduled to push forward fedora's interest in kde . Chitlsh -- http://clunixchit.blogspot.com From sundaram at fedoraproject.org Mon Feb 19 13:19:47 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Feb 2007 18:49:47 +0530 Subject: Extending FC5 lifecycle? Message-ID: <45D9A3F3.8000207@fedoraproject.org> Hi Can we decide if we wanted to extend the lifecycle of FC5 till F7 is released or not? I know there was some discussions before on that but since F7 is going to have 4 test releases and second test release is expected shortly, we need to determine this now. Rahul From matt at domsch.com Mon Feb 19 13:39:18 2007 From: matt at domsch.com (Matt Domsch) Date: Mon, 19 Feb 2007 07:39:18 -0600 Subject: Extending FC5 lifecycle? In-Reply-To: <45D9A3F3.8000207@fedoraproject.org> References: <45D9A3F3.8000207@fedoraproject.org> Message-ID: <20070219133918.GA24656@domsch.com> On Mon, Feb 19, 2007 at 06:49:47PM +0530, Rahul Sundaram wrote: > Hi > > Can we decide if we wanted to extend the lifecycle of FC5 till F7 is > released or not? I know there was some discussions before on that but > since F7 is going to have 4 test releases and second test release is > expected shortly, we need to determine this now. We decided it would be N+2 plus one month, so FC5 is maintained until one month after F7 is released (whenever that is). We bantered around "13 months", but that's really just shorthand for "N+2 plus 1 month". Thanks, Matt From sundaram at fedoraproject.org Mon Feb 19 13:44:05 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Feb 2007 19:14:05 +0530 Subject: Extending FC5 lifecycle? In-Reply-To: <20070219133918.GA24656@domsch.com> References: <45D9A3F3.8000207@fedoraproject.org> <20070219133918.GA24656@domsch.com> Message-ID: <45D9A9A5.8060608@fedoraproject.org> Matt Domsch wrote: > On Mon, Feb 19, 2007 at 06:49:47PM +0530, Rahul Sundaram wrote: >> Hi >> >> Can we decide if we wanted to extend the lifecycle of FC5 till F7 is >> released or not? I know there was some discussions before on that but >> since F7 is going to have 4 test releases and second test release is >> expected shortly, we need to determine this now. > > We decided it would be N+2 plus one month, so FC5 is maintained until > one month after F7 is released (whenever that is). We bantered around > "13 months", but that's really just shorthand for "N+2 plus 1 month". > Cool. We should send out a broader announcement then. Rahul From Axel.Thimm at ATrpms.net Mon Feb 19 13:51:28 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Feb 2007 14:51:28 +0100 Subject: Extending FC5 lifecycle? In-Reply-To: <45D9A3F3.8000207@fedoraproject.org> References: <45D9A3F3.8000207@fedoraproject.org> Message-ID: <20070219135128.GB623@neu.nirvana> Hi, On Mon, Feb 19, 2007 at 06:49:47PM +0530, Rahul Sundaram wrote: > Can we decide if we wanted to extend the lifecycle of FC5 till F7 is > released or not? I know there was some discussions before on that but > since F7 is going to have 4 test releases and second test release is > expected shortly, we need to determine this now. the suggested timelife was 13 months, e.g. the intention was to allow for two releases and 1 extra month, so that people can upgrade from version N to N+1 with a transition time for this skip-an-intermediate- release-jump of one month. Given that schedules can go back and forth like currently for F7, could the policy be reworded to "ETA is one month after the release of the next-to-next subsequent release which usually sums up to 13 months". That way we wouldn't have to adjust the absolute ETA if a release slips. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Feb 19 13:56:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 19 Feb 2007 14:56:52 +0100 Subject: Extending FC5 lifecycle? In-Reply-To: <45D9A9A5.8060608@fedoraproject.org> References: <45D9A3F3.8000207@fedoraproject.org> <20070219133918.GA24656@domsch.com> <45D9A9A5.8060608@fedoraproject.org> Message-ID: <45D9ACA4.2060406@leemhuis.info> On 19.02.2007 14:44, Rahul Sundaram wrote: > Matt Domsch wrote: >> On Mon, Feb 19, 2007 at 06:49:47PM +0530, Rahul Sundaram wrote: >>> Can we decide if we wanted to extend the lifecycle of FC5 till F7 is >>> released or not? I know there was some discussions before on that but >>> since F7 is going to have 4 test releases and second test release is >>> expected shortly, we need to determine this now. >> We decided it would be N+2 plus one month, so FC5 is maintained until >> one month after F7 is released (whenever that is). We bantered around >> "13 months", but that's really just shorthand for "N+2 plus 1 month". > Cool. We should send out a broader announcement then. +1 -- it IMHO shows nicely one of the IMHO typical Fedora problems: Things get decided, but not properly announced to broader public. I have to admit that this was also a problem of the old FESCo when I was chair, too... CU thl From jwboyer at jdub.homelinux.org Mon Feb 19 14:07:01 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 19 Feb 2007 08:07:01 -0600 Subject: Extending FC5 lifecycle? In-Reply-To: <45D9A9A5.8060608@fedoraproject.org> References: <45D9A3F3.8000207@fedoraproject.org> <20070219133918.GA24656@domsch.com> <45D9A9A5.8060608@fedoraproject.org> Message-ID: <1171894021.24204.17.camel@zod.rchland.ibm.com> On Mon, 2007-02-19 at 19:14 +0530, Rahul Sundaram wrote: > Matt Domsch wrote: > > On Mon, Feb 19, 2007 at 06:49:47PM +0530, Rahul Sundaram wrote: > >> Hi > >> > >> Can we decide if we wanted to extend the lifecycle of FC5 till F7 is > >> released or not? I know there was some discussions before on that but > >> since F7 is going to have 4 test releases and second test release is > >> expected shortly, we need to determine this now. > > > > We decided it would be N+2 plus one month, so FC5 is maintained until > > one month after F7 is released (whenever that is). We bantered around > > "13 months", but that's really just shorthand for "N+2 plus 1 month". > > > > Cool. We should send out a broader announcement then. I can do that. I'll post it to some lists shortly. josh From sundaram at fedoraproject.org Mon Feb 19 14:20:18 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Feb 2007 19:50:18 +0530 Subject: Extending FC5 lifecycle? In-Reply-To: <20070219135128.GB623@neu.nirvana> References: <45D9A3F3.8000207@fedoraproject.org> <20070219135128.GB623@neu.nirvana> Message-ID: <45D9B222.9020306@fedoraproject.org> Axel Thimm wrote: > Hi, > > On Mon, Feb 19, 2007 at 06:49:47PM +0530, Rahul Sundaram wrote: >> Can we decide if we wanted to extend the lifecycle of FC5 till F7 is >> released or not? I know there was some discussions before on that but >> since F7 is going to have 4 test releases and second test release is >> expected shortly, we need to determine this now. > > the suggested timelife was 13 months, e.g. the intention was to allow > for two releases and 1 extra month, so that people can upgrade from > version N to N+1 with a transition time for this skip-an-intermediate- > release-jump of one month. > > Given that schedules can go back and forth like currently for F7, > could the policy be reworded to "ETA is one month after the release of > the next-to-next subsequent release which usually sums up to 13 > months". That way we wouldn't have to adjust the absolute ETA if a > release slips. Right. I was just unsure whether it applied retroactively from FC5 or just for FC6 and future releases. I have updated http://fedoraproject.org/wiki/LifeCycle and http://fedoraproject.org/wiki/FAQ. I intend to send out this announcement to fedora-announce list. Let me know if you spot any mistakes. Extending the life cycle of Fedora releases ------------------------------------------- As proposed earlier in the Fedora Summit [1], Fedora Project has decided to extend the life cycle of Fedora releases. Previously every release of Fedora reaches end of life after FCn+2 test 2 is released which is approximately 9 months. We have now extended this such that every release of Fedora is maintained for a month after FCn+2 is released. This means end users of Fedora Core 5 and Fedora Core 6 will now get updates till after a month after the release of Fedora 7 and 8 respectively. This was planned to allow end users the ability to optionally skip every other release and directly upgrade from N to N+1 release of Fedora. More details available at in our FAQ [2] [1]http://fedoraproject.org/wiki/FedoraSummit/ReleaseProcess [2]http://fedoraproject.org/wiki/FAQ Rahul From Axel.Thimm at ATrpms.net Mon Feb 19 14:30:04 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Feb 2007 15:30:04 +0100 Subject: Extending FC5 lifecycle? In-Reply-To: <45D9B222.9020306@fedoraproject.org> References: <45D9A3F3.8000207@fedoraproject.org> <20070219135128.GB623@neu.nirvana> <45D9B222.9020306@fedoraproject.org> Message-ID: <20070219143004.GD623@neu.nirvana> On Mon, Feb 19, 2007 at 07:50:18PM +0530, Rahul Sundaram wrote: > Right. I was just unsure whether it applied retroactively from FC5 or > just for FC6 and future releases. I have updated > http://fedoraproject.org/wiki/LifeCycle and > http://fedoraproject.org/wiki/FAQ. I intend to send out this > announcement to fedora-announce list. Let me know if you spot any mistakes. > Extending the life cycle of Fedora releases > ------------------------------------------- > > As proposed earlier in the Fedora Summit [1], Fedora Project has decided > to extend the life cycle of Fedora releases. Previously every release of > Fedora reaches end of life after FCn+2 test 2 is released which is > approximately 9 months. We have now extended this such that every > release of Fedora is maintained for a month after FCn+2 is released. Maybe add "resulting to a net release life of approximately 13 months"? We'd like to stress the improvement of 4 additional months, many users will not really know the internals of Fedora release cycles. > This means end users of Fedora Core 5 and Fedora Core 6 will now get > updates till after a month after the release of Fedora 7 and 8 > respectively. This was planned to allow end users the ability to > optionally skip every other release and directly upgrade from N to N+1 > release of Fedora. You mean "from N to N+2". > More details available at in our FAQ [2] > > [1]http://fedoraproject.org/wiki/FedoraSummit/ReleaseProcess > [2]http://fedoraproject.org/wiki/FAQ > > Rahul There was also the forward pointing announcement from Fedora Legacy where it was said that while Fedora Legacy is shutting down efforts were underway to extend the life span of Fedora releases in another way. Do you want to mention Fedora Legacy in the above context? Maybe Jesse has some suggestion. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Mon Feb 19 14:32:49 2007 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 19 Feb 2007 09:32:49 -0500 Subject: Extending FC5 lifecycle? In-Reply-To: <45D9B222.9020306@fedoraproject.org> References: <45D9A3F3.8000207@fedoraproject.org> <20070219135128.GB623@neu.nirvana> <45D9B222.9020306@fedoraproject.org> Message-ID: <1171895569.20354.12.camel@localhost.localdomain> I've provided some Docs editorial magic below... Extending the life cycle of Fedora releases ------------------------------------------- As proposed earlier at the Fedora Summit [1], the Fedora Project has decided to extend the life cycle of Fedora releases. Previously, every release of Fedora reached its end of life (EOL) after the test2 phase of the second following release (FCn+2 test2), or approximately 9 months. For example, Fedora Core 5 was due to reach EOL when Fedora 7 test2 was released. We have now extended this cycle such that every release of Fedora is maintained for a month after final release of the second following release. This means end users of Fedora Core 5 and Fedora Core 6 will now receive updates until a month after the release of Fedora 7 and 8, respectively. This schedule allows end users the ability to optionally skip every other release, and directly upgrade from Fedora N to Fedora N+2. More details are available in the FAQ [2]. [1] http://fedoraproject.org/wiki/FedoraSummit/ReleaseProcess [2] http://fedoraproject.org/wiki/FAQ -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 sundaram at fedoraproject.org Mon Feb 19 14:36:33 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Feb 2007 20:06:33 +0530 Subject: Extending FC5 lifecycle? In-Reply-To: <20070219143004.GD623@neu.nirvana> References: <45D9A3F3.8000207@fedoraproject.org> <20070219135128.GB623@neu.nirvana> <45D9B222.9020306@fedoraproject.org> <20070219143004.GD623@neu.nirvana> Message-ID: <45D9B5F1.6010308@fedoraproject.org> Axel Thimm wrote: >> Extending the life cycle of Fedora releases >> ------------------------------------------- >> >> As proposed earlier in the Fedora Summit [1], Fedora Project has decided >> to extend the life cycle of Fedora releases. Previously every release of >> Fedora reaches end of life after FCn+2 test 2 is released which is >> approximately 9 months. We have now extended this such that every >> release of Fedora is maintained for a month after FCn+2 is released. > > Maybe add "resulting to a net release life of approximately 13 > months"? We'd like to stress the improvement of 4 additional months, > many users will not really know the internals of Fedora release > cycles. Ok. > >> This means end users of Fedora Core 5 and Fedora Core 6 will now get >> updates till after a month after the release of Fedora 7 and 8 >> respectively. This was planned to allow end users the ability to >> optionally skip every other release and directly upgrade from N to N+1 >> release of Fedora. > > You mean "from N to N+2". Duh, yes. Paul W. Frields did it better now. Jesse Keating, do you want to mention Fedora Legacy in this? Rahul From stickster at gmail.com Mon Feb 19 14:49:15 2007 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 19 Feb 2007 09:49:15 -0500 Subject: Extending FC5 lifecycle? In-Reply-To: <45D9B5F1.6010308@fedoraproject.org> References: <45D9A3F3.8000207@fedoraproject.org> <20070219135128.GB623@neu.nirvana> <45D9B222.9020306@fedoraproject.org> <20070219143004.GD623@neu.nirvana> <45D9B5F1.6010308@fedoraproject.org> Message-ID: <1171896555.20354.18.camel@localhost.localdomain> On Mon, 2007-02-19 at 20:06 +0530, Rahul Sundaram wrote: [...snip...] > Jesse Keating, do you want > to mention Fedora Legacy in this? Just to bring out a quick discussion Rahul and I were having on IRC, I'm not sure we want to include that in this particular announcement. Although the subject matter is a good fit, right now we don't have the infrastructure in place to support a resurgence of Legacy. (Let's leave aside the issue of whether anyone actually wants to *do the work*.) Rahul and I are in agreement, I think, that with the merge and other related work currently being done feverishly by the release team, it might be easier for contributors to do this work and *not* be separate from the rest of the project. But IMHO if we raise that issue now, the current state of affairs becomes a blocker issue, and that just means more unnecessary pressure on the release team. Since this issue probably has legs -- meaning that *someone* is going to raise it again, as they do every release -- I think we're safe leaving it out for now, and we can put it on the table after the SCM and other infrastructure consolidation is ready. Then it just becomes a matter of turning the idea momentum into action. If contributors want it and are really going to do the work, they will be able to transition immediately into planning and execution, instead of "waiting on 'X' to be finished." -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 Axel.Thimm at ATrpms.net Mon Feb 19 15:00:25 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Feb 2007 16:00:25 +0100 Subject: Extending FC5 lifecycle? In-Reply-To: <1171896555.20354.18.camel@localhost.localdomain> References: <45D9A3F3.8000207@fedoraproject.org> <20070219135128.GB623@neu.nirvana> <45D9B222.9020306@fedoraproject.org> <20070219143004.GD623@neu.nirvana> <45D9B5F1.6010308@fedoraproject.org> <1171896555.20354.18.camel@localhost.localdomain> Message-ID: <20070219150025.GF623@neu.nirvana> On Mon, Feb 19, 2007 at 09:49:15AM -0500, Paul W. Frields wrote: > On Mon, 2007-02-19 at 20:06 +0530, Rahul Sundaram wrote: > [...snip...] > > Jesse Keating, do you want to mention Fedora Legacy in this? > > Just to bring out a quick discussion Rahul and I were having on IRC, I'm > not sure we want to include that in this particular announcement. > Although the subject matter is a good fit, right now we don't have the > infrastructure in place to support a resurgence of Legacy. (Let's leave > aside the issue of whether anyone actually wants to *do the work*.) I don't think anyone wants to resurrect FL by this announcement, on the contrary we want to show where effectively the efforts of a FL were "merged into". E.g. *instead* of a separate entity caring about security updates we have prolongued the release life span. This should give an example to future Fedora-Legacy like initiatives that it is better to work within the project than as a sibling. It should be a nice and final wrap-up of Fedora Legacy, not a reboot of it. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Mon Feb 19 15:04:05 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 19 Feb 2007 10:04:05 -0500 Subject: Extending FC5 lifecycle? In-Reply-To: <1171896555.20354.18.camel@localhost.localdomain> References: <45D9A3F3.8000207@fedoraproject.org> <20070219135128.GB623@neu.nirvana> <45D9B222.9020306@fedoraproject.org> <20070219143004.GD623@neu.nirvana> <45D9B5F1.6010308@fedoraproject.org> <1171896555.20354.18.camel@localhost.localdomain> Message-ID: <1171897445.22651.9.camel@cutter> On Mon, 2007-02-19 at 09:49 -0500, Paul W. Frields wrote: > On Mon, 2007-02-19 at 20:06 +0530, Rahul Sundaram wrote: > [...snip...] > > Jesse Keating, do you want > > to mention Fedora Legacy in this? > > Just to bring out a quick discussion Rahul and I were having on IRC, I'm > not sure we want to include that in this particular announcement. > Although the subject matter is a good fit, right now we don't have the > infrastructure in place to support a resurgence of Legacy. (Let's leave > aside the issue of whether anyone actually wants to *do the work*.) Umm Legacy? Legacy is closed, dead, ka-put. Legacy not working had little to do with the infrastructure. It had mostly to do with no one wanting to do the hard work of security back-porting. Keeping up with the alerts, fixing the pkgs and testing them is difficult, laborious and not-terribly-fun work. That's what made legacy not work. So we should not speak of legacy unless someone has a big pile of money or a big pile of committed, involved and talented folks who will never leave us. :) since we have neither of those... -sv From jkeating at redhat.com Mon Feb 19 15:17:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Feb 2007 10:17:29 -0500 Subject: Extending FC5 lifecycle? In-Reply-To: <45D9B5F1.6010308@fedoraproject.org> References: <45D9A3F3.8000207@fedoraproject.org> <20070219143004.GD623@neu.nirvana> <45D9B5F1.6010308@fedoraproject.org> Message-ID: <200702191017.29574.jkeating@redhat.com> On Monday 19 February 2007 09:36, Rahul Sundaram wrote: > Duh, yes. ?Paul W. Frields did it better now. Jesse Keating, do you want > to mention Fedora Legacy in this? I don't see why. Legacy is a dead project, as the URLS for it clearly state. -- 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 Mon Feb 19 15:33:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Feb 2007 10:33:32 -0500 Subject: Extending FC5 lifecycle? In-Reply-To: <45D9A3F3.8000207@fedoraproject.org> References: <45D9A3F3.8000207@fedoraproject.org> Message-ID: <200702191033.32571.jkeating@redhat.com> On Monday 19 February 2007 08:19, Rahul Sundaram wrote: > Can we decide if we wanted to extend the lifecycle of FC5 till F7 is > released or not? I know there was some discussions before on that but > since F7 is going to have 4 test releases and second test release is > expected shortly, we need to determine this now. What is missing from this thread is buy in from RH engineering management to task their employees with another N months of FC5 maintenance. We don't yet have a system in place that would allow the community to push updates for this release, and we might not until F7 is out the door. So before we just go gun ho with this decision, perhaps we should get some feedback/buy in on adding this work to engineers. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Mon Feb 19 18:08:11 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 19 Feb 2007 12:08:11 -0600 Subject: smolt privacy policy Message-ID: <45D9E78B.5020602@redhat.com> I've created a first draft of the smolt Privacy Policy. Please note: It is not a legal document, it's the Infrastructures policy of how we'll be protecting the information. http://hg.fedoraproject.org/hg/hosted/smolt?f=d7efe18be592;file=doc/PrivacyPolicy It is also my intention to add package lists in the very near future. I believe this policy covers that. Please let me know what you think not just in terms of content but also wording, formatting, etc. -Mike From notting at redhat.com Mon Feb 19 18:27:29 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Feb 2007 13:27:29 -0500 Subject: smolt privacy policy In-Reply-To: <45D9E78B.5020602@redhat.com> References: <45D9E78B.5020602@redhat.com> Message-ID: <20070219182729.GA32715@nostromo.devel.redhat.com> Mike McGrath (mmcgrath at redhat.com) said: > http://hg.fedoraproject.org/hg/hosted/smolt?f=d7efe18be592;file=doc/PrivacyPolicy > > It is also my intention to add package lists in the very near future. I > believe this policy covers that. Please let me know what you think not > just in terms of content but also wording, formatting, etc. Should be "parties' attention", at least. Might want to spell out OS, in fact, you probably want to explicitly list what's being sent. Bill From stickster at gmail.com Mon Feb 19 18:33:54 2007 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 19 Feb 2007 13:33:54 -0500 Subject: smolt privacy policy In-Reply-To: <20070219182729.GA32715@nostromo.devel.redhat.com> References: <45D9E78B.5020602@redhat.com> <20070219182729.GA32715@nostromo.devel.redhat.com> Message-ID: <1171910034.20354.43.camel@localhost.localdomain> On Mon, 2007-02-19 at 13:27 -0500, Bill Nottingham wrote: > Mike McGrath (mmcgrath at redhat.com) said: > > http://hg.fedoraproject.org/hg/hosted/smolt?f=d7efe18be592;file=doc/PrivacyPolicy > > > > It is also my intention to add package lists in the very near future. I > > believe this policy covers that. Please let me know what you think not > > just in terms of content but also wording, formatting, etc. > > Should be "parties' attention", at least. Might want to spell out OS, > in fact, you probably want to explicitly list what's being sent. At the beginning of the policy, you probably should say what Smolt *does* rather than what its intentions are, especially since it can't have any intentions of its own. Or... *CAN IT?* 8-O -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 jwboyer at jdub.homelinux.org Mon Feb 19 18:37:51 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 19 Feb 2007 12:37:51 -0600 Subject: smolt privacy policy In-Reply-To: <45D9E78B.5020602@redhat.com> References: <45D9E78B.5020602@redhat.com> Message-ID: <1171910271.24204.37.camel@zod.rchland.ibm.com> On Mon, 2007-02-19 at 12:08 -0600, Mike McGrath wrote: > I've created a first draft of the smolt Privacy Policy. Please note: It > is not a legal document, it's the Infrastructures policy of how we'll be > protecting the information. > > http://hg.fedoraproject.org/hg/hosted/smolt?f=d7efe18be592;file=doc/PrivacyPolicy > > It is also my intention to add package lists in the very near future. I > believe this policy covers that. Please let me know what you think not > just in terms of content but also wording, formatting, etc. Since it's short, I'll paste it here: > Smolt's intention is to send only hardware and basic OS information to the "intention" is to open. Should be a definitive statement that smolt _only_ sends hardware and OS information. > Fedora smolt server (smoon). The only tie from the database to a submitters > machine is the UUID. As long as the submitter does not give out this UUID > the submission should be considered anonymous. If at any point in time a user s/should be considered/is. Again, make it definitive. > wants to delete their profile from the database they need only run > > smoltDeleteProfile > > The information sent to the smolt database server should be considered public > in that anyone can come in and view the statistics and share machine remove the "come in" part. > profiles. In many ways smolt is designed to get hardware vendors and other > 3rd parties attention. As such, not only will this information be shared with > 3rd parties, we will be using smolt as a lever to gain better support for open "we will be using smolt as leverage..." > source drivers and better support in general. > > IP Logging. In Fedora's smolt install all web traffic goes through a proxy > server first. This is the only place IP addresses are being logged and they > are kept on that server for a period of 4 weeks at which time log rotation > removes these logs. The Fedora Project does not aggrigate ip addresses in aggregate IP > the smolt database. These logs are private and will not be available to the > general public. > Users unhappy with this policy should simply not use smolt. Users with > questions about this policy should contact the Fedora Infrastructure Team at > admin [at] fedoraproject.org Also remember that users can delete their > profiles at any time using "smoltDeleteProfile" josh From mmcgrath at redhat.com Mon Feb 19 19:09:58 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 19 Feb 2007 13:09:58 -0600 Subject: smolt privacy policy In-Reply-To: <20070219182729.GA32715@nostromo.devel.redhat.com> References: <45D9E78B.5020602@redhat.com> <20070219182729.GA32715@nostromo.devel.redhat.com> Message-ID: <45D9F606.5060401@redhat.com> Bill Nottingham wrote: > Should be "parties' attention", at least. Might want to spell out OS, > in fact, you probably want to explicitly list what's being sent. > Instead of putting that in the policy I decided to put it in the smolt program itself, it explicitly lists everything it sends before it sends (there's a prompt in version 0.9) -Mike From sundaram at fedoraproject.org Mon Feb 19 19:45:51 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 20 Feb 2007 01:15:51 +0530 Subject: smolt privacy policy In-Reply-To: <45D9E78B.5020602@redhat.com> References: <45D9E78B.5020602@redhat.com> Message-ID: <45D9FE6F.4080406@fedoraproject.org> Mike McGrath wrote: > I've created a first draft of the smolt Privacy Policy. Please note: It > is not a legal document, it's the Infrastructures policy of how we'll be > protecting the information. > > http://hg.fedoraproject.org/hg/hosted/smolt?f=d7efe18be592;file=doc/PrivacyPolicy > > > It is also my intention to add package lists in the very near future. I > believe this policy covers that. Please let me know what you think not > just in terms of content but also wording, formatting, etc. > Instead of having privacy policies per program, it would probably be better to vet the project wide policy drafted at http://fedoraproject.org/wiki/Legal/PrivacyPolicy through the legal team. It has been sitting there for a while now. Rahul From mspevack at redhat.com Mon Feb 19 20:07:10 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 19 Feb 2007 15:07:10 -0500 (EST) Subject: Fedora Board Meeting tomorrow Message-ID: 'tis the third tuesday of the month, and so we shall meet at 10:00 AM eastern time (15:00 GMT). Follow along in #fedora-meeting Just FYI -- Next week's meeting, I will not be at, as I will still be in Europe following FOSDEM. Topics that we will discuss tomorrow. - max briefs the board about fedora art, board makes its decision and acts - deciding on the schedule slips for f7, which seems to already be done - issues surrounding the kde spin, update from rex - the "increasing the lifecycle" thread on f-a-b - jesse keating as a guest star talking about buildsys - max gives a brief overview of what will happen at fosdem - other topics, as warranted -- 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 sankar at redhat.com Tue Feb 20 03:44:23 2007 From: sankar at redhat.com (Sankarshan Mukhopadhyay) Date: Tue, 20 Feb 2007 09:14:23 +0530 Subject: smolt privacy policy In-Reply-To: <45D9E78B.5020602@redhat.com> References: <45D9E78B.5020602@redhat.com> Message-ID: <45DA6E97.6040306@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike McGrath wrote: > I've created a first draft of the smolt Privacy Policy. Please note: It > is not a legal document, it's the Infrastructures policy of how we'll be > protecting the information. > > http://hg.fedoraproject.org/hg/hosted/smolt?f=d7efe18be592;file=doc/PrivacyPolicy > These logs are private and will not be available to the general public. - -> Kind of does not make clear whether they will not be made available now or never at all. Suggest that we put in disambiguity :Sankarshan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF2m6X+g4kmZ76nyERApvNAJ9ZQWZbChNZaFcoUOodQ87RZOGOaQCcDIvI eJ44jxDT4OBazUdr72ASz0M= =f2Uj -----END PGP SIGNATURE----- From blizzard at redhat.com Wed Feb 21 03:19:22 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 20 Feb 2007 22:19:22 -0500 Subject: smolt privacy policy In-Reply-To: <45D9E78B.5020602@redhat.com> References: <45D9E78B.5020602@redhat.com> Message-ID: <1172027962.16219.69.camel@localhost.localdomain> On Mon, 2007-02-19 at 12:08 -0600, Mike McGrath wrote: > I've created a first draft of the smolt Privacy Policy. Please note: It > is not a legal document, it's the Infrastructures policy of how we'll be > protecting the information. > > http://hg.fedoraproject.org/hg/hosted/smolt?f=d7efe18be592;file=doc/PrivacyPolicy > > It is also my intention to add package lists in the very near future. I > believe this policy covers that. Please let me know what you think not > just in terms of content but also wording, formatting, etc. > > -Mike Thanks, Mike! I believe there are some regulations we have to contend with that are imposed by the EU. We'll have to get someone from legal involved at some point. That aside, I think what you have is a good start. I would start by listing out what we're collecting, how we connect that to people (or not) and how we're going to use it. And start out with why we're doing it so that people understand our motivation. Or, another way to put it, what is the acceptable use policy for the information and how it affects others. Google's privacy policy is pretty good for its format. (I won't comment about the content.) http://www.google.com/privacypolicy.html The EFF has some decent resources: http://www.eff.org/Privacy/ But that aside, I think that we need to lay down some ground rules for what we want to have as outcomes. Here are my personal views on what we should try to explain in the policy: 1. That we collect information about the hardware you have in your machine as well as things that are connected to your machine. 2. That information is linked with a unique identifier, if the user chooses to provide one. This identifier is only there to determine if a driver breaks or gets better over time. (It's not just about leverage, it's also about quality metrics we can add later.) 3. That unique identifier is never connected to an IP address. 4. Information about hardware is only released to the public in aggregate. That is, we will never release information about a specific users, only about trends and groups of users. 5. That anyone who has access to the raw data that makes up the aggregate will be required to enforce this policy and will not release specific information to the public. --Chris From luis at tieguy.org Wed Feb 21 03:34:17 2007 From: luis at tieguy.org (Luis Villa) Date: Tue, 20 Feb 2007 22:34:17 -0500 Subject: smolt privacy policy In-Reply-To: <45D9FE6F.4080406@fedoraproject.org> References: <45D9E78B.5020602@redhat.com> <45D9FE6F.4080406@fedoraproject.org> Message-ID: <2cb10c440702201934y9e48849sc032e3ce15db78b6@mail.gmail.com> On 2/19/07, Rahul Sundaram wrote: > Mike McGrath wrote: > > I've created a first draft of the smolt Privacy Policy. Please note: It > > is not a legal document, it's the Infrastructures policy of how we'll be > > protecting the information. > > Instead of having privacy policies per program, it would probably be > better to vet the project wide policy drafted at > http://fedoraproject.org/wiki/Legal/PrivacyPolicy through the legal > team. It has been sitting there for a while now. I get the sense that you're talking about a privacy policy, Rahul, and maybe Mike is talking more about a privacy architecture or privacy strategy? Just from reading the two documents, it seems they have some overlapping text and goals but are mostly operating at two different levels. Mike, would it make sense to retitle your doc as a privacy strategy or privacy implementation doc, whose goal is to explain how smolt will implement the project privacy policy Rahul pointed at? Calling it a privacy policy seems a little confusing, esp. if there is already a project privacy policy. Making this distinction might also (1) reduce the need for lawyers, who can hopefully focus on validating the requirements in the policy doc, rather than validating the implementation details in smolt (2) help provide a practical test for the overall privacy policy- if there are goals you're setting in the smolt doc, or questions the smolt doc raises, which aren't in the overall policy, this might be a good way to shake those out and get them into the bigger/broader doc. Just a thought- Luis From gdk at redhat.com Wed Feb 21 03:39:45 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Tue, 20 Feb 2007 22:39:45 -0500 (EST) Subject: smolt privacy policy In-Reply-To: <2cb10c440702201934y9e48849sc032e3ce15db78b6@mail.gmail.com> References: <45D9E78B.5020602@redhat.com> <45D9FE6F.4080406@fedoraproject.org> <2cb10c440702201934y9e48849sc032e3ce15db78b6@mail.gmail.com> Message-ID: On Tue, 20 Feb 2007, Luis Villa wrote: > Just a thought- > Luis Wow. Dude -- you oughta be a lawyer. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From mmcgrath at redhat.com Wed Feb 21 03:46:01 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 20 Feb 2007 21:46:01 -0600 Subject: smolt privacy policy In-Reply-To: <2cb10c440702201934y9e48849sc032e3ce15db78b6@mail.gmail.com> References: <45D9E78B.5020602@redhat.com> <45D9FE6F.4080406@fedoraproject.org> <2cb10c440702201934y9e48849sc032e3ce15db78b6@mail.gmail.com> Message-ID: <45DBC079.60002@redhat.com> Luis Villa wrote: > On 2/19/07, Rahul Sundaram wrote: >> Mike McGrath wrote: >> > I've created a first draft of the smolt Privacy Policy. Please >> note: It >> > is not a legal document, it's the Infrastructures policy of how >> we'll be >> > protecting the information. >> >> Instead of having privacy policies per program, it would probably be >> better to vet the project wide policy drafted at >> http://fedoraproject.org/wiki/Legal/PrivacyPolicy through the legal >> team. It has been sitting there for a while now. > > I get the sense that you're talking about a privacy policy, Rahul, and > maybe Mike is talking more about a privacy architecture or privacy > strategy? Just from reading the two documents, it seems they have some > overlapping text and goals but are mostly operating at two different > levels. > > Mike, would it make sense to retitle your doc as a privacy strategy or > privacy implementation doc, whose goal is to explain how smolt will > implement the project privacy policy Rahul pointed at? I think that policy was something that was created and never finished. I'm not even sure what context to apply to it. Who maintains it? > Calling it a > privacy policy seems a little confusing, esp. if there is already a > project privacy policy. Making this distinction might also (1) reduce > the need for lawyers, who can hopefully focus on validating the > requirements in the policy doc, rather than validating the > implementation details in smolt (2) help provide a practical test for > the overall privacy policy- if there are goals you're setting in the > smolt doc, or questions the smolt doc raises, which aren't in the > overall policy, this might be a good way to shake those out and get > them into the bigger/broader doc. > What if I "mv PrivacyPolicy YourPrivacy" ? -Mike From luis at tieguy.org Wed Feb 21 03:46:25 2007 From: luis at tieguy.org (Luis Villa) Date: Tue, 20 Feb 2007 22:46:25 -0500 Subject: smolt privacy policy In-Reply-To: References: <45D9E78B.5020602@redhat.com> <45D9FE6F.4080406@fedoraproject.org> <2cb10c440702201934y9e48849sc032e3ce15db78b6@mail.gmail.com> Message-ID: <2cb10c440702201946u43ecdf23sb1e9de146c6178f8@mail.gmail.com> On 2/20/07, Greg Dekoenigsberg wrote: > On Tue, 20 Feb 2007, Luis Villa wrote: > > > Just a thought- > > Luis > > Wow. Dude -- you oughta be a lawyer. Nah, lawyers would include the disclaimer in the first draft, rather than remembering it five minutes later... :) I'm just a slob who is conning Columbia out of a degree... Luis From luis at tieguy.org Wed Feb 21 03:44:05 2007 From: luis at tieguy.org (Luis Villa) Date: Tue, 20 Feb 2007 22:44:05 -0500 Subject: smolt privacy policy In-Reply-To: <2cb10c440702201934y9e48849sc032e3ce15db78b6@mail.gmail.com> References: <45D9E78B.5020602@redhat.com> <45D9FE6F.4080406@fedoraproject.org> <2cb10c440702201934y9e48849sc032e3ce15db78b6@mail.gmail.com> Message-ID: <2cb10c440702201944w3a301973n4066d319464dfc05@mail.gmail.com> On 2/20/07, Luis Villa wrote: > Making this distinction might also (1) reduce > the need for lawyers, who can hopefully focus on validating the > requirements in the policy doc, rather than validating the > implementation details in smolt NB: IANAL, this is not legal advice, I have no specific knowledge of EU privacy law, etc. It is just a rough guess based on (potentially misplaced) assumptions about the general sanity of EU privacy law. :) Luis From gdk at redhat.com Wed Feb 21 03:48:48 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Tue, 20 Feb 2007 22:48:48 -0500 (EST) Subject: smolt privacy policy In-Reply-To: <2cb10c440702201946u43ecdf23sb1e9de146c6178f8@mail.gmail.com> References: <45D9E78B.5020602@redhat.com> <45D9FE6F.4080406@fedoraproject.org> <2cb10c440702201934y9e48849sc032e3ce15db78b6@mail.gmail.com> <2cb10c440702201946u43ecdf23sb1e9de146c6178f8@mail.gmail.com> Message-ID: On Tue, 20 Feb 2007, Luis Villa wrote: > I'm just a slob who is conning Columbia out of a degree... The first half of that sentence doesn't match the second half of that sentence. :) --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From luis at tieguy.org Wed Feb 21 03:53:06 2007 From: luis at tieguy.org (Luis Villa) Date: Tue, 20 Feb 2007 22:53:06 -0500 Subject: smolt privacy policy In-Reply-To: <45DBC079.60002@redhat.com> References: <45D9E78B.5020602@redhat.com> <45D9FE6F.4080406@fedoraproject.org> <2cb10c440702201934y9e48849sc032e3ce15db78b6@mail.gmail.com> <45DBC079.60002@redhat.com> Message-ID: <2cb10c440702201953w55d01d65s79686baa62e95cf9@mail.gmail.com> On 2/20/07, Mike McGrath wrote: > Luis Villa wrote: > > On 2/19/07, Rahul Sundaram wrote: > >> Mike McGrath wrote: > >> > I've created a first draft of the smolt Privacy Policy. Please > >> note: It > >> > is not a legal document, it's the Infrastructures policy of how > >> we'll be > >> > protecting the information. > >> > >> Instead of having privacy policies per program, it would probably be > >> better to vet the project wide policy drafted at > >> http://fedoraproject.org/wiki/Legal/PrivacyPolicy through the legal > >> team. It has been sitting there for a while now. > > > > I get the sense that you're talking about a privacy policy, Rahul, and > > maybe Mike is talking more about a privacy architecture or privacy > > strategy? Just from reading the two documents, it seems they have some > > overlapping text and goals but are mostly operating at two different > > levels. > > > > Mike, would it make sense to retitle your doc as a privacy strategy or > > privacy implementation doc, whose goal is to explain how smolt will > > implement the project privacy policy Rahul pointed at? > I think that policy was something that was created and never finished. > I'm not even sure what context to apply to it. I had assumed that (like most privacy policies) the context is 'we're trying to explain what goals we're trying to meet with your data'. But I'm not sure of the historical/project context around it. The wiki history suggests it was written basically completely with one person, so maybe it doesn't have the buy-in I assumed it did. > Who maintains it? Wiki says Patrick Barnes; I'm still relatively-speaking the newbie around here and have no idea who that is :) > > Calling it a > > privacy policy seems a little confusing, esp. if there is already a > > project privacy policy. Making this distinction might also (1) reduce > > the need for lawyers, who can hopefully focus on validating the > > requirements in the policy doc, rather than validating the > > implementation details in smolt (2) help provide a practical test for > > the overall privacy policy- if there are goals you're setting in the > > smolt doc, or questions the smolt doc raises, which aren't in the > > overall policy, this might be a good way to shake those out and get > > them into the bigger/broader doc. > > > What if I "mv PrivacyPolicy YourPrivacy" ? Dunno. Who is 'you'? End users? Implementers? Someone in between? Understanding who that you is might help you clean up/clarify the doc. Luis (who is potentially way overthinking this :) From mmcgrath at redhat.com Wed Feb 21 03:55:31 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 20 Feb 2007 21:55:31 -0600 Subject: smolt privacy policy In-Reply-To: <1172027962.16219.69.camel@localhost.localdomain> References: <45D9E78B.5020602@redhat.com> <1172027962.16219.69.camel@localhost.localdomain> Message-ID: <45DBC2B3.9030603@redhat.com> Christopher Blizzard wrote: > On Mon, 2007-02-19 at 12:08 -0600, Mike McGrath wrote: > > That aside, I think what you have is a good start. I would start by > listing out what we're collecting, how we connect that to people (or > not) and how we're going to use it. And start out with why we're doing > it so that people understand our motivation. Or, another way to put it, > what is the acceptable use policy for the information and how it affects > others. > Yeah, it'd be good to explicitly state what we're going to do with the data and then actually follow it as a benchmark for how useful smolt is to us. If we say we're going to do a bunch of things and this time next year we haven't, that would be bad :-) > Google's privacy policy is pretty good for its format. (I won't comment > about the content.) > > http://www.google.com/privacypolicy.html > > The EFF has some decent resources: > > http://www.eff.org/Privacy/ > I'll grab some ideas. > But that aside, I think that we need to lay down some ground rules for > what we want to have as outcomes. Here are my personal views on what we > should try to explain in the policy: > > 1. That we collect information about the hardware you have in your > machine as well as things that are connected to your machine. > + packages in the near future. > 2. That information is linked with a unique identifier, if the user > chooses to provide one. This identifier is only there to determine if a > driver breaks or gets better over time. (It's not just about leverage, > it's also about quality metrics we can add later.) > > 3. That unique identifier is never connected to an IP address. > > Thats not quite true... It is linked in the web logs and that is by design (abuse prevention / correction). Those logs are kept for a finite amount of time and is listed in the policy. > 4. Information about hardware is only released to the public in > aggregate. That is, we will never release information about a specific > users, only about trends and groups of users. > > 5. That anyone who has access to the raw data that makes up the > aggregate will be required to enforce this policy and will not release > specific information to the public. > I've debated this off and on. Honestly I think it would be great to make the databases available to the public, I can't imagine what harm it would do and people could run their own queries against the database as they want to. For some reason though, in the back of my mind this seems like a bad idea. I can't give specific reasons why. -Mike From nman64 at n-man.com Wed Feb 21 06:13:08 2007 From: nman64 at n-man.com (Patrick W. Barnes) Date: Wed, 21 Feb 2007 00:13:08 -0600 Subject: smolt privacy policy In-Reply-To: <2cb10c440702201953w55d01d65s79686baa62e95cf9@mail.gmail.com> References: <45D9E78B.5020602@redhat.com> <45DBC079.60002@redhat.com> <2cb10c440702201953w55d01d65s79686baa62e95cf9@mail.gmail.com> Message-ID: <200702210013.12826.nman64@n-man.com> On Tuesday 20 February 2007, Luis Villa wrote: > On 2/20/07, Mike McGrath wrote: > > > > I think that policy was something that was created and never finished. > > I'm not even sure what context to apply to it. > > I had assumed that (like most privacy policies) the context is 'we're > trying to explain what goals we're trying to meet with your data'. But > I'm not sure of the historical/project context around it. The wiki > history suggests it was written basically completely with one person, > so maybe it doesn't have the buy-in I assumed it did. > > > Who maintains it? > > Wiki says Patrick Barnes; I'm still relatively-speaking the newbie > around here and have no idea who that is :) > Yes, I wrote the thing. It got a little bit of review within the project, but was never passed through Legal or given a final go-ahead. I still feel like it would be useful to get that review and implement the policy. With that established policy, the requirements left for smolt are greatly reduced. It would then need only to list what data is being submitted and under what jurisdiction the data will be managed, pointing to the overall policy for the rest. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://n-man.com/ LinkedIn: http://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 jwboyer at jdub.homelinux.org Wed Feb 21 13:04:34 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 21 Feb 2007 07:04:34 -0600 Subject: smolt privacy policy In-Reply-To: <45DBC2B3.9030603@redhat.com> References: <45D9E78B.5020602@redhat.com> <1172027962.16219.69.camel@localhost.localdomain> <45DBC2B3.9030603@redhat.com> Message-ID: <1172063074.24204.141.camel@zod.rchland.ibm.com> On Tue, 2007-02-20 at 21:55 -0600, Mike McGrath wrote: > > + packages in the near future. I still think that if you include package output in smolt you will limit the number of users that will actually turn in reports. I'm -1 on including packages. josh From sundaram at fedoraproject.org Wed Feb 21 13:11:40 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Feb 2007 18:41:40 +0530 Subject: smolt privacy policy In-Reply-To: <1172063074.24204.141.camel@zod.rchland.ibm.com> References: <45D9E78B.5020602@redhat.com> <1172027962.16219.69.camel@localhost.localdomain> <45DBC2B3.9030603@redhat.com> <1172063074.24204.141.camel@zod.rchland.ibm.com> Message-ID: <45DC450C.5090107@fedoraproject.org> Josh Boyer wrote: > On Tue, 2007-02-20 at 21:55 -0600, Mike McGrath wrote: >> >> + packages in the near future. > > I still think that if you include package output in smolt you will limit > the number of users that will actually turn in reports. I'm -1 on > including packages. More metrics is very very useful to collect. Smolt can be be a general profiler have independent client packages and modules which can provide information to the server. Users should be able to provide either hardware profile or package profiles or both optionally. Add in more if you want to. Rahul From dennis at ausil.us Wed Feb 21 13:21:14 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 21 Feb 2007 07:21:14 -0600 Subject: smolt privacy policy In-Reply-To: <1172063074.24204.141.camel@zod.rchland.ibm.com> References: <45D9E78B.5020602@redhat.com> <45DBC2B3.9030603@redhat.com> <1172063074.24204.141.camel@zod.rchland.ibm.com> Message-ID: <200702210721.21316.dennis@ausil.us> Once upon a time Wednesday 21 February 2007, Josh Boyer wrote: > On Tue, 2007-02-20 at 21:55 -0600, Mike McGrath wrote: > > + packages in the near future. > > I still think that if you include package output in smolt you will limit > the number of users that will actually turn in reports. I'm -1 on > including packages. they could be an optional switch. check box someething Dennis -------------- 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 Feb 21 13:33:26 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 21 Feb 2007 07:33:26 -0600 Subject: smolt privacy policy In-Reply-To: <45DC450C.5090107@fedoraproject.org> References: <45D9E78B.5020602@redhat.com> <1172027962.16219.69.camel@localhost.localdomain> <45DBC2B3.9030603@redhat.com> <1172063074.24204.141.camel@zod.rchland.ibm.com> <45DC450C.5090107@fedoraproject.org> Message-ID: <1172064806.24204.148.camel@zod.rchland.ibm.com> On Wed, 2007-02-21 at 18:41 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > On Tue, 2007-02-20 at 21:55 -0600, Mike McGrath wrote: > >> > >> + packages in the near future. > > > > I still think that if you include package output in smolt you will limit > > the number of users that will actually turn in reports. I'm -1 on > > including packages. > > More metrics is very very useful to collect. Smolt can be be a general > profiler have independent client packages and modules which can provide > information to the server. Users should be able to provide either > hardware profile or package profiles or both optionally. Add in more if > you want to. Sure, if it's optional I'm all for it. josh From mmcgrath at redhat.com Wed Feb 21 14:29:51 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 21 Feb 2007 08:29:51 -0600 Subject: Dell + Linux Message-ID: <45DC575F.8080801@redhat.com> What are we doing to make sure that this is a good experience for Dell and their customers? http://wirelessisfun.com/2007/02/20/dell-powered-by-linux/ -Mike From luis at tieguy.org Wed Feb 21 14:47:38 2007 From: luis at tieguy.org (Luis Villa) Date: Wed, 21 Feb 2007 09:47:38 -0500 Subject: Dell + Linux In-Reply-To: <45DC575F.8080801@redhat.com> References: <45DC575F.8080801@redhat.com> Message-ID: <2cb10c440702210647q3b3a6955r4c39b925d3fbecde@mail.gmail.com> Best way to make companies happy is to drive business to them. Perhaps fedora.org should be offering a 'pre-installed' link on par with the 'download' link? See for reference what http://debian.org/ does ('pre-installed' link in left-hand column) or http://www.us.debian.org/distrib/ (scroll down). I'd of course suggest making it prettier and more useful than the debian page, but you get the general drift- Fedora should drive traffic to vendors who distribute Fedora. I think this is a good thing for users too; they'd presumably get well-supported hardware, and feel good that they were voting with their money. [This would of course not be dell-specific; emperorlinux comes to mind as a fedora vendor, and I'm sure there are others as well. Sorry, Matt :)] Luis On 2/21/07, Mike McGrath wrote: > What are we doing to make sure that this is a good experience for Dell > and their customers? > > http://wirelessisfun.com/2007/02/20/dell-powered-by-linux/ > > -Mike > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > From jkeating at redhat.com Wed Feb 21 15:09:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 10:09:57 -0500 Subject: Dell + Linux In-Reply-To: <2cb10c440702210647q3b3a6955r4c39b925d3fbecde@mail.gmail.com> References: <45DC575F.8080801@redhat.com> <2cb10c440702210647q3b3a6955r4c39b925d3fbecde@mail.gmail.com> Message-ID: <200702211009.57767.jkeating@redhat.com> On Wednesday 21 February 2007 09:47, Luis Villa wrote: > Best way to make companies happy is to drive business to them. Perhaps > fedora.org should be offering a 'pre-installed' link on par with the > 'download' link? See for reference what http://debian.org/ does > ('pre-installed' link in left-hand column) or > http://www.us.debian.org/distrib/ (scroll down). I'd of course suggest > making it prettier and more useful than the debian page, but you get > the general drift- Fedora should drive traffic to vendors who > distribute Fedora. Unless we create the second logo set, I don't think we'll get very far with pre-installation. Most vendors will want to sweeten the user experience, and possibly add branding. Any of that will make it no longer Fedora, and the vendor would be unable to make such claims under the trademark policy. They'd have to remove all the Fedora/RH trademarked logos and such too. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Wed Feb 21 15:09:18 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 21 Feb 2007 09:09:18 -0600 Subject: Dell + Linux In-Reply-To: <200702211009.57767.jkeating@redhat.com> References: <45DC575F.8080801@redhat.com> <2cb10c440702210647q3b3a6955r4c39b925d3fbecde@mail.gmail.com> <200702211009.57767.jkeating@redhat.com> Message-ID: <45DC609E.8030408@redhat.com> Jesse Keating wrote: > Unless we create the second logo set, I don't think we'll get very far with > pre-installation. Most vendors will want to sweeten the user experience, and > possibly add branding. Any of that will make it no longer Fedora, and the > vendor would be unable to make such claims under the trademark policy. > They'd have to remove all the Fedora/RH trademarked logos and such too. > What if we helpped Dell create an OSS gnome and KDE theme and got it into Extras? -Mike From luis at tieguy.org Wed Feb 21 15:10:22 2007 From: luis at tieguy.org (Luis Villa) Date: Wed, 21 Feb 2007 10:10:22 -0500 Subject: Dell + Linux In-Reply-To: <200702211009.57767.jkeating@redhat.com> References: <45DC575F.8080801@redhat.com> <2cb10c440702210647q3b3a6955r4c39b925d3fbecde@mail.gmail.com> <200702211009.57767.jkeating@redhat.com> Message-ID: <2cb10c440702210710t7a601f2bt136f4f7faec2d406@mail.gmail.com> On 2/21/07, Jesse Keating wrote: > On Wednesday 21 February 2007 09:47, Luis Villa wrote: > > Best way to make companies happy is to drive business to them. Perhaps > > fedora.org should be offering a 'pre-installed' link on par with the > > 'download' link? See for reference what http://debian.org/ does > > ('pre-installed' link in left-hand column) or > > http://www.us.debian.org/distrib/ (scroll down). I'd of course suggest > > making it prettier and more useful than the debian page, but you get > > the general drift- Fedora should drive traffic to vendors who > > distribute Fedora. > > Unless we create the second logo set, I don't think we'll get very far with > pre-installation. Most vendors will want to sweeten the user experience, and > possibly add branding. Any of that will make it no longer Fedora, and the > vendor would be unable to make such claims under the trademark policy. > They'd have to remove all the Fedora/RH trademarked logos and such too. To me that indicates a problem with the trademark policy, but that is a windmill I will tilt at another day ;) Luis From jkeating at redhat.com Wed Feb 21 15:17:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 10:17:35 -0500 Subject: Dell + Linux In-Reply-To: <45DC609E.8030408@redhat.com> References: <45DC575F.8080801@redhat.com> <200702211009.57767.jkeating@redhat.com> <45DC609E.8030408@redhat.com> Message-ID: <200702211017.36125.jkeating@redhat.com> On Wednesday 21 February 2007 10:09, Mike McGrath wrote: > What if we helpped Dell create an OSS gnome and KDE theme and got it > into Extras? Is Dell willing to let their graphics be released under an OSS license, for anybody to apply them to any non-dell machine? I'm thinking... no. Seriously, we really really really need a second set of trademarks/logos that would be usable by folks like Dell to be able to do 'Fedora' preinstalls with some of their customization. They could call it Dell Linux Based on Fedora or whatever. Just some way for them to legally use the term Fedora and still accomplish the minimal customization that almost any vendor would want (and sometimes need). -- 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 Feb 21 15:17:09 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Feb 2007 20:47:09 +0530 Subject: Dell + Linux In-Reply-To: <45DC609E.8030408@redhat.com> References: <45DC575F.8080801@redhat.com> <2cb10c440702210647q3b3a6955r4c39b925d3fbecde@mail.gmail.com> <200702211009.57767.jkeating@redhat.com> <45DC609E.8030408@redhat.com> Message-ID: <45DC6275.6080008@fedoraproject.org> Mike McGrath wrote: > Jesse Keating wrote: >> Unless we create the second logo set, I don't think we'll get very far >> with pre-installation. Most vendors will want to sweeten the user >> experience, and possibly add branding. Any of that will make it no >> longer Fedora, and the vendor would be unable to make such claims >> under the trademark policy. They'd have to remove all the Fedora/RH >> trademarked logos and such too. >> > What if we helpped Dell create an OSS gnome and KDE theme and got it > into Extras? Well Dell might want to control its branding more than we allow for within the package licensing guidelines for Fedora. It is a reasonable for them to want to do that. Rahul From mmcgrath at redhat.com Wed Feb 21 15:18:26 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 21 Feb 2007 09:18:26 -0600 Subject: Dell + Linux In-Reply-To: <200702211017.36125.jkeating@redhat.com> References: <45DC575F.8080801@redhat.com> <200702211009.57767.jkeating@redhat.com> <45DC609E.8030408@redhat.com> <200702211017.36125.jkeating@redhat.com> Message-ID: <45DC62C2.4060803@redhat.com> Jesse Keating wrote: > On Wednesday 21 February 2007 10:09, Mike McGrath wrote: > >> What if we helpped Dell create an OSS gnome and KDE theme and got it >> into Extras? >> > > Is Dell willing to let their graphics be released under an OSS license, for > anybody to apply them to any non-dell machine? I'm thinking... no. > > Seriously, we really really really need a second set of trademarks/logos that > would be usable by folks like Dell to be able to do 'Fedora' preinstalls with > some of their customization. They could call it Dell Linux Based on Fedora > or whatever. Just some way for them to legally use the term Fedora and still > accomplish the minimal customization that almost any vendor would want (and > sometimes need). > What would that take? Seriously I'll do it, we can't flounder when an opportunity like this comes up, pre-install is HUGE. -Mike From sundaram at fedoraproject.org Wed Feb 21 15:26:35 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Feb 2007 20:56:35 +0530 Subject: Dell + Linux In-Reply-To: <45DC62C2.4060803@redhat.com> References: <45DC575F.8080801@redhat.com> <200702211009.57767.jkeating@redhat.com> <45DC609E.8030408@redhat.com> <200702211017.36125.jkeating@redhat.com> <45DC62C2.4060803@redhat.com> Message-ID: <45DC64AB.90001@fedoraproject.org> Mike McGrath wrote: > Jesse Keating wrote: >> On Wednesday 21 February 2007 10:09, Mike McGrath wrote: >> >>> What if we helpped Dell create an OSS gnome and KDE theme and got it >>> into Extras? >>> >> >> Is Dell willing to let their graphics be released under an OSS >> license, for anybody to apply them to any non-dell machine? I'm >> thinking... no. >> >> Seriously, we really really really need a second set of >> trademarks/logos that would be usable by folks like Dell to be able to >> do 'Fedora' preinstalls with some of their customization. They could >> call it Dell Linux Based on Fedora or whatever. Just some way for >> them to legally use the term Fedora and still accomplish the minimal >> customization that almost any vendor would want (and sometimes need). >> > What would that take? Seriously I'll do it, we can't flounder when an > opportunity like this comes up, pre-install is HUGE. I think the only major bottle neck to that is talking to lawyers. Last time the alternative logo idea was suggested it didnt go well. It might be better for us to draft the guidelines and other related items and send it to the legal team to just acknowledge it if it doesnt have major issues. Rahul From rdieter at math.unl.edu Wed Feb 21 15:27:34 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 21 Feb 2007 09:27:34 -0600 Subject: Dell + Linux In-Reply-To: <200702211017.36125.jkeating@redhat.com> References: <45DC575F.8080801@redhat.com> <200702211009.57767.jkeating@redhat.com> <45DC609E.8030408@redhat.com> <200702211017.36125.jkeating@redhat.com> Message-ID: <45DC64E6.6080002@math.unl.edu> Jesse Keating wrote: > Seriously, we really really really need a second set of trademarks/logos that > would be usable by folks like Dell to be able to do 'Fedora' preinstalls with > some of their customization. The Board (OK, Greg mostly) has been virtually *begging* rh-legal to be able to do exactly that, and all such requests have been rejected so far. -- Rex From notting at redhat.com Wed Feb 21 16:16:06 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 21 Feb 2007 11:16:06 -0500 Subject: Dell + Linux In-Reply-To: <45DC575F.8080801@redhat.com> References: <45DC575F.8080801@redhat.com> Message-ID: <20070221161606.GA16741@nostromo.devel.redhat.com> Mike McGrath (mmcgrath at redhat.com) said: > What are we doing to make sure that this is a good experience for Dell > and their customers? > > http://wirelessisfun.com/2007/02/20/dell-powered-by-linux/ Maybe I'm misreading this, but: "Apparently after the new customer feedback website opened by Dell, 2 out of 3 customers are asking for a pre-installed Linux distribution. They are talking about a tri-choice between Ubuntu, Fedora and OpenSUSE..." So, if I'm getting the pronoun-antecedent relationship right, it says: - customers are requesting Linux - the *customers* are talking about the tri-choice i.e., there's nothing from Dell stating that they're actually doing this. Would love to be proved wrong. Bill From mmcgrath at redhat.com Wed Feb 21 16:54:40 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 21 Feb 2007 10:54:40 -0600 Subject: Dell + Linux In-Reply-To: <20070221161606.GA16741@nostromo.devel.redhat.com> References: <45DC575F.8080801@redhat.com> <20070221161606.GA16741@nostromo.devel.redhat.com> Message-ID: <45DC7950.5080801@redhat.com> Bill Nottingham wrote: > Mike McGrath (mmcgrath at redhat.com) said: > >> What are we doing to make sure that this is a good experience for Dell >> and their customers? >> >> http://wirelessisfun.com/2007/02/20/dell-powered-by-linux/ >> > > Maybe I'm misreading this, but: > > "Apparently after the new customer feedback website opened by Dell, 2 out > of 3 customers are asking for a pre-installed Linux distribution. They are > talking about a tri-choice between Ubuntu, Fedora and OpenSUSE..." > > So, if I'm getting the pronoun-antecedent relationship right, it says: > > - customers are requesting Linux > - the *customers* are talking about the tri-choice > > i.e., there's nothing from Dell stating that they're actually doing this. > Would love to be proved wrong. > I've been waiting for Matt to see exactly what the deal is :-/ -Mike From Matt_Domsch at dell.com Wed Feb 21 17:15:00 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 21 Feb 2007 11:15:00 -0600 Subject: Dell + Linux In-Reply-To: <200702211009.57767.jkeating@redhat.com> References: <45DC575F.8080801@redhat.com> <2cb10c440702210647q3b3a6955r4c39b925d3fbecde@mail.gmail.com> <200702211009.57767.jkeating@redhat.com> Message-ID: <20070221171459.GA22324@humbolt.us.dell.com> On Wed, Feb 21, 2007 at 10:09:57AM -0500, Jesse Keating wrote: > On Wednesday 21 February 2007 09:47, Luis Villa wrote: > > Best way to make companies happy is to drive business to them. Perhaps > > fedora.org should be offering a 'pre-installed' link on par with the > > 'download' link? See for reference what http://debian.org/ does > > ('pre-installed' link in left-hand column) or > > http://www.us.debian.org/distrib/ (scroll down). I'd of course suggest > > making it prettier and more useful than the debian page, but you get > > the general drift- Fedora should drive traffic to vendors who > > distribute Fedora. > > Unless we create the second logo set, I don't think we'll get very > far with pre-installation. Most vendors will want to sweeten the > user experience, and possibly add branding. Any of that will make > it no longer Fedora, and the vendor would be unable to make such > claims under the trademark policy. They'd have to remove all the > Fedora/RH trademarked logos and such too. we don't rebrand RHEL or SLES today. Don't sweat this aspect, that's the least of the concerns. :-) -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Wed Feb 21 17:16:20 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 21 Feb 2007 11:16:20 -0600 Subject: Dell + Linux In-Reply-To: <45DC7950.5080801@redhat.com> References: <45DC575F.8080801@redhat.com> <20070221161606.GA16741@nostromo.devel.redhat.com> <45DC7950.5080801@redhat.com> Message-ID: <20070221171620.GB22324@humbolt.us.dell.com> On Wed, Feb 21, 2007 at 10:54:40AM -0600, Mike McGrath wrote: > Bill Nottingham wrote: > >Mike McGrath (mmcgrath at redhat.com) said: > > > >>What are we doing to make sure that this is a good experience for Dell > >>and their customers? > >> > >>http://wirelessisfun.com/2007/02/20/dell-powered-by-linux/ > >> > > > >Maybe I'm misreading this, but: > > > >"Apparently after the new customer feedback website opened by Dell, 2 out > >of 3 customers are asking for a pre-installed Linux distribution. They are > >talking about a tri-choice between Ubuntu, Fedora and OpenSUSE..." > > > >So, if I'm getting the pronoun-antecedent relationship right, it says: > > > >- customers are requesting Linux > >- the *customers* are talking about the tri-choice > > > >i.e., there's nothing from Dell stating that they're actually doing this. > >Would love to be proved wrong. Bill reads this correctly. > I've been waiting for Matt to see exactly what the deal is :-/ More after lunch. :-) The dellideastorm site is a way for Dell to collect ideas from end users, and let others vote on them. Then the ideas are collected and run through the org, to see what can be done. I just hope those 65k votes are real, and not bots. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From jkeating at redhat.com Wed Feb 21 17:53:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 12:53:24 -0500 Subject: Dell + Linux In-Reply-To: <20070221171459.GA22324@humbolt.us.dell.com> References: <45DC575F.8080801@redhat.com> <200702211009.57767.jkeating@redhat.com> <20070221171459.GA22324@humbolt.us.dell.com> Message-ID: <200702211253.24527.jkeating@redhat.com> On Wednesday 21 February 2007 12:15, Matt Domsch wrote: > we don't rebrand RHEL or SLES today. ?Don't sweat this aspect, that's > the least of the concerns. :-) You may not, but that doesn't mean $VendorBar won't want too. But you're right, the more important thing is adding software that isn't in Fedora, like a tool to contact your support team and send information regarding your system, or a new yum repo file that points to packages you provide, or, or... -- 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 Feb 21 18:21:53 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Feb 2007 23:51:53 +0530 Subject: CLA requirements Message-ID: <45DC8DC1.1010504@fedoraproject.org> Hi I had the impression that bug triaging doesnt require CLA and approved a bunch of folks who have signed for fedorabugs group in the account system but then the question was raised on whether a CLA is required for that. Do we really need CLA for groups like bug triaging and ambassadors majority of whom dont submit any content to the project? Do we have a concrete list of access points that require a CLA? Is making CLA a click through item struck on infrastructure or legal queue now? Rahul From gdk at redhat.com Wed Feb 21 19:14:08 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 21 Feb 2007 14:14:08 -0500 (EST) Subject: Dell + Linux In-Reply-To: <45DC64E6.6080002@math.unl.edu> References: <45DC575F.8080801@redhat.com> <200702211009.57767.jkeating@redhat.com> <45DC609E.8030408@redhat.com> <200702211017.36125.jkeating@redhat.com> <45DC64E6.6080002@math.unl.edu> Message-ID: On Wed, 21 Feb 2007, Rex Dieter wrote: > Jesse Keating wrote: > >> Seriously, we really really really need a second set of trademarks/logos >> that would be usable by folks like Dell to be able to do 'Fedora' >> preinstalls with some of their customization. > > The Board (OK, Greg mostly) has been virtually *begging* rh-legal to be able > to do exactly that, and all such requests have been rejected so far. The pain we've incurred trying to negotiate the dos and don'ts of the Fedora Art Project really, really, really cry out, in my opinion, for a set of community marks. But no progress on this front. I really did stamp my little foot, too. Luis, maybe when you spend a summer in the fold, you can make a case more persuasively than I've been able to. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From blizzard at redhat.com Wed Feb 21 19:45:37 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 21 Feb 2007 14:45:37 -0500 Subject: Dell + Linux In-Reply-To: <200702211009.57767.jkeating@redhat.com> References: <45DC575F.8080801@redhat.com> <2cb10c440702210647q3b3a6955r4c39b925d3fbecde@mail.gmail.com> <200702211009.57767.jkeating@redhat.com> Message-ID: <1172087137.21423.71.camel@localhost.localdomain> Just an observation: are we trying to solve a problem that doesn't exist? We don't really know what dell wants to do and we don't know if what they want to do requires changing policies. I would suggest that we get to the meat of the matter first - how to properly support some subset of Dell laptops and how to get dell involved directly in this discussion (Hi, Matt!) Smolt is already telling us that we're seeing a lot more Dell laptops than I thought we would, even though the sample size is small. It's time to start the conversation. --Chris From chitlesh at fedoraproject.org Wed Feb 21 19:52:27 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 21 Feb 2007 20:52:27 +0100 Subject: CLA requirements In-Reply-To: <45DC8DC1.1010504@fedoraproject.org> References: <45DC8DC1.1010504@fedoraproject.org> Message-ID: <13dbfe4f0702211152s4bf615ccta01e2695bb260962@mail.gmail.com> On 2/21/07, Rahul Sundaram wrote: > that. Do we really need CLA for groups like bug triaging and ambassadors > majority of whom dont submit any content to the project? Hello, Ambassadors should have cla_done. I thought we have already talked about this on the Fedora Ambassadors mailing list. Since content is the only that matter for the CLA, we must not forget that Fedora Ambassadors provide fedora with some slides, videos, pictures, marketing brochure,..... It would be wise to keep the current on-going situation as it is. If not, no one can track who signed CLA and posted what. Having a standard protocol will ease the overall load of man power. Chitlesh -- http://clunixchit.blogspot.com From tchung at fedoraproject.org Wed Feb 21 20:15:43 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Wed, 21 Feb 2007 12:15:43 -0800 Subject: CLA requirements In-Reply-To: <13dbfe4f0702211152s4bf615ccta01e2695bb260962@mail.gmail.com> References: <45DC8DC1.1010504@fedoraproject.org> <13dbfe4f0702211152s4bf615ccta01e2695bb260962@mail.gmail.com> Message-ID: <369bce3b0702211215i1f9615fegbbc37661edbb8172@mail.gmail.com> On 2/21/07, Chitlesh GOORAH wrote: > On 2/21/07, Rahul Sundaram wrote: > > that. Do we really need CLA for groups like bug triaging and ambassadors > > majority of whom dont submit any content to the project? > > Hello, > Ambassadors should have cla_done. I thought we have already talked > about this on the Fedora Ambassadors mailing list. > Since content is the only that matter for the CLA, we must not forget > that Fedora Ambassadors provide fedora with some slides, videos, > pictures, marketing brochure,..... It would be wise to keep the > current on-going situation as it is. If not, no one can track who > signed CLA and posted what. Having a standard protocol will ease the > overall load of man power. > > Chitlesh +1 for Chitlesh -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From sundaram at fedoraproject.org Wed Feb 21 20:20:04 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 22 Feb 2007 01:50:04 +0530 Subject: CLA requirements In-Reply-To: <13dbfe4f0702211152s4bf615ccta01e2695bb260962@mail.gmail.com> References: <45DC8DC1.1010504@fedoraproject.org> <13dbfe4f0702211152s4bf615ccta01e2695bb260962@mail.gmail.com> Message-ID: <45DCA974.6080109@fedoraproject.org> Chitlesh GOORAH wrote: > On 2/21/07, Rahul Sundaram wrote: >> that. Do we really need CLA for groups like bug triaging and ambassadors >> majority of whom dont submit any content to the project? > > Hello, > Ambassadors should have cla_done. I thought we have already talked > about this on the Fedora Ambassadors mailing list. Ambassadors talking among themselves is irrelevant for determining this. This is a legal and process issue. > Since content is the only that matter for the CLA, we must not forget > that Fedora Ambassadors provide fedora with some slides, videos, > pictures, marketing brochure,..... It would be wise to keep the > current on-going situation as it is. If not, no one can track who > signed CLA and posted what. Having a standard protocol will ease the > overall load of man power. On the other hand it raises the barrier. We have had repeated complaints from folks finding the process too difficult. Remember many of those people are just those who want to attend a event or two and talk about Fedora and things. Not developers or packagers who need to know all the gpg keysigning tricks Rahul From chitlesh at fedoraproject.org Wed Feb 21 20:39:45 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 21 Feb 2007 21:39:45 +0100 Subject: CLA requirements In-Reply-To: <45DCA974.6080109@fedoraproject.org> References: <45DC8DC1.1010504@fedoraproject.org> <13dbfe4f0702211152s4bf615ccta01e2695bb260962@mail.gmail.com> <45DCA974.6080109@fedoraproject.org> Message-ID: <13dbfe4f0702211239k59d3e8b2t2b0c57b03afc3065@mail.gmail.com> On 2/21/07, Rahul Sundaram wrote: > Ambassadors talking among themselves is irrelevant for determining this. > This is a legal and process issue. I understand. > On the other hand it raises the barrier. We have had repeated complaints > from folks finding the process too difficult. Remember many of those > people are just those who want to attend a event or two and talk about > Fedora and things. Then, these people should be directed to fedora marketing. Fedora Ambassadors Project is a bridge between the Fedora Project and the rest of the world. Chitlesh -- http://clunixchit.blogspot.com From sundaram at fedoraproject.org Wed Feb 21 20:44:49 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 22 Feb 2007 02:14:49 +0530 Subject: CLA requirements In-Reply-To: <13dbfe4f0702211239k59d3e8b2t2b0c57b03afc3065@mail.gmail.com> References: <45DC8DC1.1010504@fedoraproject.org> <13dbfe4f0702211152s4bf615ccta01e2695bb260962@mail.gmail.com> <45DCA974.6080109@fedoraproject.org> <13dbfe4f0702211239k59d3e8b2t2b0c57b03afc3065@mail.gmail.com> Message-ID: <45DCAF41.90308@fedoraproject.org> Chitlesh GOORAH wrote: > Then, these people should be directed to fedora marketing. This is the club mentality I would want to avoid. Fedora Ambassadors Project is a bridge between the Fedora Project and the > rest of the world. You miss the point completely. In short we dont expect ambassadors to be highly technical people. Making all of them sign the CLA is currently a high barrier to entry. If only a dozen of them are contributing content, we should probably not be making all of them sign the CLA. As simple as that. Rahul From kevin at tummy.com Wed Feb 21 20:59:15 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Wed, 21 Feb 2007 13:59:15 -0700 Subject: CLA requirements In-Reply-To: <45DC8DC1.1010504@fedoraproject.org> References: <45DC8DC1.1010504@fedoraproject.org> Message-ID: <20070221135915.2e7e35d7@ningauble.scrye.com> On Wed, 21 Feb 2007 23:51:53 +0530 sundaram at fedoraproject.org (Rahul Sundaram) wrote: > Hi > > I had the impression that bug triaging doesnt require CLA and > approved a bunch of folks who have signed for fedorabugs group in the > account system but then the question was raised on whether a CLA is > required for that. Do we really need CLA for groups like bug triaging > and ambassadors majority of whom dont submit any content to the > project? As far as fedorabugs, I think it might be good for them to have the CLA done, since they may be submitting patches, or suggested docs or other content that might end up shipping in packages and/or web pages. Alternately, perhaps bugzilla could do what it was suggested that the wiki do, namely have something like the wiki's: "By hitting Save Changes you put your changes under the WikiLicense. If you don't want that, hit Cancel to cancel your changes." ie, "By hitting submit you put your changes under the bugzillalicense. If you don't want that, don't hit submit". kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davidz at redhat.com Wed Feb 21 23:26:31 2007 From: davidz at redhat.com (David Zeuthen) Date: Wed, 21 Feb 2007 18:26:31 -0500 Subject: Dell + Linux In-Reply-To: <200702211017.36125.jkeating@redhat.com> References: <45DC575F.8080801@redhat.com> <200702211009.57767.jkeating@redhat.com> <45DC609E.8030408@redhat.com> <200702211017.36125.jkeating@redhat.com> Message-ID: <1172100391.2675.69.camel@zelda.fubar.dk> On Wed, 2007-02-21 at 10:17 -0500, Jesse Keating wrote: > On Wednesday 21 February 2007 10:09, Mike McGrath wrote: > > What if we helpped Dell create an OSS gnome and KDE theme and got it > > into Extras? > > Is Dell willing to let their graphics be released under an OSS license, for > anybody to apply them to any non-dell machine? I'm thinking... no. > > Seriously, we really really really need a second set of trademarks/logos that > would be usable by folks like Dell to be able to do 'Fedora' preinstalls with > some of their customization. They could call it Dell Linux Based on Fedora > or whatever. Just some way for them to legally use the term Fedora and still > accomplish the minimal customization that almost any vendor would want (and > sometimes need). First of all we need to make it a lot simpler to rebrand the distro AKA rip out trademarked Fedora logos; see the thread "Why is redhat-artwork multi-lib?" on fedora-devel-list about how many packages you have to modify today. Ideally people would only have to provide a single package (that would provide system-logos) and our package collection would contain packages with generic non-branded artwork for this in addition to the trademarked fedora-logos. Going forward, perhaps our tools (livecd-creator and pungi and pungi comes to mind) could be chained with some star-trek tool from the future that can create such an artwork packages given number of images (ideally just a single SVG). Then part of the build process automatically generates artwork appropriate artwork packages e.g. mydistro-logos so people doing derived distros don't need to maintain art packages if they don't want to. Or something. Just throwing out ideas. Today rebranding Fedora is just damn hard and we want to change that. David From fedora at leemhuis.info Thu Feb 22 05:42:37 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 22 Feb 2007 06:42:37 +0100 Subject: Dell + Linux In-Reply-To: <1172100391.2675.69.camel@zelda.fubar.dk> References: <45DC575F.8080801@redhat.com> <200702211009.57767.jkeating@redhat.com> <45DC609E.8030408@redhat.com> <200702211017.36125.jkeating@redhat.com> <1172100391.2675.69.camel@zelda.fubar.dk> Message-ID: <45DD2D4D.9070103@leemhuis.info> On 22.02.2007 00:26, David Zeuthen wrote: > On Wed, 2007-02-21 at 10:17 -0500, Jesse Keating wrote: >> On Wednesday 21 February 2007 10:09, Mike McGrath wrote: >>> What if we helpped Dell create an OSS gnome and KDE theme and got it >>> into Extras? >> Is Dell willing to let their graphics be released under an OSS license, for >> anybody to apply them to any non-dell machine? I'm thinking... no. >> Seriously, we really really really need a second set of trademarks/logos that >> would be usable by folks like Dell to be able to do 'Fedora' preinstalls with >> some of their customization. They could call it Dell Linux Based on Fedora >> or whatever. Just some way for them to legally use the term Fedora and still >> accomplish the minimal customization that almost any vendor would want (and >> sometimes need). > First of all we need to make it a lot simpler to rebrand the distro AKA > rip out trademarked Fedora logos; see the thread "Why is redhat-artwork > multi-lib?" on fedora-devel-list about how many packages you have to > modify today. [...] Well, I agree with this goal in general, but not for this particular goal. If Dell or some other Vendor really wants to ship Fedora with Hardware then we should do our best to make it possible that they can do it under the name "Fedora" -- that has benefits for both sides afaics. So in other words: I'm fine if $VENDOR would ship Fedora under the Fedora name with some Add-On-Packages with Closed-Source-Software that are is only for branding and support of $VENDOR -- we of course should ACK those package. Shipping stuff (say, packages from 3rd party repos) that really enhance the functionality of Fedora on the other hand is of course is not okay under the name Fedora. CU thl From nman64 at n-man.com Sat Feb 24 02:36:55 2007 From: nman64 at n-man.com (Patrick W. Barnes) Date: Fri, 23 Feb 2007 20:36:55 -0600 Subject: CLA requirements In-Reply-To: <45DCAF41.90308@fedoraproject.org> References: <45DC8DC1.1010504@fedoraproject.org> <13dbfe4f0702211239k59d3e8b2t2b0c57b03afc3065@mail.gmail.com> <45DCAF41.90308@fedoraproject.org> Message-ID: <200702232036.59207.nman64@n-man.com> On Wednesday 21 February 2007, Rahul Sundaram wrote: > Chitlesh GOORAH wrote: > > Then, these people should be directed to fedora marketing. > > This is the club mentality I would want to avoid. > It's not a club mentality. Ambassadors isn't for people who just want to attend an event, or who just want to comment on Fedora. It is for people who intend to work with us to produce materials, conduct planning, manage spending, and other such tasks that invariably end up requiring a completed CLA. Even in cases where the CLA isn't explicitly necessary, we need an identity and contact information, and the CLA is only a small step beyond that. It's really not much to ask for the amount of trust we place in them for their trouble. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://n-man.com/ LinkedIn: http://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 tchung at fedoraproject.org Sat Feb 24 02:40:28 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Fri, 23 Feb 2007 18:40:28 -0800 Subject: CLA requirements In-Reply-To: <200702232036.59207.nman64@n-man.com> References: <45DC8DC1.1010504@fedoraproject.org> <13dbfe4f0702211239k59d3e8b2t2b0c57b03afc3065@mail.gmail.com> <45DCAF41.90308@fedoraproject.org> <200702232036.59207.nman64@n-man.com> Message-ID: <369bce3b0702231840t40b71b3fo5d38a87b72b345b3@mail.gmail.com> On 2/23/07, Patrick W. Barnes wrote: > On Wednesday 21 February 2007, Rahul Sundaram wrote: > > Chitlesh GOORAH wrote: > > > Then, these people should be directed to fedora marketing. > > > > This is the club mentality I would want to avoid. > > > > It's not a club mentality. Ambassadors isn't for people who just want to > attend an event, or who just want to comment on Fedora. It is for people who > intend to work with us to produce materials, conduct planning, manage > spending, and other such tasks that invariably end up requiring a completed > CLA. Even in cases where the CLA isn't explicitly necessary, we need an > identity and contact information, and the CLA is only a small step beyond > that. It's really not much to ask for the amount of trust we place in them > for their trouble. +1 for Patrick -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From nman64 at n-man.com Sat Feb 24 02:41:12 2007 From: nman64 at n-man.com (Patrick W. Barnes) Date: Fri, 23 Feb 2007 20:41:12 -0600 Subject: CLA requirements In-Reply-To: <20070221135915.2e7e35d7@ningauble.scrye.com> References: <45DC8DC1.1010504@fedoraproject.org> <20070221135915.2e7e35d7@ningauble.scrye.com> Message-ID: <200702232041.15955.nman64@n-man.com> On Wednesday 21 February 2007, Kevin Fenzi wrote: > > As far as fedorabugs, I think it might be good for them to have the CLA > done, since they may be submitting patches, or suggested docs or other > content that might end up shipping in packages and/or web pages. > > Alternately, perhaps bugzilla could do what it was suggested that the > wiki do, namely have something like the wiki's: > "By hitting Save Changes you put your changes under the WikiLicense. If > you don't want that, hit Cancel to cancel your changes." > > ie, > > "By hitting submit you put your changes under the bugzillalicense. If > you don't want that, don't hit submit". > I agree, except that we need to point to the CLA as the agreement, rather than a specific license. That applies to the wiki, too. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://n-man.com/ LinkedIn: http://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 sundaram at fedoraproject.org Sat Feb 24 02:54:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 24 Feb 2007 08:24:39 +0530 Subject: CLA requirements In-Reply-To: <200702232036.59207.nman64@n-man.com> References: <45DC8DC1.1010504@fedoraproject.org> <13dbfe4f0702211239k59d3e8b2t2b0c57b03afc3065@mail.gmail.com> <45DCAF41.90308@fedoraproject.org> <200702232036.59207.nman64@n-man.com> Message-ID: <45DFA8EF.7030607@fedoraproject.org> Patrick W. Barnes wrote: > On Wednesday 21 February 2007, Rahul Sundaram wrote: >> Chitlesh GOORAH wrote: >>> Then, these people should be directed to fedora marketing. >> This is the club mentality I would want to avoid. >> > > It's not a club mentality. Ambassadors isn't for people who just want to > attend an event, or who just want to comment on Fedora. When it was started, it was precisely meant for people to be able to represent Fedora easily in events and generally act as regional contacts. Only a very small portion of these submit any sort of content. Now everybody has redefined it into all sort of fancy things. To reiterate, this conversation was not about ambassadors in particular but to get a legal understanding of what groups require CLA. Rahul From mmcgrath at redhat.com Sat Feb 24 02:58:50 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 23 Feb 2007 20:58:50 -0600 Subject: CLA requirements In-Reply-To: <45DFA8EF.7030607@fedoraproject.org> References: <45DC8DC1.1010504@fedoraproject.org> <13dbfe4f0702211239k59d3e8b2t2b0c57b03afc3065@mail.gmail.com> <45DCAF41.90308@fedoraproject.org> <200702232036.59207.nman64@n-man.com> <45DFA8EF.7030607@fedoraproject.org> Message-ID: <45DFA9EA.6070007@redhat.com> Rahul Sundaram wrote: > When it was started, it was precisely meant for people to be able to > represent Fedora easily in events and generally act as regional > contacts. Only a very small portion of these submit any sort of > content. Now everybody has redefined it into all sort of fancy things. > To reiterate, this conversation was not about ambassadors in > particular but to get a legal understanding of what groups require CLA. Sounds like its been a success then :-) One thing we've talked about off and on is what exactly it means to be a 'contributor'. This thread may be relevant to that. -Mike From kwade at redhat.com Sat Feb 24 03:24:35 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 23 Feb 2007 19:24:35 -0800 Subject: CLA requirements In-Reply-To: <45DFA9EA.6070007@redhat.com> References: <45DC8DC1.1010504@fedoraproject.org> <13dbfe4f0702211239k59d3e8b2t2b0c57b03afc3065@mail.gmail.com> <45DCAF41.90308@fedoraproject.org> <200702232036.59207.nman64@n-man.com> <45DFA8EF.7030607@fedoraproject.org> <45DFA9EA.6070007@redhat.com> Message-ID: <1172287476.4651.71.camel@erato.phig.org> On Fri, 2007-02-23 at 20:58 -0600, Mike McGrath wrote: > Rahul Sundaram wrote: > > When it was started, it was precisely meant for people to be able to > > represent Fedora easily in events and generally act as regional > > contacts. Only a very small portion of these submit any sort of > > content. Now everybody has redefined it into all sort of fancy things. > > To reiterate, this conversation was not about ambassadors in > > particular but to get a legal understanding of what groups require CLA. > Sounds like its been a success then :-) One thing we've talked about > off and on is what exactly it means to be a 'contributor'. This thread > may be relevant to that. Interesting point, yes. To refer back up to Rahul's comment, the CLA covers contributions of content. What is content? When you and I stand in one place together, breathing the same air, and discussing Fedora ... the content of our conversation is about Fedora. When we were at FUDCon discussing ideas, were those ideas not content covered under the CLA? Is leadership a contribution? Or only the changes made in UTF-8 characters on a page in the Wiki? Or only in CVS? As a person whose largest contribution is often the ideas I come up with, I feel very strongly that my ideas are i) contributions, and ii) covered by the CLA. I'd think Rahul would feel the same way, considering how many ideas he has contributed to Fedora. The gradient we may be wanting to define is, how much damage (intentional or otherwise) can an individual make with their contribution? The higher the damage level, the higher the risk to the Fedora Project. The higher the risk, the more trust mechanisms should be required. Following that direction, we avoid entirely the discussion of what is content and what is a contribution. A simple, generic definition should suffice: "If you provide something to the Fedora Project and did not get paid in a recognized currency or otherwise receive fair market value in trade, it is a contribution." There is danger in trying to define who needs to sign a CLA by if they are a contributor. The rule really is, everyone who contributes needs to agree to (sign) the CLA. The only question is, do they all have to agree to (sign) it using the same method? - 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 Feb 24 18:50:25 2007 From: kwade at redhat.com (Karsten Wade) Date: Sat, 24 Feb 2007 10:50:25 -0800 Subject: CLA requirements In-Reply-To: <45DCAF41.90308@fedoraproject.org> References: <45DC8DC1.1010504@fedoraproject.org> <13dbfe4f0702211152s4bf615ccta01e2695bb260962@mail.gmail.com> <45DCA974.6080109@fedoraproject.org> <13dbfe4f0702211239k59d3e8b2t2b0c57b03afc3065@mail.gmail.com> <45DCAF41.90308@fedoraproject.org> Message-ID: <1172343025.4651.92.camel@erato.phig.org> On Thu, 2007-02-22 at 02:14 +0530, Rahul Sundaram wrote: > You miss the point completely. In short we dont expect ambassadors to be > highly technical people. Making all of them sign the CLA is currently a > high barrier to entry. There is no big technical difficulty in signing the CLA. It is not that high of a barrier. When people balk at accomplishing a minor technical task to gain entry, it makes me wonder. I personally consider that being able to obtain and use a GPG key *should* be a requirement for anyone representing Fedora. If they are stopped from participating by that ... well, disappointing, but, oh, well. Anyway, that's just MHO and does not represent the direction I am backing for Fedora. I've conceded that the idea of using a click-through CLA for the Wiki should be OK, but not because I think we should require less from all Fedora contributors. For me, it's a follow-on from allowing the Wiki in the first place. It is not a deliberate attempt to get contributions from people who are unable to figure out a simple set of instructions. It is instead a deliberate attempt to gain contributions from people who are able to follow the instructions, but refuse to do so for various reasons. Because there are enough of them and their potential contributions are valuable enough, we are willing to work toward a middle-ground. IMO and AIUI, the question of, "To CLA or not to CLA?" is not really a question. The only valid question is, "How to CLA?" > If only a dozen of them are contributing > content, we should probably not be making all of them sign the CLA. As > simple as that. This logic does not follow. As I explain in a separate post, everything the Ambassadors do is a contribution. The question is not if someone needs a CLA with Fedora to contribute, but how they go about agreeing to/signing the CLA. - 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 jkeating at redhat.com Sat Feb 24 19:08:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 24 Feb 2007 14:08:50 -0500 Subject: CLA requirements In-Reply-To: <1172343025.4651.92.camel@erato.phig.org> References: <45DC8DC1.1010504@fedoraproject.org> <45DCAF41.90308@fedoraproject.org> <1172343025.4651.92.camel@erato.phig.org> Message-ID: <200702241408.51029.jkeating@redhat.com> On Saturday 24 February 2007 13:50, Karsten Wade wrote: > I've conceded that the idea of using a click-through CLA for the Wiki > should be OK, but not because I think we should require less from all > Fedora contributors. ?For me, it's a follow-on from allowing the Wiki in > the first place. ?It is not a deliberate attempt to get contributions > from people who are unable to figure out a simple set of instructions. > It is instead a deliberate attempt to gain contributions from people who > are able to follow the instructions, but refuse to do so for various > reasons. ?Because there are enough of them and their potential > contributions are valuable enough, we are willing to work toward a > middle-ground. > > IMO and AIUI, the question of, "To CLA or not to CLA?" is not really a > question. ?The only valid question is, "How to CLA?" I agree. My only problem with the CLA is that it takes a lot of hoops to get from 'I want to change this item in the wiki which I know more about' to 'I now have my verified Fedora account, CLA has been signed and mailed back correctly, I've now got a Wiki account, and I've gotten somebody to verify my Fedora account has CLA done and has added me to the EditGroup'. We lose most people around 'what is a Fedora account?' step, or somewhere else along the way when something doesn't just work perfectly (like gpg key doesn't match email used, or CLA isn't getting verified correctly, or nobody is around to add to EditGroup, or....) We REALLY need to make it easier, while protecting ourselves still with the CLA. -- 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 tchung at fedoraproject.org Sat Feb 24 19:15:06 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Sat, 24 Feb 2007 11:15:06 -0800 Subject: CLA requirements In-Reply-To: <200702241408.51029.jkeating@redhat.com> References: <45DC8DC1.1010504@fedoraproject.org> <45DCAF41.90308@fedoraproject.org> <1172343025.4651.92.camel@erato.phig.org> <200702241408.51029.jkeating@redhat.com> Message-ID: <369bce3b0702241115q42322ba9s5884216e88f05c@mail.gmail.com> On 2/24/07, Jesse Keating wrote: > I agree. My only problem with the CLA is that it takes a lot of hoops to get > from 'I want to change this item in the wiki which I know more about' to 'I > now have my verified Fedora account, CLA has been signed and mailed back > correctly, I've now got a Wiki account, and I've gotten somebody to verify my > Fedora account has CLA done and has added me to the EditGroup'. We lose most > people around 'what is a Fedora account?' step, or somewhere else along the > way when something doesn't just work perfectly (like gpg key doesn't match > email used, or CLA isn't getting verified correctly, or nobody is around to > add to EditGroup, or....) > > We REALLY need to make it easier, while protecting ourselves still with the > CLA. I thought I was doing a reasonably good job adding people to EditGroup. :) http://fedoraproject.org/wiki/EditGroupQueue http://fedoraproject.org/wiki/EditGroup Seriously, I don't really care how they sign CLA as long as they sign CLA. Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From sundaram at fedoraproject.org Sat Feb 24 19:21:43 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 25 Feb 2007 00:51:43 +0530 Subject: CLA requirements In-Reply-To: <1172343025.4651.92.camel@erato.phig.org> References: <45DC8DC1.1010504@fedoraproject.org> <13dbfe4f0702211152s4bf615ccta01e2695bb260962@mail.gmail.com> <45DCA974.6080109@fedoraproject.org> <13dbfe4f0702211239k59d3e8b2t2b0c57b03afc3065@mail.gmail.com> <45DCAF41.90308@fedoraproject.org> <1172343025.4651.92.camel@erato.phig.org> Message-ID: <45E09047.7040502@fedoraproject.org> Karsten Wade wrote: > On Thu, 2007-02-22 at 02:14 +0530, Rahul Sundaram wrote: > >> You miss the point completely. In short we dont expect ambassadors to be >> highly technical people. Making all of them sign the CLA is currently a >> high barrier to entry. > > There is no big technical difficulty in signing the CLA. It is not that > high of a barrier. > > When people balk at accomplishing a minor technical task to gain entry, > it makes me wonder. I personally consider that being able to obtain and > use a GPG key *should* be a requirement for anyone representing Fedora. > If they are stopped from participating by that ... well, disappointing, > but, oh, well. Anyway, that's just MHO and does not represent the > direction I am backing for Fedora. Depends on the context. If it's for maintaining a package, it is just part of the process. The maintainer has to deal with much more complicated things than a gpg signature during the course anyway. For a ambassadors, it is relatively high. For someone new, editing a wiki for adding some simple comments or fixing a typo, its way too high to bother. Rahul From nman64 at n-man.com Sun Feb 25 07:05:06 2007 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sun, 25 Feb 2007 01:05:06 -0600 Subject: Good riddance, ESR Message-ID: <200702250105.09966.nman64@n-man.com> While ESR has been little more than a thorn in our sides for quite some time, he seems to think he's still rather important around here, and he has much of the Linux media thinking the same thing. I'm sure most of you have already seen some publication about his rather noisy exit, and many of you have probably shaken your heads in disappointment in his behavior and the attention he has received for it. I'm not writing to start up some ESR-bashing thread, though. I want to ask if I'm the only one that thinks a tasteful rebuttal is in order. The publicity that ESR has created may be very damaging, even if it is only used by people who already don't like Fedora as fuel for their pre-existing flames. I think we should consider responding with some damage control, either through a direct rebuttal that addresses ESR's true relationship to us and our positions on some of his key statements, or through a positive "press release" that does not directly respond to ESR, but rather delivers a positive message and progress statement. The latter might be in some ways similar to Max's Slashdot interview last year. Thoughts? -- Patrick "The N-Man" Barnes nman64 at n-man.com http://n-man.com/ LinkedIn: http://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 blizzard at redhat.com Sun Feb 25 15:17:53 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Sun, 25 Feb 2007 10:17:53 -0500 Subject: Good riddance, ESR In-Reply-To: <200702250105.09966.nman64@n-man.com> References: <200702250105.09966.nman64@n-man.com> Message-ID: <1172416673.30900.7.camel@localhost.localdomain> I don't think that responding to ESR is the right way to go. It just legitimizes the tactics, even considering how _far_ off base he was in most of his claims. But I do like the idea of doing a bit of work around summarizing the huge changes that we've made since FC5 and FC6 and what F7 will mean to the community and what we have in the pipeline. Both in terms of community development and participation but also pushing the platform and technology forward. We're doing great work. (And when I say We I don't mean the people at Red Hat, who are doing great work, but I mostly mean everyone outside who is totally rocking at building a great free software distribution.) What I find truly strange in the light of his departure is that I've never felt more bullish about our future. ESR's departure comes at a strange time because we're at the cusp of something great. And I think we need to talk about that. --Chris From stickster at gmail.com Sun Feb 25 15:42:53 2007 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 25 Feb 2007 10:42:53 -0500 Subject: Good riddance, ESR In-Reply-To: <1172416673.30900.7.camel@localhost.localdomain> References: <200702250105.09966.nman64@n-man.com> <1172416673.30900.7.camel@localhost.localdomain> Message-ID: <1172418173.13489.3.camel@localhost.localdomain> On Sun, 2007-02-25 at 10:17 -0500, Christopher Blizzard wrote: > I don't think that responding to ESR is the right way to go. It just > legitimizes the tactics, even considering how _far_ off base he was in > most of his claims. > > But I do like the idea of doing a bit of work around summarizing the > huge changes that we've made since FC5 and FC6 and what F7 will mean to > the community and what we have in the pipeline. Both in terms of > community development and participation but also pushing the platform > and technology forward. We're doing great work. (And when I say We I > don't mean the people at Red Hat, who are doing great work, but I mostly > mean everyone outside who is totally rocking at building a great free > software distribution.) > > What I find truly strange in the light of his departure is that I've > never felt more bullish about our future. ESR's departure comes at a > strange time because we're at the cusp of something great. And I think > we need to talk about that. +1 all around. There are a number of news outlets and editorials that have also basically shrugged, saying, "So what?" The right time to toot our horn will be at F7 release time when we have a great milepost to shows off how much has changed and how many improvements we've made. Plenty of unofficial community outlets already exist for countering the factual inaccuracies and bluster we've seen recently. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 bpepple at fedoraproject.org Sun Feb 25 15:37:06 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 25 Feb 2007 10:37:06 -0500 Subject: Good riddance, ESR In-Reply-To: <1172416673.30900.7.camel@localhost.localdomain> References: <200702250105.09966.nman64@n-man.com> <1172416673.30900.7.camel@localhost.localdomain> Message-ID: <1172417826.1289.0.camel@Chuck> On Sun, 2007-02-25 at 10:17 -0500, Christopher Blizzard wrote: > I don't think that responding to ESR is the right way to go. It just > legitimizes the tactics, even considering how _far_ off base he was in > most of his claims. > +1 /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nman64 at n-man.com Sun Feb 25 17:18:30 2007 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sun, 25 Feb 2007 11:18:30 -0600 Subject: Good riddance, ESR In-Reply-To: <1172416673.30900.7.camel@localhost.localdomain> References: <200702250105.09966.nman64@n-man.com> <1172416673.30900.7.camel@localhost.localdomain> Message-ID: <200702251118.34048.nman64@n-man.com> On Sunday 25 February 2007, Christopher Blizzard wrote: > I don't think that responding to ESR is the right way to go. It just > legitimizes the tactics, even considering how _far_ off base he was in > most of his claims. > > But I do like the idea of doing a bit of work around summarizing the > huge changes that we've made since FC5 and FC6 and what F7 will mean to > the community and what we have in the pipeline. Both in terms of > community development and participation but also pushing the platform > and technology forward. We're doing great work. (And when I say We I > don't mean the people at Red Hat, who are doing great work, but I mostly > mean everyone outside who is totally rocking at building a great free > software distribution.) > > What I find truly strange in the light of his departure is that I've > never felt more bullish about our future. ESR's departure comes at a > strange time because we're at the cusp of something great. And I think > we need to talk about that. > Sensible. I know that F7 is still a short time away, but perhaps we can start now to prepare a truly powerful message. My current thinking is that we should solicit questions from our end-users pertaining to both the Fedora Project's current status and the F7 release, perhaps from fedora-list, and compile a list of high-quality answers. This idea is inspired by Max's Slashdot interview. I think we should then publish that document about a week before the final release - almost as a bit of a teaser. It could also be included in our release summary or other release documentation on the wiki. I'm sure there will be a large number of questions that arise from the changes since FC6, especially with the Core+Extras merger and new spins. Does anyone here think they could gather such questions? -- Patrick "The N-Man" Barnes nman64 at n-man.com http://n-man.com/ LinkedIn: http://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 mmcgrath at redhat.com Sun Feb 25 18:41:31 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 25 Feb 2007 12:41:31 -0600 Subject: Good riddance, ESR In-Reply-To: <200702251118.34048.nman64@n-man.com> References: <200702250105.09966.nman64@n-man.com> <1172416673.30900.7.camel@localhost.localdomain> <200702251118.34048.nman64@n-man.com> Message-ID: <45E1D85B.4030709@redhat.com> Patrick W. Barnes wrote: > Sensible. I know that F7 is still a short time away, but perhaps we can start > now to prepare a truly powerful message. My current thinking is that we > should solicit questions from our end-users pertaining to both the Fedora > Project's current status and the F7 release, perhaps from fedora-list, and > compile a list of high-quality answers. This idea is inspired by Max's > Slashdot interview. I think we should then publish that document about a > week before the final release - almost as a bit of a teaser. It could also > be included in our release summary or other release documentation on the > wiki. I'm sure there will be a large number of questions that arise from the > changes since FC6, especially with the Core+Extras merger and new spins. > Does anyone here think they could gather such questions? > F7 is one thing but the Fedora Universe is another, I think we as a community could do a much better job getting our global message out. -Mike From gdk at redhat.com Sun Feb 25 18:46:40 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Sun, 25 Feb 2007 13:46:40 -0500 (EST) Subject: Good riddance, ESR In-Reply-To: <1172416673.30900.7.camel@localhost.localdomain> References: <200702250105.09966.nman64@n-man.com> <1172416673.30900.7.camel@localhost.localdomain> Message-ID: On Sun, 25 Feb 2007, Christopher Blizzard wrote: > What I find truly strange in the light of his departure is that I've > never felt more bullish about our future. ESR's departure comes at a > strange time because we're at the cusp of something great. And I think > we need to talk about that. So go ahead. Fact is, we've got a bunch of people saying exactly that. The real question: how do we get *heard*? --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From mmcgrath at redhat.com Sun Feb 25 19:10:09 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 25 Feb 2007 13:10:09 -0600 Subject: Good riddance, ESR In-Reply-To: References: <200702250105.09966.nman64@n-man.com> <1172416673.30900.7.camel@localhost.localdomain> Message-ID: <45E1DF11.4020307@redhat.com> Greg Dekoenigsberg wrote: > > The real question: how do we get *heard*? Grass roots? Lets make sure we all (FAB) have slashdot and digg type accounts and comment, answer questions, be intelligent, don't feed trolls, etc. Point out that whenever someone says "Fedora is losing users to Ubuntu" that the fact is we are gaining more users every day. Whenever someone says MP3's, tell them why MP3's are bad and mention how easy it is to get MP3 support. Whenever someone says Fedora is the playground of Red Hat mention that 81% of our registered users are not @redhat.com. Talk about the merging of core and extras, there's plenty of stuff we can do to just get people used to seeing our name and that we're a fighting group that cares about our work and that cares about the larger Open Source universe. I regularly check digg and slashdot comments only to find 1-3 mentions of Fedora in Linux related forums. -Mike From jwboyer at jdub.homelinux.org Sun Feb 25 19:10:12 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 25 Feb 2007 13:10:12 -0600 Subject: Good riddance, ESR In-Reply-To: References: <200702250105.09966.nman64@n-man.com> <1172416673.30900.7.camel@localhost.localdomain> Message-ID: <1172430612.2759.11.camel@vader.jdub.homelinux.org> On Sun, 2007-02-25 at 13:46 -0500, Greg Dekoenigsberg wrote: > On Sun, 25 Feb 2007, Christopher Blizzard wrote: > > > What I find truly strange in the light of his departure is that I've > > never felt more bullish about our future. ESR's departure comes at a > > strange time because we're at the cusp of something great. And I think > > we need to talk about that. > > So go ahead. > > Fact is, we've got a bunch of people saying exactly that. > > The real question: how do we get *heard*? Have people do interviews. The slashdot one was great. Maybe see if LWN is interested in asking some questions of what Fedora is about and where it's headed. Jon you listening? :) And while I think Max _rocks_ at spreading the good word, it might not hurt to have a few others do it. Thorsten for example. Or you Greg. We could also find people to write up reviews of F7 test 2 when it comes out. Personally, I'd be very interested to see what people out there think of the new LiveCD, etc. Right now, we have lots of people writing about the kick butt stuff Fedora is doing on their blogs. That's great and should continue. But a blog is not really a "mainstream" way to get stuff out there. As much as I loath Eric's recent "spam the press" tactic, it worked didn't it? I'm not saying we should really copy that, but we _could_ ask sites if they'd be interested in doing interviews/reviews. josh From laroche at redhat.com Sun Feb 25 21:57:35 2007 From: laroche at redhat.com (Florian La Roche) Date: Sun, 25 Feb 2007 22:57:35 +0100 Subject: Good riddance, ESR In-Reply-To: <200702251118.34048.nman64@n-man.com> References: <200702250105.09966.nman64@n-man.com> <1172416673.30900.7.camel@localhost.localdomain> <200702251118.34048.nman64@n-man.com> Message-ID: <20070225215735.GA3122@dudweiler.stuttgart.redhat.com> > Sensible. I know that F7 is still a short time away, but perhaps we can start > now to prepare a truly powerful message. My current thinking is that we > should solicit questions from our end-users pertaining to both the Fedora > Project's current status and the F7 release, perhaps from fedora-list, and > compile a list of high-quality answers. This idea is inspired by Max's > Slashdot interview. I think we should then publish that document about a > week before the final release - almost as a bit of a teaser. It could also > be included in our release summary or other release documentation on the > wiki. I'm sure there will be a large number of questions that arise from the > changes since FC6, especially with the Core+Extras merger and new spins. > Does anyone here think they could gather such questions? Shouldn't these messages be also what we publish and point people to on our wiki pages? regards, Florian La Roche From bugs.michael at gmx.net Sun Feb 25 22:25:55 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 25 Feb 2007 23:25:55 +0100 Subject: Good riddance, ESR In-Reply-To: <1172430612.2759.11.camel@vader.jdub.homelinux.org> References: <200702250105.09966.nman64@n-man.com> <1172416673.30900.7.camel@localhost.localdomain> <1172430612.2759.11.camel@vader.jdub.homelinux.org> Message-ID: <20070225232555.34a1b12b.bugs.michael@gmx.net> On Sun, 25 Feb 2007 13:10:12 -0600, Josh Boyer wrote: > > The real question: how do we get *heard*? > > Have people do interviews. The slashdot one was great. Maybe see if > LWN is interested in asking some questions of what Fedora is about and > where it's headed. Jon you listening? :) > > And while I think Max _rocks_ at spreading the good word, it might not > hurt to have a few others do it. Thorsten for example. http://www.heise.de/newsticker/meldung/85619 would have been an opportunity for that. A late rebuttal directly from within the Fedora Project would not be worth a bean. Some of the project objectives conflict with ESR's personal preferences, e.g. proprietary components. It's an opinion piece. He finds his target group. Even if proprietary multimedia formats, for example, are easy to add, Fedora won't win any people [back] who think the proprietary stuff ought to come built-in. Other points of his much too brief criticism don't lose weight as long as they remain partially true or are backed up by vocal people in their comments on relevant news articles. What most news websites don't and can't know, a package submission process that starts in bugzilla is incompatible with his desire to skip any steps which don't simply ship his entirely new packages into a dumping ground and without peer review. After he had been told about the new submission process that is in use since Fedora 3 and that afterwards, packages are maintained in cvs and are built by build-servers, he has started the submission of a first half-working package end of last year, but has not completed the few steps to sign up as a Fedora Contributor. It's not that some part of the submission process didn't work, it's a simple "I don't like it that way". From aoliva at redhat.com Mon Feb 26 06:47:39 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 26 Feb 2007 03:47:39 -0300 Subject: Good riddance, ESR In-Reply-To: <20070225232555.34a1b12b.bugs.michael@gmx.net> (Michael Schwendt's message of "Sun\, 25 Feb 2007 23\:25\:55 +0100") References: <200702250105.09966.nman64@n-man.com> <1172416673.30900.7.camel@localhost.localdomain> <1172430612.2759.11.camel@vader.jdub.homelinux.org> <20070225232555.34a1b12b.bugs.michael@gmx.net> Message-ID: On Feb 25, 2007, Michael Schwendt wrote: > A late rebuttal directly from within the Fedora Project would not be worth > a bean. Some of the project objectives conflict with ESR's personal > preferences, e.g. proprietary components. It's an opinion piece. He finds > his target group. Even if proprietary multimedia formats, for example, are > easy to add, Fedora won't win any people [back] who think the proprietary > stuff ought to come built-in. http://fsfla.org/svnwiki/circular/draft/2007-03.en.html#2 Comments on this draft, slated for publication (barring changes) on 2007-03-01? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From sundaram at fedoraproject.org Mon Feb 26 11:46:44 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 26 Feb 2007 17:16:44 +0530 Subject: Good riddance, ESR In-Reply-To: References: <200702250105.09966.nman64@n-man.com> <1172416673.30900.7.camel@localhost.localdomain> <1172430612.2759.11.camel@vader.jdub.homelinux.org> <20070225232555.34a1b12b.bugs.michael@gmx.net> Message-ID: <45E2C8A4.3020303@fedoraproject.org> Alexandre Oliva wrote: > On Feb 25, 2007, Michael Schwendt wrote: > >> A late rebuttal directly from within the Fedora Project would not be worth >> a bean. Some of the project objectives conflict with ESR's personal >> preferences, e.g. proprietary components. It's an opinion piece. He finds >> his target group. Even if proprietary multimedia formats, for example, are >> easy to add, Fedora won't win any people [back] who think the proprietary >> stuff ought to come built-in. > > http://fsfla.org/svnwiki/circular/draft/2007-03.en.html#2 > > Comments on this draft, slated for publication (barring changes) on > 2007-03-01? Sorry. That's just too cryptic to me. Especially the last couple of sentences in the paragraph. Perhaps you can expand on what you are talking about instead of assuming that everyone knows about "fifth freedom". Rahul From blizzard at redhat.com Mon Feb 26 20:18:35 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 26 Feb 2007 15:18:35 -0500 Subject: the danger of becoming a cargo cult Message-ID: <1172521115.12109.43.camel@localhost.localdomain> Something clicked in my head today when I was talking with Jonathan Blandford on the phone today. He described to me the idea of the Cargo Cult, something I had never heard of: http://en.wikipedia.org/wiki/Cargo_cult In fact, there's even an entry for use in computer science: http://en.wikipedia.org/wiki/Cargo_cult_software_engineering Until now I had no name for the behaviors that I saw in Fedora and other open source projects. We do this a lot. The conversation usually goes: Ubuntu has a live cd! We should have a live cd and then we will be teh win! Yes, of course! Let us build one from these sticks and coconuts! (This is a bad example, of course, because I do actually believe that having a working livecd has a lot of great side effects: keeping our base small and compact and letting people try out our technologies easily.) What jumped out at me from the article is this paragraph: "In a form of sympathetic magic, many built life-size mockups of airplanes out of straw, and created new military style landing strips, hoping to attract more airplanes. Ultimately, though these practices did not bring about the return of the god-like airplanes that brought such marvelous cargo during the war, they did have the effect of eradicating the religious practices that had existed prior to the war." I think that we need to be careful when we decide to move to new models for things. Understanding the underlying reason why we do anything is just as important as actually doing them. When we've talked about support for proprietary codecs or letting people use Fedora in new contexts (the trademark thing) we need to understand they why just as much as the how. So far we've been good, I think. We haven't lost our soul, or by mixing metaphors, our religious practices. But there's still a lot of opportunity in the future to make a mistake like this. So we need to keep vigilant and keep our sense of purpose. That is all. Carry on. --Chris From aoliva at redhat.com Mon Feb 26 20:45:25 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 26 Feb 2007 17:45:25 -0300 Subject: Good riddance, ESR In-Reply-To: <45E2C8A4.3020303@fedoraproject.org> (Rahul Sundaram's message of "Mon\, 26 Feb 2007 17\:16\:44 +0530") References: <200702250105.09966.nman64@n-man.com> <1172416673.30900.7.camel@localhost.localdomain> <1172430612.2759.11.camel@vader.jdub.homelinux.org> <20070225232555.34a1b12b.bugs.michael@gmx.net> <45E2C8A4.3020303@fedoraproject.org> Message-ID: On Feb 26, 2007, Rahul Sundaram wrote: > Alexandre Oliva wrote: >> http://fsfla.org/svnwiki/circular/draft/2007-03.en.html#2 >> Comments on this draft, slated for publication (barring changes) on >> 2007-03-01? > Sorry. That's just too cryptic to me. Especially the last couple of > sentences in the paragraph. Perhaps you can expand on what you are > talking about instead of assuming that everyone knows about "fifth > freedom". I assumed people would take the hint and follow the first link, to read about it, since this is a follow up. I've now hinted at it more strongly, and provided a short intuitive definition. Does this make it clear enough? If not, what paragraph's last couple of sentences don't make sense to you? (or by 'paragraph' do you mean 'section'?) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From sundaram at fedoraproject.org Mon Feb 26 21:01:09 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 27 Feb 2007 02:31:09 +0530 Subject: Good riddance, ESR In-Reply-To: References: <200702250105.09966.nman64@n-man.com> <1172416673.30900.7.camel@localhost.localdomain> <1172430612.2759.11.camel@vader.jdub.homelinux.org> <20070225232555.34a1b12b.bugs.michael@gmx.net> <45E2C8A4.3020303@fedoraproject.org> Message-ID: <45E34A95.5000001@fedoraproject.org> Alexandre Oliva wrote: > I assumed people would take the hint and follow the first link, to > read about it, since this is a follow up. I've now hinted at it more > strongly, and provided a short intuitive definition. Does this make > it clear enough? Yes. It does. > > If not, what paragraph's last couple of sentences don't make sense to > you? (or by 'paragraph' do you mean 'section'?) "Fedora and Ubuntu have both revisited their policies about inclusion of non-Free firmware in their distributions, even though no actual policy changes were made at this time." We made no policy changes at all in Fedora. I am not aware of what changes were made in Ubuntu regarding firmware either. Perhaps references would be useful to understand what you are talking about. Earlier there werent many packages that met our licensing guidelines for firmware (ie) at the base minimum, it should be redistributable and those that were had licenses which required some legal review/clarifications. So now that we have some potential candidates, we are looking at including those packages. These are firmware for wireless cards. So we cant do something like codec buddy here since folks probably would require the firmware to get to a net connection in the first place. Catch 22. Rahul From fedora at leemhuis.info Tue Feb 27 06:30:18 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 27 Feb 2007 07:30:18 +0100 Subject: the danger of becoming a cargo cult In-Reply-To: <1172521115.12109.43.camel@localhost.localdomain> References: <1172521115.12109.43.camel@localhost.localdomain> Message-ID: <45E3CFFA.60707@leemhuis.info> On 26.02.2007 21:18, Christopher Blizzard wrote: > Something clicked in my head today when I was talking with Jonathan > Blandford on the phone today. He described to me the idea of the Cargo > Cult, something I had never heard of: > > http://en.wikipedia.org/wiki/Cargo_cult > > In fact, there's even an entry for use in computer science: > > http://en.wikipedia.org/wiki/Cargo_cult_software_engineering > > [...] > > So far we've been good, I think. We haven't lost our soul, or by mixing > metaphors, our religious practices. But there's still a lot of > opportunity in the future to make a mistake like this. So we need to > keep vigilant and keep our sense of purpose. > > That is all. Carry on. Agreed -- but nevertheless *I* still have the impression that Red Hat and Fedora developers work to much with upstream on improving the Linux software stack (which is a good thing in general, but: ) and don't care enough about our distribution specific stuff. Ubuntu is much more active in that area and thus has some interesting stuff that we are already still working on (codec buddy) or have on our Roadmap (say: new initsystem). That makes them much more attractive these days afaics, as they also get the improvements Red Hat has worked out automatically, too (often before we ship them). To say it in another way: In the past it was Red Hat Linux that lead the way (upstream and in the distribution) and others had to catch up under the risk to run into a "Cargo Cult". These days it seems to be Ubuntu. Just my 2 cent. CU thl From sundaram at fedoraproject.org Tue Feb 27 13:38:45 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 27 Feb 2007 19:08:45 +0530 Subject: the danger of becoming a cargo cult In-Reply-To: <45E3CFFA.60707@leemhuis.info> References: <1172521115.12109.43.camel@localhost.localdomain> <45E3CFFA.60707@leemhuis.info> Message-ID: <45E43465.6090401@fedoraproject.org> Thorsten Leemhuis wrote: > Agreed -- but nevertheless *I* still have the impression that Red Hat > and Fedora developers work to much with upstream on improving the Linux > software stack (which is a good thing in general, but: ) and don't care > enough about our distribution specific stuff. It is just different focus areas. See below. > > Ubuntu is much more active in that area and thus has some interesting > stuff that we are already still working on (codec buddy) or have on our > Roadmap (say: new initsystem). Ubuntu is pretty much in the same position regarding codec buddy since the library is getting merged with upstream Gstreamer. Fedora has SELinux, Xen, Compiz integration etc. Let's not undersell ourselves unnecessarily. Focusing on one distribution repeatedly is not a good idea either. Rahul From blizzard at redhat.com Wed Feb 28 17:07:09 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 28 Feb 2007 12:07:09 -0500 Subject: the danger of becoming a cargo cult In-Reply-To: <45E3CFFA.60707@leemhuis.info> References: <1172521115.12109.43.camel@localhost.localdomain> <45E3CFFA.60707@leemhuis.info> Message-ID: <1172682429.2871.76.camel@localhost.localdomain> On Tue, 2007-02-27 at 07:30 +0100, Thorsten Leemhuis wrote: > Agreed -- but nevertheless *I* still have the impression that Red Hat > and Fedora developers work to much with upstream on improving the Linux > software stack (which is a good thing in general, but: ) and don't care > enough about our distribution specific stuff. > > Ubuntu is much more active in that area and thus has some interesting > stuff that we are already still working on (codec buddy) or have on our > Roadmap (say: new initsystem). That makes them much more attractive > these days afaics, as they also get the improvements Red Hat has worked > out automatically, too (often before we ship them). > > To say it in another way: In the past it was Red Hat Linux that lead the > way (upstream and in the distribution) and others had to catch up under > the risk to run into a "Cargo Cult". These days it seems to be Ubuntu. I've had this conversation with Jonathan in the past, who has articulated better than most. He feels that working upstream instead of Fedora gives him the most leverage and can drive the direction of the desktop. And he's right, we've been hugely successful at building healthy upstream projects that make our jobs much easier here in Fedora. The downside to that is that Fedora's users are the _last_ to benefit from the work that Red Hat has funded. It's one of the reasons why a healthy and open Fedora is so important to me personally. In a system in which package ownership and maintenance can be done by both people inside of Red Hat and outside, we get the best of both worlds. Strong upstream work by full-time developers and an excited and engaged user/developer base that feels ownership and can do the early and final integration that Red Hat has failed to do because they are too busy fixing upstream issues. This is also connected to why I feel why it's so important that we figure out a better way to handle source, patches and packaging - maybe including source-as-SCM. Early development and testing mediates some of the the Fedora-has-best-practices-but-still-ends-up-last problem. (Loved by upstream projects and developers, used by few.) --Chris From blizzard at redhat.com Wed Feb 28 17:09:19 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 28 Feb 2007 12:09:19 -0500 Subject: the danger of becoming a cargo cult In-Reply-To: <45E43465.6090401@fedoraproject.org> References: <1172521115.12109.43.camel@localhost.localdomain> <45E3CFFA.60707@leemhuis.info> <45E43465.6090401@fedoraproject.org> Message-ID: <1172682559.2871.80.camel@localhost.localdomain> On Tue, 2007-02-27 at 19:08 +0530, Rahul Sundaram wrote: > > Ubuntu is much more active in that area and thus has some interesting > > stuff that we are already still working on (codec buddy) or have on our > > Roadmap (say: new initsystem). > > Ubuntu is pretty much in the same position regarding codec buddy since > the library is getting merged with upstream Gstreamer. Fedora has > SELinux, Xen, Compiz integration etc. Let's not undersell ourselves > unnecessarily. Focusing on one distribution repeatedly is not a good > idea either. Yeah, we have some very strong areas that others don't compete with. Xen is one of them, SELinux is another. Overall security is another - we've done a huge amount of work in that area (see Mark Cox's blog for specific statistics.) And we're starting to get ahead in other areas as well. The core + extras merge is really going to start to help us get ahead of the curve again instead of always being on the defensive. Things really _are_ looking up and I'm really excited about our future. --Chris