From bugs.michael at gmx.net Wed Nov 1 01:54:21 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 1 Nov 2006 02:54:21 +0100 Subject: [fab] Fw: libgeotiff Message-ID: <20061101025421.d173e3ce.bugs.michael@gmx.net> Begin forwarded message: Date: Mon, 30 Oct 2006 10:07:27 -0500 Subject: [Bug 178162] Review Request: libgeotiff Summary: Review Request: libgeotiff https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178162 ------- Additional Comments From mccann0011 at hotmail.com 2006-10-30 10:07 EST ------- I have no plans to do further work on this. The EPSG data is required for libgeotiff to function and we either need to include the files in the distribution or use the embedded data in the source. As noted, this has been raised upstream and as yet there has been no response. I take it that Fedora has no plans for different types of repositories - including one that would support a package such as libgeotiff? This will be unfortunate as most of the open source GIS packages depend on libgeotiff and gdal and therefore these packages will be unavailable to Fedora users. From wtogami at redhat.com Thu Nov 2 14:28:04 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 02 Nov 2006 09:28:04 -0500 Subject: [fab] Most Advanced 100% Free Distribution? Message-ID: <454A0074.8070003@redhat.com> http://lwn.net/Articles/207228/ With the avowed goal of providing a completely free distribution - one without non-free kernel binary 'blobs' or any other non-free software, the Free Software Foundation has announced sponsorship of the project. Ted Teah, FSF's free software directory maintainer explained, 'With all the kernel firmware and restricted repositories removed, and the reliance on Ubuntu's proprietary distribution management tool Launchpad gone, this distribution is the most advanced GNU/Linux distribution that has a commitment to be 100% free. Perhaps they haven't heard of Fedora? Warren Togami wtogami at redhat.com From sundaram at fedoraproject.org Thu Nov 2 14:45:33 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Nov 2006 20:15:33 +0530 Subject: [fab] Most Advanced 100% Free Distribution? In-Reply-To: <454A0074.8070003@redhat.com> References: <454A0074.8070003@redhat.com> Message-ID: <454A048D.5000608@fedoraproject.org> Warren Togami wrote: > http://lwn.net/Articles/207228/ > With the avowed goal of providing a completely free distribution - one > without non-free kernel binary 'blobs' or any other non-free software, > the Free Software Foundation has announced sponsorship of the project. > Ted Teah, FSF's free software directory maintainer explained, 'With all > the kernel firmware and restricted repositories removed, and the > reliance on Ubuntu's proprietary distribution management tool Launchpad > gone, this distribution is the most advanced GNU/Linux distribution that > has a commitment to be 100% free. > > Perhaps they haven't heard of Fedora? Perhaps they have. Our guidelines allows OSI approved licenses among which the reciprocal license is considered non-free by FSF. This is a completely theoretical issue at this point though since Fedora does not include software under this license and we have been discussing about changing the guidelines to avoid this problem even. I am not sure what the kernel binary blobs in this PR refers to. AFAIK, the upstream kernel itself includes firmware which we dont remove in Fedora. Our guidelides dont require source for all firmware and just redistribution rights. I am still waiting on understanding better FSF's standing on various other stuff like firmware, patented software etc. So we are close but not quite there yet and there might be potential roadblocks from this ever happening. Rahul From wtogami at redhat.com Thu Nov 2 14:54:51 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 02 Nov 2006 09:54:51 -0500 Subject: [fab] Most Advanced 100% Free Distribution? In-Reply-To: <454A048D.5000608@fedoraproject.org> References: <454A0074.8070003@redhat.com> <454A048D.5000608@fedoraproject.org> Message-ID: <454A06BB.10203@redhat.com> Rahul Sundaram wrote: > I am not sure what the kernel binary blobs in this PR refers to. AFAIK, > the upstream kernel itself includes firmware which we dont remove in > Fedora. Our guidelides dont require source for all firmware and just > redistribution rights. > Maybe we don't want to go this far. The benefits of redistributable firmware perhaps greatly outweigh the ideological benefits. Firmware is nowhere near the level of evil as binary-only drivers hooking into the kernel. Warren Togami wtogami at redhat.com From jkeating at redhat.com Thu Nov 2 16:03:05 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 2 Nov 2006 11:03:05 -0500 Subject: [fab] FSF Requirements for srpm provisions Message-ID: <200611021103.06057.jkeating@redhat.com> This has come up on fedora-devel-list. If somebody happens to spin a compose of Fedora rpms for say ia64, no modifications, no alterations, same exact binaries that were created at the same time the i386/x86_64/ppc ones were, do they have an obligation to host all the srpms again where they provide the spun release, or can they refer back to the mirror system of srpms? For that matter, when we allow people to make spins of Fedora comprised of their specific package set, do they have to provide the srpms of the packages they used? Is it not enough to point to the unified source directories on the mirror system? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Thu Nov 2 16:08:50 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 02 Nov 2006 10:08:50 -0600 Subject: [fab] FSF Requirements for srpm provisions In-Reply-To: <200611021103.06057.jkeating@redhat.com> References: <200611021103.06057.jkeating@redhat.com> Message-ID: <454A1812.70905@math.unl.edu> Jesse Keating wrote: > This has come up on fedora-devel-list. If somebody happens to spin a compose > of Fedora rpms for say ia64, no modifications, no alterations, same exact > binaries that were created at the same time the i386/x86_64/ppc ones were, do > they have an obligation to host all the srpms again where they provide the > spun release, or can they refer back to the mirror system of srpms? GPL FAQ says that (for GPL software anyway) the source should be at the *same* location as hosted binaries. I'd say Fedora ought to recommend the same. Not sure if we should go as far as make it mandatory. -- Rex From nman64 at n-man.com Thu Nov 2 16:15:04 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Thu, 2 Nov 2006 10:15:04 -0600 Subject: [fab] FSF Requirements for srpm provisions In-Reply-To: <200611021103.06057.jkeating@redhat.com> References: <200611021103.06057.jkeating@redhat.com> Message-ID: <200611021015.08609.nman64@n-man.com> On Thursday 02 November 2006 10:03, Jesse Keating wrote: > This has come up on fedora-devel-list. If somebody happens to spin a > compose of Fedora rpms for say ia64, no modifications, no alterations, same > exact binaries that were created at the same time the i386/x86_64/ppc ones > were, do they have an obligation to host all the srpms again where they > provide the spun release, or can they refer back to the mirror system of > srpms? > > For that matter, when we allow people to make spins of Fedora comprised of > their specific package set, do they have to provide the srpms of the > packages they used? Is it not enough to point to the unified source > directories on the mirror system? IANAL, but my understanding is that they can point back to our sources if those are the sources they used to build the software. Any modifications or added software would, of course, need to have the sources provided separately. Our offers and commitments are sufficient to satisfy licensing requirements in such cases. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://n-man.com/ LinkedIn: http://linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Thu Nov 2 16:32:37 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 2 Nov 2006 11:32:37 -0500 Subject: [fab] FSF Requirements for srpm provisions In-Reply-To: <200611021103.06057.jkeating@redhat.com> References: <200611021103.06057.jkeating@redhat.com> Message-ID: <20061102163237.GE13496@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > This has come up on fedora-devel-list. If somebody happens to spin a compose > of Fedora rpms for say ia64, no modifications, no alterations, same exact > binaries that were created at the same time the i386/x86_64/ppc ones were, do > they have an obligation to host all the srpms again where they provide the > spun release, or can they refer back to the mirror system of srpms? I'd prefer they have their own SRPMS, especially if they had to pull anything from -devel (which will get obsoleted from the download site soon.) Now, if they just want one big source ISO, that's fine. Similarly, something like Unity will probably want a source mirror b/c of obsoleted updates. Bill From ville.skytta at iki.fi Thu Nov 2 17:12:41 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 02 Nov 2006 19:12:41 +0200 Subject: [fab] FSF Requirements for srpm provisions In-Reply-To: <200611021015.08609.nman64@n-man.com> References: <200611021103.06057.jkeating@redhat.com> <200611021015.08609.nman64@n-man.com> Message-ID: <1162487561.19437.14.camel@viper.local> On Thu, 2006-11-02 at 10:15 -0600, Patrick W. Barnes wrote: > On Thursday 02 November 2006 10:03, Jesse Keating wrote: > > > > For that matter, when we allow people to make spins of Fedora comprised of > > their specific package set, do they have to provide the srpms of the > > packages they used? Is it not enough to point to the unified source > > directories on the mirror system? > > IANAL, but my understanding is that they can point back to our sources if > those are the sources they used to build the software. Any modifications or > added software would, of course, need to have the sources provided > separately. Our offers and commitments are sufficient to satisfy licensing > requirements in such cases. See http://software.newsforge.com/software/06/06/23/1728205.shtml for some apparently different opinions from a FSF GPL compliance engineer. From bob at bobjensen.com Thu Nov 2 18:10:31 2006 From: bob at bobjensen.com (Robert 'Bob' Jensen) Date: Thu, 02 Nov 2006 12:10:31 -0600 Subject: [fab] FSF Requirements for srpm provisions In-Reply-To: <20061102163237.GE13496@nostromo.devel.redhat.com> References: <200611021103.06057.jkeating@redhat.com> <20061102163237.GE13496@nostromo.devel.redhat.com> Message-ID: <454A3497.9040407@bobjensen.com> Bill Nottingham wrote: > > I'd prefer they have their own SRPMS, especially if they had to pull > anything from -devel (which will get obsoleted from the download > site soon.) > > Now, if they just want one big source ISO, that's fine. > > Similarly, something like Unity will probably want a source mirror b/c > of obsoleted updates. > > Bill > We will do as suggested. Disk space does become an issue for smaller projects like Unity though. Can we simply archive the SRPMS for "updates only", as those are the only ones that change or become obsolete in the fedora tree, then just point the "GOLD" items to the core SRPMs tree? Or should we build the SRPM tree of what we have on the re-spins? The question comes up that, seeing as we do not rebuild any of the binaries, we only group them into a final package set, do we still need the source at all? -- Robert 'Bob' Jensen * * http://fedoraproject.org/wiki/BobJensen gpg fingerprint: F9F4 7243 4243 0043 2C45 97AF E8A4 C3AE 42EB 0BC6 Fedora Unity Project * bob at fedoraunity.org * http://fedoraunity.org/ From tiemann at redhat.com Thu Nov 2 19:42:20 2006 From: tiemann at redhat.com (Michael Tiemann) Date: Thu, 02 Nov 2006 14:42:20 -0500 Subject: [fab] where does Fedora development take place? Message-ID: <1162496540.3858.42.camel@localhost.localdomain> I have a question I'm hoping you can help me answer. The question is: how many core and how many extras development trees are hosted on sourceforge, gforge, collab.net, and any and all other hosted development infrastructures? I'm trying to understand which, if any of these types of sites, has achieved some reasonable market share. Thanks for any pointers you may be able to provide. M From jkeating at redhat.com Thu Nov 2 19:51:50 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 2 Nov 2006 14:51:50 -0500 Subject: [fab] where does Fedora development take place? In-Reply-To: <1162496540.3858.42.camel@localhost.localdomain> References: <1162496540.3858.42.camel@localhost.localdomain> Message-ID: <200611021451.50834.jkeating@redhat.com> On Thursday 02 November 2006 14:42, Michael Tiemann wrote: > I have a question I'm hoping you can help me answer. ?The question is: > how many core and how many extras development trees are hosted on > sourceforge, gforge, collab.net, and any and all other hosted > development infrastructures? ?I'm trying to understand which, if any of > these types of sites, has achieved some reasonable market share. ?Thanks > for any pointers you may be able to provide. Are you speaking of the upstream package source? How many core/extras packages upstream project space is on SF/GF/collab.net/etc? I just want to understand the question correctly. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Nov 2 20:44:20 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 2 Nov 2006 15:44:20 -0500 Subject: [fab] FSF Requirements for srpm provisions In-Reply-To: <20061102163237.GE13496@nostromo.devel.redhat.com> References: <200611021103.06057.jkeating@redhat.com> <20061102163237.GE13496@nostromo.devel.redhat.com> Message-ID: <200611021544.20984.jkeating@redhat.com> On Thursday 02 November 2006 11:32, Bill Nottingham wrote: > I'd prefer they have their own SRPMS, especially if they had to pull > anything from -devel (which will get obsoleted from the download > site soon.) > > Now, if they just want one big source ISO, that's fine. What about the Fedora project case going forward? A spin of Fedora being of both Core and Extras packages, user chosen (or in some cases project chosen) package set. Does EACH spin have to ship the SRPMS used, or can all refer back to the SRPM pool at fedoraproject.org and its mirrors? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Thu Nov 2 21:09:29 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 2 Nov 2006 15:09:29 -0600 Subject: [fab] FSF Requirements for srpm provisions In-Reply-To: <200611021544.20984.jkeating@redhat.com> References: <200611021103.06057.jkeating@redhat.com> <20061102163237.GE13496@nostromo.devel.redhat.com> <200611021544.20984.jkeating@redhat.com> Message-ID: <200611021509.30377.dennis@ausil.us> On Thursday 02 November 2006 14:44, Jesse Keating wrote: > On Thursday 02 November 2006 11:32, Bill Nottingham wrote: > > I'd prefer they have their own SRPMS, especially if they had to pull > > anything from -devel (which will get obsoleted from the download > > site soon.) > > > > Now, if they just want one big source ISO, that's fine. > > What about the Fedora project case going forward? A spin of Fedora being > of both Core and Extras packages, user chosen (or in some cases project > chosen) package set. Does EACH spin have to ship the SRPMS used, or can > all refer back to the SRPM pool at fedoraproject.org and its mirrors? for Aurora Extras i republished the SRPMS even though 99% of them are the same as whats in Fedora Extras. I really didn't think about not doing it. I know from the core side in Aurora there are slightly more changes but not alot. again all SRPMS are published there also. -- Dennis Gilmore, RHCE Proud Australian From jwboyer at jdub.homelinux.org Thu Nov 2 21:34:54 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 02 Nov 2006 15:34:54 -0600 Subject: [fab] FSF Requirements for srpm provisions In-Reply-To: <200611021544.20984.jkeating@redhat.com> References: <200611021103.06057.jkeating@redhat.com> <20061102163237.GE13496@nostromo.devel.redhat.com> <200611021544.20984.jkeating@redhat.com> Message-ID: <1162503295.11351.21.camel@zod.rchland.ibm.com> On Thu, 2006-11-02 at 15:44 -0500, Jesse Keating wrote: > On Thursday 02 November 2006 11:32, Bill Nottingham wrote: > > I'd prefer they have their own SRPMS, especially if they had to pull > > anything from -devel (which will get obsoleted from the download > > site soon.) > > > > Now, if they just want one big source ISO, that's fine. > > What about the Fedora project case going forward? A spin of Fedora being of > both Core and Extras packages, user chosen (or in some cases project chosen) > package set. Does EACH spin have to ship the SRPMS used, or can all refer > back to the SRPM pool at fedoraproject.org and its mirrors? If you hose those off of fedoraproject.org (thereby making them official Fedora projects) then the problem would be solved. josh From a.badger at gmail.com Thu Nov 2 21:50:48 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 02 Nov 2006 13:50:48 -0800 Subject: [fab] FSF Requirements for srpm provisions In-Reply-To: <1162503295.11351.21.camel@zod.rchland.ibm.com> References: <200611021103.06057.jkeating@redhat.com> <20061102163237.GE13496@nostromo.devel.redhat.com> <200611021544.20984.jkeating@redhat.com> <1162503295.11351.21.camel@zod.rchland.ibm.com> Message-ID: <1162504248.2964.10.camel@localhost> On Thu, 2006-11-02 at 15:34 -0600, Josh Boyer wrote: > On Thu, 2006-11-02 at 15:44 -0500, Jesse Keating wrote: > > On Thursday 02 November 2006 11:32, Bill Nottingham wrote: > > > I'd prefer they have their own SRPMS, especially if they had to pull > > > anything from -devel (which will get obsoleted from the download > > > site soon.) > > > > > > Now, if they just want one big source ISO, that's fine. > > > > What about the Fedora project case going forward? A spin of Fedora being of > > both Core and Extras packages, user chosen (or in some cases project chosen) > > package set. Does EACH spin have to ship the SRPMS used, or can all refer > > back to the SRPM pool at fedoraproject.org and its mirrors? > > If you hose those off of fedoraproject.org (thereby making them official > Fedora projects) then the problem would be solved. As long as the SRPMs remain available. If the respin involves packages where we don't keep the RPMS/SRPMS for the life of the ISO respin then we'd be in trouble. I know this would cause trouble for things from FC-devel. I think it would be a problem for FC-updates and FE as well. Also, if one aim is for third parties to be able to redistribute the isos on CD, they might like to have the SRPMS packaged onto isos as well (just in case someone asks them for it). -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From matt at domsch.com Thu Nov 2 22:17:50 2006 From: matt at domsch.com (Matt Domsch) Date: Thu, 2 Nov 2006 16:17:50 -0600 Subject: [fab] where does Fedora development take place? In-Reply-To: <1162496540.3858.42.camel@localhost.localdomain> References: <1162496540.3858.42.camel@localhost.localdomain> Message-ID: <20061102221750.GA14080@domsch.com> On Thu, Nov 02, 2006 at 02:42:20PM -0500, Michael Tiemann wrote: > I have a question I'm hoping you can help me answer. The question is: > how many core and how many extras development trees are hosted on > sourceforge, gforge, collab.net, and any and all other hosted > development infrastructures? I'm trying to understand which, if any of > these types of sites, has achieved some reasonable market share. Thanks > for any pointers you may be able to provide. Of the packages URL lines that exist, here's what those claim. I only list those that have 5 or more SRPMS with the same URL (or same dereferenced DNS alias). 5 0pointer.de 5 cairographics.org 5 ctan.org 5 gtk.org 5 kernel.org 5 mysql.com 5 oss.sgi.com 5 pear.php.net 5 riverbankcomputing.co.uk 5 unicorn.berlios.de 5 xiph.org 6 extragear.kde.org 6 galago-project.org 6 gstreamer.freedesktop.org 6 libsdl.org 6 opendap.org 7 gnupg.org 7 go-mono.com 7 linux.duke.edu 7 turbogears.org 8 annarchy.freedesktop.org 8 fedoraproject.org 8 mozilla.org 8 scim-im.org 9 opensync.org 9 window.gnome.org 10 worldforge.org 11 projects.sourceforge.jp 13 people.redhat.com 15 freedesktop.org 15 moria.seul.org 16 redhat.com 18 kde.org 18 sources.redhat.com 19 fedora.redhat.com 19 goodies.xfce.org 21 xfce.org 22 ftp.acc.umu.se 24 jakarta.apache.org 24 nongnu.org 30 aspell.net 35 pair12.php.net 57 sourceforge.net 60 gnome.org 64 gnu.org 121 x.org 230 (none) 487 projects.sourceforge.net 517 cpansearch.perl.org From tiemann at redhat.com Thu Nov 2 22:21:32 2006 From: tiemann at redhat.com (Michael Tiemann) Date: Thu, 02 Nov 2006 17:21:32 -0500 Subject: [fab] where does Fedora development take place? In-Reply-To: <20061102221750.GA14080@domsch.com> References: <1162496540.3858.42.camel@localhost.localdomain> <20061102221750.GA14080@domsch.com> Message-ID: <1162506092.3858.50.camel@localhost.localdomain> Thanks! M From nman64 at n-man.com Fri Nov 3 05:23:53 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Thu, 2 Nov 2006 23:23:53 -0600 Subject: [fab] FSF Requirements for srpm provisions In-Reply-To: <1162504248.2964.10.camel@localhost> References: <200611021103.06057.jkeating@redhat.com> <1162503295.11351.21.camel@zod.rchland.ibm.com> <1162504248.2964.10.camel@localhost> Message-ID: <200611022323.56266.nman64@n-man.com> On Thursday 02 November 2006 15:50, Toshio Kuratomi wrote: > > As long as the SRPMs remain available. If the respin involves packages > where we don't keep the RPMS/SRPMS for the life of the ISO respin then > we'd be in trouble. > > I know this would cause trouble for things from FC-devel. I think it > would be a problem for FC-updates and FE as well. > Don't forget CVS. It's just as valid as a source provider as the SRPMS. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://n-man.com/ LinkedIn: http://linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Fri Nov 3 08:42:27 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 3 Nov 2006 09:42:27 +0100 Subject: [fab] FSF Requirements for srpm provisions In-Reply-To: <200611022323.56266.nman64@n-man.com> References: <200611021103.06057.jkeating@redhat.com> <1162503295.11351.21.camel@zod.rchland.ibm.com> <1162504248.2964.10.camel@localhost> <200611022323.56266.nman64@n-man.com> Message-ID: <20061103094227.dbd06442.bugs.michael@gmx.net> On Thu, 2 Nov 2006 23:23:53 -0600, Patrick W. Barnes wrote: > On Thursday 02 November 2006 15:50, Toshio Kuratomi wrote: > > > > As long as the SRPMs remain available. If the respin involves packages > > where we don't keep the RPMS/SRPMS for the life of the ISO respin then > > we'd be in trouble. > > > > I know this would cause trouble for things from FC-devel. I think it > > would be a problem for FC-updates and FE as well. > > > > Don't forget CVS. It's just as valid as a source provider as the SRPMS. What is the life-time of the binary files in the Fedora Extras lookaside cache? From andreas.bierfert at lowlatency.de Fri Nov 3 10:31:18 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Fri, 3 Nov 2006 11:31:18 +0100 Subject: [fab] future of rpm [in fedora] Message-ID: <20061103113118.733d5901@alkaid.a.lan> Hi, for a long time I have been thinking how it would be great to get so called 'soft dependencies' into rpm and actually make use of them for fedora extras. From what I heard at the time even apt was already able to make use of them (and thought for myself that adding it to yum would follow in time). When I asked why we did not upgrade devel to rpm >= 4.4.3 I was told that it was to late in the devel cycle to do that. So I stopped bothering about it for a while. Lately I started my promised work on better repo to web interface and started to look at the rpmlib api. That was the time I began remembering why there was no new version of rpm in fc6 and thought that now would be a good time to get a the newer version into devel so all issues with it can be worked out in time for the release. So I began by looking at bugzilla and found #174307 which really got me angry. Since then I have been thinking. Reading (rpms changelogs, f-a-b, lwn.net and so on) and gathering information about the topic. So here are my toughts about this evenso nobody will care I strongly feel that now is the time for me to make a stand: First on thing that is bothering me about the bugzilla ticket and the resulting discussions in the various places. Paul Nasrat who this bug was assigned to as component owner did not (up to now) respond to the bug. If I would do so for an extras bug people would consider it rude (and they sure are right to do so) but that might still happen because I am a volunteer. The bug was filed on 2005-11-27 so one would think that there would have been some time in the past ~2 years to respond in _any_ way to this. So now before the flame starts: I don't want to accuse Paul or anybody. This is just a fact. Now from the information I gathered I see that rh was/is having some problems with the way jbj is handling rpm development and on how to proceed with the issue. That is perfectly ok but why not state this clearly in the bugreport, give infos about the state of this and so on? Fedora is supposed to be a community project. I know that for the Core stuff other considerations (in respect to RHEL) have to be considered and that this is a big reason why the community is not as much involved and asked about core decisions but not being involved does not mean that the community is not informed and kept up to date about decisions or that nobody is responding not even with a superficial answer (or that only a few selected non rh people know). For me this is one of the biggest reasons to get upset about working on fedora stuff: the lack of communication that pops up now and then about 'sensitive' topics. I really hope that we can draw a line one of these days and that this stops. The second thing that is bothering me about the whole upgrading/forking/... rpm issue is this: jbj from a technical pov is really someone one would like to have on board for working on rpm and enhancing/fixing it. I think nobody will argue about this: jbj knows the code inside out. I don't know what issues rh and jbj had that he got fired and that lead to the tense situation that is there now. To tell you the truth I don't care and I think it does not really matter in respect to the future of rpm in fedora or even to the future of rpm as a whole. Why did the idea arise to fork rpm in the first place (as a side note: I am using fork merely as 'fork' because I want to skip the whole 'who is upstream rpm...' discussion)? From what I read it is because people (mostly rh folks) are against some of the changes/enhances that newer rpm versions have undergone. Well that is perfectly fine but why can't these people speak out what they don't like and even more importantly speak out why they don't like it (and saying because I like my coffee black does not count)? In addition we still have a packaging board that could say not to use an extension ect. even if it is ther. Just think about this for a while before you go on to read the next block. Ok that what do I want: I want to point out my strongest disbelieve that forking rpm away from jbj is the right thing to do. We are, and that no matter was is a fault of not taking action in the past 2 years, in a position where we need to make progress and take a decision but please let it be the right one. We are all grown up (at least more or less) and we cannot let some conflicts that don't really have to do with rpm let as believe that a fork is that solution we seek. There have been enough examples in the open source world where this lead to so many problems for developers as well as for people using the products and lastly blaming it on 'linux' and I think we all agree that we want to draw people to linux and not push them away from it. That happens often enough already. So yes it feels good to say that. I hope that you are still with me and reading on and not tearing my mail apart, I would really like to be heard and given the chance to try this: So I am just a seemingly inactive member of FESCo and a packager with a bunch of unimportant packages and somebody who usually does not even write mails to lists (so think about what it means that I wrote this mail) I am offering myself to do this: rpm as a open source software needs to be just that: open sources software. Nothing rh or any company has its finger on (is this a valid english analogy?). As an os project rpm should have a _team_ of people working on it. So my idea would be to not conflict with each other but to work together and work things out. How? I strongly believe that jbj would be willing to do some changes on rpm and work on a joint effort without reservation if rh people (and fedora community people) would do so without reservation. I don't expect anybody to become buddies as a result of this but for the sake of rpm and all the projects using it: lets get down on a table together and talk about this and I mean a technical discussion. Forget or lay aside any differences that don't have to do with rpm and start making decisions about rpm and its future. I am willing to talk to jbj and trying to get him to sit down at this table but the question is are you? There are so many ways the issues with new versions of rpm can be worked out that forking seems like an easy way out for the time being but could really be avoided. What I would expect to come out of this? That those people gather who would like to see rpm getting active development and form a team. A team in which decisions are made as a team and in which people can live with (attention big word coming up) democratic decisions. This way we can prevent another disaster in the open source world and even show that situations like this can be overcome if people are willing. Ok before I go on with writing even more here (and be sure I could) I hope you think about this before answering to my mail. I don't want this to turn into another huge thread with no results, flames or backbiting. Stay technical and political in an rpm project sense and work this out. I did not loose my humor yet but before I do one last word: Please. Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Nov 3 11:07:44 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 03 Nov 2006 12:07:44 +0100 Subject: [fab] looking at our surrent state a bit Message-ID: <454B2300.8080900@leemhuis.info> Hi All! Well, FC 6 is out, and I thought it might be a good time to just sit back a moment and watch at our product in contrast with other distributions and our structure in general. This mail might be a small (big?) rant here and there, but I hope that's okay now and then ;-). It also missed a "Problem foo can be solved by doing bar" -- but I can write such a document if there is interest in it. = Well, some good things first = * seems people quite like FC6 * we had no major bugs in it * FE6 seems to be okay as well (Extras didn't manage to push a proper comps.xml in time -- shame on us) = Some things that are not that well afaics = Well, this section is a bit longer :-/ Sorry. == Fedora Project Board == * it's not that much present -- we know it exists, but that's often all. * seems to meet quite seldom and it's hard to see what it does or if there even is progress somewhere * some Extras contributors mentioned to me that the hierarchy in the whole project is not documented properly (does FESCo get orders from the board? Where is the Packaging Committee located in the whole picture? Stuff like that...). * why doesn't the board at least now and then meet on irc so other interested parties can watch or comment? * the rpm problem is still not solved and makes a lot of people upset. == Fedora Core == I more and more get the impression that lots of Red Hat developers work directly in a lot of upstream projects (kernel, gnome, ...) and improve it in great ways. That a good thing as the whole Open-Source-Software-Stack gets better that way and everyone (including other distributions) can just use those improvements. That's a good thing and the main reason why I'm working in Fedora-Land and not for Ubuntu (they seem to be quite bad when it comes to be sending patches back upstream) or OpenSuse (remember the Xgl and Compiz stuff that was developed behind closed doors for quite some time; not to mention the recent Novell - MS happenings). But on the other hand it seems to me that the progress in our distribution specific stack (anaconda, config tools, initscripts) is quite slow. And not only that, also the infrastructure of Fedora for the community (new VCS, let community help in Core, ...) seems to go forward quite slowly (e.g. nearly nothing). Yes, there is some process and some quite nice new features here and there, but OpenSuse and especially Ubuntu seem to be a lot better in that area and (more important) get much more attention in the news and within the Linux community for their improvements. The Live-CD is a good example for the problems -- how long are we working on it now without a real result? Much to long! Boot-time improvements are another area where Ubuntu and Opensuse got a lot better in past. And we? Readahead improvements like https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156442 linger around without much process for ages. 73 of 850 files in readahed.early and 441 of 3757 files in readahead.later don't even exist on FC7. Readahead.later should run as last app in the init process, but doesn't as there are several other initscripts that run at level 99 (some of them are started after readahead later). There was much talk about a new init system but nothing real came out of it (and Ubuntu got all the credits for their upstart in between). Starting some jobs in parallel/or while the log-in screen is shown was in the discussion and even in testing once, but seems to have vanished again (Opensuse does something like that these days iirc). And RHGB still starts once, ends, and a new X is fireed of for the real session :-/. Takes some more time again. I also like Fedora Core due to the "Open-Source only" and "Upsteam please" attitude. But most of the normal users only see the disadvantages (nearly no drivers/features that are not upstream in out packages, no ACPI-DSTD in initrd [see also http://hughsient.livejournal.com/5889.html -- that blog entry is a good general example IMHO], no acrobat, no jre from sun, no proprietary drivers from ati/nvidia and not even the firmware for ipw2[12]00 ) that behavior creates -- and at the same time we are AFAICS quite bad when if comes to communicate the "But we are the good guys and that's the disadvantage we have to for being the good guys" to out users (that might give us some bonus points here and there). We also don't get a unique "Fedora look and feel" to the world. "Fedora is about the rapid progress of Free and Open Source software and content." (quote from http://fedoraproject.org/wiki/Objectives ). Well, that's true in some parts of Fedora (nearly always latest KDE, major kernel updates, Gnome Updates to 2.x.0 to 2.x.[0-9], lot's of updates in Extras-Land), but fail in other areas (no gutenprint in FC6 [a lot of printers are not supported due to that], only Firefox 1.5[Ubuntu 6.10 shipped two days after FC6 and has Firefox 2.0 and gutenprint] and no sign of a update in Core to FF 2.0, no X.org-Update to 7.1 [even after the proprietary drivers where able to handle it; owners of G965 hardware were left out in the cold without Support in Fedora due to this as the driver for that popular hardware depends on/is shipped in Xorg 7.1], sometimes users have to wait ages to get the latest Gnome (remember FC4) because that's not updated and out schedule isn't aligned to the gnome schedule [in other words: users of Ubuntu get the hard work from a lot of Red-Hat-Gnome-hackers earlier then Fedora Core users -- arrggghhhhh]). I especially dislike the behavior for * Gnome and Firefox as a lot of users are interested to run the latest version of those packages (sure, that's often stupid, but that's how it is) * X.org and gutenprint, as hardware support is crucial -- that sucks even more as out hardware support in other areas of Fedora is quite good as kernel and packages like sane get updates to new upstream version regularly We still have no "Fedora Core steering Commitee" (see also https://www.redhat.com/archives/fedora-advisory-board/2006-September/msg00079.html ) -- what core does or how decisions are made it completely in the dark for the Community and that really sucks. Why don't we have a public roadmap? That might give community members at least a chance to get interested in topics and start helping getting them done. == Fedora Extras == * Developers from Core talk to Extras contributors more often these days; still far from prefect, but it's getting better * the Fedora Directory Server is still not in Core or Extras afaik * we can't do anything we'd like to do; I hope we can get a bit more support from RH in the future == MISC == * I got the impression (and LWN readers, too ["hello corbert! "]) that Fedora Legacy is not able to do it's job properly. Maybe it's time to just revamp the whole project? = Closing = That's all that came to my mind now. I'm sure I missed a lot of stuff. Maybe I should maintain this document in the wiki and add all the stuff there in the next month and post it again after FC7 ;) Anyway, thx everybody for you hard work in Fedora. I like the project. But I think we could do much better -- thus this mail. CU thl From sundaram at fedoraproject.org Fri Nov 3 12:26:00 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 03 Nov 2006 17:56:00 +0530 Subject: [fab] FSF Requirements for srpm provisions In-Reply-To: <1162503295.11351.21.camel@zod.rchland.ibm.com> References: <200611021103.06057.jkeating@redhat.com> <20061102163237.GE13496@nostromo.devel.redhat.com> <200611021544.20984.jkeating@redhat.com> <1162503295.11351.21.camel@zod.rchland.ibm.com> Message-ID: <454B3558.4000403@fedoraproject.org> Josh Boyer wrote: > On Thu, 2006-11-02 at 15:44 -0500, Jesse Keating wrote: >> On Thursday 02 November 2006 11:32, Bill Nottingham wrote: >>> I'd prefer they have their own SRPMS, especially if they had to pull >>> anything from -devel (which will get obsoleted from the download >>> site soon.) >>> >>> Now, if they just want one big source ISO, that's fine. >> What about the Fedora project case going forward? A spin of Fedora being of >> both Core and Extras packages, user chosen (or in some cases project chosen) >> package set. Does EACH spin have to ship the SRPMS used, or can all refer >> back to the SRPM pool at fedoraproject.org and its mirrors? > > If you hose those off of fedoraproject.org (thereby making them official > Fedora projects) then the problem would be solved. Yes. Any respins done purely out of the formal Fedora pool of packages can be hosted off fedoraproject.org. In particular, use the bittorrent server. Fedora Unity and any others could do that and solve various infrastructure issues for free and focus efforts on the respin itself rather than worry about how to get it out there to end users. In the near future, tools like Pungi* could help do the respins and other variations in a easier way. Rahul * https://www.redhat.com/archives/fedora-devel-list/2006-October/msg00673.html From sundaram at fedoraproject.org Fri Nov 3 13:16:02 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 03 Nov 2006 18:46:02 +0530 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B2300.8080900@leemhuis.info> References: <454B2300.8080900@leemhuis.info> Message-ID: <454B4112.7030604@fedoraproject.org> Thorsten Leemhuis wrote: > Hi All! > > Well, FC 6 is out, and I thought it might be a good time to just sit > back a moment and watch at our product in contrast with other > distributions and our structure in general. > > This mail might be a small (big?) rant here and there, but I hope that's > okay now and then ;-). It also missed a "Problem foo can be solved by > doing bar" -- but I can write such a document if there is interest in it. Sure. > > = Well, some good things first = > > * seems people quite like FC6 > * we had no major bugs in it Well, we did. http://fedoraproject.org/wiki/Bugs/FC6Common. The top two bugs here affected quite a few people. It is still better than previous releases and the workarounds are simple. So thats a good thing. > * FE6 seems to be okay as well (Extras didn't manage to push a proper > comps.xml in time -- shame on us) > > = Some things that are not that well afaics = > > Well, this section is a bit longer :-/ Sorry. > > == Fedora Project Board == > > * it's not that much present -- we know it exists, but that's often all. > * seems to meet quite seldom and it's hard to see what it does or if > there even is progress somewhere We havent had a meeting in the last few weeks due to the release work and other things but whenever there is one, the agenda is posted here and post meeting results are available in the wiki and send to fedora-announce list. http://fedoraproject.org/wiki/Board/Meetings/ What else could be done? > * some Extras contributors mentioned to me that the hierarchy in the > whole project is not documented properly (does FESCo get orders from the > board? Where is the Packaging Committee located in the whole picture? > Stuff like that...). That's essentially pretty simple but that could be documented better. I will do that. Fedora Project Board | Sub Project Steering Committees | Individual contributors and users > * why doesn't the board at least now and then meet on irc so other > interested parties can watch or comment? I wouldnt mind and I heard opinions that phone conversations move much faster. If you want to participate, post meeting results can always be discussed. > But on the other hand it seems to me that the progress in our > distribution specific stack (anaconda, config tools, initscripts) is > quite slow. Is Anaconda really in the list of slow moving projects? Considering the number of changes every release and looking at the rawhide changelog even today I wouldnt make that claim. And not only that, also the infrastructure of Fedora for the > community (new VCS, let community help in Core, ...) seems to go forward > quite slowly (e.g. nearly nothing). Jesse Keating is working on setting up a mercurial repository. > > The Live-CD is a good example for the problems -- how long are we > working on it now without a real result? Much to long! Fedora Unity produced some Live CD's which can be considered real results. Official CD releases are unfortunately taking a longer time but if various sub projects would require Red Hat developers to work on them that would essential mean we would have to prioritize the work. > I also like Fedora Core due to the "Open-Source only" and "Upsteam > please" attitude. But most of the normal users only see the > disadvantages (nearly no drivers/features that are not upstream in out > packages, no ACPI-DSTD in initrd [see also > http://hughsient.livejournal.com/5889.html -- that blog entry is a good > general example IMHO], no acrobat, no jre from sun, no proprietary > drivers from ati/nvidia and not even the firmware for ipw2[12]00 ) that > behavior creates -- and at the same time we are AFAICS quite bad when if > comes to communicate the "But we are the good guys and that's the > disadvantage we have to for being the good guys" to out users (that > might give us some bonus points here and there). What could we do about that? > We also don't get a unique "Fedora look and feel" to the world. In the last couple of releases, the logo and the work done in the Fedora artwork team is very well recognized as unique and appealing in many places. "Fedora > is about the rapid progress of Free and Open Source software and > content." (quote from http://fedoraproject.org/wiki/Objectives ). Well, > that's true in some parts of Fedora (nearly always latest KDE, major > kernel updates, Gnome Updates to 2.x.0 to 2.x.[0-9], lot's of updates in > Extras-Land), but fail in other areas (no gutenprint in FC6 [a lot of > printers are not supported due to that], only Firefox 1.5[Ubuntu 6.10 > shipped two days after FC6 and has Firefox 2.0 and gutenprint] and no > sign of a update in Core to FF 2.0, no X.org-Update to 7.1 [even after > the proprietary drivers where able to handle it; owners of G965 hardware > were left out in the cold without Support in Fedora due to this as the > driver for that popular hardware depends on/is shipped in Xorg 7.1], > sometimes users have to wait ages to get the latest Gnome (remember FC4) > because that's not updated and out schedule isn't aligned to the gnome > schedule [in other words: users of Ubuntu get the hard work from a lot > of Red-Hat-Gnome-hackers earlier then Fedora Core users -- > arrggghhhhh]). That's the essence of free software. I especially dislike the behavior for > * Gnome and Firefox as a lot of users are interested to run the latest > version of those packages (sure, that's often stupid, but that's how it is) > * X.org and gutenprint, as hardware support is crucial -- that sucks > even more as out hardware support in other areas of Fedora is quite good > as kernel and packages like sane get updates to new upstream version > regularly Gutenberg, Xorg 7.1, Firefox 2.0 updates were discussed in fedora-devel list in detail. So I wont rehash that now. You want to push all major updates like GNOME and Xorg releases into updates in general release which is not really feasible if you want some form of stability. Rapid progress does not mean we can push everything into updates. > We still have no "Fedora Core steering Commitee" (see also > https://www.redhat.com/archives/fedora-advisory-board/2006-September/msg00079.html http://fedoraproject.org/wiki/Core/SteeringCommittee. > ) -- what core does or how decisions are made it completely in the dark > for the Community and that really sucks. More public regular meetings might help. I have suggested that. > Why don't we have a public roadmap? That might give community members > at least a chance to get interested in topics and start helping getting > them done. There is usually no central top down planning usually done. Individual developers work on various parts of the releases. That's the reason getting roadmaps out has been difficult. I would like to have this changed too. > == Fedora Extras == > > * Developers from Core talk to Extras contributors more often these > days; still far from prefect, but it's getting better > * the Fedora Directory Server is still not in Core or Extras afaik Individual pieces required for FDS like svrcore-devel and mozldap this is already under review in Fedora Extras and the directory server team is working on fixing various aspects like following FHS better, autotools, static libs etc. It wouldnt pass through review without making the developer changes and testing them. > * we can't do anything we'd like to do; I hope we can get a bit more > support from RH in the future What does this mean? > == MISC == > > * I got the impression (and LWN readers, too ["hello corbert! "]) that > Fedora Legacy is not able to do it's job properly. Maybe it's time to > just revamp the whole project? How? Rahul From bugs.michael at gmx.net Fri Nov 3 13:49:36 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 3 Nov 2006 14:49:36 +0100 Subject: [fab] looking at our current state a bit In-Reply-To: <454B2300.8080900@leemhuis.info> References: <454B2300.8080900@leemhuis.info> Message-ID: <20061103144936.9e5f4c86.bugs.michael@gmx.net> On Fri, 03 Nov 2006 12:07:44 +0100, Thorsten Leemhuis wrote: > * FE6 seems to be okay as well (Extras didn't manage to push a proper > comps.xml in time -- shame on us) JFYI: An updated comps.xml is in place since the day before yesterday (this is too late for the FC6 roll-out, but read on below), and I might help with updating it in an automated way, too. Once more this shows that communication is far worse than it could be. The comps.xml files in the repository have _not_ been updated since April 17th. That makes me wonder why contributors have been asked to add new entries in CVS and why a "comps SIG" has been created? There also doesn't seem to be any public communication about what the 2-3 people, who have "comps.xml automation" assigned to themselves, are working on or what they have discussed before. That is a "behind closed doors" development model, where any contributions from outside bear the risk of being wasted time (because of redundancy, reinventing the wheel or because of going into a different direction). From dennis at ausil.us Fri Nov 3 14:17:22 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 3 Nov 2006 08:17:22 -0600 Subject: [fab] looking at our current state a bit In-Reply-To: <20061103144936.9e5f4c86.bugs.michael@gmx.net> References: <454B2300.8080900@leemhuis.info> <20061103144936.9e5f4c86.bugs.michael@gmx.net> Message-ID: <200611030817.23282.dennis@ausil.us> On Friday 03 November 2006 07:49, Michael Schwendt wrote: > On Fri, 03 Nov 2006 12:07:44 +0100, Thorsten Leemhuis wrote: > > * FE6 seems to be okay as well (Extras didn't manage to push a proper > > comps.xml in time -- shame on us) > > JFYI: An updated comps.xml is in place since the day before yesterday > (this is too late for the FC6 roll-out, but read on below), and I might > help with updating it in an automated way, too. > > Once more this shows that communication is far worse than it could be. > > The comps.xml files in the repository have _not_ been updated since April > 17th. That makes me wonder why contributors have been asked to add new > entries in CVS and why a "comps SIG" has been created? There also doesn't > seem to be any public communication about what the 2-3 people, who have > "comps.xml automation" assigned to themselves, are working on or what they > have discussed before. That is a "behind closed doors" development model, > where any contributions from outside bear the risk of being wasted time > (because of redundancy, reinventing the wheel or because of going into a > different direction). As one of the people that it is assigned to. All communication has taken place in public. it has all taken place on irc in #fedora-admin and #fedora-extras Perhaps thats a communications method that does not work for you. but that has been where it has been happening. Currently the goal is to add to the push scripts so that the first step is to checkout the cvs tree check if comps.xml.in is updated. if so run make comps check the return status if make was ok put new comps in place and do rest of the push. if make comps fail a flag will be set and the push will proceed with the old comps.xml file. -- Dennis Gilmore, RHCE Proud Australian From notting at redhat.com Fri Nov 3 13:41:13 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 3 Nov 2006 08:41:13 -0500 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B2300.8080900@leemhuis.info> References: <454B2300.8080900@leemhuis.info> Message-ID: <20061103134113.GB17328@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > == Fedora Project Board == > > * it's not that much present -- we know it exists, but that's often all. > * seems to meet quite seldom and it's hard to see what it does or if > there even is progress somewhere Well, we have public minutes. What other things do you think the board should be doing? Realistically, the board does not have *direct* resources where it can by itself implement things other than policy. > quite slow. And not only that, also the infrastructure of Fedora for the > community (new VCS, let community help in Core, ...) seems to go forward > quite slowly (e.g. nearly nothing). We're working on that. FC6 and associated releases got in the way of doing much work in this area. > The Live-CD is a good example for the problems -- how long are we > working on it now without a real result? Much to long! So, counter-argument here. Most all the work for LiveCDs is being done by the non-RH community. If the community has not been able to progress this to a 'real result', what is that saying? I would like to get to the point where progress can be made in areas without direct RH involvement. > Readahead improvements like > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156442 linger > around without much process for ages. 73 of 850 files in readahed.early > and 441 of 3757 files in readahead.later don't even exist on FC7. > Readahead.later should run as last app in the init process, but doesn't > as there are several other initscripts that run at level 99 (some of > them are started after readahead later). There was much talk about a new > init system but nothing real came out of it (and Ubuntu got all the > credits for their upstart in between). Starting some jobs in parallel/or > while the log-in screen is shown was in the discussion and even in > testing once, but seems to have vanished again (Opensuse does something > like that these days iirc). And RHGB still starts once, ends, and a new > X is fireed of for the real session :-/. Takes some more time again. I should do some comparisons again, but I do believe that FC6 bootup is a good 10-20% faster than a similar bootup from FC2/FC3. It's not particularly revolutionary, but we do make some progress. That being said, there are always more ideas than there is time. > content." (quote from http://fedoraproject.org/wiki/Objectives ). Well, > that's true in some parts of Fedora (nearly always latest KDE, major > kernel updates, Gnome Updates to 2.x.0 to 2.x.[0-9], lot's of updates in > Extras-Land), but fail in other areas (no gutenprint in FC6 [a lot of > printers are not supported due to that], only Firefox 1.5[Ubuntu 6.10 > shipped two days after FC6 and has Firefox 2.0 and gutenprint] and no > sign of a update in Core to FF 2.0, How is breaking all the users extensions a *good* thing? FF 2.0 has landed in rawhide, and yes, it does browse. But now extensions like mugshot or adblock, etc. no longer work. > no X.org-Update to 7.1 [even after > the proprietary drivers where able to handle it; owners of G965 hardware > were left out in the cold without Support in Fedora due to this as the > driver for that popular hardware depends on/is shipped in Xorg 7.1], They're not left out - it's in Fedora Core 6. And the driver *still* isn't fully baked (I know, I've got a i965 box on my desk.) I'd prefer not to give users of a stable release a driver that only starts X correctly once or twice per boot. > * Gnome and Firefox as a lot of users are interested to run the latest > version of those packages (sure, that's often stupid, but that's how it is) So, it is better to constantly backport features to existing releases rather than work on pushing the next release forward? That's the tradeoff you're suggesting here. > * X.org and gutenprint, as hardware support is crucial -- that sucks > even more as out hardware support in other areas of Fedora is quite good > as kernel and packages like sane get updates to new upstream version > regularly I call bullshit on this. X.org is always the latest release available at the time the distro is frozen, and we've been working hard to get new features and better hardware support into it. All the autoconfiguration work in FC6? Done by Red Hat, and I do believe available in Fedora Core first. > Why don't we have a public roadmap? That might give community members > at least a chance to get interested in topics and start helping getting > them done. So, for many cases, it's follow-the-roadmap-for-the-upstream-project. We can do better here, but, for example, there's a lot that's just 'whatever GNOME ships.' > > == Fedora Extras == > ... > * we can't do anything we'd like to do; I hope we can get a bit more > support from RH in the future Huh? Bill From jkeating at redhat.com Fri Nov 3 14:37:01 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Nov 2006 09:37:01 -0500 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B2300.8080900@leemhuis.info> References: <454B2300.8080900@leemhuis.info> Message-ID: <200611030937.02060.jkeating@redhat.com> On Friday 03 November 2006 06:07, Thorsten Leemhuis wrote: > ?But on the other hand it seems to me that the progress in our > distribution specific stack (anaconda, config tools, initscripts) is > quite slow. And not only that, also the infrastructure of Fedora for the > community (new VCS, let community help in Core, ...) seems to go forward > quite slowly (e.g. nearly nothing). ?Yes, there is some process and some > quite nice new features here and there, but OpenSuse and especially > Ubuntu seem to be a lot better in that area and (more important) get > much more attention in the news and within the Linux community for their > improvements. As far as the VCS goes, there _has_ been significant progress. Since FC6 went out the door I took the opportunity to devote some time to this task. As of last night there is a proof of concept dist-hg setup that provides Extras package source control in mercurial, complete with Makefile support and a deployment of plague modified to build from HG. If you wish to test, see the dist-hg page: http://fedoraproject.org/wiki/Infrastructure/VersionControl/dist-hg I plan on taking what I learned from dist-hg and incorporating it into a dist-git proof of concept. [SNIP] > > ?We still have no "Fedora Core steering Commitee" (see also > https://www.redhat.com/archives/fedora-advisory-board/2006-September/msg000 >79.html ) -- what core does or how decisions are made it completely in the > dark for the Community and that really sucks. We're working on that. Core has mostly be handled by members of the Fedora board. We'd like to change how this works for the next Fedora release. > > ?Why don't we have a public roadmap? That might give community members > at least a chance to get interested in topics and start helping getting > them done. We don't have a public road map as we haven't fully looked at all the changes we'd like to do for the next Fedora release. We just got FC6 out the door, and we're taking a bit of a breather. New package versions continue to march on as always. There are some pretty major infrastructural, political, and technical changes that the Fedora Board would like to see made during the next development cycle. A "summit" will be taking place in about a weeks time to discuss much of this and present it to the community. Please stay tuned. > > == Fedora Extras == > > ?* Developers from Core talk to Extras contributors more often these > days; still far from prefect, but it's getting better We Red Hat folk continue to educate other Red Hat folk about Extras and the role the Extras developers play in the Fedora releases. Sometimes its hard to reach every one, but we're trying. > ?* the Fedora Directory Server is still not in Core or Extras afaik Last I heard there are some packages that are up for review, but are languishing due to no reviewers. We don't want to just shove the software into Extras w/out a review now do we? > ?* we can't do anything we'd like to do; I hope we can get a bit more > support from RH in the future That's a pretty vague and hurtful statement :/ > > == MISC == > > ?* I got the impression (and LWN readers, too ["hello corbert! "]) that > Fedora Legacy is not able to do it's job properly. Maybe it's time to > just revamp the whole project? This is part of what we'll be discussing at our "summit". The changes we'd like to make have far reaching implications, Legacy being one of those reached. Again, please stay tuned. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Fri Nov 3 14:44:46 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 3 Nov 2006 15:44:46 +0100 Subject: comps.xml (Re: [fab] looking at our current state a bit) In-Reply-To: <200611030817.23282.dennis@ausil.us> References: <454B2300.8080900@leemhuis.info> <20061103144936.9e5f4c86.bugs.michael@gmx.net> <200611030817.23282.dennis@ausil.us> Message-ID: <20061103154446.a717a8db.bugs.michael@gmx.net> On Fri, 3 Nov 2006 08:17:22 -0600, Dennis Gilmore wrote: > As one of the people that it is assigned to. All communication has taken > place in public. it has all taken place on irc in #fedora-admin and > #fedora-extras Perhaps thats a communications method that does not work for > you. but that has been where it has been happening. Are logs of the relevant bits available? So, public, but not really open. > Currently the goal is to add to the push scripts so that the first step is to > checkout the cvs tree check if comps.xml.in is updated. if so run make comps > check the return status if make was ok put new comps in place and do rest of > the push. if make comps fail a flag will be set and the push will proceed > with the old comps.xml file. Running "make comps" within the CVS check-out would make the push process vulnerable to real-time modifications from the outside, because the Makefile is not protected in any special ways. That would be an unnecessary security risk. From sundaram at fedoraproject.org Fri Nov 3 14:57:58 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 03 Nov 2006 20:27:58 +0530 Subject: comps.xml (Re: [fab] looking at our current state a bit) In-Reply-To: <20061103154446.a717a8db.bugs.michael@gmx.net> References: <454B2300.8080900@leemhuis.info> <20061103144936.9e5f4c86.bugs.michael@gmx.net> <200611030817.23282.dennis@ausil.us> <20061103154446.a717a8db.bugs.michael@gmx.net> Message-ID: <454B58F6.8090203@fedoraproject.org> Michael Schwendt wrote: > On Fri, 3 Nov 2006 08:17:22 -0600, Dennis Gilmore wrote: > >> As one of the people that it is assigned to. All communication has taken >> place in public. it has all taken place on irc in #fedora-admin and >> #fedora-extras Perhaps thats a communications method that does not work for >> you. but that has been where it has been happening. > > Are logs of the relevant bits available? So, public, but not really open. > The infrastructure wiki pages has all the important bits. Rahul From tibbs at math.uh.edu Fri Nov 3 15:09:04 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 03 Nov 2006 09:09:04 -0600 Subject: comps.xml (Re: [fab] looking at our current state a bit) In-Reply-To: <20061103154446.a717a8db.bugs.michael@gmx.net> References: <454B2300.8080900@leemhuis.info> <20061103144936.9e5f4c86.bugs.michael@gmx.net> <200611030817.23282.dennis@ausil.us> <20061103154446.a717a8db.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> Are logs of the relevant bits available? So, public, but not MS> really open. Man, that's petty. I'm sure plenty of people have them, but I'll make the offer: I have full logs of #fedora-extras and #fedora-admin going back at least a couple of months if someone needs them. I can even separate out the meetings from #fedora-admin if someone wants, but note that I'm away for the weekend and won't be able to look to this until Monday. - J< From sundaram at fedoraproject.org Fri Nov 3 15:16:34 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 03 Nov 2006 20:46:34 +0530 Subject: comps.xml (Re: [fab] looking at our current state a bit) In-Reply-To: References: <454B2300.8080900@leemhuis.info> <20061103144936.9e5f4c86.bugs.michael@gmx.net> <200611030817.23282.dennis@ausil.us> <20061103154446.a717a8db.bugs.michael@gmx.net> Message-ID: <454B5D52.1000406@fedoraproject.org> Jason L Tibbitts III wrote: >>>>>> "MS" == Michael Schwendt writes: > > MS> Are logs of the relevant bits available? So, public, but not > MS> really open. > > Man, that's petty. > Not really. He has a point. If Fedora Infrastructure team has been having regular meetings, then posting the logs/meeting mins would be quite useful. However the meeting is done in a public channel and the important results are already in the wiki. Rahul From fedora at leemhuis.info Fri Nov 3 15:19:12 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 03 Nov 2006 16:19:12 +0100 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B4112.7030604@fedoraproject.org> References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> Message-ID: <454B5DF0.90908@leemhuis.info> Rahul Sundaram schrieb: > Thorsten Leemhuis wrote: >> * it's not that much present -- we know it exists, but that's often all. >> * seems to meet quite seldom and it's hard to see what it does or if >> there even is progress somewhere > We havent had a meeting in the last few weeks due to the release work > and other things but whenever there is one, the agenda is posted here > and post meeting results are available in the wiki and send to > fedora-announce list. > http://fedoraproject.org/wiki/Board/Meetings/ > What else could be done? IMHO: Meet more often. Get more involved into decisions. Show presence. >> * some Extras contributors mentioned to me that the hierarchy in the >> whole project is not documented properly (does FESCo get orders from the >> board? Where is the Packaging Committee located in the whole picture? >> Stuff like that...). > That's essentially pretty simple but that could be documented better. I > will do that. [...] thx >> * why doesn't the board at least now and then meet on irc so other >> interested parties can watch or comment? > I wouldnt mind and I heard opinions that phone conversations move much > faster. [...] Well, phone meetings are okay. That's why I suggested "now and then meet on irc" -- then everyone can get in contact with the board now and then while it can still get work done. That gets rid of the "secret cabal" look that some outsiders might have. >> But on the other hand it seems to me that the progress in our >> distribution specific stack (anaconda, config tools, initscripts) is >> quite slow. > Is Anaconda really in the list of slow moving projects? [...] Yes and no -- The team does a good job, but looking back it took quite some time until anaconda was capable of using Extras during install. To long IMHO. Installing packages from CD/DVD also is still lacking. >> And not only that, also the infrastructure of Fedora for the >> community (new VCS, let community help in Core, ...) seems to go forward >> quite slowly (e.g. nearly nothing). > Jesse Keating is working on setting up a mercurial repository. I know, and Jesse, Jeremy, Bill and the others are doing great work, but their days are only 24 hours long, too (and their work days are limited, too). >> The Live-CD is a good example for the problems -- how long are we >> working on it now without a real result? Much to long! > Fedora Unity produced some Live CD's which can be considered real > results. Agreed. > Official CD releases are unfortunately taking a longer time but > if various sub projects would require Red Hat developers to work on > them that would essential mean we would have to prioritize the work. Exactly that's what I'd like to see. >> I also like Fedora Core due to the "Open-Source only" and "Upsteam >> please" attitude. But most of the normal users only see the >> disadvantages (nearly no drivers/features that are not upstream in out >> packages, no ACPI-DSTD in initrd [see also >> http://hughsient.livejournal.com/5889.html -- that blog entry is a good >> general example IMHO], no acrobat, no jre from sun, no proprietary >> drivers from ati/nvidia and not even the firmware for ipw2[12]00 ) that >> behavior creates -- and at the same time we are AFAICS quite bad when if >> comes to communicate the "But we are the good guys and that's the >> disadvantage we have to for being the good guys" to out users (that >> might give us some bonus points here and there). > What could we do about that? Not sure, I'm not a marketing guy. But we need to communicate better that we're nearly as free as Debian (here and there we are worse, in other areas we are better afaics). Most people don't know that afaics. >> We also don't get a unique "Fedora look and feel" to the world. > In the last couple of releases, the logo and the work done in the Fedora > artwork team is very well recognized as unique and appealing in many > places. The artwork is great and I really like it, but that's not what I meant. ;-) It was more and introduction to this para: > "Fedora >> is about the rapid progress of Free and Open Source software and >> content." (quote from http://fedoraproject.org/wiki/Objectives ). Well, >> that's true in some parts of Fedora (nearly always latest KDE, major >> kernel updates, Gnome Updates to 2.x.0 to 2.x.[0-9], lot's of updates in >> Extras-Land), but fail in other areas (no gutenprint in FC6 [a lot of >> printers are not supported due to that], only Firefox 1.5[Ubuntu 6.10 >> shipped two days after FC6 and has Firefox 2.0 and gutenprint] and no >> sign of a update in Core to FF 2.0, no X.org-Update to 7.1 [even after >> the proprietary drivers where able to handle it; owners of G965 hardware >> were left out in the cold without Support in Fedora due to this as the >> driver for that popular hardware depends on/is shipped in Xorg 7.1], >> sometimes users have to wait ages to get the latest Gnome (remember FC4) >> because that's not updated and out schedule isn't aligned to the gnome >> schedule [in other words: users of Ubuntu get the hard work from a lot >> of Red-Hat-Gnome-hackers earlier then Fedora Core users -- >> arrggghhhhh]). > That's the essence of free software. I know that, but it seems you didn't understand what I was up to. >> I especially dislike the behavior for >> * Gnome and Firefox as a lot of users are interested to run the latest >> version of those packages (sure, that's often stupid, but that's how it is) >> * X.org and gutenprint, as hardware support is crucial -- that sucks >> even more as out hardware support in other areas of Fedora is quite good >> as kernel and packages like sane get updates to new upstream version >> regularly > Gutenberg, Xorg 7.1, Firefox 2.0 updates were discussed in fedora-devel > list in detail. So I wont rehash that now. > > You want to push all major updates like GNOME No, I think we should align out schedule to Gnome, as it is a crucial part of our product. > and Xorg releases Xorg: yes. The updates improve hardware support and are often needed to get the latest Hardware running. And that's why I think why we should ship them often (still needs to be decided on a case by case basis). > into > updates in general release which is not really feasible if you want some > form of stability. Rapid progress does not mean we can push everything > into updates. Sure. That's not what I proposed. But if there are important things missing (FF 2.0 in FC6; AIGLX in FC5, Gnome Update in FC4) then try to get a solution that makes installing those software possible easily (the AIGLX on FC5 was more a disaster because it was poorly maintained). >> We still have no "Fedora Core steering Commitee" (see also >> https://www.redhat.com/archives/fedora-advisory-board/2006-September/msg00079.html > http://fedoraproject.org/wiki/Core/SteeringCommittee. I had something like FESCo im mind. E.g. more members (maybe even from outside of RH), public meetings, summaries to the list. >> ) -- what core does or how decisions are made it completely in the dark >> for the Community and that really sucks. > More public regular meetings might help. I have suggested that. thx. >> == Fedora Extras == >> >> * Developers from Core talk to Extras contributors more often these >> days; still far from prefect, but it's getting better >> * the Fedora Directory Server is still not in Core or Extras afaik > Individual pieces required for FDS like svrcore-devel and mozldap this > is already under review in Fedora Extras and the directory server team > is working on fixing various aspects like following FHS better, > autotools, static libs etc. It wouldnt pass through review without > making the developer changes and testing them. Yeah, warren mentioned something during yesterdays meeting. But it took quite some time and that's the biggest problem in Fedora -- everything takes a long time. >> * we can't do anything we'd like to do; I hope we can get a bit more >> support from RH in the future > What does this mean? Well, take Comaintainership as example. We need - acl support in the build system - a package database to get per dist maintainers - a better framework to make it easier to watch what the people you sponsored changes in cvs That's a lot of work (mainly on the infrastructure side) and I more and more get the impression that with our current manpower it will take one or two years until we might have it in place. A little bit help from someone that getting payed for his work might help >> == MISC == >> >> * I got the impression (and LWN readers, too ["hello corbert! "]) that >> Fedora Legacy is not able to do it's job properly. Maybe it's time to >> just revamp the whole project? > How? Give it a fresh start, a new name (because the Term "Fedora Legacy" has such a bad fame now), maybe try to get the load reduced (only support releases with odd number for a longer time, drop old releases). Cu thl From jkeating at redhat.com Fri Nov 3 15:26:45 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Nov 2006 10:26:45 -0500 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B5DF0.90908@leemhuis.info> References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> Message-ID: <200611031026.45750.jkeating@redhat.com> On Friday 03 November 2006 10:19, Thorsten Leemhuis wrote: > No, I think we should align out schedule to Gnome, as it is a crucial > part of our product. Uh, we do, or more specifically they align their schedule to our releases most often. > > > and Xorg releases > > Xorg: yes. The updates improve hardware support and are often needed to > get the latest Hardware running. And that's why I think why we should > ship them often (still needs to be decided on a case by case basis). > > > into > > updates in general release which is not really feasible if you want some > > form of stability. Rapid progress does not mean we can push everything > > into updates. > > Sure. That's not what I proposed. But if there are important things > missing (FF 2.0 in FC6; Already stated why this is a very bad idea. You get a '2' in the name, and you get to look at all your broken extensions. Not fun. > AIGLX in FC5, Decision made by the maintainer. > Gnome Update in FC4) FC4 is well Legacy now, and even at the time, it isn't desireable to make a huge update to that old of a release. (you were talking about the timeframe where FC5 was live, FC6 was in development, and FC4 was still getting some updates?) Personally I want to see a more formal update policy. Current release gets lots of updates maybe some version bumps for things like KDE/Gnome. N-1 gets less updates, more just bugfixes. N-2 and 3 are security only handled through the Fedora security team. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Nov 3 15:28:57 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Nov 2006 10:28:57 -0500 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B5DF0.90908@leemhuis.info> References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> Message-ID: <200611031028.57951.jkeating@redhat.com> On Friday 03 November 2006 10:19, Thorsten Leemhuis wrote: > Well, take Comaintainership as example. We need > > - acl support in the build system See the Infrastructure pages regarding VCS. The dist-hg proof of concept makes each package release dir its own repo and thus able to have ACLs. > - a package database to get per dist maintainers Don't have much to say here. > - a better framework to make it easier to watch what the people you > sponsored changes in cvs This again is part of the VCS changes, but could also be handled by email filtering of the commits list. > > That's a lot of work (mainly on the infrastructure side) and I more and > more get the impression that with our current manpower it will take one > or two years until we might have it in place. A little bit help from > someone that getting payed for his work might help We ARE helping. Would you like a pony too? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Nov 3 15:29:58 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Nov 2006 10:29:58 -0500 Subject: comps.xml (Re: [fab] looking at our current state a bit) In-Reply-To: <454B5D52.1000406@fedoraproject.org> References: <454B2300.8080900@leemhuis.info> <454B5D52.1000406@fedoraproject.org> Message-ID: <200611031029.59066.jkeating@redhat.com> On Friday 03 November 2006 10:16, Rahul Sundaram wrote: > Not really. He has a point. If Fedora Infrastructure team has been > having regular meetings, then posting the logs/meeting mins would be > quite useful. However the meeting is done in a public channel and the > important results are already in the wiki. Meeting notes are sent to the infrastructure list as well. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Nov 3 15:33:23 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 03 Nov 2006 21:03:23 +0530 Subject: comps.xml (Re: [fab] looking at our current state a bit) In-Reply-To: <200611031029.59066.jkeating@redhat.com> References: <454B2300.8080900@leemhuis.info> <454B5D52.1000406@fedoraproject.org> <200611031029.59066.jkeating@redhat.com> Message-ID: <454B6143.1020108@fedoraproject.org> Jesse Keating wrote: > On Friday 03 November 2006 10:16, Rahul Sundaram wrote: >> Not really. He has a point. If Fedora Infrastructure team has been >> having regular meetings, then posting the logs/meeting mins would be >> quite useful. However the meeting is done in a public channel and the >> important results are already in the wiki. > > Meeting notes are sent to the infrastructure list as well. That list is members only. No public archives. Rahul From fedora at leemhuis.info Fri Nov 3 15:47:23 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 03 Nov 2006 16:47:23 +0100 Subject: [fab] looking at our surrent state a bit In-Reply-To: <20061103134113.GB17328@nostromo.devel.redhat.com> References: <454B2300.8080900@leemhuis.info> <20061103134113.GB17328@nostromo.devel.redhat.com> Message-ID: <454B648B.9020205@leemhuis.info> Bill Nottingham schrieb: > Thorsten Leemhuis (fedora at leemhuis.info) said: >> == Fedora Project Board == >> * it's not that much present -- we know it exists, but that's often all. >> * seems to meet quite seldom and it's hard to see what it does or if >> there even is progress somewhere > Well, we have public minutes. What other things do you think the board > should be doing? A schedule page in the wiki? That's requested for sub-projects like Extras iirc, but there is no Schedule for the Board itself (and non for Core, too). > Realistically, the board does not have *direct* resources where it > can by itself implement things other than policy. Well, it jumped in the Xorg 7.1 for FC5 discussion. I liked that. I could also ask around now and then "what should the board handle?" And i could ask the subproject if they need help. >> quite slow. And not only that, also the infrastructure of Fedora for the >> community (new VCS, let community help in Core, ...) seems to go forward >> quite slowly (e.g. nearly nothing). > We're working on that. FC6 and associated releases got in the way > of doing much work in this area. I know, but it still far from perfect. >> The Live-CD is a good example for the problems -- how long are we >> working on it now without a real result? Much to long! > So, counter-argument here. Most all the work for LiveCDs is being done > by the non-RH community. If the community has not been able to progress > this to a 'real result', what is that saying? IMHO it says that the task was to big for the community . A result might have long finished if one RH employee would have helped getting the project started and up to the first real release. Then a community might exist by then that can take the project it further. > I would like to get to > the point where progress can be made in areas without direct RH involvement. I'd like to see more us working closely together. Currently Fedora often still is a bit like Core and Extras -- RH is working here, the community there, but more side-by-side and not so much together. >> Readahead improvements like >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156442 linger >> around without much process for ages. 73 of 850 files in readahed.early >> and 441 of 3757 files in readahead.later don't even exist on FC7. >> Readahead.later should run as last app in the init process, but doesn't >> as there are several other initscripts that run at level 99 (some of >> them are started after readahead later). There was much talk about a new >> init system but nothing real came out of it (and Ubuntu got all the >> credits for their upstart in between). Starting some jobs in parallel/or >> while the log-in screen is shown was in the discussion and even in >> testing once, but seems to have vanished again (Opensuse does something >> like that these days iirc). And RHGB still starts once, ends, and a new >> X is fireed of for the real session :-/. Takes some more time again. > I should do some comparisons again, but I do believe that FC6 bootup > is a good 10-20% faster than a similar bootup from FC2/FC3. It's not > particularly revolutionary, but we do make some progress. I did not try, but Suse and Ubuntu both seem to start even quicker these days. > That being said, there are always more ideas than there is time. Sure, that's true... >> content." (quote from http://fedoraproject.org/wiki/Objectives ). Well, >> that's true in some parts of Fedora (nearly always latest KDE, major >> kernel updates, Gnome Updates to 2.x.0 to 2.x.[0-9], lot's of updates in >> Extras-Land), but fail in other areas (no gutenprint in FC6 [a lot of >> printers are not supported due to that], only Firefox 1.5[Ubuntu 6.10 >> shipped two days after FC6 and has Firefox 2.0 and gutenprint] and no >> sign of a update in Core to FF 2.0, > How is breaking all the users extensions a *good* thing? FF 2.0 has > landed in rawhide, and yes, it does browse. But now extensions like > mugshot or adblock, etc. no longer work. I'm not saying we need FF 2 as a official update now. Get it out in one or two months when most extensions are fixed. Or put it in a special repo (as aiglx in FC5) and maintain it there for those interested. >> no X.org-Update to 7.1 [even after >> the proprietary drivers where able to handle it; owners of G965 hardware >> were left out in the cold without Support in Fedora due to this as the >> driver for that popular hardware depends on/is shipped in Xorg 7.1], > They're not left out - it's in Fedora Core 6. Sure, now there is something. But such Hardware is in the wild since September already. So there was a one month gap where you had no chance of running a stable release on your hardware. That's what I dislike (one month might be okay, but there were situtations in the past where it were two, three or even more months). > And the driver *still* > isn't fully baked (I know, I've got a i965 box on my desk.) Was not that bad on my desk... Well, that's not important here > I'd prefer > not to give users of a stable release a driver that only starts X correctly > once or twice per boot. Sure. But I also prefer to give them drivers if there are some. >> * Gnome and Firefox as a lot of users are interested to run the latest >> version of those packages (sure, that's often stupid, but that's how it is) > So, it is better to constantly backport features to existing releases > rather than work on pushing the next release forward? That's the tradeoff > you're suggesting here. The question is: where to draw the line. I'd like to see FF 2.0 or X.org updates in stable release *after * they were tested in devel and *only* if they seem to work properly and if they are of interest fo lof of uesrs. >> * X.org and gutenprint, as hardware support is crucial -- that sucks >> even more as out hardware support in other areas of Fedora is quite good >> as kernel and packages like sane get updates to new upstream version >> regularly > I call bullshit on this. X.org is always the latest release available > at the time the distro is frozen, and we've been working hard to get new > features and better hardware support into it. All the autoconfiguration > work in FC6? Done by Red Hat, and I do believe available in Fedora Core > first. Many thx for that. >> Why don't we have a public roadmap? That might give community members >> at least a chance to get interested in topics and start helping getting >> them done. > So, for many cases, it's follow-the-roadmap-for-the-upstream-project. > We can do better here, e.g. with a Roadmap for Fedora-Special things -- new init-system, better RHGB, stuff like that > but, for example, there's a lot that's just > 'whatever GNOME ships.' Sure. >> == Fedora Extras == > ... >> * we can't do anything we'd like to do; I hope we can get a bit more >> support from RH in the future > Huh? I got a bit more into detail in my mail to mether. CU thl From mmcgrath at fedoraproject.org Fri Nov 3 15:47:26 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 3 Nov 2006 09:47:26 -0600 Subject: [fab] looking at our surrent state a bit In-Reply-To: <200611031028.57951.jkeating@redhat.com> References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> <200611031028.57951.jkeating@redhat.com> Message-ID: <3237e4410611030747i9dd6aa4g2a2c291c89112fbd@mail.gmail.com> On 11/3/06, Jesse Keating wrote: > On Friday 03 November 2006 10:19, Thorsten Leemhuis wrote: > > Well, take Comaintainership as example. We need > > > > - acl support in the build system > > See the Infrastructure pages regarding VCS. The dist-hg proof of concept > makes each package release dir its own repo and thus able to have ACLs. > I'd also like to point out that I've had an SVN setup for FE for months but no one has shown interest. Which is very telling that not many people were interested in using SVN. Whereas mercurial and possibly git have almost instant traction from some of the developers. -Mike From sundaram at fedoraproject.org Fri Nov 3 15:57:00 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 03 Nov 2006 21:27:00 +0530 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B5DF0.90908@leemhuis.info> References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> Message-ID: <454B66CC.4010405@fedoraproject.org> Thorsten Leemhuis wrote: > Rahul Sundaram schrieb: >> Thorsten Leemhuis wrote: >>> * it's not that much present -- we know it exists, but that's often all. >>> * seems to meet quite seldom and it's hard to see what it does or if >>> there even is progress somewhere >> We havent had a meeting in the last few weeks due to the release work >> and other things but whenever there is one, the agenda is posted here >> and post meeting results are available in the wiki and send to >> fedora-announce list. >> http://fedoraproject.org/wiki/Board/Meetings/ >> What else could be done? > > IMHO: Meet more often. Get more involved into decisions. Show presence. Please be more detailed. How often do you want the board to meet? Many of the people in the board are going to be involved with other work during a new release. For the rest of us, its volunteer work. What does getting more involved into decisions and more presence involve? Like I said the meeting agenda and mins are already public. > Well, phone meetings are okay. That's why I suggested "now and then meet > on irc" -- then everyone can get in contact with the board now and then > while it can still get work done. That gets rid of the "secret cabal" > look that some outsiders might have. See above. There is nothing preventing anyone from discussing the results when the meeting mins or agenda are posted. Contacting the board is pretty easy though we recommend people post to this list instead unless it is some that needs to private. http://fedoraproject.org/wiki/Board#Contact To understand this better, ask yourself how many people not involved with FESCo would actually sit in FESCo meetings and express their opinions or would you even want to listen to such opinions at that time instead of doing it on the list? > > Yes and no -- The team does a good job, but looking back it took quite > some time until anaconda was capable of using Extras during install. To > long IMHO. Installing packages from CD/DVD also is still lacking. It is a lot of work to change Anaconda to support custom repositories. I am sure more contributors are welcome. > I know, and Jesse, Jeremy, Bill and the others are doing great work, but > their days are only 24 hours long, too (and their work days are limited, > too). A call for more volunteers to join the team was send out to fedora-announce list. You can look at wiki pages at http://fedoraproject.org/wiki/Infrastructure and contact the relevant people to help out in any of the work. Progress is already documented there to a good extend. >> Official CD releases are unfortunately taking a longer time but >> if various sub projects would require Red Hat developers to work on >> them that would essential mean we would have to prioritize the work. > > Exactly that's what I'd like to see. That's already happening. If Red Hat has to get involved with all these projects to make changes happen, where would that leave Fedora as a community project? > Not sure, I'm not a marketing guy. But we need to communicate better > that we're nearly as free as Debian (here and there we are worse, in > other areas we are better afaics). Most people don't know that afaics. Where are we worse? I dont think this is a problem of users not recognizing that Fedora is Free software but many not seeing the value of that. Ideas welcome. >> That's the essence of free software. > > I know that, but it seems you didn't understand what I was up to. No I dont obviously. Please explain. > No, I think we should align out schedule to Gnome, as it is a crucial > part of our product. Oh come on. Fedora is already very well aligned with the GNOME release schedules. > > Xorg: yes. The updates improve hardware support and are often needed to > get the latest Hardware running. And that's why I think why we should > ship them often (still needs to be decided on a case by case basis). I dont think shipping Xorg major releases as updates is a good idea now. We should avoid that IMO. > Sure. That's not what I proposed. But if there are important things > missing (FF 2.0 in FC6; AIGLX in FC5, Gnome Update in FC4) then try to > get a solution that makes installing those software possible easily (the > AIGLX on FC5 was more a disaster because it was poorly maintained). AIGLX on FC5 was not installed by default. It was a *experimental* separate repository that users had to go and install by themselves. The reasons for not moving into Firefox 2.0 was well explained by the Firefox developer and maintainer. https://www.redhat.com/archives/fedora-devel-list/2006-October/msg00624.html Major updates of GNOME post release as updates falls into the same "too risky" category as Xorg updates for me. Unlike KDE which is mostly encapsulated within itself, GNOME depends on more "system bits" like HAL and DBus etc. Now KDE has started using these too and I would wary of decisions to do major updates on this. > > I had something like FESCo im mind. E.g. more members (maybe even from > outside of RH), public meetings, summaries to the list. Having core as a Red Hat maintainer repository while having non-RH people in the steering committee doesnt really have any significant impact. What we are working on is fundamentally changing this idea by getting rid of the core/extras wall which requires infrastructure changes that is being done. > > Yeah, warren mentioned something during yesterdays meeting. But it took > quite some time and that's the biggest problem in Fedora -- everything > takes a long time. This is very broad generalization. Having you looked at the work being done in Fedora Directory Server since it was open sourced? For a long time FDS itself was open source but required the Sun JVM to work. That means we couldnt have included it in Fedora. It wouldnt have o past the review stage if that was initiated since it deviated widely from the packaging guidelines we have setup. > That's a lot of work (mainly on the infrastructure side) and I more and > more get the impression that with our current manpower it will take one > or two years until we might have it in place. A little bit help from > someone that getting payed for his work might help See Jesse Keating and other replies from the infrastructure team on this Rahul From fedora at leemhuis.info Fri Nov 3 15:58:36 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 03 Nov 2006 16:58:36 +0100 Subject: [fab] looking at our surrent state a bit In-Reply-To: <200611031026.45750.jkeating@redhat.com> References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> <200611031026.45750.jkeating@redhat.com> Message-ID: <454B672C.8070906@leemhuis.info> Jesse Keating schrieb: > On Friday 03 November 2006 10:19, Thorsten Leemhuis wrote: >> No, I think we should align out schedule to Gnome, as it is a crucial >> part of our product. > Uh, we do, Nope (see below). Just for referece: Gnome always sips mid-march and mid-september. Since quite some time now. > or more specifically they align their schedule to our releases most > often. And that's why I think we should have a long term release planing like Ubuntu and Gnome. We don't even have a schedule for FC7 currently, so GCC or X.org are not able to align their schedule to our releases... > Already stated why this is a very bad idea. You get a '2' in the name, and > you get to look at all your broken extensions. Not fun. I'm not saying we need it now. But a good solution for it might be "We'll ship FF 2.0 as a update for FC6 when it's a bit more matured and most extensions are ported; so at the end of the year probably. Until then you can get it in this special FC-6 add-on repo located on ours servers at ...." >> AIGLX in FC5, > Decision made by the maintainer. That's a excuse I hear to often these days (see gutenprint for example). That why I'd like to see a Fedora Core Steering Commitee that jumps in now and then. >> Gnome Update in FC4) > FC4 is well Legacy now, and even at the time, it isn't desireable to make a > huge update to that old of a release. (you were talking about the timeframe > where FC5 was live, FC6 was in development, and FC4 was still getting some > updates?) No. FC4 shipped with Gnome 2.10. 2.12 was never shipped by FC. 2.14 was in FC5. That 2.12 never was shipped in FC really sucked. > Personally I want to see a more formal update policy. +1 (also for Extras), but there needs to be room for decisions on a case-by-cases basis. Cu thl From jkeating at redhat.com Fri Nov 3 16:00:08 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Nov 2006 11:00:08 -0500 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B648B.9020205@leemhuis.info> References: <454B2300.8080900@leemhuis.info> <20061103134113.GB17328@nostromo.devel.redhat.com> <454B648B.9020205@leemhuis.info> Message-ID: <200611031100.08469.jkeating@redhat.com> On Friday 03 November 2006 10:47, Thorsten Leemhuis wrote: > I'm not saying we need FF 2 as a official update now. Get it out in one > or two months when most extensions are fixed. Or put it in a special > repo (as aiglx in FC5) and maintain it there for those interested. So first you're complaining that FF2 wasn't made available for FC6, and now you're saying it shouldn't be, only when its ready, and that it should be made available in a special repo for those to test. I seem to remember Chris Aillon posting up FF2 rpms for FC6 systems a while ago, and got all of some 50~ downloaders. He still feels its not ready for FC6, but it is in rawhide. How is this NOT what you wanted to see? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Nov 3 16:03:22 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 03 Nov 2006 17:03:22 +0100 Subject: [fab] looking at our surrent state a bit In-Reply-To: <200611031028.57951.jkeating@redhat.com> References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> <200611031028.57951.jkeating@redhat.com> Message-ID: <454B684A.3090504@leemhuis.info> Jesse Keating schrieb: > On Friday 03 November 2006 10:19, Thorsten Leemhuis wrote: >> Well, take Comaintainership as example. We need >> - acl support in the build system > See the Infrastructure pages regarding VCS. The dist-hg proof of concept > makes each package release dir its own repo and thus able to have ACLs. Thx for that, I'm really looking forward to it (but I keep my nose out of the details as my free time is used by Fedora work already completely). >> - a package database to get per dist maintainers > Don't have much to say here. abadger1999 works hard on it, but he does it in his free time. Here is a area where some support from someone getting payed to do work might help. >> - a better framework to make it easier to watch what the people you >> sponsored changes in cvs > This again is part of the VCS changes, but could also be handled by email > filtering of the commits list. Yes. >> That's a lot of work (mainly on the infrastructure side) and I more and >> more get the impression that with our current manpower it will take one >> or two years until we might have it in place. A little bit help from >> someone that getting payed for his work might help > We ARE helping. I know. thx for that. But I'd like to see a bit more helping for a short period of time. > Would you like a pony too? /me doesn't like horses to much. But can I have control over the Fedora Orbital laser? Jesse, please, just for two hours and I'll go immediately to bed after that. I promise. Pretty please. Cu thl From sundaram at fedoraproject.org Fri Nov 3 16:09:36 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 03 Nov 2006 21:39:36 +0530 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B672C.8070906@leemhuis.info> References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> <200611031026.45750.jkeating@redhat.com> <454B672C.8070906@leemhuis.info> Message-ID: <454B69C0.1060908@fedoraproject.org> Thorsten Leemhuis wrote: > I'm not saying we need it now. But a good solution for it might be > "We'll ship FF 2.0 as a update for FC6 when it's a bit more matured and > most extensions are ported; so at the end of the year probably. Until > then you can get it in this special FC-6 add-on repo located on ours > servers at ...." This is already there. For detailed information http://fedoraproject.org/wiki/Firefox2 > That's a excuse I hear to often these days (see gutenprint for example). > That why I'd like to see a Fedora Core Steering Commitee that jumps in > now and then. In the case of AIGLX that wouldnt change anything. AIGLX status as a experimental add on repository means that it is not a priority. > No. FC4 shipped with Gnome 2.10. 2.12 was never shipped by FC. 2.14 was > in FC5. That 2.12 never was shipped in FC really sucked. As I said earlier, putting major updates like this post release is a QA nightmare and should be avoided. >> Personally I want to see a more formal update policy There is a draft in the wiki that was included in the board update on Xorg 7.1 Rahul From fedora at leemhuis.info Fri Nov 3 16:11:30 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 03 Nov 2006 17:11:30 +0100 Subject: [fab] looking at our surrent state a bit In-Reply-To: <200611030937.02060.jkeating@redhat.com> References: <454B2300.8080900@leemhuis.info> <200611030937.02060.jkeating@redhat.com> Message-ID: <454B6A32.10309@leemhuis.info> Jesse Keating schrieb: > On Friday 03 November 2006 06:07, Thorsten Leemhuis wrote: > [...] >> We still have no "Fedora Core steering Commitee" (see also >> https://www.redhat.com/archives/fedora-advisory-board/2006-September/msg000 >> 79.html ) -- what core does or how decisions are made it completely in the >> dark for the Community and that really sucks. > We're working on that. Core has mostly be handled by members of the Fedora > board. We'd like to change how this works for the next Fedora release. thx. >> Why don't we have a public roadmap? That might give community members >> at least a chance to get interested in topics and start helping getting >> them done. > We don't have a public road map as we haven't fully looked at all the changes > we'd like to do for the next Fedora release. I think we should plan a bit more into the future here (e.g. have some rough goals for FC7 when FC6T3 [feature freeze] or FC6 get shipped or shortly afterwards). > We just got FC6 out the door, > and we're taking a bit of a breather. Well, that's okay. I needed one myself. > New package versions continue to march > on as always. Sure. > [...] >> * we can't do anything we'd like to do; I hope we can get a bit more >> support from RH in the future > That's a pretty vague and hurtful statement :/ I went a bit more into detail in another mail. Sorry, I should have done this in the initial mail. > [...] Cu thl From jkeating at redhat.com Fri Nov 3 16:17:10 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Nov 2006 11:17:10 -0500 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B6A32.10309@leemhuis.info> References: <454B2300.8080900@leemhuis.info> <200611030937.02060.jkeating@redhat.com> <454B6A32.10309@leemhuis.info> Message-ID: <200611031117.10483.jkeating@redhat.com> On Friday 03 November 2006 11:11, Thorsten Leemhuis wrote: > I think we should plan a bit more into the future here (e.g. have some > rough goals for FC7 when FC6T3 [feature freeze] or FC6 get shipped or > shortly afterwards). Honestly (IMHO) that's a horrible time to start planning. A) it takes focus off the release we're trying to get out the door, and drowns out already noisy mailing lists that we're trying to gather test feedback with threads-o-doom about what joe user wants to see in the next release, and why bob user thinks the bike shed should be brown. B) nothing can be shown for the plan for a good long while as rawhide can't start taking these new plans C) folks doing the planning are usually pretty frazzled trying to get Test3 out and then cleaning up for the final -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Nov 3 16:20:41 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Nov 2006 11:20:41 -0500 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B672C.8070906@leemhuis.info> References: <454B2300.8080900@leemhuis.info> <200611031026.45750.jkeating@redhat.com> <454B672C.8070906@leemhuis.info> Message-ID: <200611031120.41588.jkeating@redhat.com> On Friday 03 November 2006 10:58, Thorsten Leemhuis wrote: > Nope (see below). Just for referece: Gnome always sips mid-march and > mid-september. Since quite some time now. And in order to pick up the latest gnome in a reasonable time our late march and late October releases weren't timed right? We want to get their latest into our test releases and rawhide to get SOME testing before we go out the door. How can this be any better? > > or more specifically they align their schedule to our releases most > > often. > > And that's why I think we should have a long term release planing like > Ubuntu and Gnome. We don't even have a schedule for FC7 currently, so > GCC or X.org are not able to align their schedule to our releases... Mostly because we don't know how long it will take to accomplish some of the things we want to do. We don't know what all we want to do this time around and what to punt for the next release. We're "assuming" roughly 6 months, but being strictly tied down by a date kind of sucks for what we want to accomplish this time around. > > Already stated why this is a very bad idea. ?You get a '2' in the name, > > and you get to look at all your broken extensions. ?Not fun. > > I'm not saying we need it now. But a good solution for it might be > "We'll ship FF 2.0 as a update for FC6 when it's a bit more matured and > most extensions are ported; so at the end of the year probably. Until > then you can get it in this special FC-6 add-on repo located on ours > servers at ...." How is this any different from what Chris Aillon did, with his FF2 builds made public? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Nov 3 16:22:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 03 Nov 2006 17:22:32 +0100 Subject: [fab] looking at our surrent state a bit In-Reply-To: <200611031100.08469.jkeating@redhat.com> References: <454B2300.8080900@leemhuis.info> <20061103134113.GB17328@nostromo.devel.redhat.com> <454B648B.9020205@leemhuis.info> <200611031100.08469.jkeating@redhat.com> Message-ID: <454B6CC8.4030001@leemhuis.info> Seems we talked at cross purposes a bit. Jesse Keating schrieb: > On Friday 03 November 2006 10:47, Thorsten Leemhuis wrote: >> I'm not saying we need FF 2 as a official update now. Get it out in one >> or two months when most extensions are fixed. Or put it in a special >> repo (as aiglx in FC5) and maintain it there for those interested. > So first you're complaining that FF2 wasn't made available for FC6, > and now you're saying it shouldn't be, I said it doesn't match "Fedora is about the rapid progress of Free and Open Source software and content." if Ubtuntu can ship with it two days later. Further: I think it is okay that it was not shipped. But we should explain the reasons to our users and give them a outlook like "We'll probably ship it as a update" > only when its ready, and that it should be > made available in a special repo for those to test. Yes. > I seem to remember Chris Aillon posting up FF2 rpms for FC6 systems They are tagged with "fc7". Most users will fear that. > a while > ago, and got all of some 50~ downloaders. He still feels its not ready for > FC6, but it is in rawhide. How is this NOT what you wanted to see? I would like to see FF at a place like http://download.fedora.redhat.com/pub/fedora/projects/ (not "only" on people") and with a repo file that people can easily install. CU thl From jkeating at redhat.com Fri Nov 3 16:34:56 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Nov 2006 11:34:56 -0500 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B6CC8.4030001@leemhuis.info> References: <454B2300.8080900@leemhuis.info> <200611031100.08469.jkeating@redhat.com> <454B6CC8.4030001@leemhuis.info> Message-ID: <200611031134.56960.jkeating@redhat.com> On Friday 03 November 2006 11:22, Thorsten Leemhuis wrote: > I said it doesn't match "Fedora is about the rapid progress of Free and > Open Source software and content." if Ubtuntu can ship with it two days > later. And if we shipped it, we wouldn't match the perception that we actually care about our users... We could certainly ship software the day or the day after its released, if we just don't care what it would do to users systems... > > Further: I think it is okay that it was not shipped. But we should > explain the reasons to our users and give them a outlook like "We'll > probably ship it as a update" Did you not follow the threads that caillon participated in? > > > only when its ready, and that it should be > > made available in a special repo for those to test. > > Yes. > > > I seem to remember Chris Aillon posting up FF2 rpms for FC6 systems > > They are tagged with "fc7". Most users will fear that. As well they should. Any user that would be 'scared' of an fc7 tag should probably avoid testing it anyway. > > > a while > > ago, and got all of some 50~ downloaders. ?He still feels its not ready > > for FC6, but it is in rawhide. ?How is this NOT what you wanted to see? > > I would like to see FF at a place like > http://download.fedora.redhat.com/pub/fedora/projects/ > (not "only" on people") and with a repo file that people can easily > install. Which makes it even harder to provide one-off testing packages, and thus makes it even LESS interesting for maintainers to do. No, I think not. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Nov 3 17:12:03 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 03 Nov 2006 18:12:03 +0100 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B66CC.4010405@fedoraproject.org> References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> <454B66CC.4010405@fedoraproject.org> Message-ID: <454B7863.4060308@leemhuis.info> Rahul Sundaram schrieb: > Thorsten Leemhuis wrote: >> Rahul Sundaram schrieb: >>> Thorsten Leemhuis wrote: >>>> * it's not that much present -- we know it exists, but that's often all. >>>> * seems to meet quite seldom and it's hard to see what it does or if >>>> there even is progress somewhere >>> We havent had a meeting in the last few weeks due to the release work >>> and other things but whenever there is one, the agenda is posted here >>> and post meeting results are available in the wiki and send to >>> fedora-announce list. >>> http://fedoraproject.org/wiki/Board/Meetings/ >>> What else could be done? >> IMHO: Meet more often. Get more involved into decisions. Show presence. > Please be more detailed. How often do you want the board to meet? The plan was to meet all two weeks IIRC. I think that should suffice if it would be held in. Maybe "meet once or twice a month on IRC, and once per month on phone" would be even better. > Many > of the people in the board are going to be involved with other work > during a new release. Sure. but both things are important. > For the rest of us, its volunteer work. Well, Extras and many other community driven projects are able to meet once a week. It works quite well there afaics. > What > does getting more involved into decisions and more presence involve? Comment/Issue a statement on the Legacy problem that was discussed on LWN. Solve the RPM issue. Look at what discussion/topics took quite a bit of attention on the important Fedora lists and in the news > Like I said the meeting agenda and mins are already public. Where is the agenda for the next meeting? Or a schedule similar to the one FESCo has ( http://www.fedoraproject.org/wiki/Extras/Schedule ) so people interested in the work can look at the current status? Further take a look at http://www.fedoraproject.org/wiki/Board/Meetings {{{ Upcoming meetings: * October 3 (10:00 AM EDT, 2:00 PM GMT) * October 17 (5:00 PM EDT, 9:00 PM GMT) }}} Great work! (Sorry, but what shall I say) >> Well, phone meetings are okay. That's why I suggested "now and then meet >> on irc" -- then everyone can get in contact with the board now and then >> while it can still get work done. That gets rid of the "secret cabal" >> look that some outsiders might have. > See above. There is nothing preventing anyone from discussing the > results when the meeting mins or agenda are posted. "Participating in a meeting" and "looking at the results" are two different things. > [...] > To understand this better, ask yourself how many people not involved > with FESCo would actually sit in FESCo meetings Round about as many as FESCo members participate actively in hte meeting. > and express their opinions Normally they are quiet most of the time. But they raise their voice if they think that's needed or if it's an area where they are working. That works quite well. > or would you even want to listen to such opinions We do. Why shouldn't we? > at that time instead of doing it on the list? Well, why meet then in any case? Because it does not work. So we meet on IRC. But why should we lock the community out there? That would be stupid. Sure, there may be discussions that need to be held in private, but that doesn't happen that often (and if, on the private fesco-list). Sure, running the meetings will get hard if to many non-FESCo members raise their voice, but we didn't hit that problem yet -- and if that problem comes up we'll solve it in a way where we still can hear the opinion of the community.. >> Yes and no -- The team does a good job, but looking back it took quite >> some time until anaconda was capable of using Extras during install. To >> long IMHO. Installing packages from CD/DVD also is still lacking. > It is a lot of work to change Anaconda to support custom repositories. I > am sure more contributors are welcome. Well, contributing to core is still hard afaics. >> I know, and Jesse, Jeremy, Bill and the others are doing great work, but >> their days are only 24 hours long, too (and their work days are limited, >> too). > A call for more volunteers to join the team was send out to > fedora-announce list. You can look at wiki pages at > http://fedoraproject.org/wiki/Infrastructure and contact the relevant > people to help out in any of the work. Progress is already documented > there to a good extend. Yeah, I'll consider that. thx for the pointer. >>> Official CD releases are unfortunately taking a longer time but >>> if various sub projects would require Red Hat developers to work on >>> them that would essential mean we would have to prioritize the work. >> Exactly that's what I'd like to see. > That's already happening. If Red Hat has to get involved with all these > projects to make changes happen, where would that leave Fedora as a > community project? Well, we're getting rhetorical here. For me it looks like that: Red Hat failed to get the community involved properly/to build one up and thus contributors wandered of elsewhere. Those stupid contributors like me that work for Fedora in their free time are busy with a lot of stuff already and don't have time to work on more stuff. >> Not sure, I'm not a marketing guy. But we need to communicate better >> that we're nearly as free as Debian (here and there we are worse, in >> other areas we are better afaics). Most people don't know that afaics. > Where are we worse? Well, some people might say that as we ship firmware packages in our kernel. > I dont think this is a problem of users not > recognizing that Fedora is Free software but many not seeing the value > of that. Agreed. > Ideas welcome. Hmm, I don't have one just now. I'll think about it, maybe something springs to my mind. >>> That's the essence of free software. >> I know that, but it seems you didn't understand what I was up to. > No I dont obviously. Please explain. Take Gnome 2.12 as example: I'm sure many Red Hat developers worked quite hard on it and got some quite nice improvements into it. But we never shipped it in Fedora Core. Ubuntu and Suse did and took the glory for it. Just to repeat from my initial mail: I like it very much that Red Hat/Fedora works directly on upstream so close. That's why I'm contributing to Fedora. But we should not forget to improve our features that are special in our product (Live-CD, anaconda, initscripts, ...) over that. And that's what I think we're doing a bit these days. >> No, I think we should align out schedule to Gnome, as it is a crucial >> part of our product. > Oh come on. Fedora is already very well aligned with the GNOME release > schedules. See my other mail. Currently we are again, but will we stick with that for FC7 and FC8. Remember, we missed a whole Gnome release between FC4 and FC5! >> Xorg: yes. The updates improve hardware support and are often needed to >> get the latest Hardware running. And that's why I think why we should >> ship them often (still needs to be decided on a case by case basis). > I dont think shipping Xorg major releases as updates is a good idea now. > We should avoid that IMO. We should give users a chance to run their hardware they buy (even if that hardare was brought to the market after FCx) -- and the drivers for that sometimes require newer X.org releases, while the next FC with that new X.org version might still be far away. So what do you suggest to those users? Run Windows? Run Rawhide? >> Sure. That's not what I proposed. But if there are important things >> missing (FF 2.0 in FC6; AIGLX in FC5, Gnome Update in FC4) then try to >> get a solution that makes installing those software possible easily (the >> AIGLX on FC5 was more a disaster because it was poorly maintained). > AIGLX on FC5 was not installed by default. It was a *experimental* > separate repository that users had to go and install by themselves. And that did not work often as updates from core confused it multiple times. >[ripping firefox aside, see mails to jesse] > > Major updates of GNOME post release as updates falls into the same "too > risky" category as Xorg updates for me. Agreed. But I think FC4 should have get one, or FC5 should have shipped way earlier. > Unlike KDE which is mostly > encapsulated within itself, GNOME depends on more "system bits" like HAL > and DBus etc. Now KDE has started using these too and I would wary of > decisions to do major updates on this. Agreed. >> I had something like FESCo im mind. E.g. more members (maybe even from >> outside of RH), public meetings, summaries to the list. > Having core as a Red Hat maintainer repository while having non-RH > people in the steering committee doesnt really have any significant > impact. Ignoring the opinion from the community won't help building a community around Fedora. > What we are working on is fundamentally changing this idea by > getting rid of the core/extras wall which requires infrastructure > changes that is being done. And I like that :) >> Yeah, warren mentioned something during yesterdays meeting. But it took >> quite some time and that's the biggest problem in Fedora -- everything >> takes a long time. > This is very broad generalization. I think that's how it looks often from the outside. Remembers Fedora Extras? It took quite some time after the fedora.us/Red Hat Linux Project merger until it took of (one and a half year iirc). > Having you looked at the work being > done in Fedora Directory Server since it was open sourced? For a long > time FDS itself was open source but required the Sun JVM to work. That > means we couldnt have included it in Fedora. It wouldnt have o past the > review stage if that was initiated since it deviated widely from the > packaging guidelines we have setup. Okay, maybe I was barking at the wrong tree here. Sorry. Thanks all the FDS developers for their great work (and Red Hat for open sourcing it). > [...] CU thl From bugs.michael at gmx.net Fri Nov 3 17:22:51 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 3 Nov 2006 18:22:51 +0100 Subject: comps.xml (Re: [fab] looking at our current state a bit) In-Reply-To: <454B5D52.1000406@fedoraproject.org> References: <454B2300.8080900@leemhuis.info> <20061103144936.9e5f4c86.bugs.michael@gmx.net> <200611030817.23282.dennis@ausil.us> <20061103154446.a717a8db.bugs.michael@gmx.net> <454B5D52.1000406@fedoraproject.org> Message-ID: <20061103182251.6314ec3f.bugs.michael@gmx.net> On Fri, 03 Nov 2006 20:46:34 +0530, Rahul Sundaram wrote: > > MS> Are logs of the relevant bits available? So, public, but not > > MS> really open. > > > > Man, that's petty. Nah, it's not. Sometimes--as in this case--it really makes sense to admit that communication could have been much better. Or do you appreciate quotes like this? | (Extras didn't manage to push a proper | comps.xml in time -- shame on us) Not even a manual update, and that is really a surprise. The first step would have been to talk about any roadblocks _prior_ to FC6. > Not really. He has a point. If Fedora Infrastructure team has been > having regular meetings, then posting the logs/meeting mins would be > quite useful. However the meeting is done in a public channel and the > important results are already in the wiki. Slowly. I'm not talking about meetings. I'm talking about FESCo related development communication that takes place in private or semi-public places only. If more such communication is hidden from the eyes of community observers, it becomes even more difficult to help or to learn what is missing. Please don't expect contributors to hunt for relevant bits in IRC. Apparently, it's not even clear whether this action item belongs to FESCo or Infrastructure. ;) comps.xml is listed as an action item on FESCo's schedule. Searching the relevant mailing-lists has not turned up anything about it that would be equal to a status update. It's amusing that I'm supposed to either monitor two IRC channels 24/7 or ask many question before somebody might hand out a copy of the channel logs. Asking on fedora-extras-list for a status update was close to fruitless as could be experienced a few days ago. Anyway, meanwhile, as a result of this thread, I've received a status update via mail. We'll continue there. From fedora at leemhuis.info Fri Nov 3 17:24:48 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 03 Nov 2006 18:24:48 +0100 Subject: [fab] looking at our surrent state a bit In-Reply-To: <200611031117.10483.jkeating@redhat.com> References: <454B2300.8080900@leemhuis.info> <200611030937.02060.jkeating@redhat.com> <454B6A32.10309@leemhuis.info> <200611031117.10483.jkeating@redhat.com> Message-ID: <454B7B60.5080303@leemhuis.info> Jesse Keating schrieb: > On Friday 03 November 2006 11:11, Thorsten Leemhuis wrote: >> I think we should plan a bit more into the future here (e.g. have some >> rough goals for FC7 when FC6T3 [feature freeze] or FC6 get shipped or >> shortly afterwards). > Honestly (IMHO) that's a horrible time to start planning. For Ubuntu it seems fine: They started gathering ideas right away when they released 6.10 > A) it takes focus off the release we're trying to get out the door, Well, I assume at lest some packagers will have their packages in a good shape already by FCxT3. Those could work on FC(x+1) internally already. > and drowns > out already noisy mailing lists that we're trying to gather test feedback > with threads-o-doom about what joe user wants to see in the next release, and > why bob user thinks the bike shed should be brown. Well, we have different lists for it, but don't enforce that. We should IMHO. > B) nothing can be shown for the plan for a good long while as rawhide can't > start taking these new plans We could start opening up rawhide a bit earlier (e.g. when the final FCx was build). But yes, I agree here round about. > C) folks doing the planning are usually pretty frazzled trying to get Test3 > out and then cleaning up for the final Agreed. That's btw one of the reasons why I started this thread: We IMHO need more of those folks "doing the planning and finishing the release". Cu thl From fedora at leemhuis.info Fri Nov 3 17:40:54 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 03 Nov 2006 18:40:54 +0100 Subject: [fab] looking at our surrent state a bit In-Reply-To: <200611031120.41588.jkeating@redhat.com> References: <454B2300.8080900@leemhuis.info> <200611031026.45750.jkeating@redhat.com> <454B672C.8070906@leemhuis.info> <200611031120.41588.jkeating@redhat.com> Message-ID: <454B7F26.70309@leemhuis.info> Jesse Keating schrieb: > On Friday 03 November 2006 10:58, Thorsten Leemhuis wrote: >> Nope (see below). Just for referece: Gnome always sips mid-march and >> mid-september. Since quite some time now. > And in order to pick up the latest gnome in a reasonable time our late march > and late October releases weren't timed right? They would, if we would stick to them: FC1 -- 5 November 2003 - General Availability FC2 -- 18 May 2004 - General Availability FC3 -- 8 November 2004 - General Availability FC4 -- 13 June 2005 - General Availability FC5 -- 20 March 2006 - General Availability FC6 -- 24 October 2006 - General Availability Late march only once. I asked after FC5 on fedora-devel if we would stick to "late march and late September" in the future again (+ some delays if needed) and the answer was "no". But if we get our release to "round about late march and late September" in the future I'd be very glad. >>> or more specifically they align their schedule to our releases most >>> often. >> And that's why I think we should have a long term release planing like >> Ubuntu and Gnome. We don't even have a schedule for FC7 currently, so >> GCC or X.org are not able to align their schedule to our releases... > Mostly because we don't know how long it will take to accomplish some of the > things we want to do. We don't know what all we want to do this time around > and what to punt for the next release. We're "assuming" roughly 6 months, > but being strictly tied down by a date kind of sucks for what we want to > accomplish this time around. I think we should have a slightly more long-term plans. Sure, If release X needs a delay, let's delay it a bit. But that should not effect X+1 to much. >>> Already stated why this is a very bad idea. You get a '2' in the name, >>> and you get to look at all your broken extensions. Not fun. >> I'm not saying we need it now. But a good solution for it might be >> "We'll ship FF 2.0 as a update for FC6 when it's a bit more matured and >> most extensions are ported; so at the end of the year probably. Until >> then you can get it in this special FC-6 add-on repo located on ours >> servers at ...." > How is this any different from what Chris Aillon did, with his FF2 builds made > public? - was not announced in the public (or I missed it) - there is no "we probably ship it as update soon (when it's ready)" Cu thl From sundaram at fedoraproject.org Fri Nov 3 17:50:16 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 03 Nov 2006 23:20:16 +0530 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B7F26.70309@leemhuis.info> References: <454B2300.8080900@leemhuis.info> <200611031026.45750.jkeating@redhat.com> <454B672C.8070906@leemhuis.info> <200611031120.41588.jkeating@redhat.com> <454B7F26.70309@leemhuis.info> Message-ID: <454B8158.8030000@fedoraproject.org> Thorsten Leemhuis wrote: >> How is this any different from what Chris Aillon did, with his FF2 builds made >> public? > > - was not announced in the public (or I missed it) Not sure what you mean public. It was in his blog and discussed in fedora-devel list. > - there is no "we probably ship it as update soon (when it's ready)" > He said he wont and will push out Firefox 3.0 in fedora-devel list. Rahul From jkeating at redhat.com Fri Nov 3 17:52:41 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Nov 2006 12:52:41 -0500 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B7F26.70309@leemhuis.info> References: <454B2300.8080900@leemhuis.info> <200611031120.41588.jkeating@redhat.com> <454B7F26.70309@leemhuis.info> Message-ID: <200611031252.42065.jkeating@redhat.com> On Friday 03 November 2006 12:40, Thorsten Leemhuis wrote: > Late march only once. I asked after FC5 on fedora-devel if we would > stick to "late march and late September" in the future again (+ some > delays if needed) and the answer was "no". > > But if we get our release to "round about late march and late September" > in the future I'd be very glad. It's something we shoot for, but flexibility is necessary for what we do. > >>> or more specifically they align their schedule to our releases most > >>> often. > >> > >> And that's why I think we should have a long term release planing like > >> Ubuntu and Gnome. We don't even have a schedule for FC7 currently, so > >> GCC or X.org are not able to align their schedule to our releases... > > > > Mostly because we don't know how long it will take to accomplish some of > > the things we want to do. ?We don't know what all we want to do this time > > around and what to punt for the next release. ?We're "assuming" roughly 6 > > months, but being strictly tied down by a date kind of sucks for what we > > want to accomplish this time around. > > I think we should have a slightly more long-term plans. Sure, If release > X needs a delay, let's delay it a bit. But that should not effect X+1 to > much. So screw the next development cycle because we had some problems in the current one? I'd rather not. > >>> Already stated why this is a very bad idea. ?You get a '2' in the name, > >>> and you get to look at all your broken extensions. ?Not fun. > >> > >> I'm not saying we need it now. But a good solution for it might be > >> "We'll ship FF 2.0 as a update for FC6 when it's a bit more matured and > >> most extensions are ported; so at the end of the year probably. Until > >> then you can get it in this special FC-6 add-on repo located on ours > >> servers at ...." > > > > How is this any different from what Chris Aillon did, with his FF2 builds > > made public? > > - was not announced in the public (or I missed it) I'm pretty sure it hit his blog and one of the fedora lists. > - there is no "we probably ship it as update soon (when it's ready)" Because promises suck. If we determine that FF2 just breaks things too badly we might not ever ship it as an update. Making a promise to or even a hint to sets an expectation we may not want to meet. (and it's a maintainer question mostly) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Nov 3 18:02:18 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Nov 2006 13:02:18 -0500 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B7B60.5080303@leemhuis.info> References: <454B2300.8080900@leemhuis.info> <200611031117.10483.jkeating@redhat.com> <454B7B60.5080303@leemhuis.info> Message-ID: <200611031302.25413.jkeating@redhat.com> On Friday 03 November 2006 12:24, Thorsten Leemhuis wrote: > For Ubuntu it seems fine: They started gathering ideas right away when > they released 6.10 That's great for them. Was it Canonical folks, or idle chatter from the Ubuntu community and somebody tossed up a wiki page with wish lists? > > A) it takes focus off the release we're trying to get out the door, > > Well, I assume at lest some packagers will have their packages in a good > shape already by FCxT3. Those could work on FC(x+1) internally already. And when there is no 'internal' ? What sucked this time around was RHEL5. There are still lots of bugs being found in RHEL5 testing, causing fixes to be spun there, in FC6 land and in rawhide land. So we didn't really have idle core developers. Next time around, who knows. However next time around may prove to be a completely different beast anyway, what with the potential merger. > > > and drowns > > out already noisy mailing lists that we're trying to gather test feedback > > with threads-o-doom about what joe user wants to see in the next release, > > and why bob user thinks the bike shed should be brown. > > Well, we have different lists for it, but don't enforce that. We should > IMHO. So you create a new list and hope people follow you there, or you cut folks off and have a psuedo private discussion and then get beat up for not having it on more 'open' lists (IE where more people are). I'm not convinced that more lists are the answer. > > > B) nothing can be shown for the plan for a good long while as rawhide > > can't start taking these new plans > > We could start opening up rawhide a bit earlier (e.g. when the final FCx > was build). But yes, I agree here round about. maybe, however that would break folks currently on rawhide or Test3 releases waiting for the final to 'upgrade'. Tradeoff at the end user's expense. > > > C) folks doing the planning are usually pretty frazzled trying to get > > Test3 out and then cleaning up for the final > > Agreed. That's btw one of the reasons why I started this thread: We IMHO > need more of those folks "doing the planning and finishing the release". Unfortunately most of those that can do something with the planning are the same ones doing the releasing. I don't think more people is the answer here either, rather better timing of the planning vs the releasing. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Nov 3 18:32:13 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Nov 2006 00:02:13 +0530 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B7863.4060308@leemhuis.info> References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> <454B66CC.4010405@fedoraproject.org> <454B7863.4060308@leemhuis.info> Message-ID: <454B8B2D.2010909@fedoraproject.org> Thorsten Leemhuis wrote: > The plan was to meet all two weeks IIRC. I think that should suffice if > it would be held in. It has been. It was not during FC6 release time because people in the board were involved in it. Thats all. > >> What >> does getting more involved into decisions and more presence involve? > > Comment/Issue a statement on the Legacy problem that was discussed on > LWN. It was discussed in detail that evolved into a discussion about funds. The details would be made public when things evolve further. > > Where is the agenda for the next meeting? Or a schedule similar to the > one FESCo has ( http://www.fedoraproject.org/wiki/Extras/Schedule ) so > people interested in the work can look at the current status? I will set that up. > > Further take a look at > http://www.fedoraproject.org/wiki/Board/Meetings > {{{ > Upcoming meetings: > * October 3 (10:00 AM EDT, 2:00 PM GMT) > * October 17 (5:00 PM EDT, 9:00 PM GMT) > }}} > > Great work! (Sorry, but what shall I say) This was the original plans and it has been postponed due to release work as stated already. I prefer that interval to stay as it is rather than complete wipe it out. > > "Participating in a meeting" and "looking at the results" are two > different things. You can discuss the results in the list. I dont see any functional difference. I prefer the list before it makes it easier for a wider community to respond without sitting on the channel at the same time. > > Normally they are quiet most of the time. But they raise their voice if > they think that's needed or if it's an area where they are working. That > works quite well. I read FESCo meeting mins everytime and I dont see many non FESCo members actively participating or commenting in between meetings. > > Well, why meet then in any case? Because it does not work. So we meet on > IRC. The meeting is for FESCo members. If non FESCo members start actively participating and expressing their opinions on the channels then it would become tiresome pretty soon. If you want to hear opinions of the larger community its better to do that on the list instead of in between the meeting which can be done in this list for the board meetings. > But why should we lock the community out there? That would be stupid. That is exactly how FESCo meetings were held before. This doesnt lock out community if the meetings results are published regularly and can be dicussed in the lists. > Sure, there may be discussions that need to be held in private, but that > doesn't happen that often (and if, on the private fesco-list). If we force ourselves to have public discussions everytime, we wont be able to discuss things freely effectively. Some things are better off discuss between people offlist or in a private list or meeting. Board discussions are usually of this nature and I believe many people prefer talking on phone to IRC. tend to identify nicknames in IRC better than voices on phone and I am much better on email personally though. > Well, contributing to core is still hard afaics. You can very easily send patches and participate in anaconda-list if you have any interest in contributing. This is not a reason why people are not contributing. The only thing limited currently is packaging. > > Well, we're getting rhetorical here. For me it looks like that: Red Hat > failed to get the community involved properly/to build one up and thus > contributors wandered of elsewhere. Those stupid contributors like me > that work for Fedora in their free time are busy with a lot of stuff > already and don't have time to work on more stuff. I guess we could speculate on the reasons but active development didnt happen. A good way to actual fix things would be get involved. Live CD is very much a priority for us in the current development release cycle. If this involves getting someone in Red Hat to do that everytime, that might slow down progress. > >>> Not sure, I'm not a marketing guy. But we need to communicate better >>> that we're nearly as free as Debian (here and there we are worse, in >>> other areas we are better afaics). Most people don't know that afaics. >> Where are we worse? > > Well, some people might say that as we ship firmware packages in our kernel. So does Debian. > > Take Gnome 2.12 as example: I'm sure many Red Hat developers worked > quite hard on it and got some quite nice improvements into it. But we > never shipped it in Fedora Core. Ubuntu and Suse did and took the glory > for it. I would prefer we discuss things on the terms of Fedora rather go into a competitive comparison. Yes, sometimes GNOME or Firefox or Xorg or KDE would do a release in the middle of Fedora development which we wont be able to accommodate. People would have to wait for the next release if they want that. We might skip releases and pick the next one. When upstream projects work in a distributed fashion, it is inevitable that some project or the other wont be coordinated with Fedora. This is not news. > > We should give users a chance to run their hardware they buy (even if > that hardare was brought to the market after FCx) -- and the drivers for > that sometimes require newer X.org releases, while the next FC with that > new X.org version might still be far away. So what do you suggest to > those users? Run Windows? Run Rawhide? Wait for the next release. We wont be pushing everything as updates. We need to maintain quality for the release and updates. Major updates of a new release of GNOME have higher chances of regressions when pushed out as updates. > >>> Sure. That's not what I proposed. But if there are important things >>> missing (FF 2.0 in FC6; AIGLX in FC5, Gnome Update in FC4) then try to >>> get a solution that makes installing those software possible easily (the >>> AIGLX on FC5 was more a disaster because it was poorly maintained). >> AIGLX on FC5 was not installed by default. It was a *experimental* >> separate repository that users had to go and install by themselves. > > And that did not work often as updates from core confused it multiple times. Sure. There is a reason it is called experimental. If it worked reasonably well, it would have been part of the release instead of a add on repository. >> [ripping firefox aside, see mails to jesse] >> >> Major updates of GNOME post release as updates falls into the same "too >> risky" category as Xorg updates for me. > > Agreed. But I think FC4 should have get one, or FC5 should have shipped > way earlier. If a major release of Xorg follows 3 months after GNOME with a Fedora release somewhere in between we wouldnt be able to accomodate all these in the same release and not within updates either. They would have wait for the next release. > Ignoring the opinion from the community won't help building a community > around Fedora. We are trying to solve the bigger problem instead. >> This is very broad generalization. > > I think that's how it looks often from the outside. Remembers Fedora > Extras? It took quite some time after the fedora.us/Red Hat Linux > Project merger until it took of (one and a half year iirc). Yes and that got fixed only because some people in the community decided to act on it and do something about it themselves. Thats what we need more of. Rahul From stickster at gmail.com Fri Nov 3 18:53:13 2006 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 03 Nov 2006 13:53:13 -0500 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B7863.4060308@leemhuis.info> References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> <454B66CC.4010405@fedoraproject.org> <454B7863.4060308@leemhuis.info> Message-ID: <1162579993.4361.34.camel@localhost.localdomain> (My own thoughts, not a mass Board opinion, follow. In case it's not perfectly clear, others on the Board may disagree.) On Fri, 2006-11-03 at 18:12 +0100, Thorsten Leemhuis wrote: > Rahul Sundaram schrieb: > > Thorsten Leemhuis wrote: > >> Rahul Sundaram schrieb: > >>> Thorsten Leemhuis wrote: > >>>> * it's not that much present -- we know it exists, but that's often all. > >>>> * seems to meet quite seldom and it's hard to see what it does or if > >>>> there even is progress somewhere > >>> We havent had a meeting in the last few weeks due to the release work > >>> and other things but whenever there is one, the agenda is posted here > >>> and post meeting results are available in the wiki and send to > >>> fedora-announce list. > >>> http://fedoraproject.org/wiki/Board/Meetings/ > >>> What else could be done? > >> IMHO: Meet more often. Get more involved into decisions. Show presence. > > Please be more detailed. How often do you want the board to meet? > > The plan was to meet all two weeks IIRC. I think that should suffice if > it would be held in. > > Maybe "meet once or twice a month on IRC, and once per month on phone" > would be even better. Not even corporate boards meet so rigorously that there aren't cancellations or schedule changes sometimes. This is a volunteer organization. We meet twice a month if at all possible. And IRC meetings are a complete dud for a governing board like this one, IYAM, for at least, but not limited to, the following reasons: (1) Not every discussion is appropriate for sending over public airwaves. This is why real-life boards also have executive sessions; it's a good management practice and there's nothing shady about it. (2) With a smaller group of very busy individuals, it's too easy for conversation to lag on the computer. Our meetings are able to cover a great deal of material in just an hour, without wandering too much, because people are more engaged in the social connection of conversation. (3) Members can attend any meeting even if not jacked into their computer. (Insert mental image of USB cable dangling from eye/ear sockets.) > > Many > > of the people in the board are going to be involved with other work > > during a new release. > > Sure. but both things are important. No one's denying that, but making the schedule more rigorous doesn't necessarily improve the Board's efficiency. Flexibility is good. > > For the rest of us, its volunteer work. > > Well, Extras and many other community driven projects are able to meet > once a week. It works quite well there afaics. For larger scale governance and direction issues, that's too often. It would limit the amount of work that Board members can do between meetings, some of which has to be driven to external entities and appropriate time allowed for doing the work. More progress reports simply for reporting's sake is not a good use of people's time. [...snip...] > Where is the agenda for the next meeting? Or a schedule similar to the > one FESCo has ( http://www.fedoraproject.org/wiki/Extras/Schedule ) so > people interested in the work can look at the current status? > > Further take a look at > http://www.fedoraproject.org/wiki/Board/Meetings > {{{ > Upcoming meetings: > * October 3 (10:00 AM EDT, 2:00 PM GMT) > * October 17 (5:00 PM EDT, 9:00 PM GMT) > }}} > > Great work! (Sorry, but what shall I say) These cancellations happened for a variety of reasons, but chief among them were the impending release and various scrambles associated therewith. I'm not sure why you assume that a meeting cancellation means we weren't doing any work, but I can assure you sincerely that's not the case. > >> Well, phone meetings are okay. That's why I suggested "now and then meet > >> on irc" -- then everyone can get in contact with the board now and then > >> while it can still get work done. That gets rid of the "secret cabal" > >> look that some outsiders might have. > > See above. There is nothing preventing anyone from discussing the > > results when the meeting mins or agenda are posted. > > "Participating in a meeting" and "looking at the results" are two > different things. The Board's meetings are not an appropriate place for mass public participation. And since there's no way to invite just some people and not all of them without creating a further controversy, don't expect it to happen any time in the near future. This probably sounds very arrogant from anyone who is a non-elected Board member (as I and every other member was), but I would hope this will not change after the FC7-ish Board elections. USA-centric analogy: If every citizen was entitled to speak in congressional committee hearings, I guarantee their efficiency would be reduced. Every single Fedora mailing list is a venue for public participation, and between all the members here, I feel pretty confident saying we have all of them under watch. We don't ignore important issues, but we also try to avoid elevating more granular issues to our agenda. That's what the subproject steering committees do, and they all seem to do a darn good job of addressing same. [...snip...] > Sure, there may be discussions that need to be held in private, but that > doesn't happen that often (and if, on the private fesco-list). That's not the case for the Board. [...snip...] > >>> Official CD releases are unfortunately taking a longer time but > >>> if various sub projects would require Red Hat developers to work on > >>> them that would essential mean we would have to prioritize the work. > >> Exactly that's what I'd like to see. > > That's already happening. If Red Hat has to get involved with all these > > projects to make changes happen, where would that leave Fedora as a > > community project? > > Well, we're getting rhetorical here. For me it looks like that: Red Hat > failed to get the community involved properly/to build one up and thus > contributors wandered of elsewhere. Those stupid contributors like me > that work for Fedora in their free time are busy with a lot of stuff > already and don't have time to work on more stuff. This doesn't make a lot of sense to me. You're unhappy that a certain project hasn't progressed, but you don't have time to work on it. That will always be the case for everyone who likes to see advancement on every front. I have the exact same problem as a Docs contributor -- there are other things not getting done as well as I would like, but I don't think of myself as "stupid" because they're lagging. And neither should you. Your urge to keep advancing Fedora is very admirable; don't let your momentum get sidetracked -- nobody can do everything, that's why we're a community. The Board has already looked at this particular issue, and when we find large-scale project gaps, we will continue to do just that. Making a blanket rule that Red Hat is responsible for starting any worthwhile effort gives short shrift to the community efforts that have driven themselves from the beginning. If we can't get enough skilled people working on projects that involve actual coding, that is a different issue, certainly worth discussing. Anyway, thanks for your comments Thorsten, and for listening to my $0.02. It's good to have these discussions even if they cause some disagreements -- we all want the same thing at the end, which is a strong, healthy, and vibrant community for advancing FOSS. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Fri Nov 3 19:08:41 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 03 Nov 2006 20:08:41 +0100 Subject: [fab] looking at our surrent state a bit In-Reply-To: <200611031302.25413.jkeating@redhat.com> References: <454B2300.8080900@leemhuis.info> <200611031117.10483.jkeating@redhat.com> <454B7B60.5080303@leemhuis.info> <200611031302.25413.jkeating@redhat.com> Message-ID: <454B93B9.6090600@leemhuis.info> Jesse Keating schrieb: > On Friday 03 November 2006 12:24, Thorsten Leemhuis wrote: >> For Ubuntu it seems fine: They started gathering ideas right away when >> they released 6.10 > That's great for them. Was it Canonical folks, or idle chatter from the > Ubuntu community and somebody tossed up a wiki page with wish lists? http://lwn.net/Articles/204961/ From: Mark Shuttleworth Subject: Planning for Ubuntu 7.04 - the "Feisty Fawn" >>> A) it takes focus off the release we're trying to get out the door, >> Well, I assume at lest some packagers will have their packages in a good >> shape already by FCxT3. Those could work on FC(x+1) internally already. > And when there is no 'internal'? There is always "local" > What sucked this time around was RHEL5. I know. > There are still lots of bugs being found in RHEL5 testing, causing fixes to > be spun there, in FC6 land and in rawhide land. So we didn't really have > idle core developers. Yeah, okay -- but maybe you'd had community interest in things if you would give the community a chance to get participate in time? Tha what we all want afaics. > Next time around, who knows. However next time around > may prove to be a completely different beast anyway, what with the potential > merger. >>> and drowns >>> out already noisy mailing lists that we're trying to gather test feedback >>> with threads-o-doom about what joe user wants to see in the next release, >>> and why bob user thinks the bike shed should be brown. >> Well, we have different lists for it, but don't enforce that. We should >> IMHO. > So you create a new list I didn't propose a new list. You did. > and hope people follow you there, or you cut folks > off and have a psuedo private discussion and then get beat up for not having > it on more 'open' lists (IE where more people are). I'm not convinced that > more lists are the answer. As I said: I didn't propose new lists. fedora-devel was always meant for devel discussions; issues with rawhide where always meant to be discussed on fedora-test-list iirc. We just don't enforce that. We even stopped to communcate that to the people. >>> B) nothing can be shown for the plan for a good long while as rawhide >>> can't start taking these new plans >> We could start opening up rawhide a bit earlier (e.g. when the final FCx >> was build). But yes, I agree here round about. > maybe, however that would break folks currently on rawhide or Test3 releases > waiting for the final to 'upgrade'. Tradeoff at the end user's expense. Agreed. >>> C) folks doing the planning are usually pretty frazzled trying to get >>> Test3 out and then cleaning up for the final >> Agreed. That's btw one of the reasons why I started this thread: We IMHO >> need more of those folks "doing the planning and finishing the release". > Unfortunately most of those that can do something with the planning are the > same ones doing the releasing. I don't think more people is the answer here > either, rather better timing of the planning vs the releasing. Well, yes, maybe that's a solution, too. Cu thl From fedora at leemhuis.info Fri Nov 3 19:11:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 03 Nov 2006 20:11:32 +0100 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B8158.8030000@fedoraproject.org> References: <454B2300.8080900@leemhuis.info> <200611031026.45750.jkeating@redhat.com> <454B672C.8070906@leemhuis.info> <200611031120.41588.jkeating@redhat.com> <454B7F26.70309@leemhuis.info> <454B8158.8030000@fedoraproject.org> Message-ID: <454B9464.1040501@leemhuis.info> Rahul Sundaram schrieb: > Thorsten Leemhuis wrote: >>> How is this any different from what Chris Aillon did, with his FF2 builds made >>> public? >> - was not announced in the public (or I missed it) > Not sure what you mean public. I'd prefer fedora-annouce-list for such stuff. > It was in his blog and discussed in fedora-devel list. Probably not enough for a lot of people. >> - there is no "we probably ship it as update soon (when it's ready)" > He said he wont and will push out Firefox 3.0 in fedora-devel list. FF 3.0 will likely ship after FC7 afaik. That's probably much to late. Cu thl From sundaram at fedoraproject.org Fri Nov 3 19:16:47 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Nov 2006 00:46:47 +0530 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B9464.1040501@leemhuis.info> References: <454B2300.8080900@leemhuis.info> <200611031026.45750.jkeating@redhat.com> <454B672C.8070906@leemhuis.info> <200611031120.41588.jkeating@redhat.com> <454B7F26.70309@leemhuis.info> <454B8158.8030000@fedoraproject.org> <454B9464.1040501@leemhuis.info> Message-ID: <454B959F.6070705@fedoraproject.org> Thorsten Leemhuis wrote: > Rahul Sundaram schrieb: >> Thorsten Leemhuis wrote: >>>> How is this any different from what Chris Aillon did, with his FF2 builds made >>>> public? >>> - was not announced in the public (or I missed it) >> Not sure what you mean public. > > I'd prefer fedora-annouce-list for such stuff. Such experimental builds shouldnt really go into fedora-announce list. However the common issues page which I announced to that list already has the link which explains the current status. > > FF 3.0 will likely ship after FC7 afaik. That's probably much to late. > I am sure the Firefox maintainer is aware of the schedule. Rahul From jwboyer at jdub.homelinux.org Fri Nov 3 19:18:04 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 03 Nov 2006 13:18:04 -0600 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B8B2D.2010909@fedoraproject.org> References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> <454B66CC.4010405@fedoraproject.org> <454B7863.4060308@leemhuis.info> <454B8B2D.2010909@fedoraproject.org> Message-ID: <1162581484.11259.10.camel@zod.rchland.ibm.com> On Sat, 2006-11-04 at 00:02 +0530, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: > > > > > Normally they are quiet most of the time. But they raise their voice if > > they think that's needed or if it's an area where they are working. That > > works quite well. > > I read FESCo meeting mins everytime and I dont see many non FESCo > members actively participating or commenting in between meetings. I call BS. I can think of a few offhand without even trying. It doesn't happen every meeting, but it does happen. Chris Weyl, Jesse Keating, even me before I became part of FESCo. We _do_ let non-FESCo people participate whenever they'd like. > > Well, why meet then in any case? Because it does not work. So we meet on > > IRC. > > The meeting is for FESCo members. If non FESCo members start actively > participating and expressing their opinions on the channels then it > would become tiresome pretty soon. If you want to hear opinions of the > larger community its better to do that on the list instead of in between > the meeting which can be done in this list for the board meetings. We do both. It works just fine. Most people are _worth_ listening to if they have well thought out comments on the topic at hand. And if not, there are OPs in IRC. We've _never_ had to use that though. > > > But why should we lock the community out there? That would be stupid. > > That is exactly how FESCo meetings were held before. This doesnt lock > out community if the meetings results are published regularly and can be > dicussed in the lists. Yes before. Quite a while ago. Not anymore. > > Sure, there may be discussions that need to be held in private, but that > > doesn't happen that often (and if, on the private fesco-list). > > If we force ourselves to have public discussions everytime, we wont be > able to discuss things freely effectively. Some things are better off > discuss between people offlist or in a private list or meeting. Board I don't buy it. The only time I would think such a private discussion would be required are if legal matters are being discussed. As for phone vs. IRC, yes that does have some advantages. At the disadvantage of being open and transparent. My personal opinion is that the disadvantage of that outweighs the apparent benefit. josh From sundaram at fedoraproject.org Fri Nov 3 19:30:12 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Nov 2006 01:00:12 +0530 Subject: [fab] looking at our surrent state a bit In-Reply-To: <1162581484.11259.10.camel@zod.rchland.ibm.com> References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> <454B66CC.4010405@fedoraproject.org> <454B7863.4060308@leemhuis.info> <454B8B2D.2010909@fedoraproject.org> <1162581484.11259.10.camel@zod.rchland.ibm.com> Message-ID: <454B98C4.1020601@fedoraproject.org> Josh Boyer wrote: > On Sat, 2006-11-04 at 00:02 +0530, Rahul Sundaram wrote: >> Thorsten Leemhuis wrote: >> >>> Normally they are quiet most of the time. But they raise their voice if >>> they think that's needed or if it's an area where they are working. That >>> works quite well. >> I read FESCo meeting mins everytime and I dont see many non FESCo >> members actively participating or commenting in between meetings. > > I call BS. I can think of a few offhand without even trying. It > doesn't happen every meeting, but it does happen. Chris Weyl, Jesse > Keating, even me before I became part of FESCo. We _do_ let non-FESCo > people participate whenever they'd like. This wasnt about what was allowed but what happens in a regular fashion. People who are willing to participate in the list are much more than those sitting on the same channel at meeting time due to time zone differences, work time conflicts etc and hence list is always going to be better for a broader discussion. Since the board meetings mins are always published, anyone can discuss things after the meeting. I dont see why that wouldnt work. > I don't buy it. The only time I would think such a private discussion > would be required are if legal matters are being discussed. Far from true. FESCo private lists wouldnt exist if that's the case. Rahul From jkeating at redhat.com Fri Nov 3 19:30:13 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Nov 2006 14:30:13 -0500 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B93B9.6090600@leemhuis.info> References: <454B2300.8080900@leemhuis.info> <200611031302.25413.jkeating@redhat.com> <454B93B9.6090600@leemhuis.info> Message-ID: <200611031430.13586.jkeating@redhat.com> On Friday 03 November 2006 14:08, Thorsten Leemhuis wrote: > http://lwn.net/Articles/204961/ > From: ?? ???????Mark Shuttleworth > Subject: ???????Planning for Ubuntu 7.04 - the "Feisty Fawn" Sure, Max could dictate to us what he'd like to see for the next Fedora, but instead he'd like to talk to the developers, contributors, release engineers, etc.. to get a bigger picture before making any plans. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Nov 3 19:51:41 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 03 Nov 2006 20:51:41 +0100 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B8B2D.2010909@fedoraproject.org> References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> <454B66CC.4010405@fedoraproject.org> <454B7863.4060308@leemhuis.info> <454B8B2D.2010909@fedoraproject.org> Message-ID: <454B9DCD.1020401@leemhuis.info> Rahul Sundaram schrieb: > Thorsten Leemhuis wrote: >> The plan was to meet all two weeks IIRC. I think that should suffice if >> it would be held in. > It has been. It was not during FC6 release time because people in the > board were involved in it. Thats all. Only one meeting in July, August and September and none in October -- is that the timeframe of "during FC6 release"? Well, then FC7 release time starts soon again. >> Further take a look at >> http://www.fedoraproject.org/wiki/Board/Meetings >> {{{ >> Upcoming meetings: >> * October 3 (10:00 AM EDT, 2:00 PM GMT) >> * October 17 (5:00 PM EDT, 9:00 PM GMT) >> }}} >> Great work! (Sorry, but what shall I say) > This was the original plans and it has been postponed due to release > work as stated already. Well, then at least someone should have updated that page... > I prefer that interval to stay as it is rather > than complete wipe it out. >> "Participating in a meeting" and "looking at the results" are two >> different things. > You can discuss the results in the list. Not many people are probably interested to discuss things after they were decided. And such a behavior will hinter building a community because they want to get involved before a decisions is done -- even if the results that later is found doesn't match what they want. > I dont see any functional > difference. I prefer the list before it makes it easier for a wider > community to respond without sitting on the channel at the same time. Sure, list before is good. But I don't think it's enough. >> Normally they are quiet most of the time. But they raise their voice if >> they think that's needed or if it's an area where they are working. That >> works quite well. > I read FESCo meeting mins everytime and I dont see many non FESCo > members actively participating or commenting in between meetings. They can if they want (that's important) and they do: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20061005 nirk -> stopped counting after 10 lines mmcgrath -> stopped counting after 10 lines other voices from: ixs, skvidal, adrianr, jima, daniel_hoza, delero http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20061102 not that many contributions from non-fesco members, but there were voices from jima, f13 >> Well, why meet then in any case? Because it does not work. So we meet on >> IRC. > The meeting is for FESCo members. No, those are the meeting to organize Extras, and contributors are meant to participate. > If non FESCo members start actively > participating and expressing their opinions on the channels then it > would become tiresome pretty soon. It worked fine in the past months. And it seems all people likes it that way. > If you want to hear opinions of the > larger community its better to do that on the list instead of in between > the meeting which can be done in this list for the board meetings. Sure, we do it on list, too. >> But why should we lock the community out there? That would be stupid. > That is exactly how FESCo meetings were held before. And that's why we stopped that one year ago! > This doesnt lock > out community if the meetings results are published regularly and can be > dicussed in the lists. That never happens. I can understand that -- why discuss something that was decided? It's to late anyway. People will only raise voices if they really think the decsions FESCo did is really bad. >> Sure, there may be discussions that need to be held in private, but that >> doesn't happen that often (and if, on the private fesco-list). > If we force ourselves to have public discussions everytime, I didn't request that. > we wont be > able to discuss things freely effectively. Some things are better off > discuss between people offlist or in a private list or meeting. Sure. But stuff that can be discussed in the open should be discussed in the open. > Board > discussions are usually of this nature and I believe many people prefer > talking on phone to IRC. Sure. But that doesn't mean you have to completely ignore IRC. > tend to identify nicknames in IRC better than > voices on phone and I am much better on email personally though. > >> Well, contributing to core is still hard afaics. > You can very easily send patches and participate in anaconda-list if you > have any interest in contributing. anaconda is only one part of core. I meant Core as a whole. > This is not a reason why people are > not contributing. The only thing limited currently is packaging. But that's what a lot of people probably would be interested in. Well, work is on the way to change that, so no need to discuss this much wider. >> Well, we're getting rhetorical here. For me it looks like that: Red Hat >> failed to get the community involved properly/to build one up and thus >> contributors wandered of elsewhere. Those stupid contributors like me >> that work for Fedora in their free time are busy with a lot of stuff >> already and don't have time to work on more stuff. > I guess we could speculate on the reasons but active development didnt > happen. A good way to actual fix things would be get involved. Live CD > is very much a priority for us in the current development release cycle. > If this involves getting someone in Red Hat to do that everytime, that > might slow down progress. Well, I've reached the point where I'd think we need to get our own stuff much more improved (Live-CD, initscripts), even if we need to get less improvments into gnome or the kernel for one develont cycle. >>>> Not sure, I'm not a marketing guy. But we need to communicate better >>>> that we're nearly as free as Debian (here and there we are worse, in >>>> other areas we are better afaics). Most people don't know that afaics. >>> Where are we worse? >> Well, some people might say that as we ship firmware packages in our kernel. > So does Debian. Put they planed to change that. Anyway, it was just a example, not worth debating out. Debian IMHO is seen as real open-source distribution in the linux-community and we should try to get a similar fame. >> Take Gnome 2.12 as example: I'm sure many Red Hat developers worked >> quite hard on it and got some quite nice improvements into it. But we >> never shipped it in Fedora Core. Ubuntu and Suse did and took the glory >> for it. > I would prefer we discuss things on the terms of Fedora rather go into a > competitive comparison. Yes, sometimes GNOME or Firefox or Xorg or KDE > would do a release in the middle of Fedora development which we wont be > able to accommodate. People would have to wait for the next release if > they want that. We might skip releases and pick the next one. When > upstream projects work in a distributed fashion, it is inevitable that > some project or the other wont be coordinated with Fedora. This is not > news. /me gives up here -- seems I can't get Rahul to understand what I'm up to >> We should give users a chance to run their hardware they buy (even if >> that hardare was brought to the market after FCx) -- and the drivers for >> that sometimes require newer X.org releases, while the next FC with that >> new X.org version might still be far away. So what do you suggest to >> those users? Run Windows? Run Rawhide? > Wait for the next release. Please tell that somebody who just bought a new computer or hardware component and what's to use that now. > We wont be pushing everything as updates. I didn't request that. Seems you don't want to hear me on that, too. > We > need to maintain quality for the release and updates. Major updates of a > new release of GNOME have higher chances of regressions when pushed out > as updates. That why I want out schedule to be aligned with Gnome. >>>> Sure. That's not what I proposed. But if there are important things >>>> missing (FF 2.0 in FC6; AIGLX in FC5, Gnome Update in FC4) then try to >>>> get a solution that makes installing those software possible easily (the >>>> AIGLX on FC5 was more a disaster because it was poorly maintained). >>> AIGLX on FC5 was not installed by default. It was a *experimental* >>> separate repository that users had to go and install by themselves. >> And that did not work often as updates from core confused it multiple times. > Sure. There is a reason it is called experimental. [...] I'd call what happend there "the maintainer baked it once and then forget about that". Give FESCo free hand to revamp "Fedora Alternatives" and Ill show you that the community can do better. >>> [ripping firefox aside, see mails to jesse] >>> Major updates of GNOME post release as updates falls into the same "too >>> risky" category as Xorg updates for me. >> Agreed. But I think FC4 should have get one, or FC5 should have shipped >> way earlier. > If a major release of Xorg follows 3 months after GNOME with a Fedora > release somewhere in between That would not have happened if Fedora releases were aligned with the ones from Gnome. > we wouldnt be able to accomodate all these > in the same release and not within updates either. They would have wait > for the next release. > >> Ignoring the opinion from the community won't help building a community >> around Fedora. > We are trying to solve the bigger problem instead. And you keep the community out. >>> This is very broad generalization. >> I think that's how it looks often from the outside. Remembers Fedora >> Extras? It took quite some time after the fedora.us/Red Hat Linux >> Project merger until it took of (one and a half year iirc). > Yes and that got fixed only because some people in the community decided > to act on it and do something about it themselves. I know. That worked. Fedora could be so much better and ahead of our competitors if Red Hat would help with the birth of some stuff a bit more. That part of the reasons why I started this thread. > Thats what we need > more of. I don't see that happening with the current attitude. CU thl From gdk at redhat.com Fri Nov 3 20:11:59 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Fri, 3 Nov 2006 15:11:59 -0500 (EST) Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B9DCD.1020401@leemhuis.info> References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> <454B66CC.4010405@fedoraproject.org> <454B7863.4060308@leemhuis.info> <454B8B2D.2010909@fedoraproject.org> <454B9DCD.1020401@leemhuis.info> Message-ID: On Fri, 3 Nov 2006, Thorsten Leemhuis wrote: > I'd call what happend there "the maintainer baked it once and then > forget about that". Give FESCo free hand to revamp "Fedora Alternatives" > and Ill show you that the community can do better. ... > I know. That worked. Fedora could be so much better and ahead of our > competitors if Red Hat would help with the birth of some stuff a bit > more. That part of the reasons why I started this thread. ... There aren't many people in the Fedora community I trust more than I trust Thorsten. He says we've got a lot of work to do in order to make Fedora more open. He's exactly right. We've got a lot of work to do inside the fenceline, though. Honestly, a lot of that work requires the disentanglement of Fedora and RHEL -- we need the ability to innovate freely in Fedora without adversely impacting RHEL. We didn't really have that opportunity in the FC6 timeframe. But now we do. Our real goal: to figure out how to open Core to community developers. There. I said it. But it's going to take some *extremely* heavy lifting. I know it's hard to hear "we're working on it," and you can only hear that so many times. But Max, Bill and I will be flying up to Boston and spending several days talking through internal issues around Fedora with the other engineers. The goal: a proposal for a community roadmap for FC7, which we will then present to community folks for additional guidance. I'd like to see something presented on this list by November 15th. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From tcallawa at redhat.com Fri Nov 3 20:18:32 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 03 Nov 2006 14:18:32 -0600 Subject: [fab] looking at our surrent state a bit In-Reply-To: References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> <454B66CC.4010405@fedoraproject.org> <454B7863.4060308@leemhuis.info> <454B8B2D.2010909@fedoraproject.org> <454B9DCD.1020401@leemhuis.info> Message-ID: <1162585118.8918.123.camel@dhcp-32-122.ord.redhat.com> On Fri, 2006-11-03 at 15:11 -0500, Greg Dekoenigsberg wrote: > Our real goal: to figure out how to open Core to community developers. > There. I said it. But it's going to take some *extremely* heavy lifting. Or, more to the point, our real goal should be to abolish Core. Fedora Extras has shown that the community can do it right. The Fedora Packaging Committee is already setting standards for both Core and Extras. Merge Core and Extras. Really make it so that "Core" is only the packages that go on the ISOs, and not anything else, not a special set of rules. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From jkeating at redhat.com Fri Nov 3 20:20:14 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Nov 2006 15:20:14 -0500 Subject: [fab] looking at our surrent state a bit In-Reply-To: <1162585118.8918.123.camel@dhcp-32-122.ord.redhat.com> References: <454B2300.8080900@leemhuis.info> <1162585118.8918.123.camel@dhcp-32-122.ord.redhat.com> Message-ID: <200611031520.15143.jkeating@redhat.com> On Friday 03 November 2006 15:18, Tom 'spot' Callaway wrote: > Merge Core and Extras. Really make it so that "Core" is only the > packages that go on the ISOs, and not anything else, not a special set > of rules. Exactly. And get rid of the term 'core'. It's far too overloaded anyway. Fedora Linux anybody? (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Nov 3 20:22:14 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Nov 2006 01:52:14 +0530 Subject: [fab] looking at our surrent state a bit In-Reply-To: <1162585118.8918.123.camel@dhcp-32-122.ord.redhat.com> References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> <454B66CC.4010405@fedoraproject.org> <454B7863.4060308@leemhuis.info> <454B8B2D.2010909@fedoraproject.org> <454B9DCD.1020401@leemhuis.info> <1162585118.8918.123.camel@dhcp-32-122.ord.redhat.com> Message-ID: <454BA4F6.3090509@fedoraproject.org> Tom 'spot' Callaway wrote: > On Fri, 2006-11-03 at 15:11 -0500, Greg Dekoenigsberg wrote: > >> Our real goal: to figure out how to open Core to community developers. >> There. I said it. But it's going to take some *extremely* heavy lifting. > > Or, more to the point, our real goal should be to abolish Core. Fedora > Extras has shown that the community can do it right. The Fedora > Packaging Committee is already setting standards for both Core and > Extras. > > Merge Core and Extras. Really make it so that "Core" is only the > packages that go on the ISOs, and not anything else, not a special set > of rules. Thats how this is already planned. If anyone is interested in moving this faster, they should look at participating in the infrastructure and that whats we depend on to take the next steps. Rahul From sundaram at fedoraproject.org Fri Nov 3 20:22:46 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Nov 2006 01:52:46 +0530 Subject: [fab] looking at our surrent state a bit In-Reply-To: <200611031520.15143.jkeating@redhat.com> References: <454B2300.8080900@leemhuis.info> <1162585118.8918.123.camel@dhcp-32-122.ord.redhat.com> <200611031520.15143.jkeating@redhat.com> Message-ID: <454BA516.1090201@fedoraproject.org> Jesse Keating wrote: > On Friday 03 November 2006 15:18, Tom 'spot' Callaway wrote: >> Merge Core and Extras. Really make it so that "Core" is only the >> packages that go on the ISOs, and not anything else, not a special set >> of rules. > > Exactly. And get rid of the term 'core'. It's far too overloaded anyway. > Fedora Linux anybody? (: Just Fedora is fine. Rahul From tcallawa at redhat.com Fri Nov 3 20:25:24 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 03 Nov 2006 14:25:24 -0600 Subject: [fab] looking at our surrent state a bit In-Reply-To: <200611031520.15143.jkeating@redhat.com> References: <454B2300.8080900@leemhuis.info> <1162585118.8918.123.camel@dhcp-32-122.ord.redhat.com> <200611031520.15143.jkeating@redhat.com> Message-ID: <1162585529.8918.125.camel@dhcp-32-122.ord.redhat.com> On Fri, 2006-11-03 at 15:20 -0500, Jesse Keating wrote: > On Friday 03 November 2006 15:18, Tom 'spot' Callaway wrote: > > Merge Core and Extras. Really make it so that "Core" is only the > > packages that go on the ISOs, and not anything else, not a special set > > of rules. > > Exactly. And get rid of the term 'core'. It's far too overloaded anyway. > Fedora Linux anybody? (: If we do that, the FSF is going to start asking for Fedora GNU/Linux. Why not just Fedora? :) ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From notting at redhat.com Fri Nov 3 20:29:04 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 3 Nov 2006 15:29:04 -0500 Subject: [fab] looking at our surrent state a bit In-Reply-To: <1162585529.8918.125.camel@dhcp-32-122.ord.redhat.com> References: <454B2300.8080900@leemhuis.info> <1162585118.8918.123.camel@dhcp-32-122.ord.redhat.com> <200611031520.15143.jkeating@redhat.com> <1162585529.8918.125.camel@dhcp-32-122.ord.redhat.com> Message-ID: <20061103202904.GA24217@nostromo.devel.redhat.com> Tom 'spot' Callaway (tcallawa at redhat.com) said: > Why not just Fedora? :) Fedora is the universe. Some CD distribution of a subset has to be called *something*. Bill From jwboyer at jdub.homelinux.org Fri Nov 3 20:39:30 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 03 Nov 2006 14:39:30 -0600 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B98C4.1020601@fedoraproject.org> References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> <454B66CC.4010405@fedoraproject.org> <454B7863.4060308@leemhuis.info> <454B8B2D.2010909@fedoraproject.org> <1162581484.11259.10.camel@zod.rchland.ibm.com> <454B98C4.1020601@fedoraproject.org> Message-ID: <1162586370.11259.22.camel@zod.rchland.ibm.com> On Sat, 2006-11-04 at 01:00 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > On Sat, 2006-11-04 at 00:02 +0530, Rahul Sundaram wrote: > >> Thorsten Leemhuis wrote: > >> > >>> Normally they are quiet most of the time. But they raise their voice if > >>> they think that's needed or if it's an area where they are working. That > >>> works quite well. > >> I read FESCo meeting mins everytime and I dont see many non FESCo > >> members actively participating or commenting in between meetings. > > > > I call BS. I can think of a few offhand without even trying. It > > doesn't happen every meeting, but it does happen. Chris Weyl, Jesse > > Keating, even me before I became part of FESCo. We _do_ let non-FESCo > > people participate whenever they'd like. > > This wasnt about what was allowed but what happens in a regular fashion. > People who are willing to participate in the list are much more than > those sitting on the same channel at meeting time due to time zone > differences, work time conflicts etc and hence list is always going to > be better for a broader discussion. Since the board meetings mins are > always published, anyone can discuss things after the meeting. I dont > see why that wouldnt work. > > > I don't buy it. The only time I would think such a private discussion > > would be required are if legal matters are being discussed. > > Far from true. FESCo private lists wouldnt exist if that's the case. As far as I'm concerned, FESCo list can go at any time. josh From sundaram at fedoraproject.org Fri Nov 3 20:54:17 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Nov 2006 02:24:17 +0530 Subject: [fab] looking at our surrent state a bit In-Reply-To: <454B9DCD.1020401@leemhuis.info> References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> <454B66CC.4010405@fedoraproject.org> <454B7863.4060308@leemhuis.info> <454B8B2D.2010909@fedoraproject.org> <454B9DCD.1020401@leemhuis.info> Message-ID: <454BAC79.3090804@fedoraproject.org> Thorsten Leemhuis wrote: >>> Well, contributing to core is still hard afaics. >> You can very easily send patches and participate in anaconda-list if you >> have any interest in contributing. > > anaconda is only one part of core. I meant Core as a whole. The same applies to the rest of the core. Core/Extras is all about packaging. At the code level, it doesnt prevent contributors from getting involved at all. So attributing any alleged slowness of Anaconda development to "openness" of core itself doesnt seem to be the right idea to me. If you want to contribute, every project in Fedora can get patches through bugzilla. We have already had hundreds of patches from external people that has been merged in core. I dont disagree that opening up core is beneficial for *other reasons* and there are ways for people to contribute towards that but it dont expect it to speed up say Anaconda or initscript development on its own. Just expressing that so that we dont expect this to be the magic bullet that solves all the development issues. > > Well, I've reached the point where I'd think we need to get our own > stuff much more improved (Live-CD, initscripts), even if we need to get > less improvments into gnome or the kernel for one develont cycle. > >>>>> Not sure, I'm not a marketing guy. But we need to communicate better >>>>> that we're nearly as free as Debian (here and there we are worse, in >>>>> other areas we are better afaics). Most people don't know that afaics. >>>> Where are we worse? >>> Well, some people might say that as we ship firmware packages in our kernel. >> So does Debian. > > Put they planed to change that. Anyway, it was just a example, not worth > debating out. Debian IMHO is seen as real open-source distribution in > the linux-community and we should try to get a similar fame. Well, you claim we are worse than Debian in some aspects with regard to be a Free software distribution. Just pointing out we are not at this stage. Getting that message out is a different aspect. Before we do that, I would like to see that licensing audit to cross check licensing in Fedora Extras to be completed. Other stuff is waiting on FSF to let us know their standing. >> I would prefer we discuss things on the terms of Fedora rather go into a >> competitive comparison. Yes, sometimes GNOME or Firefox or Xorg or KDE >> would do a release in the middle of Fedora development which we wont be >> able to accommodate. People would have to wait for the next release if >> they want that. We might skip releases and pick the next one. When >> upstream projects work in a distributed fashion, it is inevitable that >> some project or the other wont be coordinated with Fedora. This is not >> news. > > /me gives up here -- seems I can't get Rahul to understand what I'm up to I pointed out a scenario we have been hit with many times during development of Fedora releases. I would like to hear how your ideas on how to solve that without affecting the quality of the release and updates. >> Wait for the next release. > > Please tell that somebody who just bought a new computer or hardware > component and what's to use that now. This is going to happen with every distribution and we are getting changes out much faster than many. Pushing out major updates every time is *not* the solution. I dont see any alternative. Aligning ourselves with major new GNOME, KDE, Xorg releases at the same time will not be always possible. > >> We wont be pushing everything as updates. > > I didn't request that. Seems you don't want to hear me on that, too. No I hear you but I am seeing potential issues with this. See below. >> If a major release of Xorg follows 3 months after GNOME with a Fedora >> release somewhere in between > > That would not have happened if Fedora releases were aligned with the > ones from Gnome. Why wouldnt it happen? To give you a hypothetical example. Lets assume we align Fedora Core 7 with GNOME 2.18. Xorg 7.2 gets released 3 months after the release of Fedora Core 7. What would you do then? Push out the Xorg release as an update to Fedora Core 7? We will have to wait the next release of Fedora itself otherwise we risk regressions. >> We are trying to solve the bigger problem instead. > > And you keep the community out. How exactly? Working with the infrastructure team is what is required and everyone is welcome to get involved. Rahul From kwade at redhat.com Fri Nov 3 23:16:05 2006 From: kwade at redhat.com (Karsten Wade) Date: Fri, 03 Nov 2006 15:16:05 -0800 Subject: [fab] looking at our surrent state a bit In-Reply-To: <200611031252.42065.jkeating@redhat.com> References: <454B2300.8080900@leemhuis.info> <200611031120.41588.jkeating@redhat.com> <454B7F26.70309@leemhuis.info> <200611031252.42065.jkeating@redhat.com> Message-ID: <1162595765.27328.177.camel@erato.phig.org> On Fri, 2006-11-03 at 12:52 -0500, Jesse Keating wrote: > On Friday 03 November 2006 12:40, Thorsten Leemhuis wrote: > > Late march only once. I asked after FC5 on fedora-devel if we would > > stick to "late march and late September" in the future again (+ some > > delays if needed) and the answer was "no". > > > > But if we get our release to "round about late march and late September" > > in the future I'd be very glad. > > It's something we shoot for, but flexibility is necessary for what we do. Looking at the trending from Thorsten's list: FC1 -- 5 November 2003 - General Availability FC2 -- 18 May 2004 - General Availability FC3 -- 8 November 2004 - General Availability FC4 -- 13 June 2005 - General Availability FC5 -- 20 March 2006 - General Availability FC6 -- 24 October 2006 - General Availability The nine months for FC5 brought the schedule back into the late-March/late-October flow again. If this is important, I think we all have some possibility of influencing that this stays this way; and I think some influence may already be applied. What I see Thorsten saying is, let's keep applying that influence from the community and from Red Hat to keep aligned with i) a schedule that others can predict more than five months in advance, and ii) a schedule lined up with at least one major component (GNOME). Seems reasonable to me. We can do that _and_ remain flexible -- it's better to make up your mind and change it later than to never make it up at all ... or make it up and refuse to budge from a bad decision. ;-D - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri Nov 3 23:19:35 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Nov 2006 18:19:35 -0500 Subject: [fab] looking at our surrent state a bit In-Reply-To: <1162595765.27328.177.camel@erato.phig.org> References: <454B2300.8080900@leemhuis.info> <200611031252.42065.jkeating@redhat.com> <1162595765.27328.177.camel@erato.phig.org> Message-ID: <200611031819.38370.jkeating@redhat.com> On Friday 03 November 2006 18:16, Karsten Wade wrote: > The nine months for FC5 brought the schedule back into the > late-March/late-October flow again. ?If this is important, I think we > all have some possibility of influencing that this stays this way; and I > think some influence may already be applied. ?What I see Thorsten saying > is, let's keep applying that influence from the community and from Red > Hat to keep aligned with i) a schedule that others can predict more than > five months in advance, and ii) a schedule lined up with at least one > major component (GNOME). ? > > Seems reasonable to me. ?We can do that _and_ remain flexible -- it's > better to make up your mind and change it later than to never make it up > at all ... or make it up and refuse to budge from a bad decision. ;-D I don't want to make any assumptions about the release dates for the next Fedora release until after our "summit". -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Fri Nov 3 22:14:00 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 03 Nov 2006 14:14:00 -0800 Subject: [fab] FSF Requirements for srpm provisions In-Reply-To: <200611022323.56266.nman64@n-man.com> References: <200611021103.06057.jkeating@redhat.com> <1162503295.11351.21.camel@zod.rchland.ibm.com> <1162504248.2964.10.camel@localhost> <200611022323.56266.nman64@n-man.com> Message-ID: <1162592040.5173.66.camel@localhost> On Thu, 2006-11-02 at 23:23 -0600, Patrick W. Barnes wrote: > On Thursday 02 November 2006 15:50, Toshio Kuratomi wrote: > > > > As long as the SRPMs remain available. If the respin involves packages > > where we don't keep the RPMS/SRPMS for the life of the ISO respin then > > we'd be in trouble. > > > > I know this would cause trouble for things from FC-devel. I think it > > would be a problem for FC-updates and FE as well. > > > > Don't forget CVS. It's just as valid as a source provider as the SRPMS. Is it? This might fall under the letter of the GPL but does it follow the spirit? Mirroring isos and burning them onto a disk is a no-brainer compared to checking the version of a binary rpm you have, constructing a cvs tag from it, and doing a cvs checkout from fedora cvs. Not impossible, just not on the same level of difficulty. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Fri Nov 3 23:48:42 2006 From: kwade at redhat.com (Karsten Wade) Date: Fri, 03 Nov 2006 15:48:42 -0800 Subject: [fab] looking at our surrent state a bit In-Reply-To: References: <454B2300.8080900@leemhuis.info> <454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> <454B66CC.4010405@fedoraproject.org> <454B7863.4060308@leemhuis.info> <454B8B2D.2010909@fedoraproject.org> <454B9DCD.1020401@leemhuis.info> Message-ID: <1162597723.27328.192.camel@erato.phig.org> On Fri, 2006-11-03 at 15:11 -0500, Greg Dekoenigsberg wrote: > I know it's hard to hear "we're working on it," and you can only hear that > so many times. But Max, Bill and I will be flying up to Boston and > spending several days talking through internal issues around Fedora with > the other engineers. The goal: a proposal for a community roadmap for > FC7, which we will then present to community folks for additional > guidance. I'd like to see something presented on this list by November > 15th. Is this what Jesse was calling a "summit"? If so, then I'd remove the "quotes" and call a shovel a shovel. :) Is there any chance of you providing some real time access to these proceedings? Such as: * For every meeting/proceeding, take notes and post them at regular intervals to the Wiki; one person is note taker and makes sure to keep the flow going. You can do all this on a whiteboard, then write out and put them on the Wiki. * Have all summit participants on IRC on an open channel, interacting about the meetings as they are happening. Aside from coordination benefits ("Hey, gregdek, get out of the bathroom and get back here, we're starting!"), it gives you a place to have all of us who aren't going to be in Westford to interact with you. Sure, you can track people down in other channels, etc. But having an event-only unique channel adds to the feel of openness, keeps chatter on topic, and provides a simple logging mechanism that is event-specific. * Email out highlights at the end of the day to a designated list, such as this one. Include some links back to important stuff on the Wiki. Getting everyone involved in this task makes it easy to do, accurate, useful, and fun! Just those three things are enough to give you a global interaction and help everyone not present able to be involved. FWIW, we did just those exact things at the Google Summer of Code mentors summit[1], and it worked very well. At that, with so many participants and scheduled thingies, it was nice to have a growing mind map and instant logging of the proceedings. - Karsten [1] http://www.red-bean.com/ospowiki/MentorSummit-2006 -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri Nov 3 23:51:38 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Nov 2006 18:51:38 -0500 Subject: [fab] looking at our surrent state a bit In-Reply-To: <1162597723.27328.192.camel@erato.phig.org> References: <454B2300.8080900@leemhuis.info> <1162597723.27328.192.camel@erato.phig.org> Message-ID: <200611031851.38644.jkeating@redhat.com> On Friday 03 November 2006 18:48, Karsten Wade wrote: > Just those three things are enough to give you a global interaction and > help everyone not present able to be involved. I'm pretty sure we can arrange for something like that. Responding to community folks in the channel may be sparse while we're in a heavy whiteboard session, but we can try. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Sat Nov 4 15:45:03 2006 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 04 Nov 2006 10:45:03 -0500 Subject: [fab] looking at our surrent state a bit In-Reply-To: <1162585529.8918.125.camel@dhcp-32-122.ord.redhat.com> References: <454B2300.8080900@leemhuis.info> <1162585118.8918.123.camel@dhcp-32-122.ord.redhat.com> <200611031520.15143.jkeating@redhat.com> <1162585529.8918.125.camel@dhcp-32-122.ord.redhat.com> Message-ID: <1162655103.7658.4.camel@localhost.localdomain> On Fri, 2006-11-03 at 14:25 -0600, Tom 'spot' Callaway wrote: > On Fri, 2006-11-03 at 15:20 -0500, Jesse Keating wrote: > > On Friday 03 November 2006 15:18, Tom 'spot' Callaway wrote: > > > Merge Core and Extras. Really make it so that "Core" is only the > > > packages that go on the ISOs, and not anything else, not a special set > > > of rules. > > > > Exactly. And get rid of the term 'core'. It's far too overloaded anyway. > > Fedora Linux anybody? (: > > If we do that, the FSF is going to start asking for Fedora GNU/Linux. > > Why not just Fedora? :) +1. Internet "journalists" will call it whatever they want anyway. :-) -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Sat Nov 4 16:05:23 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 04 Nov 2006 17:05:23 +0100 Subject: [fab] looking at our surrent state a bit In-Reply-To: <1162655103.7658.4.camel@localhost.localdomain> References: <454B2300.8080900@leemhuis.info> <1162585118.8918.123.camel@dhcp-32-122.ord.redhat.com> <200611031520.15143.jkeating@redhat.com> <1162585529.8918.125.camel@dhcp-32-122.ord.redhat.com> <1162655103.7658.4.camel@localhost.localdomain> Message-ID: <454CBA43.4090909@leemhuis.info> Paul W. Frields schrieb: > On Fri, 2006-11-03 at 14:25 -0600, Tom 'spot' Callaway wrote: >> On Fri, 2006-11-03 at 15:20 -0500, Jesse Keating wrote: >>> On Friday 03 November 2006 15:18, Tom 'spot' Callaway wrote: >>>> Merge Core and Extras. Really make it so that "Core" is only the >>>> packages that go on the ISOs, and not anything else, not a special set >>>> of rules. >>> Exactly. And get rid of the term 'core'. It's far too overloaded anyway. >>> Fedora Linux anybody? (: >> If we do that, the FSF is going to start asking for Fedora GNU/Linux. >> Why not just Fedora? :) > +1. Internet "journalists" will call it whatever they want anyway. :-) /me votes for "Fedora Linux" -- Internet and print "journalists" will often call it just "Fedora" then if our Linux distribution is obviously meant. Site note: "Suse Linux" was often simply denoted just as "Suse", too. But calling it "Fedora Linux" gives us a chance to do other things like Fedora Music, Fedora Hurd or Fedora Laris, that all might have nothing to do with Linux. CU thl From jkeating at redhat.com Sat Nov 4 21:55:30 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 4 Nov 2006 16:55:30 -0500 Subject: [fab] Fwd: Mono and FC Message-ID: <200611041655.30372.jkeating@redhat.com> Probably something we should look into and make a statement about. ---------- Forwarded Message ---------- Subject: Mono and FC Date: Saturday 04 November 2006 16:52 From: Paul To: For testers of Fedora Core development releases Hi, Given the decision for Novell to have SuSE killed off in much the same way as Corel Linux was, it leaves some serious questions for FC as a distro which includes Mono. Currently, it is very unclear as to what (if any) patents are infringed and as Jesse has said, they are OIN members. However, the possibility needs to be looked at as to what should be done. There is not really a problem of pulling Mono apps and libraries from FE, but for the likes of gnome, there is a lot resting on C#. Me, I'd hate to move over to KDE - I really dislike it as a desktop environment (and no, I'm not trying to start a flame war), but if this is the cost to keep FC untainted, I'm prepared to do it. I personally don't believe we can trust Novell any more in OIN - I don't know how they would behave if (say) OpenOffice caused a patent problem - would they back MS now they have a deal in place to work towards a plugin between their bastardisation of XML and the ODF format or would they support the OIN and tell MS to go screw themselves (though obviously not in words like that!). It seems to me that they may be a very large loose cannon. The question also of if they can continue distributing SuSE as a GPL'd package now they have a deal with MS over patents (which goes against the GPL and possibly gives SCO a final foothold). I don't really care if SuSE vanishes without trace, but I do care for the longer implications of such a deal as Novell did with MS. I've not seen much on the Debian lists over this, but the mono lists are very quiet; way too quiet over this - it's almost spooky. TTFN Paul -- "Der einzige Weg, Leute zu kontrollieren ist sie anzul?gen" - L. Ron "Ich kann kein Science-Fiction schreiben" Hubbard; L?gner, Betr?ger, Fixer und Wohlt?ter zu niemandem ------------------------------------------------------- -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From matt at domsch.com Sat Nov 4 22:32:57 2006 From: matt at domsch.com (Matt Domsch) Date: Sat, 4 Nov 2006 16:32:57 -0600 Subject: [fab] Fwd: Mono and FC In-Reply-To: <200611041655.30372.jkeating@redhat.com> References: <200611041655.30372.jkeating@redhat.com> Message-ID: <20061104223256.GA2924@domsch.com> On Sat, Nov 04, 2006 at 04:55:30PM -0500, Jesse Keating wrote: > Probably something we should look into and make a statement about. Mono got into Core on the promise of OIN, so fundamentally we need a statement from OIN. Unless OIN is undone, we shouldn't revisit this every time someone raises the patent boogeyman spectre. If OIN is undone, then yes, Mono and related covered activities (NTFS?) are out. My 2 cents. -Matt From stickster at gmail.com Sun Nov 5 00:57:41 2006 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 04 Nov 2006 19:57:41 -0500 Subject: [fab] Fwd: Mono and FC In-Reply-To: <200611041655.30372.jkeating@redhat.com> References: <200611041655.30372.jkeating@redhat.com> Message-ID: <1162688261.18994.19.camel@localhost.localdomain> On Sat, 2006-11-04 at 16:55 -0500, Jesse Keating wrote: > Probably something we should look into and make a statement about. > > ---------- Forwarded Message ---------- > > Subject: Mono and FC > Date: Saturday 04 November 2006 16:52 > From: Paul > To: For testers of Fedora Core development releases > > > Hi, > > Given the decision for Novell to have SuSE killed off in much the same > way as Corel Linux was, it leaves some serious questions for FC as a > distro which includes Mono. > > Currently, it is very unclear as to what (if any) patents are infringed > and as Jesse has said, they are OIN members. However, the possibility > needs to be looked at as to what should be done. There is not really a > problem of pulling Mono apps and libraries from FE, but for the likes of > gnome, there is a lot resting on C#. > > Me, I'd hate to move over to KDE - I really dislike it as a desktop > environment (and no, I'm not trying to start a flame war), but if this > is the cost to keep FC untainted, I'm prepared to do it. > > I personally don't believe we can trust Novell any more in OIN - I don't > know how they would behave if (say) OpenOffice caused a patent problem - > would they back MS now they have a deal in place to work towards a > plugin between their bastardisation of XML and the ODF format or would > they support the OIN and tell MS to go screw themselves (though > obviously not in words like that!). It seems to me that they may be a > very large loose cannon. I'm not sure I understand how this is a real concern. The OIN owns the patents on OpenOffice.org (at least v2.0.0) and I don't see what Novell's potential "backing" would achieve either way. I wonder how Novell would construct compatibility between OO.o and MS Office based on this schema while simultaneously disallowing anyone else from using, distributing, or shipping it in a non-actionable way without violating the OO.o licensing. I'm sure Microsoft's legal team has their best minds working on it, though. As a purely OT side-note, MS has not "bastardized" XML. The Microsoft Office XML Schema is just a collection of DTDs like any other schema, albeit probably (a) much more lengthy and convoluted, and (b) unlikely to ever be completely supported in any product other than Microsoft Office. > The question also of if they can continue distributing SuSE as a GPL'd > package now they have a deal with MS over patents (which goes against > the GPL and possibly gives SCO a final foothold). I don't really care if > SuSE vanishes without trace, but I do care for the longer implications > of such a deal as Novell did with MS. I think in the long run the implications for the Linux community will be rather minimal. My initial reaction was that this was the beginning of the end for Novell, making yet another in a long line of poor business decisions allowing Microsoft to bully them out of a potentially profitable market. > I've not seen much on the Debian lists over this, but the mono lists are > very quiet; way too quiet over this - it's almost spooky. BOO SCARY. (With apologies to Greg; this line in his blog made me laugh. I would like to see this particular meme spread like "All your base...".) -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Sun Nov 5 14:56:58 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 05 Nov 2006 20:26:58 +0530 Subject: [fab] Fwd: Mono and FC In-Reply-To: <1162688261.18994.19.camel@localhost.localdomain> References: <200611041655.30372.jkeating@redhat.com> <1162688261.18994.19.camel@localhost.localdomain> Message-ID: <454DFBBA.40100@fedoraproject.org> Paul W. Frields wrote: > I'm not sure I understand how this is a real concern. The OIN owns the > patents on OpenOffice.org (at least v2.0.0) and I don't see what > Novell's potential "backing" would achieve either way. I wonder how > Novell would construct compatibility between OO.o and MS Office based on > this schema while simultaneously disallowing anyone else from using, > distributing, or shipping it in a non-actionable way without violating > the OO.o licensing. I'm sure Microsoft's legal team has their best > minds working on it, though. > There seems to be a misunderstanding of how OIN works. If OIN holds some patents through Novell which could have discouraged others from suing OIN members including Red Hat, Novell's decision to independently grant the same patents rights to Microsoft effectively means that they have now reduced the strength of OIN. Novell's contribution of patents to OIN has been nullified from Microsoft's perspective. GPL and LGPL licenses have a provision that is precisely meant to prevent such exclusionary "cross licensing" of patents which applies to Samba, Openoffice.org and parts of Mono which are components listed explicitly in the agreement. Apparently, what Novell and Microsoft has done to work around this license clause is sign a covenant not to sue each other that passes for the Novell customers using the Novell codebase as long as they have a active support contract with Novell. There is also a very limited patent pledge for open source developers as long as they dont get paid for their work and dont distribute it to anyone at all. This is also revocable if you make on any patent offensive against Microsoft. http://www.microsoft.com/interop/msnovellcollab/community.mspx#ESB Rahul From jkeating at redhat.com Sun Nov 5 16:07:08 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 5 Nov 2006 11:07:08 -0500 Subject: [fab] Fwd: Mono and FC In-Reply-To: <454DFBBA.40100@fedoraproject.org> References: <200611041655.30372.jkeating@redhat.com> <1162688261.18994.19.camel@localhost.localdomain> <454DFBBA.40100@fedoraproject.org> Message-ID: <200611051107.11230.jkeating@redhat.com> On Sunday 05 November 2006 09:56, Rahul Sundaram wrote: > Paul W. Frields wrote: > > I'm not sure I understand how this is a real concern. The OIN owns the > > patents on OpenOffice.org (at least v2.0.0) and I don't see what > > Novell's potential "backing" would achieve either way. I wonder how > > Novell would construct compatibility between OO.o and MS Office based on > > this schema while simultaneously disallowing anyone else from using, > > distributing, or shipping it in a non-actionable way without violating > > the OO.o licensing. I'm sure Microsoft's legal team has their best > > minds working on it, though. > > There seems to be a misunderstanding of how OIN works. If OIN holds some > patents through Novell which could have discouraged others from suing > OIN members including Red Hat, Novell's decision to independently grant > the same patents rights to Microsoft effectively means that they have > now reduced the strength of OIN. Novell's contribution of patents to OIN > has been nullified from Microsoft's perspective. > > GPL and LGPL licenses have a provision that is precisely meant to > prevent such exclusionary "cross licensing" of patents which applies to > Samba, Openoffice.org and parts of Mono which are components listed > explicitly in the agreement. Apparently, what Novell and Microsoft has > done to work around this license clause is sign a covenant not to sue > each other that passes for the Novell customers using the Novell > codebase as long as they have a active support contract with Novell. > > There is also a very limited patent pledge for open source developers as > long as they dont get paid for their work and dont distribute it to > anyone at all. This is also revocable if you make on any patent > offensive against Microsoft. > > http://www.microsoft.com/interop/msnovellcollab/community.mspx#ESB I'm also personally concerned about the dangers of tainting. If MSFT folks are contributing to the Mono code that Novell uses, they have no worry because Novell and Microsoft have a pact. However if say a Red Hat employee looks at the source code, does that employee then become tainted by the Microsoft code? Is not anything that employee does that is related come under danger of Microsoft litigation? It is something I would like to avoid all together. If we could get upstream gnome to boot mono to the curb, I would follow suite with Fedora, sending a clear message that we have NO INTEREST in Novell+Microsoft tainted products. Sure, immediately we lose things like beagle, f-spot, and tomboy, surely replacements can be written in non BOO SCARY code... We could send the message that says "we don't care about protection from Microsoft for this software, because we don't care about that software, see we're using something better, safer, cheaper, and the community is with us." -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Sun Nov 5 16:35:08 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 05 Nov 2006 22:05:08 +0530 Subject: [fab] Fwd: Mono and FC In-Reply-To: <200611051107.11230.jkeating@redhat.com> References: <200611041655.30372.jkeating@redhat.com> <1162688261.18994.19.camel@localhost.localdomain> <454DFBBA.40100@fedoraproject.org> <200611051107.11230.jkeating@redhat.com> Message-ID: <454E12BC.1020906@fedoraproject.org> Jesse Keating wrote: > > I'm also personally concerned about the dangers of tainting. If MSFT folks > are contributing to the Mono code that Novell uses, they have no worry > because Novell and Microsoft have a pact. However if say a Red Hat employee > looks at the source code, does that employee then become tainted by the > Microsoft code? Is not anything that employee does that is related come > under danger of Microsoft litigation? It is something I would like to avoid > all together. > > If we could get upstream gnome to boot mono to the curb, I would follow suite > with Fedora, sending a clear message that we have NO INTEREST in > Novell+Microsoft tainted products. Sure, immediately we lose things like > beagle, f-spot, and tomboy, surely replacements can be written in non BOO > SCARY code... We could send the message that says "we don't care about > protection from Microsoft for this software, because we don't care about that > software, see we're using something better, safer, cheaper, and the community > is with us." Unfortunately, the potential issues with exclusionary patent agreements and any possible solutions probably cannot be limited to Mono though it is probably the most significant project since the current move sets political if not legal precedent for patent claims in the future against other distributions except Novell and even Novell if the agreement isnt renewed after 5 years. Novell is working with Microsoft on virtualisation and openxml format support which probably results in code to xen and openoffice.org both of which has significant Novell developers working on them. If these contributions are under GPL and LGPL respectively then the patent clause in GPL automatically grants everyone else the necessary rights or would prevent Novell from distributing the code to anyone. So we are probably safe with that. Things for Legal to carefully look at. Rahul From jkeating at redhat.com Sun Nov 5 17:00:41 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 5 Nov 2006 12:00:41 -0500 Subject: [fab] Fwd: Mono and FC In-Reply-To: <454E12BC.1020906@fedoraproject.org> References: <200611041655.30372.jkeating@redhat.com> <200611051107.11230.jkeating@redhat.com> <454E12BC.1020906@fedoraproject.org> Message-ID: <200611051200.41201.jkeating@redhat.com> On Sunday 05 November 2006 11:35, Rahul Sundaram wrote: > Unfortunately, the potential issues with exclusionary patent agreements > and any possible solutions probably cannot be limited to Mono though it > is probably the most significant project since the current move sets > political if not legal precedent for patent claims in the future against > other distributions except Novell and even Novell if the agreement isnt > renewed after 5 years. > > Novell is working with Microsoft on virtualisation and openxml format > support which probably results in code to xen and openoffice.org both of > which has significant Novell developers working on them. If these > contributions are under GPL and LGPL respectively then the patent clause > in GPL automatically grants everyone else the necessary rights or would > prevent Novell from distributing the code to anyone. So we are probably > safe with that. Things for Legal to carefully look at. Right, things like OO.org and Xen are less issues due to licensing. However since Novell has the right to re-license Mono at any time, and its already mostly in a license that allows for their contributions, I feel it should be avoided. That's just my opinion. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Sun Nov 5 18:25:58 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 05 Nov 2006 19:25:58 +0100 Subject: late-March/late-October (was Re: [fab] looking at our surrent state a bit) In-Reply-To: <1162595765.27328.177.camel@erato.phig.org> References: <454B2300.8080900@leemhuis.info> <200611031120.41588.jkeating@redhat.com> <454B7F26.70309@leemhuis.info> <200611031252.42065.jkeating@redhat.com> <1162595765.27328.177.camel@erato.phig.org> Message-ID: <454E2CB6.1090607@leemhuis.info> While looking of this again I noticed a detail that confused me slightly: Karsten Wade schrieb: > On Fri, 2006-11-03 at 12:52 -0500, Jesse Keating wrote: >> On Friday 03 November 2006 12:40, Thorsten Leemhuis wrote: >>> Late march only once. I asked after FC5 on fedora-devel if we would >>> stick to "late march and late September" in the future again (+ some >>> delays if needed) and the answer was "no". >>> >>> But if we get our release to "round about late march and late September" >>> in the future I'd be very glad. >> It's something we shoot for, but flexibility is necessary for what we do. > Looking at the trending from Thorsten's list: > FC1 -- 5 November 2003 - General Availability > FC2 -- 18 May 2004 - General Availability > FC3 -- 8 November 2004 - General Availability > FC4 -- 13 June 2005 - General Availability > FC5 -- 20 March 2006 - General Availability > FC6 -- 24 October 2006 - General Availability > > The nine months for FC5 brought the schedule back into the > late-March/late-October flow again. [...] Why do you (and Jesse once in this thread, too) refer to "late-March/late-October"? That should be "late-March/late-September" (GNOME releases mid-March and mid-September) or "late-April/late-October" afaics (or something in between). Note, there are seven months between March and October, but only five between October and March... CU thl From jkeating at redhat.com Sun Nov 5 18:58:38 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 5 Nov 2006 13:58:38 -0500 Subject: late-March/late-October (was Re: [fab] looking at our surrent state a bit) In-Reply-To: <454E2CB6.1090607@leemhuis.info> References: <454B2300.8080900@leemhuis.info> <1162595765.27328.177.camel@erato.phig.org> <454E2CB6.1090607@leemhuis.info> Message-ID: <200611051358.42075.jkeating@redhat.com> On Sunday 05 November 2006 13:25, Thorsten Leemhuis wrote: > Why do you (and Jesse once in this thread, too) refer to > "late-March/late-October"? I mentioned it in reference to this year's release dates. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Sun Nov 5 21:47:34 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 06 Nov 2006 03:17:34 +0530 Subject: [fab] Most Advanced 100% Free Distribution? In-Reply-To: <454A06BB.10203@redhat.com> References: <454A0074.8070003@redhat.com> <454A048D.5000608@fedoraproject.org> <454A06BB.10203@redhat.com> Message-ID: <454E5BF6.4060601@fedoraproject.org> Warren Togami wrote: > Rahul Sundaram wrote: >> I am not sure what the kernel binary blobs in this PR refers to. >> AFAIK, the upstream kernel itself includes firmware which we dont >> remove in Fedora. Our guidelides dont require source for all firmware >> and just redistribution rights. >> > > Maybe we don't want to go this far. The benefits of redistributable > firmware perhaps greatly outweigh the ideological benefits. > > Firmware is nowhere near the level of evil as binary-only drivers > hooking into the kernel. Right. I have send a list of items a while back for FSF to go through and let me know their standing on them. I am waiting on that before we decide how far we want to go with Fedora regarding firmware. One of the interesting items that caught my attention in the announcement is "builder" which is described as a tool to create customized distributions. We have a lot of derivative distributions that sync back to Fedora on every release or so and we should be enabling them to do that and contribute back in a easy fashion. We might also have a need to do derivatives and respins within the project. Someone should look at what that tool does and whether it would fit into our needs. Rahul From katzj at redhat.com Sun Nov 5 22:16:36 2006 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 05 Nov 2006 17:16:36 -0500 Subject: [fab] looking at our surrent state a bit In-Reply-To: <1162595765.27328.177.camel@erato.phig.org> References: <454B2300.8080900@leemhuis.info> <200611031120.41588.jkeating@redhat.com> <454B7F26.70309@leemhuis.info> <200611031252.42065.jkeating@redhat.com> <1162595765.27328.177.camel@erato.phig.org> Message-ID: <1162764996.4136.5.camel@aglarond.local> On Fri, 2006-11-03 at 15:16 -0800, Karsten Wade wrote: > On Fri, 2006-11-03 at 12:52 -0500, Jesse Keating wrote: > > On Friday 03 November 2006 12:40, Thorsten Leemhuis wrote: > > > Late march only once. I asked after FC5 on fedora-devel if we would > > > stick to "late march and late September" in the future again (+ some > > > delays if needed) and the answer was "no". > > > > > > But if we get our release to "round about late march and late September" > > > in the future I'd be very glad. > > > > It's something we shoot for, but flexibility is necessary for what we do. > > Looking at the trending from Thorsten's list: [snip specific dates] > The nine months for FC5 brought the schedule back into the > late-March/late-October flow again. If this is important, I think we > all have some possibility of influencing that this stays this way; and I > think some influence may already be applied. I tend to agree that there's a lot of value in trying to align with "something" like this... and we've been spastic at times as to what the "something" we're aligning with is. gcc has been the driver once, xorg once, GNOME a few times... I think that GNOME might well be the reasonable thing in general, but I do want to try to give us time to reasonably integrate the GNOME release; the relatively identical timeframes for FC5 was a bit painful from my POV. Trying to align the freeze for ~ 2 weeks after the GNOME release gives time just to make sure that things are in good shape and have a little bit more of a) hititng the confidence and b) getting all the components updated and well tested. So rather than mid-September/March, I'd try to aim for freeze of early April/October. Which, funny enough, is what we were shooting for with FC6 :-) While I somewhat share Jesse's concern about a slip of one release short-changing the next, I think that the predictability might make it worthwhile. Especially since, realistically, 5 months vs 6 doesn't make a huge difference. A bigger win is looking at trying to get more frequent and earlier testing... but that's a topic for another thread. Jeremy From deisenst at gtw.net Mon Nov 6 09:29:30 2006 From: deisenst at gtw.net (David Eisenstein) Date: Mon, 6 Nov 2006 03:29:30 -0600 Subject: You Need Fedora Legacy!! Re: [fab] looking at our surrent state a bit References: <454B2300.8080900@leemhuis.info><454B4112.7030604@fedoraproject.org> <454B5DF0.90908@leemhuis.info> Message-ID: <009601c70186$1009c670$9962cfd0@homedns.org> ----- Original Message ----- From: "Thorsten Leemhuis" To: Sent: Friday, November 03, 2006 9:19 AM Subject: Re: [fab] looking at our surrent state a bit > >> == MISC == > >> > >> * I got the impression (and LWN readers, too ["hello corbert! "]) that > >> Fedora Legacy is not able to do it's job properly. Maybe it's time to > >> just revamp the whole project? > > How? > > Give it a fresh start, a new name (because the Term "Fedora Legacy" has > such a bad fame now), maybe try to get the load reduced (only support > releases with odd number for a longer time, drop old releases). Current Fedora Legacy status: see http://fedoraproject.org/wiki/Legacy/Status Thank you, Thorsten, for having the guts to say it -- at least about Legacy's reputation/infamy now. Of course, corbet had the guts to say it first here: http://lwn.net/Articles/204722/. Thanks, corbet. It needed to be said. The Fedora Project NEEDS Fedora Legacy! I repeat: The Fedora Project NEEDS Fedora Legacy in order to be a viable Linux distribution to be used for anything other than pushing the latest and greatest software out the door for Linux afficianados to play with and submit bugzilla tickets for. As Matthew Miller said at the beginning of Fedora Legacy's thread "lwn article on the death of Fedora Legacy," "Without a functioning lifespan of over a year, Fedora is only practically useful as an enthusiast, bleeding-edge distro. That's only supposed to be _part_ of its mission." -- http://tinyurl.com/ycl3zp Fedora Board, please take heed. Although providing a stable, long-term operating system/environment is *not* one of Fedora Project's stated goals, the practical lifetime of a Fedora release of 1 year (without Legacy to be there to security-maintain them for (at least) 1 more year) is ... ridiculous -- except for the Linux enthusiast and those who love sliding down the razor-blade of computing. The Fedora Legacy build team seems to be down now to 1 or 2 builders who can push packages to Legacy's updates-testing and updates. I am one of that team now, and am the slowest, most pedantic RPM packager/signer/pusher that you'd never wanna meet. The most sure-fire way of killing Fedora Legacy is to let me be the only one doing this essential activity with Fedora Legacy Core packages that need security updates in a timely fashion. Is this really what the Fedora Board and Red Hat wants? Although I am amid working with pushing a gzip security bug ( http://tinyurl.com/yhvh4a ) to updates-testing in the last few days, in general, Legacy Security Updates for FC3 and FC4 are simply not happening. Hopefully by Tuesday or so, this FC3/FC4 bug will at least be in updates-testing for folks to play with and judge, so it can quickly be pushed to updates (only about 2 months after Red Hat Enterprise Linux pushed similar security updates on these issues). In the history of the Fedora Legacy project, IMNSHO it has not been often that updates have been released quickly to end-users (after an security hole has been made public), unless there was a hue-and-cry over on the Fedora-legacy-list about, say, sendmail or some other server program that might allow, say, remotely-controlled anonymous root access to someone's box. I would love to see Fedora Legacy (by that name or any other name) take off and prosper, and be a real boon to users of maintenance-mode Fedora Core (and Red Hat Linux -- yes, we are continuing to roll some updates to RHL 7.3 and RHL9 until December ... um ... at least I think we are??). But as some folks have clearly said, until it does, at least to take care of the *critical* security bugs (letting the moderate or important or low-security-impact bugs slide until we have the manpower to handle them) -- THE EXISTENCE OF FEDORA LEGACY IS PROVIDING A FALSE SENSE OF SECURITY FOR OUR END-USERS ... at least at this time. If you don't believe that -- look at this article about Fedora Core 6 on eWeek Magazine's web-site, by the excellent writer, Jason Brooks: http://www.eweek.com/article2/0,1895,2048117,00.asp It's not the article, really, that proves my point. It's the article's talkback. I wish what commenter "unoengborg" was saying were true. Really, really, really wish. But it ain't -- not yet. Will it ever be? That's up to you, dear reader. I would like to propose a time folks interested in a vital and alive (even revamped) FedoraLegacy project can come on over to IRC (freenode.net) and sit and yack awhile, brainstorming and struggling with these issues. I plan to be online over on channel #fedora-legacy around 10am CST for at least two hours every day this week. Come by. Come chat. Come yell! Just come! We need your help! Thank you. Warm regards, David Eisenstein From fedora at leemhuis.info Mon Nov 6 16:31:01 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 06 Nov 2006 17:31:01 +0100 Subject: [fab] looking at our surrent state a bit In-Reply-To: <1162764996.4136.5.camel@aglarond.local> References: <454B2300.8080900@leemhuis.info> <200611031120.41588.jkeating@redhat.com> <454B7F26.70309@leemhuis.info> <200611031252.42065.jkeating@redhat.com> <1162595765.27328.177.camel@erato.phig.org> <1162764996.4136.5.camel@aglarond.local> Message-ID: <454F6345.1000003@leemhuis.info> Jeremy Katz schrieb: > On Fri, 2006-11-03 at 15:16 -0800, Karsten Wade wrote: >> On Fri, 2006-11-03 at 12:52 -0500, Jesse Keating wrote: >>> On Friday 03 November 2006 12:40, Thorsten Leemhuis wrote: >[...] >>>> But if we get our release to "round about late march and late September" >>>> in the future I'd be very glad. >>> It's something we shoot for, but flexibility is necessary for what we do. >> Looking at the trending from Thorsten's list: > [snip specific dates] >> The nine months for FC5 brought the schedule back into the >> late-March/late-October flow again. If this is important, I think we >> all have some possibility of influencing that this stays this way; and I >> think some influence may already be applied. > > I tend to agree that there's a lot of value in trying to align with > "something" like this... and we've been spastic at times as to what the > "something" we're aligning with is. gcc has been the driver once, xorg > once, GNOME a few times... I think that GNOME might well be the > reasonable thing in general, Side note: That would align our schedule slightly with Ubuntu. Gcc, x.org, some other projects and authors auf hardware driver due to that might even say "hey, we know Ubuntu and Fedora release in April and October normally, so if we want to have our stuff integrated there we need to get it upstream in January/July (better earlier) to get it included there." That could be nice for everyone (if it really works out that way). > but I do want to try to give us time to > reasonably integrate the GNOME release; the relatively identical > timeframes for FC5 was a bit painful from my POV. Trying to align the > freeze for ~ 2 weeks after the GNOME release gives time just to make > sure that [...] +1 > [...] Cu thl From mspevack at redhat.com Mon Nov 6 16:41:52 2006 From: mspevack at redhat.com (Max Spevack) Date: Mon, 6 Nov 2006 11:41:52 -0500 (EST) Subject: [fab] State of Fedora (a long email) Message-ID: I've read through all the emails that hit f-a-b last week, and I spent the better part of the weekend thinking about everything that was in it. I think it was a great discussion. I didn't chime in until now because I wanted to just watch the conversation evolve and see what people were saying. As Thorsten pointed out in the email that started the thread, FC6 is a very good release. We got some good features into it, the quality is good, and the Fedora Docs, Extras, and Unity projects in particular have done a tremendous amount of good work. Tomorrow is two weeks out of the release date -- on bittorrent we've already achieved 30% of what our total activity for all of fc5 has been. THE BOARD ========= One of the things that is true about Fedora is that this fedora-advisory-board email list is *THE PLACE* where the interesting Fedora conversations are had. Far more so than any phone calls that the Board has. The most important business is conducted on this list. That said, let's address some of the cricitism about the way the Board conducts its meetings. The choice to have those meetings on the phone, as opposed to on IRC, was one that was made by the Board when we started up, the main reason being the ones that Paul stated -- phone calls are higher bandwidth, and the idea is to get everyone in that call on the same page as quickly as possible. If the Board wants to change its meeting "mechanism" I don't have a problem with that. It can be put up to discussion/vote in our next meeting (tomorrow). There are some very specific complaints that I saw about the Board, and I am 100% at fault for those complaints existing, and I need to be the one to fix it. 1) The wiki is not as up to date as it should be. 2) Insufficient communication about the rescheduling or cancellation of Board meetings. We initially set out to have the Board meet twice a month. For a while, we were quite religious about that. Fedora Core 6's release, as it got closer, played havoc with that schedule. Part of that was the fact that the "getting the release finished" work just took priority over everything else, and part of it was the fact that everyone was in much more frequent communication with each other anyway. A big part of what the phone calls are meant for is a chance for everyone on the Board to get on the same page. So the better our communication is *in between calls*, the *less need* there is for those calls themselves. Like the rest of you, I prefer to see the big decisions made on-list, where there are public archives and anyone in the Fedora community can participate. The Fedora Board is not meant to be a bottleneck -- it's meant to be a guide. Some of the places in the thread from last week mentioned that the Board should involve itself more into decisions. I don't know about that -- there's been several cases where the Board has stepped in in the last few months and "made a decision" about some topic, but those were only situations in which it seemed like the folks who were closest to those decisions had reached an impasse. I don't necessarily like the idea of the Board just swooping in and declaring things about certain projects that already have their own leadership in place. That's not what we're meant to do, and that's not how we're operating. If the Fedora Community would like to see more assertive leadership, of that kind, from the Board, I'm sure we could do it. But at least in my handling of the Board, I prefer to leave the decision making to the folks who are actually doing the engineering work, because by and large they are smarter and more-capable of making the correct decisions than someone who isn't as close (and therefore doesn't know) all of the details and nuances. NEXT FEDORA BOARD MEETING ========================= Tuesday 11/7 -- that's tomorrow. 1) Talk about how the Board is functioning. Do we change the way we meet? Do we change the frequency of our meetings? How can we do a better job, as per the discussion of the last few days? 2) RPM problem. My understanding was that we'd taken several steps to solve the RPM issues a month or so ago. Make sure everyone on the Board understands what the *current problems* are, and let's see if we can't figure out a plan to solve that. 3) Get some input from the Board about any of the topics that are down below -- just hear what people have to say, or care deeply about. Basically a FC6 postmortem. FEDORA SUMMIT ============= Sunday 11/12 - Wednesday 11/15 Max Spevack, Greg DeKoenigsberg, and Bill Nottingham are heading up to Westford. Folks we will be spending our time with: Chris Blizzard, Warren Togami, Dave Jones, Jeremy Katz, Jesse Keating. Those are the primaries. Probably many others. The goal is to come out of those days with: A first pass at a public FC7 roadmap/goals, which will be up for review by everyone on f-a-b, including the Fedora Board. Because *some* of the folks on the Board will be in those meetings, but not all, as it's basically just a bunch of us Red Hat folks getting together -- though in fairness it is the Red Hat folks who are closest to the Fedora Project. We will also make it a priority to have an IRC channel open on Mon, Tue, and Wed that people can be a part of, in which we will do our best to "broadcast" what we are discussing at any time. We'll also do an "end of day" summary like Karsten asked for, and publish as complete a transcript of what's going on as we can manage. OTHER TOPICS ============ - Fedora Legacy Topic for Fedora Summit - Fedora Directory Server This actually has some traction, I'd like its full integration to be one of the things on our roadmap for FC7 - RPM problem Topic for 11/7 FPB meeting - improvements in our own stack (anaconda, config tools, init scripts) Topics for Fedora Summit - VCS Jesse doing work on this, topic for Fedora Summit - abolish Core The *main topic* for the Fedora Summit, including Jesse's work on "pungi" or however you spell it :-) - Live CD "Official" builds like Thorsten asked for should be on our FC7 roadmap. I'd like to see better bugzilla integration as well. - Desktop usability (acroread, java, flash, etc.) This is the post controversial topic of all. Greg and I have been spending a lot of time on this. It's a further topic for the Fedora Board and Fedora Summit. - When do we release? Topic for the Fedora Summit - random topics Max thinks should be discussed for FC7 - support upgrades via yum *way better* than we do - changes to init being planned, or should they be? - the future life of fedora.redhat.com - how do we never have another release like fc6 in terms of website stuff? FINAL THOUGHTS ============== Reading through all of those emails, the one thing that really struck me and made me think was the comment that "everything in Fedora takes a long time." I agree. And I hate it. But I don't know how to fix it, other than just by continuing to push through barriers when they come up. If I sit back and try to evaluate the work that I have done since I took the job of "Fedora Project Leader" back in mid February, I certainly don't think I'd give myself top marks. I think I've done a good, but by no means fantastic job. I think it can be objectively said that Fedora is better now than it was, say, a year ago, but I also don't think Fedora is living up to its full potential. At any point in time the number of "sev 1" issues that compete for my attention is far more than I can even pay attention to, let along handle individually. So I spend a lot of time trying to delegate, or put another way, allowing the people closest to the decisions to make the ones that they think are best. So maybe this is the place where I try to ask the rest of the Fedora leadership to continue to help me -- and the best way to help is by continuing to be the leaders that you are. When I do my job every day, I feel like it is very split. There's the community-facing part of my job -- the part that all of you reading this see, and the part based upon which you form your opinions of whether or not I am a competent leader for Fedora. And then there's the internal to Red Hat part of my job -- the things that Matthew holds me accountable for, the positioning of Fedora next to our competition (be it Oracle or Ubuntu), the financial issues at play, the legal questions, and all the internal politics that come along with being part of a company. So there's some weeks in which I spend a lot of my time doing work that is "visible" to the rest of the Fedora Community and other weeks in which I'm not as visible. But that doesn't mean I'm not here, or not paying attention to Fedora. It just means that there's a lot of things competing for my time, and I can't do everything. I know that "burnout" is a taboo word in engineering circles, but that doesn't mean it isn't real. And that's why, when I think about the people who are most essential to the success of Fedora, the common trait that everyone on that list has is that they are strong leaders on their own -- capable of deciding what they think is best and then taking action. Anyway, I hope this email has answered some of the major topics from this list the last few days. I hope people feel like there's some organization to the planning that will happen in the next couple of weeks, and that the folks who won't be physically in those meetings will feel like they have insight into what's going on. -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From fedora at leemhuis.info Mon Nov 6 19:21:44 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 06 Nov 2006 20:21:44 +0100 Subject: [fab] State of Fedora (a long email) In-Reply-To: References: Message-ID: <454F8B48.3070609@leemhuis.info> Hi, Max, many thanks for your mail and your (and the Boards) work on Fedora. I know, my mail was quite a bit of a rant, but I hope thats okay now and then. I don't want to start yet another long discussion, but I think I should comment on some parts of your mail as I'm part of the reasons why it was written. Max Spevack schrieb: > [....] > One of the things that is true about Fedora is that this > fedora-advisory-board email list is *THE PLACE* where the interesting > Fedora conversations are had. Far more so than any phone calls that the > Board has. The most important business is conducted on this list. Agreed, at that's a good thing. > [....] > The choice to have those meetings on the phone, as opposed to on IRC, was > one that was made by the Board when we started up, the main reason being > the ones that Paul stated -- phone calls are higher bandwidth, and the > idea is to get everyone in that call on the same page as quickly as > possible. If the Board wants to change its meeting "mechanism" I don't > have a problem with that. It can be put up to discussion/vote in our next > meeting (tomorrow). Just to clarify: I think phone meetings are fine (well, I don't like them much, but I don't have to participate in those from the Board (-; ), but having some kind of open meetings on IRC now and then or have a kind of "consulting-hour" might be something nice in addition (and no, not all members need to participate in that "consulting-hour", but at least three or four should). > [...] > Like the rest of you, I prefer to see the big decisions made on-list, > where there are public archives and anyone in the Fedora community can > participate. Well, this list is invitation only, fedora-devel is much to noisy. I'm *wondering* if we should have some kind of "fedora-project-discussions" mailinglist, where any member of cla_done in the accounts system can participate (or even all? maybe moderated?). > The Fedora Board is not meant to be a bottleneck -- it's meant to be a > guide. Some of the places in the thread from last week mentioned that the > Board should involve itself more into decisions. I don't know about that Site note to that: Involve does not have to mean make the decisions for the sub-projects. It could guide here now and then, especially on big tasks (e.g. ask "Can we help with to get foo take off/realized?") or if the project isn't working properly (e.g. like Legacy currently). Also mediating between the different sub-projects maybe could help here and there. > -- there's been several cases where the Board has stepped in in the last > few months and "made a decision" about some topic, but those were only > situations in which it seemed like the folks who were closest to those > decisions had reached an impasse. > > I don't necessarily like the idea of the Board just swooping in and > declaring things about certain projects that already have their own > leadership in place. That's not what we're meant to do, and that's not > how we're operating. Agreed in general -- but currently it's not possible for community members to influence our biggest sub-project (Core) and maybe that was one of the reasons why I asked for above. A proper "Fedora Core Steering Committee" with community members could help to silence that wish. > [...] > FEDORA SUMMIT > ============= > [...] > We will also make it a priority to have an IRC channel open on Mon, Tue, > and Wed that people can be a part of, in which we will do our best to > "broadcast" what we are discussing at any time. What about the evening sessions? Will there be some beer, Tequilla Sunrise and Apple-juice available on IRC in the evenings after the hard work is done? > We'll also do an "end of day" summary like Karsten asked for, and publish > as complete a transcript of what's going on as we can manage. Nice, many thx. > OTHER TOPICS > ============ > [...] > - Desktop usability (acroread, java, flash, etc.) > This is the post controversial topic of all. Greg and I have been > spending a lot of time on this. It's a further topic for the Fedora Board > and Fedora Summit. My 2 cents on that: Let the Fedora Unity project handle that in a special sub-project, but help them to get it realized -- It's simply much easier for someone at redhat.com to get an answer when knocking on Adobe's/Sun's door and asking "may we ship your product in a add-one yum repo named foo". > [...] > FINAL THOUGHTS > ============== > > Reading through all of those emails, the one thing that really struck me > and made me think was the comment that "everything in Fedora takes a long > time." > > I agree. And I hate it. But I don't know how to fix it, other than just > by continuing to push through barriers when they come up. Well, my 2 cents: I sometimes think the Fedora Project and it's sub-projects could need a bit of more support by Red Hat/someone that gets payed for that work. It's probably not that much that is missing, and I think just one person could help it a lot as long as he isn't assimilated into the internal Red Hat collective ^w machinery ^w workflow to much (but enough to get things realized). (And just for completeness: That might sound as I wanted to do that job -- maybe somewhen in the future I might be interested in that, but currently I'm quite happy with my present job). > If I sit back > and try to evaluate the work that I have done since I took the job of > "Fedora Project Leader" back in mid February, I certainly don't think I'd > give myself top marks. I think I've done a good, but by no means > fantastic job. I think you did a good job and things are evolving. That takes time (I invested quite some time in this discussion and should wanter off again to get the work in Extras-land done -- there is also still so much to do). > [some insight to Max's thoughts] As I said: Many thanks for your work. It is much appreciated. > Anyway, I hope this email has answered some of the major topics from this > list the last few days. [...] It did for me. Thanks for summing them up. CU thl From sundaram at fedoraproject.org Mon Nov 6 19:30:21 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 07 Nov 2006 01:00:21 +0530 Subject: [fab] State of Fedora (a long email) In-Reply-To: <454F8B48.3070609@leemhuis.info> References: <454F8B48.3070609@leemhuis.info> Message-ID: <454F8D4D.7090705@fedoraproject.org> Thorsten Leemhuis wrote: > Well, this list is invitation only, Others do send mails to this list. It is moderated. fedora-devel is much to noisy. I'm > *wondering* if we should have some kind of "fedora-project-discussions" > mailinglist, where any member of cla_done in the accounts system can > participate (or even all? maybe moderated?). Fedora maintainers was supposed to be something like that. I dont think creating more mailing lists is the answer here. Instead of ignoring fedora-devel list as noise, bear with it and post more discussions there for general development ideas. Maintainers should be used in a limited fashion. > > Agreed in general -- but currently it's not possible for community > members to influence our biggest sub-project (Core) and maybe that was > one of the reasons why I asked for above. A proper "Fedora Core Steering > Committee" with community members could help to silence that wish. If core doesnt exist in the future, then it would be something like a Fedora Techinical Committee that oversees the entire Fedora development. I am not sure whether this needs to be a elected set of people though. Rahul From tcallawa at redhat.com Mon Nov 6 13:19:40 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 06 Nov 2006 07:19:40 -0600 Subject: [fab] Fwd: Mono and FC In-Reply-To: <454E12BC.1020906@fedoraproject.org> References: <200611041655.30372.jkeating@redhat.com> <1162688261.18994.19.camel@localhost.localdomain> <454DFBBA.40100@fedoraproject.org> <200611051107.11230.jkeating@redhat.com> <454E12BC.1020906@fedoraproject.org> Message-ID: <1162819180.4623.0.camel@dhcp-32-121.ord.redhat.com> On Sun, 2006-11-05 at 22:05 +0530, Rahul Sundaram wrote: > If these contributions are under GPL and LGPL respectively then the patent clause > in GPL automatically grants everyone else the necessary rights or would > prevent Novell from distributing the code to anyone. So we are probably > safe with that. Things for Legal to carefully look at. The same would be true for ntfsprogs, which SuSE is shipping. ~spot From fedora at leemhuis.info Mon Nov 6 20:31:14 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 06 Nov 2006 21:31:14 +0100 Subject: [fab] State of Fedora (a long email) In-Reply-To: <454F8D4D.7090705@fedoraproject.org> References: <454F8B48.3070609@leemhuis.info> <454F8D4D.7090705@fedoraproject.org> Message-ID: <454F9B92.7070805@leemhuis.info> Rahul Sundaram schrieb: > Thorsten Leemhuis wrote: >> Well, this list is invitation only, > Others do send mails to this list. It is moderated. Didn't know that. And it seems that fact is not documented in the wiki or the list's front-page. >> fedora-devel is much to noisy. I'm >> *wondering* if we should have some kind of "fedora-project-discussions" >> mailinglist, where any member of cla_done in the accounts system can >> participate (or even all? maybe moderated?). > Fedora maintainers was supposed to be something like that. And it failed. So let's admit that and change something (fedora-maintainers has quite a bad fame now already, so changing its behaviour will probably not help much). Further: cvs_cladone and cvs_extras/a @redhat.com mailing list address are two different things. > I dont think > creating more mailing lists is the answer here. I want a general mailing list cleanup of what has grown in the past years -- get rid of some old cruft here and there. I think the end-result could be two or three lists less and a better communication experience for everyone. > [...] CU thl From sundaram at fedoraproject.org Mon Nov 6 20:37:47 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 07 Nov 2006 02:07:47 +0530 Subject: [fab] State of Fedora (a long email) In-Reply-To: <454F9B92.7070805@leemhuis.info> References: <454F8B48.3070609@leemhuis.info> <454F8D4D.7090705@fedoraproject.org> <454F9B92.7070805@leemhuis.info> Message-ID: <454F9D1B.7020509@fedoraproject.org> Thorsten Leemhuis wrote: > Rahul Sundaram schrieb: >> Thorsten Leemhuis wrote: >>> Well, this list is invitation only, >> Others do send mails to this list. It is moderated. > > Didn't know that. And it seems that fact is not documented in the wiki > or the list's front-page. There is even a alias setup that people can send mails to. http://fedoraproject.org/wiki/Board#Contact. I have explicitly added a note now. > And it failed. I believe it is still only contributors who are signed up there. So let's admit that and change something > (fedora-maintainers has quite a bad fame now already, so changing its > behaviour will probably not help much). If contributors flame each other, even a contributors only list like -maintainers is going to be a less pleasant place. > > Further: cvs_cladone and cvs_extras/a @redhat.com mailing list address > are two different things. Yes. Fedora-maintainers is all contributors. Not just extras. > > I want a general mailing list cleanup of what has grown in the past > years -- get rid of some old cruft here and there. I think the > end-result could be two or three lists less and a better communication > experience for everyone. More details? Rahul From fedora at leemhuis.info Mon Nov 6 21:24:22 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 06 Nov 2006 22:24:22 +0100 Subject: [fab] State of Fedora (a long email) In-Reply-To: <454F9D1B.7020509@fedoraproject.org> References: <454F8B48.3070609@leemhuis.info> <454F8D4D.7090705@fedoraproject.org> <454F9B92.7070805@leemhuis.info> <454F9D1B.7020509@fedoraproject.org> Message-ID: <454FA806.6060505@leemhuis.info> Rahul Sundaram schrieb: > Thorsten Leemhuis wrote: >> Rahul Sundaram schrieb: >>> Thorsten Leemhuis wrote: >>>> Well, this list is invitation only, >>> Others do send mails to this list. It is moderated. >> Didn't know that. And it seems that fact is not documented in the wiki >> or the list's front-page. > There is even a alias setup that people can send mails to. > http://fedoraproject.org/wiki/Board#Contact. I have explicitly added a > note now. Thx -- in an ideal world http://www.redhat.com/mailman/listinfo/fedora-advisory-board and http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly would mention that fact, too. But well, the wiki should suffice. >> And it failed. > I believe it is still only contributors who are signed up there. The problem is not that there are "still only contributors signed up there", the problem is that contributors did not get signed up there or left again after some time/send the traffic to /dev/null now because there were flamewars or unimportant stuff was discussed. Site note: To solve this problem Extras requested a moderated, low-traffic "fedora-maintainers-annouce" list to make it possible to announce stuff to a all maintainers easily. Core blocked it, warren (in his function as FESCo member) is discussing this with Jesse currently (maybe there are some results in between, but nobody told me about). > So let's admit that and change something Needs a new name IMHO, as the current one has quite a bad fame already. >> (fedora-maintainers has quite a bad fame now already, so changing its >> behaviour will probably not help much). > If contributors flame each other, even a contributors only list like > -maintainers is going to be a less pleasant place. We'd probably should have jumped in and made the list moderated for two days when the last flamewar happened. To late now. >> Further: cvs_cladone and cvs_extras/a @redhat.com mailing list address >> are two different things. > Yes. Fedora-maintainers is all contributors. Not just extras. That's news to me (I'm a list admin there since some weeks -- I requested that after I noticed that new members tried to sign up there but were never accepted and gave up after some time). And look at https://www.redhat.com/mailman/listinfo/fedora-maintainers Quoting: "This is the list for maintainers of packages in Fedora Core and Fedora Extras." So no, Fedora-maintainers is not all contributors, it's just "maintainers" (hence the name) >> I want a general mailing list cleanup of what has grown in the past >> years -- get rid of some old cruft here and there. I think the >> end-result could be two or three lists less and a better communication >> experience for everyone. > More details? Quick and dirty braindump: - merge fedora-test into fedora-devel -- people often don't get the difference in any case - rename fedora-maintainers to fedora-contributors or fedora-project -- all people with cla_done get permitted, moderated for nearly everybody else. - start using fedora-maintainers-announce (see above) - delete: - fedora-config-list -- mostly dead, and people did not understand what its use in any case - fedora-patches-list -- dead ? - fedora-tools-list -- mostly dead? Site note: We should create a rough mailing list guideline for Fedora, as it is highly confusing that the lists are configured quite differently (reply-to munging , Tags in the Subject the two most [only?] important things). CU thl From sundaram at fedoraproject.org Mon Nov 6 21:32:28 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 07 Nov 2006 03:02:28 +0530 Subject: [fab] State of Fedora (a long email) In-Reply-To: <454FA806.6060505@leemhuis.info> References: <454F8B48.3070609@leemhuis.info> <454F8D4D.7090705@fedoraproject.org> <454F9B92.7070805@leemhuis.info> <454F9D1B.7020509@fedoraproject.org> <454FA806.6060505@leemhuis.info> Message-ID: <454FA9EC.3090600@fedoraproject.org> Thorsten Leemhuis wrote: > Quick and dirty braindump: > > - merge fedora-test into fedora-devel -- people often don't get the > difference in any case Test updates and test release discussions should be send to fedora-devel? That would result in too much traffic in fedora-devel IMO. We are planning to have more QA discussions and send the results of the test suite in the future to fedora-test list too. > - rename fedora-maintainers to fedora-contributors or fedora-project -- > all people with cla_done get permitted, moderated for nearly everybody else. > - start using fedora-maintainers-announce (see above) These are fine. > - delete: > - fedora-config-list -- mostly dead, and people did not understand what > its use in any case > - fedora-patches-list -- dead ? > - fedora-tools-list -- mostly dead? The last three are already dead. We dont delete mailing lists since we want to keep the archives. > > Site note: We should create a rough mailing list guideline for Fedora, > as it is highly confusing that the lists are configured quite > differently (reply-to munging , Tags in the Subject the two most [only?] > important things). Right. Rahul From jkeating at redhat.com Mon Nov 6 21:32:36 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Nov 2006 16:32:36 -0500 Subject: [fab] State of Fedora (a long email) In-Reply-To: <454FA806.6060505@leemhuis.info> References: <454F9D1B.7020509@fedoraproject.org> <454FA806.6060505@leemhuis.info> Message-ID: <200611061632.36686.jkeating@redhat.com> On Monday 06 November 2006 16:24, Thorsten Leemhuis wrote: > The problem is not that there are "still only contributors signed up > there", the problem is that contributors did not get signed up there or > left again after some time/send the traffic to /dev/null now because > there were flamewars or unimportant stuff was discussed. > > Site note: To solve this problem Extras requested a moderated, > low-traffic "fedora-maintainers-annouce" list to make it possible to > announce stuff to a all maintainers easily. Core blocked it, warren (in > his function as FESCo member) is discussing this with Jesse currently > (maybe there are some results in between, but nobody told me about). This was discussed between Warren, Jeremy Katz, and myself. The solution to the problem is to not create yet another mailing list, its to enforce the list for the purpose it was meant for. Announcements most often spawn discussions (see my announcement re dist-hg), having it span two lists or dealing with a readonly -> read/write list is bothersome and confusing. (yes, I know we have fedora-package-announce and fedora-announce set up that way, but those usually have less conversations attached to them). All maintainers should be on fedora-maintainers, so one should be able to announce stuff AND discuss it there. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gdk at redhat.com Mon Nov 6 23:21:02 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Mon, 6 Nov 2006 18:21:02 -0500 (EST) Subject: [fab] [Fedora-marketing-list] suse/opensuse contributors For Fedora ? (fwd) Message-ID: Maybe something worth discussing specifically next week: the status of KDE. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- ---------- Forwarded message ---------- Date: Sat, 4 Nov 2006 13:10:30 +0100 From: Chitlesh GOORAH Reply-To: fedora-marketing-list at redhat.com To: Fedora Marketing List Subject: [Fedora-marketing-list] suse/opensuse contributors For Fedora ? Hello there, Like many of you have seen in many mailing lists, suse/opensuse users and contributors are disgusted. Here, these users/contributors are mostly pro-kde, it's normal because it's suse. However some/these contributors are in search of another distro who supports KDE. Since Fedora Project already started working on UnleashKDE and will be looking for community fedora KDE contributors, I feel we need to market more on Fedora's KDE status and community contributors are respected! The idea came when a friend of mine, - a KDE contributor who spends time writing documentation and do french translation - user of opensuse suddenly seriously looking for another distro who supports KDE. People like him would be useful for the fedora community !! What do you think about it ? Any plans to make fedora benefit from this ? Even if you are not a KDE user, you can still have your say,huh! chitlesh -- http://clunixchit.blogspot.com -- Fedora-marketing-list mailing list Fedora-marketing-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list From gdk at redhat.com Mon Nov 6 23:34:49 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Mon, 6 Nov 2006 18:34:49 -0500 (EST) Subject: [fab] Fwd: Mono and FC In-Reply-To: <20061104223256.GA2924@domsch.com> References: <200611041655.30372.jkeating@redhat.com> <20061104223256.GA2924@domsch.com> Message-ID: IANAL, but I do talk with lawyers a lot. It's my understanding that the patents granted to OIN by Novell still belong to OIN, and all of the signatories are still bound to defend technologies covered by OIN. Of which Mono is one. --g On Sat, 4 Nov 2006, Matt Domsch wrote: > On Sat, Nov 04, 2006 at 04:55:30PM -0500, Jesse Keating wrote: >> Probably something we should look into and make a statement about. > > Mono got into Core on the promise of OIN, so fundamentally we need a > statement from OIN. Unless OIN is undone, we shouldn't revisit this > every time someone raises the patent boogeyman spectre. If OIN is > undone, then yes, Mono and related covered activities (NTFS?) are out. > > My 2 cents. > -Matt > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > -- ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From fedora at leemhuis.info Tue Nov 7 06:01:40 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 07 Nov 2006 07:01:40 +0100 Subject: [fab] State of Fedora (a long email) In-Reply-To: <454FA9EC.3090600@fedoraproject.org> References: <454F8B48.3070609@leemhuis.info> <454F8D4D.7090705@fedoraproject.org> <454F9B92.7070805@leemhuis.info> <454F9D1B.7020509@fedoraproject.org> <454FA806.6060505@leemhuis.info> <454FA9EC.3090600@fedoraproject.org> Message-ID: <45502144.2090301@leemhuis.info> Rahul Sundaram schrieb: > Thorsten Leemhuis wrote: >> Quick and dirty braindump: >> - merge fedora-test into fedora-devel -- people often don't get the >> difference in any case > Test updates and test release discussions should be send to > fedora-devel? That would result in too much traffic in fedora-devel IMO. Well, people post stuff there that should go to "testing" instead. Just look at the archives -- 50% of the user-initialized threads on fedora-devel would be more suitable for fedora-test list. Heck it even happens now and then that different threads on the same topic/problem get run on both lists by different people. The solution doesn't have to be to merge the threads. But maybe try harder to enforce what lands on fedora-devel. > [...] >> - rename fedora-maintainers to fedora-contributors or fedora-project -- >> all people with cla_done get permitted, moderated for nearly everybody else. >> - start using fedora-maintainers-announce (see above) > These are fine. > >> - delete: >> - fedora-config-list -- mostly dead, and people did not understand what >> its use in any case >> - fedora-patches-list -- dead ? >> - fedora-tools-list -- mostly dead? > The last three are already dead. We dont delete mailing lists since we > want to keep the archives. Then disable them and mark them as retired. People post there, sometimes don't even get replied and get confused by all that. >[...] CU thl From fedora at leemhuis.info Tue Nov 7 06:07:30 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 07 Nov 2006 07:07:30 +0100 Subject: [fab] State of Fedora (a long email) In-Reply-To: <200611061632.36686.jkeating@redhat.com> References: <454F9D1B.7020509@fedoraproject.org> <454FA806.6060505@leemhuis.info> <200611061632.36686.jkeating@redhat.com> Message-ID: <455022A2.7000700@leemhuis.info> Jesse Keating schrieb: > On Monday 06 November 2006 16:24, Thorsten Leemhuis wrote: >> The problem is not that there are "still only contributors signed up >> there", the problem is that contributors did not get signed up there or >> left again after some time/send the traffic to /dev/null now because >> there were flamewars or unimportant stuff was discussed. >> Site note: To solve this problem Extras requested a moderated, >> low-traffic "fedora-maintainers-annouce" list to make it possible to >> announce stuff to a all maintainers easily. Core blocked it, warren (in >> his function as FESCo member) is discussing this with Jesse currently >> (maybe there are some results in between, but nobody told me about). > This was discussed between Warren, Jeremy Katz, and myself. The solution to > the problem is to not create yet another mailing list, its to enforce the > list for the purpose it was meant for. Announcements most often spawn > discussions (see my announcement re dist-hg), having it span two lists or > dealing with a readonly -> read/write list is bothersome and confusing. Well, there are a lot of people in Extras land that are not interested in the discussions. They only want the announcements. I'm strongly inclined to do it just for Extras if Core doesn't want to participate. Well, we'll discuss it in the next FESCo meeting. CU thl From bugs.michael at gmx.net Tue Nov 7 12:02:25 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 7 Nov 2006 13:02:25 +0100 Subject: fedora-maintainers et al [fab] State of Fedora (a long email) In-Reply-To: <455022A2.7000700@leemhuis.info> References: <454F9D1B.7020509@fedoraproject.org> <454FA806.6060505@leemhuis.info> <200611061632.36686.jkeating@redhat.com> <455022A2.7000700@leemhuis.info> Message-ID: <20061107130225.9db7017c.bugs.michael@gmx.net> On Tue, 07 Nov 2006 07:07:30 +0100, Thorsten Leemhuis wrote: > Jesse Keating schrieb: > > On Monday 06 November 2006 16:24, Thorsten Leemhuis wrote: > >> The problem is not that there are "still only contributors signed up > >> there", the problem is that contributors did not get signed up there or > >> left again after some time/send the traffic to /dev/null now because > >> there were flamewars or unimportant stuff was discussed. > >> Site note: To solve this problem Extras requested a moderated, > >> low-traffic "fedora-maintainers-annouce" list to make it possible to > >> announce stuff to a all maintainers easily. Core blocked it, warren (in > >> his function as FESCo member) is discussing this with Jesse currently > >> (maybe there are some results in between, but nobody told me about). > > This was discussed between Warren, Jeremy Katz, and myself. The solution to > > the problem is to not create yet another mailing list, its to enforce the > > list for the purpose it was meant for. Announcements most often spawn > > discussions (see my announcement re dist-hg), having it span two lists or > > dealing with a readonly -> read/write list is bothersome and confusing. > > Well, there are a lot of people in Extras land that are not interested > in the discussions. They only want the announcements. I'm strongly > inclined to do it just for Extras if Core doesn't want to participate. > Well, we'll discuss it in the next FESCo meeting. Looking at the fedora-maintainers list archives, it does not become clear at all what the purpose [and target group] of that list is and what its content guidelines are. Clearly a lot of the content on that list since May 2005 cannot be considered a required reading by *all* Fedora maintainers. And please, don't just ask "For example?", but skim over the archives yourself. Adding to that, after it had been said that all Fedora Extras package maintainers get subscribed to the list automatically and that subscription is mandatory, this has not become true. It is not even clear whether all Core maintainers are subscribed to the list. Effectively, there is no way to address *all* maintainers and no way either to address all Extras maintainers, because fedora-extras-list is avoided like the plague by [probably many] Extras packagers due to past review-traffic madness. Apart from that, commenting on messages to fedora-extras-commits becomes inconvienient and inefficient, because its "Reply-To:" to fedora-extras-list at redhat.com is the wrong target as the packager might not be subscribed there. [...] The purpose of fedora-test-list has always been questionable, but previous comments about it have only fallen on deaf ears. The list summary says: "For testers of Fedora Core development releases" which overlaps with the description of fedora-devel-list. But first of all, it merges official Test Releases and Rawhide and also adds announcements for Test Updates for stable releases of FC. Plus, there are lists internal to Red Hat which are preferred by Core maintainers over fedora-devel-list, because the s/n ratio on fedora-devel-list is disliked. From Christian.Iseli at licr.org Tue Nov 7 12:43:06 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 7 Nov 2006 13:43:06 +0100 Subject: fedora-maintainers et al [fab] State of Fedora (a long email) In-Reply-To: <20061107130225.9db7017c.bugs.michael@gmx.net> References: <454F9D1B.7020509@fedoraproject.org> <454FA806.6060505@leemhuis.info> <200611061632.36686.jkeating@redhat.com> <455022A2.7000700@leemhuis.info> <20061107130225.9db7017c.bugs.michael@gmx.net> Message-ID: <20061107134306.6d6a373c@ludwig-alpha.unil.ch> On Tue, 7 Nov 2006 13:02:25 +0100, Michael Schwendt wrote: > Effectively, there is no way > to address *all* maintainers and no way either to address all Extras > maintainers, because fedora-extras-list is avoided like the plague by > [probably many] Extras packagers due to past review-traffic madness. I do not know on what evidence you base your assertion that f-e-l is "avoided like the plague", but if it is true I find it a real problem. IMHO, all Extras contributors must be subscribed to f-e-l, or browse the archives on a regular basis. I have zero sympathy for those telling me there is too much traffic there. We can agree on policies to put keywords in the subject line for announcements or other "general audience" topics if that makes filtering easier, but I think subscription should be mandatory. Also IMHO, we need one list able to reach *all* Fedora contributors. I don't care how it's named, but we need one, and it should be made clear to all that (at least one of) the goals of that list is to reach all Fedora contributors. C From bugs.michael at gmx.net Tue Nov 7 13:08:16 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 7 Nov 2006 14:08:16 +0100 Subject: fedora-maintainers et al [fab] State of Fedora (a long email) In-Reply-To: <20061107134306.6d6a373c@ludwig-alpha.unil.ch> References: <454F9D1B.7020509@fedoraproject.org> <454FA806.6060505@leemhuis.info> <200611061632.36686.jkeating@redhat.com> <455022A2.7000700@leemhuis.info> <20061107130225.9db7017c.bugs.michael@gmx.net> <20061107134306.6d6a373c@ludwig-alpha.unil.ch> Message-ID: <20061107140816.e4b23779.bugs.michael@gmx.net> On Tue, 7 Nov 2006 13:43:06 +0100, Christian Iseli wrote: > On Tue, 7 Nov 2006 13:02:25 +0100, Michael Schwendt wrote: > > Effectively, there is no way > > to address *all* maintainers and no way either to address all Extras > > maintainers, because fedora-extras-list is avoided like the plague by > > [probably many] Extras packagers due to past review-traffic madness. > > I do not know on what evidence you base your assertion that f-e-l is > "avoided like the plague", It's the experience I've made by talking to multiple packagers in private mail after pointing them to a message in the list archives. [As might be known, a few of us do reply to fedora-extras-commits diffs occasionally and then find out that the packagers don't see the messages sent to fedora-extras-list (and, btw, are not subscribed to fedora-extras-commits list either).] Maybe it changes slowly and they come back after the bugzilla "spam" has been moved to a separate list. But since even the number of build reports and problem reports (repoclosure, upgradepaths) has been criticised, that is evidence that there are more packagers who are not interested in general content on fedora-extras-list. From jkeating at redhat.com Tue Nov 7 13:27:56 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 7 Nov 2006 08:27:56 -0500 Subject: fedora-maintainers et al [fab] State of Fedora (a long email) In-Reply-To: <20061107130225.9db7017c.bugs.michael@gmx.net> References: <455022A2.7000700@leemhuis.info> <20061107130225.9db7017c.bugs.michael@gmx.net> Message-ID: <200611070827.56958.jkeating@redhat.com> On Tuesday 07 November 2006 07:02, Michael Schwendt wrote: > Looking at the fedora-maintainers list archives, it does not become clear > at all what the purpose [and target group] of that list is and what its > content guidelines are. Yes, there has been some misuse. > > Clearly a lot of the content on that list since May 2005 cannot be > considered a required reading by *all* Fedora maintainers. And please, > don't just ask "For example?", but skim over the archives yourself. Happens on every list. > Adding to that, after it had been said that all Fedora Extras package > maintainers get subscribed to the list automatically and that subscription > is mandatory, this has not become true. It is not even clear whether all > Core maintainers are subscribed to the list. Effectively, there is no way > to address *all* maintainers and no way either to address all Extras > maintainers, because fedora-extras-list is avoided like the plague by > [probably many] Extras packagers due to past review-traffic madness. fedora-maintainers was created for just that purpose. Every Fedora maintainer should be subscribed as that's where we're going to announce (and discuss) issues that matter to all maintainers. Freezes, lib bumps, compiler changes, guideline updates, etc... The traffic even now is not too much. Rather than abandoning it and splintering out into foo-announce and whatever I'd much rather just get people to use fedora-maintainers, and read fedora-maintainers. It really should be part of your responsibility as a package maintainer of Fedora. Also, creating yet another extras specific list makes no sense when we're trying to merge core and extras together into one package "Pangaea". Splintering off communication doesn't make sense. > Apart from that, commenting on messages to fedora-extras-commits becomes > inconvienient and inefficient, because its "Reply-To:" to > fedora-extras-list at redhat.com is the wrong target as the packager might > not be subscribed there. Personally I think doing a reply-all which would point the reply to the maintainer and cc fedora-maintainers-list would be appropriate, especially once commit messages are from all the packages, not just Extras. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Tue Nov 7 18:59:53 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 08 Nov 2006 00:29:53 +0530 Subject: [fab] State of Fedora (a long email) In-Reply-To: <45502144.2090301@leemhuis.info> References: <454F8B48.3070609@leemhuis.info> <454F8D4D.7090705@fedoraproject.org> <454F9B92.7070805@leemhuis.info> <454F9D1B.7020509@fedoraproject.org> <454FA806.6060505@leemhuis.info> <454FA9EC.3090600@fedoraproject.org> <45502144.2090301@leemhuis.info> Message-ID: <4550D7A9.2080002@fedoraproject.org> Thorsten Leemhuis wrote: >>> - delete: >>> - fedora-config-list -- mostly dead, and people did not understand what >>> its use in any case >>> - fedora-patches-list -- dead ? >>> - fedora-tools-list -- mostly dead? >> The last three are already dead. We dont delete mailing lists since we >> want to keep the archives. > > Then disable them and mark them as retired. People post there, sometimes > don't even get replied and get confused by all that. Ok. I have send a note to the IT team. Rahul From mspevack at redhat.com Tue Nov 7 19:26:03 2006 From: mspevack at redhat.com (Max Spevack) Date: Tue, 7 Nov 2006 14:26:03 -0500 (EST) Subject: [fab] planning for next week's Fedora Summit Message-ID: I started a page on the wiki. Let's all use it for easy planning, transparency, etc. http://fedoraproject.org/wiki/FedoraSummit --Max From gdk at redhat.com Wed Nov 8 20:00:35 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 8 Nov 2006 15:00:35 -0500 (EST) Subject: [fab] planning for next week's Fedora Summit In-Reply-To: References: Message-ID: I've added some possible discussion topics. Might also be a good idea for everyone to subscribe to this page -- which I'm doing right now. On Tue, 7 Nov 2006, Max Spevack wrote: > I started a page on the wiki. Let's all use it for easy planning, > transparency, etc. > > http://fedoraproject.org/wiki/FedoraSummit > > --Max > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > -- ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From wtogami at redhat.com Thu Nov 9 22:45:27 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 09 Nov 2006 17:45:27 -0500 Subject: [fab] Idea:T-Shirts at Fedora Events... Message-ID: <4553AF87.40606@redhat.com> Hey folks, I wonder if this is a good or bad idea and would appreciate your input. Typically at events like FUDCON, or regional Linux shows, we hand out many free Fedora T-shirts. Why don't we instead sell the t-shirts at a reasonable price (like $5-10) with all proceeds going to a selected charitable organization like Creative Commons, Electronic Frontier Foundation, or the FSF? http://wtogami.livejournal.com/11118.html We could also sell extremely popular, viral meme shirts like this for $10-$15, with proceeds going to these same charities. I think this is a good idea for two key reasons. 1) People who buy shirts are more likely to wear it, therefore more effective at promoting Fedora than indiscriminately handing out shirts to swag leeches. 2) Red Hat already loses money by giving away t-shirts. We could instead leverage this for a good charitable purpose. This makes Fedora look good as a supporter of greater community causes. There are of course venues where selling shirts wouldn't work too well, and we would give them away for free there. But at community oriented events, this could work very well. Thoughts? Any ideas of other major charities that are in-line with the values of the Fedora Project? Warren Togami wtogami at redhat.com From tchung at fedoraproject.org Thu Nov 9 22:52:46 2006 From: tchung at fedoraproject.org (Thomas Chung) Date: Thu, 9 Nov 2006 14:52:46 -0800 Subject: [fab] Idea:T-Shirts at Fedora Events... In-Reply-To: <4553AF87.40606@redhat.com> References: <4553AF87.40606@redhat.com> Message-ID: <369bce3b0611091452j72f3c9f5oc6d12893aa76de8f@mail.gmail.com> On 11/9/06, Warren Togami wrote: > Hey folks, > > I wonder if this is a good or bad idea and would appreciate your input. > > Typically at events like FUDCON, or regional Linux shows, we hand out > many free Fedora T-shirts. Why don't we instead sell the t-shirts at a > reasonable price (like $5-10) with all proceeds going to a selected > charitable organization like Creative Commons, Electronic Frontier > Foundation, or the FSF? > > http://wtogami.livejournal.com/11118.html > We could also sell extremely popular, viral meme shirts like this for > $10-$15, with proceeds going to these same charities. > > I think this is a good idea for two key reasons. > 1) People who buy shirts are more likely to wear it, therefore more > effective at promoting Fedora than indiscriminately handing out shirts > to swag leeches. > 2) Red Hat already loses money by giving away t-shirts. We could > instead leverage this for a good charitable purpose. This makes Fedora > look good as a supporter of greater community causes. > > There are of course venues where selling shirts wouldn't work too well, > and we would give them away for free there. But at community oriented > events, this could work very well. > > Thoughts? > > Any ideas of other major charities that are in-line with the values of > the Fedora Project? > > Warren Togami > wtogami at redhat.com I think that's a good idea. In fact, some of Fedora Ambassadors were given a permission to sell media or t-shirts at the Linux Events to cope with their own expense to produce them locally. Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From wtogami at redhat.com Fri Nov 10 01:09:47 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 09 Nov 2006 20:09:47 -0500 Subject: [fab] Idea:T-Shirts at Fedora Events... In-Reply-To: <4553BB44.9080003@redhat.com> References: <4553AF87.40606@redhat.com> <4553BB44.9080003@redhat.com> Message-ID: <4553D15B.1090906@redhat.com> Tim Burke wrote: > often there are fewer shirts than attendees... or alternatively more > forums like LUGs where there are no shirts at all. What about having > this t-shirt fee allow for more shirts at more events? I hadn't thought of using these proceeds in order to recoup costs of shirt production, thus allowing us to have more shirts. Max, what are the shirt production costs? I think the key to this is to carefully select which venues are appropriate to sell shirts, and where it would be better to give away a limited number of shirts. Like LinuxTag FUDCON or LinuxWorld .org would be totally appropriate to sell shirts. A tiny event with mostly non-converted people (like New England Linux Symposium with ~75 educators) however would be more appropriate to give away shirts. LUG's are tiny events with a finite number of people. It might be best to give away shirts? Warren Togami wtogami at redhat.com From matt at domsch.com Fri Nov 10 01:47:22 2006 From: matt at domsch.com (Matt Domsch) Date: Thu, 9 Nov 2006 19:47:22 -0600 Subject: [fab] Idea:T-Shirts at Fedora Events... In-Reply-To: <4553D15B.1090906@redhat.com> References: <4553AF87.40606@redhat.com> <4553BB44.9080003@redhat.com> <4553D15B.1090906@redhat.com> Message-ID: <20061110014722.GA17225@domsch.com> On Thu, Nov 09, 2006 at 08:09:47PM -0500, Warren Togami wrote: > Tim Burke wrote: > >often there are fewer shirts than attendees... or alternatively more > >forums like LUGs where there are no shirts at all. What about having > >this t-shirt fee allow for more shirts at more events? > > I hadn't thought of using these proceeds in order to recoup costs of > shirt production, thus allowing us to have more shirts. Max, what are > the shirt production costs? +1 - close-to-self-sustaining activities mean we can do more of them with whatever budget we've got. From mspevack at redhat.com Fri Nov 10 15:34:47 2006 From: mspevack at redhat.com (Max Spevack) Date: Fri, 10 Nov 2006 10:34:47 -0500 (EST) Subject: [fab] FedoraSummit Message-ID: Posting to both fedora-advisory-board and fedora-devel-list. Encourage anyone who is interested to check out this page: http://fedoraproject.org/wiki/FedoraSummit Next week is going to be a busy one for Fedora, and we want to do everything we can to make sure the folks on these two lists (as well as our blogs) are in the loop as to what is happening. That said, the FedoraSummit page in the wiki will give everyone an idea of what our discussion plans are, as well as our communication and transparency plans. Thanks, Max -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From kwade at redhat.com Fri Nov 10 15:52:15 2006 From: kwade at redhat.com (Karsten Wade) Date: Fri, 10 Nov 2006 07:52:15 -0800 Subject: [fab] State of Fedora (a long email) In-Reply-To: <454FA806.6060505@leemhuis.info> References: <454F8B48.3070609@leemhuis.info> <454F8D4D.7090705@fedoraproject.org> <454F9B92.7070805@leemhuis.info> <454F9D1B.7020509@fedoraproject.org> <454FA806.6060505@leemhuis.info> Message-ID: <1163173935.9868.143.camel@erato.phig.org> On Mon, 2006-11-06 at 22:24 +0100, Thorsten Leemhuis wrote: > Site note: We should create a rough mailing list guideline for Fedora, > as it is highly confusing that the lists are configured quite > differently (reply-to munging , Tags in the Subject the two most [only?] > important things). I forgot that we had put this up earlier this year, with some recent refreshing done: http://fedoraproject.org/wiki/MailinglistGuidelines/ http://fedoraproject.org/wiki/MailinglistGuidelines/SubjectLineJunk However, dudes like Patrick and me do not have the power to enforce such guidelines. The place to start for the [Subject-line-junk] is actually up at Red Hat IS. Someone such as Max needs to open a ticket in the helpdesk system and ask them to do this: * On the mailing list request page, specify that the subject is not going to be full of junk * When creating new lists, choose to leave the field empty that puts the junk in Most lists have the junk in the Subject because it was put there in the first place. Why they leave it is a mystery to me. However, there are people who like that [stuff] in their subject, such as people who let all email fall into a single Inbox and use visual filtering (*cough*Greg*cough*). But I argue that removing the [junk] does the greatest good for the larger number of people. As for Reply-to munging. Well, it's evil stuff, but there are equally smart people on both sides of that debate. Even where I am in charge (f-docs-l), I left the historical munging on because people have come to expect the behavior on the list. *sigh* - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Fri Nov 10 16:18:00 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 10 Nov 2006 17:18:00 +0100 Subject: [fab] State of Fedora (a long email) In-Reply-To: <1163173935.9868.143.camel@erato.phig.org> References: <454F8B48.3070609@leemhuis.info> <454F8D4D.7090705@fedoraproject.org> <454F9B92.7070805@leemhuis.info> <454F9D1B.7020509@fedoraproject.org> <454FA806.6060505@leemhuis.info> <1163173935.9868.143.camel@erato.phig.org> Message-ID: <4554A638.5010900@leemhuis.info> Karsten Wade schrieb: > On Mon, 2006-11-06 at 22:24 +0100, Thorsten Leemhuis wrote: >> Site note: We should create a rough mailing list guideline for Fedora, >> as it is highly confusing that the lists are configured quite >> differently (reply-to munging , Tags in the Subject the two most [only?] >> important things). > I forgot that we had put this up earlier this year, with some recent > refreshing done: > > http://fedoraproject.org/wiki/MailinglistGuidelines/ > http://fedoraproject.org/wiki/MailinglistGuidelines/SubjectLineJunk > > However, dudes like Patrick and me do not have the power to enforce such > guidelines. > > The place to start for the [Subject-line-junk] is actually up at Red Hat > IS. Someone such as Max needs to open a ticket in the helpdesk system > and ask them to do this: Well, we need to agree on something before Max can do that. But it seems nobody/no Sub-project really feels responsible for setting up a proposal and find some people to agree on it. And the board normally should not have to deal with such low-level stuff... > However, there are people who like that [stuff] in their subject, > [...] > As for Reply-to munging. Well, it's evil stuff, but there are equally > smart people on both sides of that debate. [...] Well, to be fair, I don't like to see [stuff] in the subjects and I don't like Reply-to munging. But I could live with them; the different settings on different fedora lists are those that make everything really confusing... CU thl From tburke at redhat.com Fri Nov 10 16:30:10 2006 From: tburke at redhat.com (Tim Burke) Date: Fri, 10 Nov 2006 11:30:10 -0500 Subject: [fab] Idea:T-Shirts at Fedora Events... In-Reply-To: <4553AF87.40606@redhat.com> References: <4553AF87.40606@redhat.com> Message-ID: <4554A912.1070105@redhat.com> While this concept looks great on paper... a "reality factor" consideration comes to mind. While I claim to know next-to-nothing on this topic authoritatively, I'm wondering.... remember we embarked down the road of making the Fedora Foundation a non-profit. That turned out to be a colossal beaurocratic hastle.. so much so that we considered it more bother than its worth. (Not just on the setup, but ongoing stuff). My concern is whether there is legal/accounting Pandora's Box here in terms of taking in money of any form. For example even if all the incoming money was either given to charity or into shirt costs... to the extent that the FF is RH, who would do all the accounting/legal required bookeeping/tax filing, etc... From sundaram at fedoraproject.org Fri Nov 10 17:01:56 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 10 Nov 2006 22:31:56 +0530 Subject: [fab] Idea:T-Shirts at Fedora Events... In-Reply-To: <4554A912.1070105@redhat.com> References: <4553AF87.40606@redhat.com> <4554A912.1070105@redhat.com> Message-ID: <4554B084.90104@fedoraproject.org> Tim Burke wrote: > While this concept looks great on paper... a "reality factor" > consideration comes to mind. While I claim to know next-to-nothing on > this topic authoritatively, I'm wondering.... remember we embarked down > the road of making the Fedora Foundation a non-profit. That turned out > to be a colossal beaurocratic hastle.. so much so that we considered it > more bother than its worth. (Not just on the setup, but ongoing > stuff). My concern is whether there is legal/accounting Pandora's Box > here in terms of taking in money of any form. For example even if all > the incoming money was either given to charity or into shirt costs... to > the extent that the FF is RH, who would do all the accounting/legal > required bookeeping/tax filing, etc... Well did anyone seriously look at https://www.redhat.com/archives/fedora-advisory-board/2006-October/msg00168.html? Rahul From notting at redhat.com Fri Nov 10 19:31:33 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 10 Nov 2006 14:31:33 -0500 Subject: [fab] build service Message-ID: <20061110193133.GA19544@nostromo.devel.redhat.com> Interesting idea (although this does date from last year): http://en.opensuse.org/Build_Service Bill From fedora at leemhuis.info Sat Nov 11 13:49:16 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 11 Nov 2006 14:49:16 +0100 Subject: [fab] build service In-Reply-To: <20061110193133.GA19544@nostromo.devel.redhat.com> References: <20061110193133.GA19544@nostromo.devel.redhat.com> Message-ID: <4555D4DC.7070706@leemhuis.info> Hi! Bill Nottingham schrieb: > Interesting idea (although this does date from last year): > http://en.opensuse.org/Build_Service my 2 cent on this one: I don't think we should get into similar business. We know Fedora best and we should only build for Fedora and related distros. But some open source projects may soon start to say "the latest package for Fedora can be found on the opensuse build-serice servers in their own repo at URL" (see also http://abock.org/2006/11/10/opensuse-build-service/ ). If users start to use to much of that stuff they might sooner or later end in the well known repo-mixing problems. I'd like to avoid that, because people will complain Fedora and/or yum are broken/bad. Thus I'm more and more wondering if we we should re-evaluate the "Fedora Alternatives" idea that got buried. Users of stable releases that want a bit more up2date stuff could get in there, while users that are a careful stick to the main distro, and users that like some risks use devel. But we have some much on our plate currently, thus I don't think it'll be wise to discuss that now. CU thl From bugs.michael at gmx.net Sat Nov 11 15:48:17 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 11 Nov 2006 16:48:17 +0100 Subject: [fab] build service In-Reply-To: <4555D4DC.7070706@leemhuis.info> References: <20061110193133.GA19544@nostromo.devel.redhat.com> <4555D4DC.7070706@leemhuis.info> Message-ID: <20061111164817.800fac49.bugs.michael@gmx.net> On Sat, 11 Nov 2006 14:49:16 +0100, Thorsten Leemhuis wrote: > Thus I'm more and more > wondering if we we should re-evaluate the "Fedora Alternatives" idea > that got buried. Users of stable releases that want a bit more up2date > stuff could get in there, while users that are a careful stick to the > main distro, and users that like some risks use devel. > > But we have some much on our plate currently, thus I don't think it'll > be wise to discuss that now. So? Rest assured, it would be wise. Much wiser than the current crap in FE, where we have packages which conflict with other packages in Core or Extras _explicitly_. From skvidal at linux.duke.edu Sat Nov 11 17:37:03 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 11 Nov 2006 12:37:03 -0500 Subject: [fab] build service In-Reply-To: <20061111164817.800fac49.bugs.michael@gmx.net> References: <20061110193133.GA19544@nostromo.devel.redhat.com> <4555D4DC.7070706@leemhuis.info> <20061111164817.800fac49.bugs.michael@gmx.net> Message-ID: <1163266623.9312.14.camel@cutter> On Sat, 2006-11-11 at 16:48 +0100, Michael Schwendt wrote: > On Sat, 11 Nov 2006 14:49:16 +0100, Thorsten Leemhuis wrote: > > > Thus I'm more and more > > wondering if we we should re-evaluate the "Fedora Alternatives" idea > > that got buried. Users of stable releases that want a bit more up2date > > stuff could get in there, while users that are a careful stick to the > > main distro, and users that like some risks use devel. > > > > But we have some much on our plate currently, thus I don't think it'll > > be wise to discuss that now. > > So? > > Rest assured, it would be wise. Much wiser than the current crap in FE, > where we have packages which conflict with other packages in Core or > Extras _explicitly_. > FE has packages explicitly conflicting with pkgs in core? I thought that was against the rules? -sv From bugs.michael at gmx.net Sat Nov 11 18:59:42 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 11 Nov 2006 19:59:42 +0100 Subject: Fedora Alternatives (Re: [fab] build service) In-Reply-To: <1163266623.9312.14.camel@cutter> References: <20061110193133.GA19544@nostromo.devel.redhat.com> <4555D4DC.7070706@leemhuis.info> <20061111164817.800fac49.bugs.michael@gmx.net> <1163266623.9312.14.camel@cutter> Message-ID: <20061111195942.f04ccaa0.bugs.michael@gmx.net> On Sat, 11 Nov 2006 12:37:03 -0500, seth vidal wrote: > On Sat, 2006-11-11 at 16:48 +0100, Michael Schwendt wrote: > > On Sat, 11 Nov 2006 14:49:16 +0100, Thorsten Leemhuis wrote: > > > > > Thus I'm more and more > > > wondering if we we should re-evaluate the "Fedora Alternatives" idea > > > that got buried. Users of stable releases that want a bit more up2date > > > stuff could get in there, while users that are a careful stick to the > > > main distro, and users that like some risks use devel. > > > > > > But we have some much on our plate currently, thus I don't think it'll > > > be wise to discuss that now. > > > > So? > > > > Rest assured, it would be wise. Much wiser than the current crap in FE, > > where we have packages which conflict with other packages in Core or > > Extras _explicitly_. > > > > FE has packages explicitly conflicting with pkgs in core? I thought that > was against the rules? During package review that may be true. Still there are packages which conflict with eachother explicitly, and the number of "Conflicts" tags in Extras is increasing, too. "grep ^Confli * -R" lists 46 explicit conflicts, among them are Core package names. Where they are versioned, maybe they don't conflict with anything actually. The existence of such "Conflicts" lines in spec files is dangerous and highly questionable. Since Extras are always built only against latest updates, would you put your hand into the fire that it is always safe to upgrade from something like up-to-date FC(n)+Extras to CD/DVD based FC(n+1)? Further, stuff like initng even replaces a core OS process, works with a modified boot menu and clearly is an alternative to Core and not a clean add-on. And it is not the only Extras package which is run at boot-time and must not fail ever at first-boot after an upgrade. From skvidal at linux.duke.edu Sat Nov 11 22:17:42 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 11 Nov 2006 17:17:42 -0500 Subject: Fedora Alternatives (Re: [fab] build service) In-Reply-To: <20061111195942.f04ccaa0.bugs.michael@gmx.net> References: <20061110193133.GA19544@nostromo.devel.redhat.com> <4555D4DC.7070706@leemhuis.info> <20061111164817.800fac49.bugs.michael@gmx.net> <1163266623.9312.14.camel@cutter> <20061111195942.f04ccaa0.bugs.michael@gmx.net> Message-ID: <1163283462.9312.30.camel@cutter> On Sat, 2006-11-11 at 19:59 +0100, Michael Schwendt wrote: > During package review that may be true. Still there are packages which > conflict with eachother explicitly, and the number of "Conflicts" tags in > Extras is increasing, too. "grep ^Confli * -R" lists 46 explicit > conflicts, among them are Core package names. Where they are versioned, > maybe they don't conflict with anything actually. The existence of such > "Conflicts" lines in spec files is dangerous and highly questionable. Agreed. Does fesco know about this? Is anyone looking into correcting those? We should be able to automatically scan for those on check in, I'd think. > Since Extras are always built only against latest updates, would you put > your hand into the fire that it is always safe to upgrade from something > like up-to-date FC(n)+Extras to CD/DVD based FC(n+1)? I thought that was the point of evaluating pkgs. > Further, stuff like initng even replaces a core OS process, works with a > modified boot menu and clearly is an alternative to Core and not a clean > add-on. And it is not the only Extras package which is run at boot-time > and must not fail ever at first-boot after an upgrade. it replaces only in functionality. It doesn't actually have an obsolete and, afaik, it doesn't have any conflicting files, does it? -sv From fedora at leemhuis.info Sun Nov 12 16:52:57 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 12 Nov 2006 17:52:57 +0100 Subject: Fedora Alternatives (Re: [fab] build service) In-Reply-To: <1163283462.9312.30.camel@cutter> References: <20061110193133.GA19544@nostromo.devel.redhat.com> <4555D4DC.7070706@leemhuis.info> <20061111164817.800fac49.bugs.michael@gmx.net> <1163266623.9312.14.camel@cutter> <20061111195942.f04ccaa0.bugs.michael@gmx.net> <1163283462.9312.30.camel@cutter> Message-ID: <45575169.4060906@leemhuis.info> seth vidal schrieb: > On Sat, 2006-11-11 at 19:59 +0100, Michael Schwendt wrote: >> During package review that may be true. Still there are packages which >> conflict with eachother explicitly, and the number of "Conflicts" tags in >> Extras is increasing, too. "grep ^Confli * -R" lists 46 explicit >> conflicts, among them are Core package names. Where they are versioned, >> maybe they don't conflict with anything actually. The existence of such >> "Conflicts" lines in spec files is dangerous and highly questionable. > Agreed. Well, we need some conflicts for good reasons now and then. But yes, they should often be avoided. I just looked at a bit closer: Extras: 2315 spec files in devel contain 46 conflicts in total Core: 1550 spec files in devel contain 308 conflicts in total Wow! > Does fesco know about this? I'm not aware of any discussions about that in our outside of FESCo in the past weeks. > Is anyone looking into correcting those? I don't think so. The questions also is: Do they need to be fixed? Some of of those 46 look valid on a first sight. And BTW, where is the rule in the packaging guidelines and the point in the review guidelines that forbids "Conflicts" or encourages people to avoid them? It must be somewhere, but it seems I'm to blind to find it -- maybe someone from the Packaging Committee can enlighten me... > We should be able to automatically scan for those on check in, I'd > think. We need to set up something that periodically scan the spec files for common "errors", "troublemakers" or "historic cruft" (if possible). >> Since Extras are always built only against latest updates, would you put >> your hand into the fire that it is always safe to upgrade from something >> like up-to-date FC(n)+Extras to CD/DVD based FC(n+1)? > I thought that was the point of evaluating pkgs. We have some checks that check working upgrade paths already, but a lot of packagers of both Core and Extras seem to ignore the reports that get send to maintainers-list. I think both Core and Extras needs one person (the release manager?) that fixes the stuff when max three days after the problem showed up as the maintainers seem to ignore such problems often quite to long IMHO. >> Further, stuff like initng even replaces a core OS process, works with a >> modified boot menu and clearly is an alternative to Core and not a clean >> add-on. And it is not the only Extras package which is run at boot-time >> and must not fail ever at first-boot after an upgrade. > it replaces only in functionality. It doesn't actually have an obsolete > and, afaik, it doesn't have any conflicting files, does it? I think so, otherwise it should not have passed review (but I never looked at it). CU thl From tibbs at math.uh.edu Sun Nov 12 18:08:34 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Nov 2006 12:08:34 -0600 Subject: Fedora Alternatives (Re: [fab] build service) In-Reply-To: <45575169.4060906@leemhuis.info> References: <20061110193133.GA19544@nostromo.devel.redhat.com> <4555D4DC.7070706@leemhuis.info> <20061111164817.800fac49.bugs.michael@gmx.net> <1163266623.9312.14.camel@cutter> <20061111195942.f04ccaa0.bugs.michael@gmx.net> <1163283462.9312.30.camel@cutter> <45575169.4060906@leemhuis.info> Message-ID: >>>>> "TL" == Thorsten Leemhuis writes: TL> And BTW, where is the rule in the packaging guidelines and the TL> point in the review guidelines that forbids "Conflicts" or TL> encourages people to avoid them? There isn't one; Conflicts: is a perfectly valid thing to have. It's not really the Packaging committee's business to day whether conflicts are permitted; its up to either FESCo or the core cabal to make that policy. What we could do is pass a guideline that any conflicts should be explicit through a Conflicts: header, and to require specfile comments about the nature of the conflict. I'll raise it for discussion. Of course, this is moot if conflicts simply aren't permitted, but I personally don't think that's reasonable. - J< From fedora at leemhuis.info Sun Nov 12 18:45:05 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 12 Nov 2006 19:45:05 +0100 Subject: Fedora Alternatives (Re: [fab] build service) In-Reply-To: References: <20061110193133.GA19544@nostromo.devel.redhat.com> <4555D4DC.7070706@leemhuis.info> <20061111164817.800fac49.bugs.michael@gmx.net> <1163266623.9312.14.camel@cutter> <20061111195942.f04ccaa0.bugs.michael@gmx.net> <1163283462.9312.30.camel@cutter> <45575169.4060906@leemhuis.info> Message-ID: <45576BB1.9060209@leemhuis.info> Jason L Tibbitts III schrieb: >>>>>> "TL" == Thorsten Leemhuis writes: > TL> And BTW, where is the rule in the packaging guidelines and the > TL> point in the review guidelines that forbids "Conflicts" or > TL> encourages people to avoid them? > There isn't one; Conflicts: is a perfectly valid thing to have. Well, sure, but the rule in the beginning always was "Extras packages don't conflict or replace packages from Core". Well, it seems it got lost on the way. I'm wondering if we should put it back, but I tend to think that's worth the trouble as Core and Extras might merge by FC7 in any case. > It's > not really the Packaging committee's business to day whether conflicts > are permitted; its up to either FESCo or the core cabal to make that > policy. Sure, it's FESCo business to declare a rule "Extras packages don't conflict or replace packages from Core". But maybe we should have general rules for conflicts that are for both Extras and Core and thus business for the Packaging Committee. Michael, what's your opinion here? > What we could do is pass a guideline that any conflicts should be explicit > through a Conflicts: header, and to require specfile comments about > the nature of the conflict. I'll raise it for discussion. tia > Of course, > this is moot if conflicts simply aren't permitted, but I personally > don't think that's reasonable. +1 CU thl P.S.: Should we move this discussion to fedora-maintainers? That's would be the better place afaics. From mmcgrath at fedoraproject.org Sun Nov 12 20:09:52 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sun, 12 Nov 2006 14:09:52 -0600 Subject: Fedora Alternatives (Re: [fab] build service) In-Reply-To: <45576BB1.9060209@leemhuis.info> References: <20061110193133.GA19544@nostromo.devel.redhat.com> <4555D4DC.7070706@leemhuis.info> <20061111164817.800fac49.bugs.michael@gmx.net> <1163266623.9312.14.camel@cutter> <20061111195942.f04ccaa0.bugs.michael@gmx.net> <1163283462.9312.30.camel@cutter> <45575169.4060906@leemhuis.info> <45576BB1.9060209@leemhuis.info> Message-ID: <3237e4410611121209m3be32c02hf70055e7799d0ef6@mail.gmail.com> On 11/12/06, Thorsten Leemhuis wrote: > Jason L Tibbitts III schrieb: > >>>>>> "TL" == Thorsten Leemhuis writes: > > TL> And BTW, where is the rule in the packaging guidelines and the > > TL> point in the review guidelines that forbids "Conflicts" or > > TL> encourages people to avoid them? > > There isn't one; Conflicts: is a perfectly valid thing to have. > > Well, sure, but the rule in the beginning always was "Extras packages > don't conflict or replace packages from Core". Well, it seems it got > lost on the way. I'm wondering if we should put it back, but I tend to > think that's worth the trouble as Core and Extras might merge by FC7 in > any case. I've always interperated this: MUST: Packages must not own files or directories already owned by other packages. as conflicts should be avoided. I've even filed bug reports: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201279 -Mike From bugs.michael at gmx.net Sun Nov 12 20:29:51 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 12 Nov 2006 21:29:51 +0100 Subject: Fedora Alternatives (Re: [fab] build service) In-Reply-To: <45575169.4060906@leemhuis.info> References: <20061110193133.GA19544@nostromo.devel.redhat.com> <4555D4DC.7070706@leemhuis.info> <20061111164817.800fac49.bugs.michael@gmx.net> <1163266623.9312.14.camel@cutter> <20061111195942.f04ccaa0.bugs.michael@gmx.net> <1163283462.9312.30.camel@cutter> <45575169.4060906@leemhuis.info> Message-ID: <20061112212951.a0ddff02.bugs.michael@gmx.net> On Sun, 12 Nov 2006 17:52:57 +0100, Thorsten Leemhuis wrote: [Conflicts] > > Is anyone looking into correcting those? > > I don't think so. The questions also is: Do they need to be fixed? Some > of of those 46 look valid on a first sight. Did you know that in 99.9% of the cases it would be possible to replace them with proper "Requires" or an additional "Obsoletes" in a different package? Explicit Conflicts are the worse opposite of versioned "Requires", because they tell the package resolver what is forbidden, but don't tell it how to fix it without applying lots of guessing. And if there is no way out, uhm, that's unclean packaging and not suitable for an add-ons repository. [...] Example: devel/hunky-fonts/hunky-fonts.spec Conflicts: fontconfig < 2.3.93 There's no comment that explains this. Can we please require packagers to explain such unusual things in the spec file? Either it's superfluous Conflicts information (overuse of an RPM feature) or at some point in time the package really conflicted with Core's fontconfig. In that case, ouch. From stickster at gmail.com Sun Nov 12 20:59:02 2006 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 12 Nov 2006 15:59:02 -0500 Subject: [fab] State of Fedora (a long email) In-Reply-To: <4554A638.5010900@leemhuis.info> References: <454F8B48.3070609@leemhuis.info> <454F8D4D.7090705@fedoraproject.org> <454F9B92.7070805@leemhuis.info> <454F9D1B.7020509@fedoraproject.org> <454FA806.6060505@leemhuis.info> <1163173935.9868.143.camel@erato.phig.org> <4554A638.5010900@leemhuis.info> Message-ID: <1163365142.1553.16.camel@localhost.localdomain> On Fri, 2006-11-10 at 17:18 +0100, Thorsten Leemhuis wrote: > Karsten Wade schrieb: > > However, there are people who like that [stuff] in their subject, > > [...] > > As for Reply-to munging. Well, it's evil stuff, but there are equally > > smart people on both sides of that debate. [...] > > Well, to be fair, I don't like to see [stuff] in the subjects and I > don't like Reply-to munging. But I could live with them; the different > settings on different fedora lists are those that make everything really > confusing... I can live with the latter better than the former, but mostly just +1 on the last sentence. The current hodgepodge approach is ludicrous. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Sun Nov 12 21:07:26 2006 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 12 Nov 2006 16:07:26 -0500 Subject: [fab] Idea:T-Shirts at Fedora Events... In-Reply-To: <4553AF87.40606@redhat.com> References: <4553AF87.40606@redhat.com> Message-ID: <1163365646.1553.22.camel@localhost.localdomain> On Thu, 2006-11-09 at 17:45 -0500, Warren Togami wrote: > Hey folks, > > I wonder if this is a good or bad idea and would appreciate your input. > > Typically at events like FUDCON, or regional Linux shows, we hand out > many free Fedora T-shirts. Why don't we instead sell the t-shirts at a > reasonable price (like $5-10) with all proceeds going to a selected > charitable organization like Creative Commons, Electronic Frontier > Foundation, or the FSF? [...snip...] > Any ideas of other major charities that are in-line with the values of > the Fedora Project? FSF sounds like the best candidate to me; CC a distant second, since I there's not a lot of good value in their licensing for software purposes, although they've had good impact in other content areas, and Fedora's primary mission is the advancement of free software. I would be circumspect about EFF and other groups that could reasonably be considered more politically charged. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Sun Nov 12 21:09:33 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 12 Nov 2006 22:09:33 +0100 Subject: Fedora Alternatives (Re: [fab] build service) In-Reply-To: <20061112212951.a0ddff02.bugs.michael@gmx.net> References: <20061110193133.GA19544@nostromo.devel.redhat.com> <4555D4DC.7070706@leemhuis.info> <20061111164817.800fac49.bugs.michael@gmx.net> <1163266623.9312.14.camel@cutter> <20061111195942.f04ccaa0.bugs.michael@gmx.net> <1163283462.9312.30.camel@cutter> <45575169.4060906@leemhuis.info> <20061112212951.a0ddff02.bugs.michael@gmx.net> Message-ID: <45578D8D.6020203@leemhuis.info> Michael Schwendt schrieb: > On Sun, 12 Nov 2006 17:52:57 +0100, Thorsten Leemhuis wrote: > [Conflicts] >>> Is anyone looking into correcting those? >> I don't think so. The questions also is: Do they need to be fixed? Some >> of of those 46 look valid on a first sight. > Did you know that in 99.9% of the cases it would be possible to replace > them with proper "Requires" or an additional "Obsoletes" in a different > package? No, I never did analysis so I don't know if it's "99,9%" or "99,8%" (or even less). > Explicit Conflicts are the worse opposite of versioned "Requires", As I wrote earlier: Well, we need some conflicts for good reasons now and then. But yes, they should often be avoided. > because > they tell the package resolver what is forbidden, but don't tell it how to > fix it without applying lots of guessing. And if there is no way out, uhm, > that's unclean packaging and not suitable for an add-ons repository. > [...] > Example: > devel/hunky-fonts/hunky-fonts.spec > Conflicts: fontconfig < 2.3.93 > > There's no comment that explains this. > Can we please require packagers > to explain such unusual things in the spec file? Talk to the packaging committee please. That really their business. I'm all for it. > [...] And example for a *afaik* (and Michael, please correct me if I'm wrong) valid conflicts (it was even discusses on fedora-devel quite some time ago iirc): libhugetlbfs/libhugetlbfs.spec Conflicts: kernel < 2.6.16 The package for example works fine in a chroot (vserver anyone?) without a kernel installed, but on normal machines the installed kernels needs at least to be 2.6.16. And the conflicts makes sure that the users has none installed that are older -- that's won't work with a Requires (the user could still have old kernel around and might accidentally boot into it). CU thl From bugs.michael at gmx.net Sun Nov 12 21:46:50 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 12 Nov 2006 22:46:50 +0100 Subject: Fedora Alternatives (Re: [fab] build service) In-Reply-To: <45578D8D.6020203@leemhuis.info> References: <20061110193133.GA19544@nostromo.devel.redhat.com> <4555D4DC.7070706@leemhuis.info> <20061111164817.800fac49.bugs.michael@gmx.net> <1163266623.9312.14.camel@cutter> <20061111195942.f04ccaa0.bugs.michael@gmx.net> <1163283462.9312.30.camel@cutter> <45575169.4060906@leemhuis.info> <20061112212951.a0ddff02.bugs.michael@gmx.net> <45578D8D.6020203@leemhuis.info> Message-ID: <20061112224650.6611c69f.bugs.michael@gmx.net> On Sun, 12 Nov 2006 22:09:33 +0100, Thorsten Leemhuis wrote: > > Explicit Conflicts are the worse opposite of versioned "Requires", > > As I wrote earlier: Well, we need some conflicts for good reasons now > and then. Please enlighten me. How good can a reason be to have such a conflict? At no point in time there must ever be a reason for an Extras package to conflict with Core. Extras packages are made for a well-known target. > > Example: > > devel/hunky-fonts/hunky-fonts.spec > > Conflicts: fontconfig < 2.3.93 > > > > There's no comment that explains this. > > Can we please require packagers > > to explain such unusual things in the spec file? > > Talk to the packaging committee please. That really their business. I'm > all for it. Then simply back up the proposal and forward it appropriately as part of FESCo seeking guidance by the packaging committee. Some people in FESCo are part of the packaging committee even. > > [...] > > And example for a *afaik* (and Michael, please correct me if I'm wrong) > valid conflicts (it was even discusses on fedora-devel quite some time > ago iirc): > libhugetlbfs/libhugetlbfs.spec > Conflicts: kernel < 2.6.16 > The package for example works fine in a chroot (vserver anyone?) without > a kernel installed, but on normal machines the installed kernels needs > at least to be 2.6.16. And the conflicts makes sure that the users has > none installed that are older -- that's won't work with a Requires (the > user could still have old kernel around and might accidentally boot into > it). Questionable. Superfluous. Dangerous. Blocks kernel upgrades. Tries to set up artificial hurdles for users of command-line package installers. FC-6 does only offer a kernel >= 2.6.18, so in an Extras 6 package this conflict adds nothing else than trouble. Looking for fun with an Anaconda based dist upgrade? From fedora at leemhuis.info Mon Nov 13 06:09:51 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 13 Nov 2006 07:09:51 +0100 Subject: Fedora Alternatives (Re: [fab] build service) In-Reply-To: <20061112224650.6611c69f.bugs.michael@gmx.net> References: <20061110193133.GA19544@nostromo.devel.redhat.com> <4555D4DC.7070706@leemhuis.info> <20061111164817.800fac49.bugs.michael@gmx.net> <1163266623.9312.14.camel@cutter> <20061111195942.f04ccaa0.bugs.michael@gmx.net> <1163283462.9312.30.camel@cutter> <45575169.4060906@leemhuis.info> <20061112212951.a0ddff02.bugs.michael@gmx.net> <45578D8D.6020203@leemhuis.info> <20061112224650.6611c69f.bugs.michael@gmx.net> Message-ID: <45580C2F.4080900@leemhuis.info> Michael Schwendt schrieb: > On Sun, 12 Nov 2006 22:09:33 +0100, Thorsten Leemhuis wrote: >>> There's no comment that explains this. >>> Can we please require packagers >>> to explain such unusual things in the spec file? >> Talk to the packaging committee please. That really their business. I'm >> all for it. > Then simply back up the proposal and forward it appropriately as part of > FESCo seeking guidance by the packaging committee. Some people in FESCo > are part of the packaging committee even. I forwarded the whole discussion to the Packaging Committee. See: https://www.redhat.com/archives/fedora-packaging/2006-November/msg00024.html CU thl From chitlesh at fedoraproject.org Mon Nov 13 11:00:26 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 13 Nov 2006 12:00:26 +0100 Subject: [fab] Most Advanced 100% Free Distribution? In-Reply-To: <454E5BF6.4060601@fedoraproject.org> References: <454A0074.8070003@redhat.com> <454A048D.5000608@fedoraproject.org> <454A06BB.10203@redhat.com> <454E5BF6.4060601@fedoraproject.org> Message-ID: <13dbfe4f0611130300w509dbf51if836b43536f39aa1@mail.gmail.com> To be honest, I find stallman's answers quite confusing! >From http://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF: > > * Would it be possible for the FSF to go through our packaging > > guidelines at http://fedoraproject.org/wiki/Packaging/Guidelines and the > > packages included in Fedora Core and Fedora Extras aside from our own > > licensing audit and point out clear or potential issues with it? > We can certainly go through the guidelines. We have not yet done so, > but we know of one problem in the current policy: it says that > packages can be included which qualify as open source but not as free > software. In other words, not all packages need to meet the > definition of free software. Ok, why not add "free (with source codes) and opensource software" in FE guidelines to satisfy this criteria ? chitlesh -- http://clunixchit.blogspot.com From sundaram at fedoraproject.org Mon Nov 13 11:06:30 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 13 Nov 2006 16:36:30 +0530 Subject: [fab] Most Advanced 100% Free Distribution? In-Reply-To: <13dbfe4f0611130300w509dbf51if836b43536f39aa1@mail.gmail.com> References: <454A0074.8070003@redhat.com> <454A048D.5000608@fedoraproject.org> <454A06BB.10203@redhat.com> <454E5BF6.4060601@fedoraproject.org> <13dbfe4f0611130300w509dbf51if836b43536f39aa1@mail.gmail.com> Message-ID: <455851B6.4000204@fedoraproject.org> Chitlesh GOORAH wrote: > To be honest, I find stallman's answers quite confusing! > >> From http://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF: >> > * Would it be possible for the FSF to go through our packaging >> > guidelines at http://fedoraproject.org/wiki/Packaging/Guidelines and >> the >> > packages included in Fedora Core and Fedora Extras aside from our own >> > licensing audit and point out clear or potential issues with it? > >> We can certainly go through the guidelines. We have not yet done so, >> but we know of one problem in the current policy: it says that >> packages can be included which qualify as open source but not as free >> software. In other words, not all packages need to meet the >> definition of free software. > > Ok, why not add "free (with source codes) and opensource software" in > FE guidelines to satisfy this criteria ? If you see the discussions on the main page that should clear up your confusion. We could change the guidelines but there are software licenses that we dont yet know FSF's position on that we include in Fedora. Spot has been sending these to FSF but license reviews take time. Rahul From tcallawa at redhat.com Mon Nov 13 15:37:21 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 13 Nov 2006 09:37:21 -0600 Subject: [fab] Most Advanced 100% Free Distribution? In-Reply-To: <13dbfe4f0611130300w509dbf51if836b43536f39aa1@mail.gmail.com> References: <454A0074.8070003@redhat.com> <454A048D.5000608@fedoraproject.org> <454A06BB.10203@redhat.com> <454E5BF6.4060601@fedoraproject.org> <13dbfe4f0611130300w509dbf51if836b43536f39aa1@mail.gmail.com> Message-ID: <1163432241.3501.172.camel@localhost.localdomain> On Mon, 2006-11-13 at 12:00 +0100, Chitlesh GOORAH wrote: > To be honest, I find stallman's answers quite confusing! > > >From http://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF: > > > * Would it be possible for the FSF to go through our packaging > > > guidelines at http://fedoraproject.org/wiki/Packaging/Guidelines and the > > > packages included in Fedora Core and Fedora Extras aside from our own > > > licensing audit and point out clear or potential issues with it? > > > We can certainly go through the guidelines. We have not yet done so, > > but we know of one problem in the current policy: it says that > > packages can be included which qualify as open source but not as free > > software. In other words, not all packages need to meet the > > definition of free software. > > Ok, why not add "free (with source codes) and opensource software" in > FE guidelines to satisfy this criteria ? Because it will not satisfy this criteria. There is open source software that the FSF considers non-free. Everything that the FSF considers "free" is also considered open source. They want us to just drop the open source. ~spot -------------- next part -------------- An HTML attachment was scrubbed... URL: From max at spevack.org Mon Nov 13 18:26:40 2006 From: max at spevack.org (Max Spevack) Date: Mon, 13 Nov 2006 13:26:40 -0500 (EST) Subject: [fab] Fedora summit, monday afternoon update Message-ID: I don't want to retype everything, but I would like to point people to the fedora planet in general, and my blog, where I've posted a few summaries of what we've done so far. http://planet.fedoraproject.org/ http://spevack.livejournal.com/ Also #fedora-summit on freenode. I can't get on the VPN, but I'd like someone to cross-post this to fedora-devel list. If I do it from my non-RHAT address, the note will get lost in moderation. I'd also like, at the end of the day, for someone to post the IRC logs on the FedoraSummit wiki page. -- Max Spevack + http://spevack.org + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From mmcgrath at fedoraproject.org Mon Nov 13 20:52:44 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 13 Nov 2006 14:52:44 -0600 Subject: [fab] CVS usage Message-ID: <3237e4410611131252h5bba0aafi432effbd57441512@mail.gmail.com> If attachments work, here's the current use of the CVS box (as I mentioned in the summit). If not, someone let me know. -Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: cvs-int-cpu-usage.png Type: image/png Size: 7227 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cvs-int-load-avg.png Type: image/png Size: 6596 bytes Desc: not available URL: From bob at bobjensen.com Mon Nov 13 23:09:37 2006 From: bob at bobjensen.com (Robert 'Bob' Jensen) Date: Mon, 13 Nov 2006 17:09:37 -0600 Subject: [fab] Idea:T-Shirts at Fedora Events... In-Reply-To: <4553AF87.40606@redhat.com> References: <4553AF87.40606@redhat.com> Message-ID: <4558FB31.9050503@bobjensen.com> Warren Togami wrote: > Hey folks, > > I wonder if this is a good or bad idea and would appreciate your input. > > Typically at events like FUDCON, or regional Linux shows, we hand out > many free Fedora T-shirts. Why don't we instead sell the t-shirts at a > reasonable price (like $5-10) with all proceeds going to a selected > charitable organization like Creative Commons, Electronic Frontier > Foundation, or the FSF? > > http://wtogami.livejournal.com/11118.html > We could also sell extremely popular, viral meme shirts like this for > $10-$15, with proceeds going to these same charities. > > I think this is a good idea for two key reasons. > 1) People who buy shirts are more likely to wear it, therefore more > effective at promoting Fedora than indiscriminately handing out shirts > to swag leeches. > 2) Red Hat already loses money by giving away t-shirts. We could > instead leverage this for a good charitable purpose. This makes Fedora > look good as a supporter of greater community causes. > > There are of course venues where selling shirts wouldn't work too well, > and we would give them away for free there. But at community oriented > events, this could work very well. > > Thoughts? > > Any ideas of other major charities that are in-line with the values of > the Fedora Project? > > Warren Togami > wtogami at redhat.com > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > One potential area that would be a problem is Taxes, Some areas have sales tax on clothing items, there is also the income tax issue. Just a couple nuggets to chew on, if you are selling something for a profit or not some one wants a chunk. -- Robert 'Bob' Jensen * * http://fedoraproject.org/wiki/BobJensen gpg fingerprint: F9F4 7243 4243 0043 2C45 97AF E8A4 C3AE 42EB 0BC6 Fedora Unity Project * bob at fedoraunity.org * http://fedoraunity.org/ From max at spevack.org Tue Nov 14 02:35:24 2006 From: max at spevack.org (Max Spevack) Date: Mon, 13 Nov 2006 21:35:24 -0500 (EST) Subject: [fab] fedora summit, monday night Message-ID: FAB, Lots of pages and such that are in progress of being updated this evening, but in the spirit of immediate transparency, you might want to check out (and reload later tonight/tomorrow) the following: http://fedoraproject.org/wiki/FedoraSummit http://fedoraproject.org/wiki/FedoraSummit/OpeningCore http://spevack.livejournal.com http://planet.fedoraproject.org Folks are working on getting the wiki stuff updated as I write this. --Max From gdk at redhat.com Tue Nov 14 05:23:58 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Tue, 14 Nov 2006 00:23:58 -0500 (EST) Subject: [fab] My notes from today Message-ID: http://fedoraproject.org/wiki/FedoraSummit/OpeningCore http://fedoraproject.org/wiki/FedoraSummit/ArchPolicy http://fedoraproject.org/wiki/FedoraSummit/NewBuildSystem All plans are preliminary and subject to radical and incoherent changes. :) --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From tiemann at redhat.com Tue Nov 14 13:03:59 2006 From: tiemann at redhat.com (Michael Tiemann) Date: Tue, 14 Nov 2006 08:03:59 -0500 Subject: [fab] FC7 desktop thoughts--PCLinuxOS p93a Junior | www.moka5.com? Message-ID: <1163509439.4225.38.camel@localhost.localdomain> Monica Lam was my professor when I was a Ph.D. candidate at Stanford University back in 1988. She's now at a startup doing a "LivePC" (kinda like a Live CD, but on flash devices). Here's one of many derivative works: http://www.moka5.com/node/55 I've been thinking about what the FC (or FU--I love that acronym!) 7 desktop might look like, and my favorite of late is this: 1. A "standard" desktop environment that can be a sensible node in a network when no USB key is attached--core OS, graphics system, input methods, selinux environment, yum tools, torrent tools, java execution environment, browser--whatever sensibly fits in the 512MB flash memory footprint of the One Laptop project. 2. A "personal" desktop environment that, when attached to the "standard" desktop environment, offers a truly wonderful range of desktop tools with the additional 512MB-1GB-2GB form factor of modern USB keys. 3. A "local" desktop environment that represents the 10GB-500GB hard disks that are likely attached to the desktop (or laptop machine). The local environment provides facilities for caching larger applications and datasets (such as GIS datasets, genomic sequences, protein databases, etc) as well as identifying and classifying all stateful information so that it can be managed and replicated to... 3. A "remote" desktop environment. Users can choose their favorite backing store service providers based on cost, availability, privacy, and other information. Moderately paranoid people can choose to distribute random packets of encrypted information to a diverse range of backing store providers using a variety of protocols, file formats, etc. More paranoid people can simply designate trusted disk volumes within their secure network. In this world, a single USB key provides a completely portable environment that can be effectively used even when not connected to the internet. When plugged into a machine that's already running a compatible environment, startup is faster and guest environments can share more resources. The laptop or desktop machine encapsulates the operating environment and provides the means for actually using the environment for work. It is not, itself, the de facto representation of the user's state, but merely a manifestation of the state that's managed within a larger context. Virtualization of storage and OS resources make it practical to maintain a common operating environment across multiple machines while preserving the integrity of data. The desktop or laptop is completely replaceable, making it possible to share expensive hardware resources while keeping private, non-shared data on cheap hardware (USB keys and/or inexpensive disk). Will we be ready in FC7 to make this a reality? M From tiemann at redhat.com Tue Nov 14 13:24:08 2006 From: tiemann at redhat.com (Michael Tiemann) Date: Tue, 14 Nov 2006 08:24:08 -0500 Subject: [fab] Lone Wolves - Web, game, and open source development Message-ID: <1163510649.4225.54.camel@localhost.localdomain> Given all the discussion we recently had on the fedora lists about where, precisely to draw the line between acceptable and not acceptable when it comes to 3rd-party drivers and BIOS blobs, it looks like the conversation is moving toward the center of the Ubunutu community as well... http://www.jejik.com/articles/2006/11/is_ubuntu_set_to_become_non-free M From jwboyer at jdub.homelinux.org Wed Nov 15 02:11:42 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 14 Nov 2006 20:11:42 -0600 Subject: [fab] Secondary Arches Message-ID: <1163556702.17611.38.camel@vader.jdub.homelinux.org> Hi All, I'd like to make a few comments on the secondary arch proposal that was discussed during the Fedora Summit. First, I think secondary arches are a good idea. There are communities out there that are perfectly capable and willing to enable Fedora on various hardware platforms. I think secondary arches are a great enabler for such communities, and I hope they can help spread Fedora to things other than boring old x86. That being said, I agree with spot. There are two key issues that are essentially taking a great idea and sinking it immediately. In order for secondary arches to really work, I believe the arch teams need to be able to host repositories along side the primary arches on fedoraproject.org, and binary isos for the arches (if available) should also be hosted. The fact that one has to host repositories and isos on servers outside of fedoraproject.org basically kills the distinction that it's a true Fedora release. Why? It's simple. The suggestion as it stands is that secondary arches can only use the Fedora name if all changes are in the Fedora packages. However, this will never be the case for fedora-release, which will require yum repo files that point to servers other than fedoraproject.org. Sure, that's a trivial example that can easily be circumvented by providing an "exemption" for that package. However, it hints at another issue which is the fact that people go to http://fedoraproject.org/ to download Fedora. If they now have to go to foo.bar.com to download it, you lose brand distinction. "But we can't BUILD the packages on these arches, so why should we host them?" What difference does that make? If the Board is going to allow secondary arches built on servers _outside_ of the Fedora buildsys to carry the Fedora name, then explain to me why those packages cannot sit on fedoraproject.org. At that point they are officially part of Fedora, and belong with the rest of it. Disk is cheap. I'll personally buy the Fedora project a couple 160G hard drives to host the packages and isos if that is the only reason they can't be hosted. Also, hosting repositories/isos outside of fedoraproject.org basically means those arches lose another major benefit, which is mirroring. The fedora mirror structure is fairly good, and trying to achieve something of similar numbers will simply be very difficult to accomplish. Mirrors can choose not to mirror secondary arches if they wish. Let them make that choice. I strongly urge the Board to consider these points before coming to a final policy for secondary arches. I want to see this change turn into a great move for Fedora, and not just a "dumping of work" as some are already perceiving it to be. josh -------------- 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 Christian.Iseli at licr.org Wed Nov 15 07:20:54 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 15 Nov 2006 08:20:54 +0100 Subject: [fab] Secondary Arches In-Reply-To: <1163556702.17611.38.camel@vader.jdub.homelinux.org> References: <1163556702.17611.38.camel@vader.jdub.homelinux.org> Message-ID: <20061115082054.1afc1420@ludwig-alpha.unil.ch> On Tue, 14 Nov 2006 20:11:42 -0600, Josh Boyer wrote: > I strongly urge the Board to consider these points before coming to a > final policy for secondary arches. I want to see this change turn into > a great move for Fedora, and not just a "dumping of work" as some are > already perceiving it to be. +1 C From fedora at leemhuis.info Wed Nov 15 07:36:10 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 15 Nov 2006 08:36:10 +0100 Subject: [fab] Secondary Arches In-Reply-To: <1163556702.17611.38.camel@vader.jdub.homelinux.org> References: <1163556702.17611.38.camel@vader.jdub.homelinux.org> Message-ID: <455AC36A.7070807@leemhuis.info> Hi! Some "me, too" here: Josh Boyer schrieb: > First, I think secondary arches are a good idea. +1 > [...] > There are two key issues that are > essentially taking a great idea and sinking it immediately. In order > for secondary arches to really work, I believe the arch teams need to be > able to host repositories along side the primary arches on > fedoraproject.org, and binary isos for the arches (if available) should > also be hosted. +1 >[...] > "But we can't BUILD the packages on these arches, so why should we host > them?" What difference does that make? If the Board is going to allow > secondary arches built on servers _outside_ of the Fedora buildsys to > carry the Fedora name, then explain to me why those packages cannot sit > on fedoraproject.org. +1 > Also, hosting repositories/isos outside of fedoraproject.org basically > means those arches lose another major benefit, which is mirroring. The > fedora mirror structure is fairly good, and trying to achieve something > of similar numbers will simply be very difficult to accomplish. Mirrors > can choose not to mirror secondary arches if they wish. Let them make > that choice. +1 It will will probably also lead to questions like "why doesn't the yum.conf from not working on arch foo". I'd like to avoid that. > I strongly urge the Board to consider these points before coming to a > final policy for secondary arches. I want to see this change turn into > a great move for Fedora, and not just a "dumping of work" as some are > already perceiving it to be. +1 CU thl From dwmw2 at infradead.org Wed Nov 15 11:57:04 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 15 Nov 2006 05:57:04 -0600 Subject: [fab] Architecture Policy. Message-ID: <1163564205.3396.141.camel@shinybook.infradead.org> (Not sure if I can post to f-a-b; Greg, please could you forward if not?) I think it's important for Fedora to encourage extra architectures and not to paint itself into a corner as an x86-only niche distribution. The 'ArchPolicy' on the wiki? looks like a good idea, in principle -- allowing more to asynchronously track Fedora builds and make releases from them as long as all their fixes are in upstream Fedora is a very good thing. I'm encouraged by it, in general. I'm concerned by some of the details though -- and I'm especially concerned by the fact that it seems like a retrograde step for architectures which are currently built in rawhide but which aren't listed in the new set of 'primary architectures', by taking away their current build infrastructure. That's not 'encouraging extra architectures' -- it's very much the opposite, for those architectures which are _most_ viable of the non-'primary' set. I'm particularly interested in the decision to stop counting PowerPC as a primary architecture. I've heard rumours that this decision was in part because PPC was responsible for most of the recent release slippage -- but that doesn't seem to be backed up by the slip announcements -- the first one for FC6? lists only one PPC-specific issue in the five problems that caused the slip, and the second one? doesn't seem to mention _anything_ that's specific to PPC. The FAQ in the ArchPolicy wiki page suggests that "bugs have languished for multiple releases without anybody even noticing". Do we have a reference for that? Bugs _often_ languish for multiple releases -- I don't suppose we're dropping Evolution because it's had bugs outstanding for multiple releases, are we? And on what basis do we make the claim "without anybody even noticing"? The FAQ also says "there is a reason to stop doing PPC as a primary arch until/unless it reaches critical mass once again". What, specifically, is the reason mentioned there? What is 'critical mass' and why does it matter? We know that PowerPC isn't as widespread as i386 but why is that an issue? It's still very much alive -- it's as well-maintained in kernel and glibc as i386 and x86_64 are, IBM are using Fedora as the only supported OS on their Cell blades, and we'll have Fedora for PlayStation3 very shortly too. There's even talk of switching certain other big projects I'm involved with to a PowerPC processor for their next generation. Fedora on PowerPC is very much alive. I think the change in arch policy is overall a good thing, although there will naturally be teething problems for the new process. I'd strongly recommend that we don't change the list of primary architectures at the _same_ time though. Please, let's get the new process and the asynchronous builds in place and working _before_ we start downgrading architectures from supported status. (In fact, I'd suggest that we don't make such a clear technical distinction between 'primary' and 'secondary' in the build system -- it should all be done through the same mechanism, and the only distinction between 'primary' and 'secondary' would be that a build is considered to have been successful and is 'committed' only when it's succeeded on all of the 'primary' architecture builders. But that's a technical implementation detail and hopefully what would have happened anyway -- any suggestion to the contrary is hopefully just woolly language on the wiki.) I'd like to see: 1. A clear intention _not_ to move backwards for architectures like IA64 which are _so_ close to having a 'proper' Fedora release, and have already got FC6 ISO images built. It was looking quite likely that if they keep up the good work, they could perhaps have had an official FC7/IA64 release. I don't want our changes to make that any _less_ likely, for FC7. 2. An even _clearer_ intention not to move backwards for PowerPC, which already _has_ a 'proper' Fedora release. I _certainly_ don't want it to be any less likely that we see an official FC7/PowerPC release. To clarify: I don't care a hoot if it's classified as a 'secondary' arch -- that's just nomenclature -- as long as it _does_ get built and released. The folks who look after Fedora/PPC are used to looking after PPC-specific issues, and the new process sounds entirely workable once it's all shaken out. But I think that dropping PPC from 'primary' _now_, before the process for secondary builds and in particular releases is in place is extremely premature. To be honest, it feels like a bit of a slap in the face for those who've been working on Fedora/PPC and IA64 to have the goalposts suddenly moved to include a new and hazily-defined process, even if it's a good idea in the _long_ term. 3. A commitment that the existing build machines will not suddenly be made unavailable until/unless suitable replacement arrangements are in place for _all_ current Rawhide architectures. 4. A commitment to quality -- in particular a commitment that developers will not suddenly find it acceptable to commit x86-only code (assuming little-endianness, including inline assembly etc.). As I said, the arch policy looks like a good idea in principle -- but please, let's test and debug the process by bringing in Aurora and AlphaCore folks and giving them an _improvement_ in their situation. And let's hold off for a while on making changes which have a strong chance of _adversely_ affecting architectures like PowerPC and IA64 which are either already shipped or very close to being shippable as part of Fedora. -- dwmw2 ? http://fedoraproject.org/wiki/FedoraSummit/ArchPolicy ? https://www.redhat.com/archives/fedora-devel-list/2006-October/msg00199.html ? https://www.redhat.com/archives/fedora-devel-list/2006-October/msg00431.html From fedora at leemhuis.info Wed Nov 15 12:20:44 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 15 Nov 2006 13:20:44 +0100 Subject: [fab] Architecture Policy. In-Reply-To: <1163564205.3396.141.camel@shinybook.infradead.org> References: <1163564205.3396.141.camel@shinybook.infradead.org> Message-ID: <455B061C.8000505@leemhuis.info> Hi all! David Woodhouse schrieb: > [...] > I think it's important for Fedora to encourage extra architectures and > not to paint itself into a corner as an x86-only niche distribution. > > The 'ArchPolicy' on the wiki? looks like a good idea, in principle -- > allowing more to asynchronously track Fedora builds and make releases > from them as long as all their fixes are in upstream Fedora is a very > good thing. I'm encouraged by it, in general. [...] I have to agree with a lot of what dwmw2 said. Further, I read below on the IRC log of day2: > 21:06 < warren> | * (Talking about test composes) > 21:07 < mspevack> | example: > 21:07 < mspevack> | dist-fc7 tag applies to every package built from the devel branch currently. > 21:07 < mspevack> | Test1 freeze is announced. Date hits, we create fc7-test1 tag (freeze tag) > 21:07 < mspevack> | we tag the latest dist-fc7 packages with this freeze tag > 21:07 < mspevack> | We create a test repo of all packages tagged "fc7-test1". QA happens on these packages, or some subset > 21:08 < mspevack> | realistically a lot of these packages will never get looked at. > 21:08 < mspevack> | Fixes are applied to the devel branch and built. Resulting specific package builds get tagged with "fc7-test1" at the discretion of the release team > 21:08 < mspevack> | at final release, when we announce the freeze, we create the fc-7 branch > 21:09 < mspevack> | devel begins to be tagged with the "fedora 8" tag > 21:11 < dgilmore> | mspevack: seems sane > 21:12 < mspevack> | it's all directly out of Jesse's mouth > 21:12 < mspevack> | it all needs to get run by FESCO That made we wondering: hey, sounds nice. And that makes it possible to get rid of parts from the "secondary arch" concept again IMHO. If a arch is ready and tested by the arch maintainers: go ship it together with x86 and x86_64. If not let the maintainers of arch foo add further fixes to the fc7 branch of the packages and let them ship their "FCx for arch foo" when they become ready. They just have to be sure that they apply their fixes to both FCx and devel in that case. But I'm sure they will ;) Or am I missing something here? CU thl From jkeating at redhat.com Wed Nov 15 12:43:41 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 07:43:41 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <455B061C.8000505@leemhuis.info> References: <1163564205.3396.141.camel@shinybook.infradead.org> <455B061C.8000505@leemhuis.info> Message-ID: <200611150743.41846.jkeating@redhat.com> On Wednesday 15 November 2006 07:20, Thorsten Leemhuis wrote: > That made we wondering: hey, sounds nice. And that makes it possible to > get rid of parts from the "secondary arch" concept again IMHO. If a arch > is ready and tested by the arch maintainers: go ship it together with > x86 and x86_64. If not let the maintainers of arch foo add further fixes > to the fc7 branch of the packages and let them ship their "FCx for arch > foo" when they become ready. They just have to be sure that they apply > their fixes to both FCx and devel in that case. But I'm sure they will ;) > > Or am I missing something here? You're not missing anything. We did this for x86_64, it shipped as the release+updates. So long as you're composing your spin from say FC7 shipped srpms, and FC7-updates shipped srpms, there shouldn't be a reason you can't call your arch release FC7. I'll reply to David's post when I have more time, just do note that we will _not_ make any changes to any arches until the shadowbuild feature is in place and functional. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Wed Nov 15 21:47:39 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 15 Nov 2006 16:47:39 -0500 Subject: [fab] Secondary Arches In-Reply-To: <455AC36A.7070807@leemhuis.info> References: <1163556702.17611.38.camel@vader.jdub.homelinux.org> <455AC36A.7070807@leemhuis.info> Message-ID: <20061115214739.GA6888@nostromo.devel.redhat.com> > +1 > > It will will probably also lead to questions like "why doesn't the > yum.conf from not working on > arch foo". I'd like to avoid that. I doubt they'd work anyway. You want them with some sort of simple logical separation for mirrors. Plus, if someone has to look up the yum repo definition for a core repository, we are screwing up something bad. Bill From jkeating at redhat.com Wed Nov 15 21:56:20 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Nov 2006 16:56:20 -0500 Subject: [fab] Secondary Arches In-Reply-To: <455AC36A.7070807@leemhuis.info> References: <1163556702.17611.38.camel@vader.jdub.homelinux.org> <455AC36A.7070807@leemhuis.info> Message-ID: <200611151656.20624.jkeating@redhat.com> On Wednesday 15 November 2006 02:36, Thorsten Leemhuis wrote: > It will will probably also lead to questions like "why doesn't the > yum.conf from not working on > arch foo". I'd like to avoid that. Yum configs point to a mirror list, the mirror list can point anywhere we want. No extra packaging needed, just usage of the mirror files correctly. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Wed Nov 15 22:12:37 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 15 Nov 2006 17:12:37 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <1163564205.3396.141.camel@shinybook.infradead.org> References: <1163564205.3396.141.camel@shinybook.infradead.org> Message-ID: <20061115221237.GB6888@nostromo.devel.redhat.com> David Woodhouse (dwmw2 at infradead.org) said: > I'm concerned by some of the details though -- and I'm especially > concerned by the fact that it seems like a retrograde step for > architectures which are currently built in rawhide but which aren't > listed in the new set of 'primary architectures', by taking away their > current build infrastructure. That's not 'encouraging extra > architectures' -- it's very much the opposite, for those architectures > which are _most_ viable of the non-'primary' set. Public build system does not necessarily allow for it for all the arches that are currently built for rawhide. The simplest way to achieve something is via the shadow mechanism mentioned. > I'm particularly interested in the decision to stop counting PowerPC as > a primary architecture. I've heard rumours that this decision was in > part because PPC was responsible for most of the recent release slippage > -- but that doesn't seem to be backed up by the slip announcements -- > the first one for FC6? lists only one PPC-specific issue in the five > problems that caused the slip, and the second one? doesn't seem to > mention _anything_ that's specific to PPC. Off the top of my head, I can remember: - bad package ordering - wrong kernels being installed - inability to do automated testing > The FAQ also says "there is a reason to stop doing PPC as a primary arch > until/unless it reaches critical mass once again". What, specifically, > is the reason mentioned there? Demand for PPC has *decreased* for each release since its introuction, going by the torrent stats. If it's really that alive, there should be no problem getting a community to maintain it, correct? > (In fact, I'd suggest that we don't make such a clear technical > distinction between 'primary' and 'secondary' in the build system -- it > should all be done through the same mechanism, See above. > 1. A clear intention _not_ to move backwards for architectures like > IA64 which are _so_ close to having a 'proper' Fedora release, and > have already got FC6 ISO images built. It was looking quite likely > that if they keep up the good work, they could perhaps have had > an official FC7/IA64 release. I don't want our changes to make that > any _less_ likely, for FC7. You misunderstand. Any release built solely from Fedora Source (*) can be called Fedora. > 3. A commitment that the existing build machines will not suddenly be > made unavailable until/unless suitable replacement arrangements are > in place for _all_ current Rawhide architectures. That's not feasible. We don't have the resources for a s/390, and I doubt any one is going to cough one up. (No, not hercules.) > 4. A commitment to quality -- in particular a commitment that > developers will not suddenly find it acceptable to commit x86-only > code (assuming little-endianness, including inline assembly etc.). Yes, we're all about running amok polluting the pristine PPC code with little-endian viruses. Sheesh. Bill From notting at redhat.com Wed Nov 15 22:15:31 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 15 Nov 2006 17:15:31 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <20061115221237.GB6888@nostromo.devel.redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061115221237.GB6888@nostromo.devel.redhat.com> Message-ID: <20061115221531.GC6888@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: In any case, the propsal for how we're handling arches is going to go to the board - we haven't implemented anything yet. It will almost certainly be tweaked. The status of what arches are primary vs. secondary is a separate issue, and is also going to the board. Bill From katzj at redhat.com Wed Nov 15 22:33:33 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 15 Nov 2006 17:33:33 -0500 Subject: [fab] Secondary Arches In-Reply-To: <1163556702.17611.38.camel@vader.jdub.homelinux.org> References: <1163556702.17611.38.camel@vader.jdub.homelinux.org> Message-ID: <1163630013.22892.15.camel@aglarond.local> On Tue, 2006-11-14 at 20:11 -0600, Josh Boyer wrote: > That being said, I agree with spot. There are two key issues that are > essentially taking a great idea and sinking it immediately. In order > for secondary arches to really work, I believe the arch teams need to be > able to host repositories along side the primary arches on > fedoraproject.org, and binary isos for the arches (if available) should > also be hosted. While in I agree that we _want_ to be able to do this, do we want to hold up any progress on secondary arches on a) ensuring available space[1] and b) setting up a sane[2] infrastructure for handling the putting up of the arch trees/ISOs? I don't personally think so. [snip easily avoidable bit :-] > However, it hints at another > issue which is the fact that people go to http://fedoraproject.org/ to > download Fedora. If they now have to go to foo.bar.com to download it, > you lose brand distinction. Except that even now to download Fedora, you go to mirror.kernel.org (or other local mirror site of your choice). We're not saying that we're not going to prominently link on the "Download Fedora" page. Jeremy [1] And sending 160GB drives doesn't help ;-) That's not the sort of available and mirrorable space that's really needed to be able to work within the existing infrastructure we've got for hosting content [2] I really don't want more instances along the lines of how Extras packages get up now. In fact, I hope that we manage to "fix" that with some of the other pieces in play. From davej at redhat.com Thu Nov 16 00:19:40 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 15 Nov 2006 19:19:40 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <1163564205.3396.141.camel@shinybook.infradead.org> References: <1163564205.3396.141.camel@shinybook.infradead.org> Message-ID: <20061116001939.GC3983@redhat.com> On Wed, Nov 15, 2006 at 05:57:04AM -0600, David Woodhouse wrote: > I'm particularly interested in the decision to stop counting PowerPC as > a primary architecture. I've heard rumours that this decision was in > part because PPC was responsible for most of the recent release slippage > -- but that doesn't seem to be backed up by the slip announcements -- > the first one for FC6? lists only one PPC-specific issue in the five > problems that caused the slip, and the second one? doesn't seem to > mention _anything_ that's specific to PPC. >From my perspective, one reason to relegate PPC to secondary is that when you're busy, *NO-ONE* looks at or works on PPC kernel bugs. Half the time I feel like I'm the only person looking at x86, but that's irrelevant -- I (and most other people who look at Fedora kernel bugs) have no PPC knowledge whatsoever. (And likely to stay that way). It's completely unacceptable to have an architecture be considered primary when we can't do a thing about any incoming bugs, especially when those bugs are of the form "my Mac doesn't boot". If they were "my sound doesn't work", it'd be a lesser issue, but they're nearly always the nasty "oh crap" species of bug. Note, in no way am I saying this is a failure on your part, I completely realise that you've been buried alive in OLPC stuff the last few months, but we don't have a "stand-in dwmw2". There may be a handful of @redhat.com folks with the prerequisite ppc knowledge, but unless they have a) the time and b) the motivation, these bugs aren't going to get fixed. I've tried engaging upstream (benh, paulus etc) on some of the obvious PPC bugs, some stick, and then get fixed upstream, others.. not so much. Looking at the current bug FC6 kernel lists, there's only a half dozen obvious "ppc only" bugs out of 213, but that considering it's used a lot less than x86/x86-64, the ratio of bugs/users is probably the pretty close. The only difference is that the x86/x86-64 bugs are getting attention (slowly but surely). Dave -- http://www.codemonkey.org.uk From sundaram at fedoraproject.org Thu Nov 16 00:54:06 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 16 Nov 2006 06:24:06 +0530 Subject: [fab] Lone Wolves - Web, game, and open source development In-Reply-To: <1163510649.4225.54.camel@localhost.localdomain> References: <1163510649.4225.54.camel@localhost.localdomain> Message-ID: <455BB6AE.9040407@fedoraproject.org> Michael Tiemann wrote: > Given all the discussion we recently had on the fedora lists about > where, precisely to draw the line between acceptable and not acceptable > when it comes to 3rd-party drivers and BIOS blobs, it looks like the > conversation is moving toward the center of the Ubunutu community as > well... > > http://www.jejik.com/articles/2006/11/is_ubuntu_set_to_become_non-free Installing proprietary drivers were very much the thing not the thing to do (compared to user space proprietary applications) sometime back. This is somewhat a risky move that might yield short term advantages but the long term implications of a mainstream distribution doing something like this and messages that is convey is not so positive. I think this makes it even more important for Fedora to stick with the principles and put more focus into Free software than ever but there are good conversations going on in the Fedora summit solving some of the problems like mp3 codecs in a legal way without compromising on that. Interesting times. Rahul From jwboyer at jdub.homelinux.org Thu Nov 16 02:51:03 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 15 Nov 2006 20:51:03 -0600 Subject: [fab] Secondary Arches In-Reply-To: <1163630013.22892.15.camel@aglarond.local> References: <1163556702.17611.38.camel@vader.jdub.homelinux.org> <1163630013.22892.15.camel@aglarond.local> Message-ID: <1163645463.17611.60.camel@vader.jdub.homelinux.org> On Wed, 2006-11-15 at 17:33 -0500, Jeremy Katz wrote: > On Tue, 2006-11-14 at 20:11 -0600, Josh Boyer wrote: > > That being said, I agree with spot. There are two key issues that are > > essentially taking a great idea and sinking it immediately. In order > > for secondary arches to really work, I believe the arch teams need to be > > able to host repositories along side the primary arches on > > fedoraproject.org, and binary isos for the arches (if available) should > > also be hosted. > > While in I agree that we _want_ to be able to do this, do we want to > hold up any progress on secondary arches on a) ensuring available > space[1] and b) setting up a sane[2] infrastructure for handling the > putting up of the arch trees/ISOs? I don't personally think so. What progress? Seriously. Take two of the proposed secondary arches. Sparc isn't held up because basically Aurora is doing about 90% of the work already anyway. It's just doesn't have the Fedora name. Making those builds use the Fedora buildsys (via shadow builds) and putting those rpms on the fedoraproject.org servers is the final step in the evolution of that project. Then look at PPC. How can you expect me to believe that taking an arch that _already_ has storage and ISOs and just dropping that off of fedoraproject.org because the buildsys can now send out shadow builds is progress? > [snip easily avoidable bit :-] You snipped something I wish you would have commented on. The wiki page has "we can't BUILD these packages because we don't have the hardware" as reason to not host the builds. Explain to me why that matters if those exact same builds are good enough to carry the Fedora name? > > However, it hints at another > > issue which is the fact that people go to http://fedoraproject.org/ to > > download Fedora. If they now have to go to foo.bar.com to download it, > > you lose brand distinction. > > Except that even now to download Fedora, you go to mirror.kernel.org (or > other local mirror site of your choice). We're not saying that we're > not going to prominently link on the "Download Fedora" page. For ISOs. For yum repos, we'd lose the mirroring structure already in place for Fedora. I find that to be quite bad. > [1] And sending 160GB drives doesn't help ;-) That's not the sort of > available and mirrorable space that's really needed to be able to work > within the existing infrastructure we've got for hosting content Then tell me what is. I want to know. What _would_ you need to keep the secondary arch builds on fedoraproject.org? > [2] I really don't want more instances along the lines of how Extras > packages get up now. In fact, I hope that we manage to "fix" that with > some of the other pieces in play. I don't follow what you mean here. And here's another question... where do bugs for secondary arches get reported? Is the Fedora bugzilla still used? Or will arches be required create and host their own bugzilla instances? josh From jwboyer at jdub.homelinux.org Thu Nov 16 04:02:38 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 15 Nov 2006 22:02:38 -0600 Subject: [fab] Architecture Policy. In-Reply-To: <20061116001939.GC3983@redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> Message-ID: <1163649758.17611.64.camel@vader.jdub.homelinux.org> On Wed, 2006-11-15 at 19:19 -0500, Dave Jones wrote: > > Note, in no way am I saying this is a failure on your part, I completely > realise that you've been buried alive in OLPC stuff the last few months, > but we don't have a "stand-in dwmw2". There may be a handful of > @redhat.com folks with the prerequisite ppc knowledge, but unless they > have a) the time and b) the motivation, these bugs aren't going to get fixed. > I've tried engaging upstream (benh, paulus etc) on some of the obvious > PPC bugs, some stick, and then get fixed upstream, others.. not so much. Is there a way to auto-CC someone on a per-arch basis in bugzilla? Contrary to popular belief, we do have a PPC userbase in Fedora and some of them even have kernel-fu. josh From katzj at redhat.com Thu Nov 16 04:15:54 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 15 Nov 2006 23:15:54 -0500 Subject: [fab] Secondary Arches In-Reply-To: <1163645463.17611.60.camel@vader.jdub.homelinux.org> References: <1163556702.17611.38.camel@vader.jdub.homelinux.org> <1163630013.22892.15.camel@aglarond.local> <1163645463.17611.60.camel@vader.jdub.homelinux.org> Message-ID: <1163650554.30164.30.camel@aglarond.local> On Wed, 2006-11-15 at 20:51 -0600, Josh Boyer wrote: > On Wed, 2006-11-15 at 17:33 -0500, Jeremy Katz wrote: > > On Tue, 2006-11-14 at 20:11 -0600, Josh Boyer wrote: > > > That being said, I agree with spot. There are two key issues that are > > > essentially taking a great idea and sinking it immediately. In order > > > for secondary arches to really work, I believe the arch teams need to be > > > able to host repositories along side the primary arches on > > > fedoraproject.org, and binary isos for the arches (if available) should > > > also be hosted. > > > > While in I agree that we _want_ to be able to do this, do we want to > > hold up any progress on secondary arches on a) ensuring available > > space[1] and b) setting up a sane[2] infrastructure for handling the > > putting up of the arch trees/ISOs? I don't personally think so. > > What progress? Seriously. Take two of the proposed secondary arches. > Sparc isn't held up because basically Aurora is doing about 90% of the > work already anyway. It's just doesn't have the Fedora name. Making > those builds use the Fedora buildsys (via shadow builds) and putting > those rpms on the fedoraproject.org servers is the final step in the > evolution of that project. Yes, and Aurora is able to do it due to heroic efforts. It shouldn't be as hard as it is! We want to make it easier now as well as let them use the name (as well as pointing to them on the "Get Fedora" pages in bright red letters :) While hosting is important, I didn't/don't see it as the primary thing stopping these other arch efforts from occurring. And hosting is a pretty significant amount of effort to get going. It's definitely something that is going to have to be tackled a little further into the future for a number of the things we discussed. > Then look at PPC. How can you expect me to believe that taking an arch > that _already_ has storage and ISOs and just dropping that off of > fedoraproject.org because the buildsys can now send out shadow builds is > progress? I think that trying to lump PPC in here has perhaps made the issue a little bit more muddled. So ignore PPC for a minute -- does this not start to improve things for arches like sparc? It's not the whole answer, but it's a start. For PPC, things are a little bit more complicated and it's really just a matter of how much demand the platform is seeing vs the effort required to sustain it. So does it make things less good for ppc? Definitely. But the impetus isn't the existence of secondary arches and shoving the round peg in the square hole. Instead, it's the fact that the number of ppc downloads is very small and the community of people actively testing and fixing things is quite small. > > [snip easily avoidable bit :-] > > You snipped something I wish you would have commented on. The wiki page > has "we can't BUILD these packages because we don't have the hardware" > as reason to not host the builds. Explain to me why that matters if > those exact same builds are good enough to carry the Fedora name? If we don't have the hardware, how does the admin team maintain the machines? How do we deal with a build for a single arch failing? If your question is just "why don't the bits end up on fp.org", the reason is purely one of "we're not attacking that problem first". And realistically, setting the expectation that we're not going to solve that problem in the next six months is a far better thing to do IMHO. > > > However, it hints at another > > > issue which is the fact that people go to http://fedoraproject.org/ to > > > download Fedora. If they now have to go to foo.bar.com to download it, > > > you lose brand distinction. > > > > Except that even now to download Fedora, you go to mirror.kernel.org (or > > other local mirror site of your choice). We're not saying that we're > > not going to prominently link on the "Download Fedora" page. > > For ISOs. For yum repos, we'd lose the mirroring structure already in > place for Fedora. I find that to be quite bad. We can still have the mirror CGI URLs work; so we don't necessarily lose anything for yum repos either. And hopefully, we can enable an easy way for mirrors to opt-in tied in with the rest of the mirror infrastructure. Realistically, though, a lot of mirrors aren't going to carry all the arches even if they _were_ hosted on fedoraproject.org. The amount of space that is required for a full mirror continues to grow at an astonishing rate. > > [1] And sending 160GB drives doesn't help ;-) That's not the sort of > > available and mirrorable space that's really needed to be able to work > > within the existing infrastructure we've got for hosting content > > Then tell me what is. I want to know. What _would_ you need to keep > the secondary arch builds on fedoraproject.org? The backend storage of download.fedora is netapps at this point. So that's where the expansion has to happen. > > [2] I really don't want more instances along the lines of how Extras > > packages get up now. In fact, I hope that we manage to "fix" that with > > some of the other pieces in play. > > I don't follow what you mean here. There's crazy shenanigans to get packages from the needsign queue on the buildsys master to download.fedora. > And here's another question... where do bugs for secondary arches get > reported? Is the Fedora bugzilla still used? Or will arches be > required create and host their own bugzilla instances? Centralized information -- Get the bugs in our bugzilla! Get the source in our SCM! Key off of build requests in our build infrastructure! Use the same tools to build the release! And yes, eventually, host the bits on our servers. But I just don't see how we make that happen in the short (~ 6-ish months) term with all of the other infrastructure things that are underway. Jeremy From katzj at redhat.com Thu Nov 16 04:16:26 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 15 Nov 2006 23:16:26 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <1163649758.17611.64.camel@vader.jdub.homelinux.org> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <1163649758.17611.64.camel@vader.jdub.homelinux.org> Message-ID: <1163650586.30164.32.camel@aglarond.local> On Wed, 2006-11-15 at 22:02 -0600, Josh Boyer wrote: > On Wed, 2006-11-15 at 19:19 -0500, Dave Jones wrote: > > Note, in no way am I saying this is a failure on your part, I completely > > realise that you've been buried alive in OLPC stuff the last few months, > > but we don't have a "stand-in dwmw2". There may be a handful of > > @redhat.com folks with the prerequisite ppc knowledge, but unless they > > have a) the time and b) the motivation, these bugs aren't going to get fixed. > > I've tried engaging upstream (benh, paulus etc) on some of the obvious > > PPC bugs, some stick, and then get fixed upstream, others.. not so much. > > Is there a way to auto-CC someone on a per-arch basis in bugzilla? > Contrary to popular belief, we do have a PPC userbase in Fedora and some > of them even have kernel-fu. Sadly, nothing that I know of Jeremy From skvidal at linux.duke.edu Thu Nov 16 04:25:26 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 15 Nov 2006 23:25:26 -0500 Subject: [fab] Secondary Arches In-Reply-To: <1163650554.30164.30.camel@aglarond.local> References: <1163556702.17611.38.camel@vader.jdub.homelinux.org> <1163630013.22892.15.camel@aglarond.local> <1163645463.17611.60.camel@vader.jdub.homelinux.org> <1163650554.30164.30.camel@aglarond.local> Message-ID: <1163651126.23964.22.camel@cutter> On Wed, 2006-11-15 at 23:15 -0500, Jeremy Katz wrote: > > > [2] I really don't want more instances along the lines of how Extras > > > packages get up now. In fact, I hope that we manage to "fix" that with > > > some of the other pieces in play. > > > > I don't follow what you mean here. > > There's crazy shenanigans to get packages from the needsign queue on the > buildsys master to download.fedora. Actually there are two pieces: packages push from build master to fedoraproject.org - those get rsynced to download.fedora. The reason we don't just push directly to download.fedora is that there isn't, apparently, any way to do that from outside. It is a more work than it should be. -sv From dennis at ausil.us Thu Nov 16 04:43:07 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 15 Nov 2006 22:43:07 -0600 Subject: [fab] Architecture Policy. In-Reply-To: <1163649758.17611.64.camel@vader.jdub.homelinux.org> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <1163649758.17611.64.camel@vader.jdub.homelinux.org> Message-ID: <200611152243.13209.dennis@ausil.us> Once upon a time Wednesday 15 November 2006 10:02 pm, Josh Boyer wrote: > Is there a way to auto-CC someone on a per-arch basis in bugzilla? > Contrary to popular belief, we do have a PPC userbase in Fedora and some > of them even have kernel-fu. > > josh Last time I asked i was told it was possible. But could never find out who i needed to ask so that all extras bugs reported against sparc were CC to me automatically. I was told that a component can not have a per arch owner in bugzilla. In the end I i wrote a hack of a perl script that parses the output of describecomponents.cgi and inserts the records in another bugzilla instance database. I used it for extras and core for aurora. I think we need a way for whatever bug tracker we use to have a way for people to watch / be auto assigned bugs based on arch. perhaps implemeted through a mail alias for each arch team. any sparc bug gets auto cc sparc-team at fedoraproject.org ppc bugs ppc-team at fedoraproject.org etc, it should not be a mailing list. you have a public record in bugzilla. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Thu Nov 16 05:08:03 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 15 Nov 2006 23:08:03 -0600 Subject: [fab] Secondary Arches In-Reply-To: <1163650554.30164.30.camel@aglarond.local> References: <1163556702.17611.38.camel@vader.jdub.homelinux.org> <1163645463.17611.60.camel@vader.jdub.homelinux.org> <1163650554.30164.30.camel@aglarond.local> Message-ID: <200611152308.11425.dennis@ausil.us> Once upon a time Wednesday 15 November 2006 10:15 pm, Jeremy Katz wrote: > On Wed, 2006-11-15 at 20:51 -0600, Josh Boyer wrote: > There's crazy shenanigans to get packages from the needsign queue on the > buildsys master to download.fedora. Its very crazy but oh well it will be better im sure. > > And here's another question... where do bugs for secondary arches get > > reported? Is the Fedora bugzilla still used? Or will arches be > > required create and host their own bugzilla instances? > > Centralized information -- Get the bugs in our bugzilla! Get the > source in our SCM! Key off of build requests in our build > infrastructure! Use the same tools to build the release! This is something ive been wanting to try and do for awhile now ive just never found an easy way to queue my builds based on the upstream builds. Without something at upstream saying go build this now. cvs is not right i could change things even tag it but not build and id have to work out some way to get the right tag to build. right now i rsync the srpm tree and queue all packages in alphabetical order. so sometimes things get built out of order. > And yes, eventually, host the bits on our servers. But I just don't see > how we make that happen in the short (~ 6-ish months) term with all of > the other infrastructure things that are underway. in infrastructure we have a huge amount of projects on the go and even more now with this. we could start with some simple things though like having the mirror cgi setup to handle sparc, and alpha. Has anyone been in touch with the alphacore guys at all? Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Thu Nov 16 07:59:43 2006 From: davej at redhat.com (Dave Jones) Date: Thu, 16 Nov 2006 02:59:43 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <1163654875.21366.77.camel@shinybook.infradead.org> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <1163654875.21366.77.camel@shinybook.infradead.org> Message-ID: <20061116075943.GB2387@redhat.com> On Thu, Nov 16, 2006 at 01:27:55PM +0800, David Woodhouse wrote: > > Looking at the current bug FC6 kernel lists, there's only a half dozen > > obvious "ppc only" bugs out of 213, but that considering it's used > > a lot less than x86/x86-64, the ratio of bugs/users is probably the > > pretty close. The only difference is that the x86/x86-64 bugs are getting > > attention (slowly but surely). > > To confirm your meaning above: You're saying that the number of PowerPC > bugs _isn't_ out of proportion -- that the 6/213 you see is what you > might reasonable expect from the statistics? It isn't out of proportion? Maybe it's because I don't have direct exposure as a user of ppc that it seems to be in more of a dire state than it is, but 99% of bugs that get filed for ppc are "this doesn't boot/install", which is a showstopper. Compared that to things like "my sound doesn't work" "I got an oops" "nfs doesn't work" or anything else that pops up on the more common archs. Some bugs get reported a lot more than others, like when say, CIFS is broken. This sort of thing never gets reported on PPC, even though it's equally as affected. Now, that may imply that PPC users don't care about CIFS, NFS and sound, or it could imply that there's not a sufficient userbase period. Or it could be just "it didn't even install, so I didn't get that far". We've no real metrics other than the types of bugs that /do/ get filed, and the download stats, which have been dropping off every release from what I hear. (unsurprising given the only people that previously cared with either a) mac users, who are now a dying breed due to the x86 migration or b) folks like IBM who used Fedora as a testbed until a ppc RHEL beta came along). > It is my perception that the PowerPC kernel _does_ get attention -- also > slowly, but surely. Our hardware support is better now than it was with > the FC4 release, and hardware manufacturers have been working with us to > include new hardware while we've also had improvements in support for > older machines. I don't recall there being as many "doesn't boot" complaints in FC4 or FC5 as what we have open in FC6. > If the amount/speed of bug handling is considered to be a problem, then > I'm very sure we can improve on that. Fedora doesn't have to be all > @redhat.com people, and we can _certainly_ get assistance from others if > it's known to be necessary. Right, and imo, it shouldn't be just @redhat.com people. If we can convince community folks to help, I'm all for it. > My concern is that life gets somewhat fraught around release time, and > there will be no time available, while we're in the middle of the > scramble on x86/x86_64, to work through a _separate_ process for > releasing on PowerPC. And thus that _however_ hard the PowerPC folks > work, we might not be able to release FC7/PPC in sync with the FC7 > release on other architectures because we'd be blocked on approval and > process issues. For FC6, towards the end, PPC got very little love, and that's continuing post-release. Unless something changes, we shouldn't pretend to care about it equally as much as x86/x86-64 whilst simultaneously letting it become the red headed stepchild for FC7. > Thus the suggestion -- and I know I'm repeating myself here -- that we > don't use PowerPC as a guinea pig for the new process. Use it first to > bring Aurora and/or AlphaCore into the fold, rather than breaking an > architecture which is working already today. Sparc/Alpha is an unknown commodity at this point wrt to "do things get fixed when users report them broken" (at least from my point of view, I've no idea how those projects even track bugs if they do at all), so I don't think it's really an apples/oranges comparison to PPC. If you really believe that PPC can remain as a primary answer, the solution isn't persuading me, or the f-a-b, or really anyone else to change policies. The solution is to improve the situation so that there's something in place so that users don't get left dangling when they report bugs. Dennis mentioned the idea of having per-arch mailing lists for such things that could get CC'd/assigned bugs. If there was sufficient interest from folks, then I'd agree that'd be a great start. Dave -- http://www.codemonkey.org.uk From mmcgrath at fedoraproject.org Thu Nov 16 15:06:00 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 16 Nov 2006 09:06:00 -0600 Subject: [fab] Architecture Policy. In-Reply-To: <20061116001939.GC3983@redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> Message-ID: <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> On 11/15/06, Dave Jones wrote: > On Wed, Nov 15, 2006 at 05:57:04AM -0600, David Woodhouse wrote: > > > I'm particularly interested in the decision to stop counting PowerPC as > > a primary architecture. I've heard rumours that this decision was in > > part because PPC was responsible for most of the recent release slippage > > -- but that doesn't seem to be backed up by the slip announcements -- > > the first one for FC6? lists only one PPC-specific issue in the five > > problems that caused the slip, and the second one? doesn't seem to > > mention _anything_ that's specific to PPC. > > >From my perspective, one reason to relegate PPC to secondary is that > when you're busy, *NO-ONE* looks at or works on PPC kernel bugs. > Half the time I feel like I'm the only person looking at x86, but > that's irrelevant -- I (and most other people who look at Fedora kernel > bugs) have no PPC knowledge whatsoever. (And likely to stay that way). > > It's completely unacceptable to have an architecture be considered > primary when we can't do a thing about any incoming bugs, especially > when those bugs are of the form "my Mac doesn't boot". > If they were "my sound doesn't work", it'd be a lesser issue, but they're > nearly always the nasty "oh crap" species of bug. Just food for thought regarding PPC. I'm not an advocate for or against PPC but I did want to point out that from our stats the PPC's account for a very tiny percentage of our overall userbase http://fedoraproject.org/awstats/stats/FC6-Nov-16.png (0.4%) On a side note, I have no idea if this method of stats collecting really works so take it for what it is :D -Mike From jkeating at redhat.com Thu Nov 16 15:32:45 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 16 Nov 2006 10:32:45 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> Message-ID: <200611161036.31019.jkeating@redhat.com> On Thursday 16 November 2006 10:06, Mike McGrath wrote: > Just food for thought regarding PPC. ?I'm not an advocate for or > against PPC but I did want to point out that from our stats the PPC's > account for a very tiny percentage of our overall userbase > http://fedoraproject.org/awstats/stats/FC6-Nov-16.png (0.4%) ?On a > side note, I have no idea if this method of stats collecting really > works so take it for what it is :D I think it's important to note that the data we can track shows that PPC usage is going down, while at the same time showing that i386 and x86_64 usage is going up. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Thu Nov 16 15:47:15 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 16 Nov 2006 09:47:15 -0600 Subject: [fab] Architecture Policy. In-Reply-To: <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> Message-ID: <1163692035.4340.10.camel@zod.rchland.ibm.com> On Thu, 2006-11-16 at 09:06 -0600, Mike McGrath wrote: > On 11/15/06, Dave Jones wrote: > > On Wed, Nov 15, 2006 at 05:57:04AM -0600, David Woodhouse wrote: > > > > > I'm particularly interested in the decision to stop counting PowerPC as > > > a primary architecture. I've heard rumours that this decision was in > > > part because PPC was responsible for most of the recent release slippage > > > -- but that doesn't seem to be backed up by the slip announcements -- > > > the first one for FC6? lists only one PPC-specific issue in the five > > > problems that caused the slip, and the second one? doesn't seem to > > > mention _anything_ that's specific to PPC. > > > > >From my perspective, one reason to relegate PPC to secondary is that > > when you're busy, *NO-ONE* looks at or works on PPC kernel bugs. > > Half the time I feel like I'm the only person looking at x86, but > > that's irrelevant -- I (and most other people who look at Fedora kernel > > bugs) have no PPC knowledge whatsoever. (And likely to stay that way). > > > > It's completely unacceptable to have an architecture be considered > > primary when we can't do a thing about any incoming bugs, especially > > when those bugs are of the form "my Mac doesn't boot". > > If they were "my sound doesn't work", it'd be a lesser issue, but they're > > nearly always the nasty "oh crap" species of bug. > > Just food for thought regarding PPC. I'm not an advocate for or > against PPC but I did want to point out that from our stats the PPC's > account for a very tiny percentage of our overall userbase > http://fedoraproject.org/awstats/stats/FC6-Nov-16.png (0.4%) On a > side note, I have no idea if this method of stats collecting really > works so take it for what it is :D That can't account for people getting things directly from mirrors. And if a certain large PowerPC company has an internal tier 1 mirror of Fedora you won't get any hits from there for PPC. Remember, 90% of all statistics are lies ;) That's certainly not to say that PPC isn't a smaller userbase than x86/x86_64. I think that's fairly common knowledge. I just happen to think the tracking doesn't give you the full picture for anything really. And I would guess that the userbase for everything is larger than what those statistics are saying. Whether it's accurately proportional can be debated forever. josh From blizzard at redhat.com Thu Nov 16 15:56:52 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 16 Nov 2006 10:56:52 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <1163692035.4340.10.camel@zod.rchland.ibm.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> Message-ID: <455C8A44.6050700@redhat.com> Josh Boyer wrote: > That can't account for people getting things directly from mirrors. And > if a certain large PowerPC company has an internal tier 1 mirror of > Fedora you won't get any hits from there for PPC. Remember, 90% of all > statistics are lies ;) Yet another reason to bring up measuring our installed base, as opposed to download numbers. We're arguing here without a lot of data and it shows. --Chris From skvidal at linux.duke.edu Thu Nov 16 16:02:03 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 16 Nov 2006 11:02:03 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <455C8A44.6050700@redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8A44.6050700@redhat.com> Message-ID: <1163692923.29597.3.camel@cutter> On Thu, 2006-11-16 at 10:56 -0500, Christopher Blizzard wrote: > Josh Boyer wrote: > > That can't account for people getting things directly from mirrors. And > > if a certain large PowerPC company has an internal tier 1 mirror of > > Fedora you won't get any hits from there for PPC. Remember, 90% of all > > statistics are lies ;) > > Yet another reason to bring up measuring our installed base, as opposed > to download numbers. We're arguing here without a lot of data and it shows. > You seriously think that the numbers of ppc users compared to x86/x86_64 users is seriously skewed in the numbers mike presented? Where do they get the machines? ps3 users? gamecubes? people buying macs off of ebay? -sv From mmcgrath at fedoraproject.org Thu Nov 16 16:02:49 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 16 Nov 2006 10:02:49 -0600 Subject: [fab] Architecture Policy. In-Reply-To: <455C8A44.6050700@redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8A44.6050700@redhat.com> Message-ID: <3237e4410611160802p1339a92eo89c89c9e990e2233@mail.gmail.com> On 11/16/06, Christopher Blizzard wrote: > Josh Boyer wrote: > > That can't account for people getting things directly from mirrors. And > > if a certain large PowerPC company has an internal tier 1 mirror of > > Fedora you won't get any hits from there for PPC. Remember, 90% of all > > statistics are lies ;) > > Yet another reason to bring up measuring our installed base, as opposed > to download numbers. We're arguing here without a lot of data and it shows. > > --Chris > These aren't download numbers, these are unique IP's that have contacted the mirrors.fp.o site looking for updates-released-fc6. Not saying they're exact. But it will catch users using default yum configs. We should restart the metrics conversation soon. There's a lot of smart people on the list, hopefully we can figure out something clever without being too invasive. -Mike From blizzard at redhat.com Thu Nov 16 16:08:38 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 16 Nov 2006 11:08:38 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <1163692035.4340.10.camel@zod.rchland.ibm.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> Message-ID: <455C8D06.5080807@redhat.com> I just wanted to follow up with my thoughts on this topic from the meeting. Some of it is colored with my own ideas, and I'm sorry for that. But I wanted to make sure that everyone understood what we were talking about doing here. Feedback is welcome. The problem that we're trying to solve here is two-fold in my opinion. 1. That the arches with very little market share (ppc, s390, ia64) are part of the build process and they die on a regular basis. We want a way to decouple active development from the smaller arches in a way that still allows them to thrive. 2. Encouraging development for the community that cares about the smaller arches. Let's face it, lots of interesting and smart people spend time on the smaller arches. They are passionate and they care, and their work almost always encourages the whole of the project. And you never know when a big project might come along that uses one of those arches, and you want to be ready when it does. #1 means that we need to make it possible to have "following" builds for the smaller arches. That's going to require changes on our part, something we want to do. It also means that anyone can contribute a set of build machines for one of those arches. I think that was an important part of making it successful as well. #2 is more subtle, and I think that we found a few things that make it possible. We're opening up the entire tree which means that you can substantially increase the number of people who can participate from the community all over the tree to fix small arch problems. People who care about ppc can work anywhere, any time. That's what the arch teams are for. Also, if you can build from Fedora sources, you can call it Fedora. We're happy to host the builds as official builds on the download page, even if they show up later than the official release. --Chris From jkeating at redhat.com Thu Nov 16 16:38:09 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 16 Nov 2006 11:38:09 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <455C8D06.5080807@redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> Message-ID: <200611161138.09822.jkeating@redhat.com> On Thursday 16 November 2006 11:08, Christopher Blizzard wrote: > Also, if you can build from Fedora sources, you can call it > Fedora. I don't want to go too far down this road without some real thought put behind the branding and trademark issues. Just building from Fedora sources isn't enough, what if I rebuilt everything with the Intel compiler, or with funroll-loops or whatever other crack I wanted to do? Should I still call it Fedora? I'm leaning toward no. I strongly think that if we go down this route its going to need to at LEAST be 'built from unmodified Fedora sources by unmodified Fedora tools' before you can call it 'Fedora'. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Thu Nov 16 17:11:26 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 16 Nov 2006 11:11:26 -0600 Subject: [fab] Architecture Policy. In-Reply-To: <200611161138.09822.jkeating@redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <200611161138.09822.jkeating@redhat.com> Message-ID: <455C9BBE.6060206@math.unl.edu> Jesse Keating wrote: > On Thursday 16 November 2006 11:08, Christopher Blizzard wrote: >> Also, if you can build from Fedora sources, you can call it >> Fedora. > > I don't want to go too far down this road without some real thought put behind > the branding and trademark issues. Just building from Fedora sources isn't > enough, what if I rebuilt everything with the Intel compiler, or with > funroll-loops or whatever other crack I wanted to do? Those example items (Intel compiler, modified rpmoptflags) aren't from stock Fedora, so the answer is easy, it's no longer Fedora. -- Rex From notting at redhat.com Thu Nov 16 18:10:44 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 16 Nov 2006 13:10:44 -0500 Subject: [fab] Secondary Arches In-Reply-To: <1163651126.23964.22.camel@cutter> References: <1163556702.17611.38.camel@vader.jdub.homelinux.org> <1163630013.22892.15.camel@aglarond.local> <1163645463.17611.60.camel@vader.jdub.homelinux.org> <1163650554.30164.30.camel@aglarond.local> <1163651126.23964.22.camel@cutter> Message-ID: <20061116181044.GB5704@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > Actually there are two pieces: > packages push from build master to fedoraproject.org - those get rsynced > to download.fedora. The reason we don't just push directly to > download.fedora is that there isn't, apparently, any way to do that from > outside. > > It is a more work than it should be. To draw a little picture, when you build a package for Extras, the road it takes is: - your box (make upload) - Phoenix (cvs.fedora) - Duke (build master) - Phoenix (build boxes) - Duke (build master) - RDU (mirror master) - Phoenix (mirrors) It isn't the most efficient process. Bill From mmcgrath at fedoraproject.org Thu Nov 16 18:13:03 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 16 Nov 2006 12:13:03 -0600 Subject: [fab] Secondary Arches In-Reply-To: <20061116181044.GB5704@nostromo.devel.redhat.com> References: <1163556702.17611.38.camel@vader.jdub.homelinux.org> <1163630013.22892.15.camel@aglarond.local> <1163645463.17611.60.camel@vader.jdub.homelinux.org> <1163650554.30164.30.camel@aglarond.local> <1163651126.23964.22.camel@cutter> <20061116181044.GB5704@nostromo.devel.redhat.com> Message-ID: <3237e4410611161013h5d836c01heb2b73dcf7edd317@mail.gmail.com> On 11/16/06, Bill Nottingham wrote: > seth vidal (skvidal at linux.duke.edu) said: > > Actually there are two pieces: > > packages push from build master to fedoraproject.org - those get rsynced > > to download.fedora. The reason we don't just push directly to > > download.fedora is that there isn't, apparently, any way to do that from > > outside. > > > > It is a more work than it should be. > > To draw a little picture, when you build a package for Extras, the road > it takes is: > > - your box (make upload) > - Phoenix (cvs.fedora) > - Duke (build master) > - Phoenix (build boxes) > - Duke (build master) > - RDU (mirror master) > - Phoenix (mirrors) > > It isn't the most efficient process. > > Bill Yeah, the packages bounce around a lot but has that been a pain point for anyone? -Mike From notting at redhat.com Thu Nov 16 18:16:02 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 16 Nov 2006 13:16:02 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <1163649758.17611.64.camel@vader.jdub.homelinux.org> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <1163649758.17611.64.camel@vader.jdub.homelinux.org> Message-ID: <20061116181602.GC5704@nostromo.devel.redhat.com> Josh Boyer (jwboyer at jdub.homelinux.org) said: > Is there a way to auto-CC someone on a per-arch basis in bugzilla? > Contrary to popular belief, we do have a PPC userbase in Fedora and some > of them even have kernel-fu. Not currently. This is something we'd want to solve to properly involve the arch teams for whatever arches in the plan. Bill From notting at redhat.com Thu Nov 16 18:22:11 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 16 Nov 2006 13:22:11 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <1163692035.4340.10.camel@zod.rchland.ibm.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> Message-ID: <20061116182211.GD5704@nostromo.devel.redhat.com> Josh Boyer (jwboyer at jdub.homelinux.org) said: > That can't account for people getting things directly from mirrors. And > if a certain large PowerPC company has an internal tier 1 mirror of > Fedora you won't get any hits from there for PPC. Remember, 90% of all > statistics are lies ;) True, but in the absence of anything, we have to go with the statistics we have, and those statistics say that PPC ranges from 0.4% of the userbase (Mike's graph) to 1.59% (bittorrent stats.) And I don't think we can just handwave 'that's not relevant', especially considering that some of those large PowerPC companies machines obviously aren't being tested with Fedora. (see: iSeries) Bill From skvidal at linux.duke.edu Thu Nov 16 18:24:46 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 16 Nov 2006 13:24:46 -0500 Subject: [fab] Secondary Arches In-Reply-To: <20061116181044.GB5704@nostromo.devel.redhat.com> References: <1163556702.17611.38.camel@vader.jdub.homelinux.org> <1163630013.22892.15.camel@aglarond.local> <1163645463.17611.60.camel@vader.jdub.homelinux.org> <1163650554.30164.30.camel@aglarond.local> <1163651126.23964.22.camel@cutter> <20061116181044.GB5704@nostromo.devel.redhat.com> Message-ID: <1163701486.30351.0.camel@cutter> On Thu, 2006-11-16 at 13:10 -0500, Bill Nottingham wrote: > seth vidal (skvidal at linux.duke.edu) said: > > Actually there are two pieces: > > packages push from build master to fedoraproject.org - those get rsynced > > to download.fedora. The reason we don't just push directly to > > download.fedora is that there isn't, apparently, any way to do that from > > outside. > > > > It is a more work than it should be. > > To draw a little picture, when you build a package for Extras, the road > it takes is: > > - your box (make upload) > - Phoenix (cvs.fedora) > - Duke (build master) > - Phoenix (build boxes) > - Duke (build master) > - RDU (mirror master) > - Phoenix (mirrors) > > It isn't the most efficient process. And the reason I've been big on some pieces staying outside of red hat colo space is simple: this way if some VP at red hat decides to be stupid they can't shut fedora down. They have to get legal involved to come to duke to get us to shut down a piece. I like that. -sv From jkeating at redhat.com Thu Nov 16 21:42:42 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 16 Nov 2006 16:42:42 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <455C9BBE.6060206@math.unl.edu> References: <1163564205.3396.141.camel@shinybook.infradead.org> <200611161138.09822.jkeating@redhat.com> <455C9BBE.6060206@math.unl.edu> Message-ID: <200611161642.42887.jkeating@redhat.com> On Thursday 16 November 2006 12:11, Rex Dieter wrote: > Those example items (Intel compiler, modified rpmoptflags) aren't from > stock Fedora, so the answer is easy, it's no longer Fedora. Sure, but how can you tell? How can you tell what somebody might have done to get from point A) source rpms to point B) binary rpms wrapped up in an iso? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Thu Nov 16 21:47:06 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 16 Nov 2006 15:47:06 -0600 Subject: [fab] Architecture Policy. In-Reply-To: <200611161642.42887.jkeating@redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <200611161138.09822.jkeating@redhat.com> <455C9BBE.6060206@math.unl.edu> <200611161642.42887.jkeating@redhat.com> Message-ID: <455CDC5A.9070404@math.unl.edu> Jesse Keating wrote: > On Thursday 16 November 2006 12:11, Rex Dieter wrote: >> Those example items (Intel compiler, modified rpmoptflags) aren't from >> stock Fedora, so the answer is easy, it's no longer Fedora. > > Sure, but how can you tell? How can you tell what somebody might have done to > get from point A) source rpms to point B) binary rpms wrapped up in an iso? So, use of non-trusted buildsystems (ie, outside of normal Fedora infrastructure) are out of the question (if you want to call it Fedora)? I see a chicken-and-egg in there somewhere... -- Rex From davej at redhat.com Thu Nov 16 21:49:31 2006 From: davej at redhat.com (Dave Jones) Date: Thu, 16 Nov 2006 16:49:31 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <200611161642.42887.jkeating@redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <200611161138.09822.jkeating@redhat.com> <455C9BBE.6060206@math.unl.edu> <200611161642.42887.jkeating@redhat.com> Message-ID: <20061116214931.GG3983@redhat.com> On Thu, Nov 16, 2006 at 04:42:42PM -0500, Jesse Keating wrote: > On Thursday 16 November 2006 12:11, Rex Dieter wrote: > > Those example items (Intel compiler, modified rpmoptflags) aren't from > > stock Fedora, so the answer is easy, it's no longer Fedora. > > Sure, but how can you tell? How can you tell what somebody might have done to > get from point A) source rpms to point B) binary rpms wrapped up in an iso? The intel compiler is an easy one - you can't compile the kernel (and probably a bunch of other apps) without patches right now. I see your point though, rpmoptflags would be a trickier one to spot. Dave -- http://www.codemonkey.org.uk From notting at redhat.com Thu Nov 16 21:48:16 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 16 Nov 2006 16:48:16 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <200611161642.42887.jkeating@redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <200611161138.09822.jkeating@redhat.com> <455C9BBE.6060206@math.unl.edu> <200611161642.42887.jkeating@redhat.com> Message-ID: <20061116214816.GA3263@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > Sure, but how can you tell? How can you tell what somebody might have done to > get from point A) source rpms to point B) binary rpms wrapped up in an iso? So, you'd ship a system that doesn't use the bits you use to build it? Why would someone go to that much effort? Bill From jkeating at redhat.com Thu Nov 16 21:57:58 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 16 Nov 2006 16:57:58 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <20061116214816.GA3263@nostromo.devel.redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <200611161642.42887.jkeating@redhat.com> <20061116214816.GA3263@nostromo.devel.redhat.com> Message-ID: <200611161657.59043.jkeating@redhat.com> On Thursday 16 November 2006 16:48, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > Sure, but how can you tell? ?How can you tell what somebody might have > > done to get from point A) source rpms to point B) binary rpms wrapped up > > in an iso? > > So, you'd ship a system that doesn't use the bits you use to build > it? Why would someone go to that much effort? I don't know, but I just think a blanket "built from Fedora sources can be Fedora" is a bit too far reaching. "Built from Fedora sources by Fedora tools" seems a bit safer to me, but still should get board approval to use the logo/trademark. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Thu Nov 16 22:10:34 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 16 Nov 2006 16:10:34 -0600 Subject: [fab] Architecture Policy. In-Reply-To: <200611161657.59043.jkeating@redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <200611161642.42887.jkeating@redhat.com> <20061116214816.GA3263@nostromo.devel.redhat.com> <200611161657.59043.jkeating@redhat.com> Message-ID: <1163715034.4340.20.camel@zod.rchland.ibm.com> On Thu, 2006-11-16 at 16:57 -0500, Jesse Keating wrote: > On Thursday 16 November 2006 16:48, Bill Nottingham wrote: > > Jesse Keating (jkeating at redhat.com) said: > > > Sure, but how can you tell? How can you tell what somebody might have > > > done to get from point A) source rpms to point B) binary rpms wrapped up > > > in an iso? > > > > So, you'd ship a system that doesn't use the bits you use to build > > it? Why would someone go to that much effort? > > I don't know, but I just think a blanket "built from Fedora sources can be > Fedora" is a bit too far reaching. "Built from Fedora sources by Fedora > tools" seems a bit safer to me, but still should get board approval to use > the logo/trademark. How do you conclusively prove that? You'd have to keep mock build logs for every binary in that release for people to look at. josh From max at spevack.org Fri Nov 17 03:15:56 2006 From: max at spevack.org (Max Spevack) Date: Thu, 16 Nov 2006 22:15:56 -0500 (EST) Subject: [fab] Architecture Policy. In-Reply-To: <200611161138.09822.jkeating@redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <200611161138.09822.jkeating@redhat.com> Message-ID: On Thu, 16 Nov 2006, Jesse Keating wrote: > On Thursday 16 November 2006 11:08, Christopher Blizzard wrote: > > Also, if you can build from Fedora sources, you can call it > > Fedora. > > I don't want to go too far down this road without some real thought put behind > the branding and trademark issues. Greg and I are going to have an initial meeting with Chris Grams and some of the branding folks here tomorrow, and initiate the brainstorming process. We are *NOT* just going to make a decision and then inform the community. We're going to try to come up with an initial list of possibilities in a semi-organized fashion, and then bring that to the community and go from there. --Max From mspevack at redhat.com Fri Nov 17 15:23:55 2006 From: mspevack at redhat.com (Max Spevack) Date: Fri, 17 Nov 2006 10:23:55 -0500 (EST) Subject: fc6 checkin stats by arch In-Reply-To: <1163755616.13204.27.camel@enki.eridu> References: <1163755616.13204.27.camel@enki.eridu> Message-ID: On Fri, 17 Nov 2006, Paul Nasrat wrote: > Out of curiosity can we get the arch breakdown for the clients checking > in via yum. CCing f-a-b, since it's of interest in the whole arch discussion. ppc 1427 / 309658 0.46% x86_64 38943 / 309658 12.58% x86 269288 / 309658 86.96 % That's the "unique IP addresses checking in for fc6" total. -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From blizzard at redhat.com Sat Nov 18 16:39:59 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Sat, 18 Nov 2006 11:39:59 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <200611161642.42887.jkeating@redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <200611161138.09822.jkeating@redhat.com> <455C9BBE.6060206@math.unl.edu> <200611161642.42887.jkeating@redhat.com> Message-ID: <455F375F.9090803@redhat.com> Jesse Keating wrote: > On Thursday 16 November 2006 12:11, Rex Dieter wrote: >> Those example items (Intel compiler, modified rpmoptflags) aren't from >> stock Fedora, so the answer is easy, it's no longer Fedora. > > Sure, but how can you tell? How can you tell what somebody might have done to > get from point A) source rpms to point B) binary rpms wrapped up in an iso? It's been built as self-hosting? --Chris From blizzard at redhat.com Sat Nov 18 16:40:57 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Sat, 18 Nov 2006 11:40:57 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <200611161657.59043.jkeating@redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <200611161642.42887.jkeating@redhat.com> <20061116214816.GA3263@nostromo.devel.redhat.com> <200611161657.59043.jkeating@redhat.com> Message-ID: <455F3799.9070009@redhat.com> Jesse Keating wrote: > On Thursday 16 November 2006 16:48, Bill Nottingham wrote: >> Jesse Keating (jkeating at redhat.com) said: >>> Sure, but how can you tell? How can you tell what somebody might have >>> done to get from point A) source rpms to point B) binary rpms wrapped up >>> in an iso? >> So, you'd ship a system that doesn't use the bits you use to build >> it? Why would someone go to that much effort? > > I don't know, but I just think a blanket "built from Fedora sources can be > Fedora" is a bit too far reaching. "Built from Fedora sources by Fedora > tools" seems a bit safer to me, but still should get board approval to use > the logo/trademark. > Or just "Ask us. We're nice people and we love you." --Chris From blizzard at redhat.com Sat Nov 18 16:59:47 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Sat, 18 Nov 2006 11:59:47 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <1163758251.21366.246.camel@shinybook.infradead.org> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> Message-ID: <455F3C03.2070602@redhat.com> David Woodhouse wrote: > On Thu, 2006-11-16 at 11:08 -0500, Christopher Blizzard wrote: >> 1. That the arches with very little market share (ppc, s390, ia64) are >> part of the build process and they die on a regular basis. > > Really? That ('on a regular basis') isn't my experience, whether you're > talking about build machines dying (except the S390) or whether you're > talking about the occasional compiler bugs or failure to build > individual packages. > > Every architecture will suffer occasional build machine outages, > compiler bugs or compile failures in packages -- but I'm certainly not > aware that PowerPC in particular has more than its fair share. > > It sounds like you're just saying "Making a distribution is hard. Let's > do less of it". No, it's "Making a distribution is hard. How do you enable the people who care to be able to take a more active role in making it happen?" >> 2. Encouraging development for the community that cares about the >> smaller arches. Let's face it, lots of interesting and smart people >> spend time on the smaller arches. They are passionate and they care, >> and their work almost always encourages the whole of the project. And >> you never know when a big project might come along that uses one of >> those arches, and you want to be ready when it does. > > It's OK. There seems to be a lot of pressure to use Ubuntu in the one > we're thinking of already -- I'm sure they'll cope if they have to drop > Fedora because we mess up the FC7/PPC release with a new process that > isn't ready for production yet :) > I'm hoping we don't screw it up. I think that we wouldn't have talked about it if we didn't think that what we're doing isn't working today. I want to feel out how we can actually make things better, not worse. Please tell us how we can help enable you and the rest of the PPC community into better partners. It was my hope that by enabling the PPC folks to work with freedom to walk all over the tree as part of a specific arch team that they would get more involved, not less. Do you not think that this is the case? Please tell me if you think I'm wrong about this. --Chris From sopwith at gmail.com Mon Nov 20 02:37:27 2006 From: sopwith at gmail.com (Elliot Lee) Date: Sun, 19 Nov 2006 21:37:27 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <20061116214931.GG3983@redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <200611161138.09822.jkeating@redhat.com> <455C9BBE.6060206@math.unl.edu> <200611161642.42887.jkeating@redhat.com> <20061116214931.GG3983@redhat.com> Message-ID: On Nov 16, 2006, at 4:49 PM, Dave Jones wrote: > The intel compiler is an easy one - you can't compile the kernel > (and probably > a bunch of other apps) without patches right now. I see your point > though, rpmoptflags would be a trickier one to spot. I believe at one point, each binary .rpm encoded the values of all the macros as they were set at build time. Not sure if that's still the case, and I forget exactly how it was implemented (maybe as a RPMTAG stored in the .rpm?) Each binary .rpm also stores the md5 or sha1 of the .src.rpm that it was built from, which means you can tell whether a binary package was built from unmodified .src.rpm's. Best, -- Elliot From mspevack at redhat.com Mon Nov 20 16:05:47 2006 From: mspevack at redhat.com (Max Spevack) Date: Mon, 20 Nov 2006 11:05:47 -0500 (EST) Subject: Board meeting today (with IRC) Message-ID: Re-sending. I messed up my email and I don't think this went out. ---------- Forwarded message ---------- Date: Mon, 20 Nov 2006 10:31:11 -0500 (EST) From: Max Spevack To: fedora-advisory-board at redhat.com Subject: Board meeting today (with IRC) There will be a Fedora Board meeting today at 13:00 Eastern Time (18:00 UTC) Similar to the Fedora Summit last week, we'll have IRC in #fedora-board -- someone will provide a reasonably real-time log of what we're talking about on our phone call. Current agenda items: 0) Any random bits of news. 1) Board needs to vote on/bless Diana Fong as the leader of Fedora Artwork project. 2) Fill people in/answer questions about any of the stuff that happened at the Fedora Summit last week. 3) Update from the Board members who are on FESCO as well about how that meeting went last week, FESCO's general thoughts coming out of the Fedora Summit. 4) Board composition -- proposal on the table is that Elliot Lee will become Board member Emeritus and Greg DeKoenigsberg will fill his seat until the current Board's term ends post-Fedora 7. Board needs to vote on this. 5) Any other business. -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From dwmw2 at infradead.org Fri Nov 17 00:21:30 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 17 Nov 2006 08:21:30 +0800 Subject: [fab] Architecture Policy. In-Reply-To: <20061116214816.GA3263@nostromo.devel.redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <200611161138.09822.jkeating@redhat.com> <455C9BBE.6060206@math.unl.edu> <200611161642.42887.jkeating@redhat.com> <20061116214816.GA3263@nostromo.devel.redhat.com> Message-ID: <1163722890.21366.196.camel@shinybook.infradead.org> On Thu, 2006-11-16 at 16:48 -0500, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > Sure, but how can you tell? How can you tell what somebody might have done to > > get from point A) source rpms to point B) binary rpms wrapped up in an iso? > > So, you'd ship a system that doesn't use the bits you use to build > it? Why would someone go to that much effort? One example that comes immediately to mind is cross-compilation. It's very tempting to cross-compile to support CPUs like ARM --- and fro long bitter experience we _know_ that cross-compilation causes all kinds of interesting screwups -- largely due to the {mis,}use of autotools IIRC. I'm don't think we'd ever want a cross-built distro to be 'blessed'. Scratchbox is better but still I'm not sure. -- dwmw2 From dwmw2 at infradead.org Fri Nov 17 10:02:06 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 17 Nov 2006 18:02:06 +0800 Subject: [fab] Secondary Arches In-Reply-To: <1163650554.30164.30.camel@aglarond.local> References: <1163556702.17611.38.camel@vader.jdub.homelinux.org> <1163630013.22892.15.camel@aglarond.local> <1163645463.17611.60.camel@vader.jdub.homelinux.org> <1163650554.30164.30.camel@aglarond.local> Message-ID: <1163757727.21366.236.camel@shinybook.infradead.org> On Wed, 2006-11-15 at 23:15 -0500, Jeremy Katz wrote: > > Then look at PPC. How can you expect me to believe that taking an arch > > that _already_ has storage and ISOs and just dropping that off of > > fedoraproject.org because the buildsys can now send out shadow builds is > > progress? > > I think that trying to lump PPC in here has perhaps made the issue a > little bit more muddled. So ignore PPC for a minute -- does this not > start to improve things for arches like sparc? It's not the whole > answer, but it's a start. Yes, it _does_ look like a step in the right direction. In the long term; when the dust has settled and it actually works. > For PPC, things are a little bit more complicated and it's really just a > matter of how much demand the platform is seeing vs the effort required > to sustain it. So does it make things less good for ppc? Definitely. Very much so. On the other hand, if we revisit the question in time for FC8 _after_ we test the process by bringing Aurora into the fold, then it doesn't have to be such a retrograde step for PPC. > But the impetus isn't the existence of secondary arches and shoving the > round peg in the square hole. Instead, it's the fact that the number of > ppc downloads is very small and the community of people actively testing > and fixing things is quite small. Nevertheless, it was my impression that FC6 was the best release we've done on PowerPC so far -- so much so that when I managed to snatch some time to work on FC6 before its release I actually ended up doing Bluetooth stuff rather than anything PPC-specific. FC7 will be even better, and will have support for a set of new and interesting hardware. > If your question is just "why don't the bits end up on fp.org", the > reason is purely one of "we're not attacking that problem first". And > realistically, setting the expectation that we're not going to solve > that problem in the next six months is a far better thing to do IMHO. I agree. Although the proposed ArchPolicy is a good idea in principle, it's going to take time to put it into practice, and there are a _number_ of things that realistically speaking we just aren't going to solve in the next six months. So please, let's not hold the FC7/PowerPC release hostage to those solutions. -- dwmw2 From dwmw2 at infradead.org Fri Nov 17 10:10:51 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 17 Nov 2006 18:10:51 +0800 Subject: [fab] Architecture Policy. In-Reply-To: <455C8D06.5080807@redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> Message-ID: <1163758251.21366.246.camel@shinybook.infradead.org> On Thu, 2006-11-16 at 11:08 -0500, Christopher Blizzard wrote: > 1. That the arches with very little market share (ppc, s390, ia64) are > part of the build process and they die on a regular basis. Really? That ('on a regular basis') isn't my experience, whether you're talking about build machines dying (except the S390) or whether you're talking about the occasional compiler bugs or failure to build individual packages. Every architecture will suffer occasional build machine outages, compiler bugs or compile failures in packages -- but I'm certainly not aware that PowerPC in particular has more than its fair share. It sounds like you're just saying "Making a distribution is hard. Let's do less of it". > 2. Encouraging development for the community that cares about the > smaller arches. Let's face it, lots of interesting and smart people > spend time on the smaller arches. They are passionate and they care, > and their work almost always encourages the whole of the project. And > you never know when a big project might come along that uses one of > those arches, and you want to be ready when it does. It's OK. There seems to be a lot of pressure to use Ubuntu in the one we're thinking of already -- I'm sure they'll cope if they have to drop Fedora because we mess up the FC7/PPC release with a new process that isn't ready for production yet :) -- dwmw2 From dwmw2 at infradead.org Sat Nov 18 21:36:52 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 18 Nov 2006 21:36:52 +0000 Subject: [fab] Architecture Policy. In-Reply-To: <455F3C03.2070602@redhat.com> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> Message-ID: <1163885812.3365.24.camel@shinybook.infradead.org> On Sat, 2006-11-18 at 11:59 -0500, Christopher Blizzard wrote: > Please tell us how we can help enable you and the rest of the PPC > community into better partners. It was my hope that by enabling the PPC > folks to work with freedom to walk all over the tree as part of a > specific arch team that they would get more involved, not less. We _already_ do that -- and quite effectively too. We pick up with the hairier arch-specific issues where individual package maintainers don't have the skills required (like the Modula-3 port which was required for cvsup), and we poke maintainers to fix it themselves when they (or their package) are just being dim (like assuming char is signed). We provide testing and/or access to machines as required. I'm pleased with FC6 -- I think it's probably our best release on PowerPC so far. As I said, when I managed to snatch a few moments for testing FC6 in the run-up to the release (don't tell my boss), what I found myself working on wasn't even PowerPC-specific stuff; it was Bluetooth instead. > Do you not think that this is the case? Please tell me if you think > I'm wrong about this. I think you're wrong that it's going to be helpful for PPC. The best that we can hope for is that we can regain the current situation -- the healthy balance between tasks accomplished by package maintainers and by the de facto 'arch maintainers' that we have at the moment. I also think it's massively na?ve to think that the new 'secondary' build and release process could be put in place in time for a simultaneous release of FC7 -- we have to be realistic and accept that it's _very_ unlikely to happen in that timescale. We really shouldn't hold PowerPC hostage to that; we should get the new process working with a _new_ architecture, like IA64, SPARC or Alpha, before we make the already-supported PowerPC architecture use it. Once it's _working_, move PowerPC to it by all means. But we've spent a lot of time and effort on Fedora/PPC and it isn't right to hold it hostage to the implementation of a hazily-defined new process. I'm just asking that we change one thing at a time. Get the new process working, and _then_ we can move PowerPC to it. After we've done a proper release for IA64 or SPARC or Alpha. -- dwmw2 From tcallawa at redhat.com Mon Nov 20 16:48:01 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 20 Nov 2006 10:48:01 -0600 Subject: [fab] Architecture Policy. In-Reply-To: <1163885812.3365.24.camel@shinybook.infradead.org> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> Message-ID: <1164041281.3221.126.camel@localhost.localdomain> On Sat, 2006-11-18 at 21:36 +0000, David Woodhouse wrote: > I'm just asking that we change one thing at a time. Get the new > process > working, and _then_ we can move PowerPC to it. After we've done a > proper > release for IA64 or SPARC or Alpha. I'd agree with this. PPC should be a secondary arch for a variety of reasons, none of which having to do with its code quality. Lets give SPARC a chance to succeed in the FC-7 time frame, get the framework built up, and once that is done, we'll move PPC over. Less moving pieces in a reorg is always good. ~spot From jkeating at redhat.com Mon Nov 20 16:53:10 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Nov 2006 11:53:10 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <1163758251.21366.246.camel@shinybook.infradead.org> References: <1163564205.3396.141.camel@shinybook.infradead.org> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> Message-ID: <200611201153.10569.jkeating@redhat.com> On Friday 17 November 2006 05:10, David Woodhouse wrote: > It's OK. There seems to be a lot of pressure to use Ubuntu in the one > we're thinking of already Except that Ubuntu is considering doing the same thing we are with PPC. See the notes from their summit. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Mon Nov 20 17:16:37 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 20 Nov 2006 11:16:37 -0600 Subject: [fab] Secondary Arches In-Reply-To: <1163757727.21366.236.camel@shinybook.infradead.org> References: <1163556702.17611.38.camel@vader.jdub.homelinux.org> <1163650554.30164.30.camel@aglarond.local> <1163757727.21366.236.camel@shinybook.infradead.org> Message-ID: <200611201116.38074.dennis@ausil.us> On Friday 17 November 2006 04:02, David Woodhouse wrote: > On Wed, 2006-11-15 at 23:15 -0500, Jeremy Katz wrote: > > > Then look at PPC. How can you expect me to believe that taking an arch > > > that _already_ has storage and ISOs and just dropping that off of > > > fedoraproject.org because the buildsys can now send out shadow builds > > > is progress? > > > > I think that trying to lump PPC in here has perhaps made the issue a > > little bit more muddled. So ignore PPC for a minute -- does this not > > start to improve things for arches like sparc? It's not the whole > > answer, but it's a start. > > Yes, it _does_ look like a step in the right direction. In the long > term; when the dust has settled and it actually works. PPC probably should be the second step. > > For PPC, things are a little bit more complicated and it's really just a > > matter of how much demand the platform is seeing vs the effort required > > to sustain it. So does it make things less good for ppc? Definitely. > > Very much so. On the other hand, if we revisit the question in time for > FC8 _after_ we test the process by bringing Aurora into the fold, then > it doesn't have to be such a retrograde step for PPC. i think that is perfectly acceptable. > > But the impetus isn't the existence of secondary arches and shoving the > > round peg in the square hole. Instead, it's the fact that the number of > > ppc downloads is very small and the community of people actively testing > > and fixing things is quite small. > > Nevertheless, it was my impression that FC6 was the best release we've > done on PowerPC so far -- so much so that when I managed to snatch some > time to work on FC6 before its release I actually ended up doing > Bluetooth stuff rather than anything PPC-specific. i have FC-6 on a powerbook i use pretty much everyday. with a small patch to xorg-server i even had compiz running properly. Im very happy with it. my other ppc box is still running FC-4. > FC7 will be even better, and will have support for a set of new and > interesting hardware. > > > If your question is just "why don't the bits end up on fp.org", the > > reason is purely one of "we're not attacking that problem first". And > > realistically, setting the expectation that we're not going to solve > > that problem in the next six months is a far better thing to do IMHO. > > I agree. Although the proposed ArchPolicy is a good idea in principle, > it's going to take time to put it into practice, and there are a > _number_ of things that realistically speaking we just aren't going to > solve in the next six months. So please, let's not hold the FC7/PowerPC > release hostage to those solutions. PPC does not need to be. right now Extras has 3 open power boxes with 4 cpu's a piece. there is no reason for PPC not to be built along with x86_64 and i386 on the "internal" buildsys with the hardware we have. I have a T1000 and spot has a T2000 that can be used as sparc builders. between them its 64 threads. I'm quite happy to ship mine to Phoenix or have it sit where it is and tap into the buildsys. if it does get shipped to Phoenix we really will need to have a vlan for the admin interfaces and move the dracs, etc into it. Sun saw fit to allow only telnet as the network access mechanism to the ALOM and these boxes can only be powered on through the ALOM. I currently limit plage to 10 jobs at once due to the machines single drive. the T2000 has 2 drives and can have 4. if it had 4 drives i would be quite happy to enable 24+ builds on the box at a time. though something like eclipse takes over 8 hours to build as it is largely single threaded. As a kind of side note my home connection is about to be upgraded to 15mbit/1.5mbit while not great its three times my current upload speed. and will enable builds to be uploaded at something not entirely horrible. -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From dennis at ausil.us Mon Nov 20 17:18:34 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 20 Nov 2006 11:18:34 -0600 Subject: [fab] Architecture Policy. In-Reply-To: <1163758251.21366.246.camel@shinybook.infradead.org> References: <1163564205.3396.141.camel@shinybook.infradead.org> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> Message-ID: <200611201118.35200.dennis@ausil.us> On Friday 17 November 2006 04:10, David Woodhouse wrote: > It's OK. There seems to be a lot of pressure to use Ubuntu in the one > we're thinking of already -- I'm sure they'll cope if they have to drop > Fedora because we mess up the FC7/PPC release with a new process that > isn't ready for production yet :) Last I saw Ubuntu is going to drop PPC so we really should make sure we are their to pick up the pieces. -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From tibbs at math.uh.edu Mon Nov 20 17:29:57 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 20 Nov 2006 11:29:57 -0600 Subject: [fab] Architecture Policy. In-Reply-To: <1164041281.3221.126.camel@localhost.localdomain> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> Message-ID: >>>>> "TC" == Tom 'spot' Callaway writes: TC> I'd agree with this. PPC should be a secondary arch for a variety TC> of reasons, none of which having to do with its code quality. Oddly, I can't think of a really good reason why it shouldn't be a primary arch. Is it really that much overhead for us? And if it is made secondary, is there any path for it to make it back to primary status? What would the criteria be? - J< From mspevack at redhat.com Mon Nov 20 15:31:11 2006 From: mspevack at redhat.com (Max Spevack) Date: Mon, 20 Nov 2006 10:31:11 -0500 (EST) Subject: Board meeting today (with IRC) Message-ID: There will be a Fedora Board meeting today at 13:00 Eastern Time (18:00 UTC) Similar to the Fedora Summit last week, we'll have IRC in #fedora-board -- someone will provide a reasonably real-time log of what we're talking about on our phone call. Current agenda items: 0) Any random bits of news. 1) Board needs to vote on/bless Diana Fong as the leader of Fedora Artwork project. 2) Fill people in/answer questions about any of the stuff that happened at the Fedora Summit last week. 3) Update from the Board members who are on FESCO as well about how that meeting went last week, FESCO's general thoughts coming out of the Fedora Summit. 4) Board composition -- proposal on the table is that Elliot Lee will become Board member Emeritus and Greg DeKoenigsberg will fill his seat until the current Board's term ends post-Fedora 7. Board needs to vote on this. 5) Any other business. -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From tcallawa at redhat.com Mon Nov 20 17:34:15 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 20 Nov 2006 11:34:15 -0600 Subject: [fab] Architecture Policy. In-Reply-To: References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> Message-ID: <1164044055.3221.136.camel@localhost.localdomain> On Mon, 2006-11-20 at 11:29 -0600, Jason L Tibbitts III wrote: > >>>>> "TC" == Tom 'spot' Callaway writes: > > TC> I'd agree with this. PPC should be a secondary arch for a variety > TC> of reasons, none of which having to do with its code quality. > > Oddly, I can't think of a really good reason why it shouldn't be a > primary arch. Is it really that much overhead for us? And if it is > made secondary, is there any path for it to make it back to primary > status? What would the criteria be? I really see the only distinction as: Primary: Red Hat drives the arch forward, ensures that it works, or else, Fedora is in a bad bad place. Secondary: Community drives the arch forward, ensures that it works, but if it doesn't, the majority of the Fedora universe remains intact. So, if PPC/SPARC/IA64 rises again, the userbase grows to huge numbers, then we reconsider it as a primary arch, but otherwise, we let motivated community push it. Primary/Secondary not having any distinction as to quality of the platform or the code within it. This is not a "Second class" distinction. ~spot From jkeating at redhat.com Mon Nov 20 17:50:18 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Nov 2006 12:50:18 -0500 Subject: Some activity on Fedora Hosted Projects Message-ID: <200611201250.25763.jkeating@redhat.com> One of the things identified at the summit was that we wanted to provide some soft of hosting for projects. This wouldn't necessarily be Fedora specific projects, but being able to use your Fedora accounts to get something going quickly, with source control etc. would be highly valuable. Since I needed some project space for pungi, I started looking at what was around, and gave Trac (http://trac.edgewall.org/) a serious look. It's picked up the ability to use an hg repository, which is pretty important to me, and there is the beginnings of git support, perhaps enough to make use of it now. Add to that the ability to tie into our existing accounts system for authenticated actions, and the ability for a project admin to make changes to the project all through the web makes trac a pretty compelling choice for software to manage our hosted projects. There seems to be a fairly decent community around Trac and solid community contribution to the project itself so there seems to be some sustainability there. For a proof of concept, I setup a xen guest with FC6, tossed trac on there in a multiproject configuration and added pungi as one of the projects. I'm going to approach some of the other psuedo hosted projects we've got going on to see if they would be interested in playing in the proof of concept land. I also created a wiki page to cover this: http://fedoraproject.org/wiki/Infrastructure/ProjectHosting I'd like some input from the board if this is the right direction envisioned for project hosting, and if any more effort (now or later) should be spent in this direction. For me, I got project space for pungi. I still have a few hoops to jump through before it's really useful (moving the actual hg repo of pungi to a new location, changing documentation, etc..) but its a good start. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Mon Nov 20 17:52:49 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 20 Nov 2006 11:52:49 -0600 Subject: [fab] Architecture Policy. In-Reply-To: <1164044055.3221.136.camel@localhost.localdomain> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> Message-ID: >>>>> "TC" == Tom 'spot' Callaway writes: TC> Primary/Secondary not having any distinction as to quality of the TC> platform or the code within it. This is not a "Second class" TC> distinction. Perhaps, for purely political reasons, consider replacing Primary/Secondary with a designation like "Community driven arch", or any other set of words that embodies the distinction without implying a better/worse distinction. - J< From sundaram at fedoraproject.org Mon Nov 20 17:55:14 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Nov 2006 23:25:14 +0530 Subject: [fab] Architecture Policy. In-Reply-To: References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> Message-ID: <4561EC02.6090108@fedoraproject.org> Jason L Tibbitts III wrote: >>>>>> "TC" == Tom 'spot' Callaway writes: > > TC> Primary/Secondary not having any distinction as to quality of the > TC> platform or the code within it. This is not a "Second class" > TC> distinction. > > Perhaps, for purely political reasons, consider replacing > Primary/Secondary with a designation like "Community driven arch", or > any other set of words that embodies the distinction without implying > a better/worse distinction. > If you call the secondary architecture, community driven wouldnt that imply that the primary architectures arent? Rahul From tibbs at math.uh.edu Mon Nov 20 18:39:42 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 20 Nov 2006 12:39:42 -0600 Subject: [fab] Architecture Policy. In-Reply-To: <4561EC02.6090108@fedoraproject.org> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> <4561EC02.6090108@fedoraproject.org> Message-ID: >>>>> "RS" == Rahul Sundaram writes: RS> If you call the secondary architecture, community driven wouldnt RS> that imply that the primary architectures arent? Hey, it was just an example. But are you saying that isn't the case? Here I quote spot: > Primary: Red Hat drives the arch forward, ensures that it works, or > else, Fedora is in a bad bad place. > Secondary: Community drives the arch forward, ensures that it works, but > if it doesn't, the majority of the Fedora universe remains intact. So just adding "Community driven" to the architectures that are built on community-run hardware outside of Red Hat's data centers doesn't seem at all incorrect. I was only keying off of the text of the message I was responding to. But of course I explicitly indicated that I wasn't arguing that the words "community driven" are the only two words that would work there; I was saying that it would be best some wording was chosen that didn't imply that the secondary architectures are somehow worse. It would have been nice if you could have discussed the intent of my message instead of picking out a small piece to comment on. - J< From sundaram at fedoraproject.org Mon Nov 20 19:12:23 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 21 Nov 2006 00:42:23 +0530 Subject: [fab] Architecture Policy. In-Reply-To: References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> <4561EC02.6090108@fedoraproject.org> Message-ID: <4561FE17.7040609@fedoraproject.org> Jason L Tibbitts III wrote: >>>>>> "RS" == Rahul Sundaram writes: > > RS> If you call the secondary architecture, community driven wouldnt > RS> that imply that the primary architectures arent? > > Hey, it was just an example. But are you saying that isn't the case? That is indeed the case but we are talking about political messaging here. Dont let the current reality distract you from the road ahead ;-) > Here I quote spot: > >> Primary: Red Hat drives the arch forward, ensures that it works, or >> else, Fedora is in a bad bad place. >> Secondary: Community drives the arch forward, ensures that it works, but >> if it doesn't, the majority of the Fedora universe remains intact. > > So just adding "Community driven" to the architectures that are built > on community-run hardware outside of Red Hat's data centers doesn't > seem at all incorrect. I was only keying off of the text of the > message I was responding to. > > But of course I explicitly indicated that I wasn't arguing that the > words "community driven" are the only two words that would work there; > I was saying that it would be best some wording was chosen that didn't > imply that the secondary architectures are somehow worse. It would > have been nice if you could have discussed the intent of my message > instead of picking out a small piece to comment on. > Branding by definition is all about nit picking. I am just pointing out that the particular name would exchange one set of bad political precedents with another. Yes, today the primary architectures are indeed due to Red Hat folks giving a higher priority to them but picking up "community driven" as the alternative name for secondary architectures implies that the current status is acceptable. We dont say "Red Hat is releasing Fedora Core x" for the same reason even though Red Hat currently does all the work in core now. How about tier 1 and tier 2 architectures? Rahul From notting at redhat.com Mon Nov 20 19:15:31 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 20 Nov 2006 14:15:31 -0500 Subject: [fab] Secondary Arches In-Reply-To: <200611201116.38074.dennis@ausil.us> References: <1163556702.17611.38.camel@vader.jdub.homelinux.org> <1163650554.30164.30.camel@aglarond.local> <1163757727.21366.236.camel@shinybook.infradead.org> <200611201116.38074.dennis@ausil.us> Message-ID: <20061120191531.GA18875@nostromo.devel.redhat.com> Dennis Gilmore (dennis at ausil.us) said: > PPC does not need to be. right now Extras has 3 open power boxes with 4 cpu's > a piece. there is no reason for PPC not to be built along with x86_64 and > i386 on the "internal" buildsys with the hardware we have. I have a T1000 > and spot has a T2000 that can be used as sparc builders. between them its 64 > threads. I'm quite happy to ship mine to Phoenix or have it sit where it is > and tap into the buildsys. I think using 'we can get hardware sent somewhere' as a delinator of the primary arch is a mistake. It should be what there is market (for lack of a better word) demand for, especially because of... > if it does get shipped to Phoenix we really will > need to have a vlan for the admin interfaces and move the dracs, etc into it. > Sun saw fit to allow only telnet as the network access mechanism to the ALOM > and these boxes can only be powered on through the ALOM. ... things like this. I'm not particularly enamored of making extra maintenance burden for the admin team for arches that would encompass less than 1% of Fedora. Bill From dennis at ausil.us Mon Nov 20 19:46:36 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 20 Nov 2006 13:46:36 -0600 Subject: [fab] Secondary Arches In-Reply-To: <20061120191531.GA18875@nostromo.devel.redhat.com> References: <1163556702.17611.38.camel@vader.jdub.homelinux.org> <200611201116.38074.dennis@ausil.us> <20061120191531.GA18875@nostromo.devel.redhat.com> Message-ID: <200611201346.36422.dennis@ausil.us> On Monday 20 November 2006 13:15, Bill Nottingham wrote: > Dennis Gilmore (dennis at ausil.us) said: > > PPC does not need to be. right now Extras has 3 open power boxes with 4 > > cpu's a piece. there is no reason for PPC not to be built along with > > x86_64 and i386 on the "internal" buildsys with the hardware we have. I > > have a T1000 and spot has a T2000 that can be used as sparc builders. > > between them its 64 threads. I'm quite happy to ship mine to Phoenix or > > have it sit where it is and tap into the buildsys. > > I think using 'we can get hardware sent somewhere' as a delinator of the > primary arch is a mistake. It should be what there is market (for lack of > a better word) demand for, especially because of... I never said that sparc should be primary arch just that if it is needed hardware can be made available where ever it is needed and PPC can still be built when core is migrated to the new buildsys. so it need not become a secondary arch until we have everything in place for it to be 100% success. Unless niagara based systems start flooding the market place i don't see sparc as having a large user base. but i enjoy working on it. > > if it does get shipped to Phoenix we really will > > need to have a vlan for the admin interfaces and move the dracs, etc into > > it. Sun saw fit to allow only telnet as the network access mechanism to > > the ALOM and these boxes can only be powered on through the ALOM. > > ... things like this. I'm not particularly enamored of making extra > maintenance burden for the admin team for arches that would encompass > less than 1% of Fedora. > > Bill As a member of the Admin team I agree. It could be in the same network as other things but would be better in its own. at some point we will need to separate some things out into an management network anyway. it would just be hastened. -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From notting at redhat.com Mon Nov 20 19:54:14 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 20 Nov 2006 14:54:14 -0500 Subject: [fab] Secondary Arches In-Reply-To: <200611201346.36422.dennis@ausil.us> References: <1163556702.17611.38.camel@vader.jdub.homelinux.org> <200611201116.38074.dennis@ausil.us> <20061120191531.GA18875@nostromo.devel.redhat.com> <200611201346.36422.dennis@ausil.us> Message-ID: <20061120195414.GD18875@nostromo.devel.redhat.com> Dennis Gilmore (dennis at ausil.us) said: > I never said that sparc should be primary arch just that if it is needed > hardware can be made available where ever it is needed and PPC can still be > built when core is migrated to the new buildsys. so it need not become a > secondary arch until we have everything in place for it to be 100% success. > Unless niagara based systems start flooding the market place i don't see > sparc as having a large user base. but i enjoy working on it. What I'm trying to say is that one of the things we're trying to solve with the new arch policy is the hardware issue - we want people to be able to interface with the Fedora build system with hardware that isn't in our server locations. Even if there is a groundswell for Fedora/390, no one's going to send us a mainframe (and, honestly, even if they were, I'm pretty sure we wouldn't want to deal with it ;) ) - therefore, it's best to design the policy so that it can work for community-supported arches who house the hardware themselves. Bill From dennis at ausil.us Mon Nov 20 20:19:29 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 20 Nov 2006 14:19:29 -0600 Subject: [fab] Secondary Arches In-Reply-To: <20061120195414.GD18875@nostromo.devel.redhat.com> References: <1163556702.17611.38.camel@vader.jdub.homelinux.org> <200611201346.36422.dennis@ausil.us> <20061120195414.GD18875@nostromo.devel.redhat.com> Message-ID: <200611201419.29722.dennis@ausil.us> On Monday 20 November 2006 13:54, Bill Nottingham wrote: > Dennis Gilmore (dennis at ausil.us) said: > > I never said that sparc should be primary arch just that if it is needed > > hardware can be made available where ever it is needed and PPC can still > > be built when core is migrated to the new buildsys. so it need not > > become a secondary arch until we have everything in place for it to be > > 100% success. Unless niagara based systems start flooding the market > > place i don't see sparc as having a large user base. but i enjoy > > working on it. > > What I'm trying to say is that one of the things we're trying to solve with > the new arch policy is the hardware issue - we want people to be able to > interface with the Fedora build system with hardware that isn't in our > server locations. Even if there is a groundswell for Fedora/390, no one's > going to send us a mainframe (and, honestly, even if they were, I'm pretty > sure we wouldn't want to deal with it ;) ) - therefore, it's best to design > the policy so that it can work for community-supported arches who house the > hardware themselves. > > Bill :D that works also. i imagine a S390 is extremely expensive to run. -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From dwmw2 at infradead.org Tue Nov 21 01:49:16 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 21 Nov 2006 01:49:16 +0000 Subject: [fab] Architecture Policy. In-Reply-To: <1164044055.3221.136.camel@localhost.localdomain> References: <1163564205.3396.141.camel@shinybook.infradead.org> <20061116001939.GC3983@redhat.com> <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> Message-ID: <1164073756.6925.164.camel@pmac.infradead.org> On Mon, 2006-11-20 at 11:34 -0600, Tom 'spot' Callaway wrote: > Primary: Red Hat drives the arch forward, ensures that it works, or > else, Fedora is in a bad bad place. > Secondary: Community drives the arch forward, ensures that it works, > but if it doesn't, the majority of the Fedora universe remains intact. Given that we have RHEL on PPC, Red Hat is going to support it in the end anyway. With my Red Hat on, I observe that we do get a lot of benefit from the existence of Fedora/PPC -- just as RHEL in general benefits from the existence of Fedora. I spend Red Hat time on looking after Fedora/PowerPC, and will continue to do so in addition to my own "spare" time. Using _your_ classification, PowerPC sounds more like it fits in the 'primary' camp -- there are Red Hat folks actively maintaining it. I don't really care about the classification though -- as long as the FC7/PowerPC and future releases still happen in sync with the other architectures, ends up on the same mirrors, etc. And as long as we don't start to let package-monkeys ship crap code with a 'works for me on little-endian machine with signed char' defence. It does seem like keeping PowerPC in the 'primary' set of architectures for now is the only way to achieve that, and I'm pleased that you agree with that observation. Once we've had a successful FC7/SPARC release we can revisit the question and I'll care a whole lot less about the result. -- dwmw2 From jkeating at redhat.com Tue Nov 21 16:05:28 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 21 Nov 2006 11:05:28 -0500 Subject: [Fedora Project Wiki] Update of "Infrastructure/ProjectHosting" by BillNottingham In-Reply-To: <20061121155300.26994.33913@fpserv.linux.duke.edu> References: <20061121155300.26994.33913@fpserv.linux.duke.edu> Message-ID: <200611211105.28916.jkeating@redhat.com> On Tuesday 21 November 2006 10:53, you wrote: > + ?* Issue tracking (is bz OK?) So the reason I don't think bz is OK is that if we continue to use our BZ for new projects the Product list will get quite large quite fast. Users trying to use bugzilla.redhat.com to file bugs against say Fedora or RHEL will be hit with a very large product list to choose from, and even more confusing if they're filing a bug against a package that exists in one of these products, but the package's upstream bugs are hosted on our bugzilla, the bug may get filed upstream but we'd never know "downstream" about it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Tue Nov 21 16:18:37 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Nov 2006 11:18:37 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <1164073756.6925.164.camel@pmac.infradead.org> References: <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> <1164073756.6925.164.camel@pmac.infradead.org> Message-ID: <20061121161837.GB31789@nostromo.devel.redhat.com> David Woodhouse (dwmw2 at infradead.org) said: > On Mon, 2006-11-20 at 11:34 -0600, Tom 'spot' Callaway wrote: > > Primary: Red Hat drives the arch forward, ensures that it works, or > > else, Fedora is in a bad bad place. > > Secondary: Community drives the arch forward, ensures that it works, > > but if it doesn't, the majority of the Fedora universe remains intact. > > Given that we have RHEL on PPC, Red Hat is going to support it in the > end anyway. With my Red Hat on, I observe that we do get a lot of > benefit from the existence of Fedora/PPC -- just as RHEL in general > benefits from the existence of Fedora. I highly doubt that. The platforms we support for RHEL have continually had issues throughout RHEL 5 that show that they *aren't* being tested with Fedora. > Using _your_ classification, PowerPC sounds more like it fits in the > 'primary' camp -- there are Red Hat folks actively maintaining it. It's not about who's looking after it. By that standard, Sparc is more first-class than PPC, as there are more RH people working on Sparc stuff. It's about what there is market demand and user demand for. By that standard, PPC lags horribly, and it's only getting worse. > architectures, ends up on the same mirrors, etc. And as long as we don't > start to let package-monkeys ship crap code with a 'works for me on > little-endian machine with signed char' defence. Have you *READ* the proposal? We're increasing the ability of people to fix arch-specific issues. If you want to continue to intentionally misread and misrepresent to suit your own needs, fine. I'll send you a hammer and some spikes, I'm sure you can find some nice large pieces of wood locally for yourself. Bill From notting at redhat.com Tue Nov 21 16:24:46 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Nov 2006 11:24:46 -0500 Subject: [Fedora Project Wiki] Update of "Infrastructure/ProjectHosting" by BillNottingham In-Reply-To: <200611211105.28916.jkeating@redhat.com> References: <20061121155300.26994.33913@fpserv.linux.duke.edu> <200611211105.28916.jkeating@redhat.com> Message-ID: <20061121162446.GC31789@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > On Tuesday 21 November 2006 10:53, you wrote: > > + ?* Issue tracking (is bz OK?) > > So the reason I don't think bz is OK is that if we continue to use our BZ for > new projects the Product list will get quite large quite fast. Users trying > to use bugzilla.redhat.com to file bugs against say Fedora or RHEL will be > hit with a very large product list to choose from, and even more confusing if > they're filing a bug against a package that exists in one of these products, > but the package's upstream bugs are hosted on our bugzilla, the bug may get > filed upstream but we'd never know "downstream" about it. Why not 'Fedora Hosted Projects' -> component, much like gnome.org? Alternatively, a single upstream BZ for all hosted projects. Bill From jkeating at redhat.com Tue Nov 21 16:30:52 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 21 Nov 2006 11:30:52 -0500 Subject: [Fedora Project Wiki] Update of "Infrastructure/ProjectHosting" by BillNottingham In-Reply-To: <20061121162446.GC31789@nostromo.devel.redhat.com> References: <20061121155300.26994.33913@fpserv.linux.duke.edu> <200611211105.28916.jkeating@redhat.com> <20061121162446.GC31789@nostromo.devel.redhat.com> Message-ID: <200611211130.52980.jkeating@redhat.com> On Tuesday 21 November 2006 11:24, Bill Nottingham wrote: > Why not 'Fedora Hosted Projects' -> component, much like gnome.org? Managing components for each project becomes a wash, as would versions for each project. For pungi, I'd like to separate out bugs for the gather module, the pungi module, or the /usr/bin/pungi script. I couldn't do that with the above method. Also I wouldn't be able to classify bugs between the devel/ branch or a released branch. > Alternatively, a single upstream BZ for all hosted projects. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Tue Nov 21 16:31:25 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 21 Nov 2006 16:31:25 +0000 Subject: [fab] Architecture Policy. In-Reply-To: <20061121161837.GB31789@nostromo.devel.redhat.com> References: <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> <1164073756.6925.164.camel@pmac.infradead.org> <20061121161837.GB31789@nostromo.devel.redhat.com> Message-ID: <1164126685.19448.44.camel@pmac.infradead.org> On Tue, 2006-11-21 at 11:18 -0500, Bill Nottingham wrote: > Have you *READ* the proposal? Of course I've read the proposal. Have _you_ actually tried dealing with Extras package-monkeys recently; trying to get them to fix a problem in their packages which is even slightly outside their own use case? -- dwmw2 From skvidal at linux.duke.edu Tue Nov 21 16:35:09 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 21 Nov 2006 11:35:09 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <1164126685.19448.44.camel@pmac.infradead.org> References: <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> <1164073756.6925.164.camel@pmac.infradead.org> <20061121161837.GB31789@nostromo.devel.redhat.com> <1164126685.19448.44.camel@pmac.infradead.org> Message-ID: <1164126909.2261.4.camel@cutter> On Tue, 2006-11-21 at 16:31 +0000, David Woodhouse wrote: > On Tue, 2006-11-21 at 11:18 -0500, Bill Nottingham wrote: > > Have you *READ* the proposal? > > Of course I've read the proposal. Have _you_ actually tried dealing with > Extras package-monkeys recently; trying to get them to fix a problem in > their packages which is even slightly outside their own use case? I have a suggestion, David. Stop referring to our active and appreciated volunteers as package monkeys. If you cannot refer to them respectfully in public then do not do it at all. -sv From dwmw2 at infradead.org Tue Nov 21 16:37:03 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 21 Nov 2006 16:37:03 +0000 Subject: [fab] Architecture Policy. In-Reply-To: <1164126909.2261.4.camel@cutter> References: <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> <1164073756.6925.164.camel@pmac.infradead.org> <20061121161837.GB31789@nostromo.devel.redhat.com> <1164126685.19448.44.camel@pmac.infradead.org> <1164126909.2261.4.camel@cutter> Message-ID: <1164127023.19448.47.camel@pmac.infradead.org> On Tue, 2006-11-21 at 11:35 -0500, seth vidal wrote: > I have a suggestion, David. Stop referring to our active and appreciated > volunteers as package monkeys. If you cannot refer to them respectfully > in public then do not do it at all. It's not a term of disrespect. It's a term which I use to refer to myself as well in certain circumstances. A package maintainer is able to work on the package, fix bugs, co-operate and contribute to upstream maintenance. A package-monkey can just build it and can't really do much else. I've recently tried to get rid of packages for which I can only be a package-monkey, and declined to accept new packages on similar grounds. I see no reason to get worked up about the terminology. -- dwmw2 From gdk at redhat.com Tue Nov 21 16:38:37 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Tue, 21 Nov 2006 11:38:37 -0500 (EST) Subject: [fab] Architecture Policy. In-Reply-To: <1164126909.2261.4.camel@cutter> References: <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> <1164073756.6925.164.camel@pmac.infradead.org> <20061121161837.GB31789@nostromo.devel.redhat.com> <1164126685.19448.44.camel@pmac.infradead.org> <1164126909.2261.4.camel@cutter> Message-ID: On Tue, 21 Nov 2006, seth vidal wrote: >> Of course I've read the proposal. Have _you_ actually tried dealing with >> Extras package-monkeys recently; trying to get them to fix a problem in >> their packages which is even slightly outside their own use case? > > I have a suggestion, David. Stop referring to our active and appreciated > volunteers as package monkeys. If you cannot refer to them respectfully > in public then do not do it at all. +1 to Seth's point. But beyond that... David, what would you suggest? In the abstract case: 1. A packager will almost always be packaging primarily for x86 or x86_64; 2. A packager will almost never have access to the hardware to test on other arches. Given those two constraints, the duties of the secondary arch teams are to: 1. Make changes directly to any offending packages; 2. Notify the maintainer that the changes are being made; 3. Work with the maintainer to ensure that arch-specific changes do not break the packages. What, exactly, is unreasonable about this proposal? --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From fedora at leemhuis.info Tue Nov 21 16:42:18 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 21 Nov 2006 17:42:18 +0100 Subject: [fab] Architecture Policy. In-Reply-To: <20061121161837.GB31789@nostromo.devel.redhat.com> References: <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> <1164073756.6925.164.camel@pmac.infradead.org> <20061121161837.GB31789@nostromo.devel.redhat.com> Message-ID: <45632C6A.8030007@leemhuis.info> Bill Nottingham schrieb: > David Woodhouse (dwmw2 at infradead.org) said: >> On Mon, 2006-11-20 at 11:34 -0600, Tom 'spot' Callaway wrote: >>> Primary: Red Hat drives the arch forward, ensures that it works, or >>> else, Fedora is in a bad bad place. >>> Secondary: Community drives the arch forward, ensures that it works, >>> but if it doesn't, the majority of the Fedora universe remains intact. >> Given that we have RHEL on PPC, Red Hat is going to support it in the >> end anyway. With my Red Hat on, I observe that we do get a lot of >> benefit from the existence of Fedora/PPC -- just as RHEL in general >> benefits from the existence of Fedora. > I highly doubt that. The platforms we support for RHEL have continually > had issues throughout RHEL 5 that show that they *aren't* being tested > with Fedora. Just to trough my 2 cent into the ring: With all the noise around * the Playstation 3 and FC5/YellowDOG for the PS3 * Ubuntu considering dropping PPC support * the quite new Cell arch that is only supported by FC currently I'd say: Let PPC be a primary arch for F7 as that might give us some nice bonus points in the community and some good press in the next few months. Test and develop the secondary arch infrastructure with IA64 and Sparc for F7. Discuss making PPC a secondary arch after F7 again if it works fine for IA64/Sparc. CU thl From notting at redhat.com Tue Nov 21 16:42:12 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Nov 2006 11:42:12 -0500 Subject: [Fedora Project Wiki] Update of "Infrastructure/ProjectHosting" by BillNottingham In-Reply-To: <200611211130.52980.jkeating@redhat.com> References: <20061121155300.26994.33913@fpserv.linux.duke.edu> <200611211105.28916.jkeating@redhat.com> <20061121162446.GC31789@nostromo.devel.redhat.com> <200611211130.52980.jkeating@redhat.com> Message-ID: <20061121164212.GB30490@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > On Tuesday 21 November 2006 11:24, Bill Nottingham wrote: > > Why not 'Fedora Hosted Projects' -> component, much like gnome.org? > > Managing components for each project becomes a wash, as would versions for > each project. For pungi, I'd like to separate out bugs for the gather > module, the pungi module, or the /usr/bin/pungi script. I couldn't do that > with the above method. Also I wouldn't be able to classify bugs between the > devel/ branch or a released branch. If you do a single BZ instance for all Fedora Hosted Projects, you can do this. Of course, then you have confusion between that and a Fedora bugzilla. Bill From jkeating at redhat.com Tue Nov 21 16:54:05 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 21 Nov 2006 11:54:05 -0500 Subject: [Fedora Project Wiki] Update of "Infrastructure/ProjectHosting" by BillNottingham In-Reply-To: <20061121164212.GB30490@nostromo.devel.redhat.com> References: <20061121155300.26994.33913@fpserv.linux.duke.edu> <200611211130.52980.jkeating@redhat.com> <20061121164212.GB30490@nostromo.devel.redhat.com> Message-ID: <200611211154.05193.jkeating@redhat.com> On Tuesday 21 November 2006 11:42, Bill Nottingham wrote: > If you do a single BZ instance for all Fedora Hosted Projects, you can do > this. Of course, then you have confusion between that and a Fedora > bugzilla. Right, so then a single BZ that just has a long list of each project as a product, and then each product can have its versions/components/etc... However if we were to go this route, why wouldn't the ticketing system that's tied into Trac suffice? Then we don't have to give every project owner bugzilla admin rights to make adjustments, the milestone stuff in trac can be more useful as it ties into tickets, post commit hooks can be ported from svn to hg/git so that you can auto close / update tickets on a source commit, etc... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Tue Nov 21 16:57:46 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 21 Nov 2006 16:57:46 +0000 Subject: [fab] Architecture Policy. In-Reply-To: References: <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> <1164073756.6925.164.camel@pmac.infradead.org> <20061121161837.GB31789@nostromo.devel.redhat.com> <1164126685.19448.44.camel@pmac.infradead.org> <1164126909.2261.4.camel@cutter> Message-ID: <1164128266.19448.62.camel@pmac.infradead.org> On Tue, 2006-11-21 at 11:38 -0500, Greg Dekoenigsberg wrote: > +1 to Seth's point. But beyond that... Would you care to suggest alternative nomenclature? I personally happen to think that 'package-monkey' is a perfect term -- it definitely describes my maintenance of the one gtk+dbus package I own (and which I'm trying to get rid of) to a tee. > David, what would you suggest? In the abstract case: > > 1. A packager will almost always be packaging primarily for x86 or > x86_64; > > 2. A packager will almost never have access to the hardware to test on > other arches. Packagers always have at least remote access to PowerPC machines if they need it. > Given those two constraints, the duties of the secondary arch teams > are to: You omitted the duties of the package owner, which include not committing gratuitously non-portable code. > 1. Make changes directly to any offending packages; > > 2. Notify the maintainer that the changes are being made; > > 3. Work with the maintainer to ensure that arch-specific changes do > not break the packages. > > What, exactly, is unreasonable about this proposal? I didn't call it 'unreasonable'. I said that I like it in general, with the proviso that we should make sure we don't start to allow packagers to pay less attention to portability issues than they do at the moment. We currently have a relatively good balance in package maintenance. In cases where the code is just plain stupid and unportable, it falls to the owner of the package to fix it; in the first instance, we tend to just offer guidance and access to PPC machines for testing. Where that fails, because the issue is actually arch-specific, the PPC folks will get their own hands dirty with the fix. Currently, it works well. What I said is that I don't want to see a regression in that situation -- I don't want to see packagers saying "I don't care -- it works for me on little-endian machines where char is signed". The appropriate response was "yes, that's a valid concern and we'll make sure it doesn't happen". Not the dismissive attitude which Bill showed. -- dwmw2 From mmcgrath at fedoraproject.org Tue Nov 21 17:06:26 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 21 Nov 2006 11:06:26 -0600 Subject: [fab] Architecture Policy. In-Reply-To: <1164128266.19448.62.camel@pmac.infradead.org> References: <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> <1164073756.6925.164.camel@pmac.infradead.org> <20061121161837.GB31789@nostromo.devel.redhat.com> <1164126685.19448.44.camel@pmac.infradead.org> <1164126909.2261.4.camel@cutter> <1164128266.19448.62.camel@pmac.infradead.org> Message-ID: <3237e4410611210906n16233ec6g8f4a908942630c75@mail.gmail.com> On 11/21/06, David Woodhouse wrote: > On Tue, 2006-11-21 at 11:38 -0500, Greg Dekoenigsberg wrote: > > +1 to Seth's point. But beyond that... > > Would you care to suggest alternative nomenclature? I personally happen > to think that 'package-monkey' is a perfect term -- it definitely > describes my maintenance of the one gtk+dbus package I own (and which > I'm trying to get rid of) to a tee. > > > David, what would you suggest? In the abstract case: > > > > 1. A packager will almost always be packaging primarily for x86 or > > x86_64; > > > > 2. A packager will almost never have access to the hardware to test on > > other arches. > > Packagers always have at least remote access to PowerPC machines if they > need it. > To build yes, but building is only half the battle. -Mike From dwmw2 at infradead.org Tue Nov 21 17:13:55 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 21 Nov 2006 17:13:55 +0000 Subject: [fab] Architecture Policy. In-Reply-To: <3237e4410611210906n16233ec6g8f4a908942630c75@mail.gmail.com> References: <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> <1164073756.6925.164.camel@pmac.infradead.org> <20061121161837.GB31789@nostromo.devel.redhat.com> <1164126685.19448.44.camel@pmac.infradead.org> <1164126909.2261.4.camel@cutter> <1164128266.19448.62.camel@pmac.infradead.org> <3237e4410611210906n16233ec6g8f4a908942630c75@mail.gmail.com> Message-ID: <1164129235.19448.64.camel@pmac.infradead.org> On Tue, 2006-11-21 at 11:06 -0600, Mike McGrath wrote: > > Packagers always have at least remote access to PowerPC machines if > > they need it. > > To build yes, but building is only half the battle. No, not just to build. To build and run and debug. -- dwmw2 From notting at redhat.com Tue Nov 21 17:14:52 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Nov 2006 12:14:52 -0500 Subject: [fab] Architecture Policy. In-Reply-To: <1164128266.19448.62.camel@pmac.infradead.org> References: <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> <1164073756.6925.164.camel@pmac.infradead.org> <20061121161837.GB31789@nostromo.devel.redhat.com> <1164126685.19448.44.camel@pmac.infradead.org> <1164126909.2261.4.camel@cutter> <1164128266.19448.62.camel@pmac.infradead.org> Message-ID: <20061121171452.GB626@nostromo.devel.redhat.com> David Woodhouse (dwmw2 at infradead.org) said: > > David, what would you suggest? In the abstract case: > > > > 1. A packager will almost always be packaging primarily for x86 or > > x86_64; > > > > 2. A packager will almost never have access to the hardware to test on > > other arches. > > Packagers always have at least remote access to PowerPC machines if they > need it. This does not scale to all arches (I'm beginning to think 'ports' is the right term here) that there may be for Fedora. > > Given those two constraints, the duties of the secondary arch teams > > are to: > > You omitted the duties of the package owner, which include not > committing gratuitously non-portable code. Of course. But the arch team has wide-ranging powers to fix such cases if they slip in, and the steering committees/board have the abillity to take action against maintainers if it becomes a repeated problem. > Currently, it works well. What I said is that I don't want to see a > regression in that situation -- I don't want to see packagers saying "I > don't care -- it works for me on little-endian machines where char is > signed". > > The appropriate response was "yes, that's a valid concern and we'll make > sure it doesn't happen". Not the dismissive attitude which Bill showed. No, my statement is that that's *always* been the case, and you're inventing non-issues. If there are cases of this happening now, the Extras steering committee should be made aware of it. Bill From notting at redhat.com Tue Nov 21 17:15:43 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Nov 2006 12:15:43 -0500 Subject: [Fedora Project Wiki] Update of "Infrastructure/ProjectHosting" by BillNottingham In-Reply-To: <200611211154.05193.jkeating@redhat.com> References: <20061121155300.26994.33913@fpserv.linux.duke.edu> <200611211130.52980.jkeating@redhat.com> <20061121164212.GB30490@nostromo.devel.redhat.com> <200611211154.05193.jkeating@redhat.com> Message-ID: <20061121171543.GC626@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > However if we were to go this route, why wouldn't the ticketing system that's > tied into Trac suffice? Then we don't have to give every project owner > bugzilla admin rights to make adjustments, the milestone stuff in trac can be > more useful as it ties into tickets, post commit hooks can be ported from svn > to hg/git so that you can auto close / update tickets on a source commit, > etc... It's Yet Another Tracking System for people to learn and use. You're going to have, for most any project, people filing bugs in BZ anyway against the component as it's shipped in a release. Bill From tibbs at math.uh.edu Tue Nov 21 17:19:21 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 21 Nov 2006 11:19:21 -0600 Subject: [fab] Architecture Policy. In-Reply-To: <1164128266.19448.62.camel@pmac.infradead.org> References: <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> <1164073756.6925.164.camel@pmac.infradead.org> <20061121161837.GB31789@nostromo.devel.redhat.com> <1164126685.19448.44.camel@pmac.infradead.org> <1164126909.2261.4.camel@cutter> <1164128266.19448.62.camel@pmac.infradead.org> Message-ID: >>>>> "DW" == David Woodhouse writes: DW> Would you care to suggest alternative nomenclature? Packagers, as opposed to maintainers if you need to make a distinction. DW> I personally happen to think that 'package-monkey' is a perfect DW> term It is generally considered pejorative; see "code monkey", which is used to describe people who know little about CS that produce generic code to spec: code monkey n 1. A person only capable of grinding out code, but unable to perform the higher-primate tasks of software architecture, analysis, and design. Mildly insulting. Often applied to the most junior people on a programming team. - J< From dwmw2 at infradead.org Tue Nov 21 17:31:05 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 21 Nov 2006 17:31:05 +0000 Subject: [fab] Architecture Policy. In-Reply-To: References: <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> <1164073756.6925.164.camel@pmac.infradead.org> <20061121161837.GB31789@nostromo.devel.redhat.com> <1164126685.19448.44.camel@pmac.infradead.org> <1164126909.2261.4.camel@cutter> <1164128266.19448.62.camel@pmac.infradead.org> Message-ID: <1164130265.19448.75.camel@pmac.infradead.org> On Tue, 2006-11-21 at 11:19 -0600, Jason L Tibbitts III wrote: > DW> I personally happen to think that 'package-monkey' is a perfect > DW> term > > ... see "code monkey", which is used to describe people who know > little about CS that produce generic code to spec: As I said, it seems to be a perfect fit. I have respect for those who give up their time to build packages for Fedora, even if they lack the skills to fully maintain those packages. I have less respect those who claim to be insulted by something as innocuous as the term 'package-monkey'. I think this particular line of discussion is not very fruitful -- if you have a sensible suggestion for an alternative term which fits the bill as well as 'package-monkey' then please feel free to offer it. Otherwise, let's just assume that these people are adults and can deal with it. -- dwmw2 From smooge at gmail.com Tue Nov 21 17:50:38 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 21 Nov 2006 10:50:38 -0700 Subject: [fab] Architecture Policy. In-Reply-To: <1164127023.19448.47.camel@pmac.infradead.org> References: <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> <1164073756.6925.164.camel@pmac.infradead.org> <20061121161837.GB31789@nostromo.devel.redhat.com> <1164126685.19448.44.camel@pmac.infradead.org> <1164126909.2261.4.camel@cutter> <1164127023.19448.47.camel@pmac.infradead.org> Message-ID: <80d7e4090611210950g7fd8ff51sfa19812db7535700@mail.gmail.com> On 11/21/06, David Woodhouse wrote: > On Tue, 2006-11-21 at 11:35 -0500, seth vidal wrote: > > I have a suggestion, David. Stop referring to our active and appreciated > > volunteers as package monkeys. If you cannot refer to them respectfully > > in public then do not do it at all. > > It's not a term of disrespect. It's a term which I use to refer to > myself as well in certain circumstances. > Your definition of dis-respect is not the same as the rest of the people in this conversation. A general rule of politeness seems to be that one can call oneself a disparaging name, but it is extremely im-polite to call someone else that name. EG if one sells fish, one can call oneself a fish-monger (or various other street terms on the East Side), calling someone else that is a sign of dis-respect (except in certain areas where it was all looked upon by all members of the conversation as being a sign of secret pride of 'membership'). In the context of this conversation, the term package-monkey is not seen as a source of pride by most people reading, and thus is parsed as an error by the other readers. -- 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 Tue Nov 21 17:56:58 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 21 Nov 2006 12:56:58 -0500 Subject: [Fedora Project Wiki] Update of "Infrastructure/ProjectHosting" by BillNottingham In-Reply-To: <20061121171543.GC626@nostromo.devel.redhat.com> References: <20061121155300.26994.33913@fpserv.linux.duke.edu> <200611211154.05193.jkeating@redhat.com> <20061121171543.GC626@nostromo.devel.redhat.com> Message-ID: <200611211257.01687.jkeating@redhat.com> On Tuesday 21 November 2006 12:15, Bill Nottingham wrote: > It's Yet Another Tracking System for people to learn and use. You're going > to have, for most any project, people filing bugs in BZ anyway against > the component as it's shipped in a release. Sure once its released, however before then, and if its used in any other distribution... And bugs filed in BZ for a problem are good things. Fixing it upstream and getting those fixed into a package downstream are two different things, and really should be two different bugs anyway. Upstream author isn't always going to be the downstream packager either. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Tue Nov 21 23:26:09 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 22 Nov 2006 00:26:09 +0100 Subject: [fab] Architecture Policy. In-Reply-To: <1164126685.19448.44.camel@pmac.infradead.org> References: <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> <1164073756.6925.164.camel@pmac.infradead.org> <20061121161837.GB31789@nostromo.devel.redhat.com> <1164126685.19448.44.camel@pmac.infradead.org> Message-ID: <20061122002609.eb3ddfb3.bugs.michael@gmx.net> On Tue, 21 Nov 2006 16:31:25 +0000, David Woodhouse wrote: > On Tue, 2006-11-21 at 11:18 -0500, Bill Nottingham wrote: > > Have you *READ* the proposal? > > Of course I've read the proposal. Have _you_ actually tried dealing with > Extras package-monkeys recently; trying to get them to fix a problem in > their packages which is even slightly outside their own use case? Does this refer to just https://bugzilla.redhat.com/208774 or would you like to provide more examples? From mmcgrath at fedoraproject.org Wed Nov 22 03:43:45 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 21 Nov 2006 21:43:45 -0600 Subject: Metrics: RFC Message-ID: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> So I've compiled thoughts and issues we've come across with our first round of metrics in FC6. and created a wiki page so we can actually keep track of ideas. Its a wiki so add/alter stuff as you see fit. http://fedoraproject.org/wiki/Infrastructure/Metrics I've posed a similar question to the fedora-users list to see how the community at large responds. https://www.redhat.com/archives/fedora-list/2006-November/msg05080.html Lets try to come to a conclusion as to the method we'd like to see used in Fedora. What are your thoughts? -Mike From dwmw2 at infradead.org Wed Nov 22 07:07:26 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 22 Nov 2006 07:07:26 +0000 Subject: [fab] Architecture Policy. In-Reply-To: <20061122002609.eb3ddfb3.bugs.michael@gmx.net> References: <3237e4410611160706p56e07c3fh7ad3c192baa65749@mail.gmail.com> <1163692035.4340.10.camel@zod.rchland.ibm.com> <455C8D06.5080807@redhat.com> <1163758251.21366.246.camel@shinybook.infradead.org> <455F3C03.2070602@redhat.com> <1163885812.3365.24.camel@shinybook.infradead.org> <1164041281.3221.126.camel@localhost.localdomain> <1164044055.3221.136.camel@localhost.localdomain> <1164073756.6925.164.camel@pmac.infradead.org> <20061121161837.GB31789@nostromo.devel.redhat.com> <1164126685.19448.44.camel@pmac.infradead.org> <20061122002609.eb3ddfb3.bugs.michael@gmx.net> Message-ID: <1164179246.19448.89.camel@pmac.infradead.org> On Wed, 2006-11-22 at 00:26 +0100, Michael Schwendt wrote: > On Tue, 21 Nov 2006 16:31:25 +0000, David Woodhouse wrote: > > > On Tue, 2006-11-21 at 11:18 -0500, Bill Nottingham wrote: > > > Have you *READ* the proposal? > > > > Of course I've read the proposal. Have _you_ actually tried dealing with > > Extras package-monkeys recently; trying to get them to fix a problem in > > their packages which is even slightly outside their own use case? > > Does this refer to just https://bugzilla.redhat.com/208774 or would you > like to provide more examples? I didn't have that specific bug in mind, no. If feel that to provide specific examples of 'package-monkey' behaviour _would_ be impolite to the individuals concerned -- regardless of the terminology I use; I'd be saying "I'm concerned by the quality of maintenance from people like $foo; we need to make sure we keep them in order and not let them find any extra excuses not to maintain their package properly." I merely expressed concern at the _possibility_ that this might happen, and I seem to have been assured that it won't be allowed to happen. So that's good. -- dwmw2 From blizzard at redhat.com Wed Nov 22 15:39:34 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 22 Nov 2006 10:39:34 -0500 Subject: Metrics: RFC In-Reply-To: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> Message-ID: <45646F36.2010206@redhat.com> Mike McGrath wrote: > So I've compiled thoughts and issues we've come across with our first > round of metrics in FC6. and created a wiki page so we can actually > keep track of ideas. Its a wiki so add/alter stuff as you see fit. > > http://fedoraproject.org/wiki/Infrastructure/Metrics > > I've posed a similar question to the fedora-users list to see how the > community at large responds. > > https://www.redhat.com/archives/fedora-list/2006-November/msg05080.html > I love how one of the Cons is just "evil." :) So those are a lot of possible mechanisms. Let's talk about goals instead? What do we actually want to know? Here's what I would love to have: o Rough guess of total number of installs o Total number of server machines o Total number of desktop machines o Number of people who install, use, then never use again o Total number of people who use on a daily/weekly/monthly basis o What hardware people are using in the field. Now I'm going to make an assertion. I assert that people only hate these kinds of things when it gives them no value whatsoever. That is, they don't receive anything in trade for that information. What we need to do is to make sure that in return for becoming part of our network, that people feel like they are getting something in return. Maybe it's direct, maybe it's indirect, but still useful. Let's look at an actual scenario. I would actually start with the last goal on that list to go off of. If we are able to collect a set of hardware profiles for people, just after an install, and tie that to a unique machine identifier, we could make that really useful for people. The reason being that having access to information about what hardware people are really using allows us to know where we need to concentrate our efforts. DavidZ wrote a little utility for RHEL that basically says "hey, your suspend failed, your hardware is busted!" (in friendlier terms.) What I would love to do is to do the same thing with FC6, but with tracking over time. For example, let's say you have a machine and you want to suspend it. That suspend succeeds or fails. It would be great if both success + failures of those were reported to us. Then we could really build a good/bad hardware + driver list. No one really has this today, and it's of clear benefit to our users. Also, we could include in that data what kernel people were using and if we saw a big set of new failures after a certain kernel update, we would know that a certain set of hardware was busted in a release. Really useful at a macro level to people like Dave Jones and upstream kernel people. Now, what does this have to do with metrics? Everything. Note that the above scenario allows us to gather information about desktops, hardware and daily users, and has per-machine information, but there's clear value to both the people using it and the people providing the software. That's the way that we need to approach gathering metrics. Give _and_ take, not just something we're doing to the people who use the software we so lovingly put together. That's where "Evil" comes from but we want to make sure we're not Evil. Just helpful. --Chris From mmcgrath at fedoraproject.org Wed Nov 22 15:50:06 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 22 Nov 2006 09:50:06 -0600 Subject: Metrics: RFC In-Reply-To: <45646F36.2010206@redhat.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> Message-ID: <3237e4410611220750g3e28adafxefcda19ff086fd56@mail.gmail.com> On 11/22/06, Christopher Blizzard wrote: > Mike McGrath wrote: > o Rough guess of total number of installs > o Total number of server machines > o Total number of desktop machines Its impossible to get server vs desktop > o Number of people who install, use, then never use again > o Total number of people who use on a daily/weekly/monthly basis > o What hardware people are using in the field. > I think we'd all love to see a hardware profiler, its been on the infrastructure schedule since before I joined the team. The problem is actually getting enough traction to get it developed and deployed. Is this something we could have ready for FC7 or should we come up with something very basic first and then release something more advanced for FC8? -Mike From matt at domsch.com Wed Nov 22 16:11:10 2006 From: matt at domsch.com (Matt Domsch) Date: Wed, 22 Nov 2006 10:11:10 -0600 Subject: Metrics: RFC In-Reply-To: <3237e4410611220750g3e28adafxefcda19ff086fd56@mail.gmail.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> <3237e4410611220750g3e28adafxefcda19ff086fd56@mail.gmail.com> Message-ID: <20061122161109.GB29804@domsch.com> On Wed, Nov 22, 2006 at 09:50:06AM -0600, Mike McGrath wrote: > On 11/22/06, Christopher Blizzard wrote: > >Mike McGrath wrote: > >o Rough guess of total number of installs > >o Total number of server machines > >o Total number of desktop machines > > Its impossible to get server vs desktop > > >o Number of people who install, use, then never use again > >o Total number of people who use on a daily/weekly/monthly basis > >o What hardware people are using in the field. > > > > I think we'd all love to see a hardware profiler, its been on the > infrastructure schedule since before I joined the team. The problem > is actually getting enough traction to get it developed and deployed. > Is this something we could have ready for FC7 or should we come up > with something very basic first and then release something more > advanced for FC8? We should poke the RHN folks; if you look in RHEL5 beta2 (public), they've got something that exports lshal information to a collection server backend. Perhaps we can leverage that, it's GPL after all. -Matt From blizzard at redhat.com Wed Nov 22 16:16:00 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 22 Nov 2006 11:16:00 -0500 Subject: Metrics: RFC In-Reply-To: <3237e4410611220750g3e28adafxefcda19ff086fd56@mail.gmail.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> <3237e4410611220750g3e28adafxefcda19ff086fd56@mail.gmail.com> Message-ID: <456477C0.4030700@redhat.com> Mike McGrath wrote: > Its impossible to get server vs desktop Runlevel 3 vs. runlevel 5? The installer choice made? You can make some good guesses, and that's good enough. We're not looking for something that's perfect. This is a probabilistic system, not a deterministic one. >> o Number of people who install, use, then never use again >> o Total number of people who use on a daily/weekly/monthly basis >> o What hardware people are using in the field. >> > > I think we'd all love to see a hardware profiler, its been on the > infrastructure schedule since before I joined the team. The problem > is actually getting enough traction to get it developed and deployed. > Is this something we could have ready for FC7 or should we come up > with something very basic first and then release something more > advanced for FC8? I think we should start now and if it makes FC7, that's great. If it doesn't, that's OK too. But I would love something that worked in FC6 that people can just install and use. Maybe push as an update or something. Get people testing early and often. --Chris From blizzard at redhat.com Wed Nov 22 16:16:17 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 22 Nov 2006 11:16:17 -0500 Subject: Metrics: RFC In-Reply-To: <20061122161109.GB29804@domsch.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> <3237e4410611220750g3e28adafxefcda19ff086fd56@mail.gmail.com> <20061122161109.GB29804@domsch.com> Message-ID: <456477D1.5090603@redhat.com> Matt Domsch wrote: > On Wed, Nov 22, 2006 at 09:50:06AM -0600, Mike McGrath wrote: >> On 11/22/06, Christopher Blizzard wrote: >>> Mike McGrath wrote: >>> o Rough guess of total number of installs >>> o Total number of server machines >>> o Total number of desktop machines >> Its impossible to get server vs desktop >> >>> o Number of people who install, use, then never use again >>> o Total number of people who use on a daily/weekly/monthly basis >>> o What hardware people are using in the field. >>> >> I think we'd all love to see a hardware profiler, its been on the >> infrastructure schedule since before I joined the team. The problem >> is actually getting enough traction to get it developed and deployed. >> Is this something we could have ready for FC7 or should we come up >> with something very basic first and then release something more >> advanced for FC8? > > > We should poke the RHN folks; if you look in RHEL5 beta2 (public), > they've got something that exports lshal information to a > collection server backend. Perhaps we can leverage that, it's GPL > after all. > > -Matt > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board Hmm, interesting. I wonder who wrote that. --Chris From blizzard at redhat.com Wed Nov 22 16:17:55 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 22 Nov 2006 11:17:55 -0500 Subject: Metrics: RFC In-Reply-To: <456477D1.5090603@redhat.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> <3237e4410611220750g3e28adafxefcda19ff086fd56@mail.gmail.com> <20061122161109.GB29804@domsch.com> <456477D1.5090603@redhat.com> Message-ID: <45647833.7090908@redhat.com> Christopher Blizzard wrote: > > Hmm, interesting. I wonder who wrote that. That's code for "I'm poking around to find the party responsible." --Chris From tibbs at math.uh.edu Wed Nov 22 17:12:26 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 22 Nov 2006 11:12:26 -0600 Subject: Metrics: RFC In-Reply-To: <45646F36.2010206@redhat.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> Message-ID: >>>>> "CB" == Christopher Blizzard writes: CB> If we are able to collect a set of hardware profiles for people, CB> just after an install, and tie that to a unique machine CB> identifier, we could make that really useful for people. The CB> reason being that having access to information about what hardware CB> people are really using allows us to know where we need to CB> concentrate our efforts. I and I'm sure a good portion of Fedora users would happily install a package that periodically sent various bits of info related to what hardware is in the system, what packages are installed, what kernel is currently running, etc. Such information could be immensely useful to community packagers as a validation that their packages are actually being used somewhere. There are all sorts of useful bits of information we could collect, most of which require that some client be installed. I suggest that this isn't a problem as long as: There's only one thing to install, not a collection of random info-gathering clients. The client runs from cron and doesn't consume any memory when it's not running. It is not installed by default. The installer can ask, sure. "Please help us improve Fedora! Do you want to install the blahblah client?". "Yes" should probably not be the default choice. (It could be installed by default but not enabled by default, but even that is probably pushing it. It's about the appearance of impropriety.) The list of information gathered is presented to the user somehow. An option should be there to provide someone (root?) with a report of everything sent in when it's sent in if someone really wants to know. Updates to the package which provide new information-gathering plugins should not cause those new plugins to be enabled without user intervention. That's pretty much all the evil-minimization you can reasonably do. The question is whether the response rate will be high enough and whether the responses you get give you a statistically valid sample. - J< From fedora at leemhuis.info Wed Nov 22 20:34:58 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 22 Nov 2006 21:34:58 +0100 Subject: Where is the position of FESCo/its successor now/during/after the merge Message-ID: <4564B472.9080902@leemhuis.info> Hi, it seems people are not completely sure (?) where the exact position and role of FESCo and its successor is now, during and after the merge with Core that was roughly outlined on the summit (and not yet official, but let's leave that fact out of here for now). Thus it might be a good idea to discuss this topic here to make sure we are all talking about the same stuff when we talk about FESCo and it's position in the future -- there is afaics no need to go to much into the details, just the rough direction should be enough for now afaics (I'll send out a more detailed proposal how I imagine the FESCo future after this discussion is over). I understood it like this until now: - Core Packages move over to Extras - Extras is renamed to something more generic -- let's name it "Fedora Package Collection (FPC)" here for now - FESCo will govern over all the packages and the rules around them; will likely get a new name, too; maybe new members - no Core, thus no Core cabal then; some/all people from it maybe get integrated into FESCo - the things that the Core cabal did and does (release process, bring the tree in shape for release, plan feature to work on or the next release, ...) somehow need to be done by FESCo then; probably by sub-committees/groups (or something like that) that report to FESCo - problematic topics can be moved to the Fedora Board for further discussion/guidance (no, don't go into discussing details about this just yet -- but we need that path probably) @Fedora Board: Is the above roughly correct? Cu thl (?) -- Quoting f13 from todays fesco meeting: "Well I'm just not seeing anything clear about what the new FESCo will be responsible for, and without knowing that, how can we possible determine who should be in it or out of it or reporting to it or...." From rdieter at math.unl.edu Wed Nov 22 21:50:35 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 22 Nov 2006 15:50:35 -0600 Subject: Where is the position of FESCo/its successor now/during/after the merge In-Reply-To: <4564B472.9080902@leemhuis.info> References: <4564B472.9080902@leemhuis.info> Message-ID: <4564C62B.3080204@math.unl.edu> Thorsten Leemhuis wrote: > Hi, > > it seems people are not completely sure (?) where the exact position and > role of FESCo and its successor is now, during and after the merge with > Core that was roughly outlined on the summit (and not yet official, but > let's leave that fact out of here for now). Thus it might be a good idea > to discuss this topic here to make sure we are all talking about the > same stuff when we talk about FESCo and it's position in the future -- > there is afaics no need to go to much into the details, just the rough > direction should be enough for now afaics (I'll send out a more detailed > proposal how I imagine the FESCo future after this discussion is over). > > I understood it like this until now: > > - Core Packages move over to Extras > - Extras is renamed to something more generic -- let's name it "Fedora > Package Collection (FPC)" here for now > - FESCo will govern over all the packages and the rules around them; > will likely get a new name, too; maybe new members > - no Core, thus no Core cabal then; some/all people from it maybe get > integrated into FESCo > - the things that the Core cabal did and does (release process, bring > the tree in shape for release, plan feature to work on or the next > release, ...) somehow need to be done by FESCo then; probably by > sub-committees/groups (or something like that) that report to FESCo > - problematic topics can be moved to the Fedora Board for further > discussion/guidance (no, don't go into discussing details about this > just yet -- but we need that path probably) > > @Fedora Board: Is the above roughly correct? Your summary pretty much matches my expectations for the new FESCo. -- Rex From mmcgrath at fedoraproject.org Fri Nov 24 04:58:22 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 23 Nov 2006 22:58:22 -0600 Subject: Metrics: RFC In-Reply-To: References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> Message-ID: <3237e4410611232058p151c420u3ccc5566a98e1763@mail.gmail.com> On 22 Nov 2006 11:12:26 -0600, Jason L Tibbitts III wrote: > >>>>> "CB" == Christopher Blizzard writes: > I and I'm sure a good portion of Fedora users would happily install > a package that periodically sent various bits of info related to what > hardware is in the system, what packages are installed, what kernel is > currently running, etc. Such information could be immensely useful to > community packagers as a validation that their packages are actually > being used somewhere. For those not following the Fedora-Users thread it seems like a lot of the people kind of just 'don't care' or would at least participate. The thing is the ones that don't want to participate or have moral/ethical objections to it are very vocal, and rightfully so really. As Ralf said in the thread we need to be extremely careful with this. Most of the users have so far seemed to prefer opt-in to opt-out. Whatever we do needs to be explicitly defined, probably in the release notes but also wherever the opt-in/out sction is. Those that are concerned with privacy in any way will have plenty of notice ahead of time to simply not participate. -Mike From matt at domsch.com Fri Nov 24 14:17:53 2006 From: matt at domsch.com (Matt Domsch) Date: Fri, 24 Nov 2006 08:17:53 -0600 Subject: Metrics: RFC In-Reply-To: <3237e4410611232058p151c420u3ccc5566a98e1763@mail.gmail.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> <3237e4410611232058p151c420u3ccc5566a98e1763@mail.gmail.com> Message-ID: <20061124141752.GA15810@domsch.com> On Thu, Nov 23, 2006 at 10:58:22PM -0600, Mike McGrath wrote: > On 22 Nov 2006 11:12:26 -0600, Jason L Tibbitts III > wrote: > >>>>>> "CB" == Christopher Blizzard writes: > >I and I'm sure a good portion of Fedora users would happily install > >a package that periodically sent various bits of info related to what > >hardware is in the system, what packages are installed, what kernel is > >currently running, etc. Such information could be immensely useful to > >community packagers as a validation that their packages are actually > >being used somewhere. Only somewhat; installed != used, but there's no clean way to track which apps are actually used (or is there?). Windows has something like this - if you've ever gone to the Add/Remove Programs applet to remove something, it notes roughly how often that app is used. I just know that large "Everything"-style installs will overcount. From tibbs at math.uh.edu Fri Nov 24 17:17:44 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 24 Nov 2006 11:17:44 -0600 Subject: Metrics: RFC In-Reply-To: <20061124141752.GA15810@domsch.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> <3237e4410611232058p151c420u3ccc5566a98e1763@mail.gmail.com> <20061124141752.GA15810@domsch.com> Message-ID: >>>>> "MD" == Matt Domsch writes: MD> Only somewhat; installed != used, but there's no clean way to MD> track which apps are actually used (or is there?). The accounting subsystem has the means to do that kind of thing, but I don't think it's necessary or even if it would be desired to go to the trouble to extract that level of information. After all, "installed != used" applies even to the OS installation. Every attempt to gather statistics will overcount some things and undercount others. - J< From blizzard at redhat.com Sun Nov 26 01:16:39 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Sat, 25 Nov 2006 20:16:39 -0500 Subject: Where is the position of FESCo/its successor now/during/after the merge In-Reply-To: <4564B472.9080902@leemhuis.info> References: <4564B472.9080902@leemhuis.info> Message-ID: <4568EAF7.40207@redhat.com> Thorsten Leemhuis wrote: > - Core Packages move over to Extras > - Extras is renamed to something more generic -- let's name it "Fedora > Package Collection (FPC)" here for now I think I (we?) prefer Fedora Universe.[*] --Chris * We need to have more fun with our naming, I think. Bring the love back. From blizzard at redhat.com Sun Nov 26 01:30:31 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Sat, 25 Nov 2006 20:30:31 -0500 Subject: Metrics: RFC In-Reply-To: <20061124141752.GA15810@domsch.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> <3237e4410611232058p151c420u3ccc5566a98e1763@mail.gmail.com> <20061124141752.GA15810@domsch.com> Message-ID: <4568EE37.1060804@redhat.com> Matt Domsch wrote: > > Only somewhat; installed != used, but there's no clean way to track > which apps are actually used (or is there?). Windows has something > like this - if you've ever gone to the Add/Remove Programs applet to > remove something, it notes roughly how often that app is used. I just > know that large "Everything"-style installs will overcount. Attach execution to package to usage? You could do it, sure. But someone would have to write it. :D --Chris From blizzard at redhat.com Sun Nov 26 01:32:13 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Sat, 25 Nov 2006 20:32:13 -0500 Subject: Metrics: RFC In-Reply-To: <3237e4410611232058p151c420u3ccc5566a98e1763@mail.gmail.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> <3237e4410611232058p151c420u3ccc5566a98e1763@mail.gmail.com> Message-ID: <4568EE9D.5000807@redhat.com> Mike McGrath wrote: > For those not following the Fedora-Users thread it seems like a lot of > the people kind of just 'don't care' or would at least participate. > The thing is the ones that don't want to participate or have > moral/ethical objections to it are very vocal, and rightfully so > really. As Ralf said in the thread we need to be extremely careful > with this. Is there a fedora-users thread? Do you have a url to it? > Most of the users have so far seemed to prefer opt-in to opt-out. > > Whatever we do needs to be explicitly defined, probably in the release > notes but also wherever the opt-in/out sction is. Those that are > concerned with privacy in any way will have plenty of notice ahead of > time to simply not participate. I'd rather not have an explicit opt-in/opt-out kind of decision other than "share my hardware profile support information with fedora developers - help us improve it!" with a link to a privacy policy. --Chris From blizzard at redhat.com Sun Nov 26 01:40:12 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Sat, 25 Nov 2006 20:40:12 -0500 Subject: Metrics: RFC In-Reply-To: References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> Message-ID: <4568F07C.9020904@redhat.com> Jason L Tibbitts III wrote: > I and I'm sure a good portion of Fedora users would happily install > a package that periodically sent various bits of info related to what > hardware is in the system, what packages are installed, what kernel is > currently running, etc. Such information could be immensely useful to > community packagers as a validation that their packages are actually > being used somewhere. That would be useful. But I want us to stay focused one one thing to start and one of the areas we're really hurting in is good hardware support. That can really have a positive impact on our users, so I think it's worth it to try and start there. > > There are all sorts of useful bits of information we could collect, > most of which require that some client be installed. I suggest that > this isn't a problem as long as: > > There's only one thing to install, not a collection of random > info-gathering clients. Keeping in mind what we want to measure, I would guess that we have a few things here: 1. Something that's run every time you change the kernel that can ask users to run through a set of simple tests? Annoying, but maybe we can only run it for 1/20 people and since we're just interested in statistical information, that's enough. Think high level (external monitor support, sound, suspend/resume, etc.) 2. A small program that's run during each suspend and resume. Leaves a file behind reporting success/failure and what was running right before and after each suspend. This gets picked up by a program, maybe from cron and is submitted. > > The client runs from cron and doesn't consume any memory when it's not > running. > > It is not installed by default. The installer can ask, sure. "Please > help us improve Fedora! Do you want to install the blahblah client?". > "Yes" should probably not be the default choice. (It could be > installed by default but not enabled by default, but even that is > probably pushing it. It's about the appearance of impropriety.) Yeah, we'll need to be careful. But I also want to make sure that we talk about really what we're trying to do here (really improve the system) as opposed to just find out how many users we have. The second is just a side effect of the first. > The list of information gathered is presented to the user somehow. An > option should be there to provide someone (root?) with a report of > everything sent in when it's sent in if someone really wants to know. > Updates to the package which provide new information-gathering plugins > should not cause those new plugins to be enabled without user > intervention. > > That's pretty much all the evil-minimization you can reasonably do. > The question is whether the response rate will be high enough and > whether the responses you get give you a statistically valid sample. A sample of even a few thousand systems can give us a sense of what hardware people are using. If we can connect hardware -> drivers -> kernel version -> suspend success/fail and higher level success/failure metrics (like, does my backlight control work? How about sound?) we can really start to make dave jones' life much easier. And that's one of my real goals. --Chris From smooge at gmail.com Sun Nov 26 04:50:21 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 25 Nov 2006 21:50:21 -0700 Subject: Where is the position of FESCo/its successor now/during/after the merge In-Reply-To: <4568EAF7.40207@redhat.com> References: <4564B472.9080902@leemhuis.info> <4568EAF7.40207@redhat.com> Message-ID: <80d7e4090611252050k6f02d605lecaa45ce48ccb20d@mail.gmail.com> On 11/25/06, Christopher Blizzard wrote: > Thorsten Leemhuis wrote: > > - Core Packages move over to Extras > > - Extras is renamed to something more generic -- let's name it "Fedora > > Package Collection (FPC)" here for now > > I think I (we?) prefer Fedora Universe.[*] > > --Chris > > * We need to have more fun with our naming, I think. Bring the love back. > Aquarius.. Hair? > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From fedora at leemhuis.info Sun Nov 26 14:57:01 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 26 Nov 2006 15:57:01 +0100 Subject: FESCo future Message-ID: <4569AB3D.6040007@leemhuis.info> Hi All! Well, with the proposed Core and Extras merge ( http://www.fedoraproject.org/wiki/FedoraSummit/OpeningCore ) we need to adjust FESCo to the new world order quite soon probably. Here are my thoughts and a rough proposal how it could look like. Feedback much appreciated. BTW, I send some earlier thoughts to the FESCo-list and some people in private -- this proposal is a different one ;-) Note: I'll use FPCSC (Fedora Package Collection Steering Committee) as a phrase for the FESCo successor that will govern the merged Core and Extras repository. That should help to clarifying witch of the two is meant (yes, FPCSC is lame, but it was the best my mind came up with for now; Package Universe would work, too, but it seems some people don't like the term "universe" because it has a different meaning in another repo). Note2: FPCSC in the Fedora Project hierarchy is afaics located below the FPB on the same level as the Infrastructure Group or the Ambassadors. See also: https://www.redhat.com/archives/fedora-advisory-board/2006-November/msg00248.html == Constitution of FPCSC == FPCSC will needs to do what the "Core cabal" and FESCo do now and thus will have a lot more work to do than FESCo currently does. Thus it might be a good idea to make FPCSC a bit bigger. I'd say 14, 16 or 18 people (FESCo currently has 13 members). There were deliberations to assign quite a lot of seats (6-8) to special position instead of letting the contributors vote on the seats. This was discussed in a FESCo meeting (f13 took parts in that discussions; see http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20061122 for details) and most people seemed to disliked the idea. Thus most or all seats should be elected similar to how FESCo got elected (see http://www.fedoraproject.org/wiki/Extras/Policy/FESCoElections for details how a FESCo election is done). We just need to make sure that the community and Red Hat feel represented and heard, thus I propose following mix for FPCSC: * FPCSC consists of 16 seats; * the Chair has veto rights -- that means the particular decision or topic is transfered to the Fedora Project Board for further guidance and considerations * two seats are special for a representative from the Community Committee and a representative from Red Hat (see below for backgrounds of these groups); both have veto rights, too; this positions are not bound to special persons; it would be good if always the same persons from the committee's shows up, but if they are not able to they can send someone else from the committee as stand-in. * all the other seats are elected by the community once a year after a Fedora release * at least 50% of the seats need to be filled by community members. * the chair gets elected on the first meeting after a election * If there is deadlock in a voting the decision is either deferred and brought back up in the next meeting or it is presented to the FPB for further discussion/guidance. * if a member steps down FPCSC chooses someone else to fill the seat. The member can propose someone as his replacement and FPCSC will strongly consider the person proposed. * inactive members get thrown out (we sooner or later need to define how inactive looks in detail; not showing up in the meetings, not participating or following FPCSC work, ...) * FPCSC gets initially filled with the current FESCo members and some appointed people that look like good candidates. The first election of the voted seats will happen after the next release. == Create sub-committees/groups for special tasks == FPCSC will have a lot more to do after the merge. Thus it has to delegate the all the work somehow and should not have to look after each and every detail. Special groups with a committee that leads them rather should look into the details and mostly work out solutions own their own. FPCSC should more act as coordinator and guide the big decisions. The sub-committees should handle small decisions on its own without getting FPCSC involved. Medium sized decisions should be posted to the list to notify the community about them (once before they are ratified and once after that) and to FPCSC so the Committee can speak up if they really don't like something. Big decisions should explicitly be presented to FPCSC and get ACKed there. Only really big decisions should need direct FPCSC (or sometimes even FPB) involvement. Most of these groups should act similar to the scheme how the packaging committee or FESCo are working currently. Rough example: * a members or the committee or some random interested contributor works out a proposal to solve a particular issue. * he sends the proposal to a public mailing list for discussion * he participates in the discussion and integrates suggestions from the community that came up in that discussion * he presents the proposal to the responsible committee. * the committee then might suggest/request further changes (the committee members are strongly urged to raise their concerns directly in the public discussion!) and sooner or later should find a solution and ACK it * a report of the final decision gets send to the lists (and to FPCSC if its a medium sized decision) There are some subgroups that we need on a permanent basis: * release engendering * desktop group * kernel group * installer team * packaging committee * security team * testing/QA team * a community committee (as a second FESCo successor that should handle only the interests of the community to make sure it feels really represented) * a Red Hat committee (as a Core Cabal successor that's representing Red Hat interests) * even more? there are probably some that don't come to my mind just yet. It would be good is someone from each sub-committee/group steps up for the FPCSC election; we really want representatives from the most important groups/committees in FPCSC, but we can have them all, and people should be act smart enough to get elected. Besides those permanent groups there probably now and then will be special groups that exists only on a timely manner to solve a particular issue. Due to the position in the Fedora Project hierarchy FPCSC is able to delegate work to the subgroups to let them solve particular problems. The subgroups are normally strongly encouraged to * have at least one fourth of their members from the community/from Red Hat (exception: Red Hat/Community committees) * maintain a public schedule in the wiki (similar to the stuff FESCo or the Packaging Commitee do now) * the group has to meet regularly in the public and discusses things in public, too We further need to make sure that the sub-groups work well and have someone that is accountable for each sub-group. That is quite hard in a primarily volunteer driven organization -- it often only works if there is enough momentum, if someone that really is interested in the task or if he is payed for his work. Thus for the permanent groups it will often be the best if someone that gets payed for his work is accountable. = Quorum = We all have real life and often a lot to do at work, too, thus is hard to get 50.1% of the committee members together for each meeting to vote on a proposal. Some of the existing community groups and committees with a quorum of at least 50.1% have shown that and were quite slow due to that regulation sometimes. I'd like to avoid that for FPCSC and thus propose that to accept a proposal in FPCSC at least one third of the members vote with +1 if no one dislikes the proposal in the voting -- e.g. if only one members votes with "-1" on a proposal then at least 50,1% of the total members have to vote with +1 to overrule him *or* the decisions is deferred and brought up in the next meeting; then it's enough if 1/3 of the members vote with "+1". Note that there are considerations to set up a online voting system in the long term; then even those that can't make it to the meeting are able to vote on a proposal and participate. *Maybe* we'll also let the community vote on some particular issues, but that quite hard to realize if we want to make it right. = EOF = Comments? CU thl From bugs.michael at gmx.net Sun Nov 26 17:56:34 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 26 Nov 2006 18:56:34 +0100 Subject: FESCo future In-Reply-To: <4569AB3D.6040007@leemhuis.info> References: <4569AB3D.6040007@leemhuis.info> Message-ID: <20061126185634.af549786.bugs.michael@gmx.net> On Sun, 26 Nov 2006 15:57:01 +0100, Thorsten Leemhuis wrote: > == Constitution of FPCSC == > > FPCSC will needs to do what the "Core cabal" and FESCo do now and thus > will have a lot more work to do than FESCo currently does. Thus it might > be a good idea to make FPCSC a bit bigger. I'd say 14, 16 or 18 people > (FESCo currently has 13 members). FESCO's size is insufficient already. FESCO is not as productive as it could be if there were more members. Originally, FESCO had been created to form a small group of people who could get something done. Over time, FESCO has degraded to a collection of people, who fill seats in multiple committees and find themselves unable to pursue "FESCO business". > == Create sub-committees/groups for special tasks == > > FPCSC will have a lot more to do after the merge. Thus it has to > delegate the all the work somehow and should not have to look after each > and every detail. Special groups with a committee that leads them rather > should look into the details and mostly work out solutions own their > own. FPCSC should more act as coordinator and guide the big decisions. The "big decisions" must come from the committee. Only if the decision require additional work, this can be delegated to external contributors. For instance, the final wording of policy documents can be finished with the assistance of documentation folks. > Most of these groups should act similar to the scheme how the packaging > committee or FESCo are working currently. Rough example: > > * a members or the committee or some random interested contributor > works out a proposal to solve a particular issue. Strike "most of", because what you describe in detail is just _one way_ how the community can propose something what the committee has not thought of before. Ideally most of the expertise is available in the committee, and the committee does not wait for community folks to influence the passive steering. From stickster at gmail.com Sun Nov 26 18:29:19 2006 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 26 Nov 2006 18:29:19 +0000 Subject: FESCo future In-Reply-To: <4569AB3D.6040007@leemhuis.info> References: <4569AB3D.6040007@leemhuis.info> Message-ID: <1164565759.26160.12.camel@localhost.localdomain> On Sun, 2006-11-26 at 15:57 +0100, Thorsten Leemhuis wrote: [...snip...] > * two seats are special for a representative from the Community > Committee and a representative from Red Hat (see below for backgrounds > of these groups); both have veto rights, too; this positions are not > bound to special persons; it would be good if always the same persons > from the committee's shows up, but if they are not able to they can send > someone else from the committee as stand-in. > > * all the other seats are elected by the community once a year after a > Fedora release > > * at least 50% of the seats need to be filled by community members. I think these requirements, if examined closely, have a couple problems: 1/ We need to get away from substituting "community members" for "non-Red Hat employees." Red Hatters are community members too, and the unspoken implication is that there is a big wall there. The very fact that we're combining Core and Extras shows how much this factionism has dwindled over the past three years. 2/ If the seats are elected, how and why do you propose the results be tilted away from Red Hat employees -- for instance, if the majority of the elected seats happened to go to Red Hat employees? I do think the veto rights assignments help preserve the project from shooting one of its major benfactors in the foot. > * the chair gets elected on the first meeting after a election > > * If there is deadlock in a voting the decision is either deferred and > brought back up in the next meeting or it is presented to the FPB for > further discussion/guidance. Is there a reason you went for an even number of seats? With an odd number, naturally the majority of seats have to be held either by Red Hat employees or not. But the veto rights assigned to special seats and the chair should offset any worries of the minority group. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Sun Nov 26 18:52:28 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 26 Nov 2006 19:52:28 +0100 Subject: FESCo future In-Reply-To: <20061126185634.af549786.bugs.michael@gmx.net> References: <4569AB3D.6040007@leemhuis.info> <20061126185634.af549786.bugs.michael@gmx.net> Message-ID: <4569E26C.2030507@leemhuis.info> Michael Schwendt schrieb: > On Sun, 26 Nov 2006 15:57:01 +0100, Thorsten Leemhuis wrote: >> == Constitution of FPCSC == >> >> FPCSC will needs to do what the "Core cabal" and FESCo do now and >> thus will have a lot more work to do than FESCo currently does. >> Thus it might be a good idea to make FPCSC a bit bigger. I'd say >> 14, 16 or 18 people (FESCo currently has 13 members). > FESCO's size is insufficient already. FESCO is not as productive as > it could be if there were more members. So you suggest even more members? > Originally, FESCO had been created to form a small group of people > who could get something done. Well, we got a lot bigger in between... > Over time, FESCO has degraded to a collection of people, who fill > seats in multiple committees and find themselves unable to pursue > "FESCO business". Well, we had FESCo members in earlier FESCo's that were mostly quiet and never showed up to the meeting or on the public lists, too. The problem was even bigger than now. Anyway, I partly agree; we have people in FESCo that have a whole lot of packages, do a lot of reviews, are involved in other fedora business or are member of other committees, too -- thus they have often not enough time to concentrate on their FESCo work. Yeah, that not ideal. That the reason for this in my proposal: >> * inactive members get thrown out (we sooner or later need to >> define how inactive looks in detail; not showing up in the >> meetings, not participating or following FPCSC work, ...) Anything else we {sh,c}could do to prevent such problems in FPCSC? >> == Create sub-committees/groups for special tasks == >> >> FPCSC will have a lot more to do after the merge. Thus it has to >> delegate the all the work somehow and should not have to look after >> each and every detail. Special groups with a committee that leads >> them rather should look into the details and mostly work out >> solutions own their own. FPCSC should more act as coordinator and >> guide the big decisions. > > The "big decisions" must come from the committee. Yeah, that's what I meant (and what's outlined a bit more in detail one para after the above). I clarified the wording in both places. > Only if the > decision require additional work, this can be delegated to external > contributors. I'm not sure if we are talking about the same stuff. I for example want that the Packaging Committee mostly works on its own in the future and decides nearly everything own its own. Big decisions just need a explicit ACK from FPCSC or maybe need to be developed together. > For instance, the final wording of policy documents can > be finished with the assistance of documentation folks. Hehe, that would be nice. >> Most of these groups should act similar to the scheme how the >> packaging committee or FESCo are working currently. Rough example: >> * a members or the committee or some random interested contributor >> works out a proposal to solve a particular issue. > Strike "most of", I removed it and placed a explicit exception for the Red Hat committee as I don't care how Red Hat people run it. > because what you describe in detail is just _one > way_ how the community can propose something what the committee has > not thought of before. > > Ideally most of the expertise is available in the committee, and the > committee does not wait for community folks to influence the passive > steering. Hmm, I'd prefer to have the community directly involved so they can realize want they want and don't have to wait until a FPCSC member finds time to work on a issue. CU thl From fedora at leemhuis.info Sun Nov 26 19:01:09 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 26 Nov 2006 20:01:09 +0100 Subject: FESCo future In-Reply-To: <1164565759.26160.12.camel@localhost.localdomain> References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> Message-ID: <4569E475.2030708@leemhuis.info> Paul W. Frields schrieb: > On Sun, 2006-11-26 at 15:57 +0100, Thorsten Leemhuis wrote: > [...snip...] >> * two seats are special for a representative from the Community >> Committee and a representative from Red Hat (see below for backgrounds >> of these groups); both have veto rights, too; this positions are not >> bound to special persons; it would be good if always the same persons >> from the committee's shows up, but if they are not able to they can send >> someone else from the committee as stand-in. >> >> * all the other seats are elected by the community once a year after a >> Fedora release >> >> * at least 50% of the seats need to be filled by community members. > > I think these requirements, if examined closely, have a couple problems: > > 1/ We need to get away from substituting "community members" for > "non-Red Hat employees." Red Hatters are community members too, and the > unspoken implication is that there is a big wall there. The very fact > that we're combining Core and Extras shows how much this factionism has > dwindled over the past three years. Well, I agree with that in general. But I suspect if we don't have a "at leat xx% need to be non-redhatters" rule a lot of people will say "this is just another round in the never ending Red Hat game where they say to get the community involved without giving them rights". I'd like to avoid that. Any better idea? > 2/ If the seats are elected, how and why do you propose the results be > tilted away from Red Hat employees -- for instance, if the majority of > the elected seats happened to go to Red Hat employees? Then they don't get more seats then 50%. Similar to what gnome does for its board. If more than X members (X=three iirc -- or are it only two these days?) from one company get elected for the Board than only those X elected people get on the board. > [...] >> * the chair gets elected on the first meeting after a election >> >> * If there is deadlock in a voting the decision is either deferred and >> brought back up in the next meeting or it is presented to the FPB for >> further discussion/guidance. > Is there a reason you went for an even number of seats? With an odd > number, naturally the majority of seats have to be held either by Red > Hat employees or not. And that's what I wanted to avoid. > But the veto rights assigned to special seats and > the chair should offset any worries of the minority group. Hmmm. I still prefer a even number of seats to void problems from the start -- nobody should be forced to use the veto rights to often. CU thl From stickster at gmail.com Sun Nov 26 19:25:57 2006 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 26 Nov 2006 14:25:57 -0500 Subject: FESCo future In-Reply-To: <4569E475.2030708@leemhuis.info> References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> Message-ID: <1164569157.26378.26.camel@localhost.localdomain> On Sun, 2006-11-26 at 20:01 +0100, Thorsten Leemhuis wrote: > Paul W. Frields schrieb: > > 1/ We need to get away from substituting "community members" for > > "non-Red Hat employees." Red Hatters are community members too, and the > > unspoken implication is that there is a big wall there. The very fact > > that we're combining Core and Extras shows how much this factionism has > > dwindled over the past three years. > > Well, I agree with that in general. But I suspect if we don't have a "at > leat xx% need to be non-redhatters" rule a lot of people will say "this > is just another round in the never ending Red Hat game where they say to > get the community involved without giving them rights". I'd like to > avoid that. Any better idea? Sorry, I should have been more clear -- I just had a concern with the wording. I think when we mean, "non-Red Hat employees," we should use those words, since "community members" (in my mind) includes Red Hatters and non-Red Hatters. > > 2/ If the seats are elected, how and why do you propose the results be > > tilted away from Red Hat employees -- for instance, if the majority of > > the elected seats happened to go to Red Hat employees? > > Then they don't get more seats then 50%. Similar to what gnome does for > its board. If more than X members (X=three iirc -- or are it only two > these days?) from one company get elected for the Board than only those > X elected people get on the board. > > > [...] > >> * the chair gets elected on the first meeting after a election > >> > >> * If there is deadlock in a voting the decision is either deferred and > >> brought back up in the next meeting or it is presented to the FPB for > >> further discussion/guidance. > > Is there a reason you went for an even number of seats? With an odd > > number, naturally the majority of seats have to be held either by Red > > Hat employees or not. > > And that's what I wanted to avoid. But an election is likely to produce a majority one way or the other, unless you want exactly 50% each of Red Hat and non-Red Hat folks. (And I would bet the majority by election, in the absence of some other controlling regulation, is likely to result in non-RH folks outnumbering the RH ones.) I don't think it's a big worry either way, since there's probably more chance of one group's members disagreeing among themselves than there is for the groups to go all West Side Story on each other. > > But the veto rights assigned to special seats and > > the chair should offset any worries of the minority group. > > Hmmm. I still prefer a even number of seats to void problems from the > start -- nobody should be forced to use the veto rights to often. So did you mean we should have *exactly* 50% each Red Hat and non-Red Hat seats, as opposed to "at least 50% [non-Red Hat] community members"? Because if not, it's unlikely (although possible, of course) that an election would produce that outcome spontaneously, thus making it unnecessary to have an even number or worry about tie-breakers. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sopwith at gmail.com Sun Nov 26 19:42:37 2006 From: sopwith at gmail.com (Elliot Lee) Date: Sun, 26 Nov 2006 14:42:37 -0500 Subject: FESCo future In-Reply-To: <20061126185634.af549786.bugs.michael@gmx.net> References: <4569AB3D.6040007@leemhuis.info> <20061126185634.af549786.bugs.michael@gmx.net> Message-ID: On Nov 26, 2006, at 12:56 PM, Michael Schwendt wrote: >> FPCSC will needs to do what the "Core cabal" and FESCo do now and >> thus >> will have a lot more work to do than FESCo currently does. Thus it >> might >> be a good idea to make FPCSC a bit bigger. I'd say 14, 16 or 18 >> people >> (FESCo currently has 13 members). > > FESCO's size is insufficient already. FESCO is not as productive as it > could be if there were more members. Originally, FESCO had been > created to > form a small group of people who could get something done. Over time, > FESCO has degraded to a collection of people, who fill seats in > multiple > committees and find themselves unable to pursue "FESCO business". Hey all, The rule of thumb for efficient team sizing is 7 people +/-. FESCO is too big. Part of the reason people feel comfortable slacking on "FESCO business" is because they think that with such a large group, it doesn't matter if they slack off or not (see http:// en.wikipedia.org/wiki/Social_loafing). Adding more people to FESCO/ FPCSC will just make things worse. In addition, FESCO's purpose should be for making decisions that can't be made otherwise, not for being obligated to do all the work that needs doing. If people outside FESCO are not feeling like they can make headway, FESCO needs to get out of the way and empower those people, rather than trying to add more responsibilities to a FESCO TODO list. Best, -- Elliot From bugs.michael at gmx.net Sun Nov 26 20:08:19 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 26 Nov 2006 21:08:19 +0100 Subject: FESCo future In-Reply-To: <4569E26C.2030507@leemhuis.info> References: <4569AB3D.6040007@leemhuis.info> <20061126185634.af549786.bugs.michael@gmx.net> <4569E26C.2030507@leemhuis.info> Message-ID: <20061126210819.ab2ffbe7.bugs.michael@gmx.net> On Sun, 26 Nov 2006 19:52:28 +0100, Thorsten Leemhuis wrote: > >> == Constitution of FPCSC == > >> > >> FPCSC will needs to do what the "Core cabal" and FESCo do now and > >> thus will have a lot more work to do than FESCo currently does. > >> Thus it might be a good idea to make FPCSC a bit bigger. I'd say > >> 14, 16 or 18 people (FESCo currently has 13 members). > > FESCO's size is insufficient already. FESCO is not as productive as > > it could be if there were more members. > > So you suggest even more members? Yes and no. No, when more members just fill seats and don't do more than voting quickly on proposals which are expected to come out of the community. Yes, when a high number of members (or all members) are occupied with unknown things (or multiple responsibilities in various Fedora sub-projects and committees) and cannot spend any time at all on driving things forward. The term "meritocracy" has been used again and again. So I suggest a committee consists of members, who actually pursue relevant things they have declared as their goals, e.g. http://fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations-062007 and which may have been the primary reason why the community has voted them into the committee. And in order to be able to pursue their goals in their spare-time, they must find a compromise between the multiple places where they like to contribute something. > >> * inactive members get thrown out (we sooner or later need to > >> define how inactive looks in detail; not showing up in the > >> meetings, not participating or following FPCSC work, ...) > > Anything else we {sh,c}could do to prevent such problems in FPCSC? Well, the answer starts in the part you've put in brackets. You need to find out what responsibilities or duties (regardless of whether this is about volunteers) members of a committee have and whether it's possible to let individual members cover specific areas of a committee's activities. If most of the community representatives only sit in a committee and wait for unknown action items, which might be added to a schedule, that is quite unproductive. Preferably, individual members of a committee focus on specific fields of interest which are beneficial to the project and the community of contributors, who are part of that project. > > Only if the > > decision require additional work, this can be delegated to external > > contributors. > > I'm not sure if we are talking about the same stuff. I for example want > that the Packaging Committee mostly works on its own in the future and > decides nearly everything own its own. Big decisions just need a > explicit ACK from FPCSC or maybe need to be developed together. Splitting off the Packaging Committee only means that FESCO should be able to allocate the freed time for other things. That doesn't work too well if it's the same people who are in both committees, though. > > Ideally most of the expertise is available in the committee, and the > > committee does not wait for community folks to influence the passive > > steering. > > Hmm, I'd prefer to have the community directly involved so they can > realize want they want and don't have to wait until a FPCSC member finds > time to work on a issue. Too vague to comment on. You sound quite a lot like you refer to things which don't need any committee. However, for several other things *active* steering is needed (agenda, roadmap, policies, sanctions, directions e.g.) and can only come from a committee. From bugs.michael at gmx.net Sun Nov 26 20:11:34 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 26 Nov 2006 21:11:34 +0100 Subject: FESCo future In-Reply-To: References: <4569AB3D.6040007@leemhuis.info> <20061126185634.af549786.bugs.michael@gmx.net> Message-ID: <20061126211134.97721b35.bugs.michael@gmx.net> On Sun, 26 Nov 2006 14:42:37 -0500, Elliot Lee wrote: > The rule of thumb for efficient team sizing is 7 people +/-. FESCO is > too big. Part of the reason people feel comfortable slacking on > "FESCO business" is because they think that with such a large group, > it doesn't matter if they slack off or not (see http:// > en.wikipedia.org/wiki/Social_loafing). Adding more people to FESCO/ > FPCSC will just make things worse. Yes, you might have a good point there, but several members of FESCO are members of other teams, so it's very unclear whether at any point of time FESCO even has any people left, who could work on something. ;) From fedora at leemhuis.info Mon Nov 27 14:52:06 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 27 Nov 2006 15:52:06 +0100 Subject: FESCo future In-Reply-To: <1164569157.26378.26.camel@localhost.localdomain> References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> Message-ID: <456AFB96.8060400@leemhuis.info> Hi! Paul W. Frields schrieb: > On Sun, 2006-11-26 at 20:01 +0100, Thorsten Leemhuis wrote: >> Paul W. Frields schrieb: >>> 1/ We need to get away from substituting "community members" for >>> "non-Red Hat employees." Red Hatters are community members too, and the >>> unspoken implication is that there is a big wall there. The very fact >>> that we're combining Core and Extras shows how much this factionism has >>> dwindled over the past three years. >> Well, I agree with that in general. But I suspect if we don't have a "at >> leat xx% need to be non-redhatters" rule a lot of people will say "this >> is just another round in the never ending Red Hat game where they say to >> get the community involved without giving them rights". I'd like to >> avoid that. Any better idea? > Sorry, I should have been more clear -- I just had a concern with the > wording. I think when we mean, "non-Red Hat employees," we should use > those words, since "community members" (in my mind) includes Red Hatters > and non-Red Hatters. Okay, will re-word as outlined. > [...] >>>> * If there is deadlock in a voting the decision is either deferred and >>>> brought back up in the next meeting or it is presented to the FPB for >>>> further discussion/guidance. >>> Is there a reason you went for an even number of seats? With an odd >>> number, naturally the majority of seats have to be held either by Red >>> Hat employees or not. >> And that's what I wanted to avoid. > But an election is likely to produce a majority one way or the other, > unless you want exactly 50% each of Red Hat and non-Red Hat folks. (And > I would bet the majority by election, in the absence of some other > controlling regulation, is likely to result in non-RH folks outnumbering > the RH ones.) Hmm, all I wanted to avoid is that more than 50% of the members are from Red Hat as a lot of people won't like that. > I don't think it's a big worry either way, Agreed; we in FESCo until now tried to find consensus where at least nobody said "-1". That won't work that easy in the FPCSC, but I think we generally should avoid even situations where 9 people support a proposal while 7 are against it. So I think a 8 vs. 8 is not a big deal and if it really happens we can forward the issue to the FPC as that might be the best in such a situation in any case ;) > since there's > probably more chance of one group's members disagreeing among themselves > than there is for the groups to go all West Side Story on each other. :-) >>> But the veto rights assigned to special seats and >>> the chair should offset any worries of the minority group. >> Hmmm. I still prefer a even number of seats to void problems from the >> start -- nobody should be forced to use the veto rights to often. > So did you mean we should have *exactly* 50% each Red Hat and non-Red > Hat seats, as opposed to "at least 50% [non-Red Hat] community members"? No, if we run into 50% each Red Hat and non-Red Hat seats -- fine. If we have 55% non-Red Hat seats vs 45% from Red Hat -- fine for me, too. All I want to prevent is 45% non-Red Hat seats vs 55% from Red Hat ;) But I can also accept hardcoding 50% for both sides if people want that. A uneven number of seats, too, if people prefer that. > [...] CU thl From skvidal at linux.duke.edu Mon Nov 27 14:58:17 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 27 Nov 2006 09:58:17 -0500 Subject: FESCo future In-Reply-To: <456AFB96.8060400@leemhuis.info> References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> <456AFB96.8060400@leemhuis.info> Message-ID: <1164639497.24704.0.camel@cutter> On Mon, 2006-11-27 at 15:52 +0100, Thorsten Leemhuis wrote: > Hmm, all I wanted to avoid is that more than 50% of the members are from > Red Hat as a lot of people won't like that. > Let's make sure that there is a mention that if a non-rh member takes a job at rh that they don't lose their seat immediately. Only at the next set of elections will their present employment be taken into account. does that reasonable? -sv From gdk at redhat.com Mon Nov 27 15:05:03 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Mon, 27 Nov 2006 10:05:03 -0500 (EST) Subject: Hardware analysis tool (was Metrics: RFC) In-Reply-To: References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> Message-ID: So everyone agrees that this is a fabulous idea. Is there a concrete proposal ready to fall out of it -- something that we can hand to someone and say "hey, do this"? Here's what we've already got, and have had for ages: * the client-side bits that harvest the hardware data. They come from the up2date/rhn_register client... which is, yaaay! open source. Back in the day, this code was based on kudzu, and now I guess it's based on lshal. RHN basically formats this data and sends it via xmlrpc to RHN servers -- where, near as I can tell, it sits uselessly because no one has time to analyze the data. Here's what we need to get started: * A dead simple client. Maybe based on the RHN codebase, maybe not. Basically: "did your system work like a charm out of the box? Click A. Not so much? Click B." Format the data, send it up via xmlrpc, all done, thanks so much. * A dead simple xmlrpc server in the fp.o infrastructure that pulls this data and "does something with it". Probably the best thing is just to shove it into mysql. * A simple way of reporting on this data and making it visible. Generate a list of hardware and rank each item with a ratio of "found in good configurations" versus "found in bad configurations". The items at the top of the list will likely be the best. The items at the bottom of the list will likely be the worst. Really And For True, to get to version 0.1 of this beast is Not Much Work. What's required is someone who knows a little xmlrpc, a little sql, and is willing to take ownership of it. Perhaps this is a good thing to work on at our first-ever Fedora Hackfest, to be announced Real Soon Now (tm). --g On Wed, 22 Nov 2006, Jason L Tibbitts III wrote: >>>>>> "CB" == Christopher Blizzard writes: > > CB> If we are able to collect a set of hardware profiles for people, > CB> just after an install, and tie that to a unique machine > CB> identifier, we could make that really useful for people. The > CB> reason being that having access to information about what hardware > CB> people are really using allows us to know where we need to > CB> concentrate our efforts. > > I and I'm sure a good portion of Fedora users would happily install > a package that periodically sent various bits of info related to what > hardware is in the system, what packages are installed, what kernel is > currently running, etc. Such information could be immensely useful to > community packagers as a validation that their packages are actually > being used somewhere. > > There are all sorts of useful bits of information we could collect, > most of which require that some client be installed. I suggest that > this isn't a problem as long as: > > There's only one thing to install, not a collection of random > info-gathering clients. > > The client runs from cron and doesn't consume any memory when it's not > running. > > It is not installed by default. The installer can ask, sure. "Please > help us improve Fedora! Do you want to install the blahblah client?". > "Yes" should probably not be the default choice. (It could be > installed by default but not enabled by default, but even that is > probably pushing it. It's about the appearance of impropriety.) > > The list of information gathered is presented to the user somehow. An > option should be there to provide someone (root?) with a report of > everything sent in when it's sent in if someone really wants to know. > Updates to the package which provide new information-gathering plugins > should not cause those new plugins to be enabled without user > intervention. > > That's pretty much all the evil-minimization you can reasonably do. > The question is whether the response rate will be high enough and > whether the responses you get give you a statistically valid sample. > > - J< > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > -- ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From gdk at redhat.com Mon Nov 27 15:09:38 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Mon, 27 Nov 2006 10:09:38 -0500 (EST) Subject: Where is the position of FESCo/its successor now/during/after the merge In-Reply-To: <4564C62B.3080204@math.unl.edu> References: <4564B472.9080902@leemhuis.info> <4564C62B.3080204@math.unl.edu> Message-ID: Yes, Thorsten, I think you're spot on. --g On Wed, 22 Nov 2006, Rex Dieter wrote: > Thorsten Leemhuis wrote: >> Hi, >> >> it seems people are not completely sure (?) where the exact position and >> role of FESCo and its successor is now, during and after the merge with >> Core that was roughly outlined on the summit (and not yet official, but >> let's leave that fact out of here for now). Thus it might be a good idea >> to discuss this topic here to make sure we are all talking about the >> same stuff when we talk about FESCo and it's position in the future -- >> there is afaics no need to go to much into the details, just the rough >> direction should be enough for now afaics (I'll send out a more detailed >> proposal how I imagine the FESCo future after this discussion is over). >> >> I understood it like this until now: >> >> - Core Packages move over to Extras >> - Extras is renamed to something more generic -- let's name it "Fedora >> Package Collection (FPC)" here for now >> - FESCo will govern over all the packages and the rules around them; >> will likely get a new name, too; maybe new members >> - no Core, thus no Core cabal then; some/all people from it maybe get >> integrated into FESCo >> - the things that the Core cabal did and does (release process, bring >> the tree in shape for release, plan feature to work on or the next >> release, ...) somehow need to be done by FESCo then; probably by >> sub-committees/groups (or something like that) that report to FESCo >> - problematic topics can be moved to the Fedora Board for further >> discussion/guidance (no, don't go into discussing details about this >> just yet -- but we need that path probably) >> >> @Fedora Board: Is the above roughly correct? > > Your summary pretty much matches my expectations for the new FESCo. > > -- Rex > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > -- ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From fedora at leemhuis.info Mon Nov 27 15:28:39 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 27 Nov 2006 16:28:39 +0100 Subject: FESCo future In-Reply-To: <1164639497.24704.0.camel@cutter> References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> <456AFB96.8060400@leemhuis.info> <1164639497.24704.0.camel@cutter> Message-ID: <456B0427.2090302@leemhuis.info> seth vidal schrieb: > On Mon, 2006-11-27 at 15:52 +0100, Thorsten Leemhuis wrote: >> Hmm, all I wanted to avoid is that more than 50% of the members are from >> Red Hat as a lot of people won't like that. > Let's make sure that there is a mention that if a non-rh member takes a > job at rh that they don't lose their seat immediately. Only at the next > set of elections will their present employment be taken into account. > > does that reasonable? Hmm, that okay for me, but I suspect some people won't like it. I had something like the next para in my first local draft, but I threw it out before sending it to the list as I thought "not important enough" ;-) An additional non-rh member is appointed if a non-rh member gets a job at rh and due to that less than 50% of the seats would be filled by non-rh members. CU thl From gdk at redhat.com Mon Nov 27 15:38:18 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Mon, 27 Nov 2006 10:38:18 -0500 (EST) Subject: FESCo future In-Reply-To: References: <4569AB3D.6040007@leemhuis.info> <20061126185634.af549786.bugs.michael@gmx.net> Message-ID: +1 to Sopwith's post. :) --g On Sun, 26 Nov 2006, Elliot Lee wrote: > > On Nov 26, 2006, at 12:56 PM, Michael Schwendt wrote: > >>> FPCSC will needs to do what the "Core cabal" and FESCo do now and thus >>> will have a lot more work to do than FESCo currently does. Thus it might >>> be a good idea to make FPCSC a bit bigger. I'd say 14, 16 or 18 people >>> (FESCo currently has 13 members). >> >> FESCO's size is insufficient already. FESCO is not as productive as it >> could be if there were more members. Originally, FESCO had been created to >> form a small group of people who could get something done. Over time, >> FESCO has degraded to a collection of people, who fill seats in multiple >> committees and find themselves unable to pursue "FESCO business". > > Hey all, > > The rule of thumb for efficient team sizing is 7 people +/-. FESCO is too > big. Part of the reason people feel comfortable slacking on "FESCO business" > is because they think that with such a large group, it doesn't matter if they > slack off or not (see http://en.wikipedia.org/wiki/Social_loafing). Adding > more people to FESCO/FPCSC will just make things worse. > > In addition, FESCO's purpose should be for making decisions that can't be > made otherwise, not for being obligated to do all the work that needs doing. > If people outside FESCO are not feeling like they can make headway, FESCO > needs to get out of the way and empower those people, rather than trying to > add more responsibilities to a FESCO TODO list. > > Best, > -- Elliot > > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board -- ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From gdk at redhat.com Mon Nov 27 15:51:23 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Mon, 27 Nov 2006 10:51:23 -0500 (EST) Subject: FESCo future In-Reply-To: <456B0427.2090302@leemhuis.info> References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> <456AFB96.8060400@leemhuis.info> <1164639497.24704.0.camel@cutter> <456B0427.2090302@leemhuis.info> Message-ID: (Note: I will be calling this new project "F-star" until someone tells me to stop.) My $0.02 on the structure of the F-star board: No mandate of RH/non-RH seats. At all. Pure meritocracy. It's time to put this model to the test. If the packaging community has any sense, and I believe they do, then they will elect a healthy number of Redhatters to F-star -- because if they don't, it will be *much* more difficult to accomplish *anything*. It's in everyone's best interest to put Redhatters on the F-star board. I believe that the community understands that. At the same time, if a particular Redhatter becomes a belligerent jackass, then the community is fully empowered to boot that Redhatter right the hell out of the project. I don't expect this ever to be the case, honestly, because I think our community is comprised of grown-ups. But the safeguard is important. Honestly, we've already got strong controls at the Fedora Project Board level. If things go terribly wrong with F-Star, the process for correction is simple: the Grand Poobah puts a bullet in the whole damned thing. The cost of such a failure would be enormous for everyone involved, though, and for that reason I suspect that it will never happen. What are we afraid of? --g On Mon, 27 Nov 2006, Thorsten Leemhuis wrote: > seth vidal schrieb: >> On Mon, 2006-11-27 at 15:52 +0100, Thorsten Leemhuis wrote: >>> Hmm, all I wanted to avoid is that more than 50% of the members are from >>> Red Hat as a lot of people won't like that. >> Let's make sure that there is a mention that if a non-rh member takes a >> job at rh that they don't lose their seat immediately. Only at the next >> set of elections will their present employment be taken into account. >> >> does that reasonable? > > Hmm, that okay for me, but I suspect some people won't like it. I had > something like the next para in my first local draft, but I threw it out > before sending it to the list as I thought "not important enough" ;-) > > An additional non-rh member is appointed if a non-rh member gets a job > at rh and due to that less than 50% of the seats would be filled by > non-rh members. > > CU > thl > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > -- ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From gdk at redhat.com Mon Nov 27 15:59:46 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Mon, 27 Nov 2006 10:59:46 -0500 (EST) Subject: FESCo future In-Reply-To: References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> <456AFB96.8060400@leemhuis.info> <1164639497.24704.0.camel@cutter> <456B0427.2090302@leemhuis.info> Message-ID: And honestly, I use the word "honestly" way too much. Honestly. --g On Mon, 27 Nov 2006, Greg Dekoenigsberg wrote: > > (Note: I will be calling this new project "F-star" until someone tells me to > stop.) > > My $0.02 on the structure of the F-star board: > > No mandate of RH/non-RH seats. At all. Pure meritocracy. > > It's time to put this model to the test. If the packaging community has any > sense, and I believe they do, then they will elect a healthy number of > Redhatters to F-star -- because if they don't, it will be *much* more > difficult to accomplish *anything*. It's in everyone's best interest to put > Redhatters on the F-star board. I believe that the community understands > that. > > At the same time, if a particular Redhatter becomes a belligerent jackass, > then the community is fully empowered to boot that Redhatter right the hell > out of the project. I don't expect this ever to be the case, honestly, > because I think our community is comprised of grown-ups. But the safeguard > is important. > > Honestly, we've already got strong controls at the Fedora Project Board > level. If things go terribly wrong with F-Star, the process for correction > is simple: the Grand Poobah puts a bullet in the whole damned thing. The > cost of such a failure would be enormous for everyone involved, though, and > for that reason I suspect that it will never happen. > > What are we afraid of? > > --g > > On Mon, 27 Nov 2006, Thorsten Leemhuis wrote: > >> seth vidal schrieb: >>> On Mon, 2006-11-27 at 15:52 +0100, Thorsten Leemhuis wrote: >>>> Hmm, all I wanted to avoid is that more than 50% of the members are from >>>> Red Hat as a lot of people won't like that. >>> Let's make sure that there is a mention that if a non-rh member takes a >>> job at rh that they don't lose their seat immediately. Only at the next >>> set of elections will their present employment be taken into account. >>> >>> does that reasonable? >> >> Hmm, that okay for me, but I suspect some people won't like it. I had >> something like the next para in my first local draft, but I threw it out >> before sending it to the list as I thought "not important enough" ;-) >> >> An additional non-rh member is appointed if a non-rh member gets a job >> at rh and due to that less than 50% of the seats would be filled by >> non-rh members. >> >> CU >> thl >> >> _______________________________________________ >> fedora-advisory-board mailing list >> fedora-advisory-board at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-advisory-board >> > > -- ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From dennis at ausil.us Mon Nov 27 16:03:28 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 27 Nov 2006 10:03:28 -0600 Subject: FESCo future In-Reply-To: <456AFB96.8060400@leemhuis.info> References: <4569AB3D.6040007@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> <456AFB96.8060400@leemhuis.info> Message-ID: <200611271003.29132.dennis@ausil.us> On Monday 27 November 2006 08:52, Thorsten Leemhuis wrote: > > So did you mean we should have *exactly* 50% each Red Hat and non-Red > > Hat seats, as opposed to "at least 50% [non-Red Hat] community members"? > > No, if we run into 50% each Red Hat and non-Red Hat seats -- fine. If we > have 55% non-Red Hat seats vs 45% from Red Hat -- fine for me, too. All > I want to prevent is 45% non-Red Hat seats vs 55% from Red Hat ;) > > But I can also accept hardcoding 50% for both sides if people want that. > A uneven number of seats, too, if people prefer that. > I have to say i'm very against the no more than 50% Red Hat employees guideline. We are all the Fedora Community. Whoever steps and and gets voted in by the community should do the job. if the community votes against someone because of their employment so be it. no seats should be automatically filled by RH people. All seats should be 100% community voted upon. If in the event any person does not do their job of is not meeting the needs of the community then the board or the rest of the committee needs to censure them. along with some guidelines that if it continues you will be replaced. So if a Red Hat employee is being a continual problem and is taking a Red Hat needs this so we must do it approach they get censured by the committee, the board, their manager. I sure would not want a meeting with my manager if i were a Red Hat employee if i was kicked off or about to be Kicked off the steering committee. The Community CAN NOT be defined by Red Hat / Non Red Hat employment. for one thing people will swing both ways. for example Sopwith is no longer a Red Hat Employee but is still part of the community. Other community member have gone the other way. There are no sides. there is just one big pool of people. I will not accept any mandated percentage of people. it is a very good way to split the community. -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From skvidal at linux.duke.edu Mon Nov 27 16:37:14 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 27 Nov 2006 11:37:14 -0500 Subject: FESCo future In-Reply-To: References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> <456AFB96.8060400@leemhuis.info> <1164639497.24704.0.camel@cutter> <456B0427.2090302@leemhuis.info> Message-ID: <1164645434.24704.15.camel@cutter> On Mon, 2006-11-27 at 10:51 -0500, Greg Dekoenigsberg wrote: > (Note: I will be calling this new project "F-star" until someone tells me > to stop.) > > My $0.02 on the structure of the F-star board: > > No mandate of RH/non-RH seats. At all. Pure meritocracy. > > It's time to put this model to the test. If the packaging community has > any sense, and I believe they do, then they will elect a healthy number of > Redhatters to F-star -- because if they don't, it will be *much* more > difficult to accomplish *anything*. It's in everyone's best interest to > put Redhatters on the F-star board. I believe that the community > understands that. > > At the same time, if a particular Redhatter becomes a belligerent jackass, > then the community is fully empowered to boot that Redhatter right the > hell out of the project. I don't expect this ever to be the case, > honestly, because I think our community is comprised of grown-ups. But > the safeguard is important. > > Honestly, we've already got strong controls at the Fedora Project Board > level. If things go terribly wrong with F-Star, the process for > correction is simple: the Grand Poobah puts a bullet in the whole damned > thing. The cost of such a failure would be enormous for everyone > involved, though, and for that reason I suspect that it will never happen. > > What are we afraid of? > RHLP is what we're afraid of. If we have learned NOTHING from the goings on at novell and other companies it is that the winds of corporate power change quite a bit and it is not always obvious when they do. -sv From notting at redhat.com Mon Nov 27 16:40:22 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 11:40:22 -0500 Subject: Metrics: RFC In-Reply-To: <4568F07C.9020904@redhat.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> <4568F07C.9020904@redhat.com> Message-ID: <20061127164022.GE29814@nostromo.devel.redhat.com> Christopher Blizzard (blizzard at redhat.com) said: > Keeping in mind what we want to measure, I would guess that we have a > few things here: > > 1. Something that's run every time you change the kernel that can ask > users to run through a set of simple tests? Annoying, but maybe we can > only run it for 1/20 people and since we're just interested in > statistical information, that's enough. Think high level (external > monitor support, sound, suspend/resume, etc.) How often is this needed? I would think that when hardware *regresses*, we tend to hear about it fairly quickly. Bill From notting at redhat.com Mon Nov 27 16:44:44 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 11:44:44 -0500 Subject: Where is the position of FESCo/its successor now/during/after the merge In-Reply-To: <4564B472.9080902@leemhuis.info> References: <4564B472.9080902@leemhuis.info> Message-ID: <20061127164444.GF29814@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > I understood it like this until now: > > - Core Packages move over to Extras To the current Extras infrastructure, yes. I'm not sure if 'moved to Extras' is the right phrasing, given the below. (For example, the /pub/linux/extras dir will eventually become read-only, etc.) > - Extras is renamed to something more generic -- let's name it "Fedora > Package Collection (FPC)" here for now Probably not that. :) > - FESCo will govern over all the packages and the rules around them; > will likely get a new name, too; maybe new members Right. > - no Core, thus no Core cabal then; some/all people from it maybe get > integrated into FESCo There will almost certianly be a release team that will include some, if not all, of the same members. This could be responsible to FESCo, but I don't think all things (freeze schedules, package manifests, etc.) need to be pushed up to F*Sco directly. Of course, that's mostly what you said. For example, if we produce a Desktop spin, there would be a Desktop SIG more or less responsible for deciding what apps go in it, what's default, etc. Similarly for a Server spin. And there would be a release team responsible for them, consisting of (but not limited to) testing, rel-eng, etc. Bill From fedora at leemhuis.info Mon Nov 27 17:08:30 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 27 Nov 2006 18:08:30 +0100 Subject: FESCo future In-Reply-To: References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> <456AFB96.8060400@leemhuis.info> <1164639497.24704.0.camel@cutter> <456B0427.2090302@leemhuis.info> Message-ID: <456B1B8E.5040300@leemhuis.info> Greg Dekoenigsberg schrieb: > My $0.02 on the structure of the F-star board: > > No mandate of RH/non-RH seats. At all. Pure meritocracy. [...] Honestly I'd like to agree. I even think we can and should get rid of the proposed mandate or RH/non-RH seats in the future (two or three years from now mabye?). But we IMHO need it for now to really set a sign to the public: "We seriously want the community involved in Fedora. Thus to show our trust to the community we added this rule to make sure that they wil have certain influence in the central board that in the future will govern what was known as Fedora Core until now". CU Thorsten Honestly Leemhuis -- thl ;-) From gdk at redhat.com Mon Nov 27 17:10:15 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Mon, 27 Nov 2006 12:10:15 -0500 (EST) Subject: FESCo future In-Reply-To: <456B1B8E.5040300@leemhuis.info> References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> <456AFB96.8060400@leemhuis.info> <1164639497.24704.0.camel@cutter> <456B0427.2090302@leemhuis.info> <456B1B8E.5040300@leemhuis.info> Message-ID: On Mon, 27 Nov 2006, Thorsten Leemhuis wrote: > But we IMHO need it for now to really set a sign to the public: "We > seriously want the community involved in Fedora. Thus to show our trust > to the community we added this rule to make sure that they wil have > certain influence in the central board that in the future will govern > what was known as Fedora Core until now". Why not send that signal through an open election? --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From mmcgrath at fedoraproject.org Mon Nov 27 17:17:13 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 27 Nov 2006 11:17:13 -0600 Subject: FESCo future In-Reply-To: References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> <456AFB96.8060400@leemhuis.info> <1164639497.24704.0.camel@cutter> <456B0427.2090302@leemhuis.info> <456B1B8E.5040300@leemhuis.info> Message-ID: <3237e4410611270917uf23e045wc19f64d2d2087a4a@mail.gmail.com> On 11/27/06, Greg Dekoenigsberg wrote: > On Mon, 27 Nov 2006, Thorsten Leemhuis wrote: > > > But we IMHO need it for now to really set a sign to the public: "We > > seriously want the community involved in Fedora. Thus to show our trust > > to the community we added this rule to make sure that they wil have > > certain influence in the central board that in the future will govern > > what was known as Fedora Core until now". > > Why not send that signal through an open election? > > --g > Stuff like this becomes less of a worry if we focus on SIG's for various software packages/groups instead of a large all encompassing body. Groups like KDE, Gnome, java, PHP, etc could get their own SIG's and own repos. I'm not saying we should do this, but I do think we should look at doing it. -Mike From fedora at leemhuis.info Mon Nov 27 17:24:27 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 27 Nov 2006 18:24:27 +0100 Subject: FESCo future In-Reply-To: References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> <456AFB96.8060400@leemhuis.info> <1164639497.24704.0.camel@cutter> <456B0427.2090302@leemhuis.info> <456B1B8E.5040300@leemhuis.info> Message-ID: <456B1F4B.6070803@leemhuis.info> Greg Dekoenigsberg schrieb: > On Mon, 27 Nov 2006, Thorsten Leemhuis wrote: >> But we IMHO need it for now to really set a sign to the public: "We >> seriously want the community involved in Fedora. Thus to show our trust >> to the community we added this rule to make sure that they wil have >> certain influence in the central board that in the future will govern >> what was known as Fedora Core until now". > Why not send that signal through an open election? I think that's not enough for now as we did quite bad with setting the sign "we seriously want the community involved in Fedora" in the past years. CU thl From gdk at redhat.com Mon Nov 27 17:29:23 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Mon, 27 Nov 2006 12:29:23 -0500 (EST) Subject: FESCo future In-Reply-To: <3237e4410611270917uf23e045wc19f64d2d2087a4a@mail.gmail.com> References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> <456AFB96.8060400@leemhuis.info> <1164639497.24704.0.camel@cutter> <456B0427.2090302@leemhuis.info> <456B1B8E.5040300@leemhuis.info> <3237e4410611270917uf23e045wc19f64d2d2087a4a@mail.gmail.com> Message-ID: On Mon, 27 Nov 2006, Mike McGrath wrote: > Stuff like this becomes less of a worry if we focus on SIG's for > various software packages/groups instead of a large all encompassing > body. Groups like KDE, Gnome, java, PHP, etc could get their own > SIG's and own repos. I'm not saying we should do this, but I do think > we should look at doing it. Yeah, I think there's a lot of merit in this approach. The job of F-star should be to make sure that packages in Fedora are built properly, work together, and are properly maintained. This includes "release management" of F-star in its entirety, IMHO. The management of various "distros" that are derived from F-star should be individual Projects or SIGs. Fedora Desktop would be a Project. Fedora Games would be a SIG. Sounds good to me. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From gdk at redhat.com Mon Nov 27 17:33:23 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Mon, 27 Nov 2006 12:33:23 -0500 (EST) Subject: FESCo future In-Reply-To: <456B1F4B.6070803@leemhuis.info> References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> <456AFB96.8060400@leemhuis.info> <1164639497.24704.0.camel@cutter> <456B0427.2090302@leemhuis.info> <456B1B8E.5040300@leemhuis.info> <456B1F4B.6070803@leemhuis.info> Message-ID: On Mon, 27 Nov 2006, Thorsten Leemhuis wrote: >> Why not send that signal through an open election? > > I think that's not enough for now as we did quite bad with setting the > sign "we seriously want the community involved in Fedora" in the past years. Then, imho, we've got the same problem in reverse. Saying that "50% of the F-star board is guaranteed to be non-RH" is every bit as bad as saying that "50% of the F-star board is guaranteed to be RH." The people who do the work of building packages for Fedora decide what the governance of F-star is. Full stop. We shouldn't try to address problems of perception by making arbitrary decisions in the present. We should decide what is right, and do it. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From bpepple at fedoraproject.org Mon Nov 27 17:36:53 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 27 Nov 2006 12:36:53 -0500 Subject: FESCo future In-Reply-To: <200611271003.29132.dennis@ausil.us> References: <4569AB3D.6040007@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> <456AFB96.8060400@leemhuis.info> <200611271003.29132.dennis@ausil.us> Message-ID: <1164649013.5983.10.camel@Chuck> On Mon, 2006-11-27 at 10:03 -0600, Dennis Gilmore wrote: > I have to say i'm very against the no more than 50% Red Hat employees > guideline. We are all the Fedora Community. Whoever steps and and gets > voted in by the community should do the job. if the community votes against > someone because of their employment so be it. no seats should be > automatically filled by RH people. All seats should be 100% community voted > upon. If in the event any person does not do their job of is not meeting > the needs of the community then the board or the rest of the committee needs > to censure them. along with some guidelines that if it continues you will > be replaced. So if a Red Hat employee is being a continual problem and is > taking a Red Hat needs this so we must do it approach they get censured by > the committee, the board, their manager. I sure would not want a meeting > with my manager if i were a Red Hat employee if i was kicked off or about to > be Kicked off the steering committee. I agree with Dennis here. I don't really think we need to be setting a maximum percent of members that can be employed at Red Hat, as long as the community is voting on who gets the seats. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Mon Nov 27 17:46:03 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 27 Nov 2006 10:46:03 -0700 Subject: FESCo future In-Reply-To: References: <4569AB3D.6040007@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> <456AFB96.8060400@leemhuis.info> <1164639497.24704.0.camel@cutter> <456B0427.2090302@leemhuis.info> <456B1B8E.5040300@leemhuis.info> <456B1F4B.6070803@leemhuis.info> Message-ID: <80d7e4090611270946i15260761t50b50cc09ed30008@mail.gmail.com> On 11/27/06, Greg Dekoenigsberg wrote: > On Mon, 27 Nov 2006, Thorsten Leemhuis wrote: > > >> Why not send that signal through an open election? > > > > I think that's not enough for now as we did quite bad with setting the > > sign "we seriously want the community involved in Fedora" in the past years. > > Then, imho, we've got the same problem in reverse. Saying that "50% of > the F-star board is guaranteed to be non-RH" is every bit as bad as saying > that "50% of the F-star board is guaranteed to be RH." > > The people who do the work of building packages for Fedora decide what the > governance of F-star is. Full stop. > > We shouldn't try to address problems of perception by making arbitrary > decisions in the present. We should decide what is right, and do it. > If the problems do occur, then a parliamentary system could be the best 'solution'. The house of Red Hats are those that are appointed by the 'King' and the house of Blue Hats are those elected by the commons. The limits on what each house can do is up to the unwritten constitution :). -- 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 blizzard at redhat.com Mon Nov 27 17:47:22 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 27 Nov 2006 12:47:22 -0500 Subject: Metrics: RFC In-Reply-To: <20061127164022.GE29814@nostromo.devel.redhat.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> <4568F07C.9020904@redhat.com> <20061127164022.GE29814@nostromo.devel.redhat.com> Message-ID: <456B24AA.2080200@redhat.com> Bill Nottingham wrote: > Christopher Blizzard (blizzard at redhat.com) said: >> Keeping in mind what we want to measure, I would guess that we have a >> few things here: >> >> 1. Something that's run every time you change the kernel that can ask >> users to run through a set of simple tests? Annoying, but maybe we can >> only run it for 1/20 people and since we're just interested in >> statistical information, that's enough. Think high level (external >> monitor support, sound, suspend/resume, etc.) > > How often is this needed? I would think that when hardware > *regresses*, we tend to hear about it fairly quickly. > If I could point at something that said "between kernel version X and version Y we broke sound on all T42 laptops" that would get people hopping. And doing so in a way that doesn't require us to filter through a few hundred bug reports to be able to figure out that it's T42 users as opposed to X31 users. I'm talking about a way that makes our jobs faster and easier and lets us prove the impact (negative or otherwise!) on our user community. So, yeah, we have these mechanisms today. But they are manual and we're relatively slow to respond to them. (Not that we don't work hard - I'm just saying we could be _much_ better about getting information into the right people's hands.) --Chris From blizzard at redhat.com Mon Nov 27 17:55:09 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 27 Nov 2006 12:55:09 -0500 Subject: FESCo future In-Reply-To: References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> <456AFB96.8060400@leemhuis.info> <1164639497.24704.0.camel@cutter> <456B0427.2090302@leemhuis.info> Message-ID: <456B267D.1020209@redhat.com> Greg Dekoenigsberg wrote: > > (Note: I will be calling this new project "F-star" until someone tells > me to stop.) Not the Fedora Universe Committee? --Chris From tiemann at redhat.com Mon Nov 27 18:16:52 2006 From: tiemann at redhat.com (Michael Tiemann) Date: Mon, 27 Nov 2006 13:16:52 -0500 Subject: FESCo future In-Reply-To: <80d7e4090611270946i15260761t50b50cc09ed30008@mail.gmail.com> References: <4569AB3D.6040007@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> <456AFB96.8060400@leemhuis.info> <1164639497.24704.0.camel@cutter> <456B0427.2090302@leemhuis.info> <456B1B8E.5040300@leemhuis.info> <456B1F4B.6070803@leemhuis.info> <80d7e4090611270946i15260761t50b50cc09ed30008@mail.gmail.com> Message-ID: <1164651412.2142.20.camel@localhost.localdomain> On Mon, 2006-11-27 at 10:46 -0700, Stephen John Smoogen wrote: > If the problems do occur, then a parliamentary system could be the > best 'solution'. The house of Red Hats are those that are appointed by > the 'King' and the house of Blue Hats are those elected by the > commons. The limits on what each house can do is up to the unwritten > constitution :). I think you mean a "bicameral" system. New Zealand has a unicameral parliament. See http://en.wikipedia.org/wiki/Bicameral In any case, I believe that the chief advantage of a complex governing body is when there is so little trust of the governors that it is better for there to be not enough power with which to act rather than too much. I believe that the reason we such such stunning progress on things like the Linux kernel is that, among other things, the governing process is transparent and damn simple. I'd prefer to see a system that minimizes the amount of bureaucracy, given that we know there are plenty of people willing to actually do stuff. M From gdk at redhat.com Mon Nov 27 18:20:13 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Mon, 27 Nov 2006 13:20:13 -0500 (EST) Subject: FESCo future In-Reply-To: <1164651412.2142.20.camel@localhost.localdomain> References: <4569AB3D.6040007@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> <456AFB96.8060400@leemhuis.info> <1164639497.24704.0.camel@cutter> <456B0427.2090302@leemhuis.info> <456B1B8E.5040300@leemhuis.info> <456B1F4B.6070803@leemhuis.info> <80d7e4090611270946i15260761t50b50cc09ed30008@mail.gmail.com> <1164651412.2142.20.camel@localhost.localdomain> Message-ID: On Mon, 27 Nov 2006, Michael Tiemann wrote: > In any case, I believe that the chief advantage of a complex governing > body is when there is so little trust of the governors that it is better > for there to be not enough power with which to act rather than too much. > I believe that the reason we such such stunning progress on things like > the Linux kernel is that, among other things, the governing process is > transparent and damn simple. I'd prefer to see a system that minimizes > the amount of bureaucracy, given that we know there are plenty of people > willing to actually do stuff. Yeah! What he said! :) --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From notting at redhat.com Mon Nov 27 18:28:37 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 13:28:37 -0500 Subject: FESCo future In-Reply-To: <4569AB3D.6040007@leemhuis.info> References: <4569AB3D.6040007@leemhuis.info> Message-ID: <20061127182837.GD32187@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > * the Chair has veto rights -- that means the particular decision or > topic is transfered to the Fedora Project Board for further guidance and > considerations > > * two seats are special for a representative from the Community > Committee and a representative from Red Hat (see below for backgrounds > of these groups); both have veto rights, too; this positions are not > bound to special persons; it would be good if always the same persons > from the committee's shows up, but if they are not able to they can send > someone else from the committee as stand-in. Mm, this sets things up for all sorts of fun fights. > * at least 50% of the seats need to be filled by community members. ... > * have at least one fourth of their members from the community/from Red > Hat (exception: Red Hat/Community committees) How does mandated minimums lead to a meritocracy-style structure? (if you really want to use a loaded term, you could say 'quotas' here) Bill From notting at redhat.com Mon Nov 27 18:30:50 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 13:30:50 -0500 Subject: FESCo future In-Reply-To: <4569E475.2030708@leemhuis.info> References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> Message-ID: <20061127183050.GE32187@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > Well, I agree with that in general. But I suspect if we don't have a "at > leat xx% need to be non-redhatters" rule a lot of people will say "this > is just another round in the never ending Red Hat game where they say to > get the community involved without giving them rights". I'd like to > avoid that. Any better idea? Step up. Do. Take leadership. And you'll have a viable reason to get elected. :) Bill From notting at redhat.com Mon Nov 27 18:33:19 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 13:33:19 -0500 Subject: FESCo future In-Reply-To: <1164651412.2142.20.camel@localhost.localdomain> References: <456AFB96.8060400@leemhuis.info> <1164639497.24704.0.camel@cutter> <456B0427.2090302@leemhuis.info> <456B1B8E.5040300@leemhuis.info> <456B1F4B.6070803@leemhuis.info> <80d7e4090611270946i15260761t50b50cc09ed30008@mail.gmail.com> <1164651412.2142.20.camel@localhost.localdomain> Message-ID: <20061127183319.GF32187@nostromo.devel.redhat.com> Michael Tiemann (tiemann at redhat.com) said: > I think you mean a "bicameral" system. New Zealand has a unicameral > parliament. See http://en.wikipedia.org/wiki/Bicameral Those are the ones with two humps, right? Bill From gdk at redhat.com Mon Nov 27 18:38:44 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Mon, 27 Nov 2006 13:38:44 -0500 (EST) Subject: FESCo future In-Reply-To: <20061127183050.GE32187@nostromo.devel.redhat.com> References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <20061127183050.GE32187@nostromo.devel.redhat.com> Message-ID: >> Well, I agree with that in general. But I suspect if we don't have a "at >> leat xx% need to be non-redhatters" rule a lot of people will say "this >> is just another round in the never ending Red Hat game where they say to >> get the community involved without giving them rights". I'd like to >> avoid that. The rebuttal is simple. "All members of F-star are elected by the packaging community, the majority of whom do not work for Red Hat." When the truth is on your side, use it. The Fedora haters will not be convinced no matter what we say or do. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From fedora at leemhuis.info Mon Nov 27 18:21:44 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 27 Nov 2006 19:21:44 +0100 Subject: FESCo future In-Reply-To: References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <1164569157.26378.26.camel@localhost.localdomain> <456AFB96.8060400@leemhuis.info> <1164639497.24704.0.camel@cutter> <456B0427.2090302@leemhuis.info> <456B1B8E.5040300@leemhuis.info> <456B1F4B.6070803@leemhuis.info> Message-ID: <456B2CB8.7000501@leemhuis.info> Greg Dekoenigsberg schrieb: > On Mon, 27 Nov 2006, Thorsten Leemhuis wrote: >>> Why not send that signal through an open election? >> I think that's not enough for now as we did quite bad with setting the >> sign "we seriously want the community involved in Fedora" in the past years. > Then, imho, we've got the same problem in reverse. Saying that "50% of > the F-star board is guaranteed to be non-RH" is every bit as bad as saying > that "50% of the F-star board is guaranteed to be RH." Sure. I'm fine with that. Anyway, it seems more and more people come out of their holes that don't like the "50% for the community" idea and only a small number of people back it. So maybe let's forget about it, it was just and idea. Forgetting about it IMHO is acceptable as long as both the community and RH still have each one representative that can veto something (and thus moe the decision to the board). CU thl From skvidal at linux.duke.edu Mon Nov 27 18:48:13 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 27 Nov 2006 13:48:13 -0500 Subject: FESCo future In-Reply-To: References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <20061127183050.GE32187@nostromo.devel.redhat.com> Message-ID: <1164653293.24704.38.camel@cutter> On Mon, 2006-11-27 at 13:38 -0500, Greg Dekoenigsberg wrote: > >> Well, I agree with that in general. But I suspect if we don't have a "at > >> leat xx% need to be non-redhatters" rule a lot of people will say "this > >> is just another round in the never ending Red Hat game where they say to > >> get the community involved without giving them rights". I'd like to > >> avoid that. > > The rebuttal is simple. "All members of F-star are elected by the > packaging community, the majority of whom do not work for Red Hat." > > When the truth is on your side, use it. The Fedora haters will not be > convinced no matter what we say or do. > I'm not a fedora hater but I am a corporate distrust-er and I'm unconvinced that we're not extremely vulnerable to some 'pull it off the wire' bullshit like we HAVE seen in the past. how hard would it be for a executive at rh to tell all the RH members of whatever committee: - you will vote this way, you are not allowed to tell anyone why, and if you quit you're still bound by the NDA. -sv From gdk at redhat.com Mon Nov 27 18:53:25 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Mon, 27 Nov 2006 13:53:25 -0500 (EST) Subject: FESCo future In-Reply-To: <1164653293.24704.38.camel@cutter> References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <20061127183050.GE32187@nostromo.devel.redhat.com> <1164653293.24704.38.camel@cutter> Message-ID: On Mon, 27 Nov 2006, seth vidal wrote: > how hard would it be for a executive at rh to tell all the RH members of > whatever committee: > - you will vote this way, you are not allowed to tell anyone why, and > if you quit you're still bound by the NDA. Harder than you think, Seth, especially with the track history of relative success that Fedora has generated. I know where you're coming from, dude. I really do. But if RH tries to pull that, it won't go well. Why? Because RH is comprised of *people* who actually *give a shit* about this stuff. And besides, if a Red Hat executive goes for the nuclear option, Fedora will soon have all of the tools necessary to jettison itself, Redhatters or no Redhatters, NDAs or no NDAs. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From jwboyer at jdub.homelinux.org Mon Nov 27 18:54:45 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 27 Nov 2006 12:54:45 -0600 Subject: FESCo future In-Reply-To: <1164653293.24704.38.camel@cutter> References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <20061127183050.GE32187@nostromo.devel.redhat.com> <1164653293.24704.38.camel@cutter> Message-ID: <1164653685.31203.1.camel@vader.jdub.homelinux.org> On Mon, 2006-11-27 at 13:48 -0500, seth vidal wrote: > On Mon, 2006-11-27 at 13:38 -0500, Greg Dekoenigsberg wrote: > > >> Well, I agree with that in general. But I suspect if we don't have a "at > > >> leat xx% need to be non-redhatters" rule a lot of people will say "this > > >> is just another round in the never ending Red Hat game where they say to > > >> get the community involved without giving them rights". I'd like to > > >> avoid that. > > > > The rebuttal is simple. "All members of F-star are elected by the > > packaging community, the majority of whom do not work for Red Hat." > > > > When the truth is on your side, use it. The Fedora haters will not be > > convinced no matter what we say or do. > > > > I'm not a fedora hater but I am a corporate distrust-er and I'm > unconvinced that we're not extremely vulnerable to some 'pull it off the > wire' bullshit like we HAVE seen in the past. > > how hard would it be for a executive at rh to tell all the RH members of > whatever committee: > - you will vote this way, you are not allowed to tell anyone why, and > if you quit you're still bound by the NDA. You could prevent that by requiring all buildsys and repo storage bits be owned by someone other than RH. Including the netapp hosting, and domains, etc. Would be expensive, but then they have no recourse for "pulling it off the wire" because they don't own the wire. josh From blizzard at redhat.com Mon Nov 27 19:07:17 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 27 Nov 2006 14:07:17 -0500 Subject: FESCo future In-Reply-To: <1164653685.31203.1.camel@vader.jdub.homelinux.org> References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <20061127183050.GE32187@nostromo.devel.redhat.com> <1164653293.24704.38.camel@cutter> <1164653685.31203.1.camel@vader.jdub.homelinux.org> Message-ID: <456B3765.1050706@redhat.com> Josh Boyer wrote: > > You could prevent that by requiring all buildsys and repo storage bits > be owned by someone other than RH. Including the netapp hosting, and > domains, etc. > > Would be expensive, but then they have no recourse for "pulling it off > the wire" because they don't own the wire. I want to get to a world where the buildsys and repo storage bits are hosted with Red Hat only for convenience and reliability. Not control. That's part of this process. Push all the packages outside of the firewall, get the buildsystems out there, let people contribute buildsys "bandwith", give lesser arches their own way forward, etc. It's all down that path to moving RH to a 1st tier contributor, nothing more. However, I will note that "pulling something off the wire" is often done for sound legal reasons, not for biz reasons. Everyone involved in this discussion should be clearly delineating between the two. --Chris From notting at redhat.com Mon Nov 27 19:21:13 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 14:21:13 -0500 Subject: Metrics: RFC In-Reply-To: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> Message-ID: <20061127192113.GA976@nostromo.devel.redhat.com> Mike McGrath (mmcgrath at fedoraproject.org) said: > So I've compiled thoughts and issues we've come across with our first > round of metrics in FC6. and created a wiki page so we can actually > keep track of ideas. Its a wiki so add/alter stuff as you see fit. > > http://fedoraproject.org/wiki/Infrastructure/Metrics > > I've posed a similar question to the fedora-users list to see how the > community at large responds. > > https://www.redhat.com/archives/fedora-list/2006-November/msg05080.html > > Lets try to come to a conclusion as to the method we'd like to see > used in Fedora. What are your thoughts? I've gotten some mail from outside users directly to me about this after they read the wiki - do we want to have a specific pointer about where on the lists to discuss on the wiki page? Bill From mmcgrath at fedoraproject.org Mon Nov 27 19:53:07 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 27 Nov 2006 13:53:07 -0600 Subject: FESCo future In-Reply-To: <1164653293.24704.38.camel@cutter> References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <20061127183050.GE32187@nostromo.devel.redhat.com> <1164653293.24704.38.camel@cutter> Message-ID: <3237e4410611271153u1831aa58he64b6f953a57dc08@mail.gmail.com> On 11/27/06, seth vidal wrote: > On Mon, 2006-11-27 at 13:38 -0500, Greg Dekoenigsberg wrote: > I'm not a fedora hater but I am a corporate distrust-er and I'm > unconvinced that we're not extremely vulnerable to some 'pull it off the > wire' bullshit like we HAVE seen in the past. > > how hard would it be for a executive at rh to tell all the RH members of > whatever committee: > - you will vote this way, you are not allowed to tell anyone why, and > if you quit you're still bound by the NDA. > I've thought about this a bit too, honestly I think the only way to move forward is to trust the people you're working with. Be they IBM, Red Hat or some freshman in high school. If they've proven themselves, they've proven themselves. And even though people can do strange things when their job is on the line, we can always fork. -Mike From mmcgrath at fedoraproject.org Mon Nov 27 20:12:40 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 27 Nov 2006 14:12:40 -0600 Subject: Metrics: RFC In-Reply-To: <20061127192113.GA976@nostromo.devel.redhat.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <20061127192113.GA976@nostromo.devel.redhat.com> Message-ID: <3237e4410611271212r41dab47bgc6595087f281864a@mail.gmail.com> On 11/27/06, Bill Nottingham wrote: > Mike McGrath (mmcgrath at fedoraproject.org) said: > > So I've compiled thoughts and issues we've come across with our first > > round of metrics in FC6. and created a wiki page so we can actually > > keep track of ideas. Its a wiki so add/alter stuff as you see fit. > > > > http://fedoraproject.org/wiki/Infrastructure/Metrics > > > > I've posed a similar question to the fedora-users list to see how the > > community at large responds. > > > > https://www.redhat.com/archives/fedora-list/2006-November/msg05080.html > > > > Lets try to come to a conclusion as to the method we'd like to see > > used in Fedora. What are your thoughts? > > I've gotten some mail from outside users directly to me about this after > they read the wiki - do we want to have a specific pointer about where > on the lists to discuss on the wiki page? > > Bill > I'll add it right now. -Mike From dwmw2 at infradead.org Mon Nov 27 20:43:25 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 27 Nov 2006 20:43:25 +0000 Subject: Metrics: RFC In-Reply-To: <20061127192113.GA976@nostromo.devel.redhat.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <20061127192113.GA976@nostromo.devel.redhat.com> Message-ID: <1164660205.9174.39.camel@pmac.infradead.org> On Mon, 2006-11-27 at 14:21 -0500, Bill Nottingham wrote: > I've gotten some mail from outside users directly to me about this after > they read the wiki - do we want to have a specific pointer about where > on the lists to discuss on the wiki page? The totally unrealistic "20% of time; 1% of users" figure seems to have been quoted already. Can we rephrase that and hold off on the PPC witch-hunt please? -- dwmw2 From skvidal at linux.duke.edu Mon Nov 27 20:45:00 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 27 Nov 2006 15:45:00 -0500 Subject: FESCo future In-Reply-To: <3237e4410611271153u1831aa58he64b6f953a57dc08@mail.gmail.com> References: <4569AB3D.6040007@leemhuis.info> <1164565759.26160.12.camel@localhost.localdomain> <4569E475.2030708@leemhuis.info> <20061127183050.GE32187@nostromo.devel.redhat.com> <1164653293.24704.38.camel@cutter> <3237e4410611271153u1831aa58he64b6f953a57dc08@mail.gmail.com> Message-ID: <1164660300.24704.49.camel@cutter> On Mon, 2006-11-27 at 13:53 -0600, Mike McGrath wrote: > On 11/27/06, seth vidal wrote: > > On Mon, 2006-11-27 at 13:38 -0500, Greg Dekoenigsberg wrote: > > I'm not a fedora hater but I am a corporate distrust-er and I'm > > unconvinced that we're not extremely vulnerable to some 'pull it off the > > wire' bullshit like we HAVE seen in the past. > > > > how hard would it be for a executive at rh to tell all the RH members of > > whatever committee: > > - you will vote this way, you are not allowed to tell anyone why, and > > if you quit you're still bound by the NDA. > > > > I've thought about this a bit too, honestly I think the only way to > move forward is to trust the people you're working with. Be they IBM, > Red Hat or some freshman in high school. If they've proven > themselves, they've proven themselves. And even though people can do > strange things when their job is on the line, we can always fork. > Trust people? I'd be happy to trust 'people'. It is the legal documents they have signed that I do not trust. -sv From notting at redhat.com Mon Nov 27 20:44:04 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Nov 2006 15:44:04 -0500 Subject: Metrics: RFC In-Reply-To: <1164660205.9174.39.camel@pmac.infradead.org> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <20061127192113.GA976@nostromo.devel.redhat.com> <1164660205.9174.39.camel@pmac.infradead.org> Message-ID: <20061127204404.GA31836@nostromo.devel.redhat.com> David Woodhouse (dwmw2 at infradead.org) said: > On Mon, 2006-11-27 at 14:21 -0500, Bill Nottingham wrote: > > I've gotten some mail from outside users directly to me about this after > > they read the wiki - do we want to have a specific pointer about where > > on the lists to discuss on the wiki page? > > The totally unrealistic "20% of time; 1% of users" figure seems to have > been quoted already. Can we rephrase that and hold off on the PPC > witch-hunt please? Huh? Bill From dwmw2 at infradead.org Mon Nov 27 20:51:59 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 27 Nov 2006 20:51:59 +0000 Subject: Metrics: RFC In-Reply-To: <20061127204404.GA31836@nostromo.devel.redhat.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <20061127192113.GA976@nostromo.devel.redhat.com> <1164660205.9174.39.camel@pmac.infradead.org> <20061127204404.GA31836@nostromo.devel.redhat.com> Message-ID: <1164660719.9174.47.camel@pmac.infradead.org> On Mon, 2006-11-27 at 15:44 -0500, Bill Nottingham wrote: > David Woodhouse (dwmw2 at infradead.org) said: > > On Mon, 2006-11-27 at 14:21 -0500, Bill Nottingham wrote: > > > I've gotten some mail from outside users directly to me about this after > > > they read the wiki - do we want to have a specific pointer about where > > > on the lists to discuss on the wiki page? > > > > The totally unrealistic "20% of time; 1% of users" figure seems to have > > been quoted already. Can we rephrase that and hold off on the PPC > > witch-hunt please? > > Huh? http://lwn.net/Articles/211152/ quotes it thus: >> 'Back in October, LWN covered Fedora's need for metrics on how many >> people are using the distribution. The project has now put up a page >> on possible data collection techniques with a request for comments. >> Quite a few different approaches are being considered. "The fact is >> that metrics are important for anyone trying to do something with >> limited resources. It allows us to put what little resources we do >> have to better use. If the developers spend 20% of their time >> debugging PPC and our metrics show that they are 1% of our install >> base, the argument could be made that less time needs to be spent on >> PPC."' There's enough FUD about what a support burden PPC is already; we don't have to contribute to it with stuff like the above. The 20% figure is completely unrealistic, and we all know it -- the fact that it's presented as a hypothetical example doesn't really excuse the fact that it's given so prominently and quotably. Hence the request for it to be rephrased. -- dwmw2 From mmcgrath at fedoraproject.org Mon Nov 27 21:01:16 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 27 Nov 2006 15:01:16 -0600 Subject: Metrics: RFC In-Reply-To: <1164660719.9174.47.camel@pmac.infradead.org> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <20061127192113.GA976@nostromo.devel.redhat.com> <1164660205.9174.39.camel@pmac.infradead.org> <20061127204404.GA31836@nostromo.devel.redhat.com> <1164660719.9174.47.camel@pmac.infradead.org> Message-ID: <3237e4410611271301j1e7e57ffx6667d83193064156@mail.gmail.com> On 11/27/06, David Woodhouse wrote: > On Mon, 2006-11-27 at 15:44 -0500, Bill Nottingham wrote: > > David Woodhouse (dwmw2 at infradead.org) said: > > > On Mon, 2006-11-27 at 14:21 -0500, Bill Nottingham wrote: > > > > I've gotten some mail from outside users directly to me about this after > > > > they read the wiki - do we want to have a specific pointer about where > > > > on the lists to discuss on the wiki page? > > > > > > The totally unrealistic "20% of time; 1% of users" figure seems to have > > > been quoted already. Can we rephrase that and hold off on the PPC > > > witch-hunt please? > > s/PPC/x86_64/g -Mike From dwmw2 at infradead.org Mon Nov 27 21:20:50 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 27 Nov 2006 21:20:50 +0000 Subject: Metrics: RFC In-Reply-To: <3237e4410611271301j1e7e57ffx6667d83193064156@mail.gmail.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <20061127192113.GA976@nostromo.devel.redhat.com> <1164660205.9174.39.camel@pmac.infradead.org> <20061127204404.GA31836@nostromo.devel.redhat.com> <1164660719.9174.47.camel@pmac.infradead.org> <3237e4410611271301j1e7e57ffx6667d83193064156@mail.gmail.com> Message-ID: <1164662450.9174.60.camel@pmac.infradead.org> On Mon, 2006-11-27 at 15:01 -0600, Mike McGrath wrote: > s/PPC/x86_64/g Thanks. That doesn't actually make it any more realistic, but it does at least refrain from contributing to the apparent witch-hunt, so it doesn't matter much. It is, after all, only a hypothetical example. My objection to the original was because the thing about Fedora/PPC seems to be entirely based on the perceptions of those who don't actually _use_ Fedora on PowerPC; those who don't have much real experience to offset what they see elsewhere -- and that's why even such hypothetical examples are problematic because they serve to reinforce those opinions. Other things we might hope to learn, btw: - Which initscripts are actually _enabled_ (thus which d?mons are used) - Number of users added -- is it really used as a multi-user system? Those involve a more invasive method of collecting data though. -- dwmw2 From linux at elfshadow.net Sun Nov 26 01:49:17 2006 From: linux at elfshadow.net (Jeffrey Tadlock) Date: Sat, 25 Nov 2006 20:49:17 -0500 Subject: Metrics: RFC In-Reply-To: <4568EE9D.5000807@redhat.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> <3237e4410611232058p151c420u3ccc5566a98e1763@mail.gmail.com> <4568EE9D.5000807@redhat.com> Message-ID: <4568F29D.9050303@elfshadow.net> Christopher Blizzard wrote: > Is there a fedora-users thread? Do you have a url to it? Here is the start of it: https://www.redhat.com/archives/fedora-list/2006-November/msg05080.html --Jeffrey From fedora at leemhuis.info Tue Nov 28 17:42:34 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 28 Nov 2006 18:42:34 +0100 Subject: FESCo future In-Reply-To: <4569AB3D.6040007@leemhuis.info> References: <4569AB3D.6040007@leemhuis.info> Message-ID: <456C750A.6080608@leemhuis.info> Thorsten Leemhuis schrieb: > Well, with the proposed Core and Extras merge ( > http://www.fedoraproject.org/wiki/FedoraSummit/OpeningCore ) we need to > adjust FESCo to the new world order quite soon probably. Here are my > thoughts and a rough proposal how it could look like. Feedback much > appreciated. BTW, I send some earlier thoughts to the FESCo-list and > some people in private -- this proposal is a different one ;-) > [...] Okay, so how to continue with this after the first discussion is over? Will the board look at this discussion and give me/FESCo a bit of "official" Feedback how to proceed and/or what the Board would like to see for the future FESCo? Shall I post a updated proposal? Shall we simply wait until all the stuff discussed on the Summit becomes official before we further discuss this? CU thl From sundaram at fedoraproject.org Tue Nov 28 19:09:32 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 29 Nov 2006 00:39:32 +0530 Subject: Metrics: RFC In-Reply-To: <45647833.7090908@redhat.com> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> <3237e4410611220750g3e28adafxefcda19ff086fd56@mail.gmail.com> <20061122161109.GB29804@domsch.com> <456477D1.5090603@redhat.com> <45647833.7090908@redhat.com> Message-ID: <456C896C.7070606@fedoraproject.org> Christopher Blizzard wrote: > Christopher Blizzard wrote: >> >> Hmm, interesting. I wonder who wrote that. > > That's code for "I'm poking around to find the party responsible." > > --Chris > Did you find this? Rahul From blizzard at redhat.com Tue Nov 28 19:33:00 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 28 Nov 2006 14:33:00 -0500 Subject: Metrics: RFC In-Reply-To: <456C896C.7070606@fedoraproject.org> References: <3237e4410611211943x669c06f2t228e43dc72ae5843@mail.gmail.com> <45646F36.2010206@redhat.com> <3237e4410611220750g3e28adafxefcda19ff086fd56@mail.gmail.com> <20061122161109.GB29804@domsch.com> <456477D1.5090603@redhat.com> <45647833.7090908@redhat.com> <456C896C.7070606@fedoraproject.org> Message-ID: <456C8EEC.3030502@redhat.com> Rahul Sundaram wrote: > Christopher Blizzard wrote: >> Christopher Blizzard wrote: >>> >>> Hmm, interesting. I wonder who wrote that. >> >> That's code for "I'm poking around to find the party responsible." >> >> --Chris >> > > Did you find this? > > Rahul > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board Nope. --Chris From gdk at redhat.com Wed Nov 29 20:00:21 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 29 Nov 2006 15:00:21 -0500 (EST) Subject: FUDCon Boston 2007 Message-ID: An update: Working with the folks at BU to find space for a FUDCon that would go Friday/Saturday/Sunday... likely February 9-11, 2007. Shooting for a barcamp-style event on the Friday, with a hackfest on Saturday and Sunday. We're looking for Friday-Sunday, as opposed to Saturday-Monday, because classrooms are usually much more available on Fridays than on Mondays. More info as I have it. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From kwade at redhat.com Thu Nov 30 11:05:20 2006 From: kwade at redhat.com (Karsten Wade) Date: Thu, 30 Nov 2006 03:05:20 -0800 Subject: fun with naming Message-ID: <1164884721.2584.433.camel@erato.phig.org> On Sat, 2006-11-25 at 20:16 -0500, Christopher Blizzard wrote: > Thorsten Leemhuis wrote: > > - Core Packages move over to Extras > > - Extras is renamed to something more generic -- let's name it "Fedora > > Package Collection (FPC)" here for now > > I think I (we?) prefer Fedora Universe.[*] > > --Chris > > * We need to have more fun with our naming, I think. Bring the love back. Fedoration Fedora Utopia Fedoropia Fedora Soup Fedora Stew :) -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Thu Nov 30 11:24:30 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 30 Nov 2006 12:24:30 +0100 Subject: fun with naming In-Reply-To: <1164884721.2584.433.camel@erato.phig.org> References: <1164884721.2584.433.camel@erato.phig.org> Message-ID: <456EBF6E.9090200@leemhuis.info> Karsten Wade schrieb: > On Sat, 2006-11-25 at 20:16 -0500, Christopher Blizzard wrote: >> Thorsten Leemhuis wrote: >>> - Core Packages move over to Extras >>> - Extras is renamed to something more generic -- let's name it "Fedora >>> Package Collection (FPC)" here for now >> I think I (we?) prefer Fedora Universe.[*] >> --Chris >> * We need to have more fun with our naming, I think. Bring the love back. > Fedoration > Fedora Utopia > Fedoropia > Fedora Soup > Fedora Stew Fedora Biotope Fedora Ecosystem And stolen from Luya's blog (http://thefinalzone.blogspot.com/2006/11/name-for-future-fedora-distribution.html): Fedora Synergy CU thl From blizzard at redhat.com Thu Nov 30 12:13:02 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 30 Nov 2006 07:13:02 -0500 Subject: fun with naming In-Reply-To: <1164884721.2584.433.camel@erato.phig.org> References: <1164884721.2584.433.camel@erato.phig.org> Message-ID: <456ECACE.7030809@redhat.com> Karsten Wade wrote: > On Sat, 2006-11-25 at 20:16 -0500, Christopher Blizzard wrote: >> Thorsten Leemhuis wrote: >>> - Core Packages move over to Extras >>> - Extras is renamed to something more generic -- let's name it "Fedora >>> Package Collection (FPC)" here for now >> I think I (we?) prefer Fedora Universe.[*] >> >> --Chris >> >> * We need to have more fun with our naming, I think. Bring the love back. > > Fedoration > Fedora Utopia > Fedoropia > Fedora Soup > Fedora Stew I think everyone missed the acronym. :) --Chris From jkeating at redhat.com Thu Nov 30 13:06:30 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 30 Nov 2006 08:06:30 -0500 Subject: fun with naming In-Reply-To: <1164884721.2584.433.camel@erato.phig.org> References: <1164884721.2584.433.camel@erato.phig.org> Message-ID: <200611300806.37285.jkeating@redhat.com> On Thursday 30 November 2006 06:05, Karsten Wade wrote: > Fedoration > Fedora Utopia > Fedoropia > Fedora Soup > Fedora Stew Fedora Freeverse Fedora Freedome Fedora Foundation (the packages are just the base part of the project...) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From blizzard at redhat.com Thu Nov 30 13:08:36 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 30 Nov 2006 08:08:36 -0500 Subject: fun with naming In-Reply-To: <200611300806.37285.jkeating@redhat.com> References: <1164884721.2584.433.camel@erato.phig.org> <200611300806.37285.jkeating@redhat.com> Message-ID: <456ED7D4.8040009@redhat.com> Jesse Keating wrote: > Fedora Freeverse > Fedora Freedome Two packages enter! One package leaves! > Fedora Foundation (the packages are just the base part of the project...) The return of the Foundation? I can just imagine the osnews article now. --Chris From barzilay at redhat.com Thu Nov 30 13:28:04 2006 From: barzilay at redhat.com (David Barzilay) Date: Thu, 30 Nov 2006 11:28:04 -0200 Subject: fun with naming In-Reply-To: <456EBF6E.9090200@leemhuis.info> References: <1164884721.2584.433.camel@erato.phig.org> <456EBF6E.9090200@leemhuis.info> Message-ID: <456EDC64.9080605@redhat.com> Thorsten Leemhuis wrote: > Karsten Wade schrieb: >> On Sat, 2006-11-25 at 20:16 -0500, Christopher Blizzard wrote: >>> Thorsten Leemhuis wrote: >>>> - Core Packages move over to Extras >>>> - Extras is renamed to something more generic -- let's name it "Fedora >>>> Package Collection (FPC)" here for now >>> I think I (we?) prefer Fedora Universe.[*] >>> --Chris >>> * We need to have more fun with our naming, I think. Bring the love >>> back. >> Fedoration >> Fedora Utopia >> Fedoropia >> Fedora Soup >> Fedora Stew > > Fedora Biotope > Fedora Ecosystem > > And stolen from Luya's blog > (http://thefinalzone.blogspot.com/2006/11/name-for-future-fedora-distribution.html): > > Fedora Synergy Fedora Base Fedora Basis Fedora Center Central Fedora These names would facilitate recognition in other languages (mainly the latin-based ones) and could even remain the same. -------------- next part -------------- A non-text attachment was scrubbed... Name: barzilay.vcf Type: text/x-vcard Size: 390 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Thu Nov 30 13:32:12 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 30 Nov 2006 07:32:12 -0600 Subject: fun with naming In-Reply-To: <1164884721.2584.433.camel@erato.phig.org> References: <1164884721.2584.433.camel@erato.phig.org> Message-ID: <1164893533.28480.8.camel@zod.rchland.ibm.com> On Thu, 2006-11-30 at 03:05 -0800, Karsten Wade wrote: > On Sat, 2006-11-25 at 20:16 -0500, Christopher Blizzard wrote: > > Thorsten Leemhuis wrote: > > > - Core Packages move over to Extras > > > - Extras is renamed to something more generic -- let's name it "Fedora > > > Package Collection (FPC)" here for now > > > > I think I (we?) prefer Fedora Universe.[*] > > > > --Chris > > > > * We need to have more fun with our naming, I think. Bring the love back. Why can't we just call it Fedora (or Fedora Linux)? josh From fedora at leemhuis.info Thu Nov 30 13:53:17 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 30 Nov 2006 14:53:17 +0100 Subject: fun with naming In-Reply-To: <1164893533.28480.8.camel@zod.rchland.ibm.com> References: <1164884721.2584.433.camel@erato.phig.org> <1164893533.28480.8.camel@zod.rchland.ibm.com> Message-ID: <456EE24D.4010607@leemhuis.info> Josh Boyer schrieb: > On Thu, 2006-11-30 at 03:05 -0800, Karsten Wade wrote: >> On Sat, 2006-11-25 at 20:16 -0500, Christopher Blizzard wrote: >>> Thorsten Leemhuis wrote: >>>> - Core Packages move over to Extras >>>> - Extras is renamed to something more generic -- let's name it "Fedora >>>> Package Collection (FPC)" here for now >>> I think I (we?) prefer Fedora Universe.[*] >>> * We need to have more fun with our naming, I think. Bring the love back. > Why can't we just call it Fedora Maybe we do "Fedora Solaris" one day? Or "Fedora Music"? Or even "Fedora "? I think we should leave this door open for the future. > (or Fedora Linux)? Fedora Linux would be fine, too, but we had that "Do we have to call in Fedora GNU/Linux" debate already... CU thl From jkeating at redhat.com Thu Nov 30 13:54:49 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 30 Nov 2006 08:54:49 -0500 Subject: fun with naming In-Reply-To: <200611300806.37285.jkeating@redhat.com> References: <1164884721.2584.433.camel@erato.phig.org> <200611300806.37285.jkeating@redhat.com> Message-ID: <200611300854.49304.jkeating@redhat.com> On Thursday 30 November 2006 08:06, Jesse Keating wrote: > Fedora Freeverse > Fedora Freedome > Fedora Foundation (the packages are just the base part of the project...) Fedora Finity -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at fedoraproject.org Thu Nov 30 14:12:21 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 30 Nov 2006 08:12:21 -0600 Subject: fun with naming In-Reply-To: <200611300854.49304.jkeating@redhat.com> References: <1164884721.2584.433.camel@erato.phig.org> <200611300806.37285.jkeating@redhat.com> <200611300854.49304.jkeating@redhat.com> Message-ID: <3237e4410611300612p569f0a2ct12a8a121d28aa95@mail.gmail.com> On 11/30/06, Jesse Keating wrote: > On Thursday 30 November 2006 08:06, Jesse Keating wrote: > > Fedora Freeverse > > Fedora Freedome > > Fedora Foundation (the packages are just the base part of the project...) > > Fedora Finity > FU-buntu? -Mike From gdk at redhat.com Thu Nov 30 14:21:17 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Thu, 30 Nov 2006 09:21:17 -0500 (EST) Subject: fun with naming In-Reply-To: <456ED7D4.8040009@redhat.com> References: <1164884721.2584.433.camel@erato.phig.org> <200611300806.37285.jkeating@redhat.com> <456ED7D4.8040009@redhat.com> Message-ID: Fedora Star. F-Star. With a spiffy new graphic treatment around F*. --g On Thu, 30 Nov 2006, Christopher Blizzard wrote: > Jesse Keating wrote: >> Fedora Freeverse >> Fedora Freedome > > Two packages enter! One package leaves! > >> Fedora Foundation (the packages are just the base part of the project...) > > The return of the Foundation? I can just imagine the osnews article now. > > --Chris > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > -- ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From chitlesh at fedoraproject.org Thu Nov 30 15:03:43 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 30 Nov 2006 16:03:43 +0100 Subject: fun with naming In-Reply-To: <1164893533.28480.8.camel@zod.rchland.ibm.com> References: <1164884721.2584.433.camel@erato.phig.org> <1164893533.28480.8.camel@zod.rchland.ibm.com> Message-ID: <13dbfe4f0611300703j67db0b88pf3ce5823ba593edb@mail.gmail.com> On 11/30/06, Josh Boyer < hidden > wrote: > > Why can't we just call it Fedora (or Fedora Linux)? > +1 for Fedora chitlesh -- http://clunixchit.blogspot.com From dennis at ausil.us Thu Nov 30 15:10:26 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 30 Nov 2006 09:10:26 -0600 Subject: fun with naming In-Reply-To: <456EE24D.4010607@leemhuis.info> References: <1164884721.2584.433.camel@erato.phig.org> <1164893533.28480.8.camel@zod.rchland.ibm.com> <456EE24D.4010607@leemhuis.info> Message-ID: <200611300910.26592.dennis@ausil.us> On Thursday 30 November 2006 07:53, Thorsten Leemhuis wrote: > Josh Boyer schrieb: > > (or Fedora Linux)? > > Fedora Linux would be fine, too, but we had that "Do we have to call in > Fedora GNU/Linux" debate already... I personally like Fedora Linux -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From jkeating at redhat.com Thu Nov 30 15:29:45 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 30 Nov 2006 10:29:45 -0500 Subject: fun with naming In-Reply-To: <200611300910.26592.dennis@ausil.us> References: <1164884721.2584.433.camel@erato.phig.org> <456EE24D.4010607@leemhuis.info> <200611300910.26592.dennis@ausil.us> Message-ID: <200611301029.46041.jkeating@redhat.com> On Thursday 30 November 2006 10:10, Dennis Gilmore wrote: > I personally like Fedora Linux Fedora Linux makes sense for release names, say Fedora (Gnome) Desktop Linux, or Fedora Server Linux. However the massive collection of packages should have a different term, that is kernel/platform agnostic. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Thu Nov 30 16:03:03 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 30 Nov 2006 10:03:03 -0600 Subject: fun with naming In-Reply-To: <200611301029.46041.jkeating@redhat.com> References: <1164884721.2584.433.camel@erato.phig.org> <456EE24D.4010607@leemhuis.info> <200611300910.26592.dennis@ausil.us> <200611301029.46041.jkeating@redhat.com> Message-ID: <1164902583.5065.1.camel@zod.rchland.ibm.com> On Thu, 2006-11-30 at 10:29 -0500, Jesse Keating wrote: > On Thursday 30 November 2006 10:10, Dennis Gilmore wrote: > > I personally like Fedora Linux > > Fedora Linux makes sense for release names, say Fedora (Gnome) Desktop Linux, > or Fedora Server Linux. However the massive collection of packages should > have a different term, that is kernel/platform agnostic. The Fedora works just fine. josh From jkeating at redhat.com Thu Nov 30 16:09:13 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 30 Nov 2006 11:09:13 -0500 Subject: fun with naming In-Reply-To: <1164902583.5065.1.camel@zod.rchland.ibm.com> References: <1164884721.2584.433.camel@erato.phig.org> <200611301029.46041.jkeating@redhat.com> <1164902583.5065.1.camel@zod.rchland.ibm.com> Message-ID: <200611301109.13461.jkeating@redhat.com> On Thursday 30 November 2006 11:03, Josh Boyer wrote: > The Fedora works just fine. Fedora is the project name, that is much more than just the distribution or just the package set. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From amaier at redhat.com Thu Nov 30 16:28:23 2006 From: amaier at redhat.com (Alex Maier) Date: Thu, 30 Nov 2006 11:28:23 -0500 Subject: fun with naming In-Reply-To: <1164902583.5065.1.camel@zod.rchland.ibm.com> References: <1164884721.2584.433.camel@erato.phig.org> <456EE24D.4010607@leemhuis.info> <200611300910.26592.dennis@ausil.us> <200611301029.46041.jkeating@redhat.com> <1164902583.5065.1.camel@zod.rchland.ibm.com> Message-ID: <1164904103.4388.45.camel@localhost.localdomain> What happened to the "Fedora Project"? "Project" can include any number of things -- a bunch of packages, among other things. From notting at redhat.com Thu Nov 30 16:32:21 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 30 Nov 2006 11:32:21 -0500 Subject: fun with naming In-Reply-To: <1164893533.28480.8.camel@zod.rchland.ibm.com> References: <1164884721.2584.433.camel@erato.phig.org> <1164893533.28480.8.camel@zod.rchland.ibm.com> Message-ID: <20061130163221.GB23978@nostromo.devel.redhat.com> Josh Boyer (jwboyer at jdub.homelinux.org) said: > Why can't we just call it Fedora (or Fedora Linux)? As for just Fedora, there are going to be multiple spins - a server spin, a desktop spin, a KDE spin, etc. - so *just* Fedora probably doesn't make sense for the grand conglomeration of everything. Bill From mmcgrath at fedoraproject.org Thu Nov 30 16:32:20 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 30 Nov 2006 10:32:20 -0600 Subject: fun with naming In-Reply-To: <1164904103.4388.45.camel@localhost.localdomain> References: <1164884721.2584.433.camel@erato.phig.org> <456EE24D.4010607@leemhuis.info> <200611300910.26592.dennis@ausil.us> <200611301029.46041.jkeating@redhat.com> <1164902583.5065.1.camel@zod.rchland.ibm.com> <1164904103.4388.45.camel@localhost.localdomain> Message-ID: <3237e4410611300832m6121ff5r720f74572d7acb6d@mail.gmail.com> On 11/30/06, Alex Maier wrote: > What happened to the "Fedora Project"? > "Project" can include any number of things -- a bunch of packages, among > other things. > The Fedora Project refers to the community that produces goods, not the goods produced by the community. -Mike From gdk at redhat.com Thu Nov 30 16:51:49 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Thu, 30 Nov 2006 11:51:49 -0500 (EST) Subject: fun with naming In-Reply-To: <1164904103.4388.45.camel@localhost.localdomain> References: <1164884721.2584.433.camel@erato.phig.org> <456EE24D.4010607@leemhuis.info> <200611300910.26592.dennis@ausil.us> <200611301029.46041.jkeating@redhat.com> <1164902583.5065.1.camel@zod.rchland.ibm.com> <1164904103.4388.45.camel@localhost.localdomain> Message-ID: Sigh. We're talking about a *very specific problem*: naming the Universe of Packages Build by the Fedora Project. "The Fedora Project" is the umbrella for everything that Fedora does. "Fedora" is a brand name that is attached to things that say "this is sponsored by the Fedora community". We need a way to say "this entity is a collection of all the packages that can be used to build distributions based on Fedora." And it can't just be "Fedora", and it can't be "Fedora Linux". "Fedora Universe" is close, but problematic for a couple of reasons. "Fedora Star" is maybe too clever. But again: it's about the packages. Hell, maybe it's just "the Fedora Packaging Project". Sometimes it's best to call it what it is. --g On Thu, 30 Nov 2006, Alex Maier wrote: > What happened to the "Fedora Project"? > "Project" can include any number of things -- a bunch of packages, among > other things. > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > -- ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From barzilay at redhat.com Thu Nov 30 16:56:40 2006 From: barzilay at redhat.com (David Barzilay) Date: Thu, 30 Nov 2006 14:56:40 -0200 Subject: fun with naming In-Reply-To: References: <1164884721.2584.433.camel@erato.phig.org> <456EE24D.4010607@leemhuis.info> <200611300910.26592.dennis@ausil.us> <200611301029.46041.jkeating@redhat.com> <1164902583.5065.1.camel@zod.rchland.ibm.com> <1164904103.4388.45.camel@localhost.localdomain> Message-ID: <456F0D48.1030804@redhat.com> What about "Fedora Pack"? Greg Dekoenigsberg wrote: > > Sigh. > > We're talking about a *very specific problem*: naming the Universe of > Packages Build by the Fedora Project. > > "The Fedora Project" is the umbrella for everything that Fedora does. > > "Fedora" is a brand name that is attached to things that say "this is > sponsored by the Fedora community". > > We need a way to say "this entity is a collection of all the packages > that can be used to build distributions based on Fedora." And it > can't just be "Fedora", and it can't be "Fedora Linux". > > "Fedora Universe" is close, but problematic for a couple of reasons. > "Fedora Star" is maybe too clever. > > But again: it's about the packages. Hell, maybe it's just "the Fedora > Packaging Project". Sometimes it's best to call it what it is. > > --g > > On Thu, 30 Nov 2006, Alex Maier wrote: > >> What happened to the "Fedora Project"? >> "Project" can include any number of things -- a bunch of packages, among >> other things. >> >> _______________________________________________ >> 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: barzilay.vcf Type: text/x-vcard Size: 390 bytes Desc: not available URL: From notting at redhat.com Thu Nov 30 17:03:55 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 30 Nov 2006 12:03:55 -0500 Subject: fun with naming In-Reply-To: References: <1164884721.2584.433.camel@erato.phig.org> <456EE24D.4010607@leemhuis.info> <200611300910.26592.dennis@ausil.us> <200611301029.46041.jkeating@redhat.com> <1164902583.5065.1.camel@zod.rchland.ibm.com> <1164904103.4388.45.camel@localhost.localdomain> Message-ID: <20061130170355.GB24367@nostromo.devel.redhat.com> Greg Dekoenigsberg (gdk at redhat.com) said: > But again: it's about the packages. Hell, maybe it's just "the Fedora > Packaging Project". Sometimes it's best to call it what it is. I must resist the obvious joke, and just note that that's rather boring. "The Fedora Project announces the eleventy-seventh release of the Fedora Packaging Project"? It really doesn't flow. Bill From rdieter at math.unl.edu Thu Nov 30 17:08:48 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 30 Nov 2006 11:08:48 -0600 Subject: fun with naming In-Reply-To: References: <1164884721.2584.433.camel@erato.phig.org> <456EE24D.4010607@leemhuis.info> <200611300910.26592.dennis@ausil.us> <200611301029.46041.jkeating@redhat.com> <1164902583.5065.1.camel@zod.rchland.ibm.com> <1164904103.4388.45.camel@localhost.localdomain> Message-ID: <456F1020.60804@math.unl.edu> Greg Dekoenigsberg wrote: > But again: it's about the packages. Hell, maybe it's just "the Fedora > Packaging Project". Sometimes it's best to call it what it is. Maybe recycle the codename(?) for each release and call the collection Fedora ? For example, Fedora Core 6 could have been (just): Fedora Zod -- Rex From mmcgrath at fedoraproject.org Thu Nov 30 17:09:04 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 30 Nov 2006 11:09:04 -0600 Subject: fun with naming In-Reply-To: References: <1164884721.2584.433.camel@erato.phig.org> <456EE24D.4010607@leemhuis.info> <200611300910.26592.dennis@ausil.us> <200611301029.46041.jkeating@redhat.com> <1164902583.5065.1.camel@zod.rchland.ibm.com> <1164904103.4388.45.camel@localhost.localdomain> Message-ID: <3237e4410611300909y322809c2s37977b12001e48d3@mail.gmail.com> On 11/30/06, Greg Dekoenigsberg wrote: > > "Fedora Universe" is close, but problematic for a couple of reasons. > "Fedora Star" is maybe too clever. Fedora Nova? From tibbs at math.uh.edu Thu Nov 30 17:11:03 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 Nov 2006 11:11:03 -0600 Subject: fun with naming In-Reply-To: <3237e4410611300909y322809c2s37977b12001e48d3@mail.gmail.com> References: <1164884721.2584.433.camel@erato.phig.org> <456EE24D.4010607@leemhuis.info> <200611300910.26592.dennis@ausil.us> <200611301029.46041.jkeating@redhat.com> <1164902583.5065.1.camel@zod.rchland.ibm.com> <1164904103.4388.45.camel@localhost.localdomain> <3237e4410611300909y322809c2s37977b12001e48d3@mail.gmail.com> Message-ID: "The Haberdashery". - J< From notting at redhat.com Thu Nov 30 17:10:35 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 30 Nov 2006 12:10:35 -0500 Subject: fun with naming In-Reply-To: <456F1020.60804@math.unl.edu> References: <1164884721.2584.433.camel@erato.phig.org> <456EE24D.4010607@leemhuis.info> <200611300910.26592.dennis@ausil.us> <200611301029.46041.jkeating@redhat.com> <1164902583.5065.1.camel@zod.rchland.ibm.com> <1164904103.4388.45.camel@localhost.localdomain> <456F1020.60804@math.unl.edu> Message-ID: <20061130171035.GA24743@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > Greg Dekoenigsberg wrote: > > >But again: it's about the packages. Hell, maybe it's just "the Fedora > >Packaging Project". Sometimes it's best to call it what it is. > > Maybe recycle the codename(?) for each release and call the collection > Fedora ? For example, Fedora Core 6 could have been (just): > Fedora Zod But then we'd have to use them longer in association with other things, i.e. "I just upgraded my box from Limbo to Zod and now it doesn't work!" and those on the other end of #fedora/fedora-list/bugzilla would either have to a) remember this stuff b) look it up before responding "Upgrading from *Limbo*? Are you crazy?" Bill From jkeating at redhat.com Thu Nov 30 17:14:31 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 30 Nov 2006 12:14:31 -0500 Subject: fun with naming In-Reply-To: <3237e4410611300909y322809c2s37977b12001e48d3@mail.gmail.com> References: <1164884721.2584.433.camel@erato.phig.org> <3237e4410611300909y322809c2s37977b12001e48d3@mail.gmail.com> Message-ID: <200611301214.31862.jkeating@redhat.com> On Thursday 30 November 2006 12:09, Mike McGrath wrote: > Fedora Nova? I think "Nova" translates pretty poorly, see the Chevy Nova. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Thu Nov 30 17:21:30 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 30 Nov 2006 12:21:30 -0500 Subject: fun with naming In-Reply-To: References: <1164884721.2584.433.camel@erato.phig.org> <456EE24D.4010607@leemhuis.info> <200611300910.26592.dennis@ausil.us> <200611301029.46041.jkeating@redhat.com> <1164902583.5065.1.camel@zod.rchland.ibm.com> <1164904103.4388.45.camel@localhost.localdomain> Message-ID: <20061130172130.GC24807@nostromo.devel.redhat.com> Greg Dekoenigsberg (gdk at redhat.com) said: > "Fedora Universe" is close, but problematic for a couple of reasons. > "Fedora Star" is maybe too clever. Fedora Supercalifragilisticexpialidocious? Bill From gdk at redhat.com Thu Nov 30 18:07:33 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Thu, 30 Nov 2006 13:07:33 -0500 (EST) Subject: fun with naming In-Reply-To: <200611301214.31862.jkeating@redhat.com> References: <1164884721.2584.433.camel@erato.phig.org> <3237e4410611300909y322809c2s37977b12001e48d3@mail.gmail.com> <200611301214.31862.jkeating@redhat.com> Message-ID: On Thu, 30 Nov 2006, Jesse Keating wrote: > I think "Nova" translates pretty poorly, see the Chevy Nova. Bzzt. Urban legend, kemosabe: http://www.snopes.com/business/misxlate/nova.asp Not that I think the "Nova" name is good or bad -- but we can't use the ol' Chevy Nova defense anymore. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From skvidal at linux.duke.edu Thu Nov 30 19:09:35 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 30 Nov 2006 14:09:35 -0500 Subject: fun with naming In-Reply-To: <20061130172130.GC24807@nostromo.devel.redhat.com> References: <1164884721.2584.433.camel@erato.phig.org> <456EE24D.4010607@leemhuis.info> <200611300910.26592.dennis@ausil.us> <200611301029.46041.jkeating@redhat.com> <1164902583.5065.1.camel@zod.rchland.ibm.com> <1164904103.4388.45.camel@localhost.localdomain> <20061130172130.GC24807@nostromo.devel.redhat.com> Message-ID: <1164913775.10923.4.camel@cutter> On Thu, 2006-11-30 at 12:21 -0500, Bill Nottingham wrote: > Greg Dekoenigsberg (gdk at redhat.com) said: > > "Fedora Universe" is close, but problematic for a couple of reasons. > > "Fedora Star" is maybe too clever. > > Fedora Supercalifragilisticexpialidocious? > Fedora Jazzhands! -sv From fedora at leemhuis.info Thu Nov 30 19:45:27 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 30 Nov 2006 20:45:27 +0100 Subject: fun with naming In-Reply-To: References: <1164884721.2584.433.camel@erato.phig.org> <3237e4410611300909y322809c2s37977b12001e48d3@mail.gmail.com> <200611301214.31862.jkeating@redhat.com> Message-ID: <456F34D7.2080901@leemhuis.info> Greg Dekoenigsberg schrieb: > On Thu, 30 Nov 2006, Jesse Keating wrote: >> I think "Nova" translates pretty poorly, see the Chevy Nova. > Bzzt. Urban legend, kemosabe: [...] Fedora Nexus http://en.wikipedia.org/wiki/Nexus [...] Nexus is a Latin (origin) noun which means connection or centre of something. [...] See also: http://en.wikipedia.org/wiki/The_Nexus_%28Star_Trek%29 ;-) CU thl From gdk at redhat.com Thu Nov 30 20:03:18 2006 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Thu, 30 Nov 2006 15:03:18 -0500 (EST) Subject: fun with naming In-Reply-To: <1164913775.10923.4.camel@cutter> References: <1164884721.2584.433.camel@erato.phig.org> <456EE24D.4010607@leemhuis.info> <200611300910.26592.dennis@ausil.us> <200611301029.46041.jkeating@redhat.com> <1164902583.5065.1.camel@zod.rchland.ibm.com> <1164904103.4388.45.camel@localhost.localdomain> <20061130172130.GC24807@nostromo.devel.redhat.com> <1164913775.10923.4.camel@cutter> Message-ID: I'm changing my vote to Fedora Jazzhands. --g On Thu, 30 Nov 2006, seth vidal wrote: > On Thu, 2006-11-30 at 12:21 -0500, Bill Nottingham wrote: >> Greg Dekoenigsberg (gdk at redhat.com) said: >>> "Fedora Universe" is close, but problematic for a couple of reasons. >>> "Fedora Star" is maybe too clever. >> >> Fedora Supercalifragilisticexpialidocious? >> > > Fedora Jazzhands! > > -sv > > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > -- ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From smooge at gmail.com Thu Nov 30 21:04:53 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 30 Nov 2006 14:04:53 -0700 Subject: fun with naming In-Reply-To: <1164884721.2584.433.camel@erato.phig.org> References: <1164884721.2584.433.camel@erato.phig.org> Message-ID: <80d7e4090611301304v357ddfb9s3777c3e06488d0c1@mail.gmail.com> > On Sat, 2006-11-25 at 20:16 -0500, Christopher Blizzard wrote: > > Thorsten Leemhuis wrote: > > > - Core Packages move over to Extras > > > - Extras is renamed to something more generic -- let's name it "Fedora > > > Package Collection (FPC)" here for now > > > > I think I (we?) prefer Fedora Universe.[*] > > > > --Chris > > > > * We need to have more fun with our naming, I think. Bring the love back. Fedora Sausages [You really don't want to see how its made...] -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From notting at redhat.com Thu Nov 30 21:09:22 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 30 Nov 2006 16:09:22 -0500 Subject: fun with naming In-Reply-To: <80d7e4090611301304v357ddfb9s3777c3e06488d0c1@mail.gmail.com> References: <1164884721.2584.433.camel@erato.phig.org> <80d7e4090611301304v357ddfb9s3777c3e06488d0c1@mail.gmail.com> Message-ID: <20061130210922.GA28786@nostromo.devel.redhat.com> Stephen John Smoogen (smooge at gmail.com) said: > Fedora Sausages [You really don't want to see how its made...] Snausages! Bill From gerold at lugd.org Thu Nov 30 14:21:14 2006 From: gerold at lugd.org (Gerold Kassube) Date: Thu, 30 Nov 2006 14:21:14 -0000 Subject: fun with naming In-Reply-To: <3237e4410611300612p569f0a2ct12a8a121d28aa95@mail.gmail.com> References: <1164884721.2584.433.camel@erato.phig.org> <200611300806.37285.jkeating@redhat.com> <200611300854.49304.jkeating@redhat.com> <3237e4410611300612p569f0a2ct12a8a121d28aa95@mail.gmail.com> Message-ID: <1164896448.3443.8.camel@Amilo-GK.homenet.local> better seems there foo-Buntu .... only *FEDORA* nothing more from my perspective ... Regards Gerold Am Donnerstag, den 30.11.2006, 08:12 -0600 schrieb Mike McGrath: > On 11/30/06, Jesse Keating wrote: > > On Thursday 30 November 2006 08:06, Jesse Keating wrote: > > > Fedora Freeverse > > > Fedora Freedome > > > Fedora Foundation (the packages are just the base part of the project...) > > > > Fedora Finity > > > > FU-buntu? > > -Mike > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > > _______________________________________________ > fedora-advisory-board-readonly mailing list > fedora-advisory-board-readonly at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly > -- Gerold Kassube -Vorstandsvorsitzender- Linux Usergroup L?rrach e.V. Marie-Curie-Strasse 8 79539 L?rrach _ ASCII ribbon campaign ( ) - against HTML email X & vCards / \ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: