From skvidal at fedoraproject.org Sun Nov 4 20:14:15 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sun, 04 Nov 2007 15:14:15 -0500 Subject: codec buddy pain Message-ID: <1194207255.2654.66.camel@cutter> http://lwn.net/Articles/256974/ Btw - in the interview they mention further integration of the webstore into codeina/codecbuddy. If it starts looking like we're pushing closed source software then that, imo, is when codeina gets dumped out of the distribution. I don't care about needles and I don't want to ween the addicts off. -sv From tcallawa at redhat.com Sun Nov 4 20:24:27 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 04 Nov 2007 15:24:27 -0500 Subject: codec buddy pain In-Reply-To: <1194207255.2654.66.camel@cutter> References: <1194207255.2654.66.camel@cutter> Message-ID: <1194207867.3231.7.camel@localhost.localdomain> On Sun, 2007-11-04 at 15:14 -0500, seth vidal wrote: > http://lwn.net/Articles/256974/ > > Btw - in the interview they mention further integration of the webstore > into codeina/codecbuddy. If it starts looking like we're pushing closed > source software then that, imo, is when codeina gets dumped out of the > distribution. > > I don't care about needles and I don't want to ween the addicts off. I second. ~spot From sundaram at fedoraproject.org Sun Nov 4 20:27:50 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 05 Nov 2007 01:57:50 +0530 Subject: codec buddy pain In-Reply-To: <1194207255.2654.66.camel@cutter> References: <1194207255.2654.66.camel@cutter> Message-ID: <472E2B46.1070901@fedoraproject.org> seth vidal wrote: > http://lwn.net/Articles/256974/ > > Btw - in the interview they mention further integration of the webstore > into codeina/codecbuddy. If it starts looking like we're pushing closed > source software then that, imo, is when codeina gets dumped out of the > distribution. > > I don't care about needles and I don't want to ween the addicts off. Another related point is that Rhythmbox is the default media player while Codec Buddy only works with totem (ie) the kind of users who most benefit from such features will not get it since the default action wouldn't bring this feature up at all. Did Red Hat Legal ever respond to the question of pointing to other repositories yet? Rahul From tcallawa at redhat.com Sun Nov 4 20:36:25 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 04 Nov 2007 15:36:25 -0500 Subject: codec buddy pain In-Reply-To: <472E2B46.1070901@fedoraproject.org> References: <1194207255.2654.66.camel@cutter> <472E2B46.1070901@fedoraproject.org> Message-ID: <1194208585.3231.9.camel@localhost.localdomain> On Mon, 2007-11-05 at 01:57 +0530, Rahul Sundaram wrote: > Did Red Hat Legal ever respond to the question of pointing to other > repositories yet? Not yet, but I am not hopeful that they'll answer in a way that will be useful. ~spot From blizzard at 0xdeadbeef.com Mon Nov 5 01:14:28 2007 From: blizzard at 0xdeadbeef.com (Christopher Blizzard) Date: Sun, 04 Nov 2007 20:14:28 -0500 Subject: codec buddy pain In-Reply-To: <1194207255.2654.66.camel@cutter> References: <1194207255.2654.66.camel@cutter> Message-ID: <472E6E74.3080401@0xdeadbeef.com> seth vidal wrote: > http://lwn.net/Articles/256974/ > > Btw - in the interview they mention further integration of the webstore > into codeina/codecbuddy. If it starts looking like we're pushing closed > source software then that, imo, is when codeina gets dumped out of the > distribution. > > I don't care about needles and I don't want to ween the addicts off. Pushing or making available? Or making it easy? --Chris From skvidal at fedoraproject.org Mon Nov 5 02:45:20 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sun, 04 Nov 2007 21:45:20 -0500 Subject: codec buddy pain In-Reply-To: <472E6E74.3080401@0xdeadbeef.com> References: <1194207255.2654.66.camel@cutter> <472E6E74.3080401@0xdeadbeef.com> Message-ID: <1194230720.2654.81.camel@cutter> On Sun, 2007-11-04 at 20:14 -0500, Christopher Blizzard wrote: > seth vidal wrote: > > http://lwn.net/Articles/256974/ > > > > Btw - in the interview they mention further integration of the webstore > > into codeina/codecbuddy. If it starts looking like we're pushing closed > > source software then that, imo, is when codeina gets dumped out of the > > distribution. > > > > I don't care about needles and I don't want to ween the addicts off. > > Pushing or making available? Or making it easy? > The precedent is what I'm most worried about: we're okay having sales items for closed-source codecs in our distro what about drivers? what about closed-source application software? opera? matlab? Seriously, at what point do we draw the line and what criteria do we use to distinguish one item from the other? -sv From vnk at mkc.co.nz Mon Nov 5 03:51:48 2007 From: vnk at mkc.co.nz (Vladimir Kosovac) Date: Mon, 05 Nov 2007 16:51:48 +1300 Subject: codec buddy pain In-Reply-To: <1194230720.2654.81.camel@cutter> References: <1194207255.2654.66.camel@cutter> <472E6E74.3080401@0xdeadbeef.com> <1194230720.2654.81.camel@cutter> Message-ID: <472E9354.6070100@mkc.co.nz> seth vidal wrote: > On Sun, 2007-11-04 at 20:14 -0500, Christopher Blizzard wrote: >> seth vidal wrote: >>> http://lwn.net/Articles/256974/ >>> >>> Btw - in the interview they mention further integration of the webstore >>> into codeina/codecbuddy. If it starts looking like we're pushing closed >>> source software then that, imo, is when codeina gets dumped out of the >>> distribution. >>> >>> I don't care about needles and I don't want to ween the addicts off. >> Pushing or making available? Or making it easy? >> > > The precedent is what I'm most worried about: > > we're okay having sales items for closed-source codecs in our distro > what about drivers? > what about closed-source application software? opera? matlab? > > Seriously, at what point do we draw the line and what criteria do we use > to distinguish one item from the other? > If I may - wasn't that line drawn quite a while ago, by stating Fedora goals? Codec buddy inclusion does not leave a bad taste (although this is very arguable) in the commercial context - the fact that it directly links to and encourages the use of non-Free stuff does. Vladimir > -sv > > > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From skvidal at fedoraproject.org Mon Nov 5 04:10:28 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Sun, 04 Nov 2007 23:10:28 -0500 Subject: codec buddy pain In-Reply-To: <472E9354.6070100@mkc.co.nz> References: <1194207255.2654.66.camel@cutter> <472E6E74.3080401@0xdeadbeef.com> <1194230720.2654.81.camel@cutter> <472E9354.6070100@mkc.co.nz> Message-ID: <1194235828.2654.83.camel@cutter> On Mon, 2007-11-05 at 16:51 +1300, Vladimir Kosovac wrote: > seth vidal wrote: > > On Sun, 2007-11-04 at 20:14 -0500, Christopher Blizzard wrote: > >> seth vidal wrote: > >>> http://lwn.net/Articles/256974/ > >>> > >>> Btw - in the interview they mention further integration of the webstore > >>> into codeina/codecbuddy. If it starts looking like we're pushing closed > >>> source software then that, imo, is when codeina gets dumped out of the > >>> distribution. > >>> > >>> I don't care about needles and I don't want to ween the addicts off. > >> Pushing or making available? Or making it easy? > >> > > > > The precedent is what I'm most worried about: > > > > we're okay having sales items for closed-source codecs in our distro > > what about drivers? > > what about closed-source application software? opera? matlab? > > > > Seriously, at what point do we draw the line and what criteria do we use > > to distinguish one item from the other? > > > If I may - wasn't that line drawn quite a while ago, by stating Fedora > goals? > > Codec buddy inclusion does not leave a bad taste (although this is very > arguable) in the commercial context - the fact that it directly links to > and encourages the use of non-Free stuff does. > fair enough. codec buddy as implemented in codeina and as merged upstream includes direct links to fluendo's non-free software for sale. -sv From mclasen at redhat.com Mon Nov 5 04:26:25 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 04 Nov 2007 23:26:25 -0500 Subject: codec buddy pain Message-ID: <1194236785.4535.6.camel@localhost.localdomain> > while Codec Buddy only works with totem (ie) the kind of users who > most benefit from such features will not get it since the default > action wouldn't bring this feature up at all. Which is probably a plus if you take the position of Seth that we are just handing out clean needles here... Anyway, rhythmbox will have this support in F9, possibly also in an F8 update. From sundaram at fedoraproject.org Mon Nov 5 04:30:23 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 05 Nov 2007 10:00:23 +0530 Subject: codec buddy pain In-Reply-To: <1194236785.4535.6.camel@localhost.localdomain> References: <1194236785.4535.6.camel@localhost.localdomain> Message-ID: <472E9C5F.9060701@fedoraproject.org> Matthias Clasen wrote: >> while Codec Buddy only works with totem (ie) the kind of users who >> most benefit from such features will not get it since the default >> action wouldn't bring this feature up at all. > > Which is probably a plus if you take the position of Seth that we are > just handing out clean needles here... > > Anyway, rhythmbox will have this support in F9, possibly also in an F8 > update. I personally think for individual music files, totem might be a better default choice than rhythmbox. Anyway here is a bug report from a end user. https://bugzilla.redhat.com/show_bug.cgi?id=366101 Rahul From kwade at redhat.com Mon Nov 5 15:14:26 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 05 Nov 2007 07:14:26 -0800 Subject: codec buddy pain In-Reply-To: <472E9354.6070100@mkc.co.nz> References: <1194207255.2654.66.camel@cutter> <472E6E74.3080401@0xdeadbeef.com> <1194230720.2654.81.camel@cutter> <472E9354.6070100@mkc.co.nz> Message-ID: <1194275666.4307.198.camel@erato.phig.org> On Mon, 2007-11-05 at 16:51 +1300, Vladimir Kosovac wrote: > it ... encourages the use of non-Free stuff does. No that I recall. Point out the specific language that *encourages* the use of non-free software. I'm in favor of the harm reduction stand point and the comparison to needle exchange programs. It doesn't mean I encourage addicts to shoot heroin. It means I encourage them to shoot with clean needles so as to not spread infection. They have the right to mess up their own bodies, but should not spread disease (and associated public health risk) with it. - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org 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 Mon Nov 5 15:20:02 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 05 Nov 2007 07:20:02 -0800 Subject: codec buddy pain In-Reply-To: <1194207255.2654.66.camel@cutter> References: <1194207255.2654.66.camel@cutter> Message-ID: <1194276002.4307.204.camel@erato.phig.org> On Sun, 2007-11-04 at 15:14 -0500, seth vidal wrote: > http://lwn.net/Articles/256974/ > > Btw - in the interview they mention further integration of the webstore > into codeina/codecbuddy. If it starts looking like we're pushing closed > source software then that, imo, is when codeina gets dumped out of the > distribution. Agreed; we should not be shipping a shill. > I don't care about needles and I don't want to ween the addicts off. People who build their houses on the top of the hill so the addicts in the valley don't steal from them are just delaying the inevitable. We can remove ourselves from the problem entirely, but it doesn't make the problem go away, and it doesn't stop it from growing larger (again) to engulf us. I feel we've been sticking our heads in the sand long enough. Even if CodecBuddy falls flat on its face, at least it falls forward and causes some movement. - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org 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 skvidal at fedoraproject.org Mon Nov 5 15:32:06 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 05 Nov 2007 10:32:06 -0500 Subject: codec buddy pain In-Reply-To: <1194276002.4307.204.camel@erato.phig.org> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> Message-ID: <1194276726.2654.102.camel@cutter> On Mon, 2007-11-05 at 07:20 -0800, Karsten Wade wrote: > On Sun, 2007-11-04 at 15:14 -0500, seth vidal wrote: > > http://lwn.net/Articles/256974/ > > > > Btw - in the interview they mention further integration of the webstore > > into codeina/codecbuddy. If it starts looking like we're pushing closed > > source software then that, imo, is when codeina gets dumped out of the > > distribution. > > Agreed; we should not be shipping a shill. > > > I don't care about needles and I don't want to ween the addicts off. > > People who build their houses on the top of the hill so the addicts in > the valley don't steal from them are just delaying the inevitable. > > We can remove ourselves from the problem entirely, but it doesn't make > the problem go away, and it doesn't stop it from growing larger (again) > to engulf us. If that's the case then we should just give up on this quixotic goal of having a pure-free-software distro and start talking to companies for how they'd like us to provide their closed-source packages and how to tie a webstore frontend into yum. -sv From tchung at fedoraproject.org Mon Nov 5 15:41:49 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Mon, 5 Nov 2007 07:41:49 -0800 Subject: codec buddy pain In-Reply-To: <1194275666.4307.198.camel@erato.phig.org> References: <1194207255.2654.66.camel@cutter> <472E6E74.3080401@0xdeadbeef.com> <1194230720.2654.81.camel@cutter> <472E9354.6070100@mkc.co.nz> <1194275666.4307.198.camel@erato.phig.org> Message-ID: <369bce3b0711050741k60374c50x644a75154b5990e1@mail.gmail.com> On 11/5/07, Karsten Wade wrote: > I'm in favor of the harm reduction stand point and the comparison to > needle exchange programs. It doesn't mean I encourage addicts to shoot > heroin. It means I encourage them to shoot with clean needles so as to > not spread infection. They have the right to mess up their own bodies, > but should not spread disease (and associated public health risk) with > it. > > - Karsten > -- > Karsten Wade, Developer Community Mgr. > Dev Fu : http://developer.redhatmagazine.com > Fedora : http://quaid.fedorapeople.org > gpg key : AD0E0C41 +1 Thank you for making a excellent point. -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From kwade at redhat.com Mon Nov 5 17:50:24 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 05 Nov 2007 09:50:24 -0800 Subject: codec buddy pain In-Reply-To: <1194276726.2654.102.camel@cutter> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> Message-ID: <1194285024.4307.236.camel@erato.phig.org> On Mon, 2007-11-05 at 10:32 -0500, seth vidal wrote: > Swiftian solutions are good for drawing attention to a problem, but not for providing real world solutions that we can make work. - Karsten, with 30 rejection letters for his "How to Cook Babies" cookbook -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org 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 skvidal at fedoraproject.org Mon Nov 5 18:00:35 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 05 Nov 2007 13:00:35 -0500 Subject: codec buddy pain In-Reply-To: <1194285024.4307.236.camel@erato.phig.org> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <1194285024.4307.236.camel@erato.phig.org> Message-ID: <1194285635.2654.107.camel@cutter> On Mon, 2007-11-05 at 09:50 -0800, Karsten Wade wrote: > On Mon, 2007-11-05 at 10:32 -0500, seth vidal wrote: > > > > > Swiftian solutions are good for drawing attention to a problem, but not > for providing real world solutions that we can make work. > > - Karsten, with 30 rejection letters for his "How to Cook Babies" > cookbook Except that it is a good question. Are we going to stop being a foss-only distribution for things like this? Do we want to start pushing closed-source printer drivers? Closed source kernel drivers (hahahhahahahahaha)? Where do you think the line should be drawn? -sv From luis at tieguy.org Mon Nov 5 18:05:39 2007 From: luis at tieguy.org (Luis Villa) Date: Mon, 5 Nov 2007 13:05:39 -0500 Subject: codec buddy pain In-Reply-To: <1194276726.2654.102.camel@cutter> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> Message-ID: <2cb10c440711051005ma4b921bl3b55d1bef59e2db1@mail.gmail.com> On 11/5/07, seth vidal wrote: > > On Mon, 2007-11-05 at 07:20 -0800, Karsten Wade wrote: > > On Sun, 2007-11-04 at 15:14 -0500, seth vidal wrote: > > > http://lwn.net/Articles/256974/ > > > > > > Btw - in the interview they mention further integration of the webstore > > > into codeina/codecbuddy. If it starts looking like we're pushing closed > > > source software then that, imo, is when codeina gets dumped out of the > > > distribution. > > > > Agreed; we should not be shipping a shill. > > > > > I don't care about needles and I don't want to ween the addicts off. > > > > People who build their houses on the top of the hill so the addicts in > > the valley don't steal from them are just delaying the inevitable. > > > > We can remove ourselves from the problem entirely, but it doesn't make > > the problem go away, and it doesn't stop it from growing larger (again) > > to engulf us. > > If that's the case then we should just give up on this quixotic goal of > having a pure-free-software distro and start talking to companies for > how they'd like us to provide their closed-source packages and how to > tie a webstore frontend into yum. I'm not sure if these lines are useful to you, Seth, but there are two tests for me that make me slightly less uncomfortable with these plugins than with other things: (1) is it low in the stack? if the non-free bit is low in the stack (e.g., X drivers) you're at the mercy of the vendor- all of your freedom is at risk if they go away. If the non-free bit is high in the stack, you still have the majority of your freedom intact if the non-freedom gets screwed up somehow, and you can more easilly work to replace it. (Here, the bits are very high in the stack, and very easy to replace- we'll have free implementations the very day the patents expire. But of course we should resist moving the dep deeper into the stack- no system sounds shipped as mp3, for example.) (2) does it create non-free data, or merely allow consumption of external non-free data? If we allow people to bring their stuff with them (or import it from the non-free world) we're clearly helping them move towards freedom. If we're helping them create non-free data, we're in a different boat- that is a step back. (You might argue that it is two steps forward one step back, but it is still different than merely helping consume legacy media.) [Tangentially, I feel comfortable saying that mp3 is not system-critical, but exactly where in the stack flash is is a very interesting question at this point, given how much of the web depends on it. And the firefox Fedora ships *tries* to download flash, even if it fails.] [Also, tangent: Fedora should definitely use 'legacy media' where ever possible to describe mp3s and other proprietary formats.] Luis From skvidal at fedoraproject.org Mon Nov 5 18:11:40 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 05 Nov 2007 13:11:40 -0500 Subject: codec buddy pain In-Reply-To: <2cb10c440711051005ma4b921bl3b55d1bef59e2db1@mail.gmail.com> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <2cb10c440711051005ma4b921bl3b55d1bef59e2db1@mail.gmail.com> Message-ID: <1194286300.2654.114.camel@cutter> On Mon, 2007-11-05 at 13:05 -0500, Luis Villa wrote: > I'm not sure if these lines are useful to you, Seth, but there are two > tests for me that make me slightly less uncomfortable with these > plugins than with other things: > > (1) is it low in the stack? if the non-free bit is low in the stack > (e.g., X drivers) you're at the mercy of the vendor- all of your > freedom is at risk if they go away. If the non-free bit is high in the > stack, you still have the majority of your freedom intact if the > non-freedom gets screwed up somehow, and you can more easilly work to > replace it. (Here, the bits are very high in the stack, and very easy > to replace- we'll have free implementations the very day the patents > expire. But of course we should resist moving the dep deeper into the > stack- no system sounds shipped as mp3, for example.) > > (2) does it create non-free data, or merely allow consumption of > external non-free data? If we allow people to bring their stuff with > them (or import it from the non-free world) we're clearly helping them > move towards freedom. If we're helping them create non-free data, > we're in a different boat- that is a step back. (You might argue that > it is two steps forward one step back, but it is still different than > merely helping consume legacy media.) okay, this confuses me a bit. Is the data non-free? I didn't even think that an encrypted pdf is non-free. The data could be free, just the format is not. If you mean does it help the user create non-free formats then I think we should ask ourselves what's the point of the mp3 plugin? I think it's pretty clear - the whole point of the mp3 plugin to help the user interact with the ipod-based world. That, at least to me, means both get-content-from and send-content-to that world. Converting to ogg is not good enough. > > [Tangentially, I feel comfortable saying that mp3 is not > system-critical, but exactly where in the stack flash is is a very > interesting question at this point, given how much of the web depends > on it. And the firefox Fedora ships *tries* to download flash, even if > it fails.] > How about printer drivers? > [Also, tangent: Fedora should definitely use 'legacy media' where ever > possible to describe mp3s and other proprietary formats.] And then when the patents expire we get to say, what? "No longer legacy media"? -sv From blizzard at 0xdeadbeef.com Mon Nov 5 19:04:17 2007 From: blizzard at 0xdeadbeef.com (Christopher Blizzard) Date: Mon, 05 Nov 2007 14:04:17 -0500 Subject: codec buddy pain In-Reply-To: <1194276726.2654.102.camel@cutter> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> Message-ID: <472F6931.4030701@0xdeadbeef.com> seth vidal wrote: > If that's the case then we should just give up on this quixotic goal of > having a pure-free-software distro and start talking to companies for > how they'd like us to provide their closed-source packages and how to > tie a webstore frontend into yum. yumgate! woo! In all seriousness I don't think that there are a lot of instances where we would be willing to do something like what we've done in this case. I'm happy with inconsistency, as long we're transparent about it. In this case it's just because there's no other legal way to do it. We can't even ship the free versions because of patent concerns. --Chris From skvidal at fedoraproject.org Mon Nov 5 19:00:39 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 05 Nov 2007 14:00:39 -0500 Subject: codec buddy pain In-Reply-To: <472F6931.4030701@0xdeadbeef.com> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> Message-ID: <1194289239.2654.116.camel@cutter> On Mon, 2007-11-05 at 14:04 -0500, Christopher Blizzard wrote: > seth vidal wrote: > > If that's the case then we should just give up on this quixotic goal of > > having a pure-free-software distro and start talking to companies for > > how they'd like us to provide their closed-source packages and how to > > tie a webstore frontend into yum. > > yumgate! woo! > > In all seriousness I don't think that there are a lot of instances where > we would be willing to do something like what we've done in this case. > I'm happy with inconsistency, as long we're transparent about it. > > In this case it's just because there's no other legal way to do it. We > can't even ship the free versions because of patent concerns. > This is what I'm looking for here. I'd like to be able to say something that kinda-sorta makes sense for reasons to say no to money from some vendor to put an ad for their software in the distro. -sv From blizzard at 0xdeadbeef.com Mon Nov 5 19:07:08 2007 From: blizzard at 0xdeadbeef.com (Christopher Blizzard) Date: Mon, 05 Nov 2007 14:07:08 -0500 Subject: codec buddy pain In-Reply-To: <1194286300.2654.114.camel@cutter> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <2cb10c440711051005ma4b921bl3b55d1bef59e2db1@mail.gmail.com> <1194286300.2654.114.camel@cutter> Message-ID: <472F69DC.8030506@0xdeadbeef.com> seth vidal wrote: > >> [Also, tangent: Fedora should definitely use 'legacy media' where ever >> possible to describe mp3s and other proprietary formats.] > > And then when the patents expire we get to say, what? "No longer legacy > media"? Or "encumbered media" since that's the real problem here. --Chris From blizzard at 0xdeadbeef.com Mon Nov 5 19:21:11 2007 From: blizzard at 0xdeadbeef.com (Christopher Blizzard) Date: Mon, 05 Nov 2007 14:21:11 -0500 Subject: codec buddy pain In-Reply-To: <1194289239.2654.116.camel@cutter> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> Message-ID: <472F6D27.6020701@0xdeadbeef.com> seth vidal wrote: > On Mon, 2007-11-05 at 14:04 -0500, Christopher Blizzard wrote: >> seth vidal wrote: >>> If that's the case then we should just give up on this quixotic goal of >>> having a pure-free-software distro and start talking to companies for >>> how they'd like us to provide their closed-source packages and how to >>> tie a webstore frontend into yum. >> yumgate! woo! >> >> In all seriousness I don't think that there are a lot of instances where >> we would be willing to do something like what we've done in this case. >> I'm happy with inconsistency, as long we're transparent about it. >> >> In this case it's just because there's no other legal way to do it. We >> can't even ship the free versions because of patent concerns. >> > > This is what I'm looking for here. I'd like to be able to say something > that kinda-sorta makes sense for reasons to say no to money from some > vendor to put an ad for their software in the distro. Hmm. Trying to firm up the message here. For me this was all about consuming content. The basic problem we're trying to solve for end users is that there's a lot of content on the web that requires access to patent-encumbered code. In order to keep Fedora relevant for the real world, we felt that we needed to make an exception for end users to legally obtain codecs to view encumbered content. --Chris From jwboyer at gmail.com Mon Nov 5 19:37:32 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 5 Nov 2007 13:37:32 -0600 Subject: codec buddy pain In-Reply-To: <472F6D27.6020701@0xdeadbeef.com> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> Message-ID: <20071105133732.0677e456@weaponx> On Mon, 05 Nov 2007 14:21:11 -0500 Christopher Blizzard wrote: > seth vidal wrote: > > On Mon, 2007-11-05 at 14:04 -0500, Christopher Blizzard wrote: > >> seth vidal wrote: > >>> If that's the case then we should just give up on this quixotic goal of > >>> having a pure-free-software distro and start talking to companies for > >>> how they'd like us to provide their closed-source packages and how to > >>> tie a webstore frontend into yum. > >> yumgate! woo! > >> > >> In all seriousness I don't think that there are a lot of instances where > >> we would be willing to do something like what we've done in this case. > >> I'm happy with inconsistency, as long we're transparent about it. > >> > >> In this case it's just because there's no other legal way to do it. We > >> can't even ship the free versions because of patent concerns. > >> > > > > This is what I'm looking for here. I'd like to be able to say something > > that kinda-sorta makes sense for reasons to say no to money from some > > vendor to put an ad for their software in the distro. > > Hmm. Trying to firm up the message here. > > For me this was all about consuming content. The basic problem we're > trying to solve for end users is that there's a lot of content on the > web that requires access to patent-encumbered code. In order to keep > Fedora relevant for the real world, we felt that we needed to make an > exception for end users to legally obtain codecs to view encumbered content. Wait... what prevented users from legally obtaining codecs from fluendo before? Nothing from what I remember... josh From skvidal at fedoraproject.org Mon Nov 5 20:20:21 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 05 Nov 2007 15:20:21 -0500 Subject: codec buddy pain In-Reply-To: <20071105133732.0677e456@weaponx> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> Message-ID: <1194294021.2654.123.camel@cutter> On Mon, 2007-11-05 at 13:37 -0600, Josh Boyer wrote: > On Mon, 05 Nov 2007 14:21:11 -0500 > Christopher Blizzard wrote: > > > seth vidal wrote: > > > On Mon, 2007-11-05 at 14:04 -0500, Christopher Blizzard wrote: > > >> seth vidal wrote: > > >>> If that's the case then we should just give up on this quixotic goal of > > >>> having a pure-free-software distro and start talking to companies for > > >>> how they'd like us to provide their closed-source packages and how to > > >>> tie a webstore frontend into yum. > > >> yumgate! woo! > > >> > > >> In all seriousness I don't think that there are a lot of instances where > > >> we would be willing to do something like what we've done in this case. > > >> I'm happy with inconsistency, as long we're transparent about it. > > >> > > >> In this case it's just because there's no other legal way to do it. We > > >> can't even ship the free versions because of patent concerns. > > >> > > > > > > This is what I'm looking for here. I'd like to be able to say something > > > that kinda-sorta makes sense for reasons to say no to money from some > > > vendor to put an ad for their software in the distro. > > > > Hmm. Trying to firm up the message here. > > > > For me this was all about consuming content. The basic problem we're > > trying to solve for end users is that there's a lot of content on the > > web that requires access to patent-encumbered code. In order to keep > > Fedora relevant for the real world, we felt that we needed to make an > > exception for end users to legally obtain codecs to view encumbered content. > > Wait... what prevented users from legally obtaining codecs from fluendo > before? Nothing from what I remember... > nothing, it was just not trivial nor contextual to trying to use those formats. That's what codeina has done - but it's brought something else into relief. We have this software in the distro now that a big portion of is providing a window for advertisements for closed-source codecs from another company. That's the precedent that concerns me. -sv From gdk at redhat.com Mon Nov 5 20:28:14 2007 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Mon, 5 Nov 2007 15:28:14 -0500 (EST) Subject: codec buddy pain In-Reply-To: <1194294021.2654.123.camel@cutter> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> Message-ID: On Mon, 5 Nov 2007, seth vidal wrote: > That's what codeina has done - but it's brought something else into > relief. We have this software in the distro now that a big portion of is > providing a window for advertisements for closed-source codecs from > another company. > > That's the precedent that concerns me. So which is the worse scenario? 1. Providing no support at all to MP3 users? 2. Encouraging MP3 users to break the law? 3. Pointing MP3 users to a legal solution that privileges a particular vendor -- with the possibility of including other vendors later? There are no easy answers here. If there we're, we'd have solved the problem by now. --g -- Greg DeKoenigsberg Community Development Manager Red Hat, Inc. :: 1-919-754-4255 "To whomsoever much hath been given... ...from him much shall be asked" From jkeating at redhat.com Mon Nov 5 20:36:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 5 Nov 2007 15:36:29 -0500 Subject: codec buddy pain In-Reply-To: References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> Message-ID: <20071105153629.17e84e91@redhat.com> On Mon, 5 Nov 2007 15:28:14 -0500 (EST) Greg DeKoenigsberg wrote: > 1. Providing no support at all to MP3 users? > > 2. Encouraging MP3 users to break the law? > > 3. Pointing MP3 users to a legal solution that privileges a > particular vendor -- with the possibility of including other vendors > later? 4. Point to a Fedora controlled URL that has a list of current providers of legal software to play the content. Something that is controlled by Fedora (Board) and clearly not just a commercial for $COMPANY. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at gmail.com Mon Nov 5 20:38:23 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 5 Nov 2007 14:38:23 -0600 Subject: codec buddy pain In-Reply-To: <1194294021.2654.123.camel@cutter> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> Message-ID: <20071105143823.62a9f036@weaponx> On Mon, 05 Nov 2007 15:20:21 -0500 seth vidal wrote: > > On Mon, 2007-11-05 at 13:37 -0600, Josh Boyer wrote: > > On Mon, 05 Nov 2007 14:21:11 -0500 > > Christopher Blizzard wrote: > > > > > seth vidal wrote: > > > > On Mon, 2007-11-05 at 14:04 -0500, Christopher Blizzard wrote: > > > >> seth vidal wrote: > > > >>> If that's the case then we should just give up on this quixotic goal of > > > >>> having a pure-free-software distro and start talking to companies for > > > >>> how they'd like us to provide their closed-source packages and how to > > > >>> tie a webstore frontend into yum. > > > >> yumgate! woo! > > > >> > > > >> In all seriousness I don't think that there are a lot of instances where > > > >> we would be willing to do something like what we've done in this case. > > > >> I'm happy with inconsistency, as long we're transparent about it. > > > >> > > > >> In this case it's just because there's no other legal way to do it. We > > > >> can't even ship the free versions because of patent concerns. > > > >> > > > > > > > > This is what I'm looking for here. I'd like to be able to say something > > > > that kinda-sorta makes sense for reasons to say no to money from some > > > > vendor to put an ad for their software in the distro. > > > > > > Hmm. Trying to firm up the message here. > > > > > > For me this was all about consuming content. The basic problem we're > > > trying to solve for end users is that there's a lot of content on the > > > web that requires access to patent-encumbered code. In order to keep > > > Fedora relevant for the real world, we felt that we needed to make an > > > exception for end users to legally obtain codecs to view encumbered content. > > > > Wait... what prevented users from legally obtaining codecs from fluendo > > before? Nothing from what I remember... > > > > nothing, it was just not trivial nor contextual to trying to use those > formats. > > That's what codeina has done - but it's brought something else into > relief. We have this software in the distro now that a big portion of is > providing a window for advertisements for closed-source codecs from > another company. > > That's the precedent that concerns me. Yes, exactly. Chris' statement earlier seemed to imply we did something in F8 to make it technically possible to get legal codecs, where that really isn't the case. It was just made easier. josh From skvidal at fedoraproject.org Mon Nov 5 20:37:48 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 05 Nov 2007 15:37:48 -0500 Subject: codec buddy pain In-Reply-To: References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> Message-ID: <1194295068.2654.129.camel@cutter> On Mon, 2007-11-05 at 15:28 -0500, Greg DeKoenigsberg wrote: > On Mon, 5 Nov 2007, seth vidal wrote: > > > That's what codeina has done - but it's brought something else into > > relief. We have this software in the distro now that a big portion of is > > providing a window for advertisements for closed-source codecs from > > another company. > > > > That's the precedent that concerns me. > > So which is the worse scenario? > > 1. Providing no support at all to MP3 users? > > 2. Encouraging MP3 users to break the law? > > 3. Pointing MP3 users to a legal solution that privileges a particular > vendor -- with the possibility of including other vendors later? > > There are no easy answers here. If there we're, we'd have solved the > problem by now. imo it would be best to provide mp3 decode support via codeina, only and not provide the for-pay links to the other codecs. -sv From tibbs at math.uh.edu Mon Nov 5 20:39:15 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 Nov 2007 14:39:15 -0600 Subject: codec buddy pain In-Reply-To: <20071105153629.17e84e91@redhat.com> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> 4. Point to a Fedora controlled URL that has a list of current JK> providers of legal software to play the content. Something that JK> is controlled by Fedora (Board) and clearly not just a commercial JK> for $COMPANY. Is that not what's being done? I thought that codec buddy was accepted only on the condition that it directed users to a fp.org web page that we could control. - J< From gdk at redhat.com Mon Nov 5 20:43:28 2007 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Mon, 5 Nov 2007 15:43:28 -0500 (EST) Subject: codec buddy pain In-Reply-To: <20071105153629.17e84e91@redhat.com> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> Message-ID: On Mon, 5 Nov 2007, Jesse Keating wrote: > 4. Point to a Fedora controlled URL that has a list of current > providers of legal software to play the content. Something that is > controlled by Fedora (Board) and clearly not just a commercial for > $COMPANY. Yes, Jesse. You're exactly right. Even if it creates an extra step for the user. The problem, IIRC, is that the Fluendo folks did the work and we are consuming the upstream code without modification. Is this correct? Is this literally a matter of changing URLs in Codeina -- a %config change in our RPM? Does anyone know the answer to this? --g -- Greg DeKoenigsberg Community Development Manager Red Hat, Inc. :: 1-919-754-4255 "To whomsoever much hath been given... ...from him much shall be asked" From jkeating at redhat.com Mon Nov 5 20:54:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 5 Nov 2007 15:54:47 -0500 Subject: codec buddy pain In-Reply-To: References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> Message-ID: <20071105155447.6871fc20@redhat.com> On 05 Nov 2007 14:39:15 -0600 Jason L Tibbitts III wrote: > Is that not what's being done? Not currently. > I thought that codec buddy was > accepted only on the condition that it directed users to a fp.org web > page that we could control. It currently opens a window and displays content from an xml file on the local file system. Then you can click from that window and it will take you to the site configured. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- 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 Mon Nov 5 20:56:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 5 Nov 2007 15:56:45 -0500 Subject: codec buddy pain In-Reply-To: References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> Message-ID: <20071105155645.4b727e8b@redhat.com> On Mon, 5 Nov 2007 15:43:28 -0500 (EST) Greg DeKoenigsberg wrote: > Yes, Jesse. You're exactly right. Even if it creates an extra step > for the user. > > The problem, IIRC, is that the Fluendo folks did the work and we are > consuming the upstream code without modification. Is this correct? As best as I can tell. > Is this literally a matter of changing URLs in Codeina -- a %config > change in our RPM? Does anyone know the answer to this? I don't know that the app can take you directly to a website. It currently loads a window and populates it from a .xml file on the file system. I distinctly remember raising this concern a while ago. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at fedoraproject.org Mon Nov 5 20:57:51 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 05 Nov 2007 15:57:51 -0500 Subject: codec buddy pain In-Reply-To: References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> Message-ID: <1194296271.2654.131.camel@cutter> On Mon, 2007-11-05 at 15:43 -0500, Greg DeKoenigsberg wrote: > On Mon, 5 Nov 2007, Jesse Keating wrote: > > > 4. Point to a Fedora controlled URL that has a list of current > > providers of legal software to play the content. Something that is > > controlled by Fedora (Board) and clearly not just a commercial for > > $COMPANY. > > Yes, Jesse. You're exactly right. Even if it creates an extra step for > the user. > > The problem, IIRC, is that the Fluendo folks did the work and we are > consuming the upstream code without modification. Is this correct? Is > this literally a matter of changing URLs in Codeina -- a %config change in > our RPM? Does anyone know the answer to this? mostly a change to an xml file in codeina to purge out the other references. we also have to have something sensible to repoint it to. -sv From mclasen at redhat.com Mon Nov 5 21:21:08 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 05 Nov 2007 16:21:08 -0500 Subject: codec buddy pain In-Reply-To: References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> Message-ID: <1194297668.5020.1.camel@localhost.localdomain> On Mon, 2007-11-05 at 15:43 -0500, Greg DeKoenigsberg wrote: > On Mon, 5 Nov 2007, Jesse Keating wrote: > > > 4. Point to a Fedora controlled URL that has a list of current > > providers of legal software to play the content. Something that is > > controlled by Fedora (Board) and clearly not just a commercial for > > $COMPANY. > > Yes, Jesse. You're exactly right. Even if it creates an extra step for > the user. > > The problem, IIRC, is that the Fluendo folks did the work and we are > consuming the upstream code without modification. Is this correct? Is > this literally a matter of changing URLs in Codeina -- a %config change in > our RPM? Does anyone know the answer to this? > No, this is not correct. We entirely control the initial dialog that explains the situation (what has been dubbed "the sermon" in early reviews) and contains the link to the fedora wiki, and we have changed the wording of that dialog in the run-up to F8, based on feedback from people from this list. From mclasen at redhat.com Mon Nov 5 21:22:16 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 05 Nov 2007 16:22:16 -0500 Subject: codec buddy pain In-Reply-To: <1194296271.2654.131.camel@cutter> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> <1194296271.2654.131.camel@cutter> Message-ID: <1194297736.5020.3.camel@localhost.localdomain> On Mon, 2007-11-05 at 15:57 -0500, seth vidal wrote: > On Mon, 2007-11-05 at 15:43 -0500, Greg DeKoenigsberg wrote: > > On Mon, 5 Nov 2007, Jesse Keating wrote: > > > > > 4. Point to a Fedora controlled URL that has a list of current > > > providers of legal software to play the content. Something that is > > > controlled by Fedora (Board) and clearly not just a commercial for > > > $COMPANY. > > > > Yes, Jesse. You're exactly right. Even if it creates an extra step for > > the user. > > > > The problem, IIRC, is that the Fluendo folks did the work and we are > > consuming the upstream code without modification. Is this correct? Is > > this literally a matter of changing URLs in Codeina -- a %config change in > > our RPM? Does anyone know the answer to this? > > mostly a change to an xml file in codeina to purge out the other > references. > > we also have to have something sensible to repoint it to. You mean more sensible than www.fedoraproject.org/CodecBuddy ? I really don't get it; that page was written by board people, in response to feedback from the board. What more do you want ? From gdk at redhat.com Mon Nov 5 21:31:33 2007 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Mon, 5 Nov 2007 16:31:33 -0500 (EST) Subject: codec buddy pain In-Reply-To: <1194297736.5020.3.camel@localhost.localdomain> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> <1194296271.2654.131.camel@cutter> <1194297736.5020.3.camel@localhost.localdomain> Message-ID: On Mon, 5 Nov 2007, Matthias Clasen wrote: > You mean more sensible than www.fedoraproject.org/CodecBuddy ? > I really don't get it; that page was written by board people, in > response to feedback from the board. What more do you want ? Maybe /me needs to stop talking out of his ass, and look at how CodecBuddy is actually working. :/ --g -- Greg DeKoenigsberg Community Development Manager Red Hat, Inc. :: 1-919-754-4255 "To whomsoever much hath been given... ...from him much shall be asked" From skvidal at fedoraproject.org Mon Nov 5 21:52:42 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 05 Nov 2007 16:52:42 -0500 Subject: codec buddy pain In-Reply-To: References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> <1194296271.2654.131.camel@cutter> <1194297736.5020.3.camel@localhost.localdomain> Message-ID: <1194299562.2654.161.camel@cutter> On Mon, 2007-11-05 at 16:31 -0500, Greg DeKoenigsberg wrote: > On Mon, 5 Nov 2007, Matthias Clasen wrote: > > > You mean more sensible than www.fedoraproject.org/CodecBuddy ? > > I really don't get it; that page was written by board people, in > > response to feedback from the board. What more do you want ? > > Maybe /me needs to stop talking out of his ass, and look at how CodecBuddy > is actually working. :/ - load totem - attempt to open an mp3 - get taken to a popup window that mentions the evils of patents, briefly - get prompted to install the mp3 decoder and/or buy a full system of decoder/encoders for mp3s or - load totem - attempt to open a wmv file - get taken to a popup window that mentions the evils of patents/formats, briefly - get prompted to buy some codecs from fluendo - click on some you want - get taken to fluendo's website to buy them You can see it for yourself here: http://skvidal.fedorapeople.org/hidden/codeina/ -sv From blizzard at 0xdeadbeef.com Mon Nov 5 22:06:21 2007 From: blizzard at 0xdeadbeef.com (Christopher Blizzard) Date: Mon, 05 Nov 2007 17:06:21 -0500 Subject: codec buddy pain In-Reply-To: <20071105143823.62a9f036@weaponx> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105143823.62a9f036@weaponx> Message-ID: <472F93DD.5090903@0xdeadbeef.com> Josh Boyer wrote: > Yes, exactly. Chris' statement earlier seemed to imply we did > something in F8 to make it technically possible to get legal codecs, > where that really isn't the case. It was just made easier. > Easier is important. But that's not the point. I think that Seth's worried that we're using our valuable real estate to promote a company. A special exemption, if you will. And I'm fine with it. If there were another company you could get the same stuff from I would suggest that we add them as an option. But we're not there right now. --Chris From skvidal at fedoraproject.org Mon Nov 5 22:11:22 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 05 Nov 2007 17:11:22 -0500 Subject: codec buddy pain In-Reply-To: <472F93DD.5090903@0xdeadbeef.com> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105143823.62a9f036@weaponx> <472F93DD.5090903@0xdeadbeef.com> Message-ID: <1194300682.2654.166.camel@cutter> On Mon, 2007-11-05 at 17:06 -0500, Christopher Blizzard wrote: > Josh Boyer wrote: > > Yes, exactly. Chris' statement earlier seemed to imply we did > > something in F8 to make it technically possible to get legal codecs, > > where that really isn't the case. It was just made easier. > > > Easier is important. But that's not the point. I think that Seth's > worried that we're using our valuable real estate to promote a company. > A special exemption, if you will. And I'm fine with it. If there were > another company you could get the same stuff from I would suggest that > we add them as an option. But we're not there right now. > My concern is the next time a company comes to us with the same. Maybe they want a package in the distro which just installs a yum plugin and a .repo file. The plugin pops up a message everytime you run yum in interactive which says "don't you need bitkeeper for all your software development needs? Press 'yes' here to have bitkeeper installed for you" And then it goes out to some repo and installs it for them. Now, if this were a 'package' of some kind it might get rejected - though there's no reason in the packaging guidelines to do so. However, if the company behind bitkeeper came to us and agreed to give fedora/red hat a big lump of cash in exchange for us to include this package, by default, in the distro I want to be sure we have a reason/way to say no. That's what I'm worried about. unrelated: the above is an interesting use case for yum plugins :) -sv From notting at redhat.com Mon Nov 5 22:28:49 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 5 Nov 2007 17:28:49 -0500 Subject: codec buddy pain In-Reply-To: <1194297668.5020.1.camel@localhost.localdomain> References: <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> <1194297668.5020.1.camel@localhost.localdomain> Message-ID: <20071105222849.GB18511@nostromo.devel.redhat.com> Matthias Clasen (mclasen at redhat.com) said: > No, this is not correct. We entirely control the initial dialog that > explains the situation (what has been dubbed "the sermon" in early > reviews) and contains the link to the fedora wiki, and we have changed > the wording of that dialog in the run-up to F8, based on feedback from > people from this list. In fact, I wonder if architecturally in the future it's better to just pull the distro dialogs out of codeina entirely, and reverse the execution order (the plugin install helper calls the $distro_code, which then has the option of calling codeina proper.) Bill From blizzard at 0xdeadbeef.com Mon Nov 5 23:01:10 2007 From: blizzard at 0xdeadbeef.com (Christopher Blizzard) Date: Mon, 05 Nov 2007 18:01:10 -0500 Subject: codec buddy pain In-Reply-To: <1194300682.2654.166.camel@cutter> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105143823.62a9f036@weaponx> <472F93DD.5090903@0xdeadbeef.com> <1194300682.2654.166.camel@cutter> Message-ID: <472FA0B6.6040402@0xdeadbeef.com> seth vidal wrote: > On Mon, 2007-11-05 at 17:06 -0500, Christopher Blizzard wrote: > >> Josh Boyer wrote: >> >>> Yes, exactly. Chris' statement earlier seemed to imply we did >>> something in F8 to make it technically possible to get legal codecs, >>> where that really isn't the case. It was just made easier. >>> >>> >> Easier is important. But that's not the point. I think that Seth's >> worried that we're using our valuable real estate to promote a company. >> A special exemption, if you will. And I'm fine with it. If there were >> another company you could get the same stuff from I would suggest that >> we add them as an option. But we're not there right now. >> >> > > My concern is the next time a company comes to us with the same. > > Maybe they want a package in the distro which just installs a yum plugin > and a .repo file. > > The plugin pops up a message everytime you run yum in interactive which > says "don't you need bitkeeper for all your software development needs? > Press 'yes' here to have bitkeeper installed for you" And then it goes > out to some repo and installs it for them. > > Now, if this were a 'package' of some kind it might get rejected - > though there's no reason in the packaging guidelines to do so. However, > if the company behind bitkeeper came to us and agreed to give fedora/red > hat a big lump of cash in exchange for us to include this package, by > default, in the distro I want to be sure we have a reason/way to say no. > > I feel like I understand your concerns. I think that we would evaluate such a thing and say yes or no. A construct for evaluating it might be something like: 1. Does it serve a core need for users? 2. Is there a legally available free software alternative or different hardware the user can use? 3. Does it make us throw up in our mouths a little bit? OK. That last one is over the top. But that's part of how I would evaluate this. --Chris From stickster at gmail.com Tue Nov 6 00:27:19 2007 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 05 Nov 2007 19:27:19 -0500 Subject: codec buddy pain In-Reply-To: <1194300682.2654.166.camel@cutter> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105143823.62a9f036@weaponx> <472F93DD.5090903@0xdeadbeef.com> <1194300682.2654.166.camel@cutter> Message-ID: <1194308839.30261.45.camel@localhost.localdomain> On Mon, 2007-11-05 at 17:11 -0500, seth vidal wrote: > On Mon, 2007-11-05 at 17:06 -0500, Christopher Blizzard wrote: > > Josh Boyer wrote: > > > Yes, exactly. Chris' statement earlier seemed to imply we did > > > something in F8 to make it technically possible to get legal codecs, > > > where that really isn't the case. It was just made easier. > > > > > Easier is important. But that's not the point. I think that Seth's > > worried that we're using our valuable real estate to promote a company. > > A special exemption, if you will. And I'm fine with it. If there were > > another company you could get the same stuff from I would suggest that > > we add them as an option. But we're not there right now. > > > > My concern is the next time a company comes to us with the same. > > Maybe they want a package in the distro which just installs a yum plugin > and a .repo file. > > The plugin pops up a message everytime you run yum in interactive which > says "don't you need bitkeeper for all your software development needs? > Press 'yes' here to have bitkeeper installed for you" And then it goes > out to some repo and installs it for them. > > Now, if this were a 'package' of some kind it might get rejected - > though there's no reason in the packaging guidelines to do so. However, > if the company behind bitkeeper came to us and agreed to give fedora/red > hat a big lump of cash in exchange for us to include this package, by > default, in the distro I want to be sure we have a reason/way to say no. > > That's what I'm worried about. > > unrelated: the above is an interesting use case for yum plugins :) This is a really interesting discussion in that it begs the question of why we have an advisory board or a Fedora Project Board. If we could codify every decision point, we could just write them in the wiki and dissolve at least the actual authority group (FPB). Sometimes the reason "because it makes me break out in hives" is an OK answer. What exactly are we afraid will happen if less virtuous company XYZ approaches us in the fashion described above, with some offer that really does make us break out in hives? (I know that anything with any currency symbol involved makes Seth break out in hives. I understand.) Is anyone worried that everyone on this list, or on the Board, will suddenly have their eyeballs turn into big cartoon dollar signs, and forget any semblance of FOSS ethics? Are people who are likely to do that also likely to be in a Fedora leadership position? Originally the CodecBuddy idea came out of a motive of simply making things easier on our users within US+etc. legal limits while simultaneously educating them. If the problem really is that we can't prove that motive, I'd say welcome to politics. I worry that trying to have neat dividing lines prepared for fuzzy issues makes it easier to push off responsibility for judgment calls on some piece of written text. And it makes it inevitable, rather than simply possible, that you'll alienate community members by doing so, and probably more of them to boot. I don't see a real problem with Fluendo benefiting in some fashion from codeina, as long as there's no lockout that prevents anyone else from doing the same. Fluendo has devoted very significant resources to FOSS, and although the vouching in this case is in code form, the Fedora community has vouched for other vendors similarly before (think Intel for one). -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://pfrields.fedorapeople.org/ 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 rtlm10 at gmail.com Tue Nov 6 01:29:27 2007 From: rtlm10 at gmail.com (Russell Harrison) Date: Mon, 5 Nov 2007 20:29:27 -0500 Subject: codec buddy pain In-Reply-To: <1194308839.30261.45.camel@localhost.localdomain> References: <1194207255.2654.66.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105143823.62a9f036@weaponx> <472F93DD.5090903@0xdeadbeef.com> <1194300682.2654.166.camel@cutter> <1194308839.30261.45.camel@localhost.localdomain> Message-ID: <1ed4a0130711051729p193258e6ge14551ae44d4a183@mail.gmail.com> On 11/5/07, Paul W. Frields wrote: > Sometimes the reason "because it makes me break out in hives" is an OK answer. Well said, its important to remember that. Sometimes I forget. > I don't see a real problem with Fluendo benefiting in some fashion from > codeina, as long as there's no lockout that prevents anyone else from > doing the same. Fluendo has devoted very significant resources to FOSS, > and although the vouching in this case is in code form, the Fedora > community has vouched for other vendors similarly before (think Intel > for one). I agree here. We actually support many different companies indirectly with our code. Every time we integrate any APIs for an online service we are in effect advertising and promoting that service. We distribute packages that integrate Google Maps, upload files to flickr, provide interfaces to the Magnatune music store, etc. I personally don't have a problem with this, as all a company needs to benefit from this is to open up their APIs and or contribute to the same project providing the user with more choice. Everyone wins here. If we ever were to exclude support for a service or product at the expense of another one, that would be a position that isn't supportable. In the case of CodecBuddy things are a bit more gray because it involves closed binaries. The problem is that when people can't play this media or that media they feel they should be able to they assume "Fedora sucks! It can't play my mp3s". CodecBuddy provides the opportunity to explain why support for such formats isn't included. Hopefully redirecting the users irritation to where it belongs: the US Patent Office. As long as we make it very clear that there are viable alternative free formats, and that supporting the non-free formats IS possible with existing open source code, it just isn't legal here in the states. I see it as an opportunity to gain support for free software as no one is going to want to pay for the other formats supported by Fluendo. They are going to want to play them however and that may motivate people to find out a bit more about why they simply "aren't allowed". -- Russell Harrison Systems Administrator -- Linux Desktops Cisco Systems, Inc. Note: The positions or opinions expressed in this email are my own. They are not necessarily those of my employer. From a.badger at gmail.com Tue Nov 6 01:47:41 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 05 Nov 2007 17:47:41 -0800 Subject: codec buddy pain In-Reply-To: <1ed4a0130711051729p193258e6ge14551ae44d4a183@mail.gmail.com> References: <1194207255.2654.66.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105143823.62a9f036@weaponx> <472F93DD.5090903@0xdeadbeef.com> <1194300682.2654.166.camel@cutter> <1194308839.30261.45.camel@localhost.localdomain> <1ed4a0130711051729p193258e6ge14551ae44d4a183@mail.gmail.com> Message-ID: <472FC7BD.5080301@gmail.com> Russell Harrison wrote: > Hopefully redirecting the users irritation to where it belongs: the US > Patent Office. As long as we make it very clear that there are viable > alternative free formats, and that supporting the non-free formats IS > possible with existing open source code, it just isn't legal here in > the states. This is a tremendously good point, I think. In the FOSS community I think we have a lot of resentment towards the patent system. But it won't be until our users start to build up a resentment towards the system that we actually see anything happen. And one sure way to do that is to make the American consumers feel that the rest of the world has an advantage over them due to the patent laws in the country they live in. -Toshio From skvidal at fedoraproject.org Tue Nov 6 04:26:55 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 05 Nov 2007 23:26:55 -0500 Subject: codec buddy pain In-Reply-To: <472FC7BD.5080301@gmail.com> References: <1194207255.2654.66.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105143823.62a9f036@weaponx> <472F93DD.5090903@0xdeadbeef.com> <1194300682.2654.166.camel@cutter> <1194308839.30261.45.camel@localhost.localdomain> <1ed4a0130711051729p193258e6ge14551ae44d4a183@mail.gmail.com> <472FC7BD.5080301@gmail.com> Message-ID: <1194323215.2654.192.camel@cutter> On Mon, 2007-11-05 at 17:47 -0800, Toshio Kuratomi wrote: > Russell Harrison wrote: > > Hopefully redirecting the users irritation to where it belongs: the US > > Patent Office. As long as we make it very clear that there are viable > > alternative free formats, and that supporting the non-free formats IS > > possible with existing open source code, it just isn't legal here in > > the states. > > This is a tremendously good point, I think. In the FOSS community I > think we have a lot of resentment towards the patent system. But it > won't be until our users start to build up a resentment towards the > system that we actually see anything happen. And one sure way to do > that is to make the American consumers feel that the rest of the world > has an advantage over them due to the patent laws in the country they > live in. > It's not just the US. The european patent system isn't vastly better, either. -sv From skvidal at fedoraproject.org Tue Nov 6 04:37:36 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 05 Nov 2007 23:37:36 -0500 Subject: codec buddy pain In-Reply-To: <1194308839.30261.45.camel@localhost.localdomain> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105143823.62a9f036@weaponx> <472F93DD.5090903@0xdeadbeef.com> <1194300682.2654.166.camel@cutter> <1194308839.30261.45.camel@localhost.localdomain> Message-ID: <1194323856.2654.197.camel@cutter> On Mon, 2007-11-05 at 19:27 -0500, Paul W. Frields wrote: > This is a really interesting discussion in that it begs the question of > why we have an advisory board or a Fedora Project Board. If we could > codify every decision point, we could just write them in the wiki and > dissolve at least the actual authority group (FPB). Sometimes the > reason "because it makes me break out in hives" is an OK answer. > My concern is just about looking inconsistent or hypocritical. Inconsistencies cause problems when trying to enforce decisions. > What exactly are we afraid will happen if less virtuous company XYZ > approaches us in the fashion described above, with some offer that > really does make us break out in hives? (I know that anything with any > currency symbol involved makes Seth break out in hives. I understand.) > Is anyone worried that everyone on this list, or on the Board, will > suddenly have their eyeballs turn into big cartoon dollar signs, and > forget any semblance of FOSS ethics? Are people who are likely to do > that also likely to be in a Fedora leadership position? No, I'm more afraid of us not being able to form a cogent argument for why not. Especially not if internal Red Hat interest come into play. If someone is interested in shareholder value and says "but you've done it before in codeina, so why not do it now for brand-x?" This is the opposite of the slippery-slope - it's the foothold for making fedora something we may not end up liking. -sv From kwade at redhat.com Tue Nov 6 17:51:08 2007 From: kwade at redhat.com (Karsten Wade) Date: Tue, 06 Nov 2007 09:51:08 -0800 Subject: codec buddy pain In-Reply-To: <1194297668.5020.1.camel@localhost.localdomain> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> <1194297668.5020.1.camel@localhost.localdomain> Message-ID: <1194371468.4307.305.camel@erato.phig.org> On Mon, 2007-11-05 at 16:21 -0500, Matthias Clasen wrote: > No, this is not correct. We entirely control the initial dialog that > explains the situation (what has been dubbed "the sermon" in early > reviews) and contains the link to the fedora wiki, and we have changed > the wording of that dialog in the run-up to F8, based on feedback from > people from this list. This is what I understood was happening. If it is an advertisement, or has the workflow that Seth posted[1], or has any how-to-buy-directly stuff still, that is a 'RED ALERT' condition and needs to be fixed as a zero-day update. We would also need some marketing/pr-type correction out there as well. - Karsten [1] http://www.redhat.com/archives/fedora-advisory-board/2007-November/msg00036.html -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org 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 smooge at gmail.com Tue Nov 6 17:33:48 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 6 Nov 2007 10:33:48 -0700 Subject: codec buddy pain In-Reply-To: <1194323856.2654.197.camel@cutter> References: <1194207255.2654.66.camel@cutter> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105143823.62a9f036@weaponx> <472F93DD.5090903@0xdeadbeef.com> <1194300682.2654.166.camel@cutter> <1194308839.30261.45.camel@localhost.localdomain> <1194323856.2654.197.camel@cutter> Message-ID: <80d7e4090711060933l5e328081t142bbdc10f4600e6@mail.gmail.com> On 11/5/07, seth vidal wrote: > > On Mon, 2007-11-05 at 19:27 -0500, Paul W. Frields wrote: > > > This is a really interesting discussion in that it begs the question of > > why we have an advisory board or a Fedora Project Board. If we could > > codify every decision point, we could just write them in the wiki and > > dissolve at least the actual authority group (FPB). Sometimes the > > reason "because it makes me break out in hives" is an OK answer. > > > > My concern is just about looking inconsistent or hypocritical. > Inconsistencies cause problems when trying to enforce decisions. > > > > > What exactly are we afraid will happen if less virtuous company XYZ > > approaches us in the fashion described above, with some offer that > > really does make us break out in hives? (I know that anything with any > > currency symbol involved makes Seth break out in hives. I understand.) > > Is anyone worried that everyone on this list, or on the Board, will > > suddenly have their eyeballs turn into big cartoon dollar signs, and > > forget any semblance of FOSS ethics? Are people who are likely to do > > that also likely to be in a Fedora leadership position? > > No, I'm more afraid of us not being able to form a cogent argument for > why not. Especially not if internal Red Hat interest come into play. If > someone is interested in shareholder value and says "but you've done it > before in codeina, so why not do it now for brand-x?" > > This is the opposite of the slippery-slope - it's the foothold for > making fedora something we may not end up liking. This is where a representative democracy comes into place. Figure out who are the people who have the right to vote and put it towards the equivalent 'congress' of people. If the some sort of majority agree that this ok then I would say the slippery slope is one that enough people has agreed to walk on. Stephen "I for one look forward to being lobbied by big money interests for my vote" Smoogen -- 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 mclasen at redhat.com Wed Nov 7 02:27:05 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 06 Nov 2007 21:27:05 -0500 Subject: codec buddy pain In-Reply-To: <1194371468.4307.305.camel@erato.phig.org> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> <1194297668.5020.1.camel@localhost.localdomain> <1194371468.4307.305.camel@erato.phig.org> Message-ID: <1194402425.3963.27.camel@localhost.localdomain> On Tue, 2007-11-06 at 09:51 -0800, Karsten Wade wrote: > On Mon, 2007-11-05 at 16:21 -0500, Matthias Clasen wrote: > > > No, this is not correct. We entirely control the initial dialog that > > explains the situation (what has been dubbed "the sermon" in early > > reviews) and contains the link to the fedora wiki, and we have changed > > the wording of that dialog in the run-up to F8, based on feedback from > > people from this list. > > This is what I understood was happening. > > If it is an advertisement, or has the workflow that Seth posted[1], or > has any how-to-buy-directly stuff still, that is a 'RED ALERT' condition > and needs to be fixed as a zero-day update. We would also need some > marketing/pr-type correction out there as well. Can't we all please stop the alarmist tone, and just try codeina once, before continuing this discussion ? I am surprised how much of this discussion seems to be based on hearsay or reading reviews. From skvidal at fedoraproject.org Wed Nov 7 03:22:35 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 06 Nov 2007 22:22:35 -0500 Subject: codec buddy pain In-Reply-To: <1194402425.3963.27.camel@localhost.localdomain> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> <1194297668.5020.1.camel@localhost.localdomain> <1194371468.4307.305.camel@erato.phig.org> <1194402425.3963.27.camel@localhost.localdomain> Message-ID: <1194405755.2033.0.camel@cutter> On Tue, 2007-11-06 at 21:27 -0500, Matthias Clasen wrote: > On Tue, 2007-11-06 at 09:51 -0800, Karsten Wade wrote: > > On Mon, 2007-11-05 at 16:21 -0500, Matthias Clasen wrote: > > > > > No, this is not correct. We entirely control the initial dialog that > > > explains the situation (what has been dubbed "the sermon" in early > > > reviews) and contains the link to the fedora wiki, and we have changed > > > the wording of that dialog in the run-up to F8, based on feedback from > > > people from this list. > > > > This is what I understood was happening. > > > > If it is an advertisement, or has the workflow that Seth posted[1], or > > has any how-to-buy-directly stuff still, that is a 'RED ALERT' condition > > and needs to be fixed as a zero-day update. We would also need some > > marketing/pr-type correction out there as well. > > Can't we all please stop the alarmist tone, and just try codeina once, > before continuing this discussion ? I am surprised how much of this > discussion seems to be based on hearsay or reading reviews. My entire concern is based on use of codeina and the screenshots I took and posted. -sv From tcallawa at redhat.com Wed Nov 7 15:07:01 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 07 Nov 2007 10:07:01 -0500 Subject: Legal update Message-ID: <1194448021.3148.61.camel@localhost.localdomain> I've gotten some legal updates that I know some people have been waiting for: libgpod/gtkpod support for newer ipods: Legal says that we can incorporate this code, it does not violate the DMCA, because it is solely for the purposes of interoperability. This means that we can go ahead and enable support for new ipods in Fedora. ***** Linking to "third party repositories": Legal says that we can link, from the Fedora website, to third party repositories, so long as no one has made a critical assessment to determine that a patent or patents cover the technology in question and no party has actually asserted their patents against the technology, we should be okay. Once we are on notice of a claim of infringement or are aware of a competent assessment that concludes infringement is likely, we would need to take the link down or run a serious risk of facing a claim for inducing infringement. Merely linking would be highly unlikely to subject us to a claim of direct infringement. I asked about MP3, and it was stated that unless we are specifically aware of the MP3 patent holders asserting a claim against the technology, we are still okay. This means that we can put a page up on the fedoraproject.org wiki, which carefully explains that there is an optional addon repository called Livna, which contains packages that for a variety of reasons, are not included in the normal Fedora repositories. We should not specify these reasons, and if someone asserted their patents against something in Livna, we would need to take the page down. We can link to Livna directly on this page. We cannot ship yum configs which enable Livna (but Livna provides these, so we don't really need to). ***** As a reminder, if you have legal issues related to Fedora, please let me know, and I'll do my best to get them resolved. Thanks, ~spot From kwade at redhat.com Wed Nov 7 15:35:12 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 07 Nov 2007 07:35:12 -0800 Subject: codec buddy pain In-Reply-To: <1194402425.3963.27.camel@localhost.localdomain> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> <1194297668.5020.1.camel@localhost.localdomain> <1194371468.4307.305.camel@erato.phig.org> <1194402425.3963.27.camel@localhost.localdomain> Message-ID: <1194449712.4307.344.camel@erato.phig.org> On Tue, 2007-11-06 at 21:27 -0500, Matthias Clasen wrote: > Can't we all please stop the alarmist tone, and just try codeina once, > before continuing this discussion ? I am surprised how much of this > discussion seems to be based on hearsay or reading reviews. I'm not in a position to do that, and unfortunately have to rely upon y'all, who have slightly or wildly different stories. However, I understand from *you* that Seth's screenshots are old and the situation has changed to one not to be alarmed about. Right? - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org 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 jspaleta at gmail.com Wed Nov 7 17:27:19 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 7 Nov 2007 08:27:19 -0900 Subject: Legal update In-Reply-To: <1194448021.3148.61.camel@localhost.localdomain> References: <1194448021.3148.61.camel@localhost.localdomain> Message-ID: <604aa7910711070927n392d0509s28eeb3fcad4b01f0@mail.gmail.com> On Nov 7, 2007 6:07 AM, Tom spot Callaway wrote: > This means that we can put a page up on the fedoraproject.org wiki, > which carefully explains that there is an optional addon repository > called Livna, which contains packages that for a variety of reasons, are > not included in the normal Fedora repositories. We should not specify > these reasons, and if someone asserted their patents against something > in Livna, we would need to take the page down. We can link to Livna > directly on this page. We cannot ship yum configs which enable Livna > (but Livna provides these, so we don't really need to). Can we link to a specific rpm which will configure livna for use... the livna-release rpm as it currently exits? Can we potentially link to livna from inside packages that we ship.. aka codeina? -jef"s/livna/rpmfusion/"spaleta From kwade at redhat.com Wed Nov 7 17:37:42 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 07 Nov 2007 09:37:42 -0800 Subject: codec buddy pain In-Reply-To: <1194402425.3963.27.camel@localhost.localdomain> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> <1194297668.5020.1.camel@localhost.localdomain> <1194371468.4307.305.camel@erato.phig.org> <1194402425.3963.27.camel@localhost.localdomain> Message-ID: <1194457062.4307.372.camel@erato.phig.org> On Tue, 2007-11-06 at 21:27 -0500, Matthias Clasen wrote: > Can't we all please stop the alarmist tone, and just try codeina once, > before continuing this discussion ? I am surprised how much of this > discussion seems to be based on hearsay or reading reviews. Another piece of hearsay: http://fedora-tutorials.com/2007/11/07/pow-codec-buddy/ The sequence shown in that post has no Board-approved dialog pop-up. It seems to be the standard codeina -- pop a dialog that gives the option to get some non-free codecs, then walk the user through a purchasing situation. Is that review based on an old version? I won't go into all the things that disturb me if that is an accurate review based on current packages; I'll do as you ask, and wait to find out. - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From gdk at redhat.com Wed Nov 7 17:42:57 2007 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 7 Nov 2007 12:42:57 -0500 (EST) Subject: codec buddy pain In-Reply-To: <1194457062.4307.372.camel@erato.phig.org> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> <1194297668.5020.1.camel@localhost.localdomain> <1194371468.4307.305.camel@erato.phig.org> <1194402425.3963.27.camel@localhost.localdomain> <1194457062.4307.372.camel@erato.phig.org> Message-ID: On Wed, 7 Nov 2007, Karsten Wade wrote: > On Tue, 2007-11-06 at 21:27 -0500, Matthias Clasen wrote: > >> Can't we all please stop the alarmist tone, and just try codeina once, >> before continuing this discussion ? I am surprised how much of this >> discussion seems to be based on hearsay or reading reviews. > > Another piece of hearsay: > > http://fedora-tutorials.com/2007/11/07/pow-codec-buddy/ > > The sequence shown in that post has no Board-approved dialog pop-up. It > seems to be the standard codeina -- pop a dialog that gives the option > to get some non-free codecs, then walk the user through a purchasing > situation. > > Is that review based on an old version? It's based on the Live media version. When I run Gold Fedora 8 from my USB key, that's what I get too. --g From jkeating at redhat.com Wed Nov 7 18:14:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Nov 2007 13:14:25 -0500 Subject: Legal update In-Reply-To: <604aa7910711070927n392d0509s28eeb3fcad4b01f0@mail.gmail.com> References: <1194448021.3148.61.camel@localhost.localdomain> <604aa7910711070927n392d0509s28eeb3fcad4b01f0@mail.gmail.com> Message-ID: <20071107131425.42e2fe75@redhat.com> On Wed, 7 Nov 2007 08:27:19 -0900 "Jeff Spaleta" wrote: > Can we link to a specific rpm which will configure livna for use... > the livna-release rpm as it currently exits? > > Can we potentially link to livna from inside packages that we ship.. > aka codeina? > > -jef"s/livna/rpmfusion/"spaleta I think these are grayer areas. I'd feel much more comfortable just referencing it on a website, since we can pull that without issuing package updates. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Wed Nov 7 18:15:52 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 07 Nov 2007 13:15:52 -0500 Subject: Legal update In-Reply-To: <20071107131425.42e2fe75@redhat.com> References: <1194448021.3148.61.camel@localhost.localdomain> <604aa7910711070927n392d0509s28eeb3fcad4b01f0@mail.gmail.com> <20071107131425.42e2fe75@redhat.com> Message-ID: <1194459352.3148.69.camel@localhost.localdomain> On Wed, 2007-11-07 at 13:14 -0500, Jesse Keating wrote: > On Wed, 7 Nov 2007 08:27:19 -0900 > "Jeff Spaleta" wrote: > > > Can we link to a specific rpm which will configure livna for use... > > the livna-release rpm as it currently exits? > > > > Can we potentially link to livna from inside packages that we ship.. > > aka codeina? > > > > -jef"s/livna/rpmfusion/"spaleta > > I think these are grayer areas. I'd feel much more comfortable just > referencing it on a website, since we can pull that without issuing > package updates. I asked Legal about this, and they said no. Codeina can point to the Fedora webpage where we link to Livna, but not any more directly than that. ~spot From jspaleta at gmail.com Wed Nov 7 18:25:00 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 7 Nov 2007 09:25:00 -0900 Subject: Legal update In-Reply-To: <20071107131425.42e2fe75@redhat.com> References: <1194448021.3148.61.camel@localhost.localdomain> <604aa7910711070927n392d0509s28eeb3fcad4b01f0@mail.gmail.com> <20071107131425.42e2fe75@redhat.com> Message-ID: <604aa7910711071025jedd7c06n5996ae427e7a132b@mail.gmail.com> On Nov 7, 2007 9:14 AM, Jesse Keating wrote: > I think these are grayer areas. I'd feel much more comfortable just > referencing it on a website, since we can pull that without issuing > package updates. We can reference the livna-release rpm on a website without issuing package updates as well. Can we have a paragraph on our webpage which includes a url to livna's release rpm or equivalent url mechanism which essentially becomes "Click here to enable this repository on your system." Or do we link to livna's frontpage and then livna has the "Click here to enable" url there. -jef"Don't get me wrong being able to reference livna at all even if its just a url to the repository's mainpage is a big benefit."spaleta From mclasen at redhat.com Wed Nov 7 18:35:09 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 07 Nov 2007 13:35:09 -0500 Subject: codec buddy pain In-Reply-To: <1194457062.4307.372.camel@erato.phig.org> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> <1194297668.5020.1.camel@localhost.localdomain> <1194371468.4307.305.camel@erato.phig.org> <1194402425.3963.27.camel@localhost.localdomain> <1194457062.4307.372.camel@erato.phig.org> Message-ID: <1194460509.4333.5.camel@localhost.localdomain> On Wed, 2007-11-07 at 09:37 -0800, Karsten Wade wrote: > On Tue, 2007-11-06 at 21:27 -0500, Matthias Clasen wrote: > > > Can't we all please stop the alarmist tone, and just try codeina once, > > before continuing this discussion ? I am surprised how much of this > > discussion seems to be based on hearsay or reading reviews. > > Another piece of hearsay: > > http://fedora-tutorials.com/2007/11/07/pow-codec-buddy/ > > The sequence shown in that post has no Board-approved dialog pop-up. It > seems to be the standard codeina -- pop a dialog that gives the option > to get some non-free codecs, then walk the user through a purchasing > situation. > > Is that review based on an old version? Unfortunately, I discovered last night after sending my last mail that we forgot to add a dependency to the codeina package when we put in nottings rewording patch that added the link to the fedora wiki. The side effect of that is that the distro dialog ("the sermon") is skipped unless you happen to have python-sexy installed. This could be what you are seeing in the above walk through. This is really unfortunate (and makes me look bad in this discussion). I have built a fix and pushed it as a zero-day update. Matthias From jspaleta at gmail.com Wed Nov 7 18:43:32 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 7 Nov 2007 09:43:32 -0900 Subject: codec buddy pain In-Reply-To: <1194460509.4333.5.camel@localhost.localdomain> References: <1194207255.2654.66.camel@cutter> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> <1194297668.5020.1.camel@localhost.localdomain> <1194371468.4307.305.camel@erato.phig.org> <1194402425.3963.27.camel@localhost.localdomain> <1194457062.4307.372.camel@erato.phig.org> <1194460509.4333.5.camel@localhost.localdomain> Message-ID: <604aa7910711071043h3316d328sb491684c792bf867@mail.gmail.com> On Nov 7, 2007 9:35 AM, Matthias Clasen wrote: > This could be what you are seeing in the above walk through. This is > really unfortunate (and makes me look bad in this discussion). I have > built a fix and pushed it as a zero-day update. Do we have any workflow associated with updating the livecd/liveusb images? I'm asking this in general not just for this issue. People make mistakes, I'm not going to quibble over blame. But do we have a workflow in place to rev our livecd images to fix stuff like this post release? I don't want to see our live images be a museum of our zero day oops for the lifespan of the release. -jef From gdk at redhat.com Wed Nov 7 18:44:54 2007 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 7 Nov 2007 13:44:54 -0500 (EST) Subject: codec buddy pain In-Reply-To: <1194460509.4333.5.camel@localhost.localdomain> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> <1194297668.5020.1.camel@localhost.localdomain> <1194371468.4307.305.camel@erato.phig.org> <1194402425.3963.27.camel@localhost.localdomain> <1194457062.4307.372.camel@erato.phig.org> <1194460509.4333.5.camel@localhost.localdomain> Message-ID: On Wed, 7 Nov 2007, Matthias Clasen wrote: > Unfortunately, I discovered last night after sending my last mail that > we forgot to add a dependency to the codeina package when we put in > nottings rewording patch that added the link to the fedora wiki. The > side effect of that is that the distro dialog ("the sermon") is skipped > unless you happen to have python-sexy installed. > > This could be what you are seeing in the above walk through. This is > really unfortunate (and makes me look bad in this discussion). I have > built a fix and pushed it as a zero-day update. Heh heh heh! I'm only laughing because I've lived this pain in other scenarios. Open mouth, berate others, be right in principle but wrong in fact, take thorough beating. :) I'm sorry, Matthias. --g -- Greg DeKoenigsberg Community Development Manager Red Hat, Inc. :: 1-919-754-4255 "To whomsoever much hath been given... ...from him much shall be asked" From vnk at mkc.co.nz Wed Nov 7 18:47:57 2007 From: vnk at mkc.co.nz (Vladimir Kosovac) Date: Thu, 08 Nov 2007 07:47:57 +1300 Subject: codec buddy pain In-Reply-To: <1194457062.4307.372.camel@erato.phig.org> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> <1194297668.5020.1.camel@localhost.localdomain> <1194371468.4307.305.camel@erato.phig.org> <1194402425.3963.27.camel@localhost.localdomain> <1194457062.4307.372.camel@erato.phig.org> Message-ID: <4732085D.8010808@mkc.co.nz> Karsten Wade wrote: > On Tue, 2007-11-06 at 21:27 -0500, Matthias Clasen wrote: > >> Can't we all please stop the alarmist tone, and just try codeina once, >> before continuing this discussion ? I am surprised how much of this >> discussion seems to be based on hearsay or reading reviews. > > Another piece of hearsay: > > http://fedora-tutorials.com/2007/11/07/pow-codec-buddy/ > > The sequence shown in that post has no Board-approved dialog pop-up. It > seems to be the standard codeina -- pop a dialog that gives the option > to get some non-free codecs, then walk the user through a purchasing > situation. > > Is that review based on an old version? Screenshots on that page are the actual sequence on install from DVD.i386.iso Internode [Au] mirror still has pub/fedora/linux/releases/8/ open, this is where I got iso image from. It looks like a final release but I have no meanings of confirming this, other than the clues from the installed system: - pirut is picking up updates from updates, not rawhide repo. - test 3 worked properly (with FAB approved pop-up). Tree for 7.92 shows version codeina-0.10.1-1 and the one I currently have (from iso) is codeina-0.10.1-5 - /etc/fedora-release is Fedora release 8 (Werewolf) Vladimir > > I won't go into all the things that disturb me if that is an accurate > review based on current packages; I'll do as you ask, and wait to find > out. > > - Karsten > > > ------------------------------------------------------------------------ > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From vnk at mkc.co.nz Wed Nov 7 18:53:36 2007 From: vnk at mkc.co.nz (Vladimir Kosovac) Date: Thu, 08 Nov 2007 07:53:36 +1300 Subject: codec buddy pain In-Reply-To: <1194460509.4333.5.camel@localhost.localdomain> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> <1194297668.5020.1.camel@localhost.localdomain> <1194371468.4307.305.camel@erato.phig.org> <1194402425.3963.27.camel@localhost.localdomain> <1194457062.4307.372.camel@erato.phig.org> <1194460509.4333.5.camel@localhost.localdomain> Message-ID: <473209B0.6070007@mkc.co.nz> Matthias Clasen wrote: > On Wed, 2007-11-07 at 09:37 -0800, Karsten Wade wrote: >> On Tue, 2007-11-06 at 21:27 -0500, Matthias Clasen wrote: >> >>> Can't we all please stop the alarmist tone, and just try codeina once, >>> before continuing this discussion ? I am surprised how much of this >>> discussion seems to be based on hearsay or reading reviews. >> Another piece of hearsay: >> >> http://fedora-tutorials.com/2007/11/07/pow-codec-buddy/ >> >> The sequence shown in that post has no Board-approved dialog pop-up. It >> seems to be the standard codeina -- pop a dialog that gives the option >> to get some non-free codecs, then walk the user through a purchasing >> situation. >> >> Is that review based on an old version? > > Unfortunately, I discovered last night after sending my last mail that > we forgot to add a dependency to the codeina package when we put in > nottings rewording patch that added the link to the fedora wiki. The > side effect of that is that the distro dialog ("the sermon") is skipped > unless you happen to have python-sexy installed. > I can also confirm this, with two 'sexy' packages, it works as intended. Vladimir > This could be what you are seeing in the above walk through. This is > really unfortunate (and makes me look bad in this discussion). I have > built a fix and pushed it as a zero-day update. > > > Matthias > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From mspevack at redhat.com Wed Nov 7 18:59:44 2007 From: mspevack at redhat.com (Max Spevack) Date: Wed, 7 Nov 2007 13:59:44 -0500 (EST) Subject: codec buddy pain In-Reply-To: <1194207255.2654.66.camel@cutter> References: <1194207255.2654.66.camel@cutter> Message-ID: > Btw - in the interview they mention further integration of the > webstore into codeina/codecbuddy. If it starts looking like we're > pushing closed source software then that, imo, is when codeina gets > dumped out of the distribution. This is not addressed to Seth, I'm just using his first email as the reply point. I don't have a lot to add after this very long thread, but I will say this: Remember -- Codeina is an *attempt* to address one of the Constant Complaints that we also get in Fedora. Every time I have ever been at a Fedora event with Jeremy, we turn to each other and try to guess how long it will take before someone asks The MP3 Question. We are not making ANY MONEY off of Codec Buddy, either Fedora or Red Hat. If it ends up being a failed experiment, it can be pulled in Fedora 9. If it ends up needing improvements, then it can get them. If everyone likes it, then we can feel good about ourselves. Nothing is ever set in stone. Let's give it some time to be digested by our Average Users and see how it goes. --Max From bpepple at fedoraproject.org Wed Nov 7 19:02:47 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 07 Nov 2007 14:02:47 -0500 Subject: codec buddy pain In-Reply-To: References: <1194207255.2654.66.camel@cutter> Message-ID: <1194462168.16428.10.camel@nixon> On Wed, 2007-11-07 at 13:59 -0500, Max Spevack wrote: > If it ends up being a failed experiment, it can be pulled in Fedora 9. > If it ends up needing improvements, then it can get them. If everyone > likes it, then we can feel good about ourselves. > > Nothing is ever set in stone. Let's give it some time to be digested by > our Average Users and see how it goes. +1 /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 mclasen at redhat.com Wed Nov 7 19:02:48 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 07 Nov 2007 14:02:48 -0500 Subject: codec buddy pain In-Reply-To: References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> <1194297668.5020.1.camel@localhost.localdomain> <1194371468.4307.305.camel@erato.phig.org> <1194402425.3963.27.camel@localhost.localdomain> <1194457062.4307.372.camel@erato.phig.org> <1194460509.4333.5.camel@localhost.localdomain> Message-ID: <1194462168.4333.11.camel@localhost.localdomain> On Wed, 2007-11-07 at 13:44 -0500, Greg DeKoenigsberg wrote: > On Wed, 7 Nov 2007, Matthias Clasen wrote: > > > Unfortunately, I discovered last night after sending my last mail that > > we forgot to add a dependency to the codeina package when we put in > > nottings rewording patch that added the link to the fedora wiki. The > > side effect of that is that the distro dialog ("the sermon") is skipped > > unless you happen to have python-sexy installed. > > > > This could be what you are seeing in the above walk through. This is > > really unfortunate (and makes me look bad in this discussion). I have > > built a fix and pushed it as a zero-day update. > > Heh heh heh! > > I'm only laughing because I've lived this pain in other scenarios. Open > mouth, berate others, be right in principle but wrong in fact, take > thorough beating. :) Yeah, its funny how these things happen. Clearly, this laugh is on me... From jkeating at redhat.com Wed Nov 7 19:21:42 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Nov 2007 14:21:42 -0500 Subject: Legal update In-Reply-To: <604aa7910711071025jedd7c06n5996ae427e7a132b@mail.gmail.com> References: <1194448021.3148.61.camel@localhost.localdomain> <604aa7910711070927n392d0509s28eeb3fcad4b01f0@mail.gmail.com> <20071107131425.42e2fe75@redhat.com> <604aa7910711071025jedd7c06n5996ae427e7a132b@mail.gmail.com> Message-ID: <20071107142142.3f947963@redhat.com> On Wed, 7 Nov 2007 09:25:00 -0900 "Jeff Spaleta" wrote: > Or do we link to livna's frontpage and then livna has the "Click here > to enable" url there. Yes. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Wed Nov 7 20:02:40 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 07 Nov 2007 21:02:40 +0100 Subject: Fedora Unity releases updated Fedora 7 Re-Spins Message-ID: <473219E0.80807@kanarip.com> The Fedora Unity Project is proud to announce the release of new ISO Re-Spins (DVD and CD Sets) of Fedora 7. These Re-Spin ISOs are based on Fedora 7 and all updates released as of October 30th, 2007. The ISO images are available for i386 and x86_64 architectures via jigdo starting Wednesday, November 7th, 2007. We have included CD Image sets for those in the Fedora community that do not have DVD drives or burners available. Fedora Unity has taken up the Re-Spin task to provide the community with the chance to install Fedora with recent updates already included. These updates might otherwise comprise more than 1.91GiB of downloads for a full install. This is a community project, for and by the community. You can contribute to the community by joining our test process. A full changelog of the packages that have been updated in this Re-Spin can be reviewed on http://spins.fedoraunity.org/changelogs/20071030/ This Re-Spin will obsolete the previous Re-Spin released by Fedora Unity, namely '20070912'. If you are interested in helping with the testing or mirroring efforts, please contact the Fedora Unity team. Contact information is available at http://fedoraunity.org/ or the #fedora-unity channel on the Freenode IRC Network (irc.freenode.net). Go to http://spins.fedoraunity.org/ to get the bits! To report bugs in the Re-Spins please use http://bugs.fedoraunity.org/ Kind regards, Jeroen van Meeuwen Fedora Unity Founder kanarip at fedoraunity.org -- Fedora is a trademark of Red Hat, Inc. From kwade at redhat.com Wed Nov 7 20:16:38 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 07 Nov 2007 12:16:38 -0800 Subject: codec buddy pain In-Reply-To: <1194460509.4333.5.camel@localhost.localdomain> References: <1194207255.2654.66.camel@cutter> <1194276002.4307.204.camel@erato.phig.org> <1194276726.2654.102.camel@cutter> <472F6931.4030701@0xdeadbeef.com> <1194289239.2654.116.camel@cutter> <472F6D27.6020701@0xdeadbeef.com> <20071105133732.0677e456@weaponx> <1194294021.2654.123.camel@cutter> <20071105153629.17e84e91@redhat.com> <1194297668.5020.1.camel@localhost.localdomain> <1194371468.4307.305.camel@erato.phig.org> <1194402425.3963.27.camel@localhost.localdomain> <1194457062.4307.372.camel@erato.phig.org> <1194460509.4333.5.camel@localhost.localdomain> Message-ID: <1194466598.6142.32.camel@erato.phig.org> On Wed, 2007-11-07 at 13:35 -0500, Matthias Clasen wrote: > Unfortunately, I discovered last night after sending my last mail that > we forgot to add a dependency to the codeina package when we put in > nottings rewording patch that added the link to the fedora wiki. The > side effect of that is that the distro dialog ("the sermon") is skipped > unless you happen to have python-sexy installed. > > This could be what you are seeing in the above walk through. This is > really unfortunate (and makes me look bad in this discussion). I have > built a fix and pushed it as a zero-day update. Thanks. No worries, glad you checked. Let's spin up the PR-machine to inform the world. What shall we say? - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Wed Nov 7 20:33:02 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 07 Nov 2007 12:33:02 -0800 Subject: Legal update Message-ID: <1194467582.6142.45.camel@erato.phig.org> (Sorry about breaking the threading, I haven't yet received Spot's original to reply to.) On Date: Wed, 07 Nov 2007 10:07:01 -0500 Spot wrote: > > Linking to "third party repositories": Legal says that we can link, > from the Fedora website, to third party repositories, so long as no > one has made a critical assessment to determine that a patent or > patents cover the technology in question ... Please define 'critical assessment' and the kind of person qualified to make it. ISTM that many people in Fedora have assessed if a piece of software is presenting technical capabilities that may be covered by a patent. Examples of this abound and are regularly linked to. None of the authors are lawyers. So is that the line? Just don't hire a lawyer to determine if package $FOO may infringe on a patent or patents? - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org 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 max at spevack.org Thu Nov 8 13:03:20 2007 From: max at spevack.org (Max Spevack) Date: Thu, 8 Nov 2007 08:03:20 -0500 (EST) Subject: IRC and release day Message-ID: Public service announcement. I know that lots of general users tend to wander into development and infrastructure related channels on the release day looking for help. I ask everyone who is on Fedora IRC to be extra sensitive to the fact that if you don't recognize someone's IRC handle, it is probably a person who is new to Fedora and/or Linux. It takes 2 seconds to give a curt answer, and 5 seconds to politely redirect people to #fedora and #fedora8 where the general release chatter will be happening. Please err on the side of politeness, and encourage others to do so as well, in all the fedora IRC channels. Thank you and congrats on the release! I hope that lots of the fedora folks get some rest and relaxation this weekend. I'm looking forward to finally having some time to upgrade everything other than my primary box to Fedora 8. :) --Max From kanarip at kanarip.com Thu Nov 8 21:51:05 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 08 Nov 2007 22:51:05 +0100 Subject: Fedora Unity releases Fedora 8 CD Sets Message-ID: <473384C9.70002@kanarip.com> The Fedora Unity Project is proud to announce the release of new CD Spins of Fedora 8. These CD ISOs are based on the Fedora 8 DVD.iso. The ISO images are available for i386 and x86_64 architectures via jigdo starting Thursday, November 8th, 2007. We have included CD Image sets for those in the Fedora community that do not have DVD drives or burners available. The Default install will require the first 3 CDs. If you are interested in helping with the testing or mirroring efforts, please contact the Fedora Unity team. Contact information is available at http://fedoraunity.org/ or the #fedora-unity channel on the Freenode IRC Network (irc.freenode.net). Go to http://spins.fedoraunity.org/ to get the bits! To report bugs in the Re-Spins please use http://bugs.fedoraunity.org/ Kind regards, Jeroen van Meeuwen Fedora Unity Founder kanarip at fedoraunity.org Fedora is a trademark of Red Hat, Inc. From mspevack at redhat.com Thu Nov 8 21:55:45 2007 From: mspevack at redhat.com (Max Spevack) Date: Thu, 8 Nov 2007 16:55:45 -0500 (EST) Subject: 3 development process improvements Message-ID: It is very rare that Fedora developers actually talk to each other on the phone (as opposed to IRC), but jkeating, mmcgrath, and I were just having a quick chat. Three general points that I jotted down for further email discussion: (1) pick a release name sooner in the cycle so that artwork, marketing materials, and web content can be finished sooner. (2) get web content finished at a specific deadline in the schedule (maybe same as string freeze?) (3) more dedicated feature QA/smoke-testing. Ask feature owners, as we get to the pre-release time, to do a fresh install and sanity check their feature to make sure it looks and operates the way it should. Just some suggestions for further discussion here, or on fedora-devel-list. still happy about today's release, Max From sundaram at fedoraproject.org Fri Nov 9 06:48:59 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 09 Nov 2007 12:18:59 +0530 Subject: [Fwd: Creative Commons wants your feedback and support] Message-ID: <473402DB.8040005@fedoraproject.org> Hi In case, someone wants to work with them more on this. Rahul -------------- next part -------------- An embedded message was scrubbed... From: Lawrence Lessig Subject: Creative Commons wants your feedback and support Date: Thu, 8 Nov 2007 15:58:43 -0800 Size: 6173 URL: From kwade at redhat.com Fri Nov 9 16:04:54 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 09 Nov 2007 08:04:54 -0800 Subject: [Fwd: Creative Commons wants your feedback and support] In-Reply-To: <473402DB.8040005@fedoraproject.org> References: <473402DB.8040005@fedoraproject.org> Message-ID: <1194624294.23923.76.camel@erato.phig.org> On Fri, 2007-11-09 at 12:18 +0530, Rahul Sundaram wrote: > Hi > > In case, someone wants to work with them more on this. If you read the email, you'll see that: i) it's focused on bloggers (we probably got it for Fedora Planet), and ii) it asks us not to blog about certain parts of the email (that is, not to widely distribute this direct email.) So, I'm not sure if there is anything here that has anything to do with the Fedora Project. - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org 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 skvidal at fedoraproject.org Fri Nov 9 16:50:10 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 09 Nov 2007 11:50:10 -0500 Subject: [Fwd: Creative Commons wants your feedback and support] In-Reply-To: <1194624294.23923.76.camel@erato.phig.org> References: <473402DB.8040005@fedoraproject.org> <1194624294.23923.76.camel@erato.phig.org> Message-ID: <1194627010.15170.86.camel@cutter> On Fri, 2007-11-09 at 08:04 -0800, Karsten Wade wrote: > On Fri, 2007-11-09 at 12:18 +0530, Rahul Sundaram wrote: > > Hi > > > > In case, someone wants to work with them more on this. > > If you read the email, you'll see that: i) it's focused on bloggers (we > probably got it for Fedora Planet), and ii) it asks us not to blog about > certain parts of the email (that is, not to widely distribute this > direct email.) > > So, I'm not sure if there is anything here that has anything to do with > the Fedora Project. > +1 -sv From caillon at redhat.com Fri Nov 9 17:36:19 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 09 Nov 2007 18:36:19 +0100 Subject: 3 development process improvements In-Reply-To: References: Message-ID: <47349A93.8070609@redhat.com> Max Spevack wrote: > It is very rare that Fedora developers actually talk to each other on > the phone (as opposed to IRC), but jkeating, mmcgrath, and I were just > having a quick chat. > > Three general points that I jotted down for further email discussion: > > (1) pick a release name sooner in the cycle so that artwork, marketing > materials, and web content can be finished sooner. I've mentioned this before for to a few people. Completely agree here. > (3) more dedicated feature QA/smoke-testing. Ask feature owners, as we > get to the pre-release time, to do a fresh install and sanity check > their feature to make sure it looks and operates the way it should. I really wish that we had more of a dedicated/organized QA effort for Fedora. Smoketesting is a great first step. I really hope that we can make some headway with this, because it was a very successful way to draw in contributors to Mozilla back in the day (and still is). From gdk at redhat.com Fri Nov 9 17:43:09 2007 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Fri, 9 Nov 2007 12:43:09 -0500 (EST) Subject: 3 development process improvements In-Reply-To: <47349A93.8070609@redhat.com> References: <47349A93.8070609@redhat.com> Message-ID: On Fri, 9 Nov 2007, Christopher Aillon wrote: > I really wish that we had more of a dedicated/organized QA effort for > Fedora. Smoketesting is a great first step. I really hope that we can > make some headway with this, because it was a very successful way to > draw in contributors to Mozilla back in the day (and still is). In fact, I'm focusing on the QA effort for OLPC right now for the exact same reason. --g -- Greg DeKoenigsberg Community Development Manager Red Hat, Inc. :: 1-919-754-4255 "To whomsoever much hath been given... ...from him much shall be asked" From jkeating at redhat.com Fri Nov 9 19:06:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 9 Nov 2007 14:06:25 -0500 Subject: Dealing with PPC in Fedora 9(+) Message-ID: <20071109140625.4728aadd@redhat.com> Now that Fedora 8 is out, I'd like to make a suggestion with regard to PPC. It's no secret that we've been talking about dropping PPC. First it was all together, then it was so that it could be come a secondary arch. So far, we've failed to execute. Starting now, I'd like to treat PPC as a pseudo secondary arch. This is because the secondary arch framework just isn't in place yet. What would this mean? We'd continue to build ppc binaries as if it were a primary arch, this requires no change to Koji. We continue to make rawhide trees of it, this requires no change to buildrawhide (mash, pungi). However, come release time (Alpha/Beta/Pre Release/RCs/Final) it would fall upon a secondary arch team for PPC to create release trees and isos of the bits. It would fall upon this team to QA the bits. It would fall upon this team to host the bits for download at release time (if no suitable framework exists for hosting the bits elsewhere at various release points, rel-eng could insert them into the normal tree structure as a last resort). We would clearly advertise that PPC is to be considered a secondary arch. We would do this /now/ so that there is enough time for interested parties can form a team and have it in place to handle bug reports, composes, etc... It's time to make this happen, instead of sitting on it for yet one more release. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laroche at redhat.com Sat Nov 10 12:00:36 2007 From: laroche at redhat.com (Florian La Roche) Date: Sat, 10 Nov 2007 13:00:36 +0100 Subject: 3 development process improvements In-Reply-To: References: Message-ID: <20071110120036.GA20614@dudweiler.stuttgart.redhat.com> On Thu, Nov 08, 2007 at 04:55:45PM -0500, Max Spevack wrote: > It is very rare that Fedora developers actually talk to each other on > the phone (as opposed to IRC), but jkeating, mmcgrath, and I were just > having a quick chat. > > Three general points that I jotted down for further email discussion: > > (1) pick a release name sooner in the cycle so that artwork, marketing > materials, and web content can be finished sooner. > > (2) get web content finished at a specific deadline in the schedule > (maybe same as string freeze?) > > (3) more dedicated feature QA/smoke-testing. Ask feature owners, as we > get to the pre-release time, to do a fresh install and sanity check > their feature to make sure it looks and operates the way it should. > > Just some suggestions for further discussion here, or on > fedora-devel-list. Hello Max, I longer time between release candidates and the final release would be great. Trees are too long broken during that timeframe. regards, Florian La Roche From jkeating at redhat.com Sun Nov 11 03:26:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 10 Nov 2007 22:26:57 -0500 Subject: 3 development process improvements In-Reply-To: <20071110120036.GA20614@dudweiler.stuttgart.redhat.com> References: <20071110120036.GA20614@dudweiler.stuttgart.redhat.com> Message-ID: <20071110222657.041463ab@redhat.com> On Sat, 10 Nov 2007 13:00:36 +0100 Florian La Roche wrote: > I longer time between release candidates and the final release > would be great. Trees are too long broken during that timeframe. I'd like to see some evidence to support that. We don't create release candidates until we have the tree in a shape that we think is actually releasable. Until then we're creating pre-releases, starting from when we enter a deep freeze. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- 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 Sun Nov 11 03:42:10 2007 From: davej at redhat.com (Dave Jones) Date: Sat, 10 Nov 2007 22:42:10 -0500 Subject: 3 development process improvements In-Reply-To: <20071110222657.041463ab@redhat.com> References: <20071110120036.GA20614@dudweiler.stuttgart.redhat.com> <20071110222657.041463ab@redhat.com> Message-ID: <20071111034210.GA12156@redhat.com> On Sat, Nov 10, 2007 at 10:26:57PM -0500, Jesse Keating wrote: > On Sat, 10 Nov 2007 13:00:36 +0100 > Florian La Roche wrote: > > > I longer time between release candidates and the final release > > would be great. Trees are too long broken during that timeframe. > > I'd like to see some evidence to support that. We don't create release > candidates until we have the tree in a shape that we think is actually > releasable. Until then we're creating pre-releases, starting from when > we enter a deep freeze. Not specifically the rc->final related, but the compose failed far too often during F8. It felt like a majority of the time the images/ dir never got populated. My install method of choice is PXE/kickstart, and I did a *lot* less test installs during F8 than I did in earlier releases due to this. The thing that really bites is that if the compose failed, that it was often left that way until the following day (where it may fail again). Perhaps the compose needs to be split up into multiple parts somehow so that the latter bits can be re-run by hand without having to wait for a full compose? Dave -- http://www.codemonkey.org.uk From jkeating at redhat.com Sun Nov 11 03:50:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 10 Nov 2007 22:50:38 -0500 Subject: 3 development process improvements In-Reply-To: <20071111034210.GA12156@redhat.com> References: <20071110120036.GA20614@dudweiler.stuttgart.redhat.com> <20071110222657.041463ab@redhat.com> <20071111034210.GA12156@redhat.com> Message-ID: <20071110225038.119b7ca1@redhat.com> On Sat, 10 Nov 2007 22:42:10 -0500 Dave Jones wrote: > Not specifically the rc->final related, but the compose failed > far too often during F8. It felt like a majority of the time the > images/ dir never got populated. > > My install method of choice is PXE/kickstart, and I did a *lot* less > test installs during F8 than I did in earlier releases due to this. > > The thing that really bites is that if the compose failed, that it > was often left that way until the following day (where it may fail > again). Perhaps the compose needs to be split up into multiple parts > somehow so that the latter bits can be re-run by hand without > having to wait for a full compose? Unfortunately the compose part had nothing to do with the stability of the tree itself. It's all in the fragility of the infrastructure around making rawhide show up, and that's something we're continually working on. Given that we have extremely easy to use tools out there to compose trees, we really aren't tied to waiting for rawhide to show up. So long as it's a repo of packages we can use tools like pungi and livecd-creator to do composes on our own for testing. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- 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 Sun Nov 11 03:51:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 10 Nov 2007 22:51:32 -0500 Subject: 3 development process improvements In-Reply-To: <20071110225038.119b7ca1@redhat.com> References: <20071110120036.GA20614@dudweiler.stuttgart.redhat.com> <20071110222657.041463ab@redhat.com> <20071111034210.GA12156@redhat.com> <20071110225038.119b7ca1@redhat.com> Message-ID: <20071110225132.51b7595f@redhat.com> On Sat, 10 Nov 2007 22:50:38 -0500 Jesse Keating wrote: > Given that we have extremely easy to use tools out there to compose > trees, we really aren't tied to waiting for rawhide to show up. So > long as it's a repo of packages we can use tools like pungi and > livecd-creator to do composes on our own for testing. Also, rescue.iso can be used with any repo of packages, so if you have a working rescue.iso you can point it at the rawhide repo of packages to install. The images/ bits need not show up for it to be usable as an installation target. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Sun Nov 11 07:45:47 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 11 Nov 2007 02:45:47 -0500 Subject: Dealing with PPC in Fedora 9(+) In-Reply-To: <20071109140625.4728aadd@redhat.com> References: <20071109140625.4728aadd@redhat.com> Message-ID: <1194767147.2588.149.camel@shinybook.infradead.org> On Fri, 2007-11-09 at 14:06 -0500, Jesse Keating wrote: > Now that Fedora 8 is out, I'd like to make a suggestion with regard to > PPC. It's no secret that we've been talking about dropping PPC. First > it was all together, then it was so that it could be come a secondary > arch. So far, we've failed to execute. That's not entirely true. We agreed that we would not change the status of PowerPC until one new 'secondary architecture' had been added. We have been working towards that goal, and progress has been made. Not all of it has been entirely sensible, on the build system side, but stuff _has_ happened. > Starting now, I'd like to treat PPC as a pseudo secondary arch. This > is because the secondary arch framework just isn't in place yet. I would like to stick to the agreement to keep PPC as a primary arch. This is _also_ because the secondary arch framework isn't in place yet. > What would this mean? We'd continue to build ppc binaries as if it were > a primary arch, this requires no change to Koji. We continue to make > rawhide trees of it, this requires no change to buildrawhide (mash, > pungi). Sounds good so far :) > However, come release time (Alpha/Beta/Pre Release/RCs/Final) > it would fall upon a secondary arch team for PPC to create release > trees and isos of the bits. I'm not sure exactly what that means, because my visibility into those parts of the release process has always been somewhat limited -- in fact I usually mostly ignore the rc1/rc2/rc3 or alpha/beta/prerelease or fish/monkey/turnip or whatever you want to call them this week, and just poke at rawhide. I've always considered the 'RC' spins to be just a confidence trick to get more victims^Wusers to install the stuff. What does it actually take to create the RC spins? I thought it was mostly just a case of running the same tools which run automatically to build rawhide each night? Given that those tools seem to change from release to release, it sounds like having that done by a separate team is just make-work stuff, for now. When we have other secondary architectures we'll want some kind of process for it, but at the moment it sounds like it would just be easier to keep running the same script three times instead of twice, surely? > It would fall upon this team to QA the bits. It certainly makes sense for myself and other volunteers to take a more active and _visible_ r?le in QA, I agree. I've been vaguely aware of text matrices in the wiki, but I've never been sure that it would be welcome for me to simply mark stuff off as 'tested'. I try to just make sure that when it _is_ tested, it works. > It would fall upon this team to host the bits for download at > release time (if no suitable framework exists for hosting the bits > elsewhere at various release points, rel-eng could insert them into > the normal tree structure as a last resort). Let's not do this yet -- the hosting, and surrounding issues about "Fedora" branding and mirroring, is a fairly important part of the "secondary architecture infrastructure" which we agreed should be in place and working for at least one other architecture _before_ we switch PowerPC over to it. > We would clearly advertise that PPC is to be considered a secondary arch. Advertise to whom and for what purpose? Precisely what is the message that you'd be trying to convey? What effect would you want to achieve? The term 'secondary arch' doesn't really mean a lot, in and of itself. Do you mean that you'd want to advertise to Fedora packagers that we don't really care about stupid endianness bugs any more, and they can be much more sloppy in their code? Do you mean that you'd want to advertise to Fedora users that we won't bother to look at bugs which happen to show up on PowerPC, unless they're also reproduced on some other platform? Do you mean that you just want to stick your fingers up at PowerPC because you think RISC is the work of the devil? :) Do you want to lower the expectations of Fedora users, so that they don't expect Fedora/PowerPC to be as BugFree? as Fedora/i386? I think all of those are bad ideas. The first two because they'd reduce the quality of Fedora code _overall_, the third because it's silly, and the fourth because if Fedora/PPC is significantly lower in quality than Fedora/i386 then we shouldn't release it as "Fedora" at all. Ok, admittedly they were straw men... what _do_ you want to be saying? > We would do this /now/ so that there is enough time for interested > parties can form a team and have it in place to handle bug reports, > composes, etc... Is there an issue with the way that bug reports are handled already? We keep the FE-ExcludeArch-ppc bug nice and empty, and the ppc64 version as empty as it needs to be given that we favour 32-bit userspace. Let's work towards making sure that F9 QA is done for you by those who care about the platform. Tell us what you need done in that respect, and we'll make sure it happens. But let's not change the hosting or other arrangements until another arch has led the way, as previously agreed. -- dwmw2 From dwmw2 at infradead.org Sun Nov 11 13:21:56 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 11 Nov 2007 08:21:56 -0500 Subject: Why 'secondary architectures'? In-Reply-To: <20071109140625.4728aadd@redhat.com> References: <20071109140625.4728aadd@redhat.com> Message-ID: <1194787316.2588.194.camel@shinybook.infradead.org> On Fri, 2007-11-09 at 14:06 -0500, Jesse Keating wrote: > Now that Fedora 8 is out, I'd like to make a suggestion with regard to > PPC. It's no secret that we've been talking about dropping PPC. First > it was all together, then it was so that it could be come a secondary > arch. So far, we've failed to execute. Digressing from the technical side, I'd like to properly understand your motivation. _Why_ do you want to do this? I like Fedora. I like to see it expand and get used in places it couldn't have been used before. I've always wanted to see it ported to new architectures and made versatile enough to do new things -- to be used as a basis for more than the bog-standard Linux desktop/small server on a PeeCee. I'd love to see more functionality -- more _possibilities_ -- merged under the 'Fedora' umbrella. As far as I can tell, you have the opposite desire. You seem to want to reduce what we have -- even when something's _working_, you want to back away from it -- disown it and all but abandon it. And even 'advertise' that we're doing so -- you want to shout it from the rooftops that we're backing into our corner. Why? We strive to ensure that PowerPC "Just Works?", when it comes to QA and release time. I think we do a reasonably good job, don't we? Stuff slips through occasionally, of course -- we should do more testing with SELinux enabled, for example. But in general, I don't think we do badly. So why do you constantly fight to throw out our work? What benefit do you think this attitude brings to Fedora? I assume you don't _just_ do it because you enjoy the massive slap in the face that we feel every time you do it? :) Have I missed a large amount of work which you personally need to do for each release? Or missed a large store of 'private' bugs in bugzilla which have never come to my attention? Or just misinterpreted the state of Fedora on PowerPC despite the fact that I use it on all my primary machines? So what _is_ the motivation? If Fedora/PowerPC is not good enough to be called 'Fedora', I will heartily agree that we should stop calling it that. That isn't the case though. If Fedora/PowerPC causes a significant amount of work for you, we can strive to take that load off you -- although I understood that's part of what the "secondary architecture infrastructure" was _for_, and we'd agreed that reclassifying Fedora/PowerPC would wait until that was in place. It can't be _just_ about the number of users -- I bet that there are fewer users of Kerberos on Fedora than there are PowerPC users, but we don't get people ranting after every release that they want to drop Kerberos support. Our usage numbers are very tenuous anyway, and we certainly can't factor in the bizarre things like the fact that Linus chose Fedora _because_ it runs on PowerPC. -- dwmw2 From smooge at gmail.com Mon Nov 12 04:26:23 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 11 Nov 2007 21:26:23 -0700 Subject: Why 'secondary architectures'? In-Reply-To: <1194787316.2588.194.camel@shinybook.infradead.org> References: <20071109140625.4728aadd@redhat.com> <1194787316.2588.194.camel@shinybook.infradead.org> Message-ID: <80d7e4090711112026m4a1890d5o3df29aacd06c6dbc@mail.gmail.com> On Nov 11, 2007 6:21 AM, David Woodhouse wrote: > On Fri, 2007-11-09 at 14:06 -0500, Jesse Keating wrote: > > Now that Fedora 8 is out, I'd like to make a suggestion with regard to > > PPC. It's no secret that we've been talking about dropping PPC. First > > it was all together, then it was so that it could be come a secondary > > arch. So far, we've failed to execute. > > Digressing from the technical side, I'd like to properly understand your > motivation. _Why_ do you want to do this? > ... Long rant snipped ... I would say that David is volunteering to run the PPC SIG then. Beyond the personal satisfaction you got from flaming someone, did this email accomplish anything? -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jkeating at redhat.com Mon Nov 12 14:14:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Nov 2007 09:14:20 -0500 Subject: Dealing with PPC in Fedora 9(+) In-Reply-To: <1194767147.2588.149.camel@shinybook.infradead.org> References: <20071109140625.4728aadd@redhat.com> <1194767147.2588.149.camel@shinybook.infradead.org> Message-ID: <20071112091420.09813094@redhat.com> On Sun, 11 Nov 2007 02:45:47 -0500 David Woodhouse wrote: > That's not entirely true. We agreed that we would not change the > status of PowerPC until one new 'secondary architecture' had been > added. We have been working towards that goal, and progress has been > made. Not all of it has been entirely sensible, on the build system > side, but stuff _has_ happened. Sure, stuff has happened. Honestly we hoped that it would happen sooner. I'm still not considering turning PPC completely into a secondary arch precisely because secondary arch stuff isn't ready and another arch hasn't played guinea pig for you. > > > Starting now, I'd like to treat PPC as a pseudo secondary arch. > > This is because the secondary arch framework just isn't in place > > yet. > > I would like to stick to the agreement to keep PPC as a primary arch. > This is _also_ because the secondary arch framework isn't in place > yet. I'm making a compromise. I don't want to turn PPC into a full secondary arch yet either, however in the places that really aren't related to the buildsystem there is no reason why PPC can't take care of itself. > > What would this mean? We'd continue to build ppc binaries as if it > > were a primary arch, this requires no change to Koji. We continue > > to make rawhide trees of it, this requires no change to > > buildrawhide (mash, pungi). > > Sounds good so far :) > > > However, come release time (Alpha/Beta/Pre Release/RCs/Final) > > it would fall upon a secondary arch team for PPC to create release > > trees and isos of the bits. > > I'm not sure exactly what that means, because my visibility into those > parts of the release process has always been somewhat limited -- in > fact I usually mostly ignore the rc1/rc2/rc3 or alpha/beta/prerelease > or fish/monkey/turnip or whatever you want to call them this week, > and just poke at rawhide. I've always considered the 'RC' spins to be > just a confidence trick to get more victims^Wusers to install the > stuff. > > What does it actually take to create the RC spins? I thought it was > mostly just a case of running the same tools which run automatically > to build rawhide each night? Not quite. Some of the same tools are involved, but are ran differently (so that isos are made), with different configs for the Fedora spin, and rawhide doesn't include Live images. > Given that those tools seem to change from release to release, it > sounds like having that done by a separate team is just make-work > stuff, for now. When we have other secondary architectures we'll want > some kind of process for it, but at the moment it sounds like it > would just be easier to keep running the same script three times > instead of twice, surely? No. The same tools have been used for Fedora 7 and 8. They've been developed on and improved, but its the same tools. They have to be ran on the arch they are composing, which means we can't easily use setarch to produce ppc trees/media like we do on x86. This requires those of us doing the compose to maintain a second machine and thread the output back into the other arches. There is also validation of the bits, time spent syncing them around, etc... > > > It would fall upon this team to QA the bits. > > It certainly makes sense for myself and other volunteers to take a > more active and _visible_ r?le in QA, I agree. I've been vaguely > aware of text matrices in the wiki, but I've never been sure that it > would be welcome for me to simply mark stuff off as 'tested'. I try > to just make sure that when it _is_ tested, it works. Will's repeated pleadings for people to help out have been missed? That's a shame. > > > It would fall upon this team to host the bits for download at > > release time (if no suitable framework exists for hosting the bits > > elsewhere at various release points, rel-eng could insert them into > > the normal tree structure as a last resort). > > Let's not do this yet -- the hosting, and surrounding issues about > "Fedora" branding and mirroring, is a fairly important part of the > "secondary architecture infrastructure" which we agreed should be in > place and working for at least one other architecture _before_ we > switch PowerPC over to it. I'm not so sure that this is the "important" part. It's really quite simple. If you're built from our bits, you can call it Fedora. Put it in a directory structure that would fit well with the rest of the mirror structure so that if mirrors chose to, they could spend their bandwidth and disk space on mirroring ppc (or other secondary arches). > > > We would clearly advertise that PPC is to be considered a secondary > > arch. > > Advertise to whom and for what purpose? Precisely what is the message > that you'd be trying to convey? What effect would you want to achieve? > The term 'secondary arch' doesn't really mean a lot, in and of itself. > > Do you mean that you'd want to advertise to Fedora packagers that we > don't really care about stupid endianness bugs any more, and they can > be much more sloppy in their code? -1 Troll. Whether the builds happen as part of a primary arch set (which we aren't changing right now), or they happen as part of a secondary arch build set, the maintainer is going to see a failure. They're going to care as much about it as they did in the past. Only now there would be a more official set of people to help them out with said arch issues. > > Do you mean that you'd want to advertise to Fedora users that we won't > bother to look at bugs which happen to show up on PowerPC, unless > they're also reproduced on some other platform? Again troll, but in all reality we have extremely few ppc rawhide users to begin with, and problems show up and stagnate for MONTHS before somebody like me or Jeremy find it as part of tree validation stuff. What I want is for it to be clear that the quality of PPC is entirely up to the the user base for it. All too often the user base, even your self, just rely upon somebody else to find the problems, and you just come in late in the game or the release and see "yep, everything is still fine. No need to pay attention to alpha/beta/rawhide, it'll just work at release time and I don't have to care.". If every arch did that we would miss the majority of the bugs. The difference is on other arches, we have a very large set of users using it every day and testing it every day and reporting all the problems they find. We hear crickets from the ppc community. Advertising PPC as a secondary arch is a clear sign that the fate of ppc relies upon the users of that arch. If they don't step up and pay attention and report when there are issues, they'll likely get missed and wind up in the final release. > [ snip ] > > Do you want to lower the expectations of Fedora users, so that they > don't expect Fedora/PowerPC to be as BugFree? as Fedora/i386? I want to set the expectation that the BugFreeness of PPC relies on them the users actually using rawhide and the test releases to find the bugs, like the x86 folks do. The bugs we find on x86 will be fixed for free on ppc, but if nobody is using the ppc development trees then any ppc specific bugs are going to fall through and ruin that BugFree state. > > I think all of those are bad ideas. The first two because they'd > reduce the quality of Fedora code _overall_, > the third because it's > silly, and the fourth because if Fedora/PPC is significantly lower in > quality than Fedora/i386 then we shouldn't release it as "Fedora" at > all. Then /do/ something about it. Don't just rely on others to find your bugs, don't just rely on the release team to find all your bugs at the last moment, don't expect QA to spend a ton of effort finding your bugs when a very tiny amount of people actually consume the work. > Ok, admittedly they were straw men... what _do_ you want to be saying? > > > We would do this /now/ so that there is enough time for interested > > parties can form a team and have it in place to handle bug reports, > > composes, etc... > > Is there an issue with the way that bug reports are handled already? > We keep the FE-ExcludeArch-ppc bug nice and empty, and the ppc64 > version as empty as it needs to be given that we favour 32-bit > userspace. That doesn't have to change. > > Let's work towards making sure that F9 QA is done for you by those who > care about the platform. Tell us what you need done in that respect, > and we'll make sure it happens. But let's not change the hosting or > other arrangements until another arch has led the way, as previously > agreed. The way to accomplish this is to put the responsibility of producing the release upon those that would consume it. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at gmail.com Mon Nov 12 14:29:28 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 12 Nov 2007 08:29:28 -0600 Subject: Why 'secondary architectures'? In-Reply-To: <80d7e4090711112026m4a1890d5o3df29aacd06c6dbc@mail.gmail.com> References: <20071109140625.4728aadd@redhat.com> <1194787316.2588.194.camel@shinybook.infradead.org> <80d7e4090711112026m4a1890d5o3df29aacd06c6dbc@mail.gmail.com> Message-ID: <20071112082928.45e91b56@vader.jdub.homelinux.org> On Sun, 11 Nov 2007 21:26:23 -0700 "Stephen John Smoogen" wrote: > On Nov 11, 2007 6:21 AM, David Woodhouse wrote: > > On Fri, 2007-11-09 at 14:06 -0500, Jesse Keating wrote: > > > Now that Fedora 8 is out, I'd like to make a suggestion with regard to > > > PPC. It's no secret that we've been talking about dropping PPC. First > > > it was all together, then it was so that it could be come a secondary > > > arch. So far, we've failed to execute. > > > > Digressing from the technical side, I'd like to properly understand your > > motivation. _Why_ do you want to do this? > > > ... Long rant snipped ... > > I would say that David is volunteering to run the PPC SIG then. He's been doing that for a long time already. josh From dwmw2 at infradead.org Mon Nov 12 19:40:31 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 12 Nov 2007 14:40:31 -0500 Subject: Dealing with PPC in Fedora 9(+) In-Reply-To: <20071112091420.09813094@redhat.com> References: <20071109140625.4728aadd@redhat.com> <1194767147.2588.149.camel@shinybook.infradead.org> <20071112091420.09813094@redhat.com> Message-ID: <1194896431.2588.370.camel@shinybook.infradead.org> On Mon, 2007-11-12 at 09:14 -0500, Jesse Keating wrote: > > I would like to stick to the agreement to keep PPC as a primary arch. > > This is _also_ because the secondary arch framework isn't in place > > yet. > > I'm making a compromise. I don't want to turn PPC into a full > secondary arch yet either, however in the places that really aren't > related to the buildsystem there is no reason why PPC can't take care > of itself. I certainly agree that we can reach such a compromise on the rel-eng/QA side. > No. The same tools have been used for Fedora 7 and 8. They've been > developed on and improved, but its the same tools. They have to be ran > on the arch they are composing, which means we can't easily use setarch > to produce ppc trees/media like we do on x86. This requires those of > us doing the compose to maintain a second machine and thread the output > back into the other arches. There is also validation of the bits, time > spent syncing them around, etc... OK, cool. This kind of thing has been black magic for so long that I'd mostly given up on trying to follow it. I may need a small amount of babysitting, because I'm not very clever. But it sounds like it makes sense for us to handle the composes for ourselves too, as you suggest. We'd still want to put them in the 'normal' download location though, for now. > > It certainly makes sense for myself and other volunteers to take a > > more active and _visible_ r?le in QA, I agree. I've been vaguely > > aware of text matrices in the wiki, but I've never been sure that it > > would be welcome for me to simply mark stuff off as 'tested'. I try > > to just make sure that when it _is_ tested, it works. > > Will's repeated pleadings for people to help out have been missed? > That's a shame. Yes, they have. And yes, it is. If that's my fault, then I apologise -- Will, please do feel free to Cc me (and fedora-ppc at lists.infradead.org) directly if you need assistance with anything related to PowerPC. And if we're not paying sufficient attention to fora which we _should_ be monitoring, please point us at them and we'll try to do better. > > > It would fall upon this team to host the bits for download at > > > release time (if no suitable framework exists for hosting the bits > > > elsewhere at various release points, rel-eng could insert them into > > > the normal tree structure as a last resort). > > > > Let's not do this yet -- the hosting, and surrounding issues about > > "Fedora" branding and mirroring, is a fairly important part of the > > "secondary architecture infrastructure" which we agreed should be in > > place and working for at least one other architecture _before_ we > > switch PowerPC over to it. > > I'm not so sure that this is the "important" part. Not "the" important part, I agree -- but "an" important part. One of the things we want to be tested out by a guinea pig first :) > It's really quite simple. If you're built from our bits, you can call > it Fedora. Put it in a directory structure that would fit well with > the rest of the mirror structure so that if mirrors chose to, they > could spend their bandwidth and disk space on mirroring ppc (or other > secondary arches). Absolutely -- and in fact we already _have_ such a structure. Mirrors can, and do, already choose which architectures to carry. I don't think we need to change the location for Fedora 9. Especially if it's likely to change again when we set it up properly for "secondary architectures". > > > We would clearly advertise that PPC is to be considered a secondary > > > arch. > > > > Advertise to whom and for what purpose? Precisely what is the message > > that you'd be trying to convey? What effect would you want to achieve? > > The term 'secondary arch' doesn't really mean a lot, in and of itself. <...> > What I want is for it to be clear that the quality of PPC is entirely > up to the the user base for it. All too often the user base, even your > self, just rely upon somebody else to find the problems, and you just > come in late in the game or the release and see "yep, everything is > still fine. No need to pay attention to alpha/beta/rawhide, it'll just > work at release time and I don't have to care.". Thanks, Jesse. Nice to know my work is entirely worthless. Here was I thinking that I'd been running rawhide, and reporting and fixing bugs (most of which didn't turn out to be arch-specific anyway). Maybe I just imagined it. <...deep breath...> I certainly have no intention of relying on somebody else to find PPC-specific problems. I start testing rawhide at about the same point in each cycle that I've _always_ started testing rawhide, even in the days where I was playing with RHL on i386. I was not aware that I came to it "late in the game", and the bugs I find when I do this usually turn out not to be PPC-specific. Perhaps I should start earlier. > If every arch did that we would miss the majority of the bugs. The > difference is on other arches, we have a very large set of users using > it every day and testing it every day and reporting all the problems > they find. We hear crickets from the ppc community. I'm dubious about the validity or relevance of that observation. You could just as well say that we hear crickets from the Kerberos-using community. If I file or fix a bug which isn't arch-specific, I don't mention PowerPC. Do you count me as an i386 user when I do that? Arch-specific bugs make up a _small_ proportion of the total, in my experience. Anyway, if we agree that the PPC SIG will take on the task of QA for F9, then that point is moot, is it not? If it isn't installable and "good enough" in time, then it doesn't go out in sync with F9/x86. > Advertising PPC as a secondary arch is a clear sign that the fate of > ppc relies upon the users of that arch. If they don't step up and pay > attention and report when there are issues, they'll likely get missed > and wind up in the final release. <...> > I want to set the expectation that the BugFreeness of PPC relies on > them the users actually using rawhide and the test releases to find the > bugs, OK, that makes some sense; thank you for clarifying. That being the intention, the best time for this 'advertisement' doesn't seem to be _now_, as you suggested -- it would be better to do it when we put out the first release candidate tree. _That_ is when we want the testers to be paying maximum attention. It's also an issue which shouldn't directly concern you -- it's up for the us (the PPC SIG) to whip our users into action when we believe we need more from them. > > if Fedora/PPC is significantly lower in quality than Fedora/i386 > > then we shouldn't release it as "Fedora" at all. > Then /do/ something about it. Don't just rely on others to find your > bugs, don't just rely on the release team to find all your bugs at the > last moment, don't expect QA to spend a ton of effort finding your > bugs <...another deep breath...> OK. Let's do it that way. I wish I'd thought of that earlier :) > The way to accomplish this is to put the responsibility of producing > the release upon those that would consume it. OK. The PPC SIG will take on the responsibility of producing the composes and doing the QA on them, for the F9 release. If we don't manage that, it won't go out on PPC. As you said, we don't need to make any changes to the build system or the way rawhide is handled right now. I don't believe it's realistic to make changes to the hosting and mirroring arrangements either -- let's stick with the plan of keeping them in the 'normal tree' which you called a last resort. We'll plan to have each spin ready on time, so it can go out fairly much synchronously with the i386 and x86_64 releases -- and more to the point, with precisely the same package set. If for some reason we slip, let's impose a rule that we may not ship any packages in the PPC spin which are not in rawhide (for the RCs) or f9-updates (for the release). OK? -- dwmw2 From jkeating at redhat.com Mon Nov 12 19:58:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Nov 2007 14:58:30 -0500 Subject: Dealing with PPC in Fedora 9(+) In-Reply-To: <1194896431.2588.370.camel@shinybook.infradead.org> References: <20071109140625.4728aadd@redhat.com> <1194767147.2588.149.camel@shinybook.infradead.org> <20071112091420.09813094@redhat.com> <1194896431.2588.370.camel@shinybook.infradead.org> Message-ID: <20071112145830.71a3535f@redhat.com> On Mon, 12 Nov 2007 14:40:31 -0500 David Woodhouse wrote: > I don't believe it's realistic to make changes to the hosting and > mirroring arrangements either -- let's stick with the plan of keeping > them in the 'normal tree' which you called a last resort. > > We'll plan to have each spin ready on time, so it can go out fairly > much synchronously with the i386 and x86_64 releases -- and more to > the point, with precisely the same package set. If for some reason we > slip, let's impose a rule that we may not ship any packages in the > PPC spin which are not in rawhide (for the RCs) or f9-updates (for > the release). > > OK? This seems a reasonable compromise all together. I can be happy with this for Fedora 9. Hopefully by the time 9 is let loose, we'll have had at least one other full fledged secondary arch up and running and proving that the method can work. @Board folks, can this be approved at your next meeting, or do I need to drive this through FESCo ? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- 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 Mon Nov 12 21:38:22 2007 From: matt at domsch.com (Matt Domsch) Date: Mon, 12 Nov 2007 15:38:22 -0600 Subject: Dealing with PPC in Fedora 9(+) In-Reply-To: <20071112145830.71a3535f@redhat.com> References: <20071109140625.4728aadd@redhat.com> <1194767147.2588.149.camel@shinybook.infradead.org> <20071112091420.09813094@redhat.com> <1194896431.2588.370.camel@shinybook.infradead.org> <20071112145830.71a3535f@redhat.com> Message-ID: <20071112213820.GA19436@domsch.com> On Mon, Nov 12, 2007 at 02:58:30PM -0500, Jesse Keating wrote: > @Board folks, can this be approved at your next meeting, or do I need > to drive this through FESCo ? To me, this seems entirely within the purvue of FESCo. It's an organization of the division of labor needed to create a given release. -Matt From jspaleta at gmail.com Mon Nov 12 21:58:22 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 12 Nov 2007 12:58:22 -0900 Subject: Dealing with PPC in Fedora 9(+) In-Reply-To: <1194896431.2588.370.camel@shinybook.infradead.org> References: <20071109140625.4728aadd@redhat.com> <1194767147.2588.149.camel@shinybook.infradead.org> <20071112091420.09813094@redhat.com> <1194896431.2588.370.camel@shinybook.infradead.org> Message-ID: <604aa7910711121358q160bb129mc336baa818ed20b5@mail.gmail.com> On Nov 12, 2007 10:40 AM, David Woodhouse wrote: > We'll plan to have each spin ready on time, so it can go out fairly much > synchronously with the i386 and x86_64 releases -- and more to the > point, with precisely the same package set. If for some reason we slip, > let's impose a rule that we may not ship any packages in the PPC spin > which are not in rawhide (for the RCs) or f9-updates (for the release). > > OK? Clarify for me one thing. Assuming you slip relative to x86 release date and you need to use f9-updates packages... what are we doing with respect to ensuring source distribution? Will you be rolling srpm isos that match the binary isos? We don't make any effort to keep srpms nor binaries for updates available for the full lifetime of a release. So i just want to make sure we know what we are doing for secondary arches to meet source distribution requirements. -jef"I am a broken record...but I don't want a pedantic source distribution requirement biting us in the ass"spaleta From dwmw2 at infradead.org Tue Nov 13 00:20:16 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 12 Nov 2007 19:20:16 -0500 Subject: Dealing with PPC in Fedora 9(+) In-Reply-To: <604aa7910711121358q160bb129mc336baa818ed20b5@mail.gmail.com> References: <20071109140625.4728aadd@redhat.com> <1194767147.2588.149.camel@shinybook.infradead.org> <20071112091420.09813094@redhat.com> <1194896431.2588.370.camel@shinybook.infradead.org> <604aa7910711121358q160bb129mc336baa818ed20b5@mail.gmail.com> Message-ID: <1194913216.2588.415.camel@shinybook.infradead.org> On Mon, 2007-11-12 at 12:58 -0900, Jeff Spaleta wrote: > Clarify for me one thing. Assuming you slip relative to x86 release > date and you need to use f9-updates packages... what are we doing with > respect to ensuring source distribution? Will you be rolling srpm > isos that match the binary isos? We don't make any effort to keep > srpms nor binaries for updates available for the full lifetime of a > release. So i just want to make sure we know what we are doing for > secondary arches to meet source distribution requirements. Hm, interesting question. In the past, when I've done 'Fedora X + stuff' releases, such as the spins I've done for newly-supported hardware like Pegasos and PS3, I've shipped the install tree with an SRPMS/ directory containing the two or three packages which I had to update. Would that be a reasonable answer? Of course, my preferred answer is just not to slip :) -- dwmw2 From smooge at gmail.com Tue Nov 13 02:26:46 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 12 Nov 2007 19:26:46 -0700 Subject: Why 'secondary architectures'? In-Reply-To: <20071112082928.45e91b56@vader.jdub.homelinux.org> References: <20071109140625.4728aadd@redhat.com> <1194787316.2588.194.camel@shinybook.infradead.org> <80d7e4090711112026m4a1890d5o3df29aacd06c6dbc@mail.gmail.com> <20071112082928.45e91b56@vader.jdub.homelinux.org> Message-ID: <80d7e4090711121826m5ebd2216w7b9761a099144f08@mail.gmail.com> On Nov 12, 2007 7:29 AM, Josh Boyer wrote: > On Sun, 11 Nov 2007 21:26:23 -0700 > "Stephen John Smoogen" wrote: > > > On Nov 11, 2007 6:21 AM, David Woodhouse wrote: > > > On Fri, 2007-11-09 at 14:06 -0500, Jesse Keating wrote: > > > > Now that Fedora 8 is out, I'd like to make a suggestion with regard to > > > > PPC. It's no secret that we've been talking about dropping PPC. First > > > > it was all together, then it was so that it could be come a secondary > > > > arch. So far, we've failed to execute. > > > > > > Digressing from the technical side, I'd like to properly understand your > > > motivation. _Why_ do you want to do this? > > > > > ... Long rant snipped ... > > > > I would say that David is volunteering to run the PPC SIG then. > > He's been doing that for a long time already. > And I am an ignoramus once again.. cranky man goes back to cleaning up users directories. -- 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 mclasen at redhat.com Tue Nov 13 13:47:56 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 13 Nov 2007 08:47:56 -0500 Subject: codec buddy pain In-Reply-To: <1194236785.4535.6.camel@localhost.localdomain> References: <1194236785.4535.6.camel@localhost.localdomain> Message-ID: <1194961676.3536.1.camel@localhost.localdomain> On Sun, 2007-11-04 at 23:26 -0500, Matthias Clasen wrote: > > while Codec Buddy only works with totem (ie) the kind of users who > > most benefit from such features will not get it since the default > > action wouldn't bring this feature up at all. > > Which is probably a plus if you take the position of Seth that we are > just handing out clean needles here... > > Anyway, rhythmbox will have this support in F9, possibly also in an F8 > update. FYI, rythmbox codeina support has just landed in rawhide. It'll find its way into an F8 update once it has seen some testing. From gdk at redhat.com Wed Nov 14 14:25:52 2007 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 14 Nov 2007 09:25:52 -0500 (EST) Subject: Red Hat Announces Fourth-Annual Red Hat Summit (fwd) Message-ID: This, by the way, will also be the location of FUDCon this summer. Working on a deal to get a corner of the summit for Fedora only, where access to FUDCon is free but access to the Summit is fee. Which could mean, oh, a thousand people at FUDCon. --g -- Greg DeKoenigsberg Community Development Manager Red Hat, Inc. :: 1-919-754-4255 "To whomsoever much hath been given... ...from him much shall be asked" ---------- Forwarded message ---------- Date: Wed, 14 Nov 2007 09:11:54 -0500 From: Kerrin Catallozzi To: media-monitor at redhat.com Subject: Red Hat Announces Fourth-Annual Red Hat Summit 11/14/07 Business Wire Red Hat Announces Fourth-Annual Red Hat Summit Customers, Partners and Open Source Community Members Invited to Join Together June 18-20 in Boston, Mass. RALEIGH, N.C.--(BUSINESS WIRE)--Red Hat (NYSE: RHT), the world's leading provider of open source solutions, today announced the fourth-annual Red Hat Summit to take place June 18-20, 2008 at the Hynes Convention Center in Boston, Mass. The Red Hat Summit is an annual conference featuring hands-on workshops, demonstrations, technical and business sessions, solutions expos and opportunities to speak and network with the developers, engineers and partners behind Red Hat's leading open source software solutions. Bringing together customers, partners and members of the community in a global open source knowledge exchange, the Red Hat Summit also highlights keynote speeches presented by visionary industry leaders. Last year, featured Summit keynoters included Red Hat CEO Matthew Szulik, Red Hat CTO Brian Stevens, Dreamworks Head of Digital Operations Derek Chan, eMusic CEO David Pakman, AMD's Henri Richard and other visionaries. ?We are thrilled to announce our fourth Red Hat Summit, to take place in Boston next June,? said Michael Chen, vice president, Corporate Marketing at Red Hat. ?The Summit has always provided high-value networking and learning opportunities. We look forward to developing a highly compelling agenda with the help of customers, partners and open source community leaders.? For more information about the Red Hat Summit 2008 in Boston, Mass., visit http://www.redhat.com/promo/summit/2008. For information about the JBoss international users conference, JBoss World Orlando, taking place Feb. 13-15, 2008, visit www.jbossworld.com . -- Kerri Catallozzi Red Hat Corporate Communications 919.754.4268 More news, more often: www.press.redhat.com From bpepple at fedoraproject.org Wed Nov 14 17:14:17 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 14 Nov 2007 12:14:17 -0500 Subject: Dealing with PPC in Fedora 9(+) In-Reply-To: <20071112213820.GA19436@domsch.com> References: <20071109140625.4728aadd@redhat.com> <1194767147.2588.149.camel@shinybook.infradead.org> <20071112091420.09813094@redhat.com> <1194896431.2588.370.camel@shinybook.infradead.org> <20071112145830.71a3535f@redhat.com> <20071112213820.GA19436@domsch.com> Message-ID: <1195060457.1858.0.camel@nixon> On Mon, 2007-11-12 at 15:38 -0600, Matt Domsch wrote: > On Mon, Nov 12, 2007 at 02:58:30PM -0500, Jesse Keating wrote: > > @Board folks, can this be approved at your next meeting, or do I need > > to drive this through FESCo ? > > To me, this seems entirely within the purvue of FESCo. It's an > organization of the division of labor needed to create a given release. Jesse, do you want me to add this to this week's FESCo schedule? /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 jspaleta at gmail.com Wed Nov 14 17:29:37 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 14 Nov 2007 08:29:37 -0900 Subject: Dealing with PPC in Fedora 9(+) In-Reply-To: <1194913216.2588.415.camel@shinybook.infradead.org> References: <20071109140625.4728aadd@redhat.com> <1194767147.2588.149.camel@shinybook.infradead.org> <20071112091420.09813094@redhat.com> <1194896431.2588.370.camel@shinybook.infradead.org> <604aa7910711121358q160bb129mc336baa818ed20b5@mail.gmail.com> <1194913216.2588.415.camel@shinybook.infradead.org> Message-ID: <604aa7910711140929x2fa80715s43ccdd7f59f6eb55@mail.gmail.com> On Nov 12, 2007 3:20 PM, David Woodhouse wrote: > In the past, when I've done 'Fedora X + stuff' releases, such as the > spins I've done for newly-supported hardware like Pegasos and PS3, I've > shipped the install tree with an SRPMS/ directory containing the two or > three packages which I had to update. Would that be a reasonable answer? Its a sufficient answer, not sure if I can reasonably answer whether its reasonable. > Of course, my preferred answer is just not to slip :) I think you should find as many ways as possible to gunk up the secondary arch workflow process now, so we can establish precedents on how to handle different problems so the sparc people don't get to. -jef"really really hates debugging code where making an unsigned integer too small makes things go crazy, especially when the new too small value use to work"spaleta From fedora at leemhuis.info Wed Nov 14 17:44:56 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 14 Nov 2007 18:44:56 +0100 Subject: Review queue/FESCo after the merge (was: Re: qct review request, no response?) In-Reply-To: <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp> References: <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp> Message-ID: <473B3418.9020207@leemhuis.info> CCing fedora-advisory-board On 14.11.2007 13:36, Mamoru Tasaka wrote: > Neal Becker wrote, at 11/14/2007 09:01 PM +9:00: >> I've seen no response to: >> https://bugzilla.redhat.com/show_bug.cgi?id=373621 >> Did I do something wrong, or is everyone busy? > Please be patient. Currently there are about 270 review requests > which are not assigned to anybody. And 1108 open reviews in total (including lots of merge reviews (?)) according to http://fedoraproject.org/wiki/PackageMaintainers/InProgressReviewRequests which redirects to https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Fedora&component=Package+Review&query_format=advanced&bug_status=ASSIGNED&bug_status=FAILS_QA&bug_status=MODIFIED&bug_status=NEEDINFO&bug_status=NEW&bug_status=ON_DEV&bug_status=ON_QA&bug_status=PASSES_QA&bug_status=POST&bug_status=RELEASE_PENDING&bug_status=VERIFIED&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&fixed_in_type=allwordssubstr&fixed_in=&qa_whiteboard_type=allwordssubstr&qa_whiteboard=&keywords_type=allwords&keywords=&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=flagtypes.name&type0-0-0=notsubstring&value0-0-0=fedora-review%2B&f ield0-1-0=bug_id&type0-1-0=notregexp&value0-1-0=%5E163776%24&field0-2-0=bug_id&type0-2-0=notregexp&value0-2-0=%5E163778%24&field0-3-0=bug_id&type0-3-0=notregexp&value0-3-0=%5E163779%24&field0-4-0=bug_id&type0-4-0=notregexp&value0-4-0=%5E177841%24 Some of them are quite old. And the list of course doesn't include those bugs that got closed as the packager lost interest over time. I think we have a problem here. I'm actually wondering what FESCo (and the Board) thinks about that. Or, to look at the big picture: During the Extras days FESCo would have taken care of something like that months ago. IIRC FESCo constantly tried to improve the workflow for reviewers and packagers to make their life easier, Extras better and everyone happy. And there were new sponsors nominated and accepted every few weeks to make sure the number of sponsors grows in parallel with the number of packagers/packages.. Both things seem to get lost during the merge(?). FESCo got lots of new things to take care of. It seems to me most of the things it took care of in the past fell of the table and nobody really takes care of them anymore these days. Or, let's say it different way: In the Extras-days FESCo made sure contributers stayed happy while we grew. These days FESCo mainly makes sure we get a distribution out every 6 months. Is this what we wanted when we designed the current governing model? I don't think so. Is it bad? Yes, I think it is, that's why I wrote this mail. Why do you think it's bad? Because I more and more often hear in private that contributers are unhappy. I also got the impression that people are more and more unwilling to participate in discussions and on lists. And there are no new leaders emerging in FESCo/packaging-land (the low number of people that volunteered during the FESCo election is one reasons for this opinion; or look at FPC -- according to the wiki the same people since one year; there is also next-to no interest by non-committee-members in participating in the meetings). What do you suggest? I'm not sure; some random ideas: Get barriers out of the way. Maybe redefine the governing model again and merge FESCo and the Board. Lower the importances of the committees -- make them coordinate and not dominate. Make reviewing easier and help people with exchanging reviews while making sure we get new sponsors. Move over to a slightly more wiki-style approach for the packages and make sure contributers are happy. Cu knurd (?) -- can't remember, but wasn't it a unwritten (or even written?) goal to get all Core packages reviewed by F8? (?) -- does anybody know how many new sponsors we got since F7? From caillon at redhat.com Wed Nov 14 17:54:04 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 14 Nov 2007 18:54:04 +0100 Subject: Review queue/FESCo after the merge In-Reply-To: <473B3418.9020207@leemhuis.info> References: <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp> <473B3418.9020207@leemhuis.info> Message-ID: <473B363C.9030808@redhat.com> Thorsten Leemhuis wrote: > And 1108 open reviews in total (including lots of merge reviews (?)) > according to > http://fedoraproject.org/wiki/PackageMaintainers/InProgressReviewRequests > > which redirects to > https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Fedora&component=Package+Review&query_format=advanced&bug_status=ASSIGNED&bug_status=FAILS_QA&bug_status=MODIFIED&bug_status=NEEDINFO&bug_status=NEW&bug_status=ON_DEV&bug_status=ON_QA&bug_status=PASSES_QA&bug_status=POST&bug_status=RELEASE_PENDING&bug_status=VERIFIED&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&fixed_in_type=allwordssubstr&fixed_in=&qa_whiteboard_type=allwordssubstr&qa_whiteboard=&keywords_type=allwords&keywords=&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=flagtypes.name&type0-0-0=notsubstring&value0-0-0=fedora-review%2B &f > ield0-1-0=bug_id&type0-1-0=notregexp&value0-1-0=%5E163776%24&field0-2-0=bug_id&type0-2-0=notregexp&value0-2-0=%5E163778%24&field0-3-0=bug_id&type0-3-0=notregexp&value0-3-0=%5E163779%24&field0-4-0=bug_id&type0-4-0=notregexp&value0-4-0=%5E177841%24 > > Some of them are quite old. And the list of course doesn't include those > bugs that got closed as the packager lost interest over time. > > > I think we have a problem here. I'm actually wondering what FESCo (and > the Board) thinks about that. Thanks for the mail, Thorsten. I've actually been thinking about this pretty recently. We have a problem, I agree. It's a problem I'm happy to have in a way because it means we're growing fast. Part of the problem is the review process itself. It encompasses several pages, many of the items are duplicated, etc. It's just unruly. And the more packaging guidelines we have, the worse it will get. I tried doing a few package reviews again recently and it annoyed me to no end to have to do this. And I understand the benefits here of doing the reviews. I think the ideal way to fix this is to have a web app that people submit packages to for review. This web app will build the SRPM in koji, can check the md5sum of the tarball vs upstream, can run rpmlint, make sure the various specfile tags are in the right format, etc etc etc -- as many things that we can automate in the review process we should automate. Once it passes the robot review, it auto files the bugzilla ticket with a link to the review, and then a human can worry about looking at the few things (s)he needs to. This will greatly improve the process for everyone IMO. Now I just need to convince someone to do this work :) From jkeating at redhat.com Wed Nov 14 21:09:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 14 Nov 2007 16:09:06 -0500 Subject: Dealing with PPC in Fedora 9(+) In-Reply-To: <1195060457.1858.0.camel@nixon> References: <20071109140625.4728aadd@redhat.com> <1194767147.2588.149.camel@shinybook.infradead.org> <20071112091420.09813094@redhat.com> <1194896431.2588.370.camel@shinybook.infradead.org> <20071112145830.71a3535f@redhat.com> <20071112213820.GA19436@domsch.com> <1195060457.1858.0.camel@nixon> Message-ID: <20071114160906.53b1bf29@redhat.com> On Wed, 14 Nov 2007 12:14:17 -0500 Brian Pepple wrote: > Jesse, do you want me to add this to this week's FESCo schedule? Please. I have a few topics, I just have to sort my thoughts :/ -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- 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 Wed Nov 14 21:13:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 14 Nov 2007 16:13:55 -0500 Subject: Dealing with PPC in Fedora 9(+) In-Reply-To: <1194913216.2588.415.camel@shinybook.infradead.org> References: <20071109140625.4728aadd@redhat.com> <1194767147.2588.149.camel@shinybook.infradead.org> <20071112091420.09813094@redhat.com> <1194896431.2588.370.camel@shinybook.infradead.org> <604aa7910711121358q160bb129mc336baa818ed20b5@mail.gmail.com> <1194913216.2588.415.camel@shinybook.infradead.org> Message-ID: <20071114161355.48ab1aeb@redhat.com> On Mon, 12 Nov 2007 19:20:16 -0500 David Woodhouse wrote: > Hm, interesting question. > > In the past, when I've done 'Fedora X + stuff' releases, such as the > spins I've done for newly-supported hardware like Pegasos and PS3, > I've shipped the install tree with an SRPMS/ directory containing the > two or three packages which I had to update. Would that be a > reasonable answer? I answered this in person with David today. When a secondary arch does a release that would match up to a primary release (like "9"), The secondary arch has a full srpm tree (since hardlinks are cheap right?). When we shuffle this into the mirror system, hardlinks will be made, and just the few differences will show up. New repodata will have to be made, but we can accomplish that. Thoughts? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- 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 Wed Nov 14 21:16:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 14 Nov 2007 16:16:57 -0500 Subject: Review queue/FESCo after the merge In-Reply-To: <473B363C.9030808@redhat.com> References: <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp> <473B3418.9020207@leemhuis.info> <473B363C.9030808@redhat.com> Message-ID: <20071114161657.06db5590@redhat.com> On Wed, 14 Nov 2007 18:54:04 +0100 Christopher Aillon wrote: > Now I just need to convince someone to do this work :) And this is the crux of the issue. Perhaps in the "old FESCo" days, more people were interested in working on this as there were some easy gains to be made. Now a days, such gains would not be easy and a lot of work would have to be put in to make things better, and there just isn't anybody volunteering to do it. Good thing we have J5 who's been tasked by Red Hat to work on this problem space. One needs not be in FESCo to work on these issues. FESCo just has to say "yes, we'd like to see that happen, and we approve this change" -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Wed Nov 14 21:24:46 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 14 Nov 2007 23:24:46 +0200 Subject: Review queue/FESCo after the merge In-Reply-To: <473B3FA8.70106@hhs.nl> References: <473B3418.9020207@leemhuis.info> <473B3FA8.70106@hhs.nl> Message-ID: <200711142324.46859.ville.skytta@iki.fi> On Wednesday 14 November 2007, Hans de Goede wrote: > Thorsten Leemhuis wrote: > > > or look at FPC -- according to the wiki the same people since one year > > Funny that you mention it, I have been thinking about joining the FPC for a > while now, so if there is a position there I'm available. We discussed rotating/adding FPC positions a few weeks ago, see http://fedoraproject.org/wiki/Packaging/Minutes20071016 Not sure if a mail asking for general interest in joining the FPC was ever sent out though, if it was, I missed it. > I don't think > I've to prove my packagingskills / knowledge and given my aversion to > bureaucracy I'll be sure to keep the guidelines mean, lean and streamlined. I think it would be great to have you (as well as other fresh blood) on board. From tcallawa at redhat.com Wed Nov 14 21:33:28 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 14 Nov 2007 16:33:28 -0500 Subject: Fedora Packaging Committee (Was: Re: Review queue/FESCo after the merge) In-Reply-To: <200711142324.46859.ville.skytta@iki.fi> References: <473B3418.9020207@leemhuis.info> <473B3FA8.70106@hhs.nl> <200711142324.46859.ville.skytta@iki.fi> Message-ID: <1195076008.3871.36.camel@localhost.localdomain> On Wed, 2007-11-14 at 23:24 +0200, Ville Skytt? wrote: > On Wednesday 14 November 2007, Hans de Goede wrote: > > Thorsten Leemhuis wrote: > > > > > or look at FPC -- according to the wiki the same people since one year > > > > Funny that you mention it, I have been thinking about joining the FPC for a > > while now, so if there is a position there I'm available. > > We discussed rotating/adding FPC positions a few weeks ago, see > http://fedoraproject.org/wiki/Packaging/Minutes20071016 > > Not sure if a mail asking for general interest in joining the FPC was ever > sent out though, if it was, I missed it. It was not, but now it will be! Are you interested in helping to shape the Fedora Packaging Guidelines? Well, of course not. Only someone truly insan... wait, what? You said yes? Are you feeling well? Sit down for a moment. Seriously, we're looking for well qualified and motivated volunteers to help us make the hard decisions on how Fedora packages should be made. If you're interested, please drop me an email off list. Must be a Fedora contributor with CVS access. Thanks, ~spot From robearro at 163.com Thu Nov 15 03:35:58 2007 From: robearro at 163.com (=?gb2312?B?tN6078HB?=) Date: Thu, 15 Nov 2007 11:35:58 +0800 Subject: ata_piix driver does not work for SATA II controller on my computer Message-ID: <200711151135583287922@163.com> Hello everybody? While I using the usb disk boot the computer for installing the fedora 8, it is long time for loading the driver for sata II controller ICH8 (ata_piix.ko) ,and then tell me cannot find any storage media of my computer. here the specs Intel P965+82801HB(ICH8) chipset 1GB DDR2 at 667Mhz 250GB SATA drive display adapter is a 7900 Nvidia on a PCI-16 slot Could anyone help me or give me some advices?Help. thanks for helping. 2007-11-15 From sundaram at fedoraproject.org Thu Nov 15 03:34:38 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 15 Nov 2007 09:04:38 +0530 Subject: ata_piix driver does not work for SATA II controller on my computer In-Reply-To: <200711151135583287922@163.com> References: <200711151135583287922@163.com> Message-ID: <473BBE4E.90007@fedoraproject.org> ??? wrote: > Hello everybody? > While I using the usb disk boot the computer for installing the fedora 8, it is long time for loading the driver for sata II controller ICH8 (ata_piix.ko) ,and then tell me cannot find any storage media of my computer. > here the specs > Intel P965+82801HB(ICH8) chipset > 1GB DDR2 at 667Mhz > 250GB SATA drive > display adapter is a 7900 Nvidia on a PCI-16 slot > > Could anyone help me or give me some advices?Help. > > thanks for helping. You are on the wrong list. Try fedora-list for end user help. http://fedoraproject.org/wiki/Communicate. Rahul From robearro at 163.com Thu Nov 15 05:06:46 2007 From: robearro at 163.com (=?gb2312?B?tN6078HB?=) Date: Thu, 15 Nov 2007 13:06:46 +0800 Subject: ata_piix driver does not work for SATA II controller on mycomputer References: <200711151135583287922@163.com>, <473BBE4E.90007@fedoraproject.org> Message-ID: <200711151306457965786@163.com> OK, thanks. robearro wrote: > Hello everybody? > While I using the usb disk boot the computer for installing the fedora 8, it is long time for loading the driver for sata II controller ICH8 (ata_piix.ko) ,and then tell me cannot find any storage media of my computer. > here the specs > Intel P965+82801HB(ICH8) chipset > 1GB DDR2 at 667Mhz > 250GB SATA drive > display adapter is a 7900 Nvidia on a PCI-16 slot > > Could anyone help me or give me some advices?Help. > > thanks for helping. You are on the wrong list. Try fedora-list for end user help. http://fedoraproject.org/wiki/Communicate. Rahul _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board at redhat.com http://www.redhat.com/mailman/listinfo/fedora-advisory-board From kanarip at kanarip.com Thu Nov 15 15:58:30 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 15 Nov 2007 16:58:30 +0100 Subject: Fedora Unity releases Fedora 8 Everything Spin Message-ID: <473C6CA6.3090209@kanarip.com> The Fedora Unity Project is proud to announce the release of new spin, the Everything Spin. Included in this spin are all the packages available at the time Fedora 8 was released. The Everything spin has been long anticipated[1] and is now available for download. The ISO images are available for i386 and x86_64 architectures starting Thursday, November 15th, 2007. This release, unlike the Everything Spin for Fedora 7[2], is made available via Jigdo[3]. We have included CD ISO image sets for those in the Fedora community that do not have DVD drives or burners available, and just because it's fun using them[4]. This spin also includes 3 DVD images for each architecture, as well as 2 DVD Dual Layer images for those who are able to use them. Please mind that the second DVD Dual Layer ISO images is actually small enough to be burned onto a normal DVD. If you are interested in helping with the testing or mirroring efforts, please contact the Fedora Unity team. Contact information is available at http://fedoraunity.org/ or the #fedora-unity channel on the Freenode IRC Network (irc.freenode.net). Go to http://spins.fedoraunity.org/ to get the bits! To report bugs in the Re-Spins please use http://bugs.fedoraunity.org/ Kind regards, Jeroen van Meeuwen Fedora Unity Founder kanarip at fedoraunity.org Fedora is a trademark of Red Hat, Inc. [1] "Everything Spin?" -thread on fedora-advisory-board m-l. https://www.redhat.com/archives/fedora-advisory-board/2007-May/msg00028.html [2] Fedora 7 Everything Spin Torrents http://fedora.kanarip.com/torrents/ [3a] Releasing Fedora via Jigdo http://fedoraproject.org/wiki/Features/JigdoRelease [3b] Using Jigdo http://fedorasolved.org/post-install-solutions/jigdo/ [4] Screenshot of Everything (*) Installation using CD images http://kanarip.fedorapeople.org/Fedora-8-Everything%20CD%20Installation%20Media.png From sundaram at fedoraproject.org Thu Nov 15 20:16:30 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 16 Nov 2007 01:46:30 +0530 Subject: Legal update In-Reply-To: <1194448021.3148.61.camel@localhost.localdomain> References: <1194448021.3148.61.camel@localhost.localdomain> Message-ID: <473CA91E.2040501@fedoraproject.org> Tom "spot" Callaway wrote: > Linking to "third party repositories": Legal says that we can link, from > the Fedora website, to third party repositories, so long as no one has > made a critical assessment to determine that a patent or patents cover > the technology in question and no party has actually asserted their > patents against the technology, we should be okay. Once we are on notice > of a claim of infringement or are aware of a competent assessment that > concludes infringement is likely, we would need to take the link down or > run a serious risk of facing a claim for inducing infringement. Merely > linking would be highly unlikely to subject us to a claim of direct > infringement. I asked about MP3, and it was stated that unless we are > specifically aware of the MP3 patent holders asserting a claim against > the technology, we are still okay. So the real question now that Red Hat Legal is ok with it is whether we in the Fedora Project should be doing it? I think we should link to RPM Fusion (the free part) in the future if and when it's up and running from codeina as a alternative to Fluendo codecs since that is the reason why I wanted [1] to ask this question and why I requested RPM Fusion folks to split the repository into two parts. Free (but potentially patent encumbered) and non-free. If we want to do this, the exact wording and methodology that would satisfy our legal obligations should be discussed too. Rahul [1] http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-board/2717 From notting at redhat.com Thu Nov 15 20:33:10 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Nov 2007 15:33:10 -0500 Subject: Legal update In-Reply-To: <473CA91E.2040501@fedoraproject.org> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> Message-ID: <20071115203310.GA7042@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: >> Linking to "third party repositories": Legal says that we can link, from >> the Fedora website, to third party repositories, so long as no one has >> made a critical assessment to determine that a patent or patents cover >> the technology in question and no party has actually asserted their >> patents against the technology, we should be okay. Once we are on notice >> of a claim of infringement or are aware of a competent assessment that >> concludes infringement is likely, we would need to take the link down or >> run a serious risk of facing a claim for inducing infringement. Merely >> linking would be highly unlikely to subject us to a claim of direct >> infringement. I asked about MP3, and it was stated that unless we are >> specifically aware of the MP3 patent holders asserting a claim against >> the technology, we are still okay. > > So the real question now that Red Hat Legal is ok with it is whether we in > the Fedora Project should be doing it? > > I think we should link to RPM Fusion (the free part) in the future if and > when it's up and running from codeina ... in what way? The codeina codec list is included in the packaging. Bill From sundaram at fedoraproject.org Fri Nov 16 08:26:30 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 16 Nov 2007 13:56:30 +0530 Subject: Legal update In-Reply-To: <20071115203310.GA7042@nostromo.devel.redhat.com> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> Message-ID: <473D5436.3080201@fedoraproject.org> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >>> Linking to "third party repositories": Legal says that we can link, from >>> the Fedora website, to third party repositories, so long as no one has >>> made a critical assessment to determine that a patent or patents cover >>> the technology in question and no party has actually asserted their >>> patents against the technology, we should be okay. Once we are on notice >>> of a claim of infringement or are aware of a competent assessment that >>> concludes infringement is likely, we would need to take the link down or >>> run a serious risk of facing a claim for inducing infringement. Merely >>> linking would be highly unlikely to subject us to a claim of direct >>> infringement. I asked about MP3, and it was stated that unless we are >>> specifically aware of the MP3 patent holders asserting a claim against >>> the technology, we are still okay. >> So the real question now that Red Hat Legal is ok with it is whether we in >> the Fedora Project should be doing it? >> >> I think we should link to RPM Fusion (the free part) in the future if and >> when it's up and running from codeina > > ... in what way? The codeina codec list is included in the packaging. In the initial dialog box perhaps? I don't know what would be the most appropriate thing to do. Rahul From tcallawa at redhat.com Fri Nov 16 13:42:28 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 16 Nov 2007 08:42:28 -0500 Subject: Legal update In-Reply-To: <473D5436.3080201@fedoraproject.org> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> Message-ID: <1195220548.3238.6.camel@localhost.localdomain> On Fri, 2007-11-16 at 13:56 +0530, Rahul Sundaram wrote: > Bill Nottingham wrote: > > Rahul Sundaram (sundaram at fedoraproject.org) said: > >>> Linking to "third party repositories": Legal says that we can link, from > >>> the Fedora website, to third party repositories, so long as no one has > >>> made a critical assessment to determine that a patent or patents cover > >>> the technology in question and no party has actually asserted their > >>> patents against the technology, we should be okay. Once we are on notice > >>> of a claim of infringement or are aware of a competent assessment that > >>> concludes infringement is likely, we would need to take the link down or > >>> run a serious risk of facing a claim for inducing infringement. Merely > >>> linking would be highly unlikely to subject us to a claim of direct > >>> infringement. I asked about MP3, and it was stated that unless we are > >>> specifically aware of the MP3 patent holders asserting a claim against > >>> the technology, we are still okay. > >> So the real question now that Red Hat Legal is ok with it is whether we in > >> the Fedora Project should be doing it? > >> > >> I think we should link to RPM Fusion (the free part) in the future if and > >> when it's up and running from codeina > > > > ... in what way? The codeina codec list is included in the packaging. > > In the initial dialog box perhaps? I don't know what would be the most > appropriate thing to do. You cannot link to livna/RPM Fusion from within a package, RH Legal was very clear on that. You can link to the Fedoraproject.org page that links to it, but not directly to it. ~spot From stickster at gmail.com Fri Nov 16 14:24:43 2007 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 16 Nov 2007 09:24:43 -0500 Subject: Legal update In-Reply-To: <473D5436.3080201@fedoraproject.org> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> Message-ID: <1195223083.19379.24.camel@localhost.localdomain> On Fri, 2007-11-16 at 13:56 +0530, Rahul Sundaram wrote: > Bill Nottingham wrote: > > Rahul Sundaram (sundaram at fedoraproject.org) said: > >> I think we should link to RPM Fusion (the free part) in the future if and > >> when it's up and running from codeina > > > > ... in what way? The codeina codec list is included in the packaging. > > In the initial dialog box perhaps? I don't know what would be the most > appropriate thing to do. Yeah, I think Rahul is talking about a simple link and not extending codeina to support system-wide RPM installation. To me, the latter would cut down on the whole reason behind having a sermon dialog, since only the first user on a system would ever see it in that case, if they take the non-free route. Granted, most use cases for this fall into the single-user box, like a laptop or home desktop, but coding just for that case potentially cuts out a lot of the educable audience. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://pfrields.fedorapeople.org/ 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 Fri Nov 16 14:23:12 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 16 Nov 2007 19:53:12 +0530 Subject: Legal update In-Reply-To: <1195220548.3238.6.camel@localhost.localdomain> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> <1195220548.3238.6.camel@localhost.localdomain> Message-ID: <473DA7D0.9010801@fedoraproject.org> Tom "spot" Callaway wrote: > On Fri, 2007-11-16 at 13:56 +0530, Rahul Sundaram wrote: >> Bill Nottingham wrote: >>> Rahul Sundaram (sundaram at fedoraproject.org) said: >>>>> Linking to "third party repositories": Legal says that we can link, from >>>>> the Fedora website, to third party repositories, so long as no one has >>>>> made a critical assessment to determine that a patent or patents cover >>>>> the technology in question and no party has actually asserted their >>>>> patents against the technology, we should be okay. Once we are on notice >>>>> of a claim of infringement or are aware of a competent assessment that >>>>> concludes infringement is likely, we would need to take the link down or >>>>> run a serious risk of facing a claim for inducing infringement. Merely >>>>> linking would be highly unlikely to subject us to a claim of direct >>>>> infringement. I asked about MP3, and it was stated that unless we are >>>>> specifically aware of the MP3 patent holders asserting a claim against >>>>> the technology, we are still okay. >>>> So the real question now that Red Hat Legal is ok with it is whether we in >>>> the Fedora Project should be doing it? >>>> >>>> I think we should link to RPM Fusion (the free part) in the future if and >>>> when it's up and running from codeina >>> ... in what way? The codeina codec list is included in the packaging. >> In the initial dialog box perhaps? I don't know what would be the most >> appropriate thing to do. > > You cannot link to livna/RPM Fusion from within a package, RH Legal was > very clear on that. You can link to the Fedoraproject.org page that > links to it, but not directly to it. I had the impression that it was about linking to the repository package directly instead of just the website? If even linking to the website itself from a dialog box in codeina is not ok with Red Hat Legal, we could either update http://fedoraproject.org/wiki/CodecBuddy or in the second dialog where it lists the Fluendo codecs, we could introduce a new link that says "click here for free alternatives" or something similar. Is that ok? Rahul From tcallawa at redhat.com Fri Nov 16 14:31:21 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 16 Nov 2007 09:31:21 -0500 Subject: Legal update In-Reply-To: <473DA7D0.9010801@fedoraproject.org> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> <1195220548.3238.6.camel@localhost.localdomain> <473DA7D0.9010801@fedoraproject.org> Message-ID: <1195223481.3238.17.camel@localhost.localdomain> On Fri, 2007-11-16 at 19:53 +0530, Rahul Sundaram wrote: > Tom "spot" Callaway wrote: > > On Fri, 2007-11-16 at 13:56 +0530, Rahul Sundaram wrote: > >> Bill Nottingham wrote: > >>> Rahul Sundaram (sundaram at fedoraproject.org) said: > >>>>> Linking to "third party repositories": Legal says that we can link, from > >>>>> the Fedora website, to third party repositories, so long as no one has > >>>>> made a critical assessment to determine that a patent or patents cover > >>>>> the technology in question and no party has actually asserted their > >>>>> patents against the technology, we should be okay. Once we are on notice > >>>>> of a claim of infringement or are aware of a competent assessment that > >>>>> concludes infringement is likely, we would need to take the link down or > >>>>> run a serious risk of facing a claim for inducing infringement. Merely > >>>>> linking would be highly unlikely to subject us to a claim of direct > >>>>> infringement. I asked about MP3, and it was stated that unless we are > >>>>> specifically aware of the MP3 patent holders asserting a claim against > >>>>> the technology, we are still okay. > >>>> So the real question now that Red Hat Legal is ok with it is whether we in > >>>> the Fedora Project should be doing it? > >>>> > >>>> I think we should link to RPM Fusion (the free part) in the future if and > >>>> when it's up and running from codeina > >>> ... in what way? The codeina codec list is included in the packaging. > >> In the initial dialog box perhaps? I don't know what would be the most > >> appropriate thing to do. > > > > You cannot link to livna/RPM Fusion from within a package, RH Legal was > > very clear on that. You can link to the Fedoraproject.org page that > > links to it, but not directly to it. > > I had the impression that it was about linking to the repository package > directly instead of just the website? If even linking to the website > itself from a dialog box in codeina is not ok with Red Hat Legal, we > could either update http://fedoraproject.org/wiki/CodecBuddy or in the > second dialog where it lists the Fluendo codecs, we could introduce a > new link that says "click here for free alternatives" or something > similar. Is that ok? The semantics of the how are not really my call, as long as you follow these two rules: 1. The only place we can link to 3rd party repositories is from fedoraproject.org, under the terms that I originally described. 2. We cannot directly link to 3rd party repositories from any Fedora package. ~spot From stickster at gmail.com Fri Nov 16 14:35:35 2007 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 16 Nov 2007 09:35:35 -0500 Subject: Legal update In-Reply-To: <1195220548.3238.6.camel@localhost.localdomain> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> <1195220548.3238.6.camel@localhost.localdomain> Message-ID: <1195223735.19379.35.camel@localhost.localdomain> On Fri, 2007-11-16 at 08:42 -0500, Tom "spot" Callaway wrote: > On Fri, 2007-11-16 at 13:56 +0530, Rahul Sundaram wrote: > > Bill Nottingham wrote: > > > Rahul Sundaram (sundaram at fedoraproject.org) said: > > >> I think we should link to RPM Fusion (the free part) in the future if and > > >> when it's up and running from codeina > > > > > > ... in what way? The codeina codec list is included in the packaging. > > > > In the initial dialog box perhaps? I don't know what would be the most > > appropriate thing to do. > > You cannot link to livna/RPM Fusion from within a package, RH Legal was > very clear on that. You can link to the Fedoraproject.org page that > links to it, but not directly to it. Any such fp.o page, then, should be concise and emphasize the importance of free formats once again. Making the change to codeina in this case is pretty trivial once that page is up to snuff. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://pfrields.fedorapeople.org/ 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 skvidal at fedoraproject.org Fri Nov 16 14:37:33 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 16 Nov 2007 09:37:33 -0500 Subject: Legal update In-Reply-To: <1195223481.3238.17.camel@localhost.localdomain> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> <1195220548.3238.6.camel@localhost.localdomain> <473DA7D0.9010801@fedoraproject.org> <1195223481.3238.17.camel@localhost.localdomain> Message-ID: <1195223853.23955.107.camel@cutter> On Fri, 2007-11-16 at 09:31 -0500, Tom "spot" Callaway wrote: > The semantics of the how are not really my call, as long as you follow > these two rules: > > 1. The only place we can link to 3rd party repositories is from > fedoraproject.org, under the terms that I originally described. > > 2. We cannot directly link to 3rd party repositories from any Fedora > package. > If codeina used a file housed on fp.o that talked about livna and fluendo, etc, would that be acceptable? essentially, if we modified codeina to get this file: /usr/share/codeina/xml/available-plugins.xml from our website. Or referred to our site from that file, even. that sounds like it is within the rules. -sv From tcallawa at redhat.com Fri Nov 16 14:49:52 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 16 Nov 2007 09:49:52 -0500 Subject: Legal update In-Reply-To: <1195223853.23955.107.camel@cutter> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> <1195220548.3238.6.camel@localhost.localdomain> <473DA7D0.9010801@fedoraproject.org> <1195223481.3238.17.camel@localhost.localdomain> <1195223853.23955.107.camel@cutter> Message-ID: <1195224592.3238.25.camel@localhost.localdomain> On Fri, 2007-11-16 at 09:37 -0500, seth vidal wrote: > On Fri, 2007-11-16 at 09:31 -0500, Tom "spot" Callaway wrote: > > > The semantics of the how are not really my call, as long as you follow > > these two rules: > > > > 1. The only place we can link to 3rd party repositories is from > > fedoraproject.org, under the terms that I originally described. > > > > 2. We cannot directly link to 3rd party repositories from any Fedora > > package. > > > > If codeina used a file housed on fp.o that talked about livna and > fluendo, etc, would that be acceptable? > > essentially, if we modified codeina to get this file: > /usr/share/codeina/xml/available-plugins.xml > > from our website. Or referred to our site from that file, even. > > that sounds like it is within the rules. If we link to the fedoraproject.org page, rather than include it in the package, it is fine. To be crystal clear: Thou shalt not mention 3rd party repositories inside any file which lives in a Fedora package. Codeina could say "look at this URL for other options", and point to http://fedoraproject.org/wiki/ThirdPartyRepositories I'm pretty sure we cannot offer up a .xml file which configures livna like you're describing. ~spot From notting at redhat.com Fri Nov 16 13:49:10 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 16 Nov 2007 08:49:10 -0500 Subject: Legal update In-Reply-To: <473D5436.3080201@fedoraproject.org> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> Message-ID: <20071116134910.GA27479@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: >>> I think we should link to RPM Fusion (the free part) in the future if and >>> when it's up and running from codeina >> ... in what way? The codeina codec list is included in the packaging. > > In the initial dialog box perhaps? I don't know what would be the most > appropriate thing to do. That is not 'on the website' either. Bill From sundaram at fedoraproject.org Fri Nov 16 14:50:19 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 16 Nov 2007 20:20:19 +0530 Subject: Legal update In-Reply-To: <20071116134910.GA27479@nostromo.devel.redhat.com> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> <20071116134910.GA27479@nostromo.devel.redhat.com> Message-ID: <473DAE2B.5070406@fedoraproject.org> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >>>> I think we should link to RPM Fusion (the free part) in the future if and >>>> when it's up and running from codeina >>> ... in what way? The codeina codec list is included in the packaging. >> In the initial dialog box perhaps? I don't know what would be the most >> appropriate thing to do. > > That is not 'on the website' either. See my other mail for more details. Rahul From tcallawa at redhat.com Fri Nov 16 14:55:04 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 16 Nov 2007 09:55:04 -0500 Subject: Legal update In-Reply-To: <1195224592.3238.25.camel@localhost.localdomain> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> <1195220548.3238.6.camel@localhost.localdomain> <473DA7D0.9010801@fedoraproject.org> <1195223481.3238.17.camel@localhost.localdomain> <1195223853.23955.107.camel@cutter> <1195224592.3238.25.camel@localhost.localdomain> Message-ID: <1195224904.3238.29.camel@localhost.localdomain> On Fri, 2007-11-16 at 09:49 -0500, Tom "spot" Callaway wrote: > I'm pretty sure we cannot offer up a .xml file which configures livna > like you're describing. FWIW, I can pose this question to RH Legal if we want. Specifically, I can ask: "Are we permitted to offer a file on the Fedoraproject.org website (not in a package) which would allow Fedora users to enable a third party repository, and install content from it?" This would cover the .xml files and yum configs, for example. ~spot From sundaram at fedoraproject.org Fri Nov 16 14:56:52 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 16 Nov 2007 20:26:52 +0530 Subject: Legal update In-Reply-To: <1195224904.3238.29.camel@localhost.localdomain> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> <1195220548.3238.6.camel@localhost.localdomain> <473DA7D0.9010801@fedoraproject.org> <1195223481.3238.17.camel@localhost.localdomain> <1195223853.23955.107.camel@cutter> <1195224592.3238.25.camel@localhost.localdomain> <1195224904.3238.29.camel@localhost.localdomain> Message-ID: <473DAFB4.7090703@fedoraproject.org> Tom "spot" Callaway wrote: > On Fri, 2007-11-16 at 09:49 -0500, Tom "spot" Callaway wrote: >> I'm pretty sure we cannot offer up a .xml file which configures livna >> like you're describing. > > FWIW, I can pose this question to RH Legal if we want. Specifically, I > can ask: > > "Are we permitted to offer a file on the Fedoraproject.org website (not > in a package) which would allow Fedora users to enable a third party > repository, and install content from it?" > > This would cover the .xml files and yum configs, for example. That's what SUSE does though they point to separate website which has a xml file that will install a package from another repository and that is being advertised as "one click" install. Rahul From notting at redhat.com Fri Nov 16 15:05:09 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 16 Nov 2007 10:05:09 -0500 Subject: Legal update In-Reply-To: <473DA7D0.9010801@fedoraproject.org> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> <1195220548.3238.6.camel@localhost.localdomain> <473DA7D0.9010801@fedoraproject.org> Message-ID: <20071116150509.GA31346@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > I had the impression that it was about linking to the repository package > directly instead of just the website? If even linking to the website itself > from a dialog box in codeina is not ok with Red Hat Legal, It's not. What part of 'you may not link to the repository in the software' is hard to understand? > update http://fedoraproject.org/wiki/CodecBuddy or in the second dialog > where it lists the Fluendo codecs, we could introduce a new link that says > "click here for free alternatives" or something similar. Is that ok? Again, that second dialog is in the software itself, populated from the XML file. Bill From tcallawa at redhat.com Fri Nov 16 15:07:39 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 16 Nov 2007 10:07:39 -0500 Subject: Legal update In-Reply-To: <473DAFB4.7090703@fedoraproject.org> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> <1195220548.3238.6.camel@localhost.localdomain> <473DA7D0.9010801@fedoraproject.org> <1195223481.3238.17.camel@localhost.localdomain> <1195223853.23955.107.camel@cutter> <1195224592.3238.25.camel@localhost.localdomain> <1195224904.3238.29.camel@localhost.localdomain> <473DAFB4.7090703@fedoraproject.org> Message-ID: <1195225659.3238.43.camel@localhost.localdomain> On Fri, 2007-11-16 at 20:26 +0530, Rahul Sundaram wrote: > Tom "spot" Callaway wrote: > > On Fri, 2007-11-16 at 09:49 -0500, Tom "spot" Callaway wrote: > >> I'm pretty sure we cannot offer up a .xml file which configures livna > >> like you're describing. > > > > FWIW, I can pose this question to RH Legal if we want. Specifically, I > > can ask: > > > > "Are we permitted to offer a file on the Fedoraproject.org website (not > > in a package) which would allow Fedora users to enable a third party > > repository, and install content from it?" > > > > This would cover the .xml files and yum configs, for example. > > That's what SUSE does though they point to separate website which has a > xml file that will install a package from another repository and that is > being advertised as "one click" install. We can't directly link to another repository's website from our package. We can link to a page on fedoraproject.org, which has a link to an .xml file hosted by that repository. Of course, that's not ideal, you don't want to hand an .xml file to a user and say "go forth"! I know I'm sounding like a broken record, but we've been given a very narrow path to follow, and we need to be careful not to confuse it for a superhighway. ~spot From skvidal at fedoraproject.org Fri Nov 16 15:09:13 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 16 Nov 2007 10:09:13 -0500 Subject: Legal update In-Reply-To: <1195224904.3238.29.camel@localhost.localdomain> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> <1195220548.3238.6.camel@localhost.localdomain> <473DA7D0.9010801@fedoraproject.org> <1195223481.3238.17.camel@localhost.localdomain> <1195223853.23955.107.camel@cutter> <1195224592.3238.25.camel@localhost.localdomain> <1195224904.3238.29.camel@localhost.localdomain> Message-ID: <1195225753.24228.0.camel@cutter> On Fri, 2007-11-16 at 09:55 -0500, Tom "spot" Callaway wrote: > On Fri, 2007-11-16 at 09:49 -0500, Tom "spot" Callaway wrote: > > I'm pretty sure we cannot offer up a .xml file which configures livna > > like you're describing. > > FWIW, I can pose this question to RH Legal if we want. Specifically, I > can ask: > > "Are we permitted to offer a file on the Fedoraproject.org website (not > in a package) which would allow Fedora users to enable a third party > repository, and install content from it?" > > This would cover the .xml files and yum configs, for example. > please do so. If we can do this then we can essentially make these files be much like the mirrorlists and they would allow us a stepping stone around the problem. -sv From sundaram at fedoraproject.org Fri Nov 16 15:09:26 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 16 Nov 2007 20:39:26 +0530 Subject: Legal update In-Reply-To: <20071116150509.GA31346@nostromo.devel.redhat.com> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> <1195220548.3238.6.camel@localhost.localdomain> <473DA7D0.9010801@fedoraproject.org> <20071116150509.GA31346@nostromo.devel.redhat.com> Message-ID: <473DB2A6.5070605@fedoraproject.org> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >> I had the impression that it was about linking to the repository package >> directly instead of just the website? If even linking to the website itself >> from a dialog box in codeina is not ok with Red Hat Legal, > > It's not. What part of 'you may not link to the repository in the software' > is hard to understand? The "repository" might mean either a website that hosts the repository or a .repo or repo release rpm file. There might be a legal difference in between these. I am merely asking for some clarifications. >> update http://fedoraproject.org/wiki/CodecBuddy or in the second dialog >> where it lists the Fluendo codecs, we could introduce a new link that says >> "click here for free alternatives" or something similar. Is that ok? > > Again, that second dialog is in the software itself, populated from the > XML file. Click here for free alternatives could lead to some page in the Fedora wiki which then would lead to the third party repository. I don't know the implementation details enough to know whether it is possible currently. If not, it could probably be modified to do this. The question I am asking is really whether we want to do this or not in the first place. Rahul From notting at redhat.com Fri Nov 16 15:28:55 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 16 Nov 2007 10:28:55 -0500 Subject: Legal update In-Reply-To: <473DB2A6.5070605@fedoraproject.org> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> <1195220548.3238.6.camel@localhost.localdomain> <473DA7D0.9010801@fedoraproject.org> <20071116150509.GA31346@nostromo.devel.redhat.com> <473DB2A6.5070605@fedoraproject.org> Message-ID: <20071116152855.GA422@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > Bill Nottingham wrote: >> Rahul Sundaram (sundaram at fedoraproject.org) said: >>> I had the impression that it was about linking to the repository package >>> directly instead of just the website? If even linking to the website >>> itself from a dialog box in codeina is not ok with Red Hat Legal, >> It's not. What part of 'you may not link to the repository in the >> software' >> is hard to understand? > > The "repository" might mean either a website that hosts the repository or a > .repo or repo release rpm file. There might be a legal difference in > between these. I am merely asking for some clarifications. In *either* case of what you're saying, the answer for 'from a dialog box in codeina' is still no. >>> update http://fedoraproject.org/wiki/CodecBuddy or in the second dialog >>> where it lists the Fluendo codecs, we could introduce a new link that >>> says "click here for free alternatives" or something similar. Is that ok? >> Again, that second dialog is in the software itself, populated from the >> XML file. > > Click here for free alternatives could lead to some page in the Fedora wiki > which then would lead to the third party repository. I don't know the > implementation details enough to know whether it is possible currently. Then don't repeatedly ask 'can we do X' when informed that the software can't do X. Bill From sundaram at fedoraproject.org Fri Nov 16 15:26:48 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 16 Nov 2007 20:56:48 +0530 Subject: Legal update In-Reply-To: <20071116152855.GA422@nostromo.devel.redhat.com> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> <1195220548.3238.6.camel@localhost.localdomain> <473DA7D0.9010801@fedoraproject.org> <20071116150509.GA31346@nostromo.devel.redhat.com> <473DB2A6.5070605@fedoraproject.org> <20071116152855.GA422@nostromo.devel.redhat.com> Message-ID: <473DB6B8.7070806@fedoraproject.org> Bill Nottingham wrote: > Then don't repeatedly ask 'can we do X' when informed that the software > can't do X. If we wanted to do this, obviously the software could be modified. The question again boils down to do we want to do this? Rahul From notting at redhat.com Fri Nov 16 15:40:57 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 16 Nov 2007 10:40:57 -0500 Subject: Legal update In-Reply-To: <473DB6B8.7070806@fedoraproject.org> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> <1195220548.3238.6.camel@localhost.localdomain> <473DA7D0.9010801@fedoraproject.org> <20071116150509.GA31346@nostromo.devel.redhat.com> <473DB2A6.5070605@fedoraproject.org> <20071116152855.GA422@nostromo.devel.redhat.com> <473DB6B8.7070806@fedoraproject.org> Message-ID: <20071116154057.GB422@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > Bill Nottingham wrote: > >> Then don't repeatedly ask 'can we do X' when informed that the software >> can't do X. > > If we wanted to do this, obviously the software could be modified. The > question again boils down to do we want to do this? That's not what I'm talking about. Spot said very clearly that *the software can not link to the third party repo.* You have then asked if, and I quote: - "we could link to RPM fusion from codeina" (i.e., link to the third party repo from the software (codeina)) - "[we could link to the repo] in the initial dialog box perhaps?" (i.e., linking to the repo from the dialog box, which is part of the software) - "linking to the [rpmfusion] webiste itself from a dialog box in codeina" (i.e., linking to a third party repo from a dialog box, which is part of the software) - "in the second dialog where it lists the Fluendo codecs, we could introduce a new link [to the third party repo] that says..." (i.e., link from the dialog, which is part of the software, to the third party repo) So, asking 'if we want to do this' is silly, as every example you've given is *exactly what we were told we could not do.* Bill From sundaram at fedoraproject.org Fri Nov 16 15:45:25 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 16 Nov 2007 21:15:25 +0530 Subject: Legal update In-Reply-To: <20071116154057.GB422@nostromo.devel.redhat.com> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> <1195220548.3238.6.camel@localhost.localdomain> <473DA7D0.9010801@fedoraproject.org> <20071116150509.GA31346@nostromo.devel.redhat.com> <473DB2A6.5070605@fedoraproject.org> <20071116152855.GA422@nostromo.devel.redhat.com> <473DB6B8.7070806@fedoraproject.org> <20071116154057.GB422@nostromo.devel.redhat.com> Message-ID: <473DBB15.1050704@fedoraproject.org> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >> Bill Nottingham wrote: >> >>> Then don't repeatedly ask 'can we do X' when informed that the software >>> can't do X. >> If we wanted to do this, obviously the software could be modified. The >> question again boils down to do we want to do this? > > That's not what I'm talking about. > > Spot said very clearly that *the software can not link to the third > party repo.* > > You have then asked if, and I quote: > > - "we could link to RPM fusion from codeina" (i.e., link to the third > party repo from the software (codeina)) > - "[we could link to the repo] in the initial dialog box perhaps?" (i.e., > linking to the repo from the dialog box, which is part of the software) > - "linking to the [rpmfusion] webiste itself from a dialog box in codeina" > (i.e., linking to a third party repo from a dialog box, which is part of > the software) > - "in the second dialog where it lists the Fluendo codecs, we could introduce > a new link [to the third party repo] that says..." (i.e., link from > the dialog, which is part of the software, to the third party repo) > > So, asking 'if we want to do this' is silly, as every example you've given > is *exactly what we were told we could not do.* You have skipped some of what I said. Spot has said you can't link *directly* either the website or the software repository but some of my suggestions were not that. I specifically mentioned that we could add some information to the CodecBuddy page in the wiki about RPM Fusion which is certainly possible if we wanted to. My third suggestion that you have mentioned wasn't about a direct link either which you assumed it was. The link would go a Fedora Project wiki page which would explain our view points and then also link to RPM Fusion. Does that clarify what I said? Rahul From monkeyboythom at gmail.com Fri Nov 16 16:06:20 2007 From: monkeyboythom at gmail.com (Monkey Boy) Date: Fri, 16 Nov 2007 11:06:20 -0500 Subject: Legal Update Message-ID: To all, I wonder if this goes far enough? Could someone not technically astute to see that Fedora is indeed trying to coexist with usability and the letter of the law, try to identify the XML files as the same as Bittorrent tracker files? I know...there is a big difference between storing a key mapping file of stolen or unauthorized copies of material versus hosting configuration files of software that may or may not be legally acceptable around the world (or even in just one country). Could you turn the requirement on it's ear and be even more specific on the Wiki page? Instead of saying here are some third parties links to stuff that may or may not be legal in your country why not explicitly say what is legal in what country? You could have Third-party names listed under individual countries. (Does the EU count as one country?) And under the United State section you can have the sound of crickets chirping. What I'm getting at is that by explaining what is known to be legal in a particular country is more effective than listing out the third party links and saying to the reader, "good luck in your country." Also, it give those who live in a country that does not accept that as legal the ability to judge for themselves as to whether or not they should install. I hope I haven't confused the issue more. Thanks, Thom If we link to the fedoraproject.org page, rather than include it in the > package, it is fine. > > To be crystal clear: > > Thou shalt not mention 3rd party repositories inside any file which > lives in a Fedora package. > > Codeina could say "look at this URL for other options", and point to > http://fedoraproject.org/wiki/ThirdPartyRepositories > > I'm pretty sure we cannot offer up a .xml file which configures livna > like you're describing. > > ~spot > -- The difference between blogging and flogging is that flogging actually leaves an impression on people. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Fri Nov 16 17:10:06 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 16 Nov 2007 08:10:06 -0900 Subject: Legal Update In-Reply-To: References: Message-ID: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> On Nov 16, 2007 7:06 AM, Monkey Boy wrote: > Could you turn the requirement on it's ear and be even more specific on the > Wiki page? Instead of saying here are some third parties links to stuff that > may or may not be legal in your country why not explicitly say what is legal > in what country? Are you offering to find lawyers who are experts in each country's legal system who are willing to provide binding legal advice and liability coverage concerning the accuracy of such lists? Or were you thinking we could get binding legal advice..wikipedia-style.. from individual users. I don't think you've got a firm grasp of how screwed up "contributory infringement" can be. The act of explicitly discussing the details about what is and is not legal and where what is and is not available is, could very well increase the liability for contributory infringement for the party hosting the webpages containing that detailed information that also host links to 3rd party resources where these materials can be gotten. Stuff like that can be construed as a "willful" act to aid infringement. We've just got the legal nod to link to 3rd party repositories as long as we make extremely general references and we do not get into the specifics of the contents of those repositories. What you are suggesting most probably create additional liability and would threaten our ability to link to external repositories at all. So you'll be making a choice. Do you want the Fedora project website to be as explicit an as accurate as possible concerning the legality of using specific software without any links whatsoever to places where you can obtain the software. Or do you want us to be able to reference the websites of 3rd party repositories in a general way for people to more easily find? I think detailed, thoughtful legal analysis for problematic software in each and every country would be an extraordinary educational experience, and I think we'd all learn a lot about the details of evolving software patent law outside the US. But such an "educational" experience would mean that Fedora sites will not be pointing people to any 3rd party repositories. And I'm pretty sure that's not what you want. -jef From kwade at redhat.com Fri Nov 16 17:21:48 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 16 Nov 2007 09:21:48 -0800 Subject: Legal Update In-Reply-To: References: Message-ID: <1195233709.5916.37.camel@erato.phig.org> On Fri, 2007-11-16 at 11:06 -0500, Monkey Boy wrote: > > You could have Third-party names listed under individual countries. > (Does the EU count as one country?) And under the United State section > you can have the sound of crickets chirping. I think the challenge here is the complexity. First, none of us are lawyers to suggest what is legal or not legal in any country. Second, none of us are lawyers in any specific country to be able to know what is legal or not legal in that specific country. There are around 194 countries in the world currently[1], so that introduces a lot of complexity to manage. [1] http://geography.about.com/cs/countries/a/numbercountries.htm > What I'm getting at is that by explaining what is known to be legal in > a particular country is more effective than listing out the third > party links and saying to the reader, "good luck in your country." > Also, it give those who live in a country that does not accept that as > legal the ability to judge for themselves as to whether or not they > should install. What I like about your idea is the general concept of showing people that their country may limit their freedoms or support bad policies. I'm imagining a world map picture with broad sweeping colors to generalize -- more free, less free, etc. But I fear it is not feasible, safe, or legal to make such declarations without the lawyers to back it up. - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org 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 jspaleta at gmail.com Fri Nov 16 17:54:28 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 16 Nov 2007 08:54:28 -0900 Subject: Legal Update In-Reply-To: <1195233709.5916.37.camel@erato.phig.org> References: <1195233709.5916.37.camel@erato.phig.org> Message-ID: <604aa7910711160954q4dda5203t15daab66a5e2d135@mail.gmail.com> On Nov 16, 2007 8:21 AM, Karsten Wade wrote: > But I fear it is not feasible, safe, or legal to make such declarations > without the lawyers to back it up. No, broad generalizations that could be used to color a map would be very ill-advised. -jef From kwade at redhat.com Fri Nov 16 18:31:19 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 16 Nov 2007 10:31:19 -0800 Subject: Legal Update In-Reply-To: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> Message-ID: <1195237879.5916.53.camel@erato.phig.org> On Fri, 2007-11-16 at 08:10 -0900, Jeff Spaleta wrote: > So you'll be making a choice. Do you want the Fedora project website > to be as explicit an as accurate as possible concerning the legality > of using specific software without any links whatsoever to places > where you can obtain the software. Or do you want us to be able to > reference the websites of 3rd party repositories in a general way for > people to more easily find? If you ask me, I'd rather educate than enable. But pragmatically, we're not going to get a good word in edgewise while the addicts are still bouncing off the walls looking for a fix. Maybe after they're calmed down a bit and have that $certain_mp3_they_love playing in the background, we can SCARE THE SHIT OUT OF THEM about patents and format lock-in and such. Kind of like getting someone high in the early '60s on stuff not yet illegal, and showing them video of people in prison twenty years later for possession of that same high-making stuff. Put a damper on that high. :) - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org 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 jspaleta at gmail.com Fri Nov 16 18:52:22 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 16 Nov 2007 09:52:22 -0900 Subject: Legal Update In-Reply-To: <1195237879.5916.53.camel@erato.phig.org> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <1195237879.5916.53.camel@erato.phig.org> Message-ID: <604aa7910711161052x3d50b44cp975f9965445cd165@mail.gmail.com> On Nov 16, 2007 9:31 AM, Karsten Wade wrote: > If you ask me, I'd rather educate than enable. I'm not sure our userbase nor our contributor base wants a detailed discussions which cites actual court cases concerning the evolving state of software patents in different countries. The EU situation as it comes to "technical" inventions involving software or more generally algorithms is not as black and white as some people who like to believe. Are we as a project prepared to due this topic justice? Do we as a project have the credibility to effectively educate on this subject? Or do we need to partner with a different community that has credibility in legal matters? Perhaps we could find a way to get groklaw involved? -jef From vnk at mkc.co.nz Fri Nov 16 19:22:50 2007 From: vnk at mkc.co.nz (Vladimir Kosovac) Date: Sat, 17 Nov 2007 08:22:50 +1300 Subject: Legal Update In-Reply-To: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> Message-ID: <473DEE0A.3000106@mkc.co.nz> Jeff Spaleta wrote: > I don't think you've got a firm grasp of how screwed up "contributory > infringement" can be. > The act of explicitly discussing the details about what is and is not > legal and where what is and is not available is, could very well > increase the liability for contributory infringement for the party > hosting the webpages containing that detailed information that also > host links to 3rd party resources where these materials can be gotten. > Stuff like that can be construed as a "willful" act to aid > infringement. > > We've just got the legal nod to link to 3rd party repositories as long > as we make extremely general references and we do not get into the > specifics of the contents of those repositories. Since Red Hat Legal's directions are very clear on the issue, the way forward might be "ThirdPartyRepositories" fp.o page, linked to from codeina, firefox start page, (anything else?). Apart from direct links to livna/RPM Fusion, other repos maybe, this page could provide a bit more general reference to what exactly third parties are hosting, by listing multi-media players, display drivers, etc, rather than explicitly mentioning encumbered codecs. That ought to be 'general' enough to stay in clear from a legal perspective. I am encouraged by a fact that 7 and 8 releases were praised for real values they provided and that a lack of out-of-the-box mp3/mpeg{2,4}/wm/flash support did not seem as important as it used to be. It still is (important) and Fedora will address it by linking to repository which provides said functionality. Fedora can't make this one-click install but once people find their way to livna pages, it's a no brainer. We now have a nod to at least provide one-click way to the repo, so just do it and move on. Vladimir -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jspaleta at gmail.com Fri Nov 16 19:38:18 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 16 Nov 2007 10:38:18 -0900 Subject: Legal Update In-Reply-To: <473DEE0A.3000106@mkc.co.nz> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> Message-ID: <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> On Nov 16, 2007 10:22 AM, Vladimir Kosovac wrote: > Apart from direct links to livna/RPM Fusion, other repos maybe, this > page could provide a bit more general reference to what exactly third > parties are hosting, by listing multi-media players, display drivers, > etc, rather than explicitly mentioning encumbered codecs. That ought to > be 'general' enough to stay in clear from a legal perspective. No i think you are wrong. I think mentioning repository contents by name should be absolutely off-limits. A sample of general categories of things at each listed repository possibly, but specific software projects absolutely not. 3rd party repository sites will hopefully have browsable searchable listings, there's very very little point it attempting to make a hand-picked selection of packages in our description of the repository. And there's certaintly no point in attempting to duplicate the full list of repository offerings in a fedora controlled space...we'd never be as accurate as the repository site's own listings, unless that repository is dedicated to a single package like Adobe's flash plugin repository. I think Fedora as a project and the userbase are best served if we limit ourselves to a statement that these repositories include software that does not meet the Fedora Project guidelines for inclusion and leave it at that. If we can't leave it at that, then I would go as far as supporting the listing a few categories of software that apply to a repository if we mean to list multiple repositories. Dribble for example would be all about games. I wouldn't bother telling people which games... just that Dribble is where you should look if you are interested in more games. -jef From tcallawa at redhat.com Fri Nov 16 20:24:47 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 16 Nov 2007 15:24:47 -0500 Subject: Legal update In-Reply-To: <1195225753.24228.0.camel@cutter> References: <1194448021.3148.61.camel@localhost.localdomain> <473CA91E.2040501@fedoraproject.org> <20071115203310.GA7042@nostromo.devel.redhat.com> <473D5436.3080201@fedoraproject.org> <1195220548.3238.6.camel@localhost.localdomain> <473DA7D0.9010801@fedoraproject.org> <1195223481.3238.17.camel@localhost.localdomain> <1195223853.23955.107.camel@cutter> <1195224592.3238.25.camel@localhost.localdomain> <1195224904.3238.29.camel@localhost.localdomain> <1195225753.24228.0.camel@cutter> Message-ID: <1195244687.3177.0.camel@localhost.localdomain> On Fri, 2007-11-16 at 10:09 -0500, seth vidal wrote: > On Fri, 2007-11-16 at 09:55 -0500, Tom "spot" Callaway wrote: > > On Fri, 2007-11-16 at 09:49 -0500, Tom "spot" Callaway wrote: > > > I'm pretty sure we cannot offer up a .xml file which configures livna > > > like you're describing. > > > > FWIW, I can pose this question to RH Legal if we want. Specifically, I > > can ask: > > > > "Are we permitted to offer a file on the Fedoraproject.org website (not > > in a package) which would allow Fedora users to enable a third party > > repository, and install content from it?" > > > > This would cover the .xml files and yum configs, for example. > > > > please do so. If we can do this then we can essentially make these files > be much like the mirrorlists and they would allow us a stepping stone > around the problem. RH Legal says we can do this. ~spot From vnk at mkc.co.nz Fri Nov 16 20:56:39 2007 From: vnk at mkc.co.nz (Vladimir Kosovac) Date: Sat, 17 Nov 2007 09:56:39 +1300 Subject: Legal Update In-Reply-To: <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> Message-ID: <473E0407.8060804@mkc.co.nz> Jeff Spaleta wrote: > On Nov 16, 2007 10:22 AM, Vladimir Kosovac wrote: >> Apart from direct links to livna/RPM Fusion, other repos maybe, this >> page could provide a bit more general reference to what exactly third >> parties are hosting, by listing multi-media players, display drivers, >> etc, rather than explicitly mentioning encumbered codecs. That ought to >> be 'general' enough to stay in clear from a legal perspective. > > No i think you are wrong. I think mentioning repository contents by > name should be absolutely off-limits. A sample of general categories > of things at each listed repository possibly, but specific software > projects absolutely not. Categories - right 3rd party repository sites will hopefully > have browsable searchable listings, there's very very little point it > attempting to make a hand-picked selection of packages in our > description of the repository. And there's certaintly no point in > attempting to duplicate the full list of repository offerings in a > fedora controlled space...we'd never be as accurate as the repository > site's own listings, unless that repository is dedicated to a single > package like Adobe's flash plugin repository. > > I think Fedora as a project and the userbase are best served if we > limit ourselves to a statement that these repositories include > software that does not meet the Fedora Project guidelines for > inclusion and leave it at that. Agree, wholeheartedly. I guess where I'm getting at is that Fedora as a project does so many good things that the patented codecs should safely be treated as a side-issue and not encouraged. Providing links to repo(s), with perhaps a bit more general info is more than Fedora provided thus far. However, according to the Tom Callaway's post that just came through, it looks like more is OKed by RHL and non-free repo configs will be possible directly from fp.o site. If we can't leave it at that, then I > would go as far as supporting the listing a few categories of software > that apply to a repository if we mean to list multiple repositories. > Dribble for example would be all about games. I wouldn't bother > telling people which games... just that Dribble is where you should > look if you are interested in more games. > > -jef > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From monkeyboythom at gmail.com Fri Nov 16 22:10:07 2007 From: monkeyboythom at gmail.com (Monkey Boy) Date: Fri, 16 Nov 2007 17:10:07 -0500 Subject: Legal Update Message-ID: OK. So no real involvement with any country specific legal authority. Because from what I take - a: to be too immense in scope (what countries would we really need) to b: it looks like a lot of work. Fair enough. Contributory infringement > The other form of indirect infringement, contributory infringement, > requires (1) knowledge of the infringing activity and (2) a material > contribution -- actual assistance or inducement -- to the alleged piracy. > Posting access codes from authorized copies of software, serial numbers, > or other tools to assist in accessing such software may subject you to > liability. Providing a forum for uploading and downloading any copyrighted > file or cracker utility may also be contributory infringement. Even though > you may not actually make software directly available on your site, > providing assistance (or supporting a forum in which others may provide > assistance) in locating unauthorized copies of software, links to download > sites, server space, or support for sites that do the above may > contributorily infringe. > So why even have this page? Yes, those are worthwhile products but why even invite such issue, even if cleared by RedHat legal? Also, who is responsible for updating and managing this page? And to, what makes the cut and what does not when considering these third party applications? To me, it is just as much time to review each and every app as it would be to find country specific legal advice. -thom wiley -------------- next part -------------- An HTML attachment was scrubbed... URL: From stickster at gmail.com Sat Nov 17 05:25:15 2007 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 17 Nov 2007 00:25:15 -0500 Subject: Legal Update In-Reply-To: <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> Message-ID: <1195277115.11139.13.camel@localhost.localdomain> On Fri, 2007-11-16 at 10:38 -0900, Jeff Spaleta wrote: > On Nov 16, 2007 10:22 AM, Vladimir Kosovac wrote: > > Apart from direct links to livna/RPM Fusion, other repos maybe, this > > page could provide a bit more general reference to what exactly third > > parties are hosting, by listing multi-media players, display drivers, > > etc, rather than explicitly mentioning encumbered codecs. That ought to > > be 'general' enough to stay in clear from a legal perspective. > > No i think you are wrong. I think mentioning repository contents by > name should be absolutely off-limits. A sample of general categories > of things at each listed repository possibly, but specific software > projects absolutely not. 3rd party repository sites will hopefully > have browsable searchable listings, there's very very little point it > attempting to make a hand-picked selection of packages in our > description of the repository. And there's certaintly no point in > attempting to duplicate the full list of repository offerings in a > fedora controlled space...we'd never be as accurate as the repository > site's own listings, unless that repository is dedicated to a single > package like Adobe's flash plugin repository. > > I think Fedora as a project and the userbase are best served if we > limit ourselves to a statement that these repositories include > software that does not meet the Fedora Project guidelines for > inclusion and leave it at that. If we can't leave it at that, then I > would go as far as supporting the listing a few categories of software > that apply to a repository if we mean to list multiple repositories. > Dribble for example would be all about games. I wouldn't bother > telling people which games... just that Dribble is where you should > look if you are interested in more games. Here's what I think is hilarious about this whole debate: People who want support for feature/codec/package X still have to find out how to do that. Where do they find out, if we don't publish it on our official one-click page? They find out from the same place where they would have found the advice to use the MungeyPants repo in the first place. What problem are we actually solving with this link, anyway? -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://pfrields.fedorapeople.org/ 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 jspaleta at gmail.com Sun Nov 18 19:57:01 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 18 Nov 2007 10:57:01 -0900 Subject: Legal Update In-Reply-To: <1195277115.11139.13.camel@localhost.localdomain> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> Message-ID: <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> On Nov 16, 2007 8:25 PM, Paul W. Frields wrote: > Here's what I think is hilarious about this whole debate: People who > want support for feature/codec/package X still have to find out how to > do that. Where do they find out, if we don't publish it on our official > one-click page? Too many pronouns I'm not following so I'm not sure exactly what part of your logic I should be shaking my fist at in rage. I want to shake my fist and foam and the mouth and yell at you, but I can't figure out why. -jef From kwade at redhat.com Sun Nov 18 20:24:37 2007 From: kwade at redhat.com (Karsten Wade) Date: Sun, 18 Nov 2007 12:24:37 -0800 Subject: Legal Update In-Reply-To: <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> Message-ID: <1195417477.5916.120.camel@erato.phig.org> On Sun, 2007-11-18 at 10:57 -0900, Jeff Spaleta wrote: > On Nov 16, 2007 8:25 PM, Paul W. Frields wrote: > > Here's what I think is hilarious about this whole debate: People who > > want support for feature/codec/package X still have to find out how to > > do that. Where do they find out, if we don't publish it on our official > > one-click page? "If you are having troubles getting some technology to work with Fedora, it may be because we cannot ship that software due to legal or moral reasons. You may find solutions to your problems or or perhaps . You can read up more about ." Then we rely upon the $here folks to direct people properly once they get there. Heck, it could even be a new, special Fedora landing page. > Too many pronouns I'm not following so I'm not sure exactly what part > of your logic I should be shaking my fist at in rage. I want to shake > my fist and foam and the mouth and yell at you, but I can't figure out > why. Huh^3? -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org 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 tcallawa at redhat.com Mon Nov 19 02:22:36 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 18 Nov 2007 21:22:36 -0500 Subject: Legal Update In-Reply-To: <1195417477.5916.120.camel@erato.phig.org> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195417477.5916.120.camel@erato.phig.org> Message-ID: <1195438956.3849.6.camel@localhost.localdomain> On Sun, 2007-11-18 at 12:24 -0800, Karsten Wade wrote: > On Sun, 2007-11-18 at 10:57 -0900, Jeff Spaleta wrote: > > On Nov 16, 2007 8:25 PM, Paul W. Frields wrote: > > > Here's what I think is hilarious about this whole debate: People who > > > want support for feature/codec/package X still have to find out how to > > > do that. Where do they find out, if we don't publish it on our official > > > one-click page? > > "If you are having troubles getting some technology to work with Fedora, > it may be because we cannot ship that software due to legal or moral > reasons. You may find solutions to your problems or or > perhaps . You can read up more about ." Can't say that. You can say something like "There are some software packages which Fedora does not include for various reasons. Here are some repositories which carry some of these packages." ~spot From stickster at gmail.com Mon Nov 19 13:36:51 2007 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 19 Nov 2007 08:36:51 -0500 Subject: Legal Update In-Reply-To: <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> Message-ID: <1195479411.3937.12.camel@localhost.localdomain> On Sun, 2007-11-18 at 10:57 -0900, Jeff Spaleta wrote: > On Nov 16, 2007 8:25 PM, Paul W. Frields wrote: > > Here's what I think is hilarious about this whole debate: People who > > want support for feature/codec/package X still have to find out how to > > do that. Where do they find out, if we don't publish it on our official > > one-click page? > > Too many pronouns I'm not following so I'm not sure exactly what part > of your logic I should be shaking my fist at in rage. I want to shake > my fist and foam and the mouth and yell at you, but I can't figure out > why. Sorry if I was unclear. My point was that trying to walk this particular legal line -- a very fine one at that -- is making the value of our possibly-soon-to-be-published verbiage practically nil. Joe wants support for turning CDs into MP3s. If we can only tell him "You can find support for things we can't carry at ," how has that really helped Joe? He already has to go to some other location, presumably an unofficial forum or FAQ, in order to discover which packages he needs to "yum install" to get the support he wants. Instead, we send him to the repository, which really only has directions on how to get the repo configured, as opposed to actual help. I am not saying we should go further. I am saying that what we *are* considering is practically useless, since Joe would have gone to the forum/FAQ/ anyway to find out what he needed to do. Advice through those channels would already include configuring the repo, so we wouldn't be cutting out a step, really, or giving Joe anything of real value. Rage away! :-) -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://pfrields.fedorapeople.org/ 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 Nov 19 14:53:58 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Nov 2007 20:23:58 +0530 Subject: Legal Update In-Reply-To: <1195479411.3937.12.camel@localhost.localdomain> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> Message-ID: <4741A386.1060104@fedoraproject.org> Paul W. Frields wrote: > > Sorry if I was unclear. My point was that trying to walk this > particular legal line -- a very fine one at that -- is making the value > of our possibly-soon-to-be-published verbiage practically nil. Are you considering the entire workflow? 1) Click on a MPEG file 2) A dialog explains why we support open non-patent encumbered formats 3) Another dialog which offers the Fluendo codecs/ "Click here for alternatives" 4) User chooses to click on alternatives link 5) Gets directed to Fedora wiki page which has a link to RPM Fusion website or a repo file or package (Which spot has confirmed recently that Legal is ok with) 6) Installs software with a single click via Pirut How is this not an advantage over the current situation? Rahul From jkeating at redhat.com Mon Nov 19 15:09:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Nov 2007 10:09:22 -0500 Subject: Legal Update In-Reply-To: <4741A386.1060104@fedoraproject.org> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> Message-ID: <20071119100922.308527e5@redhat.com> On Mon, 19 Nov 2007 20:23:58 +0530 Rahul Sundaram wrote: > 3) Another dialog which offers the Fluendo codecs/ "Click here for > alternatives" > 4) User chooses to click on alternatives link > 5) Gets directed to Fedora wiki page which has a link to RPM Fusion This part smells a lot like having a "reason" why these other repos exist (like what kind of content are within) which is verboten. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Mon Nov 19 15:09:25 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Nov 2007 20:39:25 +0530 Subject: Legal Update In-Reply-To: <20071119100922.308527e5@redhat.com> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> <20071119100922.308527e5@redhat.com> Message-ID: <4741A725.3030707@fedoraproject.org> Jesse Keating wrote: > On Mon, 19 Nov 2007 20:23:58 +0530 > Rahul Sundaram wrote: > >> 3) Another dialog which offers the Fluendo codecs/ "Click here for >> alternatives" >> 4) User chooses to click on alternatives link >> 5) Gets directed to Fedora wiki page which has a link to RPM Fusion > > This part smells a lot like having a "reason" why these other repos > exist (like what kind of content are within) which is verboten. Can you explain a bit more what you mean by that? I am not sure I understand. Rahul From caillon at redhat.com Mon Nov 19 15:21:24 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 19 Nov 2007 16:21:24 +0100 Subject: Legal Update In-Reply-To: <4741A725.3030707@fedoraproject.org> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> <20071119100922.308527e5@redhat.com> <4741A725.3030707@fedoraproject.org> Message-ID: <4741A9F4.9080603@redhat.com> On 11/19/2007 04:09 PM, Rahul Sundaram wrote: > Jesse Keating wrote: >> On Mon, 19 Nov 2007 20:23:58 +0530 >> Rahul Sundaram wrote: >> >>> 3) Another dialog which offers the Fluendo codecs/ "Click here for >>> alternatives" >>> 4) User chooses to click on alternatives link >>> 5) Gets directed to Fedora wiki page which has a link to RPM Fusion >> >> This part smells a lot like having a "reason" why these other repos >> exist (like what kind of content are within) which is verboten. > > Can you explain a bit more what you mean by that? I am not sure I > understand. 3) Another dialog which offers legal stuff / Click here for potentially illegal stuff. 4) User chooses to click on link to illegal stuff. 5) Gets redirected to Fedora wiki page with intent to get illegal stuff. Smells of contributory infringment. From kwade at redhat.com Mon Nov 19 15:26:12 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 19 Nov 2007 07:26:12 -0800 Subject: Legal Update In-Reply-To: <1195479411.3937.12.camel@localhost.localdomain> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> Message-ID: <1195485972.13156.5.camel@erato.phig.org> On Mon, 2007-11-19 at 08:36 -0500, Paul W. Frields wrote: > ... how has that > really helped Joe? He already has to go to some other location, > presumably an unofficial forum or FAQ, in order to discover which > packages he needs to "yum install" to get the support he wants. > Instead, we send him to the repository, which really only has directions > on how to get the repo configured, as opposed to actual help. I think the scenario we are discussing is not for an experienced user who will go to fora and FAQs for solutions. It helps inexperienced users who may not have heard of any of the elements involved, from codecs to patents, and how that affects them. - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org 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 sundaram at fedoraproject.org Mon Nov 19 15:26:34 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Nov 2007 20:56:34 +0530 Subject: Legal Update In-Reply-To: <4741A9F4.9080603@redhat.com> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> <20071119100922.308527e5@redhat.com> <4741A725.3030707@fedoraproject.org> <4741A9F4.9080603@redhat.com> Message-ID: <4741AB2A.3070207@fedoraproject.org> Christopher Aillon wrote: > On 11/19/2007 04:09 PM, Rahul Sundaram wrote: >> Jesse Keating wrote: >>> On Mon, 19 Nov 2007 20:23:58 +0530 >>> Rahul Sundaram wrote: >>> >>>> 3) Another dialog which offers the Fluendo codecs/ "Click here for >>>> alternatives" >>>> 4) User chooses to click on alternatives link >>>> 5) Gets directed to Fedora wiki page which has a link to RPM Fusion >>> >>> This part smells a lot like having a "reason" why these other repos >>> exist (like what kind of content are within) which is verboten. >> >> Can you explain a bit more what you mean by that? I am not sure I >> understand. > > > 3) Another dialog which offers legal stuff / Click here for potentially > illegal stuff. > 4) User chooses to click on link to illegal stuff. > 5) Gets redirected to Fedora wiki page with intent to get illegal stuff. > > Smells of contributory infringment. We asked Red Hat Legal and they have told us clearly what is allowed and what I have described is what is allowed AFAIK. If we need any clarification, we can go back and ask the real lawyers. Rahul From stickster at gmail.com Mon Nov 19 15:37:20 2007 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 19 Nov 2007 10:37:20 -0500 Subject: Legal Update In-Reply-To: <4741A386.1060104@fedoraproject.org> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> Message-ID: <1195486640.3937.16.camel@localhost.localdomain> On Mon, 2007-11-19 at 20:23 +0530, Rahul Sundaram wrote: > Paul W. Frields wrote: > > > > > Sorry if I was unclear. My point was that trying to walk this > > particular legal line -- a very fine one at that -- is making the value > > of our possibly-soon-to-be-published verbiage practically nil. > > Are you considering the entire workflow? > > 1) Click on a MPEG file > 2) A dialog explains why we support open non-patent encumbered formats > 3) Another dialog which offers the Fluendo codecs/ "Click here for > alternatives" > 4) User chooses to click on alternatives link > 5) Gets directed to Fedora wiki page which has a link to RPM Fusion > website or a repo file or package (Which spot has confirmed recently > that Legal is ok with) > 6) Installs software with a single click via Pirut > > How is this not an advantage over the current situation? I understand this workflow fine, but "Joe User" has no way of figuring out which package is the one to install for once he has his repo configured, meaning our links haven't helped him. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://pfrields.fedorapeople.org/ 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 Nov 19 15:33:57 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Nov 2007 21:03:57 +0530 Subject: Legal Update In-Reply-To: <1195486640.3937.16.camel@localhost.localdomain> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> <1195486640.3937.16.camel@localhost.localdomain> Message-ID: <4741ACE5.5040808@fedoraproject.org> Paul W. Frields wrote: > On Mon, 2007-11-19 at 20:23 +0530, Rahul Sundaram wrote: >> Paul W. Frields wrote: >> >>> Sorry if I was unclear. My point was that trying to walk this >>> particular legal line -- a very fine one at that -- is making the value >>> of our possibly-soon-to-be-published verbiage practically nil. >> Are you considering the entire workflow? >> >> 1) Click on a MPEG file >> 2) A dialog explains why we support open non-patent encumbered formats >> 3) Another dialog which offers the Fluendo codecs/ "Click here for >> alternatives" >> 4) User chooses to click on alternatives link >> 5) Gets directed to Fedora wiki page which has a link to RPM Fusion >> website or a repo file or package (Which spot has confirmed recently >> that Legal is ok with) >> 6) Installs software with a single click via Pirut >> >> How is this not an advantage over the current situation? > > I understand this workflow fine, but "Joe User" has no way of figuring > out which package is the one to install for once he > has his repo configured, meaning our links haven't helped him. 7) RPM Fusion website explains in great detail which package he needs for what functionality. Rahul From caillon at redhat.com Mon Nov 19 15:56:22 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 19 Nov 2007 16:56:22 +0100 Subject: Legal Update In-Reply-To: <4741AB2A.3070207@fedoraproject.org> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> <20071119100922.308527e5@redhat.com> <4741A725.3030707@fedoraproject.org> <4741A9F4.9080603@redhat.com> <4741AB2A.3070207@fedoraproject.org> Message-ID: <4741B226.5070109@redhat.com> On 11/19/2007 04:26 PM, Rahul Sundaram wrote: > Christopher Aillon wrote: >> On 11/19/2007 04:09 PM, Rahul Sundaram wrote: >>> Jesse Keating wrote: >>>> On Mon, 19 Nov 2007 20:23:58 +0530 >>>> Rahul Sundaram wrote: >>>> >>>>> 3) Another dialog which offers the Fluendo codecs/ "Click here for >>>>> alternatives" >>>>> 4) User chooses to click on alternatives link >>>>> 5) Gets directed to Fedora wiki page which has a link to RPM Fusion >>>> >>>> This part smells a lot like having a "reason" why these other repos >>>> exist (like what kind of content are within) which is verboten. >>> >>> Can you explain a bit more what you mean by that? I am not sure I >>> understand. >> >> >> 3) Another dialog which offers legal stuff / Click here for >> potentially illegal stuff. >> 4) User chooses to click on link to illegal stuff. >> 5) Gets redirected to Fedora wiki page with intent to get illegal stuff. >> >> Smells of contributory infringment. > > We asked Red Hat Legal and they have told us clearly what is allowed and > what I have described is what is allowed AFAIK. If we need any > clarification, we can go back and ask the real lawyers. > Read spot's mail again. You can't give a reason. You can say general things such as "There's some other software that we don't ship which is available here". You can't say "There's some other software that we don't ship because of .... which is available here". Including it in a very specific context like this seems to fall more into the latter, not the former, and does not appear to be allowed. From sundaram at fedoraproject.org Mon Nov 19 16:03:20 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Nov 2007 21:33:20 +0530 Subject: Legal Update In-Reply-To: <4741B226.5070109@redhat.com> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> <20071119100922.308527e5@redhat.com> <4741A725.3030707@fedoraproject.org> <4741A9F4.9080603@redhat.com> <4741AB2A.3070207@fedoraproject.org> <4741B226.5070109@redhat.com> Message-ID: <4741B3C8.2070204@fedoraproject.org> Christopher Aillon wrote: > > Read spot's mail again. You can't give a reason. You can say general > things such as "There's some other software that we don't ship which is > available here". You can't say "There's some other software that we > don't ship because of .... which is available here". Including it in a > very specific context like this seems to fall more into the latter, not > the former, and does not appear to be allowed. What I understood is that is that we can't explicitly say in words the reason behind why we don't include certain software. I don't consider the context in the workflow that I described as not allowed. Spot, let me know what you think. If we need to get legal confirmation on the specific workflow as I suggested, let's get that done. Rahul From jkeating at redhat.com Mon Nov 19 16:23:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Nov 2007 11:23:47 -0500 Subject: Legal Update In-Reply-To: <4741B3C8.2070204@fedoraproject.org> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> <20071119100922.308527e5@redhat.com> <4741A725.3030707@fedoraproject.org> <4741A9F4.9080603@redhat.com> <4741AB2A.3070207@fedoraproject.org> <4741B226.5070109@redhat.com> <4741B3C8.2070204@fedoraproject.org> Message-ID: <20071119112347.4819c609@redhat.com> On Mon, 19 Nov 2007 21:33:20 +0530 Rahul Sundaram wrote: > What I understood is that is that we can't explicitly say in words > the reason behind why we don't include certain software. I don't > consider the context in the workflow that I described as not allowed. > Spot, let me know what you think. If we need to get legal > confirmation on the specific workflow as I suggested, let's get that > done. I personally feel that you're trying any way possible to get around what Legal has said. It's very reasonable to assume that if you attempted to do /something/, were told that Fedora can't help you do /something/ but if you happen to look over /here/, that we are now putting context into what /here/ is and what /here/ provides. This is what Legal does not want us to do. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- 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 Mon Nov 19 16:29:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Nov 2007 11:29:27 -0500 Subject: Legal Update In-Reply-To: <20071119112347.4819c609@redhat.com> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> <20071119100922.308527e5@redhat.com> <4741A725.3030707@fedoraproject.org> <4741A9F4.9080603@redhat.com> <4741AB2A.3070207@fedoraproject.org> <4741B226.5070109@redhat.com> <4741B3C8.2070204@fedoraproject.org> <20071119112347.4819c609@redhat.com> Message-ID: <20071119112927.0bf8b5e6@redhat.com> On Mon, 19 Nov 2007 11:23:47 -0500 Jesse Keating wrote: > I personally feel that you're trying any way possible to get around > what Legal has said. It's very reasonable to assume that if you > attempted to do /something/, were told that Fedora can't help you > do /something/ but if you happen to look over /here/, that we are now > putting context into what /here/ is and what /here/ provides. This is > what Legal does not want us to do. To put it another way; If you came to me and said you were thirsty. I said I don't have water, because it's illegal for me to provide you water. I give you a list of vendors that sell water, and also I have this "Free alternative" link. This link takes you to a generic looking list of buckets, no information about what is in each bucket. Is it not logical that you would /assume/ that all of those buckets had water in them? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Nov 19 16:33:43 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 19 Nov 2007 17:33:43 +0100 Subject: Legal Update In-Reply-To: <20071119100922.308527e5@redhat.com> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> <20071119100922.308527e5@redhat.com> Message-ID: <4741BAE7.1010303@leemhuis.info> On 19.11.2007 16:09, Jesse Keating wrote: > On Mon, 19 Nov 2007 20:23:58 +0530 > Rahul Sundaram wrote: > >> 3) Another dialog which offers the Fluendo codecs/ "Click here for >> alternatives" >> 4) User chooses to click on alternatives link >> 5) Gets directed to Fedora wiki page which has a link to RPM Fusion > This part smells a lot like having a "reason" why these other repos > exist (like what kind of content are within) which is verboten. Besides that: it smells a bit like "this solution is preferred, the other one not". Is that what we want? That actually a interesting point in general. E.g. if I start a new fluendo-competition company tomorrow can I get my own codeina-like app into Fedora? Or modify codeina so it points to my webshop as well? IOW: Maybe we should create a webpage in the fedoraproject wiki. Then instead of having codeina directly offering the solution for playing popular multimedia formats let it direct users to the wiki page. Let that one list the different solutions side by side with links to homepage from foo and bar; those then can have "click here to use our offerings" and "for playing baz afterwards run foobar install foobaz" CU knurd From sundaram at fedoraproject.org Mon Nov 19 16:28:52 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Nov 2007 21:58:52 +0530 Subject: Legal Update In-Reply-To: <20071119112347.4819c609@redhat.com> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> <20071119100922.308527e5@redhat.com> <4741A725.3030707@fedoraproject.org> <4741A9F4.9080603@redhat.com> <4741AB2A.3070207@fedoraproject.org> <4741B226.5070109@redhat.com> <4741B3C8.2070204@fedoraproject.org> <20071119112347.4819c609@redhat.com> Message-ID: <4741B9C4.2020206@fedoraproject.org> Jesse Keating wrote: > I personally feel that you're trying any way possible to get around > what Legal has said. It's very reasonable to assume that if you > attempted to do /something/, were told that Fedora can't help you > do /something/ but if you happen to look over /here/, that we are now > putting context into what /here/ is and what /here/ provides. This is > what Legal does not want us to do. You are trying to guess the legal outcome based on engineering logic which frequently is very different from logic (or what is the equivalent there) in the legal world. I personally feel that what I am proposing is just fine and if there is any doubt about that, we should ask Red Hat Legal directly instead of trying to guess what is allowed or not. Rahul From jkeating at redhat.com Mon Nov 19 16:43:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Nov 2007 11:43:16 -0500 Subject: Legal Update In-Reply-To: <4741BAE7.1010303@leemhuis.info> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> <20071119100922.308527e5@redhat.com> <4741BAE7.1010303@leemhuis.info> Message-ID: <20071119114316.13f55901@redhat.com> On Mon, 19 Nov 2007 17:33:43 +0100 Thorsten Leemhuis wrote: > That actually a interesting point in general. E.g. if I start a new > fluendo-competition company tomorrow can I get my own codeina-like app > into Fedora? Or modify codeina so it points to my webshop as well? Theoretically yes. It's unclear to me if the current build of codeina supports multiple vendors though. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Mon Nov 19 16:51:32 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 19 Nov 2007 11:51:32 -0500 Subject: Legal Update In-Reply-To: <4741B3C8.2070204@fedoraproject.org> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> <20071119100922.308527e5@redhat.com> <4741A725.3030707@fedoraproject.org> <4741A9F4.9080603@redhat.com> <4741AB2A.3070207@fedoraproject.org> <4741B226.5070109@redhat.com> <4741B3C8.2070204@fedoraproject.org> Message-ID: <1195491092.3849.20.camel@localhost.localdomain> On Mon, 2007-11-19 at 21:33 +0530, Rahul Sundaram wrote: > What I understood is that is that we can't explicitly say in words the > reason behind why we don't include certain software. I don't consider > the context in the workflow that I described as not allowed. Spot, let > me know what you think. If we need to get legal confirmation on the > specific workflow as I suggested, let's get that done. Like I've told several other people, it would depend on the precise way that it is implemented. Draft out a specific flow of action (with the exact wording) for what you want to implement, and lets discuss it amongst ourselves. When we are in agreement that it is the sort of thing that we'd like to try to do, I'll run it past the lawyers, and we'll go from there. ~spot From kwade at redhat.com Mon Nov 19 17:15:39 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 19 Nov 2007 09:15:39 -0800 Subject: Legal Update In-Reply-To: <4741BAE7.1010303@leemhuis.info> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> <20071119100922.308527e5@redhat.com> <4741BAE7.1010303@leemhuis.info> Message-ID: <1195492539.13156.8.camel@erato.phig.org> On Mon, 2007-11-19 at 17:33 +0100, Thorsten Leemhuis wrote: > Besides that: it smells a bit like "this solution is preferred, the > other one not". Is that what we want? > > That actually a interesting point in general. E.g. if I start a new > fluendo-competition company tomorrow can I get my own codeina-like app > into Fedora? Or modify codeina so it points to my webshop as well? How about what we really want, which is codeina pointing at zero web shops? > IOW: Maybe we should create a webpage in the fedoraproject wiki. Then > instead of having codeina directly offering the solution for playing > popular multimedia formats let it direct users to the wiki page. Let > that one list the different solutions side by side with links to > homepage from foo and bar; those then can have "click here to use our > offerings" and "for playing baz afterwards run foobar install foobaz" This is what we tried to have for Fedora 8. I trust that it is being/has already been fixed in an update? - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org 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 sundaram at fedoraproject.org Mon Nov 19 17:25:30 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Nov 2007 22:55:30 +0530 Subject: Legal Update In-Reply-To: <1195491092.3849.20.camel@localhost.localdomain> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> <20071119100922.308527e5@redhat.com> <4741A725.3030707@fedoraproject.org> <4741A9F4.9080603@redhat.com> <4741AB2A.3070207@fedoraproject.org> <4741B226.5070109@redhat.com> <4741B3C8.2070204@fedoraproject.org> <1195491092.3849.20.camel@localhost.localdomain> Message-ID: <4741C70A.1090704@fedoraproject.org> Tom "spot" Callaway wrote: > > Like I've told several other people, it would depend on the precise way > that it is implemented. > > Draft out a specific flow of action (with the exact wording) for what > you want to implement, and lets discuss it amongst ourselves. When we > are in agreement that it is the sort of thing that we'd like to try to > do, I'll run it past the lawyers, and we'll go from there. The problem unfortunately is that, we don't seem to get past the stage where we want to guess whether it's legal or not and nobody wants to discuss what is that we want to accomplish assuming it is legal. What I would want us to accomplish: -------------------------------- Codeina offers a legal solution via Fluendo for those in regions that accept and enforce patents on software. Unfortunately this favors a non-free solution while there are perfectly legal (in regions which don't enforce patents on software which happen to be the majority of the world) free and open source software available via third party repositories for Fedora. What I would like for us to be able to do is point to a third party repository (specifically the free repo of RPM Fusion) as a alternative source in addition to Fluendo. We have spending nitpicking my suggestions on how to accomplish this rather than whether the above goal is something we agree on the whole or not and then figure out how best to accomplish it. Assuming we do, what I am suggesting below is a couple of potential ways to get that done. Feel free to suggest better alternatives. Spot, I am especially interested in hearing any proposals from you considering that you are likely to be a better judge of what is allowed. How To Get It Done ------------------- Solution 1 ---------- Refer http://fedoraproject.org/wiki/Multimedia/Codeina to understand what I am talking about. * Retain the first dialog as it is. * In the second dialog box, above "available products", have a link "click here for free alternatives" which refers to a Fedora Wiki page that references http://fedoraproject.org/wiki/CodecBuddy and links to the RPM Fusion free repo release package. Solution 2 ----------- * In the first dialog, modify it so that it says, For more information, refer to the Fedora Project website which links to the CodecBuddy wiki page. * Drop the "see available options" button and codeina. * In http://fedoraproject.org/wiki/CodecBuddy, refer to the Fluendo website as well as RPM Fusion free repo release package. Solution 3 ---------- * Retain everything else as it is. * Just modify http://fedoraproject.org/wiki/CodecBuddy to link to the RPM Fusion free repo release package. Rahul From caillon at redhat.com Mon Nov 19 17:36:30 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 19 Nov 2007 18:36:30 +0100 Subject: Legal Update In-Reply-To: <4741C70A.1090704@fedoraproject.org> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> <20071119100922.308527e5@redhat.com> <4741A725.3030707@fedoraproject.org> <4741A9F4.9080603@redhat.com> <4741AB2A.3070207@fedoraproject.org> <4741B226.5070109@redhat.com> <4741B3C8.2070204@fedoraproject.org> <1195491092.3849.20.camel@localhost.localdomain> <4741C70A.1090704@fedoraproject.org> Message-ID: <4741C99E.9030909@redhat.com> On 11/19/2007 06:25 PM, Rahul Sundaram wrote: > Codeina offers a legal solution via Fluendo for those in regions that > accept and enforce patents on software. Unfortunately this favors a > non-free solution while there are perfectly legal (in regions which > don't enforce patents on software which happen to be the majority of the > world) free and open source software available via third party > repositories for Fedora. Careful. Not enforcing a law doesn't mean it doesn't exist. From sundaram at fedoraproject.org Mon Nov 19 17:35:46 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Nov 2007 23:05:46 +0530 Subject: Legal Update In-Reply-To: <4741C99E.9030909@redhat.com> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> <20071119100922.308527e5@redhat.com> <4741A725.3030707@fedoraproject.org> <4741A9F4.9080603@redhat.com> <4741AB2A.3070207@fedoraproject.org> <4741B226.5070109@redhat.com> <4741B3C8.2070204@fedoraproject.org> <1195491092.3849.20.camel@localhost.localdomain> <4741C70A.1090704@fedoraproject.org> <4741C99E.9030909@redhat.com> Message-ID: <4741C972.7040100@fedoraproject.org> Christopher Aillon wrote: > On 11/19/2007 06:25 PM, Rahul Sundaram wrote: >> Codeina offers a legal solution via Fluendo for those in regions that >> accept and enforce patents on software. Unfortunately this favors a >> non-free solution while there are perfectly legal (in regions which >> don't enforce patents on software which happen to be the majority of >> the world) free and open source software available via third party >> repositories for Fedora. > > Careful. Not enforcing a law doesn't mean it doesn't exist. Right but in many regions of the world, there isn't any law that validates patents on software directly. There are some Grey areas in other regions. Rahul From fedora at leemhuis.info Mon Nov 19 17:59:15 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 19 Nov 2007 18:59:15 +0100 Subject: Legal Update In-Reply-To: <1195492539.13156.8.camel@erato.phig.org> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> <20071119100922.308527e5@redhat.com> <4741BAE7.1010303@leemhuis.info> <1195492539.13156.8.camel@erato.phig.org> Message-ID: <4741CEF3.8020503@leemhuis.info> On 19.11.2007 18:15, Karsten Wade wrote: > On Mon, 2007-11-19 at 17:33 +0100, Thorsten Leemhuis wrote: > >> Besides that: it smells a bit like "this solution is preferred, the >> other one not". Is that what we want? >> That actually a interesting point in general. E.g. if I start a new >> fluendo-competition company tomorrow can I get my own codeina-like app >> into Fedora? Or modify codeina so it points to my webshop as well? > How about what we really want, which is codeina pointing at zero web > shops? >> IOW: Maybe we should create a webpage in the fedoraproject wiki. Then >> instead of having codeina directly offering the solution for playing >> popular multimedia formats let it direct users to the wiki page. Let >> that one list the different solutions side by side with links to >> homepage from foo and bar; those then can have "click here to use our >> offerings" and "for playing baz afterwards run foobar install foobaz" > This is what we tried to have for Fedora 8. I trust that it is > being/has already been fixed in an update? I just tried (not sure if I did it properly -- I just started codeina manually and tried) -- you get the "Fedora has the mission of always being freely re-distributable; this means[...]" popup; once you go further you can still select the commercial codecs -- then you get send to a webshop. Cu knurd From tcallawa at redhat.com Mon Nov 19 18:05:25 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 19 Nov 2007 13:05:25 -0500 Subject: Legal Update In-Reply-To: <4741C70A.1090704@fedoraproject.org> References: <604aa7910711160910u20ce9243gda154420710aa970@mail.gmail.com> <473DEE0A.3000106@mkc.co.nz> <604aa7910711161138l325e3ffcsa9b3295fdd141339@mail.gmail.com> <1195277115.11139.13.camel@localhost.localdomain> <604aa7910711181157m10eab7fi2814d7f0369567bb@mail.gmail.com> <1195479411.3937.12.camel@localhost.localdomain> <4741A386.1060104@fedoraproject.org> <20071119100922.308527e5@redhat.com> <4741A725.3030707@fedoraproject.org> <4741A9F4.9080603@redhat.com> <4741AB2A.3070207@fedoraproject.org> <4741B226.5070109@redhat.com> <4741B3C8.2070204@fedoraproject.org> <1195491092.3849.20.camel@localhost.localdomain> <4741C70A.1090704@fedoraproject.org> Message-ID: <1195495525.3849.27.camel@localhost.localdomain> So, after thinking about this some more, I'd rather just say no to this entirely. Lets stick to having a page on the website which refers people to other repositories which carry packages that Fedora does not include, and leave it at that. Sorry. ~spot From smooge at gmail.com Mon Nov 19 22:42:29 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 19 Nov 2007 15:42:29 -0700 Subject: Legal Update In-Reply-To: <4741C972.7040100@fedoraproject.org> References: <4741A725.3030707@fedoraproject.org> <4741A9F4.9080603@redhat.com> <4741AB2A.3070207@fedoraproject.org> <4741B226.5070109@redhat.com> <4741B3C8.2070204@fedoraproject.org> <1195491092.3849.20.camel@localhost.localdomain> <4741C70A.1090704@fedoraproject.org> <4741C99E.9030909@redhat.com> <4741C972.7040100@fedoraproject.org> Message-ID: <80d7e4090711191442w47f6e0b0pac6bdd2d063bbc47@mail.gmail.com> On Nov 19, 2007 10:35 AM, Rahul Sundaram wrote: > Christopher Aillon wrote: > > On 11/19/2007 06:25 PM, Rahul Sundaram wrote: > >> Codeina offers a legal solution via Fluendo for those in regions that > >> accept and enforce patents on software. Unfortunately this favors a > >> non-free solution while there are perfectly legal (in regions which > >> don't enforce patents on software which happen to be the majority of > >> the world) free and open source software available via third party > >> repositories for Fedora. > > > > Careful. Not enforcing a law doesn't mean it doesn't exist. > > Right but in many regions of the world, there isn't any law that > validates patents on software directly. There are some Grey areas in > other regions. > While the most restrictive state doesn't apply, the state where the majority of funding and base of operations does apply. -- 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 fedora at leemhuis.info Tue Nov 20 15:32:33 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Nov 2007 16:32:33 +0100 Subject: predictable releases Halloween and May Day (was: Re: [Fedora Project Wiki] Update of "Releases/9/Schedule" by JesseKeating) In-Reply-To: <20071120140141.26599.22108@app1.fedora.phx.redhat.com> References: <20071120140141.26599.22108@app1.fedora.phx.redhat.com> Message-ID: <4742FE11.5010409@leemhuis.info> On 20.11.2007 15:01, fedorawiki-noreply at fedoraproject.org wrote: > The following page has been changed by JesseKeating: > http://fedoraproject.org/wiki/Releases/9/Schedule?action=diff&rev2=11&rev1=10 > > The comment on the change is: > Update with releng/fesco changes. > ------------------------------------------------------------------------------ > ||Date||Event|| > ||8 Nov 2007||Fedora 8 Release|| > ||8 Nov 2007||Fedora 9 Planning Begins (Features considered for approval)|| > + ||15 Jan 2008||Fedora 9 Alpha freeze (non blocking)|| > - ||17 Jan 2008||Fedora 9 Alpha release|| > + ||24 Jan 2008||Fedora 9 Alpha release|| > ||4 March 2008||Fedora 9 Beta freeze|| > ||4 March 2008||Fedora 9 Planning Ends (No new Features considered)|| > ||4 March 2008||Fedora 9 '''FEATURE freeze '''|| > @@ -18, +19 @@ > > ||1 April 2008||Fedora 9 '''translation freeze'''|| > ||8 April 2008||Final Development freeze|| > ||8 April 2008||Branch all packages for Fedora 9|| > + ||10 April 2008||Fedora 9 Preview Release|| > - ||17 April 2008||Release Candidate 1|| > + ||22 April 2008||Release Candidate 1|| > - ||1 May 2008||Fedora 9 final release|| > + ||29 May 2008||Fedora 9 final release|| > > - In addition to the test releases, the nightly trees will usually be installable. > + In addition to the test releases, the nightly trees will usually be installable. > + > + After Beta release, weekly snapshots will be attempted each Friday. I thought the Board not that long ago agreed to have more predictable release schedule with a release target end of April/early May and end of October/early November? Gregdek for example mentioned in http://gregdek.livejournal.com/12639.html: "we're going to start tracking release dates for Fedora much more aggressively. The current goal: release Fedora twice a year, at Halloween and May Day, every year." Did that goal change again? Or was it forgotten? Just wondering. CU knurd From tcallawa at redhat.com Tue Nov 20 15:34:22 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 20 Nov 2007 10:34:22 -0500 Subject: predictable releases Halloween and May Day (was: Re: [Fedora Project Wiki] Update of "Releases/9/Schedule" by JesseKeating) In-Reply-To: <4742FE11.5010409@leemhuis.info> References: <20071120140141.26599.22108@app1.fedora.phx.redhat.com> <4742FE11.5010409@leemhuis.info> Message-ID: <1195572862.27963.19.camel@localhost.localdomain> On Tue, 2007-11-20 at 16:32 +0100, Thorsten Leemhuis wrote: > I thought the Board not that long ago agreed to have more predictable > release schedule with a release target end of April/early May and end of > October/early November? Gregdek for example mentioned in > http://gregdek.livejournal.com/12639.html: "we're going to start > tracking release dates for Fedora much more aggressively. The current > goal: release Fedora twice a year, at Halloween and May Day, every year." I think May 31 is more realistic (we released F7 on May 31). It has the added bonus of being my birthday. ;) ~spot From katzj at redhat.com Tue Nov 20 15:45:30 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 20 Nov 2007 10:45:30 -0500 Subject: predictable releases Halloween and May Day (was: Re: [Fedora Project Wiki] Update of "Releases/9/Schedule" by JesseKeating) In-Reply-To: <4742FE11.5010409@leemhuis.info> References: <20071120140141.26599.22108@app1.fedora.phx.redhat.com> <4742FE11.5010409@leemhuis.info> Message-ID: <1195573530.4552.13.camel@localhost.localdomain> On Tue, 2007-11-20 at 16:32 +0100, Thorsten Leemhuis wrote: > I thought the Board not that long ago agreed to have more predictable > release schedule with a release target end of April/early May and end of > October/early November? Gregdek for example mentioned in > http://gregdek.livejournal.com/12639.html: "we're going to start > tracking release dates for Fedora much more aggressively. The current > goal: release Fedora twice a year, at Halloween and May Day, every year." > > Did that goal change again? Or was it forgotten? > > Just wondering. I think Jesse just mis-did his month counting :) Jeremy From katzj at redhat.com Tue Nov 20 15:47:03 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 20 Nov 2007 10:47:03 -0500 Subject: predictable releases Halloween and May Day (was: Re: [Fedora Project Wiki] Update of "Releases/9/Schedule" by JesseKeating) In-Reply-To: <1195572862.27963.19.camel@localhost.localdomain> References: <20071120140141.26599.22108@app1.fedora.phx.redhat.com> <4742FE11.5010409@leemhuis.info> <1195572862.27963.19.camel@localhost.localdomain> Message-ID: <1195573623.4552.16.camel@localhost.localdomain> On Tue, 2007-11-20 at 10:34 -0500, Tom "spot" Callaway wrote: > On Tue, 2007-11-20 at 16:32 +0100, Thorsten Leemhuis wrote: > > > I thought the Board not that long ago agreed to have more predictable > > release schedule with a release target end of April/early May and end of > > October/early November? Gregdek for example mentioned in > > http://gregdek.livejournal.com/12639.html: "we're going to start > > tracking release dates for Fedora much more aggressively. The current > > goal: release Fedora twice a year, at Halloween and May Day, every year." > > I think May 31 is more realistic (we released F7 on May 31). It has the > added bonus of being my birthday. ;) F7 was May 31, F8 was Nov 8 (we pushed back a little from the goal of Oct 31 to have 5.5 months for the release), and F9 should be back to May 1. That then gets us back on the 6 month schedule that was wanted without huge differences. If we do F9 on May 31, then it's almost a 7 month cycle. Jeremy From jkeating at redhat.com Tue Nov 20 15:47:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Nov 2007 10:47:12 -0500 Subject: predictable releases Halloween and May Day (was: Re: [Fedora Project Wiki] Update of "Releases/9/Schedule" by JesseKeating) In-Reply-To: <1195573530.4552.13.camel@localhost.localdomain> References: <20071120140141.26599.22108@app1.fedora.phx.redhat.com> <4742FE11.5010409@leemhuis.info> <1195573530.4552.13.camel@localhost.localdomain> Message-ID: <20071120104712.3d5b78cc@redhat.com> On Tue, 20 Nov 2007 10:45:30 -0500 Jeremy Katz wrote: > > tracking release dates for Fedora much more aggressively. The > > current goal: release Fedora twice a year, at Halloween and May > > Day, every year." > > > > Did that goal change again? Or was it forgotten? > > > > Just wondering. > > I think Jesse just mis-did his month counting :) Oops. It was requested of us to do our final releases on Tuesdays instead of Thursdays. It's a lot easier to get the press to pay attention to us early in the week rather than later. I just forgot to change the month when I changed the day. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Nov 20 16:07:24 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Nov 2007 17:07:24 +0100 Subject: predictable releases Halloween and May Day In-Reply-To: <20071120104712.3d5b78cc@redhat.com> References: <20071120140141.26599.22108@app1.fedora.phx.redhat.com> <4742FE11.5010409@leemhuis.info> <1195573530.4552.13.camel@localhost.localdomain> <20071120104712.3d5b78cc@redhat.com> Message-ID: <4743063C.3000206@leemhuis.info> On 20.11.2007 16:47, Jesse Keating wrote: > On Tue, 20 Nov 2007 10:45:30 -0500 > Jeremy Katz wrote: > >>> tracking release dates for Fedora much more aggressively. The >>> current goal: release Fedora twice a year, at Halloween and May >>> Day, every year." >>> Did that goal change again? Or was it forgotten? >>> Just wondering. >> I think Jesse just mis-did his month counting :) > Oops. It was requested of us to do our final releases on Tuesdays > instead of Thursdays. It's a lot easier to get the press to pay > attention to us early in the week rather than later. I just forgot to > change the month when I changed the day. Things happen -- looking back at the changes now I might have guest that if I might have looked closer, but the "Release Candidate 1" moved to a later date, so on a first sight it made sense that the final release moved to a later date as well. CU knurd From poelstra at redhat.com Tue Nov 20 16:14:40 2007 From: poelstra at redhat.com (John Poelstra) Date: Tue, 20 Nov 2007 08:14:40 -0800 Subject: predictable releases Halloween and May Day In-Reply-To: <20071120104712.3d5b78cc@redhat.com> References: <20071120140141.26599.22108@app1.fedora.phx.redhat.com> <4742FE11.5010409@leemhuis.info> <1195573530.4552.13.camel@localhost.localdomain> <20071120104712.3d5b78cc@redhat.com> Message-ID: <474307F0.6080605@redhat.com> Jesse Keating wrote: > On Tue, 20 Nov 2007 10:45:30 -0500 > Jeremy Katz wrote: > >>> tracking release dates for Fedora much more aggressively. The >>> current goal: release Fedora twice a year, at Halloween and May >>> Day, every year." >>> >>> Did that goal change again? Or was it forgotten? >>> >>> Just wondering. >> I think Jesse just mis-did his month counting :) > > Oops. It was requested of us to do our final releases on Tuesdays > instead of Thursdays. It's a lot easier to get the press to pay > attention to us early in the week rather than later. I just forgot to > change the month when I changed the day. > I could easily create a custom report (if we don't have it already) to automatically create this page... upside is that everything calculates automatically, downside it is not as pretty, though I don't think it would be that hard to fix with some css tweaks. http://poelstra.fedorapeople.org/schedules/f9/f9-milestones.html Slightly, tangentially, I wonder if the pretty wiki version http://fedoraproject.org/wiki/Releases/9/Schedule should be higher level and encompassing of important milestones across the Fedora Project (Events like FUDCon, Art Team, Marketing, Infrastructure, etc.) while putting some of the more team specific tasks in sub-schedules in that team's wiki space. Thoughts? Comments? John From mspevack at redhat.com Tue Nov 20 16:25:21 2007 From: mspevack at redhat.com (Max Spevack) Date: Tue, 20 Nov 2007 11:25:21 -0500 (EST) Subject: predictable releases Halloween and May Day (was: Re: [Fedora Project Wiki] Update of "Releases/9/Schedule" by JesseKeating) In-Reply-To: <20071120104712.3d5b78cc@redhat.com> References: <20071120140141.26599.22108@app1.fedora.phx.redhat.com> <4742FE11.5010409@leemhuis.info> <1195573530.4552.13.camel@localhost.localdomain> <20071120104712.3d5b78cc@redhat.com> Message-ID: On Tue, 20 Nov 2007, Jesse Keating wrote: > Oops. It was requested of us to do our final releases on Tuesdays > instead of Thursdays. It's a lot easier to get the press to pay > attention to us early in the week rather than later. I just forgot to > change the month when I changed the day. In order to be responsive to Red Hat marketing/PR's request that major things like releases happen earlier in the week rather than later, we are moving the release day from Thursday to Tuesday. The Tuesday closest to May 1 2008 is April 29th, and so that is the initial Fedora 9 target. Similarly, the Tuesday closest to Halloween 2008 is October 28th, and that is probably what we will shoot for next year. --Max From poelstra at redhat.com Wed Nov 21 05:07:09 2007 From: poelstra at redhat.com (John Poelstra) Date: Tue, 20 Nov 2007 21:07:09 -0800 Subject: Fedora Board Recap 2007-NOV-13 Message-ID: <4743BCFD.2090003@redhat.com> http://fedoraproject.org/wiki/Board/Meetings/2007-11-13 Attendees: Chris Aillon, Max Spevack, Seth Vidal, John Poelstra, Steve Dickson, Jef Spaleta, Matt Domsch, Bill Nottingham, Karsten Wade, and Dennis Gilmore, and Chris Blizzard == Fedora 9 Planning == === Source Code === * Long term storage and availability of source code * ability to match source code to any released package--store for four years * create source on the fly so that space is not a concern * One approach would be to change the way we tag things or to disable forced tagging * Area of interest for Matt, Jef, Chris A === Wevisor === * Written in TurboGears * A web-based version of system-config-kickstart * kickstart stored online * Make sure it can import anaconda * What is needed to resurect it? * Development of this tool and providing it as a service are separate problems to solve * Area of interest for Max === Fedora Store SIG === * Looking to make Fedora store process better * First meeting on IRC 1800 UTC Wednesday === Presto === * Infrastructure evaluation needs to be done by Release Engineering * Must be integrated with Koji before anything else can happen == FUDCon == * January 11 to 13, 2008 * Location: TBD * Deadline for decision is 2007-11-20 (next week's meeting) From poelstra at redhat.com Wed Nov 21 05:21:45 2007 From: poelstra at redhat.com (John Poelstra) Date: Tue, 20 Nov 2007 21:21:45 -0800 Subject: Fedora Board Recap 2007-NOV-20 Message-ID: <4743C069.2040903@redhat.com> http://fedoraproject.org/wiki/Board/Meetings/2007-11-20 == Roll Call == Attendees: Max Spevack, Seth Vidal, John Poelstra, Steve Dickson, Chris Aillon, Bill Nottingham, and Dennis Gilmore Regrets: Matt Domsch, Jef Spaleta, Karsten Wade, Chris Blizzard == FUDCon == * Waiting for final word from Greg D == CD Sets == * The board desires that a CD set be created for Fedora 9 * The board does not have a specific preference as to who creates this CD set. It could be: --Release Engineering --Fedora Unity --Other From jkeating at redhat.com Wed Nov 21 13:16:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 08:16:20 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <4743BCFD.2090003@redhat.com> References: <4743BCFD.2090003@redhat.com> Message-ID: <20071121081620.3bf6586d@redhat.com> On Tue, 20 Nov 2007 21:07:09 -0800 John Poelstra wrote: > === Source Code === > * Long term storage and availability of source code > * ability to match source code to any released package--store for > four years > * create source on the fly so that space is not a concern > * One approach would be to change the way we tag things or to > disable forced tagging > * Area of interest for Matt, Jef, Chris A I have to say that I'm still pretty against any strategy that has us or any of our downstreams relying upon us for a GPLv2 3b or 3c distribution method. I feel that the methods described are entirely too vague and too easily misinterpreted and could easily drive Fedora into a "trap" of never being able to retire sources at all. Instead I'd far rather investigate methods to make it easier and lighter weight for us and downstreams to continue using 3a methods and offering the source along side the binary, so that when we retire the binary we can retire the source. Making clever use of hardlinks, offering more things like spins.fp.o for not just Fedora branded spins but for any branded Fedora based spin, adding source gathering capabilities to the likes of our live image creators so that a limited number of source isos can be used at events where binary isos are given, etc... I strongly feel we can make it easy enough to use 3a that we don't have to fall into a trap with 3b/c. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Wed Nov 21 14:02:40 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 21 Nov 2007 15:02:40 +0100 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121081620.3bf6586d@redhat.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> Message-ID: <47443A80.6010207@kanarip.com> Jesse Keating wrote: > On Tue, 20 Nov 2007 21:07:09 -0800 > John Poelstra wrote: > >> === Source Code === >> * Long term storage and availability of source code >> * ability to match source code to any released package--store for >> four years >> * create source on the fly so that space is not a concern >> * One approach would be to change the way we tag things or to >> disable forced tagging >> * Area of interest for Matt, Jef, Chris A > > I have to say that I'm still pretty against any strategy that has us or > any of our downstreams relying upon us for a GPLv2 3b or 3c > distribution method. I feel that the methods described are entirely > too vague and too easily misinterpreted and could easily drive Fedora > into a "trap" of never being able to retire sources at all. > Personally I am opposed to trying to find clever ways to not needing to host the source (rpms). Finding ways to do anything different from *just making the sources available online* for a period of time is asking for trouble; It should work, but what if it doesn't -or fails half-way? How does investing in a couple of discs weigh (each release?) against the potential legal liability of losing anything because in the past you thought you needed some 'clever way' to make sources available. I can't really understand though how anyone could be opposed to the Fedora Project releasing under 3b. Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Wed Nov 21 14:07:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 09:07:36 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <47443A80.6010207@kanarip.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> Message-ID: <20071121090736.48f8efc8@redhat.com> On Wed, 21 Nov 2007 15:02:40 +0100 Jeroen van Meeuwen wrote: > Personally I am opposed to trying to find clever ways to not needing > to host the source (rpms). Finding ways to do anything different from > *just making the sources available online* for a period of time is > asking for trouble; It should work, but what if it doesn't -or fails > half-way? How does investing in a couple of discs weigh (each > release?) against the potential legal liability of losing anything > because in the past you thought you needed some 'clever way' to make > sources available. > > I can't really understand though how anyone could be opposed to the > Fedora Project releasing under 3b. Forgive my use of "clever". I meant making use of hardlinks so that keeping the sources for each available binary release online less of a problem. I also want to avoid the "clever" idea of regenerating srpms on the fly. I just want them available, but I want them available just for the period of time the binary release is available, so that when the binary release is retired, so can any sources associated with it, that aren't used by a different binary release. I'm more than happy with the Fedora project taking on that resource, but I want it done in a way that has a reasonable end in sight, not an infinite trap. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at fedoraproject.org Wed Nov 21 14:15:30 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 21 Nov 2007 09:15:30 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121090736.48f8efc8@redhat.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> Message-ID: <1195654530.4113.4.camel@cutter> On Wed, 2007-11-21 at 09:07 -0500, Jesse Keating wrote: > On Wed, 21 Nov 2007 15:02:40 +0100 > Jeroen van Meeuwen wrote: > > > Personally I am opposed to trying to find clever ways to not needing > > to host the source (rpms). Finding ways to do anything different from > > *just making the sources available online* for a period of time is > > asking for trouble; It should work, but what if it doesn't -or fails > > half-way? How does investing in a couple of discs weigh (each > > release?) against the potential legal liability of losing anything > > because in the past you thought you needed some 'clever way' to make > > sources available. > > > > I can't really understand though how anyone could be opposed to the > > Fedora Project releasing under 3b. > > Forgive my use of "clever". I meant making use of hardlinks so that > keeping the sources for each available binary release online less of a > problem. I also want to avoid the "clever" idea of regenerating srpms > on the fly. I just want them available, but I want them available just > for the period of time the binary release is available, so that when > the binary release is retired, so can any sources associated with it, > that aren't used by a different binary release. I'm more than happy > with the Fedora project taking on that resource, but I want it done in > a way that has a reasonable end in sight, not an infinite trap. > 3 years is a long time for keeping the sources around if we generate them that way. It seems like we're better off in terms of space and in terms of being able to provide sources for the longer run if we can generate srpms on the fly out of cvs. -sv From jkeating at redhat.com Wed Nov 21 14:25:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 09:25:00 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <1195654530.4113.4.camel@cutter> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> Message-ID: <20071121092500.5545ed9c@redhat.com> On Wed, 21 Nov 2007 09:15:30 -0500 seth vidal wrote: > 3 years is a long time for keeping the sources around if we generate > them that way. It seems like we're better off in terms of space and in > terms of being able to provide sources for the longer run if we can > generate srpms on the fly out of cvs. 3 years only comes into play if you use 3b/c. If you use 3a, you only have to keep the source as long as you keep the binary. In the case of respins, you only have to keep the sources associated with the respin for as long as that respin binary is hosted. This is the real concern, the updates sources used in respins. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at fedoraproject.org Wed Nov 21 14:30:39 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 21 Nov 2007 09:30:39 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121092500.5545ed9c@redhat.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> Message-ID: <1195655439.4113.12.camel@cutter> On Wed, 2007-11-21 at 09:25 -0500, Jesse Keating wrote: > On Wed, 21 Nov 2007 09:15:30 -0500 > seth vidal wrote: > > > 3 years is a long time for keeping the sources around if we generate > > them that way. It seems like we're better off in terms of space and in > > terms of being able to provide sources for the longer run if we can > > generate srpms on the fly out of cvs. > > 3 years only comes into play if you use 3b/c. If you use 3a, you only > have to keep the source as long as you keep the binary. In the case of > respins, you only have to keep the sources associated with the respin > for as long as that respin binary is hosted. This is the real concern, > the updates sources used in respins. > But if we have the source tarball and spec file + patches in cvs - which we do right now, anyway, why not generate them on demand and not even need to host the srpms until they're desired? We save space even in the short run. -sv From kanarip at kanarip.com Wed Nov 21 14:30:06 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 21 Nov 2007 15:30:06 +0100 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <1195654530.4113.4.camel@cutter> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> Message-ID: <474440EE.6000907@kanarip.com> seth vidal wrote: > 3 years is a long time for keeping the sources around if we generate > them that way. It seems like we're better off in terms of space and in > terms of being able to provide sources for the longer run if we can > generate srpms on the fly out of cvs. > However once you choose to generate srpms on the fly out of cvs, you are also committing to using cvs for the same amount of time. Migrating the cvs component to anything else might show to have a huge tail and might just not work in the sense that the new vcs might not give you srpms with the same checksum, or . Besides that, generating spins off of on-the-fly generated srpms without some repository being generated might prove to be a challenge as well -remember downstream /can/ use 3c if FP does 3b, it can also use 3a if they want to. Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Wed Nov 21 14:38:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 09:38:43 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <1195655439.4113.12.camel@cutter> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> Message-ID: <20071121093843.46a75bad@redhat.com> On Wed, 21 Nov 2007 09:30:39 -0500 seth vidal wrote: > But if we have the source tarball and spec file + patches in cvs - > which we do right now, anyway, why not generate them on demand and > not even need to host the srpms until they're desired? > > We save space even in the short run. Because that will overtime potentially generate something that is different than the original srpm, unless we plan on freezing the machines that do the srpm production and never update rpm on them. It also feels very "hacky" when we can go a far more simplistic route of just hosting the files and using hardlinks to reduce the actual space overhead. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- 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 Nov 21 14:48:32 2007 From: matt at domsch.com (Matt Domsch) Date: Wed, 21 Nov 2007 08:48:32 -0600 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121093843.46a75bad@redhat.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> <20071121093843.46a75bad@redhat.com> Message-ID: <20071121144831.GA29012@domsch.com> On Wed, Nov 21, 2007 at 09:38:43AM -0500, Jesse Keating wrote: > On Wed, 21 Nov 2007 09:30:39 -0500 > seth vidal wrote: > > > But if we have the source tarball and spec file + patches in cvs - > > which we do right now, anyway, why not generate them on demand and > > not even need to host the srpms until they're desired? > > > > We save space even in the short run. > > Because that will overtime potentially generate something that is > different than the original srpm And really, that's OK. We don't have to provide exactly the same SRPM. We have to provide the sources that went into the binary. If we provide that in a convenient SRPM form, that's fine - that's easy for our existing tools to consume. But we could post directories full of look-aside cache tarballs and patches if we wanted to. -Matt From skvidal at fedoraproject.org Wed Nov 21 14:44:43 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 21 Nov 2007 09:44:43 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <474440EE.6000907@kanarip.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> Message-ID: <1195656283.4113.14.camel@cutter> On Wed, 2007-11-21 at 15:30 +0100, Jeroen van Meeuwen wrote: > seth vidal wrote: > > 3 years is a long time for keeping the sources around if we generate > > them that way. It seems like we're better off in terms of space and in > > terms of being able to provide sources for the longer run if we can > > generate srpms on the fly out of cvs. > > > > However once you choose to generate srpms on the fly out of cvs, you are > also committing to using cvs for the same amount of time. Migrating the > cvs component to anything else might show to have a huge tail and might > just not work in the sense that the new vcs might not give you srpms > with the same checksum, or . > No we aren't committing to using cvs. We're committing to the tool which generates the srpms being able to talk to whatever we're using in the future. -sv From kanarip at kanarip.com Wed Nov 21 14:58:50 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 21 Nov 2007 15:58:50 +0100 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <1195656283.4113.14.camel@cutter> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <1195656283.4113.14.camel@cutter> Message-ID: <474447AA.6070006@kanarip.com> seth vidal wrote: > On Wed, 2007-11-21 at 15:30 +0100, Jeroen van Meeuwen wrote: >> seth vidal wrote: >>> 3 years is a long time for keeping the sources around if we generate >>> them that way. It seems like we're better off in terms of space and in >>> terms of being able to provide sources for the longer run if we can >>> generate srpms on the fly out of cvs. >>> >> However once you choose to generate srpms on the fly out of cvs, you are >> also committing to using cvs for the same amount of time. Migrating the >> cvs component to anything else might show to have a huge tail and might >> just not work in the sense that the new vcs might not give you srpms >> with the same checksum, or . >> > > No we aren't committing to using cvs. We're committing to the tool > which generates the srpms being able to talk to whatever we're using in > the future. > I'm sorry I see now I shouldn't have used 'cvs' there but the point was that we would need to be able to consistently generate the same file over and over again. However while typing this message I read: Matt Domsch wrote: > And really, that's OK. We don't have to provide exactly the same > SRPM. We have to provide the sources that went into the binary. If > we provide that in a convenient SRPM form, that's fine - that's easy > for our existing tools to consume. But we could post directories full > of look-aside cache tarballs and patches if we wanted to. So it seems the point is that it doesn't matter how or where from srpms are being created (although it seems to me a spec file with some (in the future, say 3 years from now- obsoleted tags will only be able to generate a valid srpm by a fully backwards compatible RPM implementation on the host, or we're gonna need to mock it all), and that we save space if we do; provided this actually works now and does so for a long, long period of time what's holding us back from trying to accomplish this -regardless of FP actually distributing under 3b or not? Kind regards, Jeroen "archives everything anyway" van Meeuwen -kanarip From jkeating at redhat.com Wed Nov 21 15:04:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 10:04:03 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121144831.GA29012@domsch.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> <20071121093843.46a75bad@redhat.com> <20071121144831.GA29012@domsch.com> Message-ID: <20071121100403.6a7df8a9@redhat.com> On Wed, 21 Nov 2007 08:48:32 -0600 Matt Domsch wrote: > And really, that's OK. We don't have to provide exactly the same > SRPM. We have to provide the sources that went into the binary. If > we provide that in a convenient SRPM form, that's fine - that's easy > for our existing tools to consume. But we could post directories full > of look-aside cache tarballs and patches if we wanted to. Whatever we do, I want /extremely/ clear interpretation of which ever GPL distribution method we choose to use. v2 3b/c are extremely vague and I have severe issues with using them. v3 is not exactly better in this regard. v2 3a is clear. v3 6a is pretty clear, and would apply to handing out media at trade shows or via free media. v3 6d is pretty clear and applies to how we do things today, except that it makes it more clear that you can rely on some other party to host your source, with the caveat that if the 3rd party goes away, you're still responsible for making those sources available. v3 6e clarifies bittorrent like distribution in that using v3 6d for source in conjunction with v3 6e for binary is OK, provided that you make 6e users aware of the location of 6d. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Wed Nov 21 15:15:19 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 21 Nov 2007 16:15:19 +0100 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121100403.6a7df8a9@redhat.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> <20071121093843.46a75bad@redhat.com> <20071121144831.GA29012@domsch.com> <20071121100403.6a7df8a9@redhat.com> Message-ID: <47444B87.2010303@kanarip.com> Jesse Keating wrote: > On Wed, 21 Nov 2007 08:48:32 -0600 > Matt Domsch wrote: > >> And really, that's OK. We don't have to provide exactly the same >> SRPM. We have to provide the sources that went into the binary. If >> we provide that in a convenient SRPM form, that's fine - that's easy >> for our existing tools to consume. But we could post directories full >> of look-aside cache tarballs and patches if we wanted to. > > > Whatever we do, I want /extremely/ clear interpretation of which ever > GPL distribution method we choose to use. v2 3b/c are extremely vague > and I have severe issues with using them. v3 is not exactly better in > this regard. v2 3a is clear. v3 6a is pretty clear, and would apply > to handing out media at trade shows or via free media. v3 6d is pretty > clear and applies to how we do things today, except that it makes it > more clear that you can rely on some other party to host your source, > with the caveat that if the 3rd party goes away, you're still > responsible for making those sources available. v3 6e clarifies > bittorrent like distribution in that using v3 6d for source in > conjunction with v3 6e for binary is OK, provided that you make 6e > users aware of the location of 6d. > I wasn't aware that potentially distributing via GPLv3 was in the picture too, but from what I understand v3 6d in combination with any form of the Fedora Project making the sources available for a (limited) period of time would mean that: 1) it's very clear 2) downstream can point to sources hosted by the Fedora Project 3) sources do not have to be stored 3 years, but (for example) a one release lifecycle If possible, this certainly looks like a winner. Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Wed Nov 21 15:34:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 10:34:14 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <47444B87.2010303@kanarip.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> <20071121093843.46a75bad@redhat.com> <20071121144831.GA29012@domsch.com> <20071121100403.6a7df8a9@redhat.com> <47444B87.2010303@kanarip.com> Message-ID: <20071121103414.7df6c100@redhat.com> On Wed, 21 Nov 2007 16:15:19 +0100 Jeroen van Meeuwen wrote: > 1) it's very clear > 2) downstream can point to sources hosted by the Fedora Project > 3) sources do not have to be stored 3 years, but (for example) a one > release lifecycle > > If possible, this certainly looks like a winner. Well, sources would need to be available for as long as downstreams have done a binary release based from those sources. Whether Fedora hosts those sources, or Fedora says they'll host those sources for a period of time and then retire them, at which point the downstream has to pick up the sources is debatable. Easier to manage if we provide hosting for as many downstreams as possible, at least the exploaded content so that hardlinks can be maximized. I don't know if distribution via v3 is even possible at this point, I'm just looking into the future. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From blizzard at 0xdeadbeef.com Wed Nov 21 16:55:16 2007 From: blizzard at 0xdeadbeef.com (Christopher Blizzard) Date: Wed, 21 Nov 2007 11:55:16 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <47443A80.6010207@kanarip.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> Message-ID: <72A07690-91BD-467F-AFC2-17247B7B0E6C@0xdeadbeef.com> On Nov 21, 2007, at 9:02 AM, Jeroen van Meeuwen wrote: > Personally I am opposed to trying to find clever ways to not needing > to host the source (rpms). Finding ways to do anything different > from *just making the sources available online* for a period of time > is asking for trouble; It should work, but what if it doesn't -or > fails half-way? How does investing in a couple of discs weigh (each > release?) against the potential legal liability of losing anything > because in the past you thought you needed some 'clever way' to make > sources available. There are a lot of things that we've wanted to do that this particular requirement makes difficult. We're looking for ways to do it that scale and still comply with the license. For example, if you have to keep around a source rpm for anything that you might have possibly ever might have distributed it makes for an explosion of disk space. (Scratch builds? Personal builds?) However, sources and patches don't explode anywhere near as quickly and if that can be carefully archived in a way that makes the source easy to get, then we're doing more than just complying with the license. --Chris From blizzard at 0xdeadbeef.com Wed Nov 21 16:56:26 2007 From: blizzard at 0xdeadbeef.com (Christopher Blizzard) Date: Wed, 21 Nov 2007 11:56:26 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <474440EE.6000907@kanarip.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> Message-ID: <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> On Nov 21, 2007, at 9:30 AM, Jeroen van Meeuwen wrote: > However once you choose to generate srpms on the fly out of cvs, you > are also committing to using cvs for the same amount of time. > Migrating the cvs component to anything else might show to have a > huge tail and might just not work in the sense that the new vcs > might not give you srpms with the same checksum, or unforeseen-hurdle-here>. Or you could just keep the old system around and not use it. --Chris From kanarip at kanarip.com Wed Nov 21 17:00:05 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 21 Nov 2007 18:00:05 +0100 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121103414.7df6c100@redhat.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> <20071121093843.46a75bad@redhat.com> <20071121144831.GA29012@domsch.com> <20071121100403.6a7df8a9@redhat.com> <47444B87.2010303@kanarip.com> <20071121103414.7df6c100@redhat.com> Message-ID: <47446415.1040809@kanarip.com> Jesse Keating wrote: > On Wed, 21 Nov 2007 16:15:19 +0100 > Jeroen van Meeuwen wrote: > >> 1) it's very clear >> 2) downstream can point to sources hosted by the Fedora Project >> 3) sources do not have to be stored 3 years, but (for example) a one >> release lifecycle >> >> If possible, this certainly looks like a winner. > > Well, sources would need to be available for as long as downstreams > have done a binary release based from those sources. This isn't true. It's the other way around. Downstream may point to FP as long as FP has these sources online. From the moment FP decides to take these sources off-line it's up to downstream to decide whether they take their binaries off-line or whether to continue hosting the sources themselves. Practically FP would commit to, say, hosting the sources for everything it releases for the life-cycle of the release -it's then up to downstream whether they themselves extend that period by taking over. Whether Fedora > hosts those sources, or Fedora says they'll host those sources for a > period of time and then retire them, at which point the downstream has > to pick up the sources is debatable. Easier to manage if we provide > hosting for as many downstreams as possible, at least the exploaded > content so that hardlinks can be maximized. > Am I correct to understand that you'd rather (offer to) host the sources for downstream projects separately (but hard-linked as much as possible to save some space), then just host (all of) the sources? Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Wed Nov 21 17:02:01 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 21 Nov 2007 18:02:01 +0100 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> Message-ID: <47446489.3080505@kanarip.com> Christopher Blizzard wrote: > > On Nov 21, 2007, at 9:30 AM, Jeroen van Meeuwen wrote: > >> However once you choose to generate srpms on the fly out of cvs, you >> are also committing to using cvs for the same amount of time. >> Migrating the cvs component to anything else might show to have a huge >> tail and might just not work in the sense that the new vcs might not >> give you srpms with the same checksum, or >> . > > Or you could just keep the old system around and not use it. > Keeping old systems around doesn't sound very efficient -one goal that I guess is attempted to be achieved by the "keeping-only-so-many-copies of the sources re-generating the SRPM on demand" idea. Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Wed Nov 21 17:07:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 12:07:45 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <47446415.1040809@kanarip.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> <20071121093843.46a75bad@redhat.com> <20071121144831.GA29012@domsch.com> <20071121100403.6a7df8a9@redhat.com> <47444B87.2010303@kanarip.com> <20071121103414.7df6c100@redhat.com> <47446415.1040809@kanarip.com> Message-ID: <20071121120745.372ff014@redhat.com> On Wed, 21 Nov 2007 18:00:05 +0100 Jeroen van Meeuwen wrote: > This isn't true. It's the other way around. Downstream may point to > FP as long as FP has these sources online. From the moment FP decides > to take these sources off-line it's up to downstream to decide > whether they take their binaries off-line or whether to continue > hosting the sources themselves. Practically FP would commit to, say, > hosting the sources for everything it releases for the life-cycle of > the release -it's then up to downstream whether they themselves > extend that period by taking over. I think we just said the same thing but with different words. > > Whether Fedora > > hosts those sources, or Fedora says they'll host those sources for a > > period of time and then retire them, at which point the downstream > > has to pick up the sources is debatable. Easier to manage if we > > provide hosting for as many downstreams as possible, at least the > > exploaded content so that hardlinks can be maximized. > > > > Am I correct to understand that you'd rather (offer to) host the > sources for downstream projects separately (but hard-linked as much > as possible to save some space), then just host (all of) the sources? Yes, because then we can prune more efficiently. As each binary distribution is pruned, we can prune that specific reference to a source package. If no more binary distributions exist with references to the source package, then the actual file on the file system goes away. There may be many interim updates that don't ever get included in any binary distribution (other than our updates directory) and would be pruned out automatically when the update is superseded. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From blizzard at 0xdeadbeef.com Wed Nov 21 17:11:11 2007 From: blizzard at 0xdeadbeef.com (Christopher Blizzard) Date: Wed, 21 Nov 2007 12:11:11 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <47446489.3080505@kanarip.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> Message-ID: On Nov 21, 2007, at 12:02 PM, Jeroen van Meeuwen wrote: > Keeping old systems around doesn't sound very efficient -one goal > that I guess is attempted to be achieved by the "keeping-only-so- > many-copies of the sources re-generating the SRPM on demand" idea. If it's cheaper than converting the data and it's not in active use, then it's fine. Also if the new system has to figure out how to use the old system's data it can often add unattractive constraints. Anyway, it's just an option. Just putting it out there. --Chris From jspaleta at gmail.com Wed Nov 21 17:27:56 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 Nov 2007 08:27:56 -0900 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <47446489.3080505@kanarip.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> Message-ID: <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> On Nov 21, 2007 8:02 AM, Jeroen van Meeuwen wrote: > Keeping old systems around doesn't sound very efficient -one goal that I > guess is attempted to be achieved by the "keeping-only-so-many-copies of > the sources re-generating the SRPM on demand" idea. There several issues that need to be addressed and i think the regenerated of srpms on demand makes headway on all of them without speaking to the GPL licensing issue directly. 1) We as a project are producing live-cds, and encouraging people to physically hand this out. But we are not providing source in a way that these people can easily meet the requirements of GPLv2 if someone receiving a physical livecd requests the corresponding sourcecode. How do we as a project expect this to be handled currently by ambassadors or the free media project.. or even a sitting board member? When I hand out a f7/f8 live cd and someone asks me for the corresponding source what do I say as a Fedora Board member? Are these people who are giving out physical media acting as this project's agents or acting on their own? If the are acting as our agents does this project have a legal responsibility to make sure they can meet the source code distribution requirements? If they are not acting as our agents in a legal sense, do we have an ethical obligation to make it reasonable easy for people handing out fedora media to meet the source distribution requirements? Both Jesse's idea of hardlinked archive and the srpm generation on demand will help here. But the hardlinked archive isn't going to scale out. 2) Koji is space constrained. We are going to need to flush things from koji quite frequently. I'm not sure we can rely on koji to be the point at which we archive anything even srpms. Nor do I think we have the resources to scale jesse's big pile of archived srpms. His idea may scale just fine right now, but what happens a year from now when there are 12 different active spin SIGS, each producing monthly re-spins? The space needed to house a hardlinked dump of all possible 'released' srpms is still an unbounded constraint. The cvs and lookaside space on the other hand are consuming much smaller amounts of space currently and we can most certainly set a limit on the size limit for the re-generated srpms cache. 3)re-generation of srpms on the fly lets us provide more than the absolute minimum in required service. We should be aiming to provide source distribution for everything we've built through koji and has been in a publicly facing repository.. including rawhide. The big ball of hardlinked srpms certainly can't give us source distribution coverage that also includes everything seen in the public rawhide tree. -jef From kanarip at kanarip.com Wed Nov 21 17:28:52 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 21 Nov 2007 18:28:52 +0100 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121120745.372ff014@redhat.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> <20071121093843.46a75bad@redhat.com> <20071121144831.GA29012@domsch.com> <20071121100403.6a7df8a9@redhat.com> <47444B87.2010303@kanarip.com> <20071121103414.7df6c100@redhat.com> <47446415.1040809@kanarip.com> <20071121120745.372ff014@redhat.com> Message-ID: <47446AD4.3020705@kanarip.com> Jesse Keating wrote: > Yes, because then we can prune more efficiently. As each binary > distribution is pruned, we can prune that specific reference to a > source package. If no more binary distributions exist with references > to the source package, then the actual file on the file system goes > away. There may be many interim updates that don't ever get included > in any binary distribution (other than our updates directory) and would > be pruned out automatically when the update is superseded. > On the other hand you rely on downstream to tell you when it is OK for them to have you purge the binary (as well as the sources) all and all not making it very manageable or even sustainable in the long run. Committing to provide the sources for a given period of time however let's you crontab a 'find -exec', leaving any "real responsibility" to downstream; far more efficient and way more manageable for us, good enough for anyone else. BTW, these interim updates, builds or even CVS commits are not released effectively -like you said they are never included in any binary distribution. I'm thinking these got included in the bigger picture somehow, while I was just talking about released updates (possibly including updates-testing) -nothing more, not even development/. Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Wed Nov 21 17:40:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 12:40:00 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> Message-ID: <20071121124000.24d3c93c@redhat.com> On Wed, 21 Nov 2007 08:27:56 -0900 "Jeff Spaleta" wrote: > Both Jesse's idea of hardlinked archive and the srpm generation on > demand will help here. But the hardlinked archive isn't going to scale > out. > > 2) Koji is space constrained. We are going to need to flush things > from koji quite frequently. I'm not sure we can rely on koji to be the > point at which we archive anything even srpms. Nor do I think we have > the resources to scale jesse's big pile of archived srpms. His idea > may scale just fine right now, but what happens a year from now when > there are 12 different active spin SIGS, each producing monthly > re-spins? The space needed to house a hardlinked dump of all possible > 'released' srpms is still an unbounded constraint. The cvs and > lookaside space on the other hand are consuming much smaller amounts > of space currently and we can most certainly set a limit on the size > limit for the re-generated srpms cache. > > 3)re-generation of srpms on the fly lets us provide more than the > absolute minimum in required service. We should be aiming to provide > source distribution for everything we've built through koji and has > been in a publicly facing repository.. including rawhide. The big > ball of hardlinked srpms certainly can't give us source distribution > coverage that also includes everything seen in the public rawhide > tree. I think the two efforts can go in tandem, however I would rely upon the hardlinked tree as v2 3a distribution means, and not rely upon on the fly generation to fulfill v2 3b/c. Please avoid 3b/c at all costs. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Wed Nov 21 17:48:11 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 Nov 2007 08:48:11 -0900 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121124000.24d3c93c@redhat.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> Message-ID: <604aa7910711210948y6e79e806u1cf35939eb58ea59@mail.gmail.com> On Nov 21, 2007 8:40 AM, Jesse Keating wrote: > I think the two efforts can go in tandem, however I would rely upon the > hardlinked tree as v2 3a distribution means, and not rely upon on the > fly generation to fulfill v2 3b/c. Please avoid 3b/c at all costs. When I hand out an F7 or F8 livecd in my capacity as a Fedora Board member right now, am I engaging in conduct which necesitates the use of the written offer for source code clause? -jef From jkeating at redhat.com Wed Nov 21 17:46:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 12:46:21 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <47446AD4.3020705@kanarip.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> <20071121093843.46a75bad@redhat.com> <20071121144831.GA29012@domsch.com> <20071121100403.6a7df8a9@redhat.com> <47444B87.2010303@kanarip.com> <20071121103414.7df6c100@redhat.com> <47446415.1040809@kanarip.com> <20071121120745.372ff014@redhat.com> <47446AD4.3020705@kanarip.com> Message-ID: <20071121124621.30cefb45@redhat.com> On Wed, 21 Nov 2007 18:28:52 +0100 Jeroen van Meeuwen wrote: > On the other hand you rely on downstream to tell you when it is OK > for them to have you purge the binary (as well as the sources) all > and all not making it very manageable or even sustainable in the long > run. Committing to provide the sources for a given period of time > however let's you crontab a 'find -exec', leaving any "real > responsibility" to downstream; far more efficient and way more > manageable for us, good enough for anyone else. No, I rely on the downstream to either purge their release themselves, either by replacing it with a newer one, or having it autopurged at a time agreed upon when accepting the donated hosting. The key is tying the removal of the binary release with the removal of the source release. I suppose we could be less helpful and just say we're going to host the source you used for $bla time, after that you're SOL, but I'm trying to be a bit more helpful. > > BTW, these interim updates, builds or even CVS commits are not > released effectively -like you said they are never included in any > binary distribution. I'm thinking these got included in the bigger > picture somehow, while I was just talking about released updates > (possibly including updates-testing) -nothing more, not even > development/. I was talking about released (or -testing) updates that were never included in any respin. They went out as an update, then later was replaced by a newer update, without any respin coming along and using them. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Wed Nov 21 17:51:40 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 21 Nov 2007 18:51:40 +0100 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121124000.24d3c93c@redhat.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> Message-ID: <4744702C.8000001@kanarip.com> Jesse Keating wrote: > I think the two efforts can go in tandem, however I would rely upon the > hardlinked tree as v2 3a distribution means, and not rely upon on the > fly generation to fulfill v2 3b/c. Please avoid 3b/c at all costs. > What's this? Should I now say: "Please do 3b/c because it's money better spent then trying to avoid it at all costs" ?? Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Wed Nov 21 18:15:34 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 21 Nov 2007 19:15:34 +0100 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121124621.30cefb45@redhat.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> <20071121093843.46a75bad@redhat.com> <20071121144831.GA29012@domsch.com> <20071121100403.6a7df8a9@redhat.com> <47444B87.2010303@kanarip.com> <20071121103414.7df6c100@redhat.com> <47446415.1040809@kanarip.com> <20071121120745.372ff014@redhat.com> <47446AD4.3020705@kanarip.com> <20071121124621.30cefb45@redhat.com> Message-ID: <474475C6.2090009@kanarip.com> Jesse Keating wrote: > On Wed, 21 Nov 2007 18:28:52 +0100 > Jeroen van Meeuwen wrote: > >> On the other hand you rely on downstream to tell you when it is OK >> for them to have you purge the binary (as well as the sources) all >> and all not making it very manageable or even sustainable in the long >> run. Committing to provide the sources for a given period of time >> however let's you crontab a 'find -exec', leaving any "real >> responsibility" to downstream; far more efficient and way more >> manageable for us, good enough for anyone else. > > No, I rely on the downstream to either purge their release themselves, > either by replacing it with a newer one, or having it autopurged at a > time agreed upon when accepting the donated hosting. The key is tying > the removal of the binary release with the removal of the source > release. > I see what you mean but this also means that FP is going to function as an umbrella in a way that someone down the line is not going to be able to do whatever it is he does just because someone within the FP doesn't feel like it, doesn't accept it, or, has "zero confidence" in that person (or his spin, code, you name it I may have misunderstood it). > I suppose we could be less helpful and just say we're going to host the > source you used for $bla time, after that you're SOL, but I'm trying to > be a bit more helpful. > Again this option doesn't give anyone the freedom to "go at it", as it needs FP to intervene and create some hard links. It's improvement, it sure is, but it isn't what I've been looking for all along. >> BTW, these interim updates, builds or even CVS commits are not >> released effectively -like you said they are never included in any >> binary distribution. I'm thinking these got included in the bigger >> picture somehow, while I was just talking about released updates >> (possibly including updates-testing) -nothing more, not even >> development/. > > I was talking about released (or -testing) updates that were never > included in any respin. They went out as an update, then later was > replaced by a newer update, without any respin coming along and using > them. > To optimize with such granularity... Isn't that way too much overkill? Nevermind, withdrawn. This branch in the discussion isn't my beef and I should stick to my point; giving anyone enough freedom to do whatever it is they want to do with Fedora, based on Fedora or rebranded FUbuntu for all I care, without the legal responsibilities of having to host or distribute the sources or creating any other type of overhead. No-one (individuals and small projects in particular) should care about GPL-compliance knowing that someone else has that area covered. If that means you wish to communicate with every individual or (small) project that does foo with Fedora, or else you'll purge what they are required have available when distributing their spin, in the granular matter that you are going to hard-link each file into some published directory dedicated to that one custom spin or downstream project... I don't know whether to say "Thank you" or "Good luck". Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Wed Nov 21 18:14:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 13:14:26 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <604aa7910711210948y6e79e806u1cf35939eb58ea59@mail.gmail.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <604aa7910711210948y6e79e806u1cf35939eb58ea59@mail.gmail.com> Message-ID: <20071121131426.49505f9b@redhat.com> On Wed, 21 Nov 2007 08:48:11 -0900 "Jeff Spaleta" wrote: > When I hand out an F7 or F8 livecd in my capacity as a Fedora Board > member right now, am I engaging in conduct which necesitates the use > of the written offer for source code clause? Yes. That hasn't changed. I'd really like to see us instead make a limited number of source isos to match the live image(s) so that they can be offered in tandum. If the recepient doesn't take the source, well that's just too bad. But once we stop offering the binary, then we can stop offering the source too. No need for a written offer. At least that's my non-lawyer interpretation that I have yet to validate with a lawyer. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- 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 Wed Nov 21 18:16:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 13:16:04 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <4744702C.8000001@kanarip.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <4744702C.8000001@kanarip.com> Message-ID: <20071121131604.1bbb652b@redhat.com> On Wed, 21 Nov 2007 18:51:40 +0100 Jeroen van Meeuwen wrote: > What's this? Should I now say: "Please do 3b/c because it's money > better spent then trying to avoid it at all costs" ?? I have no idea how to parse that. In my opinion, targetting 3b/c is very dangerous for Fedora as an upstream, as it is entirely too vague and could easily land us in a trap where every single source ever to pass through our build system must be always available in the same location from now until eternity. /That/ is what I'd like to avoid. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at gmail.com Wed Nov 21 18:25:11 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 21 Nov 2007 12:25:11 -0600 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <474475C6.2090009@kanarip.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> <20071121093843.46a75bad@redhat.com> <20071121144831.GA29012@domsch.com> <20071121100403.6a7df8a9@redhat.com> <47444B87.2010303@kanarip.com> <20071121103414.7df6c100@redhat.com> <47446415.1040809@kanarip.com> <20071121120745.372ff014@redhat.com> <47446AD4.3020705@kanarip.com> <20071121124621.30cefb45@redhat.com> <474475C6.2090009@kanarip.com> Message-ID: <20071121122511.6dfd1d6e@weaponx> On Wed, 21 Nov 2007 19:15:34 +0100 Jeroen van Meeuwen wrote: > This branch in the discussion isn't my beef and I should stick to my > point; giving anyone enough freedom to do whatever it is they want to do > with Fedora, based on Fedora or rebranded FUbuntu for all I care, > without the legal responsibilities of having to host or distribute the > sources or creating any other type of overhead. No-one (individuals and > small projects in particular) should care about GPL-compliance knowing > that someone else has that area covered. I think that is a dangerous statement to make. If you are distributing binaries of GPL'd work, you should care about GPL-compliance. Making an assumption that it is handled by someone else is putting their head in the sand. If Fedora is covering it for them, and they know that, great. If it isn't, or something changes, they should be prepared to get themselves back into compliance one way or another. I understand your point, but you need to be careful with how you state your goal. josh From jkeating at redhat.com Wed Nov 21 18:24:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 13:24:53 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <474475C6.2090009@kanarip.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> <20071121093843.46a75bad@redhat.com> <20071121144831.GA29012@domsch.com> <20071121100403.6a7df8a9@redhat.com> <47444B87.2010303@kanarip.com> <20071121103414.7df6c100@redhat.com> <47446415.1040809@kanarip.com> <20071121120745.372ff014@redhat.com> <47446AD4.3020705@kanarip.com> <20071121124621.30cefb45@redhat.com> <474475C6.2090009@kanarip.com> Message-ID: <20071121132453.15beb89f@redhat.com> On Wed, 21 Nov 2007 19:15:34 +0100 Jeroen van Meeuwen wrote: > This branch in the discussion isn't my beef and I should stick to my > point; giving anyone enough freedom to do whatever it is they want to > do with Fedora, based on Fedora or rebranded FUbuntu for all I care, > without the legal responsibilities of having to host or distribute > the sources or creating any other type of overhead. No-one > (individuals and small projects in particular) should care about > GPL-compliance knowing that someone else has that area covered. This is likely the basis of our disagreement then. I don't feel comfortable resting that legal obligation with Fedora, especially as an afterthought. I'd prefer that if you wish to rely upon Fedora to foot your legal requirements, you participate in our hosting program so that Fedora can ensure an end in sight for our legal assumed responsibilities. Nothing should prevent a downstream from doing their own thing, not participating with Fedora project. I would just rather that if they choose to do this, that they also choose to handle their own legal responsibilities. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Wed Nov 21 18:29:55 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 Nov 2007 09:29:55 -0900 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121131426.49505f9b@redhat.com> References: <4743BCFD.2090003@redhat.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <604aa7910711210948y6e79e806u1cf35939eb58ea59@mail.gmail.com> <20071121131426.49505f9b@redhat.com> Message-ID: <604aa7910711211029n53722ce2na0614a43bae1fab5@mail.gmail.com> On Nov 21, 2007 9:14 AM, Jesse Keating wrote: > Yes. That hasn't changed. Okay this is important. As things stand right now we aren't avoiding the need for the written offer clause with our own in-house project activities. We don't have to call forth downstream distributors to have a reason to rely on the written offer. We're already doing things in a grey manner which necessitate the use of the clause which you don't want to use. The dam has burst. > I'd really like to see us instead make a > limited number of source isos to match the live image(s) so that they > can be offered in tandum. That takes care of the official media.. but don't we have an ethical obligation to make it easy for other people acting on our behalf who are producing additional media to pass around to make available the corresponding source isos. Or in the future.. src usb keys? -jef From kanarip at kanarip.com Wed Nov 21 18:49:07 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 21 Nov 2007 19:49:07 +0100 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121122511.6dfd1d6e@weaponx> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> <20071121093843.46a75bad@redhat.com> <20071121144831.GA29012@domsch.com> <20071121100403.6a7df8a9@redhat.com> <47444B87.2010303@kanarip.com> <20071121103414.7df6c100@redhat.com> <47446415.1040809@kanarip.com> <20071121120745.372ff014@redhat.com> <47446AD4.3020705@kanarip.com> <20071121124621.30cefb45@redhat.com> <474475C6.2090009@kanarip.com> <20071121122511.6dfd1d6e@weaponx> Message-ID: <47447DA3.6040905@kanarip.com> Josh Boyer wrote: > On Wed, 21 Nov 2007 19:15:34 +0100 > Jeroen van Meeuwen wrote: >> This branch in the discussion isn't my beef and I should stick to my >> point; giving anyone enough freedom to do whatever it is they want to do >> with Fedora, based on Fedora or rebranded FUbuntu for all I care, >> without the legal responsibilities of having to host or distribute the >> sources or creating any other type of overhead. No-one (individuals and >> small projects in particular) should care about GPL-compliance knowing >> that someone else has that area covered. > > I think that is a dangerous statement to make. If you are distributing > binaries of GPL'd work, you should care about GPL-compliance. Making > an assumption that it is handled by someone else is putting their head > in the sand. > > If Fedora is covering it for them, and they know that, great. If it > isn't, or something changes, they should be prepared to get themselves > back into compliance one way or another. > > I understand your point, but you need to be careful with how you state > your goal. > When pulled out of context, it doesn't make a very good quote. The entire /thread/ is about how I want FP to carry the burden and how the individual or small project to be able to rely upon that. -Jeroen From kanarip at kanarip.com Wed Nov 21 18:51:02 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 21 Nov 2007 19:51:02 +0100 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121131604.1bbb652b@redhat.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <4744702C.8000001@kanarip.com> <20071121131604.1bbb652b@redhat.com> Message-ID: <47447E16.2040005@kanarip.com> Jesse Keating wrote: > On Wed, 21 Nov 2007 18:51:40 +0100 > Jeroen van Meeuwen wrote: > >> What's this? Should I now say: "Please do 3b/c because it's money >> better spent then trying to avoid it at all costs" ?? > > I have no idea how to parse that. > > In my opinion, targetting 3b/c is very dangerous for Fedora as an > upstream, as it is entirely too vague and could easily land us in a > trap where every single source ever to pass through our build system > must be always available in the same location from now until > eternity. /That/ is what I'd like to avoid. > Right, even in more realistic extremes that is a situation we need to avoid, but that doesn't mean we should abandon the option on beforehand. GPLv2 3b/c says you put out an offer in which the instructions are to obtain the sources and that any non-commercial party can forward that offer. So, if that offer says: "The sources of Fedora 8 and it's updates are available as of November 8th 2007, for a period of 4 years and one month, to be downloaded from d.f.r.c" -obviously without the legal speak... then what is so dangerous? How can something you say you find so vague and without any real precedence be so dangerous if complied upon? - This may be my ignorance speaking, but it's a serious question; I don't see it. At the very least we could be looking at answering two questions: 1) What's the deal with GPLv2 3b, can we use it for released non-development stuff (built, signed and pushed out to the mirrors) only and let the rest be as it is now. 2) Can we distribute under the more explicit GPLv3 and what would be it's best option. Kind regards, Jeroen van Meeuwen From a.badger at gmail.com Wed Nov 21 18:56:06 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 21 Nov 2007 10:56:06 -0800 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121132453.15beb89f@redhat.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> <20071121093843.46a75bad@redhat.com> <20071121144831.GA29012@domsch.com> <20071121100403.6a7df8a9@redhat.com> <47444B87.2010303@kanarip.com> <20071121103414.7df6c100@redhat.com> <47446415.1040809@kanarip.com> <20071121120745.372ff014@redhat.com> <47446AD4.3020705@kanarip.com> <20071121124621.30cefb45@redhat.com> <474475C6.2090009@kanarip.com> <20071121132453.15beb89f@redhat.com> Message-ID: <47447F46.2080903@gmail.com> Jesse Keating wrote: > I'd prefer that if you wish to rely upon Fedora to foot > your legal requirements, you participate in our hosting program so that > Fedora can ensure an end in sight for our legal assumed > responsibilities. > > Nothing should prevent a downstream from doing their own thing, not > participating with Fedora project. I would just rather that if they > choose to do this, that they also choose to handle their own legal > responsibilities. > So here's an interesting ramification of this: third party spins that aren't allowed to call themselves Fedora (because they add patented OSS software, for instance), won't be able to participate in our hosting program. So a solution that relies on our hosting the spins won't address the needs of those people. I don't know if that's the target audience of the initial proposal, though. -Toshio From tcallawa at redhat.com Wed Nov 21 19:00:48 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 21 Nov 2007 14:00:48 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <47447E16.2040005@kanarip.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <4744702C.8000001@kanarip.com> <20071121131604.1bbb652b@redhat.com> <47447E16.2040005@kanarip.com> Message-ID: <1195671648.6663.13.camel@localhost.localdomain> On Wed, 2007-11-21 at 19:51 +0100, Jeroen van Meeuwen wrote: > GPLv2 3b/c says you put out an offer in which the instructions are to > obtain the sources and that any non-commercial party can forward that > offer. The concern is that depending on the legal interpretation of 3b and 3c of the GPL, the clock may restart on every redistribution. So, we host a release of Fedora for 3 years, then take it down, but on the day before we do, someone else redistributes it and then asks us to honor our "3 years worth of source" promise, since for them, it hasn't been three years since their initial date of redistribution. The GPL is painfully vague on what it means here, hence Jesse's (and historically, Red Hat Legal's) instinct to avoid invoking this. ~spot From jwboyer at gmail.com Wed Nov 21 19:08:29 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 21 Nov 2007 13:08:29 -0600 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <47447DA3.6040905@kanarip.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> <20071121093843.46a75bad@redhat.com> <20071121144831.GA29012@domsch.com> <20071121100403.6a7df8a9@redhat.com> <47444B87.2010303@kanarip.com> <20071121103414.7df6c100@redhat.com> <47446415.1040809@kanarip.com> <20071121120745.372ff014@redhat.com> <47446AD4.3020705@kanarip.com> <20071121124621.30cefb45@redhat.com> <474475C6.2090009@kanarip.com> <20071121122511.6dfd1d6e@weaponx> <47447DA3.6040905@kanarip.com> Message-ID: <20071121130829.095a2df3@weaponx> On Wed, 21 Nov 2007 19:49:07 +0100 Jeroen van Meeuwen wrote: > Josh Boyer wrote: > > On Wed, 21 Nov 2007 19:15:34 +0100 > > Jeroen van Meeuwen wrote: > >> This branch in the discussion isn't my beef and I should stick to my > >> point; giving anyone enough freedom to do whatever it is they want to do > >> with Fedora, based on Fedora or rebranded FUbuntu for all I care, > >> without the legal responsibilities of having to host or distribute the > >> sources or creating any other type of overhead. No-one (individuals and > >> small projects in particular) should care about GPL-compliance knowing > >> that someone else has that area covered. > > > > I think that is a dangerous statement to make. If you are distributing > > binaries of GPL'd work, you should care about GPL-compliance. Making > > an assumption that it is handled by someone else is putting their head > > in the sand. > > > > If Fedora is covering it for them, and they know that, great. If it > > isn't, or something changes, they should be prepared to get themselves > > back into compliance one way or another. > > > > I understand your point, but you need to be careful with how you state > > your goal. > > > > When pulled out of context, it doesn't make a very good quote. The > entire /thread/ is about how I want FP to carry the burden and how the > individual or small project to be able to rely upon that. It's not out of context. Even if you accomplish your goal in getting Fedora to carry the burden _now_, that doesn't mean it can't change again in the future. GPL compliance is not something you figure out once and call it good, because things change and downstreams would have to adapt to that. josh From jspaleta at gmail.com Wed Nov 21 19:13:22 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 Nov 2007 10:13:22 -0900 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <1195671648.6663.13.camel@localhost.localdomain> References: <4743BCFD.2090003@redhat.com> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <4744702C.8000001@kanarip.com> <20071121131604.1bbb652b@redhat.com> <47447E16.2040005@kanarip.com> <1195671648.6663.13.camel@localhost.localdomain> Message-ID: <604aa7910711211113r43e7cc35vaad92271b2504d60@mail.gmail.com> On Nov 21, 2007 10:00 AM, Tom spot Callaway wrote: > The concern is that depending on the legal interpretation of 3b and 3c > of the GPL, the clock may restart on every redistribution. So, we host a > release of Fedora for 3 years, then take it down, but on the day before > we do, someone else redistributes it and then asks us to honor our "3 > years worth of source" promise, since for them, it hasn't been three > years since their initial date of redistribution. I have a pile of F7 live cds. If I'm still a board member 3 years from now (god forbid) and I had that F7 livecd out. Is Fedora as a project responsible for making the source available still? Again how we are dealing with livecds right now makes this issue unavoidable. If the clock starts over everytime i hand one of these officially pressed disks out.. you're screwed. I have enough f7 livecd disks left to hand out once a year for the next decade or more. Feel free to fly up here and forcible take them from me.... muhahahahahahaha. -jef From jkeating at redhat.com Wed Nov 21 19:14:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 14:14:30 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <604aa7910711211029n53722ce2na0614a43bae1fab5@mail.gmail.com> References: <4743BCFD.2090003@redhat.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <604aa7910711210948y6e79e806u1cf35939eb58ea59@mail.gmail.com> <20071121131426.49505f9b@redhat.com> <604aa7910711211029n53722ce2na0614a43bae1fab5@mail.gmail.com> Message-ID: <20071121141430.0812e783@redhat.com> On Wed, 21 Nov 2007 09:29:55 -0900 "Jeff Spaleta" wrote: > Okay this is important. As things stand right now we aren't avoiding > the need for the written offer clause with our own in-house project > activities. That's correct. We're just saying "LALALA" and hoping nobody calls us on it. When we gave out DVDs in the pre-live era, we'd also have source DVDs made up (or we did at some things I seem to remember) and we avoided the issue. However now, we aren't. I'd like to stop that, by offering source images at the same time we're offering live images. > We don't have to call forth downstream distributors to > have a reason to rely on the written offer. We're already doing things > in a grey manner which necessitate the use of the clause which you > don't want to use. The dam has burst. No, the dam has leaked in a few instances, but those are done with. We can right now prevent the dam from further leaking. > > > I'd really like to see us instead make a > > limited number of source isos to match the live image(s) so that > > they can be offered in tandum. > > That takes care of the official media.. but don't we have an ethical > obligation to make it easy for other people acting on our behalf who > are producing additional media to pass around to make available the > corresponding source isos. Or in the future.. src usb keys? Of course we can make it easy for them. We make the tools used to create the binary images optionally create source images. Then those that are passing out the binary media can offer the source media at the same time. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- 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 Wed Nov 21 19:15:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 14:15:34 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <47447F46.2080903@gmail.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> <20071121093843.46a75bad@redhat.com> <20071121144831.GA29012@domsch.com> <20071121100403.6a7df8a9@redhat.com> <47444B87.2010303@kanarip.com> <20071121103414.7df6c100@redhat.com> <47446415.1040809@kanarip.com> <20071121120745.372ff014@redhat.com> <47446AD4.3020705@kanarip.com> <20071121124621.30cefb45@redhat.com> <474475C6.2090009@kanarip.com> <20071121132453.15beb89f@redhat.com> <47447F46.2080903@gmail.com> Message-ID: <20071121141534.61d38f65@redhat.com> On Wed, 21 Nov 2007 10:56:06 -0800 Toshio Kuratomi wrote: > So here's an interesting ramification of this: third party spins that > aren't allowed to call themselves Fedora (because they add patented > OSS software, for instance), won't be able to participate in our > hosting program. So a solution that relies on our hosting the spins > won't address the needs of those people. > > I don't know if that's the target audience of the initial proposal, > though. I'm pretty sure we can get away with hosting them in some fashion, the same as sourceforge can get away with hosting projects that are of shady nature. It's not Fedora, it's not our product, we're just providing hosting. But yes, not a target of the initial offering. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- 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 Wed Nov 21 19:26:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 14:26:46 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <604aa7910711211113r43e7cc35vaad92271b2504d60@mail.gmail.com> References: <4743BCFD.2090003@redhat.com> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <4744702C.8000001@kanarip.com> <20071121131604.1bbb652b@redhat.com> <47447E16.2040005@kanarip.com> <1195671648.6663.13.camel@localhost.localdomain> <604aa7910711211113r43e7cc35vaad92271b2504d60@mail.gmail.com> Message-ID: <20071121142646.459a1840@redhat.com> On Wed, 21 Nov 2007 10:13:22 -0900 "Jeff Spaleta" wrote: > I have a pile of F7 live cds. If I'm still a board member 3 years from > now (god forbid) and I had that F7 livecd out. Is Fedora as a project > responsible for making the source available still? Somewhat yes. Likely we'll demand (and help you) create source discs to go along with those binary discs so you can hand them both out should the recipient want them. > Again how we are > dealing with livecds right now makes this issue unavoidable. Not so. We can be responsible and correct the issue for what we hand out in the future, regardless of when it was created. Just create source to offer with the binary and problem solved. > If the > clock starts over everytime i hand one of these officially pressed > disks out.. you're screwed. I have enough f7 livecd disks left to hand > out once a year for the next decade or more. Feel free to fly up here > and forcible take them from me.... muhahahahahahaha. We have ways of dealing with jackasses. Quite simply we can make a claim that Fedora distributed it to you, and now you're re-distributing it, and now it's -your- onus to provide either the source with it, or an offer to get the source valid for 3 years. We gave you no such offer, so we're under no obligation to honor it. (setting aside the fact that we violated the GPLv2 when we distributed it to you without either giving you the source or an offer for the source) -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Wed Nov 21 19:36:01 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 Nov 2007 10:36:01 -0900 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121142646.459a1840@redhat.com> References: <4743BCFD.2090003@redhat.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <4744702C.8000001@kanarip.com> <20071121131604.1bbb652b@redhat.com> <47447E16.2040005@kanarip.com> <1195671648.6663.13.camel@localhost.localdomain> <604aa7910711211113r43e7cc35vaad92271b2504d60@mail.gmail.com> <20071121142646.459a1840@redhat.com> Message-ID: <604aa7910711211136j168d6366x229e3e2db6701864@mail.gmail.com> On Nov 21, 2007 10:26 AM, Jesse Keating wrote: > Somewhat yes. Likely we'll demand (and help you) create source discs > to go along with those binary discs so you can hand them both out > should the recipient want them. That's what a want.. to make sure that people handing out Fedora branded media have a reasonable way to generate corresponding source media as needed for a reasonable timescale... including rawhide iso images. Or am I not allowed to hand out rawhide media to encourage more testing? -jef From jkeating at redhat.com Wed Nov 21 19:40:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 14:40:11 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <604aa7910711211136j168d6366x229e3e2db6701864@mail.gmail.com> References: <4743BCFD.2090003@redhat.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <4744702C.8000001@kanarip.com> <20071121131604.1bbb652b@redhat.com> <47447E16.2040005@kanarip.com> <1195671648.6663.13.camel@localhost.localdomain> <604aa7910711211113r43e7cc35vaad92271b2504d60@mail.gmail.com> <20071121142646.459a1840@redhat.com> <604aa7910711211136j168d6366x229e3e2db6701864@mail.gmail.com> Message-ID: <20071121144011.66837093@redhat.com> On Wed, 21 Nov 2007 10:36:01 -0900 "Jeff Spaleta" wrote: > That's what a want.. to make sure that people handing out Fedora > branded media have a reasonable way to generate corresponding source > media as needed for a reasonable timescale... including rawhide iso > images. Or am I not allowed to hand out rawhide media to encourage > more testing? Nope, you're allowed to. Want to work on a patch for livecd-creator to also create a source iso? Some of the code could be stolen from pungi. If nobody else gets to it, perhaps I'll work on this over the weekend. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwade at redhat.com Wed Nov 21 19:46:05 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 21 Nov 2007 11:46:05 -0800 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> Message-ID: <1195674366.12502.53.camel@erato.phig.org> On Wed, 2007-11-21 at 08:27 -0900, Jeff Spaleta wrote: > When I hand out a f7/f8 live cd and someone asks me for the > corresponding source what do I say as a Fedora Board member? We need e.g. sources.fedoraproject.org. Easy to remember URL that has all the details of "how to get the source", whatever that is. I mean, we can't expect every Ambassador to break out a series of steps to get the sources, right? :) - Karsten, who doesn't know the answer either -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org 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 jspaleta at gmail.com Wed Nov 21 19:48:55 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 Nov 2007 10:48:55 -0900 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121144011.66837093@redhat.com> References: <4743BCFD.2090003@redhat.com> <20071121124000.24d3c93c@redhat.com> <4744702C.8000001@kanarip.com> <20071121131604.1bbb652b@redhat.com> <47447E16.2040005@kanarip.com> <1195671648.6663.13.camel@localhost.localdomain> <604aa7910711211113r43e7cc35vaad92271b2504d60@mail.gmail.com> <20071121142646.459a1840@redhat.com> <604aa7910711211136j168d6366x229e3e2db6701864@mail.gmail.com> <20071121144011.66837093@redhat.com> Message-ID: <604aa7910711211148g682e0432h4a67f52f928e2bf4@mail.gmail.com> On Nov 21, 2007 10:40 AM, Jesse Keating wrote: > Nope, you're allowed to. Want to work on a patch for livecd-creator to > also create a source iso? Some of the code could be stolen from > pungi. If nobody else gets to it, perhaps I'll work on this over the > weekend. Do i want to? only if I can make it generate animated theora maps as well as src isos! I'll have to dig into pungi first and make sure I understand how its being done there. Are you saying that as a project we can make a commitment to producing the corresponding source media image for every binary media image we produce at the time of binary media image production? I still think that we're gonna hit a scalability problem here. But your right no matter how we implement the rest of it making it cookie-cutter easy to generate the source media for a livecd is going to be a necessary piece of the puzzle whether we use a hardlinked cache of srpms or generate them as needed. -jef From kwade at redhat.com Wed Nov 21 19:56:08 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 21 Nov 2007 11:56:08 -0800 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121103414.7df6c100@redhat.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> <20071121093843.46a75bad@redhat.com> <20071121144831.GA29012@domsch.com> <20071121100403.6a7df8a9@redhat.com> <47444B87.2010303@kanarip.com> <20071121103414.7df6c100@redhat.com> Message-ID: <1195674968.12502.59.camel@erato.phig.org> On Wed, 2007-11-21 at 10:34 -0500, Jesse Keating wrote: > Well, sources would need to be available for as long as downstreams > have done a binary release based from those sources. Whether Fedora > hosts those sources, or Fedora says they'll host those sources for a > period of time and then retire them, at which point the downstream has > to pick up the sources is debatable. Easier to manage if we provide > hosting for as many downstreams as possible, at least the exploaded > content so that hardlinks can be maximized. Note that EPEL, a Fedora project, has a much longer window of usage of packages based on older Fedora source. Currently eight years. How does EPEL fit in here? Is it a downstream? EPEL explicitly only supports what people are interested in maintaining. I.e., a package for EPEL 5 may be orphaned after a few years. Does EPEL's obligation to make sources available stop at that time? Or N periods of time after that? What if a package is un-orphaned after that? E.g., during year four, someone picks up an orphaned foo.rpm. Does that restart the clock on making sources available? What does EPEL do if Fedora no longer has that source available? - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org 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 poelstra at redhat.com Wed Nov 21 21:37:05 2007 From: poelstra at redhat.com (John Poelstra) Date: Wed, 21 Nov 2007 13:37:05 -0800 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121141430.0812e783@redhat.com> References: <4743BCFD.2090003@redhat.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <604aa7910711210948y6e79e806u1cf35939eb58ea59@mail.gmail.com> <20071121131426.49505f9b@redhat.com> <604aa7910711211029n53722ce2na0614a43bae1fab5@mail.gmail.com> <20071121141430.0812e783@redhat.com> Message-ID: <4744A501.2080707@redhat.com> Jesse Keating said the following on 11/21/2007 11:14 AM Pacific Time: > On Wed, 21 Nov 2007 09:29:55 -0900 > "Jeff Spaleta" wrote: > >> Okay this is important. As things stand right now we aren't avoiding >> the need for the written offer clause with our own in-house project >> activities. > > That's correct. We're just saying "LALALA" and hoping nobody calls us > on it. When we gave out DVDs in the pre-live era, we'd also have > source DVDs made up (or we did at some things I seem to remember) and > we avoided the issue. However now, we aren't. I'd like to stop that, > by offering source images at the same time we're offering live images. Maybe this has already been discussed, but what have the distros with live CDs done before us? Are we really the first project to try and solve this problem? John From kanarip at kanarip.com Wed Nov 21 21:43:54 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 21 Nov 2007 22:43:54 +0100 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <1195671648.6663.13.camel@localhost.localdomain> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <4744702C.8000001@kanarip.com> <20071121131604.1bbb652b@redhat.com> <47447E16.2040005@kanarip.com> <1195671648.6663.13.camel@localhost.localdomain> Message-ID: <4744A69A.802@kanarip.com> Tom "spot" Callaway wrote: > On Wed, 2007-11-21 at 19:51 +0100, Jeroen van Meeuwen wrote: >> GPLv2 3b/c says you put out an offer in which the instructions are to >> obtain the sources and that any non-commercial party can forward that >> offer. > > The concern is that depending on the legal interpretation of 3b and 3c > of the GPL, the clock may restart on every redistribution. So, we host a > release of Fedora for 3 years, then take it down, but on the day before > we do, someone else redistributes it and then asks us to honor our "3 > years worth of source" promise, since for them, it hasn't been three > years since their initial date of redistribution. > > The GPL is painfully vague on what it means here, hence Jesse's (and > historically, Red Hat Legal's) instinct to avoid invoking this. > GPLv2 doesn't say though that once the binary is released originally, the clock starts ticking all over again each time it is redistributed by a third party that uses 3c. A written offer can easily contain a time frame consistent with the three years described in the license, possibly extended to 3 years + a release's lifecycle. If this is really so much of a concern, we wouldn't have released any live media until we cleared this -or we are potentially stabbing ourselves in the back by not being (entirely) GPL compliant in this aspect. Either we investigate what is (or is not) possible under GPLv2 3b/c or GPLv3 6-, or we should just say "no" -in which case someone else might pick this up and re-distribute Fedora (almost entirely) under GPLv2 3b. -Jeroen From kanarip at kanarip.com Wed Nov 21 21:54:15 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 21 Nov 2007 22:54:15 +0100 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121130829.095a2df3@weaponx> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> <20071121093843.46a75bad@redhat.com> <20071121144831.GA29012@domsch.com> <20071121100403.6a7df8a9@redhat.com> <47444B87.2010303@kanarip.com> <20071121103414.7df6c100@redhat.com> <47446415.1040809@kanarip.com> <20071121120745.372ff014@redhat.com> <47446AD4.3020705@kanarip.com> <20071121124621.30cefb45@redhat.com> <474475C6.2090009@kanarip.com> <20071121122511.6dfd1d6e@weaponx> <47447DA3.6040905@kanarip.com> <20071121130829.095a2df3@weaponx> Message-ID: <4744A907.9020307@kanarip.com> Josh Boyer wrote: > On Wed, 21 Nov 2007 19:49:07 +0100 > Jeroen van Meeuwen wrote: > >> Josh Boyer wrote: >>> On Wed, 21 Nov 2007 19:15:34 +0100 >>> Jeroen van Meeuwen wrote: >>>> This branch in the discussion isn't my beef and I should stick to my >>>> point; giving anyone enough freedom to do whatever it is they want to do >>>> with Fedora, based on Fedora or rebranded FUbuntu for all I care, >>>> without the legal responsibilities of having to host or distribute the >>>> sources or creating any other type of overhead. No-one (individuals and >>>> small projects in particular) should care about GPL-compliance knowing >>>> that someone else has that area covered. >>> I think that is a dangerous statement to make. If you are distributing >>> binaries of GPL'd work, you should care about GPL-compliance. Making >>> an assumption that it is handled by someone else is putting their head >>> in the sand. >>> >>> If Fedora is covering it for them, and they know that, great. If it >>> isn't, or something changes, they should be prepared to get themselves >>> back into compliance one way or another. >>> >>> I understand your point, but you need to be careful with how you state >>> your goal. >>> >> When pulled out of context, it doesn't make a very good quote. The >> entire /thread/ is about how I want FP to carry the burden and how the >> individual or small project to be able to rely upon that. > > It's not out of context. > > Even if you accomplish your goal in getting Fedora to carry the burden > _now_, that doesn't mean it can't change again in the future. GPL > compliance is not something you figure out once and call it good, > because things change and downstreams would have to adapt to that. > > josh > Luckily for the Fedora Project though hosting the sources for a given time frame under GPLv2 3b _now_ does not include the responsibility of downstream's adaption to changes _later_, while in Jesse's proposal things end up so tight every change upstream means a change downstream and vice-versa. -Jeroen From jkeating at redhat.com Wed Nov 21 22:50:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 17:50:49 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <1195674968.12502.59.camel@erato.phig.org> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <20071121092500.5545ed9c@redhat.com> <1195655439.4113.12.camel@cutter> <20071121093843.46a75bad@redhat.com> <20071121144831.GA29012@domsch.com> <20071121100403.6a7df8a9@redhat.com> <47444B87.2010303@kanarip.com> <20071121103414.7df6c100@redhat.com> <1195674968.12502.59.camel@erato.phig.org> Message-ID: <20071121175049.31eebc74@redhat.com> On Wed, 21 Nov 2007 11:56:08 -0800 Karsten Wade wrote: > Note that EPEL, a Fedora project, has a much longer window of usage of > packages based on older Fedora source. Currently eight years. > > How does EPEL fit in here? Is it a downstream? As I see it, EPEL is it's own project, because it publishes the srpms along side the binaries. > > EPEL explicitly only supports what people are interested in > maintaining. I.e., a package for EPEL 5 may be orphaned after a few > years. > > Does EPEL's obligation to make sources available stop at that time? > Or N periods of time after that? EPELs obligation with regard to the sources lasts as long as the binary is made available. If you retire the binary, you can retire the source. > > What if a package is un-orphaned after that? E.g., during year four, > someone picks up an orphaned foo.rpm. Does that restart the clock on > making sources available? What does EPEL do if Fedora no longer has > that source available? Again, unorphaning the package would mean making a build for it, which would produce a binary, and a source. The source would be made available along with the binary, and then there is no clock. Just keep the source up as long as the binary. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- 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 Wed Nov 21 22:53:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 17:53:36 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <604aa7910711211148g682e0432h4a67f52f928e2bf4@mail.gmail.com> References: <4743BCFD.2090003@redhat.com> <20071121124000.24d3c93c@redhat.com> <4744702C.8000001@kanarip.com> <20071121131604.1bbb652b@redhat.com> <47447E16.2040005@kanarip.com> <1195671648.6663.13.camel@localhost.localdomain> <604aa7910711211113r43e7cc35vaad92271b2504d60@mail.gmail.com> <20071121142646.459a1840@redhat.com> <604aa7910711211136j168d6366x229e3e2db6701864@mail.gmail.com> <20071121144011.66837093@redhat.com> <604aa7910711211148g682e0432h4a67f52f928e2bf4@mail.gmail.com> Message-ID: <20071121175336.73da8ffa@redhat.com> On Wed, 21 Nov 2007 10:48:55 -0900 "Jeff Spaleta" wrote: > Are you saying that as a project we can make a commitment to producing > the corresponding source media image for every binary media image we > produce at the time of binary media image production? We can get away with making a limited number of source isos that works for either the specific binary images we hand out, or maybe one larger one that works for all the binary ones. I just propose that we use this method instead of an offer to download the sources, which would pin us to at least 3 years, potentially a /lot/ more depending on the interpretation of the license. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- 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 Wed Nov 21 22:57:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 17:57:10 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <4744A69A.802@kanarip.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <4744702C.8000001@kanarip.com> <20071121131604.1bbb652b@redhat.com> <47447E16.2040005@kanarip.com> <1195671648.6663.13.camel@localhost.localdomain> <4744A69A.802@kanarip.com> Message-ID: <20071121175710.5cb57c76@redhat.com> On Wed, 21 Nov 2007 22:43:54 +0100 Jeroen van Meeuwen wrote: > GPLv2 doesn't say though that once the binary is released originally, > the clock starts ticking all over again each time it is redistributed > by a third party that uses 3c. A written offer can easily contain a > time frame consistent with the three years described in the license, > possibly extended to 3 years + a release's lifecycle. That's your interpretation. Are you a lawyer? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- 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 Nov 21 23:16:19 2007 From: matt at domsch.com (Matt Domsch) Date: Wed, 21 Nov 2007 17:16:19 -0600 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121175710.5cb57c76@redhat.com> References: <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <4744702C.8000001@kanarip.com> <20071121131604.1bbb652b@redhat.com> <47447E16.2040005@kanarip.com> <1195671648.6663.13.camel@localhost.localdomain> <4744A69A.802@kanarip.com> <20071121175710.5cb57c76@redhat.com> Message-ID: <20071121231614.GB29012@domsch.com> On Wed, Nov 21, 2007 at 05:57:10PM -0500, Jesse Keating wrote: > On Wed, 21 Nov 2007 22:43:54 +0100 > Jeroen van Meeuwen wrote: > > > GPLv2 doesn't say though that once the binary is released originally, > > the clock starts ticking all over again each time it is redistributed > > by a third party that uses 3c. A written offer can easily contain a > > time frame consistent with the three years described in the license, > > possibly extended to 3 years + a release's lifecycle. > > That's your interpretation. Are you a lawyer? Without putting words in people's mouths, including a time frame is consistent with my conversation with Brett Smith of the FSF. -Matt From kanarip at kanarip.com Wed Nov 21 23:19:35 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 22 Nov 2007 00:19:35 +0100 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121175710.5cb57c76@redhat.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <4744702C.8000001@kanarip.com> <20071121131604.1bbb652b@redhat.com> <47447E16.2040005@kanarip.com> <1195671648.6663.13.camel@localhost.localdomain> <4744A69A.802@kanarip.com> <20071121175710.5cb57c76@redhat.com> Message-ID: <4744BD07.9070705@kanarip.com> Jesse Keating wrote: > On Wed, 21 Nov 2007 22:43:54 +0100 > Jeroen van Meeuwen wrote: > >> GPLv2 doesn't say though that once the binary is released originally, >> the clock starts ticking all over again each time it is redistributed >> by a third party that uses 3c. A written offer can easily contain a >> time frame consistent with the three years described in the license, >> possibly extended to 3 years + a release's lifecycle. > > That's your interpretation. Are you a lawyer? > You on the other hand are fearing the exact opposite so much you wouldn't let anyone dig into it -"Please avoid at all costs". Now, tell me, are you a lawyer, Mr. Keating? Don't try and make this about me, attack my opinion with arguments, please. Last time I checked we share a common goal here -a greater good if you will. Haven't I requested -since you think it is so dangerous- to determine what it is it says we can or cannot do? -Jeroen From kanarip at kanarip.com Wed Nov 21 23:21:27 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 22 Nov 2007 00:21:27 +0100 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121231614.GB29012@domsch.com> References: <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <4744702C.8000001@kanarip.com> <20071121131604.1bbb652b@redhat.com> <47447E16.2040005@kanarip.com> <1195671648.6663.13.camel@localhost.localdomain> <4744A69A.802@kanarip.com> <20071121175710.5cb57c76@redhat.com> <20071121231614.GB29012@domsch.com> Message-ID: <4744BD77.6030706@kanarip.com> Matt Domsch wrote: > On Wed, Nov 21, 2007 at 05:57:10PM -0500, Jesse Keating wrote: >> On Wed, 21 Nov 2007 22:43:54 +0100 >> Jeroen van Meeuwen wrote: >> >>> GPLv2 doesn't say though that once the binary is released originally, >>> the clock starts ticking all over again each time it is redistributed >>> by a third party that uses 3c. A written offer can easily contain a >>> time frame consistent with the three years described in the license, >>> possibly extended to 3 years + a release's lifecycle. >> That's your interpretation. Are you a lawyer? > > Without putting words in people's mouths, including a time frame is > consistent with my conversation with Brett Smith of the FSF. > So has it been with some people I've talked to -can't think of their names right now. The overall impression was though, that the counter does not reset itself because of some third party taking you up on the original offer. Hence the thought it might be worthwhile to investigate. -Jeroen From jkeating at redhat.com Wed Nov 21 23:22:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Nov 2007 18:22:32 -0500 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <4744BD07.9070705@kanarip.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <4744702C.8000001@kanarip.com> <20071121131604.1bbb652b@redhat.com> <47447E16.2040005@kanarip.com> <1195671648.6663.13.camel@localhost.localdomain> <4744A69A.802@kanarip.com> <20071121175710.5cb57c76@redhat.com> <4744BD07.9070705@kanarip.com> Message-ID: <20071121182232.666a3758@redhat.com> On Thu, 22 Nov 2007 00:19:35 +0100 Jeroen van Meeuwen wrote: > You on the other hand are fearing the exact opposite so much you > wouldn't let anyone dig into it -"Please avoid at all costs". Now, > tell me, are you a lawyer, Mr. Keating? Don't try and make this about > me, attack my opinion with arguments, please. Last time I checked we > share a common goal here -a greater good if you will. > > Haven't I requested -since you think it is so dangerous- to determine > what it is it says we can or cannot do? It's already on my to-do list to have a nice long sitdown with our legal team regarding this issue. However it's not something I can do today. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Wed Nov 21 23:44:37 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 22 Nov 2007 00:44:37 +0100 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121182232.666a3758@redhat.com> References: <4743BCFD.2090003@redhat.com> <20071121081620.3bf6586d@redhat.com> <47443A80.6010207@kanarip.com> <20071121090736.48f8efc8@redhat.com> <1195654530.4113.4.camel@cutter> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <4744702C.8000001@kanarip.com> <20071121131604.1bbb652b@redhat.com> <47447E16.2040005@kanarip.com> <1195671648.6663.13.camel@localhost.localdomain> <4744A69A.802@kanarip.com> <20071121175710.5cb57c76@redhat.com> <4744BD07.9070705@kanarip.com> <20071121182232.666a3758@redhat.com> Message-ID: <4744C2E5.6000704@kanarip.com> Jesse Keating wrote: > On Thu, 22 Nov 2007 00:19:35 +0100 > Jeroen van Meeuwen wrote: > >> You on the other hand are fearing the exact opposite so much you >> wouldn't let anyone dig into it -"Please avoid at all costs". Now, >> tell me, are you a lawyer, Mr. Keating? Don't try and make this about >> me, attack my opinion with arguments, please. Last time I checked we >> share a common goal here -a greater good if you will. >> >> Haven't I requested -since you think it is so dangerous- to determine >> what it is it says we can or cannot do? > > It's already on my to-do list to have a nice long sitdown with our > legal team regarding this issue. However it's not something I can do > today. > Sure I understand, thanks for following up on this. Really, thanks. Kind regards, Jeroen van Meeuwen -kanarip From jspaleta at gmail.com Thu Nov 22 00:40:16 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 Nov 2007 15:40:16 -0900 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <20071121231614.GB29012@domsch.com> References: <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <4744702C.8000001@kanarip.com> <20071121131604.1bbb652b@redhat.com> <47447E16.2040005@kanarip.com> <1195671648.6663.13.camel@localhost.localdomain> <4744A69A.802@kanarip.com> <20071121175710.5cb57c76@redhat.com> <20071121231614.GB29012@domsch.com> Message-ID: <604aa7910711211640y76befb43g621dd68b6eb13797@mail.gmail.com> On Nov 21, 2007 2:16 PM, Matt Domsch wrote: > Without putting words in people's mouths, including a time frame is > consistent with my conversation with Brett Smith of the FSF. We've pretty much come to the point where we have to have a legal ruling as to which if any GPLv2 or v3 "offer" clauses are consistent with the idea of a pre-defined time frame. The discussion of whether or not we want to make use or encourage the use of any such clause can't move forward until we know if setting an explicit time frame as part of an offer does really set a limit of the project's burden to provide source. I've long ago given up the notion that common-sense makes any sense when applied to legalese. In the mean time we have to do something with regard to source availability for at least the media images that we host. And I still would like to see us implement srpm re-generation on demand to help aid consumers get source for a reasonable period of time (that is above and beyond the strict legal requirements) for releases,updates,updates-testing and even rawhide. -jef From loupgaroublond at gmail.com Thu Nov 22 07:51:39 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 22 Nov 2007 02:51:39 -0500 Subject: Making respins with custom configs and files Message-ID: <7f692fec0711212351i4492f3b9o7fe9ef2fa05b9ff5@mail.gmail.com> Hey List, I've come out of my coding ban (till finals are over) to work on a small side project. It's a tool that lets you pick a set of files from a running system, they could be anything, config files, random non-free fonts installed to /usr/share/fonts/, grub splash screens, etc..., and lets you make an RPM out of them. Since some of these files might clash with other packages, it doesn't install them directly to the root, but hidden away in /usr/share. There is a second tool that then deploys these lumps of files. It solves the following use cases: Scenario 1 Tim is a power user. He has a system heavily configured, with a custom set of packages, from five repos, and all sorts of other things he found on online on deviantart. He wants to make a respin of his computer using Revisor, so he can pop a CD in the brand new machine, use it to install Fedora, and be up and running in under 30 minutes. Since a large number of files that are not in his /home partition are just as important still require time setting up, he would rather tell Revisor where to look, and have it copy all these files automatically. He's also given a package full of files that he could drop into a private repo if he ever finds the time to set one up. Scenario 2 Kim is a computer science student. She's been given an assignment that involves a complicated build and runtime environment. In her proprietary-software centric school, ensuring that her code will compile and run cleanly when she submits it for a grade is a huge chore. She would rather give the professors a Live CD saying 'run this', that drops them into a stripped down Gnome environment, with a terminal, and all her programs sitting on the desktop. She gets an A, and her professor starts considering incorporating Linux into the curriculum for its ease of use. Scenario 3 Jim is a technician for Megacorp and is configuring a bunch of machines. He knows how to make RPMs, but it is a lengthy process since he is not familiar with it. He has a set of files he wants to include with every system he configures, that include corporate branding on every spot available. The list of files is large, but the only thing he needs to do is copy them to specific places. He would rather just give a command a list of files that spits out a spec file and a tarball that he can add to an automated system. The packages will then be deployed the next time he schedules an update. Right now, I have two working scripts. There are a couple of minor bugs, and I have some SELinux questions. Is this something people want to see in Fedora 9? Would it be useful to the revisor/respin crowd? Or am I completely off the mark here, and someone has a better idea? Cheers, Yaakov From kanarip at kanarip.com Thu Nov 22 11:33:39 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 22 Nov 2007 12:33:39 +0100 Subject: Making respins with custom configs and files In-Reply-To: <7f692fec0711212351i4492f3b9o7fe9ef2fa05b9ff5@mail.gmail.com> References: <7f692fec0711212351i4492f3b9o7fe9ef2fa05b9ff5@mail.gmail.com> Message-ID: <47456913.1030206@kanarip.com> Hi Yaakov, the Fedora Advisory Board may not be the most appropriate list to discuss Fedora 9 or Revisor features, more appropriate maybe is the Revisor development or user discussion list[1], and the fedora-livecd-list[2]. However looking at what it is you are trying to solve, have you tried working with copy_dir maybe? Revisor uses that setting to copy all contents from that location onto the live or installation media. With Live Media these files are copied onto "/" which is to become the root filesystem once you boot up the Live Media, and with Installation Media it copies it into the files/ directory in the tree (so that during the installation you can use it in %post). If this has any short-comings on solving the scenario's you are addressing, please let me know because I think these are perfectly valid use cases. Kind regards, Jeroen van Meeuwen -kanarip [1] Revisor mailing lists: http://lists.fedoraunity.org [2] Fedora Live CD List: http://www.redhat.com/mailman/listinfo/fedora-livecd-list Yaakov Nemoy wrote: > Hey List, > > I've come out of my coding ban (till finals are over) to work on a > small side project. It's a tool that lets you pick a set of files > from a running system, they could be anything, config files, random > non-free fonts installed to /usr/share/fonts/, grub splash screens, > etc..., and lets you make an RPM out of them. Since some of these > files might clash with other packages, it doesn't install them > directly to the root, but hidden away in /usr/share. There is a > second tool that then deploys these lumps of files. It solves the > following use cases: > > Scenario 1 > Tim is a power user. He has a system heavily configured, with a > custom set of packages, from five repos, and all sorts of other things > he found on online on deviantart. He wants to make a respin of his > computer using Revisor, so he can pop a CD in the brand new machine, > use it to install Fedora, and be up and running in under 30 minutes. > Since a large number of files that are not in his /home partition are > just as important still require time setting up, he would rather tell > Revisor where to look, and have it copy all these files automatically. > He's also given a package full of files that he could drop into a > private repo if he ever finds the time to set one up. > > Scenario 2 > Kim is a computer science student. She's been given an assignment > that involves a complicated build and runtime environment. In her > proprietary-software centric school, ensuring that her code will > compile and run cleanly when she submits it for a grade is a huge > chore. She would rather give the professors a Live CD saying 'run > this', that drops them into a stripped down Gnome environment, with a > terminal, and all her programs sitting on the desktop. She gets an A, > and her professor starts considering incorporating Linux into the > curriculum for its ease of use. > > Scenario 3 > Jim is a technician for Megacorp and is configuring a bunch of > machines. He knows how to make RPMs, but it is a lengthy process > since he is not familiar with it. He has a set of files he wants to > include with every system he configures, that include corporate > branding on every spot available. The list of files is large, but the > only thing he needs to do is copy them to specific places. He would > rather just give a command a list of files that spits out a spec file > and a tarball that he can add to an automated system. The packages > will then be deployed the next time he schedules an update. > > > Right now, I have two working scripts. There are a couple of minor > bugs, and I have some SELinux questions. Is this something people > want to see in Fedora 9? Would it be useful to the revisor/respin > crowd? Or am I completely off the mark here, and someone has a better > idea? > > Cheers, > Yaakov > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board From bob at fedoraunity.org Thu Nov 22 21:40:52 2007 From: bob at fedoraunity.org (Robert 'Bob' Jensen) Date: Thu, 22 Nov 2007 15:40:52 -0600 Subject: Fedora Board Recap 2007-NOV-13 In-Reply-To: <604aa7910711211113r43e7cc35vaad92271b2504d60@mail.gmail.com> References: <4743BCFD.2090003@redhat.com> <474440EE.6000907@kanarip.com> <67E6457A-0AB5-41A6-B53D-A0BA55EC4CC8@0xdeadbeef.com> <47446489.3080505@kanarip.com> <604aa7910711210927k63cbd7eev77fcc24a4b2489e1@mail.gmail.com> <20071121124000.24d3c93c@redhat.com> <4744702C.8000001@kanarip.com> <20071121131604.1bbb652b@redhat.com> <47447E16.2040005@kanarip.com> <1195671648.6663.13.camel@localhost.localdomain> <604aa7910711211113r43e7cc35vaad92271b2504d60@mail.gmail.com> Message-ID: <4745F764.9040500@fedoraunity.org> Jeff Spaleta wrote: > On Nov 21, 2007 10:00 AM, Tom spot Callaway wrote: >> The concern is that depending on the legal interpretation of 3b and 3c >> of the GPL, the clock may restart on every redistribution. So, we host a >> release of Fedora for 3 years, then take it down, but on the day before >> we do, someone else redistributes it and then asks us to honor our "3 >> years worth of source" promise, since for them, it hasn't been three >> years since their initial date of redistribution. > > I have a pile of F7 live cds. If I'm still a board member 3 years from > now (god forbid) and I had that F7 livecd out. Is Fedora as a project > responsible for making the source available still? Again how we are > dealing with livecds right now makes this issue unavoidable. If the > clock starts over everytime i hand one of these officially pressed > disks out.. you're screwed. I have enough f7 livecd disks left to hand > out once a year for the next decade or more. Feel free to fly up here > and forcible take them from me.... muhahahahahahaha. > > -jef > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board I can go one better, I have Fedora Core 6 PPC DVDs.... Robert 'Bob' Jensen Fedora Unity Project Fedora Ambassador Fedora Contributor http://fedoraproject.org/wiki/BobJensen From mspevack at redhat.com Mon Nov 26 16:31:26 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 26 Nov 2007 11:31:26 -0500 (EST) Subject: Fedora Board Elections Message-ID: As you all know, the Fedora Board consists of 9 seats -- 5 appointed by Red Hat and 4 elected by the community. After Fedora 7's release, 6 of those 9 seats rotated -- 3 appointed and 3 elected. Now that Fedora 8 has been released, the other 3 seats need to rotate -- 2 of the appointed ones, and 1 elected seat. Bill Nottingham is going to remain on the Fedora Board in an appointed seat. The second appointment will be made soon -- Chris Blizzard has stepped aside from the Fedora Board, and we are looking at a couple of different ideas for his seat. We only have 1 elected seat open this time around, but I wanted to kick off the process for filling it. Last time, the community elected Dennis Gilmore, Jef Spaleta, and Chris Aillon to the Fedora Board -- all superb choices. http://fedoraproject.org/wiki/Board/Elections The URL above contains all the necessary information. Nominations are open until December 6th. Thanks, Max From mspevack at redhat.com Mon Nov 26 17:24:12 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 26 Nov 2007 12:24:12 -0500 (EST) Subject: Fedora Board Elections In-Reply-To: References: Message-ID: On Mon, 26 Nov 2007, Max Spevack wrote: > Now that Fedora 8 has been released, the other 3 seats need to rotate > -- 2 of the appointed ones, and 1 elected seat. We will try to balance this out at 2/2 in the future -- Seth's hire and transfer from elected to appointed seat messed up the spacing a little bit. --Max From matt at domsch.com Mon Nov 26 18:11:57 2007 From: matt at domsch.com (Matt Domsch) Date: Mon, 26 Nov 2007 12:11:57 -0600 Subject: Fedora Board Elections In-Reply-To: References: Message-ID: <20071126181156.GC18422@domsch.com> On Mon, Nov 26, 2007 at 11:31:26AM -0500, Max Spevack wrote: > As you all know, the Fedora Board consists of 9 seats -- 5 appointed by > Red Hat and 4 elected by the community. > > After Fedora 7's release, 6 of those 9 seats rotated -- 3 appointed and > 3 elected. > > Now that Fedora 8 has been released, the other 3 seats need to rotate -- > 2 of the appointed ones, and 1 elected seat. > > Bill Nottingham is going to remain on the Fedora Board in an appointed > seat. The second appointment will be made soon -- Chris Blizzard has > stepped aside from the Fedora Board, and we are looking at a couple of > different ideas for his seat. > > We only have 1 elected seat open this time around, but I wanted to kick > off the process for filling it. FWIW, I'm currently occupying this seat, and will stand for re-election, but would be quite happy to see additional candidates. I've updated http://fedoraproject.org/wiki/Board/Elections/Nominations. Thanks, Matt From msaksena at marvell.com Tue Nov 27 17:21:41 2007 From: msaksena at marvell.com (Manas Saksena) Date: Tue, 27 Nov 2007 09:21:41 -0800 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions Message-ID: <1196184101.19184.50.camel@localhost.localdomain> Hi, I would like to request support for hosting git conversion of Fedora CVS as per Lennert's post to fedora-infrastructure-list. https://www.redhat.com/archives/fedora-infrastructure-list/2007-November/msg00136.html While there were a few responses to the mail (both support and skepticism) there was no clear decision. The basic idea of this effort is to enable downstream development efforts that make use of the fedora package repository as their upstream source. The specific efforts that I am interested are: 1. Building small footprint systems (for embedded systems use). 2. Cross-building (a subset of) Fedora packages. 3. Support for architectures and platforms that are not (yet) integrated into the Fedora project. 4. Building a GNOME Mobile distribution. etc. Others may find it useful for other purposes. The git tree does not have to be hosted in the fedora infrastructure, but it seems like the natural place for it to be. It also sends the message that the Fedora project encourages downstream efforts that can leverage Fedora into areas that are not of direct/current interest for the project. So, in summary, I would appreciate if the Fedora board can consider this request and provide clear guidance on whether this activity can/should be supported through the fedora infrastructure. Regards, Manas Saksena From skvidal at fedoraproject.org Tue Nov 27 18:15:34 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 27 Nov 2007 13:15:34 -0500 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <1196184101.19184.50.camel@localhost.localdomain> References: <1196184101.19184.50.camel@localhost.localdomain> Message-ID: <1196187334.15420.116.camel@cutter> On Tue, 2007-11-27 at 09:21 -0800, Manas Saksena wrote: > Hi, > > I would like to request support for hosting git conversion of Fedora CVS > as per Lennert's post to fedora-infrastructure-list. > > https://www.redhat.com/archives/fedora-infrastructure-list/2007-November/msg00136.html > > While there were a few responses to the mail (both support and > skepticism) there was no clear decision. > > The basic idea of this effort is to enable downstream development > efforts that make use of the fedora package repository as their upstream > source. > > The specific efforts that I am interested are: > > 1. Building small footprint systems (for embedded systems use). > 2. Cross-building (a subset of) Fedora packages. > 3. Support for architectures and platforms that are not (yet) integrated > into the Fedora project. > 4. Building a GNOME Mobile distribution. > > etc. Others may find it useful for other purposes. > > The git tree does not have to be hosted in the fedora infrastructure, > but it seems like the natural place for it to be. It also sends the > message that the Fedora project encourages downstream efforts that can > leverage Fedora into areas that are not of direct/current interest for > the project. > > So, in summary, I would appreciate if the Fedora board can consider this > request and provide clear guidance on whether this activity can/should > be supported through the fedora infrastructure. I'm not positive but this doesn't seem like a board decision. If the releng, fesco and infrastructure teams are at an impasse we can take it up for discussion but I don't see a reason to not let those groups do what they're supposed to do. -sv From msaksena at marvell.com Wed Nov 28 03:49:46 2007 From: msaksena at marvell.com (Manas Saksena) Date: Tue, 27 Nov 2007 19:49:46 -0800 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enabledownstream development efforts and distributions In-Reply-To: <1196187334.15420.116.camel@cutter> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> Message-ID: <1196221786.19184.69.camel@localhost.localdomain> On Tue, 2007-11-27 at 10:15 -0800, seth vidal wrote: > > On Tue, 2007-11-27 at 09:21 -0800, Manas Saksena wrote: > > Hi, > > > > I would like to request support for hosting git conversion of Fedora > CVS > > as per Lennert's post to fedora-infrastructure-list. > > > > > https://www.redhat.com/archives/fedora-infrastructure-list/2007-November/msg00136.html > > > > While there were a few responses to the mail (both support and > > skepticism) there was no clear decision. > > > > The basic idea of this effort is to enable downstream development > > efforts that make use of the fedora package repository as their > upstream > > source. > > > > The specific efforts that I am interested are: > > > > 1. Building small footprint systems (for embedded systems use). > > 2. Cross-building (a subset of) Fedora packages. > > 3. Support for architectures and platforms that are not (yet) > integrated > > into the Fedora project. > > 4. Building a GNOME Mobile distribution. > > > > etc. Others may find it useful for other purposes. > > > > The git tree does not have to be hosted in the fedora > infrastructure, > > but it seems like the natural place for it to be. It also sends the > > message that the Fedora project encourages downstream efforts that > can > > leverage Fedora into areas that are not of direct/current interest > for > > the project. > > > > So, in summary, I would appreciate if the Fedora board can consider > this > > request and provide clear guidance on whether this activity > can/should > > be supported through the fedora infrastructure. > > I'm not positive but this doesn't seem like a board decision. If the > releng, fesco and infrastructure teams are at an impasse we can take > it > up for discussion but I don't see a reason to not let those groups do > what they're supposed to do. > One of the stated goals of Fedora is to support downstream activities and distributions like I mentioned. The proposal here was for a relatively small investment on the part of the Fedora project towards support of that goal. However, I guess the decision from the infrastructure team (presumably as a follow-up to the email here) is clear -- that this is an activity that the team views as a diversion, and should be supported outside the fedora infrastructure. Thanks for your time. Regards, Manas From sundaram at fedoraproject.org Wed Nov 28 07:38:17 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 28 Nov 2007 13:08:17 +0530 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <1196187334.15420.116.camel@cutter> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> Message-ID: <474D1AE9.7030903@fedoraproject.org> seth vidal wrote: > I'm not positive but this doesn't seem like a board decision. If the > releng, fesco and infrastructure teams are at an impasse we can take it > up for discussion but I don't see a reason to not let those groups do > what they're supposed to do. Well, it has already been discussed in fedora-infrastructure list with no agreement on whether this is something we should do or not and that's the reason it is being escalated to the Fedora Project Board. IMO it is certainly something the Fedora Project Board should look into encouraging for two reasons. It seems the natural next step for being a better upstream after enabling spins to look at what we can do to enable derivatives (such as OLPC or the work Marvell is doing) which are not just straight subsets of the Fedora repository and it could potentially help us evaluate whether we want to move to distributed SCM's (which also seems to have been discussed without any decision repeatedly). Both of these should be considered by the board individually and in this context too. Rahul From skvidal at fedoraproject.org Wed Nov 28 13:32:31 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 28 Nov 2007 08:32:31 -0500 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <474D1AE9.7030903@fedoraproject.org> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> Message-ID: <1196256751.15420.185.camel@cutter> On Wed, 2007-11-28 at 13:08 +0530, Rahul Sundaram wrote: > seth vidal wrote: > > > I'm not positive but this doesn't seem like a board decision. If the > > releng, fesco and infrastructure teams are at an impasse we can take it > > up for discussion but I don't see a reason to not let those groups do > > what they're supposed to do. > > Well, it has already been discussed in fedora-infrastructure list with > no agreement on whether this is something we should do or not and that's > the reason it is being escalated to the Fedora Project Board. IMO it is > certainly something the Fedora Project Board should look into > encouraging for two reasons. > > It seems the natural next step for being a better upstream after > enabling spins to look at what we can do to enable derivatives (such as > OLPC or the work Marvell is doing) which are not just straight subsets > of the Fedora repository and it could potentially help us evaluate > whether we want to move to distributed SCM's (which also seems to have > been discussed without any decision repeatedly). Both of these should be > considered by the board individually and in this context too. When last I looked it sure sounded like fedora-infrastructure thought it was a duplication of what we already have and an odd duplication at that. Moreover, it wasn't like fedora-infrastructure couldn't come to a unanimous decision on the subject, if you read the original thread it was more like no one cared a whole huge amount and the subject just died. Yesterday mike responded with a detailed comment and I agreed with him. It's a misuse of our very limited disk space and it's not obvious why a git repo is the one item to waste the disk space on versus another scm. -sv From sundaram at fedoraproject.org Wed Nov 28 14:26:23 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 28 Nov 2007 19:56:23 +0530 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <1196256751.15420.185.camel@cutter> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> Message-ID: <474D7A8F.7030908@fedoraproject.org> seth vidal wrote: > When last I looked it sure sounded like fedora-infrastructure thought it > was a duplication of what we already have and an odd duplication at > that. Atleast some people in the team seem to be supportive of that effort. Moreover, it wasn't like fedora-infrastructure couldn't come to a > unanimous decision on the subject, if you read the original thread it > was more like no one cared a whole huge amount and the subject just > died. The question as I now see it is whether the Fedora Project Board cares about the use cases described and wants to support that. Previous discussions about moving to distributed SCM's were focused on the advantages (or lack of that) to package maintainers. Atleast some derivative distributions find it useful and moving to a distributed SCM would avoid the need to duplicate package CVS under git. Enabling spins was a board decision. Is supporting the needs of derivative distributions a equivalent priority? I think the answer to that should come from the Fedora Project Board. Rahul From jkeating at redhat.com Wed Nov 28 14:35:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Nov 2007 09:35:31 -0500 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <474D7A8F.7030908@fedoraproject.org> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> <474D7A8F.7030908@fedoraproject.org> Message-ID: <20071128093531.63cecb41@redhat.com> On Wed, 28 Nov 2007 19:56:23 +0530 Rahul Sundaram wrote: > The question as I now see it is whether the Fedora Project Board > cares about the use cases described and wants to support that. > Previous discussions about moving to distributed SCM's were focused > on the advantages (or lack of that) to package maintainers. Atleast > some derivative distributions find it useful and moving to a > distributed SCM would avoid the need to duplicate package CVS under > git. > > Enabling spins was a board decision. Is supporting the needs of > derivative distributions a equivalent priority? I think the answer > to that should come from the Fedora Project Board. The problem is that we don't want these downstreams to become dependent on a copy of the content, which may or may not be valid over time, or may or may not be continued over time. If it's an experiment, that's what RFRs (Request for Resource) are for, I've used an RFR in the past to do a short term experiment with a direct conversion of dist-cvs to hg, and to git. However they had expected end times and the resources were recycled. I don't think anybody disagrees that we should move to another SCM that allows for better downstream interaction. However just a direct copy of our workflow to git doesn't help. Nobody wants to work on the hard problem, thus nothing gets done, no matter /who/ wants it. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Wed Nov 28 15:01:40 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 28 Nov 2007 20:31:40 +0530 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <20071128093531.63cecb41@redhat.com> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> <474D7A8F.7030908@fedoraproject.org> <20071128093531.63cecb41@redhat.com> Message-ID: <474D82D4.2080502@fedoraproject.org> Jesse Keating wrote: > I don't think anybody disagrees that we should move to another SCM that > allows for better downstream interaction. However just a direct copy > of our workflow to git doesn't help. If it doesn't help people wouldn't have requested it in the first place. It might be the case that we don't want that as a final plan but this could be a incremental process. Provide a copy and mark it as experimental. See how well it used and then if the advantages are compelling to more people, some might take the initiative to move us to a distributed SCM altogether. Nobody wants to work on the hard > problem, thus nothing gets done, no matter /who/ wants it. Has the Fedora Board recognized that moving to a distributed SCM is desirable for downstream folks and asked Fedora infrastructure to work on that or indicated in any way that this is the future direction? I think this is one of the instances where the Fedora Board should take on a more active role. Rahul From rdieter at math.unl.edu Wed Nov 28 15:14:33 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 28 Nov 2007 09:14:33 -0600 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <474D82D4.2080502@fedoraproject.org> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> <474D7A8F.7030908@fedoraproject.org> <20071128093531.63cecb41@redhat.com> <474D82D4.2080502@fedoraproject.org> Message-ID: <474D85D9.1080603@math.unl.edu> Rahul Sundaram wrote: > Has the Fedora Board recognized that moving to a distributed SCM is > desirable for downstream folks and asked Fedora infrastructure to work > on that or indicated in any way that this is the future direction? A SIG was started to address this: http://fedoraproject.org/wiki/Infrastructure/SCMSig -- Rex From skvidal at fedoraproject.org Wed Nov 28 15:25:38 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 28 Nov 2007 10:25:38 -0500 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <20071128093531.63cecb41@redhat.com> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> <474D7A8F.7030908@fedoraproject.org> <20071128093531.63cecb41@redhat.com> Message-ID: <1196263538.15420.205.camel@cutter> On Wed, 2007-11-28 at 09:35 -0500, Jesse Keating wrote: > I don't think anybody disagrees that we should move to another SCM that > allows for better downstream interaction. However just a direct copy > of our workflow to git doesn't help. Nobody wants to work on the hard > problem, thus nothing gets done, no matter /who/ wants it. > The sad part is the above work is particularly hard b/c whomever works on it will have to deal with the never ending screed from users of whichever scm you didn't choose to use. I can't think of anything as demotivating as that. -sv From mmcgrath at redhat.com Wed Nov 28 15:30:57 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 28 Nov 2007 09:30:57 -0600 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <474D82D4.2080502@fedoraproject.org> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> <474D7A8F.7030908@fedoraproject.org> <20071128093531.63cecb41@redhat.com> <474D82D4.2080502@fedoraproject.org> Message-ID: <474D89B1.7020707@redhat.com> Rahul Sundaram wrote: > Jesse Keating wrote: > >> I don't think anybody disagrees that we should move to another SCM that >> allows for better downstream interaction. However just a direct copy >> of our workflow to git doesn't help. > > If it doesn't help people wouldn't have requested it in the first > place. It might be the case that we don't want that as a final plan > but this could be a incremental process. Provide a copy and mark it as > experimental. See how well it used and then if the advantages are > compelling to more people, some might take the initiative to move us > to a distributed SCM altogether. People request all sorts of things. In my mind the pain of backups, jobs, storage and dealing with hg, bzr and mercurial people wanting the same thing vastly out weighs the benefit (which I'm still unclear of) Additionally on the list it was determined if someone else wanted to host this, we can make access to the raw cvs repo easier. > Nobody wants to work on the hard >> problem, thus nothing gets done, no matter /who/ wants it. > > Has the Fedora Board recognized that moving to a distributed SCM is > desirable for downstream folks and asked Fedora infrastructure to work > on that or indicated in any way that this is the future direction? I > think this is one of the instances where the Fedora Board should take > on a more active role. To date no one has had the combination of vision, persistence and just plain craziness to put together a comprehensive plan, propose it to the list, put a proof of concept together, and then convince people it's what we need. This is no small task and since CVS is working (we are putting in source and getting RPM's somehow), it could likely be some time before it happens. -Mike From jwboyer at gmail.com Wed Nov 28 18:15:55 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 28 Nov 2007 12:15:55 -0600 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <474D82D4.2080502@fedoraproject.org> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> <474D7A8F.7030908@fedoraproject.org> <20071128093531.63cecb41@redhat.com> <474D82D4.2080502@fedoraproject.org> Message-ID: <20071128121555.79632088@zod.rchland.ibm.com> On Wed, 28 Nov 2007 20:31:40 +0530 Rahul Sundaram wrote: > >Nobody wants to work on the hard > > problem, thus nothing gets done, no matter /who/ wants it. > > Has the Fedora Board recognized that moving to a distributed SCM is > desirable for downstream folks and asked Fedora infrastructure to work > on that or indicated in any way that this is the future direction? I > think this is one of the instances where the Fedora Board should take on > a more active role. Frankly, I don't think the Board has any business in this discussion yet. There are known pain points in providing this (and switching SCMs all together), the benefits to Fedora are little to none at the moment, and it can be hosted elsewhere. Your insistence at having them declare something one way or another seems to be nothing more than whining because you aren't getting your way. josh From sundaram at fedoraproject.org Wed Nov 28 18:18:04 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 28 Nov 2007 23:48:04 +0530 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <20071128121555.79632088@zod.rchland.ibm.com> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> <474D7A8F.7030908@fedoraproject.org> <20071128093531.63cecb41@redhat.com> <474D82D4.2080502@fedoraproject.org> <20071128121555.79632088@zod.rchland.ibm.com> Message-ID: <474DB0DC.8070805@fedoraproject.org> Josh Boyer wrote: > Frankly, I don't think the Board has any business in this discussion > yet. There are known pain points in providing this (and switching SCMs > all together), the benefits to Fedora are little to none at the moment, > and it can be hosted elsewhere. As has been indicated before, the board already has a stake in the discussion having expressed the desire to see Fedora as a better upstream and having initiated the SCM SIG. So it is not really a question of whether they should have a role but whether they should have a more active role in the discussions. Apparently the problem is now lack of people to do the tasks involved which is ok as long as the desire is clearly expressed so others can volunteer if they are interested. > Your insistence at having them declare something one way or another > seems to be nothing more than whining because you aren't getting your > way. I really have no personal stake on it. So this is a gross mis characterization and only distracts us from having a conversation about real issues. Please avoid doing so. Rahul From jkeating at redhat.com Wed Nov 28 18:27:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Nov 2007 13:27:55 -0500 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <474DB0DC.8070805@fedoraproject.org> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> <474D7A8F.7030908@fedoraproject.org> <20071128093531.63cecb41@redhat.com> <474D82D4.2080502@fedoraproject.org> <20071128121555.79632088@zod.rchland.ibm.com> <474DB0DC.8070805@fedoraproject.org> Message-ID: <20071128132755.462e8f60@redhat.com> On Wed, 28 Nov 2007 23:48:04 +0530 Rahul Sundaram wrote: > I really have no personal stake on it. So this is a gross mis > characterization and only distracts us from having a conversation > about real issues. Please avoid doing so. What are you really looking for the board to say here? "We want it." Ok, then what? Work still has to get done, and there is still nobody volunteering to do it. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Wed Nov 28 18:33:24 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 28 Nov 2007 12:33:24 -0600 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <20071128132755.462e8f60@redhat.com> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> <474D7A8F.7030908@fedoraproject.org> <20071128093531.63cecb41@redhat.com> <474D82D4.2080502@fedoraproject.org> <20071128121555.79632088@zod.rchland.ibm.com> <474DB0DC.8070805@fedoraproject.org> <20071128132755.462e8f60@redhat.com> Message-ID: <474DB474.70002@redhat.com> Jesse Keating wrote: > On Wed, 28 Nov 2007 23:48:04 +0530 > Rahul Sundaram wrote: > > >> I really have no personal stake on it. So this is a gross mis >> characterization and only distracts us from having a conversation >> about real issues. Please avoid doing so. >> > > What are you really looking for the board to say here? "We want it." > Ok, then what? Work still has to get done, and there is still nobody > volunteering to do it. > In fairness, when the board does say "we want it" and no one is volunteering to do it, it falls on me. This sort of situation has come up very rarely in the past. But I'm not under the impression that the board actually does a copy of cvs in git that gets updated periodically for people to use at their leisure. I'd think the board might only get involved once a few proposals are put forth and the community can't decide which one to use. Up till now though no comprehensive proposals have been put forth "Lets use git" isn't a proposal. -Mike From sundaram at fedoraproject.org Wed Nov 28 18:35:14 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 29 Nov 2007 00:05:14 +0530 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <20071128132755.462e8f60@redhat.com> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> <474D7A8F.7030908@fedoraproject.org> <20071128093531.63cecb41@redhat.com> <474D82D4.2080502@fedoraproject.org> <20071128121555.79632088@zod.rchland.ibm.com> <474DB0DC.8070805@fedoraproject.org> <20071128132755.462e8f60@redhat.com> Message-ID: <474DB4E2.7070005@fedoraproject.org> Jesse Keating wrote: > What are you really looking for the board to say here? "We want it." > Ok, then what? Work still has to get done, and there is still nobody > volunteering to do it. "We want it" is fine since realistically when you are managing a largely volunteer group, all that you can do is express is your ideas and motivations behind it. Board did that last week or so with the request for a CD set from the next release onwards. We don't have to assume that nobody would be interested. As Thorsten said in the recent discussions in fedora-devel list about FESCo, merely expressing the desire can get others motivated to do it and it is a important thing for us to continue doing periodically. If people don't, that's ok since we would have a clear open request for help. This is one of the ways in which higher level groups can drive the direction of the project. Rahul From jwboyer at gmail.com Wed Nov 28 18:39:57 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 28 Nov 2007 12:39:57 -0600 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <474DB0DC.8070805@fedoraproject.org> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> <474D7A8F.7030908@fedoraproject.org> <20071128093531.63cecb41@redhat.com> <474D82D4.2080502@fedoraproject.org> <20071128121555.79632088@zod.rchland.ibm.com> <474DB0DC.8070805@fedoraproject.org> Message-ID: <20071128123957.182bde03@zod.rchland.ibm.com> On Wed, 28 Nov 2007 23:48:04 +0530 Rahul Sundaram wrote: > Josh Boyer wrote: > > Frankly, I don't think the Board has any business in this discussion > > yet. There are known pain points in providing this (and switching SCMs > > all together), the benefits to Fedora are little to none at the moment, > > and it can be hosted elsewhere. > > As has been indicated before, the board already has a stake in the > discussion having expressed the desire to see Fedora as a better > upstream and having initiated the SCM SIG. So it is not really a The Board didn't start the SCM SIG. > question of whether they should have a role but whether they should have > a more active role in the discussions. Apparently the problem is now > lack of people to do the tasks involved which is ok as long as the > desire is clearly expressed so others can volunteer if they are interested. Lack of people is part of the problem. Lack of physical resources is the other. Hosting this costs real money. The infrastructure team is already trying to battle some space issues at the moment. > > Your insistence at having them declare something one way or another > > seems to be nothing more than whining because you aren't getting your > > way. > > I really have no personal stake on it. So this is a gross mis > characterization and only distracts us from having a conversation about > real issues. Please avoid doing so. It's not a distraction. You're essentially going around the people that have the most knowledge about the necessities involved by trying to invoke the Board to tell them how to do their role. If you want to have a discussion, talk with infrastructure and FESCo. If you want to recruit people to actually work on this, post it to -devel or -devel-announce. At any rate, I'll avoid discussing this with you from now on. josh From poelstra at redhat.com Wed Nov 28 18:58:11 2007 From: poelstra at redhat.com (John Poelstra) Date: Wed, 28 Nov 2007 10:58:11 -0800 Subject: Fedora Board Recap 2007-NOV-27 Message-ID: <474DBA43.3010706@redhat.com> http://fedoraproject.org/wiki/Board/Meetings/2007-11-27 == Roll Call == Attendees: Bob McWhirter, Dennis Gilmore, Max Spevack, Greg Dekoenigsberg, Jack Aboutboul, Seth Vidal, John Poelstra, Steve Dickson, Bill Nottingham, Chris Aillon, and Matt Domsch, Karsten Wade, Jef Spaleta == Empty Board Seat == * Discussion surrounding open appointed board seat vacated by Chris Blizzard == Fedora Marketing == * Jack Aboutboul coming on full time with Red Hat * Discussion of what Jack's role may encompass * Brainstorm about the future == FUDCon == * We will hold FUDCon 2008-01-11 to 2008-01-13 * Jack is looking for a location in Boston, Mass * Fallback plan if Jack does not find something in Boston by Friday (2007-11-30) is to hold it in RDU From sundaram at fedoraproject.org Wed Nov 28 18:51:57 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 29 Nov 2007 00:21:57 +0530 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <20071128123957.182bde03@zod.rchland.ibm.com> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> <474D7A8F.7030908@fedoraproject.org> <20071128093531.63cecb41@redhat.com> <474D82D4.2080502@fedoraproject.org> <20071128121555.79632088@zod.rchland.ibm.com> <474DB0DC.8070805@fedoraproject.org> <20071128123957.182bde03@zod.rchland.ibm.com> Message-ID: <474DB8CD.10104@fedoraproject.org> Josh Boyer wrote: > On Wed, 28 Nov 2007 23:48:04 +0530 > Rahul Sundaram wrote: >> As has been indicated before, the board already has a stake in the >> discussion having expressed the desire to see Fedora as a better >> upstream and having initiated the SCM SIG. So it is not really a > > The Board didn't start the SCM SIG. I know that. They expressed the desire to see it happen which is exactly the kind of actions that I am asking for. >>> Your insistence at having them declare something one way or another >>> seems to be nothing more than whining because you aren't getting your >>> way. >> I really have no personal stake on it. So this is a gross mis >> characterization and only distracts us from having a conversation about >> real issues. Please avoid doing so. > > It's not a distraction. You're essentially going around the people > that have the most knowledge about the necessities involved by trying > to invoke the Board to tell them how to do their role. What am I doing is expressing a wish to see this happen and explaining why I believe it is important that the board take a active role on these matters as a former member myself. This is neither whining nor dictating anything. If anybody thinks they have all the knowledge they ever need to act on these things and aren't open to hearing others ideas, then I am afraid there is nothing more to discuss. Rahul From jspaleta at gmail.com Wed Nov 28 18:59:28 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 28 Nov 2007 09:59:28 -0900 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <20071128121555.79632088@zod.rchland.ibm.com> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> <474D7A8F.7030908@fedoraproject.org> <20071128093531.63cecb41@redhat.com> <474D82D4.2080502@fedoraproject.org> <20071128121555.79632088@zod.rchland.ibm.com> Message-ID: <604aa7910711281059o9aa15b3y4b904765ce537cba@mail.gmail.com> On Nov 28, 2007 9:15 AM, Josh Boyer wrote: > Frankly, I don't think the Board has any business in this discussion > yet. There are known pain points in providing this (and switching SCMs > all together), the benefits to Fedora are little to none at the moment, > and it can be hosted elsewhere. I don't see much here that needs rubber stamping from the board. Let me sum up where i think the discussion is at: 1) A community member has done the necessary work to implement a way to make a copy of fedora's cvs and turn it into something git friendly. This gives downstream people who are comfortable with git a way a new interact with our package sources. This is not a bad thing, and I decree that as a board member such initiative should be applauded. I'd send him a t-shirt and some stickers, but I don't have any. 2) This person feels comfortable enough with how its working to want to expose this as a public consumable for other people. The question is how to best do that. 3) There are some concerns about doing this as part of infrastructure right now. There is some resource duplication here and since git has not been selected as the next piece of technology to use its not clear that providing git as a fedora services versus some other technology is worth the resource burn. If there was a long term directive to move to git for Fedora's usage, then there would be a compelling reason to burn internal infrastructure resources to duplicate cvs into git. 4) Infrastructure is willing to help make it easier for a community hosted solution to get access to cvs for duplication. Do I have the story so far? If there isn't a cohesive plan to start transitioning to git internally over sometime scale, I'm not sure exactly what I'm suppose to be supporting. I've got other things I'd like to see infrastructure diskspace and human resources used for like spin source isos, that I feel are far more critical to provide than a duplication of cvs content as a git consumable. I mean I'm not going to actively lobby against duplicating git but I've no reason to prefer to see resources used for this over other things. Here's the reality as I see it. We simply can not do everything as part of internal infrastructure. Sometimes this project will need to rely on community provided services to extend the projects capabilities into new areas. Some of these things will eventually be pulled into the project as an internal service based on the success and growth of the service while it was being hosted externally. Other services won't be for a variety of reasons (though none of the efforts should be considered failures even if they are discarded or reach a niche audience) What the Board needs to figure out is how to make it possible to make the Fedora brand a big enough tent to encompass services that are not internally hosted, in an equitable manner. Encourage people to host community services, give credit where credit is due, and give these external community services some credibility as being an outgrowth of the project and some recognition as to the effort being made regardless as whether the service is adopted/co-opted by the Fedora project offically . -jef From jwboyer at gmail.com Wed Nov 28 19:03:30 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 28 Nov 2007 13:03:30 -0600 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <604aa7910711281059o9aa15b3y4b904765ce537cba@mail.gmail.com> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> <474D7A8F.7030908@fedoraproject.org> <20071128093531.63cecb41@redhat.com> <474D82D4.2080502@fedoraproject.org> <20071128121555.79632088@zod.rchland.ibm.com> <604aa7910711281059o9aa15b3y4b904765ce537cba@mail.gmail.com> Message-ID: <20071128130330.0d3c2ba2@zod.rchland.ibm.com> On Wed, 28 Nov 2007 09:59:28 -0900 "Jeff Spaleta" wrote: > On Nov 28, 2007 9:15 AM, Josh Boyer wrote: > > Frankly, I don't think the Board has any business in this discussion > > yet. There are known pain points in providing this (and switching SCMs > > all together), the benefits to Fedora are little to none at the moment, > > and it can be hosted elsewhere. > > I don't see much here that needs rubber stamping from the board. > Let me sum up where i think the discussion is at: > > 1) A community member has done the necessary work to implement a way to make > a copy of fedora's cvs and turn it into something git friendly. This > gives downstream people who are comfortable with git a way a new > interact with our package sources. This is not a bad thing, and I > decree that as a board member such initiative should be applauded. > I'd send him a t-shirt and some stickers, but I don't have any. > > 2) This person feels comfortable enough with how its working to want > to expose this as a public consumable for other people. The question > is how to best do that. > > 3) There are some concerns about doing this as part of infrastructure > right now. There is some resource duplication here and since git has > not been selected as the next piece of technology to use its not clear > that providing git as a fedora services versus some other technology > is worth the resource burn. If there was a long term directive to > move to git for Fedora's usage, then there would be a compelling > reason to burn internal infrastructure resources to duplicate cvs into > git. > > 4) Infrastructure is willing to help make it easier for a community > hosted solution to get access to cvs for duplication. > > Do I have the story so far? If there isn't a cohesive plan to start > transitioning to git internally over sometime scale, I'm not sure > exactly what I'm suppose to be supporting. I've got other things I'd > like to see infrastructure diskspace and human resources used for like > spin source isos, that I feel are far more critical to provide than a > duplication of cvs content as a git consumable. I mean I'm not going > to actively lobby against duplicating git but I've no reason to prefer > to see resources used for this over other things. Agreed. > Here's the reality as I see it. We simply can not do everything as > part of internal infrastructure. Sometimes this project will need to > rely on community provided services to extend the projects > capabilities into new areas. Some of these things will eventually be > pulled into the project as an internal service based on the success > and growth of the service while it was being hosted externally. Other > services won't be for a variety of reasons (though none of the > efforts should be considered failures even if they are discarded or > reach a niche audience) A big +10. > What the Board needs to figure out is how to make it possible to make > the Fedora brand a big enough tent to encompass services that are not > internally hosted, in an equitable manner. Encourage people to host > community services, give credit where credit is due, and give these > external community services some credibility as being an outgrowth of > the project and some recognition as to the effort being made > regardless as whether the service is adopted/co-opted by the Fedora > project offically . Agreed. josh From sundaram at fedoraproject.org Wed Nov 28 19:20:51 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 29 Nov 2007 00:50:51 +0530 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <604aa7910711281059o9aa15b3y4b904765ce537cba@mail.gmail.com> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> <474D7A8F.7030908@fedoraproject.org> <20071128093531.63cecb41@redhat.com> <474D82D4.2080502@fedoraproject.org> <20071128121555.79632088@zod.rchland.ibm.com> <604aa7910711281059o9aa15b3y4b904765ce537cba@mail.gmail.com> Message-ID: <474DBF93.3050801@fedoraproject.org> Jeff Spaleta wrote: > What the Board needs to figure out is how to make it possible to make > the Fedora brand a big enough tent to encompass services that are not > internally hosted, in an equitable manner. This involves figuring out which of the community setup services which the board needs to endorse as part of the Fedora brand and that involves some amount of rubber stamping IMO. Whether it is setup internally or hosted externally is really a implementation detail if we all have a better understanding of the kind of the things the Fedora Board collectively wants to see happen (ie) vision and that is the communication and direction that I am really asking for apart from whatever routine short term management of the project. Encourage people to host > community services, give credit where credit is due, and give these > external community services some credibility as being an outgrowth of > the project and some recognition as to the effort being made > regardless as whether the service is adopted/co-opted by the Fedora > project officially . Agreed. As part of these, we should look into the kind of activities that help the Fedora "ecosystem" and not just the direct benefits for the project. Linking to Creative Commons from start.fp.o as an example of what we have already done along those lines. Rahul From sundaram at fedoraproject.org Wed Nov 28 19:42:38 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 29 Nov 2007 01:12:38 +0530 Subject: Localized spins Message-ID: <474DC4AE.1040405@fedoraproject.org> Hi What am I working on currently with the L10N folks is a set of Fedora 8 spins which are localized to have about a dozen different Indian languages as the default which includes variants of either the GNOME or KDE spin or both. Some of these are based on requests from the local magazines (with a circulation rate of several thousands of copies) which want to distribute a variant of Fedora with one of the Indian languages as default. Is this something that Fedora Project can host in spins.fp.o? If we don't want to host them, am I still allowed to call them Fedora? Rahul From rdieter at math.unl.edu Wed Nov 28 20:01:13 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 28 Nov 2007 14:01:13 -0600 Subject: Localized spins In-Reply-To: <474DC4AE.1040405@fedoraproject.org> References: <474DC4AE.1040405@fedoraproject.org> Message-ID: <474DC909.7070207@math.unl.edu> Rahul Sundaram wrote: > If we > don't want to host them, am I still allowed to call them Fedora? standard rule: If these are compromprised of only packages already in Fedora, yes. -- Rex From sundaram at fedoraproject.org Wed Nov 28 19:59:46 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 29 Nov 2007 01:29:46 +0530 Subject: Localized spins In-Reply-To: <474DC909.7070207@math.unl.edu> References: <474DC4AE.1040405@fedoraproject.org> <474DC909.7070207@math.unl.edu> Message-ID: <474DC8B2.4060507@fedoraproject.org> Rex Dieter wrote: > Rahul Sundaram wrote: > >> If we don't want to host them, am I still allowed to call them Fedora? > > standard rule: If these are compromised of only packages already in > Fedora, yes. Earlier IIRC I was told that I still have to get the approval from Fedora Board if I want to use the Fedora brand for a customized spin of any sort. If that is not the case, the trademark guidelines probably need to be modified or the current policy written down somewhere officially so that everyone can rely on the information to distribute their customized Fedora spins without necessarily having to make them available via spins.fp.o first. Rahul From rdieter at math.unl.edu Wed Nov 28 20:11:50 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 28 Nov 2007 14:11:50 -0600 Subject: Localized spins In-Reply-To: <474DC8B2.4060507@fedoraproject.org> References: <474DC4AE.1040405@fedoraproject.org> <474DC909.7070207@math.unl.edu> <474DC8B2.4060507@fedoraproject.org> Message-ID: <474DCB86.2030002@math.unl.edu> Rahul Sundaram wrote: > Rex Dieter wrote: >> Rahul Sundaram wrote: >> >>> If we don't want to host them, am I still allowed to call them Fedora? >> >> standard rule: If these are compromised of only packages already in >> Fedora, yes. > > Earlier IIRC I was told that I still have to get the approval from > Fedora Board if I want to use the Fedora brand for a customized spin of > any sort. Now I remember why my brane often hurts thinking on topics such as licensing, patents, trademarks... I had been successfully repressing those thoughts, but now... ouch. Sorry for any misinformation. -- Rex From jspaleta at gmail.com Wed Nov 28 20:25:59 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 28 Nov 2007 11:25:59 -0900 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <474DBF93.3050801@fedoraproject.org> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> <474D7A8F.7030908@fedoraproject.org> <20071128093531.63cecb41@redhat.com> <474D82D4.2080502@fedoraproject.org> <20071128121555.79632088@zod.rchland.ibm.com> <604aa7910711281059o9aa15b3y4b904765ce537cba@mail.gmail.com> <474DBF93.3050801@fedoraproject.org> Message-ID: <604aa7910711281225l73f567e4je43a6f1fe489fc4f@mail.gmail.com> On Nov 28, 2007 10:20 AM, Rahul Sundaram wrote: > This involves figuring out which of the community setup services which > the board needs to endorse as part of the Fedora brand and that involves > some amount of rubber stamping IMO. Whether it is setup internally or > hosted externally is really a implementation detail if we all have a > better understanding of the kind of the things the Fedora Board > collectively wants to see happen (ie) vision and that is the > communication and direction that I am really asking for apart from > whatever routine short term management of the project. While vision is important, pointing in an arbitrary direction without taking into account what the momentum isn't a particularly good way to lead. Momentum must be accounted for in such things, and quite honestly I don't see much in the way of obvious momentum behind a particular SCM. Everyone wants a pony, no one can decide on what color the pony needs to be. I'd prefer to see an informed proposal from the SCM SIG, before pointing off in an arbitrary direction without the support of the people willing and capable of doing the work to make it happen. The Board is more effective if it spends more time serving and supporting initiatives instead of dictating them. Are you expecting the Board to be able to anticipate all the ways the community members can be clever? Are you looking for unfunded and unmanned directives for projects that the Board would like to see implemented? In this specific case, I certainly never would have thought of duplicating cvs as git. Shame on me. I really dont know what sort of high level vision statement your asking for here. Does the board want Fedora to use a distributed SCM at some point? Is that the sort of vision statement you want to hear.I personally don't give a rats ass what pieces of technology Fedora as a project actually makes a commitment to using as long as it makes it easier for us to be a conduit for upstream development. Any technology choice which makes it easier for downstream to consume us, but doesn't make it easier for downstream to contribute back to us and then us back into upstream projects is NOT something I want to see and runs counter to the upstreaming mantra. Certainly duplicating our cvs as a git collection is not going to help make it easier to contribute back to us and then on into upstream. The distributed SCM issue is absolutely mired in implementation details. Considering the landscape I'm not even sure we end up with a net win in terms of easing the contribution burden by selecting a single candidate technology. I'm willing to wait for the SCM SIG to present a roadmap. > Agreed. As part of these, we should look into the kind of activities > that help the Fedora "ecosystem" and not just the direct benefits for > the project. Linking to Creative Commons from start.fp.o as an example > of what we have already done along those lines. If we had to host all of Creative Commons internally, we wouldn't be able to do it. Supporting an externally hosted git duplication of our cvs is still on the table in the original thread on the infrastructure list. Are we talking about linking to an externally hosted git duplication of our cvs? -jef From skvidal at fedoraproject.org Wed Nov 28 20:23:50 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 28 Nov 2007 15:23:50 -0500 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <604aa7910711281225l73f567e4je43a6f1fe489fc4f@mail.gmail.com> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> <474D7A8F.7030908@fedoraproject.org> <20071128093531.63cecb41@redhat.com> <474D82D4.2080502@fedoraproject.org> <20071128121555.79632088@zod.rchland.ibm.com> <604aa7910711281059o9aa15b3y4b904765ce537cba@mail.gmail.com> <474DBF93.3050801@fedoraproject.org> <604aa7910711281225l73f567e4je43a6f1fe489fc4f@mail.gmail.com> Message-ID: <1196281430.15420.222.camel@cutter> On Wed, 2007-11-28 at 11:25 -0900, Jeff Spaleta wrote: > I really dont know what sort of high level vision statement your > asking for here. > Does the board want Fedora to use a distributed SCM at some point? Is > that the sort of vision statement you want to hear.I personally don't > give a rats ass what pieces of technology Fedora as a project actually > makes a commitment to using as long as it makes it easier for us to be > a conduit for upstream development. Any technology choice which makes > it easier for downstream to consume us, but doesn't make it easier for > downstream to contribute back to us and then us back into upstream > projects is NOT something I want to see and runs counter to the > upstreaming mantra. Certainly duplicating our cvs as a git collection > is not going to help make it easier to contribute back to us and then > on into upstream. > > The distributed SCM issue is absolutely mired in implementation > details. Considering the landscape I'm not even sure we end up with a > net win in terms of easing the contribution burden by selecting a > single candidate technology. I'm willing to wait for the SCM SIG to > present a roadmap. holy crap I like this answer. +10 -sv From jspaleta at gmail.com Wed Nov 28 20:33:18 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 28 Nov 2007 11:33:18 -0900 Subject: Localized spins In-Reply-To: <474DC4AE.1040405@fedoraproject.org> References: <474DC4AE.1040405@fedoraproject.org> Message-ID: <604aa7910711281233g528989a7pe0859ceb453fdf98@mail.gmail.com> On Nov 28, 2007 10:42 AM, Rahul Sundaram wrote: > Is this something that Fedora Project can host in spins.fp.o? If we > don't want to host them, am I still allowed to call them Fedora? Assuming the images are built such that we have the option to host them, then you should be able to call them Fedora. Board approval may still be involved. I don't think the commitment to hosting them on spins.fp.o is a blocker to calling it Fedora, but we may need you to make a public hosting commitment in place of being hosted internally. Do you have a working image right now? -jef From sundaram at fedoraproject.org Wed Nov 28 20:29:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 29 Nov 2007 01:59:55 +0530 Subject: Hosting and Supporting GIT conversion of Fedora CVS to enable downstream development efforts and distributions In-Reply-To: <604aa7910711281225l73f567e4je43a6f1fe489fc4f@mail.gmail.com> References: <1196184101.19184.50.camel@localhost.localdomain> <1196187334.15420.116.camel@cutter> <474D1AE9.7030903@fedoraproject.org> <1196256751.15420.185.camel@cutter> <474D7A8F.7030908@fedoraproject.org> <20071128093531.63cecb41@redhat.com> <474D82D4.2080502@fedoraproject.org> <20071128121555.79632088@zod.rchland.ibm.com> <604aa7910711281059o9aa15b3y4b904765ce537cba@mail.gmail.com> <474DBF93.3050801@fedoraproject.org> <604aa7910711281225l73f567e4je43a6f1fe489fc4f@mail.gmail.com> Message-ID: <474DCFC3.4080304@fedoraproject.org> Jeff Spaleta wrote: > > Are you expecting the Board to be able to anticipate all the ways the > community members can be clever? Are you looking for unfunded and > unmanned directives for projects that the Board would like to see > implemented? In this specific case, I certainly never would have > thought of duplicating cvs as git. Shame on me. Not to such low level details but the kind of audiences we are trying to serve. If a distributed SCM's help serve one set of audiences better, that kind of activities needs to be encouraged. You don't have to look at the specifics too much here. This is just an example. > If we had to host all of Creative Commons internally, we wouldn't be > able to do it. Supporting an externally hosted git duplication of our > cvs is still on the table in the original thread on the infrastructure > list. Are we talking about linking to an externally hosted git > duplication of our cvs? Correct. Linking is one way to endorse the effort. If we have the systems but not the people to do the effort, letting people who might be interested to use our systems to do their thing is another. Rahul From sundaram at fedoraproject.org Wed Nov 28 20:32:07 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 29 Nov 2007 02:02:07 +0530 Subject: Localized spins In-Reply-To: <604aa7910711281233g528989a7pe0859ceb453fdf98@mail.gmail.com> References: <474DC4AE.1040405@fedoraproject.org> <604aa7910711281233g528989a7pe0859ceb453fdf98@mail.gmail.com> Message-ID: <474DD047.2050408@fedoraproject.org> Jeff Spaleta wrote: > On Nov 28, 2007 10:42 AM, Rahul Sundaram wrote: >> Is this something that Fedora Project can host in spins.fp.o? If we >> don't want to host them, am I still allowed to call them Fedora? > > Assuming the images are built such that we have the option to host > them, then you should be able to call them Fedora. Board approval may > still be involved. I don't think the commitment to hosting them on > spins.fp.o is a blocker to calling it Fedora, but we may need you to > make a public hosting commitment in place of being hosted internally. I don't have any resources to host the images publicly elsewhere. > Do you have a working image right now? Not yet. Looks like I am running into bugs with livecd-creator. Still debugging issues. Rahul From sundaram at fedoraproject.org Wed Nov 28 20:59:17 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 29 Nov 2007 02:29:17 +0530 Subject: Localized spins In-Reply-To: <474DD047.2050408@fedoraproject.org> References: <474DC4AE.1040405@fedoraproject.org> <604aa7910711281233g528989a7pe0859ceb453fdf98@mail.gmail.com> <474DD047.2050408@fedoraproject.org> Message-ID: <474DD6A5.4010805@fedoraproject.org> Rahul Sundaram wrote: > Jeff Spaleta wrote: > >> Do you have a working image right now? > > Not yet. Looks like I am running into bugs with livecd-creator. Still > debugging issues. Ok. Fixed. I have a working image now. Rahul From jspaleta at gmail.com Thu Nov 29 00:54:29 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 28 Nov 2007 15:54:29 -0900 Subject: Localized spins In-Reply-To: <474DD047.2050408@fedoraproject.org> References: <474DC4AE.1040405@fedoraproject.org> <604aa7910711281233g528989a7pe0859ceb453fdf98@mail.gmail.com> <474DD047.2050408@fedoraproject.org> Message-ID: <604aa7910711281654m2cb9b1few8aae106a6eec0568@mail.gmail.com> On Nov 28, 2007 11:32 AM, Rahul Sundaram wrote: > I don't have any resources to host the images publicly elsewhere. Do you have a place where you can put the live image temporarily for it to be looked at? I'll see if we can make sure we discuss the localized spin at the next board meeting, but we'll need someone to make your freshly minted preview image available somewhere for people to poke at. -jef From jkeating at redhat.com Thu Nov 29 01:04:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Nov 2007 20:04:00 -0500 Subject: Localized spins In-Reply-To: <604aa7910711281654m2cb9b1few8aae106a6eec0568@mail.gmail.com> References: <474DC4AE.1040405@fedoraproject.org> <604aa7910711281233g528989a7pe0859ceb453fdf98@mail.gmail.com> <474DD047.2050408@fedoraproject.org> <604aa7910711281654m2cb9b1few8aae106a6eec0568@mail.gmail.com> Message-ID: <20071128200400.6e46b792@redhat.com> On Wed, 28 Nov 2007 15:54:29 -0900 "Jeff Spaleta" wrote: > Do you have a place where you can put the live image temporarily for > it to be looked at? > I'll see if we can make sure we discuss the localized spin at the next > board meeting, but we'll need someone to make your freshly minted > preview image available somewhere for people to poke at. Failing that, a functional .ks file would suffice. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Thu Nov 29 02:36:14 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 28 Nov 2007 20:36:14 -0600 Subject: Localized spins In-Reply-To: <20071128200400.6e46b792@redhat.com> References: <474DC4AE.1040405@fedoraproject.org> <604aa7910711281233g528989a7pe0859ceb453fdf98@mail.gmail.com> <474DD047.2050408@fedoraproject.org> <604aa7910711281654m2cb9b1few8aae106a6eec0568@mail.gmail.com> <20071128200400.6e46b792@redhat.com> Message-ID: <474E259E.1020407@redhat.com> Jesse Keating wrote: > On Wed, 28 Nov 2007 15:54:29 -0900 > "Jeff Spaleta" wrote: > > >> Do you have a place where you can put the live image temporarily for >> it to be looked at? >> I'll see if we can make sure we discuss the localized spin at the next >> board meeting, but we'll need someone to make your freshly minted >> preview image available somewhere for people to poke at. >> > > Failing that, a functional .ks file would suffice. > > I'm actually wondering that myself, we do have a procedure for these sorts of things. - http://fedoraproject.org/wiki/Infrastructure/CustomSpins -Mike From sundaram at fedoraproject.org Thu Nov 29 19:31:56 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 30 Nov 2007 01:01:56 +0530 Subject: Localized spins In-Reply-To: <20071128200400.6e46b792@redhat.com> References: <474DC4AE.1040405@fedoraproject.org> <604aa7910711281233g528989a7pe0859ceb453fdf98@mail.gmail.com> <474DD047.2050408@fedoraproject.org> <604aa7910711281654m2cb9b1few8aae106a6eec0568@mail.gmail.com> <20071128200400.6e46b792@redhat.com> Message-ID: <474F13AC.4050403@fedoraproject.org> Jesse Keating wrote: > On Wed, 28 Nov 2007 15:54:29 -0900 > "Jeff Spaleta" wrote: > >> Do you have a place where you can put the live image temporarily for >> it to be looked at? >> I'll see if we can make sure we discuss the localized spin at the next >> board meeting, but we'll need someone to make your freshly minted >> preview image available somewhere for people to poke at. > > Failing that, a functional .ks file would suffice. I have a couple of tested .ks files at http://sundaram.fedorapeople.org/ These are derived from the desktop ks file for Fedora 8 with the locale, keyboard and timezone settings customized along with a few package changes. Take a look at it and let me know if these are ok. I have a few other languages where a customized spin is desired and I am working on the L10N team here. Might take sometime. Thanks. Rahul