From kwade at redhat.com Thu Mar 1 01:31:53 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 28 Feb 2007 17:31:53 -0800 Subject: CLA requirements In-Reply-To: <200702241408.51029.jkeating@redhat.com> References: <45DC8DC1.1010504@fedoraproject.org> <45DCAF41.90308@fedoraproject.org> <1172343025.4651.92.camel@erato.phig.org> <200702241408.51029.jkeating@redhat.com> Message-ID: <1172712713.4651.377.camel@erato.phig.org> On Sat, 2007-02-24 at 14:08 -0500, Jesse Keating wrote: > On Saturday 24 February 2007 13:50, Karsten Wade wrote: > > > > IMO and AIUI, the question of, "To CLA or not to CLA?" is not really a > > question. The only valid question is, "How to CLA?" > > I agree. My only problem with the CLA is that it takes a lot of hoops to get > from 'I want to change this item in the wiki which I know more about' to 'I > now have my verified Fedora account, CLA has been signed and mailed back > correctly, I've now got a Wiki account, and I've gotten somebody to verify my > Fedora account has CLA done and has added me to the EditGroup'. We lose most > people around 'what is a Fedora account?' step, or somewhere else along the > way when something doesn't just work perfectly (like gpg key doesn't match > email used, or CLA isn't getting verified correctly, or nobody is around to > add to EditGroup, or....) > > We REALLY need to make it easier, while protecting ourselves still with the > CLA. So, have we made any progress with the click-through CLA? We need levels of hoops one goes through depending on the contribution level. Moving up in contributor level means stepping through one more hoop. Here is a proposed layout: http://fedoraproject.org/wiki/KarstenWade/Drafts/CLAAcceptanceHierarchies It defines four levels of contributor with increasing hoops to go through for access gained. The levels are designed to fit against potential risk to the Fedora Project; the more you can do that can hurt the project (on purpose or by accident), the more you have to go through that proves you are responsible for your own actions. Something like that. The idea of this table is to give the legal experts the knowledge that we are aware of and mitigating for risk with our CLA acceptance model. By defining the general-Wiki-editor as being able to touch lower risk areas of content, we make it possible for those people to need a lower-assurance level CLA such as a click-through. What think ye? - 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 Thu Mar 1 01:35:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Feb 2007 20:35:44 -0500 Subject: CLA requirements In-Reply-To: <1172712713.4651.377.camel@erato.phig.org> References: <45DC8DC1.1010504@fedoraproject.org> <200702241408.51029.jkeating@redhat.com> <1172712713.4651.377.camel@erato.phig.org> Message-ID: <200702282035.47964.jkeating@redhat.com> On Wednesday 28 February 2007 20:31:53 Karsten Wade wrote: > The idea of this table is to give the legal experts the knowledge that > we are aware of and mitigating for risk with our CLA acceptance model. > By defining the general-Wiki-editor as being able to touch lower risk > areas of content, we make it possible for those people to need a > lower-assurance level CLA such as a click-through. > > What think ye? Seems pretty sane to me. -- 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 sopwith at gmail.com Thu Mar 1 02:00:32 2007 From: sopwith at gmail.com (Elliot Lee) Date: Wed, 28 Feb 2007 21:00:32 -0500 Subject: CLA requirements In-Reply-To: <1172287476.4651.71.camel@erato.phig.org> References: <45DC8DC1.1010504@fedoraproject.org> <13dbfe4f0702211239k59d3e8b2t2b0c57b03afc3065@mail.gmail.com> <45DCAF41.90308@fedoraproject.org> <200702232036.59207.nman64@n-man.com> <45DFA8EF.7030607@fedoraproject.org> <45DFA9EA.6070007@redhat.com> <1172287476.4651.71.camel@erato.phig.org> Message-ID: On Feb 23, 2007, at 22:24 , Karsten Wade wrote: > Interesting point, yes. To refer back up to Rahul's comment, the CLA > covers contributions of content. What is content? My strawman guess - a work covered by copyright law. The CLA exists for legal purposes. There are probably situations where CLA completion has been incorrectly set as a prerequisite for participation, in areas of Fedora where having a clear license is not really necessary. Yea, the CLA process itself can be hairy, and fixing it probably just requires someone to think about the user experience a little. Right now there is an obscure set of instructions locked away behind two or three links. We really need a 'get involved in Fedora' wizard that walks the user through all the steps sequentially, from signing up for an account through the CLA to applying for the relevant groups. On the other hand, the basic process is sound and verifies people's e- mail address anyways, which is a good thing if we're giving them CVS access or sending them T-shirts or whatever. Steps like 'adding to EditGroup' are totally separate from the CLA, and can be automated if someone takes the time to write the scripts. It just needs work. Best, -- Elliot From fedora at leemhuis.info Thu Mar 1 06:09:13 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Mar 2007 07:09:13 +0100 Subject: the danger of becoming a cargo cult In-Reply-To: <1172682429.2871.76.camel@localhost.localdomain> References: <1172521115.12109.43.camel@localhost.localdomain> <45E3CFFA.60707@leemhuis.info> <1172682429.2871.76.camel@localhost.localdomain> Message-ID: <45E66E09.3040503@leemhuis.info> On 28.02.2007 18:07, Christopher Blizzard wrote: > On Tue, 2007-02-27 at 07:30 +0100, Thorsten Leemhuis wrote: >> Agreed -- but nevertheless *I* still have the impression that Red Hat >> and Fedora developers work to much with upstream on improving the Linux >> software stack (which is a good thing in general, but: ) and don't care >> enough about our distribution specific stuff. >> Ubuntu is much more active in that area and thus has some interesting >> stuff that we are already still working on (codec buddy) or have on our >> Roadmap (say: new initsystem). That makes them much more attractive >> these days afaics, as they also get the improvements Red Hat has worked >> out automatically, too (often before we ship them). >> To say it in another way: In the past it was Red Hat Linux that lead the >> way (upstream and in the distribution) and others had to catch up under >> the risk to run into a "Cargo Cult". These days it seems to be Ubuntu. > I've had this conversation with Jonathan in the past, who has > articulated better than most. He feels that working upstream instead of > Fedora gives him the most leverage and can drive the direction of the > desktop. And he's right, we've been hugely successful at building > healthy upstream projects that make our jobs much easier here in Fedora. I agree with this fully. But we have a lot of stuff that is special to Fedora (say anaconda, pup, pirut, initscripts) -- that afaics an area where we need more improvements. When it comes to those improvements it's often Jeremy that does them or at leasts coordinates them. He does it great, but we afaics could need two or three Jeremy's for all the stuff that is lingering around undone for a long time. Just some days ago there was this commit in the wiki: http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems?action=diff&rev2=6&rev1=5 Commit text: "I'm doing this? At this point, not likely to happen for F7 unless someone wants to start contributing patches" Installing packages with yum/pirut from CD/DVD is another example that a lot of people asked for a long time already, but Jeremy didn't find time for it. > The downside to that is that Fedora's users are the _last_ to benefit > from the work that Red Hat has funded. I would not say the "last", but yes, often it are others that get them earlier. Especially those in Gnome, as other Distros have a time based release schedule that is close to the one from Gnome. > It's one of the reasons why a healthy and open Fedora is so important to > me personally. +1 > In a system in which package ownership and maintenance > can be done by both people inside of Red Hat and outside, we get the > best of both worlds. Strong upstream work by full-time developers and > an excited and engaged user/developer base that feels ownership and can > do the early and final integration that Red Hat has failed to do because > they are too busy fixing upstream issues. Maybe -- but some tasks are quite big, and then often a helping and guiding hand from someone that is paid for his work and has ~30 minutes for it each day for it makes the difference. > This is also connected to why I feel why it's so important that we > figure out a better way to handle source, patches and packaging - maybe > including source-as-SCM. Early development and testing mediates some of > the the Fedora-has-best-practices-but-still-ends-up-last problem. > (Loved by upstream projects and developers, used by few.) Agreed. But as I said: the focus for my "rant" that you replied to was more on the Fedora-specific stuff (say for example the Encrypted Filesystems, where the underlying technology IMHO should be worked on upstream, but we need to use it) where we need more improvements to make Fedora more interesting. Take the LiveCD as a example: It took much to long time to get where we are now -- we could have been there where we are now two or three years ago. CU thl From kwade at redhat.com Thu Mar 1 16:45:30 2007 From: kwade at redhat.com (Karsten Wade) Date: Thu, 01 Mar 2007 08:45:30 -0800 Subject: CLA requirements In-Reply-To: References: <45DC8DC1.1010504@fedoraproject.org> <13dbfe4f0702211239k59d3e8b2t2b0c57b03afc3065@mail.gmail.com> <45DCAF41.90308@fedoraproject.org> <200702232036.59207.nman64@n-man.com> <45DFA8EF.7030607@fedoraproject.org> <45DFA9EA.6070007@redhat.com> <1172287476.4651.71.camel@erato.phig.org> Message-ID: <1172767530.4651.438.camel@erato.phig.org> On Wed, 2007-02-28 at 21:00 -0500, Elliot Lee wrote: > three links. We really need a 'get involved in Fedora' wizard that > walks the user through all the steps sequentially, from signing up > for an account through the CLA to applying for the relevant groups. mizmo and I prototyped this at FUDCon, and are ready to put it in place under Plone: http://fedoraproject.org/wiki/Join From each of those groupings should be a link to one or more ProjectName/Join links. That final page contains project-specific how-to-get-involved instructions. We need to be sure that we don't impose a one-size-fits-all approach to account creation if it overrides the individual project unique preferences. As long as a full-wizard-style doesn't stray into that territory, it is worth setting as a goal. - 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 sankar at redhat.com Fri Mar 2 02:40:14 2007 From: sankar at redhat.com (Sankarshan Mukhopadhyay) Date: Fri, 02 Mar 2007 08:10:14 +0530 Subject: Good riddance, ESR In-Reply-To: References: <200702250105.09966.nman64@n-man.com> <1172416673.30900.7.camel@localhost.localdomain> Message-ID: <45E78E8E.2020000@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg Dekoenigsberg wrote: > Fact is, we've got a bunch of people saying exactly that. > > The real question: how do we get *heard*? We write/blog about it. Rather than lengthy how-what-when articles we rely on the power of mashups like planets. digg and /. to consolidate them. :Sankarshan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF546O+g4kmZ76nyERAveSAJ0YxQT4p2qLAGuu93gp+0t4OASCoACfbefg Pdn/chqxAPkdrxWbBG9HAhY= =Q/ao -----END PGP SIGNATURE----- From mspevack at redhat.com Fri Mar 2 13:51:01 2007 From: mspevack at redhat.com (Max Spevack) Date: Fri, 2 Mar 2007 08:51:01 -0500 (EST) Subject: back from fosdem Message-ID: f-a-b, Just wanted to broadcast out that I'm back from FOSDEM and my couple of days of vacation in Europe. I have a giant pile of email to go through, so if you've been sending me stuff in the past week, please have some patience. If there is anything supremely urgent, let me know and I'll try to get to it sooner rather than later. It's probably going to take me into early next week to get caught up on everything. Congrats on all the folks who worked to get Test2 out -- I've got it humming away on my laptop (via rawhide), and everything looks good. Ok, more later. Just wanted people to know that I'm around. For my reports from FOSDEM, see my blog: http://spevack.livejournal.com --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 barzilay at redhat.com Fri Mar 2 15:03:31 2007 From: barzilay at redhat.com (David Barzilay) Date: Fri, 02 Mar 2007 12:03:31 -0300 Subject: FC6 downloads and others Message-ID: <45E83CC3.9050700@redhat.com> Dear All, I just gave an interview on Fedora to a local IT publication and need to answer these questions asap: . number of FC6 downloads as of today or most updatet number . installation size for full desktop . installation size for default desktop Many thanks for your input! Best, -- David Barzilay Manager, Marketing Brasil A virtualiza??o j? ? uma realidade. Saiba mais em http://www.br.redhat.com From rdieter at math.unl.edu Fri Mar 2 15:30:26 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 02 Mar 2007 09:30:26 -0600 Subject: FC6 downloads and others In-Reply-To: <45E83CC3.9050700@redhat.com> References: <45E83CC3.9050700@redhat.com> Message-ID: <45E84312.6070808@math.unl.edu> David Barzilay wrote: > Dear All, > > I just gave an interview on Fedora to a local IT publication and need > to answer these questions asap: > > . number of FC6 downloads as of today or most updatet number http://fedoraproject.org/wiki/Statistics -- Rex From barzilay at redhat.com Fri Mar 2 15:52:18 2007 From: barzilay at redhat.com (David Barzilay) Date: Fri, 02 Mar 2007 12:52:18 -0300 Subject: FC6 downloads and others In-Reply-To: <45E83CC3.9050700@redhat.com> References: <45E83CC3.9050700@redhat.com> Message-ID: <45E84832.6070708@redhat.com> Went through Anaconda and found out: . desktop install default: 1,9 GB . desktop install full: 2,8 GB Thanks, -- db David Barzilay wrote: > Dear All, > > I just gave an interview on Fedora to a local IT publication and need > to answer these questions asap: > > . number of FC6 downloads as of today or most updatet number > . installation size for full desktop > . installation size for default desktop > > Many thanks for your input! > > Best, > -- David Barzilay Manager, Marketing Brasil A virtualiza??o j? ? uma realidade. Saiba mais em http://www.br.redhat.com From jrb at redhat.com Fri Mar 2 16:01:33 2007 From: jrb at redhat.com (Jonathan Blandford) Date: Fri, 02 Mar 2007 11:01:33 -0500 Subject: back from fosdem In-Reply-To: References: Message-ID: <1172851293.3070.5.camel@localhost.localdomain> On Fri, 2007-03-02 at 08:51 -0500, Max Spevack wrote: > If there is anything supremely urgent, let me know and I'll try to get to > it sooner rather than later. It's probably going to take me into early > next week to get caught up on everything. Should I wait until next week then before giving you a call? Thanks, -Jonathan From mspevack at redhat.com Fri Mar 2 19:40:54 2007 From: mspevack at redhat.com (Max Spevack) Date: Fri, 2 Mar 2007 14:40:54 -0500 (EST) Subject: back from fosdem In-Reply-To: <1172851293.3070.5.camel@localhost.localdomain> References: <1172851293.3070.5.camel@localhost.localdomain> Message-ID: On Fri, 2 Mar 2007, Jonathan Blandford wrote: >> If there is anything supremely urgent, let me know and I'll try to get >> to it sooner rather than later. It's probably going to take me into >> early next week to get caught up on everything. > > Should I wait until next week then before giving you a call? Just to close out the thread, jrb and I have scheduled some time to chat next week. Nothing else to see here... --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 mmcgrath at redhat.com Mon Mar 5 17:12:40 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 05 Mar 2007 11:12:40 -0600 Subject: Secondary ARCH Message-ID: <45EC4F88.5060105@redhat.com> There's a SPARC build and an ia64 build for Fedora right now. This stuff isn't easy to do and we need to figure out a way to at least host their code/binaries. I'd like to create a place under fedoraproject.org, more preferably on the mirrors. Possibly under /secondary/ or something like that. Lets get this figured out because waiting any longer is a great disservice to the work these people have done. -Mike From blizzard at redhat.com Mon Mar 5 17:19:47 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 05 Mar 2007 12:19:47 -0500 Subject: Secondary ARCH In-Reply-To: <45EC4F88.5060105@redhat.com> References: <45EC4F88.5060105@redhat.com> Message-ID: <1173115187.17325.55.camel@localhost.localdomain> On Mon, 2007-03-05 at 11:12 -0600, Mike McGrath wrote: > There's a SPARC build and an ia64 build for Fedora right now. This > stuff isn't easy to do and we need to figure out a way to at least host > their code/binaries. I'd like to create a place under > fedoraproject.org, more preferably on the mirrors. Possibly under > /secondary/ or something like that. Lets get this figured out because > waiting any longer is a great disservice to the work these people have done. I think the first step is talking to the various parties and figuring out how much space they really need. --Chris From dennis at ausil.us Mon Mar 5 17:36:51 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 5 Mar 2007 11:36:51 -0600 Subject: Secondary ARCH In-Reply-To: <1173115187.17325.55.camel@localhost.localdomain> References: <45EC4F88.5060105@redhat.com> <1173115187.17325.55.camel@localhost.localdomain> Message-ID: <200703051136.52286.dennis@ausil.us> On Monday 05 March 2007 11:19:47 am Christopher Blizzard wrote: > On Mon, 2007-03-05 at 11:12 -0600, Mike McGrath wrote: > > There's a SPARC build and an ia64 build for Fedora right now. This > > stuff isn't easy to do and we need to figure out a way to at least host > > their code/binaries. I'd like to create a place under > > fedoraproject.org, more preferably on the mirrors. Possibly under > > /secondary/ or something like that. Lets get this figured out because > > waiting any longer is a great disservice to the work these people have > > done. > > I think the first step is talking to the various parties and figuring > out how much space they really need. Well the current corona tree for sparc is 18GB and that is without iso's that is for core and extras. IA64 i think He is just wanting his iso's composed from rawhide hosted. though very soon there will not be any ia64 rawhide builds unless we get ia64 builders donated. what policies in general do we want to have on secondary archs? -- Dennis Gilmore, RHCE From jkeating at redhat.com Mon Mar 5 17:47:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 5 Mar 2007 12:47:29 -0500 Subject: Secondary ARCH In-Reply-To: <200703051136.52286.dennis@ausil.us> References: <45EC4F88.5060105@redhat.com> <1173115187.17325.55.camel@localhost.localdomain> <200703051136.52286.dennis@ausil.us> Message-ID: <200703051247.29984.jkeating@redhat.com> On Monday 05 March 2007 12:36:51 Dennis Gilmore wrote: > what policies in general do we want to have on secondary > archs? We don't have any. We have to come up with acceptable policies that adhere to things like GPL. -- 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 Mon Mar 5 18:26:46 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 05 Mar 2007 13:26:46 -0500 Subject: Secondary ARCH In-Reply-To: <200703051136.52286.dennis@ausil.us> References: <45EC4F88.5060105@redhat.com> <1173115187.17325.55.camel@localhost.localdomain> <200703051136.52286.dennis@ausil.us> Message-ID: <1173119206.17325.75.camel@localhost.localdomain> On Mon, 2007-03-05 at 11:36 -0600, Dennis Gilmore wrote: > On Monday 05 March 2007 11:19:47 am Christopher Blizzard wrote: > > On Mon, 2007-03-05 at 11:12 -0600, Mike McGrath wrote: > > > There's a SPARC build and an ia64 build for Fedora right now. This > > > stuff isn't easy to do and we need to figure out a way to at least host > > > their code/binaries. I'd like to create a place under > > > fedoraproject.org, more preferably on the mirrors. Possibly under > > > /secondary/ or something like that. Lets get this figured out because > > > waiting any longer is a great disservice to the work these people have > > > done. > > > > I think the first step is talking to the various parties and figuring > > out how much space they really need. > > Well the current corona tree for sparc is 18GB and that is without iso's that > is for core and extras. > > IA64 i think He is just wanting his iso's composed from rawhide hosted. > though very soon there will not be any ia64 rawhide builds unless we get ia64 > builders donated. what policies in general do we want to have on secondary > archs? > > What's needed other than a set of output rpms and isos? From what I remember of the meeting we had a few months ago we expected secondary arch builds to happen on contributed machines, but wanted to host final bits. That should be our target, right? i.e. are there other things that we need to have in place for adding capacity down the road? And what capacity is it? We need a little brainstorming. --Chris From dennis at ausil.us Mon Mar 5 18:45:27 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 5 Mar 2007 12:45:27 -0600 Subject: Secondary ARCH In-Reply-To: <1173119206.17325.75.camel@localhost.localdomain> References: <45EC4F88.5060105@redhat.com> <200703051136.52286.dennis@ausil.us> <1173119206.17325.75.camel@localhost.localdomain> Message-ID: <200703051245.27898.dennis@ausil.us> On Monday 05 March 2007 12:26:46 pm Christopher Blizzard wrote: > On Mon, 2007-03-05 at 11:36 -0600, Dennis Gilmore wrote: > > On Monday 05 March 2007 11:19:47 am Christopher Blizzard wrote: > > > On Mon, 2007-03-05 at 11:12 -0600, Mike McGrath wrote: > > > > There's a SPARC build and an ia64 build for Fedora right now. This > > > > stuff isn't easy to do and we need to figure out a way to at least > > > > host their code/binaries. I'd like to create a place under > > > > fedoraproject.org, more preferably on the mirrors. Possibly under > > > > /secondary/ or something like that. Lets get this figured out > > > > because waiting any longer is a great disservice to the work these > > > > people have done. > > > > > > I think the first step is talking to the various parties and figuring > > > out how much space they really need. > > > > Well the current corona tree for sparc is 18GB and that is without iso's > > that is for core and extras. > > > > IA64 i think He is just wanting his iso's composed from rawhide hosted. > > though very soon there will not be any ia64 rawhide builds unless we get > > ia64 builders donated. what policies in general do we want to have on > > secondary archs? > > What's needed other than a set of output rpms and isos? From what I > remember of the meeting we had a few months ago we expected secondary > arch builds to happen on contributed machines, but wanted to host final > bits. That should be our target, right? Yes that's how i see it. > i.e. are there other things that we need to have in place for adding > capacity down the road? And what capacity is it? We need a little > brainstorming. We need to add support to koji to handle secondary arch builds. that is intended for the second phase of implementation. First phase is to have it up and functional for our primary arch needs. we need to realise that we will very quickly eat up disk space. alot of the corona figure i quoted is SRPMS. They are nearly all identical to whats in Fedora. there are a few minor patches. but in a secondary arch world there will be one set of SRPMS for all archs. So that will be something that will not increase storage space used. there will be binary rpms which corona is ~11G plus iso's another variable amount depending on spins. so each arch we add is probably going to need 25-30G per release. by the time updates are added. we need that storage in 4 locations. the three primary mirrors and the buildsys. so say we have i386, x86_64, ppc, ppc64, ia64, sparc and SRPMS we are looking at needing ~200GB of disk space per release x 4 locations. -- Dennis Gilmore, RHCE From sundaram at fedoraproject.org Mon Mar 5 18:51:07 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 06 Mar 2007 00:21:07 +0530 Subject: Secondary ARCH In-Reply-To: <1173119206.17325.75.camel@localhost.localdomain> References: <45EC4F88.5060105@redhat.com> <1173115187.17325.55.camel@localhost.localdomain> <200703051136.52286.dennis@ausil.us> <1173119206.17325.75.camel@localhost.localdomain> Message-ID: <45EC669B.7010007@fedoraproject.org> Christopher Blizzard wrote: > What's needed other than a set of output rpms and isos? From what I > remember of the meeting we had a few months ago we expected secondary > arch builds to happen on contributed machines, but wanted to host final > bits. That should be our target, right? If we do that and these variations add patches, how do we ensure that they dont have trojans or exploits? > i.e. are there other things that we need to have in place for adding > capacity down the road? And what capacity is it? We need a little > brainstorming. * Process for new folks interested to create Fedora for architecture X - Owners, bug tracking, build system, hosting. * Figure out how secondary architectures can become primary ones * Do we want to move PPC as a secondary architecture? * Alpha. We probably need to contact the Alphacore (http://alphacore.info/) folks and ask if they are interested. Note that CentOS 4.2 and above has alpha core support. Rahul From jkeating at redhat.com Mon Mar 5 19:03:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 5 Mar 2007 14:03:55 -0500 Subject: Secondary ARCH In-Reply-To: <45EC669B.7010007@fedoraproject.org> References: <45EC4F88.5060105@redhat.com> <1173119206.17325.75.camel@localhost.localdomain> <45EC669B.7010007@fedoraproject.org> Message-ID: <200703051403.55411.jkeating@redhat.com> On Monday 05 March 2007 13:51:07 Rahul Sundaram wrote: > * Do we want to move PPC as a secondary architecture? Already asked and answered many times over. Yes, as soon as the infrastructure is ready to support it easily. > * Alpha. We probably need to contact the Alphacore > (http://alphacore.info/) folks and ask if they are interested. Note that > CentOS 4.2 and above has alpha core support. They've already contacted me asking for information, so they do want to join in the fun when possible. -- 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 Mar 5 19:06:28 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 5 Mar 2007 13:06:28 -0600 Subject: Secondary ARCH In-Reply-To: <45EC669B.7010007@fedoraproject.org> References: <45EC4F88.5060105@redhat.com> <1173119206.17325.75.camel@localhost.localdomain> <45EC669B.7010007@fedoraproject.org> Message-ID: <200703051306.29031.dennis@ausil.us> On Monday 05 March 2007 12:51:07 pm Rahul Sundaram wrote: > Christopher Blizzard wrote: > > What's needed other than a set of output rpms and isos? From what I > > remember of the meeting we had a few months ago we expected secondary > > arch builds to happen on contributed machines, but wanted to host final > > bits. That should be our target, right? > > If we do that and these variations add patches, how do we ensure that > they dont have trojans or exploits? We have to trust them to an extent. any patches that need adding for one arch will get applied in the base SCM and a build will get issued for all archs. so we will see commits from arch teams. > > i.e. are there other things that we need to have in place for adding > > capacity down the road? And what capacity is it? We need a little > > brainstorming. > > * Process for new folks interested to create Fedora for architecture X - > Owners, bug tracking, build system, hosting. They will need to provide resources and show they have something viable. They the board can choose to add them or not. we also need to work out what to do when an arch no longer is maintained. how to we drop it. > * Figure out how secondary architectures can become primary ones > * Do we want to move PPC as a secondary architecture? When it is proven that secondary archs work yes > * Alpha. We probably need to contact the Alphacore > (http://alphacore.info/) folks and ask if they are interested. Note that > CentOS 4.2 and above has alpha core support. Sure we need to give them the opportunity. -- Dennis Gilmore, RHCE From katzj at redhat.com Mon Mar 5 19:01:00 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 05 Mar 2007 14:01:00 -0500 Subject: Secondary ARCH In-Reply-To: <1173119206.17325.75.camel@localhost.localdomain> References: <45EC4F88.5060105@redhat.com> <1173115187.17325.55.camel@localhost.localdomain> <200703051136.52286.dennis@ausil.us> <1173119206.17325.75.camel@localhost.localdomain> Message-ID: <1173121260.3121.33.camel@aglarond.local> On Mon, 2007-03-05 at 13:26 -0500, Christopher Blizzard wrote: > What's needed other than a set of output rpms and isos? From what I > remember of the meeting we had a few months ago we expected secondary > arch builds to happen on contributed machines, but wanted to host final > bits. That should be our target, right? I think the main technical things are (off the top of my head) * Backend storage. Probably fairly significant chunks as you're going to want to keep releases (tree + ISOs), development (tree at least), potentially test releases if they don't want/can't host themselves * Sync mechanism. We don't currently have a good way for these sorts of things to get their bits onto above backend storage. The "add an rsync to an internal server that can run as a cronjob" really only gets us so far. I expect that the secondary arches would far prefer a push mechanism. * Need a good way to kick off the secondary arch builds. This isn't the highest priority, but it is eventually needed Then, there are the more fuzzy things like * How do we get bugs reported and ensure that arch groups find out about bugs that are arch specific without adding much (if any) overhead for everyone else. * How do we make it easy for patches to flow in, although this problem with one SCM that's external. Although there's then a need for a policy around how to give commit access or not Jeremy From mspevack at redhat.com Mon Mar 5 19:26:41 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 5 Mar 2007 14:26:41 -0500 (EST) Subject: fedora board meeting tomorrow (3/6) Message-ID: We have a meeting tomorrow morning (3/6) at 10:00 AM EST (15:00 GMT). We'll be on the phone, and in #fedora-meeting Topics of conversation 1) FOSDEM wrapup (Max) 2) Test2 debrief (Jeremy/Bill) 3) Core/Extras merge issues (Max) 4) Improved Fedora->RHEL communication (Max) Surely there are other important topics that I am not thinking of right now that need discussion. Anyone, feel free to add to the list. Not to mention the many topics (like KDE, for example), that simply need *action* and less discussion. :-) Going AFK for a bit... --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 dennis at ausil.us Mon Mar 5 19:50:18 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 5 Mar 2007 13:50:18 -0600 Subject: Secondary ARCH In-Reply-To: <1173121260.3121.33.camel@aglarond.local> References: <45EC4F88.5060105@redhat.com> <1173119206.17325.75.camel@localhost.localdomain> <1173121260.3121.33.camel@aglarond.local> Message-ID: <200703051350.18865.dennis@ausil.us> On Monday 05 March 2007 01:01:00 pm Jeremy Katz wrote: > On Mon, 2007-03-05 at 13:26 -0500, Christopher Blizzard wrote: > > What's needed other than a set of output rpms and isos? From what I > > remember of the meeting we had a few months ago we expected secondary > > arch builds to happen on contributed machines, but wanted to host final > > bits. That should be our target, right? > > I think the main technical things are (off the top of my head) > * Backend storage. Probably fairly significant chunks as you're going > to want to keep releases (tree + ISOs), development (tree at least), > potentially test releases if they don't want/can't host themselves This is probably the biggest hurdle. How long should we keep old releases around? could we for instance move non supported realease to a single box and have it available at archive.fedoraproject.org or even get rid of old releases entirely at some point? > * Sync mechanism. We don't currently have a good way for these sorts of > things to get their bits onto above backend storage. The "add an rsync > to an internal server that can run as a cronjob" really only gets us so > far. I expect that the secondary arches would far prefer a push > mechanism. > * Need a good way to kick off the secondary arch builds. This isn't the > highest priority, but it is eventually needed the sync and kicking off kinda come down to the same thing. The way we have briefly talked about doing this is to have a koji hub at the secondary arch site and have it talk to the main hub. which will do the queueing of builds and sync things back to the main hub when built. > Then, there are the more fuzzy things like > * How do we get bugs reported and ensure that arch groups find out about > bugs that are arch specific without adding much (if any) overhead for > everyone else. have an alias for the secondary arch team or a mailing list. and have all bugs reported against that arch auto cc'd to the team > * How do we make it easy for patches to flow in, although this problem > with one SCM that's external. Although there's then a need for a policy > around how to give commit access or not -- Dennis Gilmore, RHCE From katzj at redhat.com Mon Mar 5 19:54:26 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 05 Mar 2007 14:54:26 -0500 Subject: Secondary ARCH In-Reply-To: <200703051350.18865.dennis@ausil.us> References: <45EC4F88.5060105@redhat.com> <1173119206.17325.75.camel@localhost.localdomain> <1173121260.3121.33.camel@aglarond.local> <200703051350.18865.dennis@ausil.us> Message-ID: <1173124466.3121.48.camel@aglarond.local> On Mon, 2007-03-05 at 13:50 -0600, Dennis Gilmore wrote: > On Monday 05 March 2007 01:01:00 pm Jeremy Katz wrote: > > On Mon, 2007-03-05 at 13:26 -0500, Christopher Blizzard wrote: > > > What's needed other than a set of output rpms and isos? From what I > > > remember of the meeting we had a few months ago we expected secondary > > > arch builds to happen on contributed machines, but wanted to host final > > > bits. That should be our target, right? > > > > I think the main technical things are (off the top of my head) > > * Backend storage. Probably fairly significant chunks as you're going > > to want to keep releases (tree + ISOs), development (tree at least), > > potentially test releases if they don't want/can't host themselves > This is probably the biggest hurdle. > > How long should we keep old releases around? > could we for instance move non supported realease to a single box and have it > available at archive.fedoraproject.org or even get rid of old releases > entirely at some point? There are GPL requirements on keeping things around for a certain length of time. And for historical reasons, I don't think we ever want to get rid of them entirely. Not that I've had to go install Red Hat Linux 6.2 in a while, but it's nice that I _can_ if I need to :) Something like archive.fedoraproject.org probably could work, though, to help with mirror burden. It doesn't really help our storage concerns though. > > * Sync mechanism. We don't currently have a good way for these sorts of > > things to get their bits onto above backend storage. The "add an rsync > > to an internal server that can run as a cronjob" really only gets us so > > far. I expect that the secondary arches would far prefer a push > > mechanism. > > * Need a good way to kick off the secondary arch builds. This isn't the > > highest priority, but it is eventually needed > the sync and kicking off kinda come down to the same thing. The way we have > briefly talked about doing this is to have a koji hub at the secondary arch > site and have it talk to the main hub. which will do the queueing of builds > and sync things back to the main hub when built. Yes and no -- that helps for packages, it doesn't help for ISOs. Or live CDs. > > Then, there are the more fuzzy things like > > * How do we get bugs reported and ensure that arch groups find out about > > bugs that are arch specific without adding much (if any) overhead for > > everyone else. > > have an alias for the secondary arch team or a mailing list. and have all > bugs reported against that arch auto cc'd to the team Yeah, that's the obvious answer. Just have to make sure that we can do it with bugzilla. Jeremy From dennis at ausil.us Mon Mar 5 20:28:01 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 5 Mar 2007 14:28:01 -0600 Subject: Secondary ARCH In-Reply-To: <1173124466.3121.48.camel@aglarond.local> References: <45EC4F88.5060105@redhat.com> <200703051350.18865.dennis@ausil.us> <1173124466.3121.48.camel@aglarond.local> Message-ID: <200703051428.02024.dennis@ausil.us> On Monday 05 March 2007 01:54:26 pm Jeremy Katz wrote: > On Mon, 2007-03-05 at 13:50 -0600, Dennis Gilmore wrote: > > On Monday 05 March 2007 01:01:00 pm Jeremy Katz wrote: > > > On Mon, 2007-03-05 at 13:26 -0500, Christopher Blizzard wrote: > > > > What's needed other than a set of output rpms and isos? From what I > > > > remember of the meeting we had a few months ago we expected secondary > > > > arch builds to happen on contributed machines, but wanted to host > > > > final bits. That should be our target, right? > > > > > > I think the main technical things are (off the top of my head) > > > * Backend storage. Probably fairly significant chunks as you're going > > > to want to keep releases (tree + ISOs), development (tree at least), > > > potentially test releases if they don't want/can't host themselves > > > > This is probably the biggest hurdle. > > > > How long should we keep old releases around? > > could we for instance move non supported realease to a single box and > > have it available at archive.fedoraproject.org or even get rid of old > > releases entirely at some point? > > There are GPL requirements on keeping things around for a certain length > of time. And for historical reasons, I don't think we ever want to get > rid of them entirely. Not that I've had to go install Red Hat Linux 6.2 > in a while, but it's nice that I _can_ if I need to :) Something like > archive.fedoraproject.org probably could work, though, to help with > mirror burden. It doesn't really help our storage concerns though. It does to the extent that we would only have one copy not the three we currently keep.my understanding of how the primary mirror is setup is that there are three sites currently. > > > * Sync mechanism. We don't currently have a good way for these sorts > > > of things to get their bits onto above backend storage. The "add an > > > rsync to an internal server that can run as a cronjob" really only gets > > > us so far. I expect that the secondary arches would far prefer a push > > > mechanism. > > > * Need a good way to kick off the secondary arch builds. This isn't > > > the highest priority, but it is eventually needed > > > > the sync and kicking off kinda come down to the same thing. The way we > > have briefly talked about doing this is to have a koji hub at the > > secondary arch site and have it talk to the main hub. which will do the > > queueing of builds and sync things back to the main hub when built. > > Yes and no -- that helps for packages, it doesn't help for ISOs. Or > live CDs. these could be created close to the master buildsys and downloaded for testing. > > > Then, there are the more fuzzy things like > > > * How do we get bugs reported and ensure that arch groups find out > > > about bugs that are arch specific without adding much (if any) overhead > > > for everyone else. > > > > have an alias for the secondary arch team or a mailing list. and have > > all bugs reported against that arch auto cc'd to the team > > Yeah, that's the obvious answer. Just have to make sure that we can do > it with bugzilla. I was told that its possible awhile ago when i asked if all sparc extras bugs got assigned to me. I was told i could be cc'd but not made the owner based on arch. I'm asking now to make sure that we can indeed do that. -- Dennis Gilmore, RHCE From katzj at redhat.com Mon Mar 5 20:54:29 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 05 Mar 2007 15:54:29 -0500 Subject: Secondary ARCH In-Reply-To: <200703051428.02024.dennis@ausil.us> References: <45EC4F88.5060105@redhat.com> <200703051350.18865.dennis@ausil.us> <1173124466.3121.48.camel@aglarond.local> <200703051428.02024.dennis@ausil.us> Message-ID: <1173128069.3121.50.camel@aglarond.local> On Mon, 2007-03-05 at 14:28 -0600, Dennis Gilmore wrote: > On Monday 05 March 2007 01:54:26 pm Jeremy Katz wrote: > > > > * Sync mechanism. We don't currently have a good way for these sorts > > > > of things to get their bits onto above backend storage. The "add an > > > > rsync to an internal server that can run as a cronjob" really only gets > > > > us so far. I expect that the secondary arches would far prefer a push > > > > mechanism. > > > > * Need a good way to kick off the secondary arch builds. This isn't > > > > the highest priority, but it is eventually needed > > > > > > the sync and kicking off kinda come down to the same thing. The way we > > > have briefly talked about doing this is to have a koji hub at the > > > secondary arch site and have it talk to the main hub. which will do the > > > queueing of builds and sync things back to the main hub when built. > > > > Yes and no -- that helps for packages, it doesn't help for ISOs. Or > > live CDs. > these could be created close to the master buildsys and downloaded for > testing. Building ISOs requires running buildinstall which requires running arch-specific stuff. There's just no way around this. And I really don't want to be in the situation where we have to have a box of the arch in the colo for it to be a secondary arch. If that's the case, we haven't succeeded. Jeremy From mmcgrath at redhat.com Mon Mar 5 20:59:58 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 05 Mar 2007 14:59:58 -0600 Subject: Secondary ARCH In-Reply-To: <1173128069.3121.50.camel@aglarond.local> References: <45EC4F88.5060105@redhat.com> <200703051350.18865.dennis@ausil.us> <1173124466.3121.48.camel@aglarond.local> <200703051428.02024.dennis@ausil.us> <1173128069.3121.50.camel@aglarond.local> Message-ID: <45EC84CE.7050803@redhat.com> Jeremy Katz wrote: > On Mon, 2007-03-05 at 14:28 -0600, Dennis Gilmore wrote: > >> On Monday 05 March 2007 01:54:26 pm Jeremy Katz wrote: >> >>>>> * Sync mechanism. We don't currently have a good way for these sorts >>>>> of things to get their bits onto above backend storage. The "add an >>>>> rsync to an internal server that can run as a cronjob" really only gets >>>>> us so far. I expect that the secondary arches would far prefer a push >>>>> mechanism. >>>>> * Need a good way to kick off the secondary arch builds. This isn't >>>>> the highest priority, but it is eventually needed >>>>> >>>> the sync and kicking off kinda come down to the same thing. The way we >>>> have briefly talked about doing this is to have a koji hub at the >>>> secondary arch site and have it talk to the main hub. which will do the >>>> queueing of builds and sync things back to the main hub when built. >>>> >>> Yes and no -- that helps for packages, it doesn't help for ISOs. Or >>> live CDs. >>> >> these could be created close to the master buildsys and downloaded for >> testing. >> > > Building ISOs requires running buildinstall which requires running > arch-specific stuff. There's just no way around this. And I really > don't want to be in the situation where we have to have a box of the > arch in the colo for it to be a secondary arch. If that's the case, we > haven't succeeded. > > Jeremy > Nothing's more complex than the extras updates :-D All we need to do is say "SPARC Guys, your trusted. Tell us where you'd like to stage your source / binaries / etc" Then we copy from there to the mirror. This is just like what we have set up at duke in many regards. If we (Fedora Project Proper) have to support and work and work to keep an arch up and going then its not a secondary arch. We have to set up these projects to succeed on their own. If they don't, then the community has spoken. -Mike From dwmw2 at infradead.org Tue Mar 6 10:47:58 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 06 Mar 2007 10:47:58 +0000 Subject: Secondary ARCH In-Reply-To: <200703051428.02024.dennis@ausil.us> References: <45EC4F88.5060105@redhat.com> <200703051350.18865.dennis@ausil.us> <1173124466.3121.48.camel@aglarond.local> <200703051428.02024.dennis@ausil.us> Message-ID: <1173178078.3461.301.camel@pmac.infradead.org> On Mon, 2007-03-05 at 14:28 -0600, Dennis Gilmore wrote: > I was told that its possible awhile ago when i asked if all sparc extras bugs > got assigned to me. I was told i could be cc'd but not made the owner based > on arch. I'm asking now to make sure that we can indeed do that. There wasn't ever any real suggestion that you'd want to be made the owner based on architecture, was there? Not for anything except the kernel and maybe glibc, at least? A Cc is all we want. -- dwmw2 From dennis at ausil.us Tue Mar 6 13:47:06 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 6 Mar 2007 07:47:06 -0600 Subject: Secondary ARCH In-Reply-To: <1173178078.3461.301.camel@pmac.infradead.org> References: <45EC4F88.5060105@redhat.com> <200703051428.02024.dennis@ausil.us> <1173178078.3461.301.camel@pmac.infradead.org> Message-ID: <200703060747.06395.dennis@ausil.us> Once upon a time Tuesday 06 March 2007, David Woodhouse wrote: > On Mon, 2007-03-05 at 14:28 -0600, Dennis Gilmore wrote: > > I was told that its possible awhile ago when i asked if all sparc extras > > bugs got assigned to me. I was told i could be cc'd but not made the > > owner based on arch. I'm asking now to make sure that we can indeed do > > that. > > There wasn't ever any real suggestion that you'd want to be made the > owner based on architecture, was there? Not for anything except the > kernel and maybe glibc, at least? A Cc is all we want. Cc is all we want. I was told its not possible to do in bugzilla yesterday afternoon. so we would need a cron job that interfaces with bugzilla and finds new arch bugs and adds the teams to cc. Dennis From dwmw2 at infradead.org Tue Mar 6 14:17:07 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 06 Mar 2007 14:17:07 +0000 Subject: Secondary ARCH In-Reply-To: <200703060747.06395.dennis@ausil.us> References: <45EC4F88.5060105@redhat.com> <200703051428.02024.dennis@ausil.us> <1173178078.3461.301.camel@pmac.infradead.org> <200703060747.06395.dennis@ausil.us> Message-ID: <1173190627.3603.3.camel@hades.cambridge.redhat.com> On Tue, 2007-03-06 at 07:47 -0600, Dennis Gilmore wrote: > Cc is all we want. I was told its not possible to do in bugzilla yesterday > afternoon. so we would need a cron job that interfaces with bugzilla and > finds new arch bugs and adds the teams to cc. Or the package maintainer could just add the team to Cc manually if it turns out to be an arch-specific problem? -- dwmw2 From jkeating at redhat.com Tue Mar 6 14:45:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Mar 2007 09:45:14 -0500 Subject: Secondary ARCH In-Reply-To: <1173190627.3603.3.camel@hades.cambridge.redhat.com> References: <45EC4F88.5060105@redhat.com> <200703060747.06395.dennis@ausil.us> <1173190627.3603.3.camel@hades.cambridge.redhat.com> Message-ID: <200703060945.14317.jkeating@redhat.com> On Tuesday 06 March 2007 09:17:07 David Woodhouse wrote: > Or the package maintainer could just add the team to Cc manually if it > turns out to be an arch-specific problem? Setting up easy to use aliases would help for this. ppc at fedoraproject.org, sparc at fedoraproject.org, alpha at fedoraproject.org, and we could even create such aliases for the primary arches too, and have arch maintainers for those to tackle arch specific type things. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Tue Mar 6 14:51:38 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 06 Mar 2007 14:51:38 +0000 Subject: Secondary ARCH In-Reply-To: <200703060945.14317.jkeating@redhat.com> References: <45EC4F88.5060105@redhat.com> <200703060747.06395.dennis@ausil.us> <1173190627.3603.3.camel@hades.cambridge.redhat.com> <200703060945.14317.jkeating@redhat.com> Message-ID: <1173192698.3603.9.camel@hades.cambridge.redhat.com> On Tue, 2007-03-06 at 09:45 -0500, Jesse Keating wrote: > Setting up easy to use aliases would help for this. ppc at fedoraproject.org, > sparc at fedoraproject.org, alpha at fedoraproject.org, and we could even create > such aliases for the primary arches too, and have arch maintainers for those > to tackle arch specific type things. Yeah, that's a good idea. -- dwmw2 From jwboyer at jdub.homelinux.org Tue Mar 6 14:59:17 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 06 Mar 2007 08:59:17 -0600 Subject: Secondary ARCH In-Reply-To: <1173192698.3603.9.camel@hades.cambridge.redhat.com> References: <45EC4F88.5060105@redhat.com> <200703060747.06395.dennis@ausil.us> <1173190627.3603.3.camel@hades.cambridge.redhat.com> <200703060945.14317.jkeating@redhat.com> <1173192698.3603.9.camel@hades.cambridge.redhat.com> Message-ID: <1173193157.6561.35.camel@zod.rchland.ibm.com> On Tue, 2007-03-06 at 14:51 +0000, David Woodhouse wrote: > On Tue, 2007-03-06 at 09:45 -0500, Jesse Keating wrote: > > Setting up easy to use aliases would help for this. ppc at fedoraproject.org, > > sparc at fedoraproject.org, alpha at fedoraproject.org, and we could even create > > such aliases for the primary arches too, and have arch maintainers for those > > to tackle arch specific type things. > > Yeah, that's a good idea. Feel free to add me to the ppc alias. josh From mmcgrath at redhat.com Tue Mar 6 15:02:33 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 06 Mar 2007 09:02:33 -0600 Subject: Secondary ARCH In-Reply-To: <200703060945.14317.jkeating@redhat.com> References: <45EC4F88.5060105@redhat.com> <200703060747.06395.dennis@ausil.us> <1173190627.3603.3.camel@hades.cambridge.redhat.com> <200703060945.14317.jkeating@redhat.com> Message-ID: <45ED8289.2000803@redhat.com> Jesse Keating wrote: > On Tuesday 06 March 2007 09:17:07 David Woodhouse wrote: > >> Or the package maintainer could just add the team to Cc manually if it >> turns out to be an arch-specific problem? >> > > Setting up easy to use aliases would help for this. ppc at fedoraproject.org, > sparc at fedoraproject.org, alpha at fedoraproject.org, and we could even create > such aliases for the primary arches too, and have arch maintainers for those > to tackle arch specific type things. > We might as well just have official groups, let them manage themselves. They still get a unified email address, etc. -Mike From jkeating at redhat.com Tue Mar 6 15:09:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Mar 2007 10:09:29 -0500 Subject: Secondary ARCH In-Reply-To: <45ED8289.2000803@redhat.com> References: <45EC4F88.5060105@redhat.com> <200703060945.14317.jkeating@redhat.com> <45ED8289.2000803@redhat.com> Message-ID: <200703061009.29787.jkeating@redhat.com> On Tuesday 06 March 2007 10:02:33 Mike McGrath wrote: > We might as well just have official groups, let them manage themselves. ? > They still get a unified email address, etc. Sure, how the alias gets populated I care not about, just that it is available for maintainers to call upon when they have issues. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Wed Mar 7 18:07:29 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 07 Mar 2007 12:07:29 -0600 Subject: Secondary ARCH In-Reply-To: <200703061009.29787.jkeating@redhat.com> References: <45EC4F88.5060105@redhat.com> <200703060945.14317.jkeating@redhat.com> <45ED8289.2000803@redhat.com> <200703061009.29787.jkeating@redhat.com> Message-ID: <45EEFF61.3080809@redhat.com> Jesse Keating wrote: > On Tuesday 06 March 2007 10:02:33 Mike McGrath wrote: > >> We might as well just have official groups, let them manage themselves. >> They still get a unified email address, etc. >> > > Sure, how the alias gets populated I care not about, just that it is available > for maintainers to call upon when they have issues. > How's this sound, I'll get groups created for the sparc and ia64 people. We'll give them a way to upload their RPM's to our system. We'll figure out how to get it to the master mirror later. -Mike From jkeating at redhat.com Wed Mar 7 19:01:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Mar 2007 14:01:57 -0500 Subject: Secondary ARCH In-Reply-To: <45EEFF61.3080809@redhat.com> References: <45EC4F88.5060105@redhat.com> <200703061009.29787.jkeating@redhat.com> <45EEFF61.3080809@redhat.com> Message-ID: <200703071402.00620.jkeating@redhat.com> On Wednesday 07 March 2007 13:07:29 Mike McGrath wrote: > How's this sound, I'll get groups created for the sparc and ia64 > people. ?We'll give them a way to upload their RPM's to our system. ? > We'll figure out how to get it to the master mirror later. I think this is a good start. I'm a little concerned with how we ensure that what they put up as "Fedora" stuff is actually Fedora stuff, generated legally, securely, etc... We haven't really had to think on this before because we only put up what we generate, now we're going to put up what somebody else generates from a different system. Just something that will keep me up at night. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Wed Mar 7 19:12:52 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 07 Mar 2007 13:12:52 -0600 Subject: Secondary ARCH In-Reply-To: <200703071402.00620.jkeating@redhat.com> References: <45EC4F88.5060105@redhat.com> <200703061009.29787.jkeating@redhat.com> <45EEFF61.3080809@redhat.com> <200703071402.00620.jkeating@redhat.com> Message-ID: <45EF0EB4.9080508@redhat.com> Jesse Keating wrote: > On Wednesday 07 March 2007 13:07:29 Mike McGrath wrote: > >> How's this sound, I'll get groups created for the sparc and ia64 >> people. We'll give them a way to upload their RPM's to our system. >> We'll figure out how to get it to the master mirror later. >> > > I think this is a good start. I'm a little concerned with how we ensure that > what they put up as "Fedora" stuff is actually Fedora stuff, generated > legally, securely, etc... We haven't really had to think on this before > because we only put up what we generate, now we're going to put up what > somebody else generates from a different system. Just something that will > keep me up at night. > I'd say the same way we do it now, bugzilla. (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224627) for example. We have ultimate control to remove something if we need to. -Mike From notting at redhat.com Thu Mar 8 22:19:23 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 8 Mar 2007 17:19:23 -0500 Subject: Secondary ARCH In-Reply-To: <45EF0EB4.9080508@redhat.com> References: <45EC4F88.5060105@redhat.com> <200703061009.29787.jkeating@redhat.com> <45EEFF61.3080809@redhat.com> <200703071402.00620.jkeating@redhat.com> <45EF0EB4.9080508@redhat.com> Message-ID: <20070308221923.GH5337@nostromo.devel.redhat.com> Mike McGrath (mmcgrath at redhat.com) said: > >I think this is a good start. I'm a little concerned with how we ensure > >that what they put up as "Fedora" stuff is actually Fedora stuff, > >generated legally, securely, etc... We haven't really had to think on > >this before because we only put up what we generate, now we're going to > >put up what somebody else generates from a different system. Just > >something that will keep me up at night. > > I'd say the same way we do it now, bugzilla. > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224627) for > example. We have ultimate control to remove something if we need to. I think what he's asking is do we have the resources to *review* that stuff is built from the same/similar sources, etc. Bill From mmcgrath at redhat.com Thu Mar 8 22:28:11 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 08 Mar 2007 16:28:11 -0600 Subject: Secondary ARCH In-Reply-To: <20070308221923.GH5337@nostromo.devel.redhat.com> References: <45EC4F88.5060105@redhat.com> <200703061009.29787.jkeating@redhat.com> <45EEFF61.3080809@redhat.com> <200703071402.00620.jkeating@redhat.com> <45EF0EB4.9080508@redhat.com> <20070308221923.GH5337@nostromo.devel.redhat.com> Message-ID: <45F08DFB.7010209@redhat.com> Bill Nottingham wrote: > Mike McGrath (mmcgrath at redhat.com) said: > >>> I think this is a good start. I'm a little concerned with how we ensure >>> that what they put up as "Fedora" stuff is actually Fedora stuff, >>> generated legally, securely, etc... We haven't really had to think on >>> this before because we only put up what we generate, now we're going to >>> put up what somebody else generates from a different system. Just >>> something that will keep me up at night. >>> >> I'd say the same way we do it now, bugzilla. >> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224627) for >> example. We have ultimate control to remove something if we need to. >> > > I think what he's asking is do we have the resources to *review* that > stuff is built from the same/similar sources, etc. > > Bill > > I hate to even suggest this but do we need some sort of super CLA? or would the CLA cover this already? Side note: I'm not sure we can host this immediately, we just don't have the storage right this minute. I'm looking around though. -Mike From dennis at ausil.us Thu Mar 8 22:42:14 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 8 Mar 2007 16:42:14 -0600 Subject: Secondary ARCH In-Reply-To: <20070308221923.GH5337@nostromo.devel.redhat.com> References: <45EC4F88.5060105@redhat.com> <45EF0EB4.9080508@redhat.com> <20070308221923.GH5337@nostromo.devel.redhat.com> Message-ID: <200703081642.14749.dennis@ausil.us> On Thursday 08 March 2007 04:19:23 pm Bill Nottingham wrote: > Mike McGrath (mmcgrath at redhat.com) said: > > >I think this is a good start. I'm a little concerned with how we ensure > > >that what they put up as "Fedora" stuff is actually Fedora stuff, > > >generated legally, securely, etc... We haven't really had to think on > > >this before because we only put up what we generate, now we're going to > > >put up what somebody else generates from a different system. Just > > >something that will keep me up at night. > > > > I'd say the same way we do it now, bugzilla. > > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224627) for > > example. We have ultimate control to remove something if we need to. > > I think what he's asking is do we have the resources to *review* that > stuff is built from the same/similar sources, etc. > > Bill the goal is to have the secondary arch buildsys pull from fedora cvs. we could make sure that we have root access to all build systems so we can spot check and make sure they have not pointed the buildsys at a different SCM we could do diffs on the SRPMS from secondary archs and primary archs. Secondary arch SRPMS must match primary arch ones. any patches they need must get put in to cvs and build across all archs -- Dennis Gilmore, RHCE From kwade at redhat.com Fri Mar 9 22:36:10 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 09 Mar 2007 14:36:10 -0800 Subject: copyright year question Message-ID: <1173479770.3935.283.camel@erato.phig.org> We had a question come up, as I was updating some copyright years in a few documents. What is the proper practice for writing and maintaining years of copyright? We have documents that may represent a work-in-time, and Websites that represent work-across-time. Should we only specify the years that new content was added to a body? Can we span years, e.g. "(c) 2003 - 2007", and have 2005 and 2006 included? Or do we need to enumerate specific years that content is added for it to be protected? I.e., "(c) 2003, 2004, 2005, 2006, 2007". Should we update copyright for all documents to the current year, just in case? Either by enumerating all intervening years or doing a span, whichever is proper. Does the copyright in the footer on a site cover all content? Or should some content have individual copyright dates? Or all content have only the dates they had content written, such as "(c) 2003, 2005, 2007"? Can we distill this to a set of questions for a lawyer? Or do we have a practice we can use that covers us no matter what? Regardless, I'd like us to set a practice and follow it across all our content publication areas, source code to documentation. Do you agree? Thanks - 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 smooge at gmail.com Fri Mar 9 23:13:44 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 9 Mar 2007 16:13:44 -0700 Subject: copyright year question In-Reply-To: <1173479770.3935.283.camel@erato.phig.org> References: <1173479770.3935.283.camel@erato.phig.org> Message-ID: <80d7e4090703091513u7d375ff6v7dddaf9aa5c3676a@mail.gmail.com> On 3/9/07, Karsten Wade wrote: > We had a question come up, as I was updating some copyright years in a > few documents. What is the proper practice for writing and maintaining > years of copyright? We have documents that may represent a > work-in-time, and Websites that represent work-across-time. > > Should we only specify the years that new content was added to a body? > > Can we span years, e.g. "(c) 2003 - 2007", and have 2005 and 2006 > included? Or do we need to enumerate specific years that content is > added for it to be protected? I.e., "(c) 2003, 2004, 2005, 2006, 2007". > My memory from this is old.. but I think a document has to have the date that significant changes made to it listed seperately. This is definately where a lawyer versed in copyright come in because I only remember this from a discussion on RH webpages back in 1998 and I think he had to get an outside opinion. > Should we update copyright for all documents to the current year, just > in case? Either by enumerating all intervening years or doing a span, > whichever is proper. > > Does the copyright in the footer on a site cover all content? Or should > some content have individual copyright dates? Or all content have only > the dates they had content written, such as "(c) 2003, 2005, 2007"? > This was fuzzy back in 1998. It might have been clarified by now. > Can we distill this to a set of questions for a lawyer? Or do we have a > practice we can use that covers us no matter what? > You should have a practice written out at some point. The reason is that at some point as a corporate work, the copyright will end for some parts of the document.. and someone will have to figure what effect that remaining sentance that hasnt been changed in the year 2100 will have :). > Regardless, I'd like us to set a practice and follow it across all our > content publication areas, source code to documentation. Do you agree? > -- 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 kwade at redhat.com Mon Mar 12 22:58:34 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 12 Mar 2007 14:58:34 -0800 Subject: CLA circling to a solution Message-ID: <1173740314.3935.445.camel@erato.phig.org> A task I took from FUDCon was to write up a human-speak CLA, as well as figure out the level of hoops people need to go through to contribute at various levels. I'd like to get Greg to take these in front of a lawyer, so I'm trying to get the bugs out. Thoughts? Fixes? Opinions? http://fedoraproject.org/wiki/KarstenWade/Drafts/HumanSpeakCLA http://fedoraproject.org/wiki/KarstenWade/Drafts/CLAAcceptanceHierarchies Greg, you ready? - Karsten PS - watching the video from the FUDCon session "Lowering the Barriers ..." helped me to be sure all of our thoughts were caught here. Kudos to the value of video archives. -- 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 tchung at fedoraproject.org Mon Mar 12 23:03:08 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Mon, 12 Mar 2007 16:03:08 -0700 Subject: CLA circling to a solution In-Reply-To: <1173740314.3935.445.camel@erato.phig.org> References: <1173740314.3935.445.camel@erato.phig.org> Message-ID: <369bce3b0703121603x7bfa73b1h1a80b19a3658dfd1@mail.gmail.com> On 3/12/07, Karsten Wade wrote: >.. > PS - watching the video from the FUDCon session "Lowering the > Barriers ..." helped me to be sure all of our thoughts were caught here. > Kudos to the value of video archives. Speaking of FUDCon videos, are we ever going to upload them on YouTube or GoogleVideo? Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From sankar at redhat.com Tue Mar 13 12:49:24 2007 From: sankar at redhat.com (Sankarshan Mukhopadhyay) Date: Tue, 13 Mar 2007 18:19:24 +0530 Subject: Any ToDo list for Derived Distributions ? Message-ID: <45F69DD4.4070906@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Got this question off-hand a few days back as to whether there's a set of guidelines that needs to be followed (in terms of legalese etc) if someone wishes to create a Derived Distribution. The DerivedDistributions page on the wiki (and the links to LiveCD or Distribution) don't tell much in terms of a checklist of Dos and Don'ts :Sankarshan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF9p3U+g4kmZ76nyERAsKYAJ9Z/iZr6T/XCHaqWCcKhJMOLdpnNgCgpsse 0vILRo6jxExbekeMW0fcqxw= =Awhx -----END PGP SIGNATURE----- From sundaram at fedoraproject.org Tue Mar 13 14:26:54 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 13 Mar 2007 19:56:54 +0530 Subject: Any ToDo list for Derived Distributions ? In-Reply-To: <45F69DD4.4070906@redhat.com> References: <45F69DD4.4070906@redhat.com> Message-ID: <45F6B4AE.4040107@fedoraproject.org> Sankarshan Mukhopadhyay wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Got this question off-hand a few days back as to whether there's a set > of guidelines that needs to be followed (in terms of legalese etc) if > someone wishes to create a Derived Distribution. The > DerivedDistributions page on the wiki (and the links to LiveCD or > Distribution) don't tell much in terms of a checklist of Dos and Don'ts Pungi and Pilgrim should offer features that allows easy rebranding. Meanwhile you have: http://fedoraproject.org/wiki/Marketing/Branding http://fedoraproject.org/wiki/Legal/TrademarkGuidelines Rahul From mspevack at redhat.com Tue Mar 13 14:54:17 2007 From: mspevack at redhat.com (Max Spevack) Date: Tue, 13 Mar 2007 10:54:17 -0400 (EDT) Subject: fedora board meeting cancelled today Message-ID: With Board members out of town, getting married, or otherwise occupied, we won't be having our meeting today. The next meeting will be on March 20th. And now back to your regularly scheduled threads. --Max From blizzard at redhat.com Tue Mar 13 17:12:05 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 13 Mar 2007 13:12:05 -0400 Subject: Any ToDo list for Derived Distributions ? In-Reply-To: <45F69DD4.4070906@redhat.com> References: <45F69DD4.4070906@redhat.com> Message-ID: <1173805925.24092.4.camel@localhost.localdomain> On Tue, 2007-03-13 at 18:19 +0530, Sankarshan Mukhopadhyay wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Got this question off-hand a few days back as to whether there's a set > of guidelines that needs to be followed (in terms of legalese etc) if > someone wishes to create a Derived Distribution. The > DerivedDistributions page on the wiki (and the links to LiveCD or > Distribution) don't tell much in terms of a checklist of Dos and Don'ts I think the rule for branded derived distributions is to ask if you can use the mark. We want to know about them anywya. --Chris From kwade at redhat.com Wed Mar 14 19:29:24 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 14 Mar 2007 12:29:24 -0700 Subject: CLA circling to a solution In-Reply-To: <1173740314.3935.445.camel@erato.phig.org> References: <1173740314.3935.445.camel@erato.phig.org> Message-ID: <1173900564.23924.29.camel@erato.phig.org> On Mon, 2007-03-12 at 14:58 -0800, Karsten Wade wrote: > Greg, you ready? I connected with Greg today, and from that am submitting the plain-English and the CLA acceptance levels to our friendly legal counsel for review, comment, and etc. Once we have a working solution, we can apply that to the Wiki to open that doorway wider. - 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 max at spevack.org Thu Mar 15 06:02:36 2007 From: max at spevack.org (Max Spevack) Date: Thu, 15 Mar 2007 02:02:36 -0400 (EDT) Subject: Must Have for Fedora 7 Message-ID: So I didn't see anything like this on the wiki, but it seems like a reasonable enough page to mash together out of all the other project management type pages -- a "must have" page that enumerates the items that Fedora 7 simply cannot ship without. I ask you all to review it and comment. Keep in mind that it's an initial draft that I did at 1:30 in the morning, so I may have forgotten something blatantly obvious or have other large errors. Once we're happy, I'm going to make sure that Red Hat internal engineering all knows about it also. http://fedoraproject.org/wiki/Releases/7/MustHave I know I haven't been very active on this list recently -- my apologies for that. Been quite busy elsewhere, unfortunately a lot of it feels kind of behind the scenes. I'll post on my blog end of week/weekend a larger discussion of what I've been up to lately. --Max -- Max Spevack + http://spevack.org + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From sankar at redhat.com Thu Mar 15 06:19:09 2007 From: sankar at redhat.com (Sankarshan Mukhopadhyay) Date: Thu, 15 Mar 2007 11:49:09 +0530 Subject: Must Have for Fedora 7 In-Reply-To: References: Message-ID: <45F8E55D.4090509@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Max Spevack wrote: > http://fedoraproject.org/wiki/Releases/7/MustHave "Fedora 7 requires that the tools and documentation that make it as simple as possible to spin a custom distribution, using packages in Fedora as a base." What would be additionally useful is an explicit mention of: * What are the *cannot do* for the Custom Spins ? In terms of trademarks, 3rd Party Repos, 3rd Party Applications, Branding etc * A consistent messaging that the process of custom spins is not going to be one-off need based stuff but will have some bits from blessing from the Fedora Project Lead and those-who-matter * If required/requested Custom Spins (valid as per point #1) would be provided hosting infrastructure and their own their own subprojects lock-step with Fedora (Core) Going forward making a statement (if at all possible) that the Fedora tree of binaries and source bits are stuff from which folks are welcome to do spins (subject to clauses) and the Fedora project does its own spins called "Fedora" :Sankarshan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF+OVd+g4kmZ76nyERArFXAJ0R3RM/zGq7N1kcYtvi+b14tcd8mwCfYf5h yjxTwY3gLaE3f6ue5K+u+po= =OUhU -----END PGP SIGNATURE----- From jkeating at redhat.com Thu Mar 15 12:19:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Mar 2007 08:19:17 -0400 Subject: Must Have for Fedora 7 In-Reply-To: References: Message-ID: <200703150819.20871.jkeating@redhat.com> On Thursday 15 March 2007 02:02:36 Max Spevack wrote: > http://fedoraproject.org/wiki/Releases/7/MustHave I thought we passed on the idea of a Desktop like spin to fit on one CD. If the LiveCD is also installable, why create a second CD that is just installable? Cannot the LiveCD fulfill both the Live role and the 'single cd install' role for both Gnome and KDE? This would leave the Prime spin for pure installable media. Also missing was what I thought the board meeting at the summit decided, an "Everything" spin. There seems to be a sufficient usage case for creating such a beast, and fairly easy with pungi to just do a manifest of '*'. -- 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 Mar 15 12:44:18 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 15 Mar 2007 07:44:18 -0500 Subject: Must Have for Fedora 7 In-Reply-To: References: Message-ID: <1173962658.3413.14.camel@zod.rchland.ibm.com> On Thu, 2007-03-15 at 02:02 -0400, Max Spevack wrote: > So I didn't see anything like this on the wiki, but it seems like a > reasonable enough page to mash together out of all the other project > management type pages -- a "must have" page that enumerates the items that > Fedora 7 simply cannot ship without. > > I ask you all to review it and comment. Keep in mind that it's an initial > draft that I did at 1:30 in the morning, so I may have forgotten something > blatantly obvious or have other large errors. Once we're happy, I'm going > to make sure that Red Hat internal engineering all knows about it also. > > http://fedoraproject.org/wiki/Releases/7/MustHave > The first part should probably read: "Fedora Core and Fedora Extras must be merged into a single source control system and use a single buildsystem, creating a new package set that carries the already overloaded name Fedora." Also, I would move the buildsystem parts from the "Ability to spin a custom..." section to the "Merge Core and Extras" section. Spinning a custom distro/LiveCD is done with already built packages and the buildsys is really needed as part of the merge. Pilgrim is now called "livecd-utils". You can put my name next to yours as a guinea pig for the custom spin stuff. The LiveCDs are installable. I don't think we need a separate install iso outside of those for Gnome and KDE. josh From jkeating at redhat.com Thu Mar 15 13:13:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Mar 2007 09:13:24 -0400 Subject: Must Have for Fedora 7 In-Reply-To: <1173962658.3413.14.camel@zod.rchland.ibm.com> References: <1173962658.3413.14.camel@zod.rchland.ibm.com> Message-ID: <200703150913.24513.jkeating@redhat.com> On Thursday 15 March 2007 08:44:18 Josh Boyer wrote: > Also, I would move the buildsystem parts from the "Ability to spin a > custom..." section to the "Merge Core and Extras" section. ?Spinning a > custom distro/LiveCD is done with already built packages and the > buildsys is really needed as part of the merge. Well to be fair, the compose tool only needs yum repos to work with and it doesn't really care where those repos come from. The person running the tool (me) really cares about where they come from and how they are generated though (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Mar 15 13:20:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Mar 2007 09:20:29 -0400 Subject: Vendor and Packager for merged Fedora Message-ID: <200703150920.29270.jkeating@redhat.com> Vendor and Packager tags in the rpms that are currently in Core have: Vendor: Red Hat, Inc. Packager : Red Hat, Inc. and during build, _host is set to -redhat-linux Extras has: Vendor: Fedora Project Packager : Fedora Project and I'm not sure what _host is set to during build. These are all things configurable with Koji. In the merged world, does anybody have objections to using what Extras does now for Vendor and Packager? I'm not sure what all _host is uses for, but I know there are some package (I think mozilla/firefox) that care about it, and I'm reluctant to change what it is set for internally right now. -- 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 skvidal at linux.duke.edu Thu Mar 15 13:51:50 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 15 Mar 2007 09:51:50 -0400 Subject: Vendor and Packager for merged Fedora In-Reply-To: <200703150920.29270.jkeating@redhat.com> References: <200703150920.29270.jkeating@redhat.com> Message-ID: <1173966710.20424.192.camel@cutter> On Thu, 2007-03-15 at 09:20 -0400, Jesse Keating wrote: > Vendor and Packager tags in the rpms that are currently in Core have: > > Vendor: Red Hat, Inc. > Packager : Red Hat, Inc. > > and during build, _host is set to -redhat-linux > > Extras has: > > Vendor: Fedora Project > Packager : Fedora Project > I think this one makes sense for all pkgs > and I'm not sure what _host is set to during build. > > These are all things configurable with Koji. In the merged world, does > anybody have objections to using what Extras does now for Vendor and > Packager? > > I'm not sure what all _host is uses for, but I know there are some package (I > think mozilla/firefox) that care about it, and I'm reluctant to change what > it is set for internally right now. I would say leave it for now and change it as the first thing we do for f8/rawhide once f7 is out. -sv From jwboyer at jdub.homelinux.org Thu Mar 15 14:00:14 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 15 Mar 2007 09:00:14 -0500 Subject: Vendor and Packager for merged Fedora In-Reply-To: <1173966710.20424.192.camel@cutter> References: <200703150920.29270.jkeating@redhat.com> <1173966710.20424.192.camel@cutter> Message-ID: <1173967214.3413.18.camel@zod.rchland.ibm.com> On Thu, 2007-03-15 at 09:51 -0400, seth vidal wrote: > On Thu, 2007-03-15 at 09:20 -0400, Jesse Keating wrote: > > Vendor and Packager tags in the rpms that are currently in Core have: > > > > Vendor: Red Hat, Inc. > > Packager : Red Hat, Inc. > > > > and during build, _host is set to -redhat-linux > > > > Extras has: > > > > Vendor: Fedora Project > > Packager : Fedora Project > > > > I think this one makes sense for all pkgs > > > > and I'm not sure what _host is set to during build. > > > > These are all things configurable with Koji. In the merged world, does > > anybody have objections to using what Extras does now for Vendor and > > Packager? > > > > I'm not sure what all _host is uses for, but I know there are some package (I > > think mozilla/firefox) that care about it, and I'm reluctant to change what > > it is set for internally right now. > > I would say leave it for now and change it as the first thing we do for > f8/rawhide once f7 is out. +1 josh From mspevack at redhat.com Thu Mar 15 14:19:16 2007 From: mspevack at redhat.com (Max Spevack) Date: Thu, 15 Mar 2007 10:19:16 -0400 (EDT) Subject: Must Have for Fedora 7 In-Reply-To: <1173962658.3413.14.camel@zod.rchland.ibm.com> References: <1173962658.3413.14.camel@zod.rchland.ibm.com> Message-ID: On Thu, 15 Mar 2007, Josh Boyer wrote: > The first part should probably read: > > "Fedora Core and Fedora Extras must be merged into a single source > control system and use a single buildsystem, creating a new package set > that carries the already overloaded name Fedora." > > Also, I would move the buildsystem parts from the "Ability to spin a > custom..." section to the "Merge Core and Extras" section. Spinning a > custom distro/LiveCD is done with already built packages and the > buildsys is really needed as part of the merge. > > Pilgrim is now called "livecd-utils". > > You can put my name next to yours as a guinea pig for the custom spin > stuff. > > The LiveCDs are installable. I don't think we need a separate install > iso outside of those for Gnome and KDE. +1 on Josh and Jesse's stuff. I'll make changes. You guys can make changes too -- I don't need to be the only person editing the page. Like I said, it was late at night, and this stuff was on my mind and stopping me from sleeping, so I just spat out a draft. Now it's normal hours and we make it "correct". --Max From rdieter at math.unl.edu Thu Mar 15 14:21:07 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 15 Mar 2007 09:21:07 -0500 Subject: Vendor and Packager for merged Fedora In-Reply-To: <200703150920.29270.jkeating@redhat.com> References: <200703150920.29270.jkeating@redhat.com> Message-ID: <45F95653.3090501@math.unl.edu> Jesse Keating wrote: > Vendor and Packager tags in the rpms that are currently in Core have: > > Vendor: Red Hat, Inc. > Packager : Red Hat, Inc. > > and during build, _host is set to -redhat-linux > > Extras has: > > Vendor: Fedora Project > Packager : Fedora Project > > and I'm not sure what _host is set to during build. > > These are all things configurable with Koji. In the merged world, does > anybody have objections to using what Extras does now for Vendor and > Packager? no objection, good idea, +1 > I'm not sure what all _host is uses for, but I know there are some package (I > think mozilla/firefox) that care about it, and I'm reluctant to change what > it is set for internally right now. this one has potential to break a lot of things (configure scripts, auto*foo), tread carefully. -- Rex From notting at redhat.com Thu Mar 15 14:17:57 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Mar 2007 10:17:57 -0400 Subject: Vendor and Packager for merged Fedora In-Reply-To: <45F95653.3090501@math.unl.edu> References: <200703150920.29270.jkeating@redhat.com> <45F95653.3090501@math.unl.edu> Message-ID: <20070315141757.GB1802@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > >I'm not sure what all _host is uses for, but I know there are some package > >(I think mozilla/firefox) that care about it, and I'm reluctant to change > >what it is set for internally right now. > > this one has potential to break a lot of things (configure scripts, > auto*foo), tread carefully. In fact, it might be worth it to frob the value, run off one of Matt's mass rebuild tests, and see a) what fails b) what file paths/scripts/etc end up diferent. Bill From jkeating at redhat.com Thu Mar 15 14:32:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Mar 2007 10:32:06 -0400 Subject: Vendor and Packager for merged Fedora In-Reply-To: <20070315141757.GB1802@nostromo.devel.redhat.com> References: <200703150920.29270.jkeating@redhat.com> <45F95653.3090501@math.unl.edu> <20070315141757.GB1802@nostromo.devel.redhat.com> Message-ID: <200703151032.06716.jkeating@redhat.com> On Thursday 15 March 2007 10:17:57 Bill Nottingham wrote: > In fact, it might be worth it to frob the value, run off one of Matt's > mass rebuild tests, and see a) what fails b) what file paths/scripts/etc > end up diferent. I believe this is setable in mock configs so should be pretty easy for Matt to do this. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mspevack at redhat.com Thu Mar 15 14:59:57 2007 From: mspevack at redhat.com (Max Spevack) Date: Thu, 15 Mar 2007 10:59:57 -0400 (EDT) Subject: Must Have for Fedora 7 (v2) In-Reply-To: References: Message-ID: http://fedoraproject.org/wiki/Releases/7/MustHave Version 2 is up, fixing my blatant errors from last night and clarifying a few other things. Feel free to edit wiki directly or keep commenting on list. Would it be best to restart this thread on fedora-devel-list? I wanted to work out any major problems on this list first. --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 jkeating at redhat.com Thu Mar 15 15:08:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Mar 2007 11:08:24 -0400 Subject: Must Have for Fedora 7 (v2) In-Reply-To: References: Message-ID: <200703151108.25024.jkeating@redhat.com> On Thursday 15 March 2007 10:59:57 Max Spevack wrote: > Version 2 is up, fixing my blatant errors from last night and clarifying a > few other things. ?Feel free to edit wiki directly or keep commenting on > list. > > Would it be best to restart this thread on fedora-devel-list? > > I wanted to work out any major problems on this list first. I think the current copy looks good enough to unleash (: -- 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 sankar at redhat.com Thu Mar 15 15:12:58 2007 From: sankar at redhat.com (Sankarshan Mukhopadhyay) Date: Thu, 15 Mar 2007 20:42:58 +0530 Subject: Must Have for Fedora 7 (v2) In-Reply-To: References: Message-ID: <45F9627A.4070901@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Max Spevack wrote: > http://fedoraproject.org/wiki/Releases/7/MustHave > > Version 2 is up, fixing my blatant errors from last night and clarifying > a few other things. Feel free to edit wiki directly or keep commenting > on list. Looks cuddly enough to be unleashed (or as they said "On my command unleash hell :P) :SM ps: Those legal bits about custom spins don't yet have owners assigned -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF+WJ6+g4kmZ76nyERAmRSAJ47FnBONV/yM9/h5JROB3GeYyesvgCgop/Z q9c2oSKDFk/h/8tu1AOb81c= =BPtM -----END PGP SIGNATURE----- From mspevack at redhat.com Thu Mar 15 15:15:13 2007 From: mspevack at redhat.com (Max Spevack) Date: Thu, 15 Mar 2007 11:15:13 -0400 (EDT) Subject: Must Have for Fedora 7 (v2) In-Reply-To: <200703151108.25024.jkeating@redhat.com> References: <200703151108.25024.jkeating@redhat.com> Message-ID: On Thu, 15 Mar 2007, Jesse Keating wrote: > On Thursday 15 March 2007 10:59:57 Max Spevack wrote: >> Version 2 is up, fixing my blatant errors from last night and clarifying a >> few other things. ?Feel free to edit wiki directly or keep commenting on >> list. >> >> Would it be best to restart this thread on fedora-devel-list? >> >> I wanted to work out any major problems on this list first. > > I think the current copy looks good enough to unleash (: Ok, I'll re-post over there. Let's end this thread now so we can keep the discussion on one list at a time. --Max From notting at redhat.com Thu Mar 15 15:21:45 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Mar 2007 11:21:45 -0400 Subject: Must Have for Fedora 7 (v2) In-Reply-To: References: Message-ID: <20070315152145.GA2294@nostromo.devel.redhat.com> Max Spevack (mspevack at redhat.com) said: > Would it be best to restart this thread on fedora-devel-list? Perhaps links to the feature list entries for these things? Bill From Axel.Thimm at ATrpms.net Fri Mar 16 22:55:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 16 Mar 2007 23:55:43 +0100 Subject: Vendor and Packager for merged Fedora In-Reply-To: <200703150920.29270.jkeating@redhat.com> References: <200703150920.29270.jkeating@redhat.com> Message-ID: <20070316225543.GD15623@neu.nirvana> On Thu, Mar 15, 2007 at 09:20:29AM -0400, Jesse Keating wrote: > Vendor and Packager tags in the rpms that are currently in Core have: > > Vendor: Red Hat, Inc. > Packager : Red Hat, Inc. > > and during build, _host is set to -redhat-linux > > Extras has: > > Vendor: Fedora Project > Packager : Fedora Project > > and I'm not sure what _host is set to during build. > > These are all things configurable with Koji. In the merged world, does > anybody have objections to using what Extras does now for Vendor and > Packager? Maybe instead of http://bugzilla.redhat.com/bugzilla direct the URL to simply fp.o? > I'm not sure what all _host is uses for, but I know there are some package (I > think mozilla/firefox) that care about it, and I'm reluctant to change what > it is set for internally right now. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Mar 16 23:01:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Mar 2007 19:01:48 -0400 Subject: Vendor and Packager for merged Fedora In-Reply-To: <20070316225543.GD15623@neu.nirvana> References: <200703150920.29270.jkeating@redhat.com> <20070316225543.GD15623@neu.nirvana> Message-ID: <200703161901.48641.jkeating@redhat.com> On Friday 16 March 2007 18:55:43 Axel Thimm wrote: > Maybe instead of http://bugzilla.redhat.com/bugzilla direct the URL to > simply fp.o? Sure, so long as we make it painfully clear in the wiki landing page how to file bugs (: -- 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 Axel.Thimm at ATrpms.net Fri Mar 16 23:08:39 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 17 Mar 2007 00:08:39 +0100 Subject: Vendor and Packager for merged Fedora In-Reply-To: <200703161901.48641.jkeating@redhat.com> References: <200703150920.29270.jkeating@redhat.com> <20070316225543.GD15623@neu.nirvana> <200703161901.48641.jkeating@redhat.com> Message-ID: <20070316230839.GA21829@neu.nirvana> On Fri, Mar 16, 2007 at 07:01:48PM -0400, Jesse Keating wrote: > On Friday 16 March 2007 18:55:43 Axel Thimm wrote: > > Maybe instead of http://bugzilla.redhat.com/bugzilla direct the URL to > > simply fp.o? > > Sure, so long as we make it painfully clear in the wiki landing page how to > file bugs (: Indeed, it should get on the frontpage somewhere, which it currently isn't. Maybe next to the spot where "Common Issues" are mentioned. It is semantically close and rather prominent. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Mar 16 23:27:53 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 17 Mar 2007 04:57:53 +0530 Subject: Vendor and Packager for merged Fedora In-Reply-To: <20070316230839.GA21829@neu.nirvana> References: <200703150920.29270.jkeating@redhat.com> <20070316225543.GD15623@neu.nirvana> <200703161901.48641.jkeating@redhat.com> <20070316230839.GA21829@neu.nirvana> Message-ID: <45FB27F9.1030706@fedoraproject.org> Axel Thimm wrote: > On Fri, Mar 16, 2007 at 07:01:48PM -0400, Jesse Keating wrote: >> On Friday 16 March 2007 18:55:43 Axel Thimm wrote: >>> Maybe instead of http://bugzilla.redhat.com/bugzilla direct the URL to >>> simply fp.o? >> Sure, so long as we make it painfully clear in the wiki landing page how to >> file bugs (: > > Indeed, it should get on the frontpage somewhere, which it currently > isn't. Maybe next to the spot where "Common Issues" are mentioned. It > is semantically close and rather prominent. Done. http://fedoraproject.org Rahul From fedora at leemhuis.info Sun Mar 18 14:38:25 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 18 Mar 2007 15:38:25 +0100 Subject: @FESCo (and in parts maybe for the Board, too): How to handle packaging issues for EPEL? Message-ID: <45FD4EE1.3020309@leemhuis.info> Hi, there are more and more discussions about packaging issues in EPEL (repotag, fedora-usermgmt) where people request EPEL-specific packaging rules that are different from the ones used in Fedora, that got and get defined by the Packaging Committee. Having special packaging rules in EPEL could afaics lead to situations where packages aren't easily portable between Fedora and EPEL. I think this would be qite bad and not what we want -- especially in the long term. To avoid that I'd like to ask FESCo and the Board to clarify the position of the Packaging Committee and its relation to EPEL as well as what Packaging rules get used for EPEL. It's afaics like this: The Packaging Committee handles all issues around Packaging for both Fedora and EPEL. The EPEL-SIG can define rules about maintaining packages in the repo (like for example the "Package Maintenance And Updates policy for EPEL "http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates ), but no exceptions for "theoretical" packaging (e.g. how to write spec files) itself. Is this correct? Do you guys want something different? If this is correct: Can you please make something like the above official then? CU thl P.S.: This mail is my own opinion -- I'm not sending this on behalf of the EPEL-SIG From bpepple at fedoraproject.org Sun Mar 18 14:58:19 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 18 Mar 2007 10:58:19 -0400 Subject: @FESCo (and in parts maybe for the Board, too): How to handle packaging issues for EPEL? In-Reply-To: <45FD4EE1.3020309@leemhuis.info> References: <45FD4EE1.3020309@leemhuis.info> Message-ID: <1174229899.7857.9.camel@lincoln> On Sun, 2007-03-18 at 15:38 +0100, Thorsten Leemhuis wrote: > > It's afaics like this: The Packaging Committee handles all issues around > Packaging for both Fedora and EPEL. The EPEL-SIG can define rules about > maintaining packages in the repo (like for example the "Package > Maintenance And Updates policy for EPEL > "http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates > ), but no exceptions for "theoretical" packaging (e.g. how to write spec > files) itself. > > Is this correct? Do you guys want something different? Seems like a reasonable policy. Is there anyone on the Packaging Committee that is also involved in EPEL? If not, there probably should be. /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 fedora at leemhuis.info Sun Mar 18 15:02:55 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 18 Mar 2007 16:02:55 +0100 Subject: @FESCo (and in parts maybe for the Board, too): How to handle packaging issues for EPEL? In-Reply-To: <1174229899.7857.9.camel@lincoln> References: <45FD4EE1.3020309@leemhuis.info> <1174229899.7857.9.camel@lincoln> Message-ID: <45FD549F.6090105@leemhuis.info> Brian Pepple schrieb: > On Sun, 2007-03-18 at 15:38 +0100, Thorsten Leemhuis wrote: >> It's afaics like this: The Packaging Committee handles all issues around >> Packaging for both Fedora and EPEL. The EPEL-SIG can define rules about >> maintaining packages in the repo (like for example the "Package >> Maintenance And Updates policy for EPEL >> "http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates >> ), but no exceptions for "theoretical" packaging (e.g. how to write spec >> files) itself. >> Is this correct? Do you guys want something different? > Seems like a reasonable policy. Is there anyone on the Packaging > Committee that is also involved in EPEL? If not, there probably should > be. Axel Thimm is members of both groups. Spot himself is interested in EPEL afaics, too. Rex seems to be interested in EPEL a bit as well. Cu thl From bugs.michael at gmx.net Sun Mar 18 17:13:26 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 18 Mar 2007 18:13:26 +0100 Subject: @FESCo (and in parts maybe for the Board, too): How to handle packaging issues for EPEL? In-Reply-To: <45FD4EE1.3020309@leemhuis.info> References: <45FD4EE1.3020309@leemhuis.info> Message-ID: <20070318181326.3c105739.bugs.michael@gmx.net> On Sun, 18 Mar 2007 15:38:25 +0100, Thorsten Leemhuis wrote: > Hi, > > there are more and more discussions about packaging issues in EPEL > (repotag, fedora-usermgmt) where people request EPEL-specific packaging > rules that are different from the ones used in Fedora, that got and get > defined by the Packaging Committee. It has not been decided on fedora-usermgmt before. Neither by FESCO, nor by the Packaging Committee. It remains an optional tool that is not mentioned in the guidelines. It has not been decided on "a repotag" before. Using %dist is still optional. And that is good. If I understand the request correctly, there is the desire to make a repotag mandatory. When doing that, it would conflict with an optional %dist tag. Even longer file names. Even more information that influences RPM version comparison. Where a forward-looking requirement of "foo > 1.0-3" used to be accurate enough, packagers already need to be more careful and consider the dist tag, because "foo-1.0-3.fc7" is > 1.0-3 only because of the dist tag. Another macro that is added to the package %release value won't make it better. By looking at only a file name you cannot tell anyway who built the package. From fedora at leemhuis.info Sun Mar 18 17:19:19 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 18 Mar 2007 18:19:19 +0100 Subject: @FESCo (and in parts maybe for the Board, too): How to handle packaging issues for EPEL? In-Reply-To: <20070318181326.3c105739.bugs.michael@gmx.net> References: <45FD4EE1.3020309@leemhuis.info> <20070318181326.3c105739.bugs.michael@gmx.net> Message-ID: <45FD7497.1060801@leemhuis.info> Michael Schwendt schrieb: > On Sun, 18 Mar 2007 15:38:25 +0100, Thorsten Leemhuis wrote: >> there are more and more discussions about packaging issues in EPEL >> (repotag, fedora-usermgmt) where people request EPEL-specific packaging >> rules that are different from the ones used in Fedora, that got and get >> defined by the Packaging Committee. > It has not been decided on fedora-usermgmt before. Neither by FESCO, nor > by the Packaging Committee. It remains an optional tool that is not > mentioned in the guidelines. But some people want to forbid it now, so seems we need a decision now. > It has not been decided on "a repotag" before. But some people want to enforce one now, so seems we need a decision now. Side note: It seems a repotag is unwanted by the Packaging Committee leader, so EPEL is just careful here and doesn't want to set facts against the Committee with should deal with this. If they say "EPEL SIG decides" then it's fine for me. > Using %dist is still optional. And that is good. +1 > If I understand the request correctly, there is the desire to make a repotag > mandatory. When doing that, it would conflict with an optional %dist tag. Why? It could be in the spec files as Release: 1%{?dist}%{?rel} or something like that. > Even longer file names. Even more information that influences RPM version > comparison. [...] Agreed to this and parts of the other stuff that I stripped. That why I asked the packaging committee to look into the issue: https://www.redhat.com/archives/fedora-packaging/2007-March/msg00079.html Cu thl From bugs.michael at gmx.net Sun Mar 18 18:06:27 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 18 Mar 2007 19:06:27 +0100 Subject: @FESCo (and in parts maybe for the Board, too): How to handle packaging issues for EPEL? In-Reply-To: <45FD7497.1060801@leemhuis.info> References: <45FD4EE1.3020309@leemhuis.info> <20070318181326.3c105739.bugs.michael@gmx.net> <45FD7497.1060801@leemhuis.info> Message-ID: <20070318190627.802da8bd.bugs.michael@gmx.net> On Sun, 18 Mar 2007 18:19:19 +0100, Thorsten Leemhuis wrote: > > It has not been decided on fedora-usermgmt before. Neither by FESCO, nor > > by the Packaging Committee. It remains an optional tool that is not > > mentioned in the guidelines. > > But some people want to forbid it now, so seems we need a decision now. So what? EPEL has different [and special] requirements anyway. I've written more about that in one of the threads about fedora-usermgmt. EPEL may decide independently on such things. If, however, it is about something in the Fedora guidelines, we should be careful when we want to keep a close relationship with RHEL. fedora-usermgmt is not in the guidelines yet. > > It has not been decided on "a repotag" before. > > But some people want to enforce one now, so seems we need a decision now. 2x now is not true, however. The repotag issue is not a show-stopper. > > If I understand the request correctly, there is the desire to make a repotag > > mandatory. When doing that, it would conflict with an optional %dist tag. > > Why? It could be in the spec files as > > Release: 1%{?dist}%{?rel} > > or something like that. Both values, if defined and expanded, are added to the %{release} value wherever that one is used, e.g. in sub-package requirements and automatic dependencies. When %dist remains optional, you compare %dist and %rel or vice versa. In manually added versioned dependencies (or also Obsoletes and Provides), both macros are omitted. In the %changelog they are omitted, too. [As a side-note, it is already worse enough when packagers copy a %dist-ified spec file for one dist to another dist, wiping and overwriting previous changelog entries.] From rdieter at math.unl.edu Sun Mar 18 18:23:14 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 18 Mar 2007 13:23:14 -0500 Subject: @FESCo (and in parts maybe for the Board, too): How to handle packaging issues for EPEL? In-Reply-To: <45FD7497.1060801@leemhuis.info> References: <45FD4EE1.3020309@leemhuis.info> <20070318181326.3c105739.bugs.michael@gmx.net> <45FD7497.1060801@leemhuis.info> Message-ID: <45FD8392.7020409@math.unl.edu> Thorsten Leemhuis wrote: > Side note: It seems a repotag is unwanted by the Packaging Committee > leader, so EPEL is just careful here and doesn't want to set facts > against the Committee with should deal with this. If they say "EPEL SIG > decides" then it's fine for me. Imo, "EPEL SIG decides" or "no repotag" will be the most likely answers you will get from the PC. -- Rex From tcallawa at redhat.com Mon Mar 19 02:10:25 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 18 Mar 2007 21:10:25 -0500 Subject: @FESCo (and in parts maybe for the Board, too): How to handle packaging issues for EPEL? In-Reply-To: <45FD8392.7020409@math.unl.edu> References: <45FD4EE1.3020309@leemhuis.info> <20070318181326.3c105739.bugs.michael@gmx.net> <45FD7497.1060801@leemhuis.info> <45FD8392.7020409@math.unl.edu> Message-ID: <1174270225.4310.33.camel@localhost.localdomain> On Sun, 2007-03-18 at 13:23 -0500, Rex Dieter wrote: > Thorsten Leemhuis wrote: > > > Side note: It seems a repotag is unwanted by the Packaging Committee > > leader, so EPEL is just careful here and doesn't want to set facts > > against the Committee with should deal with this. If they say "EPEL SIG > > decides" then it's fine for me. > > Imo, "EPEL SIG decides" or "no repotag" will be the most likely answers > you will get from the PC. I'd rather see the Vendor tag used for the "repotag" purpose than overloading Release. ~spot From jkeating at redhat.com Mon Mar 19 12:28:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Mar 2007 08:28:53 -0400 Subject: @FESCo (and in parts maybe for the Board, too): How to handle packaging issues for EPEL? In-Reply-To: <1174270225.4310.33.camel@localhost.localdomain> References: <45FD4EE1.3020309@leemhuis.info> <45FD8392.7020409@math.unl.edu> <1174270225.4310.33.camel@localhost.localdomain> Message-ID: <200703190828.53868.jkeating@redhat.com> On Sunday 18 March 2007 22:10:25 Tom 'spot' Callaway wrote: > I'd rather see the Vendor tag used for the "repotag" purpose than > overloading Release. +1. Although vendor tag is just as fakeable. gpg key is about the only sure way too tell. -- 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 Axel.Thimm at ATrpms.net Mon Mar 19 16:18:37 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Mar 2007 17:18:37 +0100 Subject: fesco, fpc and epel relationships (was: How to handle packaging issues for EPEL?) In-Reply-To: <45FD4EE1.3020309@leemhuis.info> References: <45FD4EE1.3020309@leemhuis.info> Message-ID: <20070319161837.GC2212@neu.nirvana> Hi, On Sun, Mar 18, 2007 at 03:38:25PM +0100, Thorsten Leemhuis wrote: > To avoid that I'd like to ask FESCo and the Board to clarify the > position of the Packaging Committee and its relation to EPEL as well as > what Packaging rules get used for EPEL. I think setting up mandates and formal relationships between the various groups is important. Given that currently most FPC members are not really into RHEL, and that in the past whenever a RHEL rule was being discussed it was (IMHO wrongly) most often simply dumped, because "we are Fedora, not RHEL" the FPC needs to know its current responsibilities. It is also important to really have an EPEL entity. Various questions that are being raised are either resolved due to 100% consensus or not at all ATM. The fedora-usermgmt and repotag topics are two rather less important issues that after a given timeframe could have been simply voted on by EPEL, but since it is not recognizing itself yet as a voting body it is floating rather helpless in the floods of infinite threads trying to outsource these questions to Fedora, fesco, fpc etc. There is no doubt that some parts need to be controlled by fesco and higher organs, but it could be like for the packaging group: the FPC makes some decisions and fesco ratifies them. Why not copy the same model to the EPEL and fesco relationship? An EPEL SIG or call it board/committee/anything is formed that votes on proposals and forwards them to fesco to ratify. If you're looking for a short acronym I'd recommend FEG/FEC (Fedora Enterprise Group/Committee). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Mon Mar 19 16:22:18 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 19 Mar 2007 11:22:18 -0500 Subject: fesco, fpc and epel relationships In-Reply-To: <20070319161837.GC2212@neu.nirvana> References: <45FD4EE1.3020309@leemhuis.info> <20070319161837.GC2212@neu.nirvana> Message-ID: <45FEB8BA.2020100@redhat.com> Axel Thimm wrote: > Hi, > > On Sun, Mar 18, 2007 at 03:38:25PM +0100, Thorsten Leemhuis wrote: > >> To avoid that I'd like to ask FESCo and the Board to clarify the >> position of the Packaging Committee and its relation to EPEL as well as >> what Packaging rules get used for EPEL. >> > > I think setting up mandates and formal relationships between the > various groups is important. Given that currently most FPC members are > not really into RHEL, and that in the past whenever a RHEL rule was > being discussed it was (IMHO wrongly) most often simply dumped, > because "we are Fedora, not RHEL" the FPC needs to know its current > responsibilities. > Fedora is more than the operating system. Fedora = RedHat = Ford Fedora (OS) = RHEL = Mustang We aren't the OS, we produce the OS. -Mike From Axel.Thimm at ATrpms.net Mon Mar 19 16:29:52 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Mar 2007 17:29:52 +0100 Subject: fesco, fpc and epel relationships In-Reply-To: <45FEB8BA.2020100@redhat.com> References: <45FD4EE1.3020309@leemhuis.info> <20070319161837.GC2212@neu.nirvana> <45FEB8BA.2020100@redhat.com> Message-ID: <20070319162952.GE2212@neu.nirvana> On Mon, Mar 19, 2007 at 11:22:18AM -0500, Mike McGrath wrote: > > I think setting up mandates and formal relationships between the > > various groups is important. Given that currently most FPC members > > are not really into RHEL, and that in the past whenever a RHEL > > rule was being discussed it was (IMHO wrongly) most often simply > > dumped, because "we are Fedora, not RHEL" the FPC needs to know > > its current responsibilities. > > > Fedora is more than the operating system. > > Fedora = RedHat = Ford > Fedora (OS) = RHEL = Mustang > > We aren't the OS, we produce the OS. You mean in relation to the quote I gave above: "we are Fedora, not RHEL"? The longer version is "We are creating guidelines for packaging within Fedora Core and Fedora Extras and base them on the demand of these users and packagers. We are not taking into account special requirements that are outside this scope, e.g. when they are RHEL specific, because we don't write guidelines for RHEL". That statement most probably doesn't hold true anymore, but someone needs to pass the responsibilities and mandate down to the FPC. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Mon Mar 19 16:38:35 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 19 Mar 2007 11:38:35 -0500 Subject: fesco, fpc and epel relationships In-Reply-To: <20070319162952.GE2212@neu.nirvana> References: <45FD4EE1.3020309@leemhuis.info> <20070319161837.GC2212@neu.nirvana> <45FEB8BA.2020100@redhat.com> <20070319162952.GE2212@neu.nirvana> Message-ID: <1174322315.3484.12.camel@dhcp120.install.boston.redhat.com> On Mon, 2007-03-19 at 17:29 +0100, Axel Thimm wrote: > On Mon, Mar 19, 2007 at 11:22:18AM -0500, Mike McGrath wrote: > > > I think setting up mandates and formal relationships between the > > > various groups is important. Given that currently most FPC members > > > are not really into RHEL, and that in the past whenever a RHEL > > > rule was being discussed it was (IMHO wrongly) most often simply > > > dumped, because "we are Fedora, not RHEL" the FPC needs to know > > > its current responsibilities. > > > > > Fedora is more than the operating system. > > > > Fedora = RedHat = Ford > > Fedora (OS) = RHEL = Mustang > > > > We aren't the OS, we produce the OS. > > You mean in relation to the quote I gave above: "we are Fedora, not > RHEL"? > > The longer version is "We are creating guidelines for packaging within > Fedora Core and Fedora Extras and base them on the demand of these > users and packagers. We are not taking into account special > requirements that are outside this scope, e.g. when they are RHEL > specific, because we don't write guidelines for RHEL". > > That statement most probably doesn't hold true anymore, but someone > needs to pass the responsibilities and mandate down to the FPC. I don't see why the FPC can't do "EPEL" specific guidelines where relevant. ~spot From Axel.Thimm at ATrpms.net Mon Mar 19 16:44:24 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Mar 2007 17:44:24 +0100 Subject: fesco, fpc and epel relationships In-Reply-To: <1174322315.3484.12.camel@dhcp120.install.boston.redhat.com> References: <45FD4EE1.3020309@leemhuis.info> <20070319161837.GC2212@neu.nirvana> <45FEB8BA.2020100@redhat.com> <20070319162952.GE2212@neu.nirvana> <1174322315.3484.12.camel@dhcp120.install.boston.redhat.com> Message-ID: <20070319164424.GB14393@neu.nirvana> On Mon, Mar 19, 2007 at 11:38:35AM -0500, Tom 'spot' Callaway wrote: > On Mon, 2007-03-19 at 17:29 +0100, Axel Thimm wrote: > > On Mon, Mar 19, 2007 at 11:22:18AM -0500, Mike McGrath wrote: > > > > I think setting up mandates and formal relationships between the > > > > various groups is important. Given that currently most FPC members > > > > are not really into RHEL, and that in the past whenever a RHEL > > > > rule was being discussed it was (IMHO wrongly) most often simply > > > > dumped, because "we are Fedora, not RHEL" the FPC needs to know > > > > its current responsibilities. > > > > > > > Fedora is more than the operating system. > > > > > > Fedora = RedHat = Ford > > > Fedora (OS) = RHEL = Mustang > > > > > > We aren't the OS, we produce the OS. > > > > You mean in relation to the quote I gave above: "we are Fedora, not > > RHEL"? > > > > The longer version is "We are creating guidelines for packaging within > > Fedora Core and Fedora Extras and base them on the demand of these > > users and packagers. We are not taking into account special > > requirements that are outside this scope, e.g. when they are RHEL > > specific, because we don't write guidelines for RHEL". > > > > That statement most probably doesn't hold true anymore, but someone > > needs to pass the responsibilities and mandate down to the FPC. > > I don't see why the FPC can't do "EPEL" specific guidelines where > relevant. Neither do I, but we need the authority and commitment. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Mar 19 16:47:12 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 19 Mar 2007 17:47:12 +0100 Subject: fesco, fpc and epel relationships In-Reply-To: <20070319161837.GC2212@neu.nirvana> References: <45FD4EE1.3020309@leemhuis.info> <20070319161837.GC2212@neu.nirvana> Message-ID: <45FEBE90.5050106@leemhuis.info> Axel Thimm schrieb: > > It is also important to really have an EPEL entity. Just FYI on this list, I'm preparing something for a kind of EPEL Steering Committee in the next days to show to mailing lists and to FESCo afterwards. CU thl From tcallawa at redhat.com Mon Mar 19 16:46:31 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 19 Mar 2007 11:46:31 -0500 Subject: fesco, fpc and epel relationships In-Reply-To: <20070319164424.GB14393@neu.nirvana> References: <45FD4EE1.3020309@leemhuis.info> <20070319161837.GC2212@neu.nirvana> <45FEB8BA.2020100@redhat.com> <20070319162952.GE2212@neu.nirvana> <1174322315.3484.12.camel@dhcp120.install.boston.redhat.com> <20070319164424.GB14393@neu.nirvana> Message-ID: <1174322791.3484.14.camel@dhcp120.install.boston.redhat.com> On Mon, 2007-03-19 at 17:44 +0100, Axel Thimm wrote: > > I don't see why the FPC can't do "EPEL" specific guidelines where > > relevant. > > Neither do I, but we need the authority and commitment. No one has said that FPC doesn't have the authority. EPEL is a Fedora project. Thus, I hereby deem that FPC has the authority. As to the commitment, I have it. I can only speak for myself on such matters. ~spot From Axel.Thimm at ATrpms.net Mon Mar 19 16:59:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Mar 2007 17:59:15 +0100 Subject: fesco, fpc and epel relationships In-Reply-To: <1174322791.3484.14.camel@dhcp120.install.boston.redhat.com> References: <45FD4EE1.3020309@leemhuis.info> <20070319161837.GC2212@neu.nirvana> <45FEB8BA.2020100@redhat.com> <20070319162952.GE2212@neu.nirvana> <1174322315.3484.12.camel@dhcp120.install.boston.redhat.com> <20070319164424.GB14393@neu.nirvana> <1174322791.3484.14.camel@dhcp120.install.boston.redhat.com> Message-ID: <20070319165915.GF14393@neu.nirvana> On Mon, Mar 19, 2007 at 11:46:31AM -0500, Tom 'spot' Callaway wrote: > On Mon, 2007-03-19 at 17:44 +0100, Axel Thimm wrote: > > > > I don't see why the FPC can't do "EPEL" specific guidelines where > > > relevant. > > > > Neither do I, but we need the authority and commitment. > > No one has said that FPC doesn't have the authority. > EPEL is a Fedora project. > > Thus, I hereby deem that FPC has the authority. > > As to the commitment, I have it. I can only speak for myself on such > matters. Same here, so let's formalize it at tomorrow's IRC meeting (the commitment) and the authority is asserted until the board says otherwise. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Mar 19 17:13:06 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 19 Mar 2007 18:13:06 +0100 Subject: fesco, fpc and epel relationships In-Reply-To: <20070319165915.GF14393@neu.nirvana> References: <45FD4EE1.3020309@leemhuis.info> <20070319161837.GC2212@neu.nirvana> <45FEB8BA.2020100@redhat.com> <20070319162952.GE2212@neu.nirvana> <1174322315.3484.12.camel@dhcp120.install.boston.redhat.com> <20070319164424.GB14393@neu.nirvana> <1174322791.3484.14.camel@dhcp120.install.boston.redhat.com> <20070319165915.GF14393@neu.nirvana> Message-ID: <45FEC4A2.7070202@leemhuis.info> Axel Thimm schrieb: > On Mon, Mar 19, 2007 at 11:46:31AM -0500, Tom 'spot' Callaway wrote: >> On Mon, 2007-03-19 at 17:44 +0100, Axel Thimm wrote: >>>> I don't see why the FPC can't do "EPEL" specific guidelines where >>>> relevant. >>> Neither do I, but we need the authority and commitment. >> No one has said that FPC doesn't have the authority. >> EPEL is a Fedora project. >> Thus, I hereby deem that FPC has the authority. >> As to the commitment, I have it. I can only speak for myself on such >> matters. Thanks spot. > Same here, so let's formalize it at tomorrow's IRC meeting (the > commitment) and the authority is asserted until the board says > otherwise. Just to clarify: FESCo is the Committee above FPC (and below the Board) afaics; see https://www.redhat.com/archives/fedora-advisory-board/2007-January/msg00157.html That scheme was ACKed by the board IIRC, too. We really need to put this stuff (which committee is located where in the game and what is each Committee responsible for) into the wiki somewhere... CU thl From Axel.Thimm at ATrpms.net Mon Mar 19 17:19:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Mar 2007 18:19:38 +0100 Subject: fesco, fpc and epel relationships In-Reply-To: <45FEC4A2.7070202@leemhuis.info> References: <45FD4EE1.3020309@leemhuis.info> <20070319161837.GC2212@neu.nirvana> <45FEB8BA.2020100@redhat.com> <20070319162952.GE2212@neu.nirvana> <1174322315.3484.12.camel@dhcp120.install.boston.redhat.com> <20070319164424.GB14393@neu.nirvana> <1174322791.3484.14.camel@dhcp120.install.boston.redhat.com> <20070319165915.GF14393@neu.nirvana> <45FEC4A2.7070202@leemhuis.info> Message-ID: <20070319171938.GH14393@neu.nirvana> On Mon, Mar 19, 2007 at 06:13:06PM +0100, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > > On Mon, Mar 19, 2007 at 11:46:31AM -0500, Tom 'spot' Callaway wrote: > >> On Mon, 2007-03-19 at 17:44 +0100, Axel Thimm wrote: > >>>> I don't see why the FPC can't do "EPEL" specific guidelines where > >>>> relevant. > >>> Neither do I, but we need the authority and commitment. > >> No one has said that FPC doesn't have the authority. > >> EPEL is a Fedora project. > >> Thus, I hereby deem that FPC has the authority. > >> As to the commitment, I have it. I can only speak for myself on such > >> matters. > > Thanks spot. > > > Same here, so let's formalize it at tomorrow's IRC meeting (the > > commitment) and the authority is asserted until the board says > > otherwise. > > Just to clarify: FESCo is the Committee above FPC (and below the Board) > afaics; see > https://www.redhat.com/archives/fedora-advisory-board/2007-January/msg00157.html > > That scheme was ACKed by the board IIRC, too. I thought that was always the case and was well known to everyone involved. How does that fit in this discussion? Did anything of the above imply that the FPC is trying to get above FESCO? ;=) > We really need to put this stuff (which committee is located where in > the game and what is each Committee responsible for) into the wiki > somewhere... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Mar 19 17:30:00 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 19 Mar 2007 12:30:00 -0500 Subject: fesco, fpc and epel relationships In-Reply-To: <20070319171938.GH14393@neu.nirvana> References: <45FD4EE1.3020309@leemhuis.info> <20070319161837.GC2212@neu.nirvana> <45FEB8BA.2020100@redhat.com> <20070319162952.GE2212@neu.nirvana> <1174322315.3484.12.camel@dhcp120.install.boston.redhat.com> <20070319164424.GB14393@neu.nirvana> <1174322791.3484.14.camel@dhcp120.install.boston.redhat.com> <20070319165915.GF14393@neu.nirvana> <45FEC4A2.7070202@leemhuis.info> <20070319171938.GH14393@neu.nirvana> Message-ID: <45FEC898.5010605@math.unl.edu> Axel Thimm wrote: > On Mon, Mar 19, 2007 at 06:13:06PM +0100, Thorsten Leemhuis wrote: >> Axel Thimm schrieb: >> Just to clarify: FESCo is the Committee above FPC (and below the Board) >> afaics; see >> https://www.redhat.com/archives/fedora-advisory-board/2007-January/msg00157.html >> >> That scheme was ACKed by the board IIRC, too. > > I thought that was always the case and was well known to everyone > involved. True, but it wasn't previously codified or acknowledged as being official. -- Rex From fedora at leemhuis.info Mon Mar 19 17:37:09 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 19 Mar 2007 18:37:09 +0100 Subject: fesco, fpc and epel relationships In-Reply-To: <20070319171938.GH14393@neu.nirvana> References: <45FD4EE1.3020309@leemhuis.info> <20070319161837.GC2212@neu.nirvana> <45FEB8BA.2020100@redhat.com> <20070319162952.GE2212@neu.nirvana> <1174322315.3484.12.camel@dhcp120.install.boston.redhat.com> <20070319164424.GB14393@neu.nirvana> <1174322791.3484.14.camel@dhcp120.install.boston.redhat.com> <20070319165915.GF14393@neu.nirvana> <45FEC4A2.7070202@leemhuis.info> <20070319171938.GH14393@neu.nirvana> Message-ID: <45FECA45.4070608@leemhuis.info> Axel Thimm schrieb: > On Mon, Mar 19, 2007 at 06:13:06PM +0100, Thorsten Leemhuis wrote: >> Axel Thimm schrieb: >>> On Mon, Mar 19, 2007 at 11:46:31AM -0500, Tom 'spot' Callaway wrote: >>>> On Mon, 2007-03-19 at 17:44 +0100, Axel Thimm wrote: >>>>>> I don't see why the FPC can't do "EPEL" specific guidelines where >>>>>> relevant. >>>>> Neither do I, but we need the authority and commitment. >>>> No one has said that FPC doesn't have the authority. >>>> EPEL is a Fedora project. >>>> Thus, I hereby deem that FPC has the authority. >>>> As to the commitment, I have it. I can only speak for myself on such >>>> matters. >> Thanks spot. >> >>> Same here, so let's formalize it at tomorrow's IRC meeting (the >>> commitment) and the authority is asserted until the board says >>> otherwise. >> Just to clarify: FESCo is the Committee above FPC (and below the Board) >> afaics; see >> https://www.redhat.com/archives/fedora-advisory-board/2007-January/msg00157.html >> >> That scheme was ACKed by the board IIRC, too. > I thought that was always the case No, in the past the FPC was afaics kind of on the same level as Core and Extras Committee's, just that the latter had a kind of veto right. > and was well known to everyone > involved. How does that fit in this discussion? [...] It was you that started with sub-thread with "I think setting up mandates and formal relationships between the various groups is important." I this way wanted to agree with that and that's why I wrote: >> We really need to put this stuff (which committee is located where in >> the game and what is each Committee responsible for) into the wiki >> somewhere... Cu thl From mmcgrath at redhat.com Mon Mar 19 18:31:57 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 19 Mar 2007 13:31:57 -0500 Subject: Lessons Learned Message-ID: <45FED71D.3010801@redhat.com> What can we learn from this so we don't repeat it? http://linux.slashdot.org/linux/07/03/19/1522208.shtml -Mike From gdk at redhat.com Mon Mar 19 18:34:37 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Mon, 19 Mar 2007 14:34:37 -0400 (EDT) Subject: Lessons Learned In-Reply-To: <45FED71D.3010801@redhat.com> References: <45FED71D.3010801@redhat.com> Message-ID: On Mon, 19 Mar 2007, Mike McGrath wrote: > What can we learn from this so we don't repeat it? > > http://linux.slashdot.org/linux/07/03/19/1522208.shtml Make hard decisions when they need to be made. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From smooge at gmail.com Mon Mar 19 18:40:44 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 19 Mar 2007 12:40:44 -0600 Subject: Lessons Learned In-Reply-To: <45FED71D.3010801@redhat.com> References: <45FED71D.3010801@redhat.com> Message-ID: <80d7e4090703191140n24a2e52fob7a2b8eb24ba32b9@mail.gmail.com> On 3/19/07, Mike McGrath wrote: > What can we learn from this so we don't repeat it? > > http://linux.slashdot.org/linux/07/03/19/1522208.shtml > > -Mike This is a problem with pure democracies that show up time and time again. Even in a democratic meritocracy it will show up at a certain size of population. The reason seems to be the difference between the theory of a democracy that people will get along if they are well educated about the facts, and the reality that a certain segment of a population will not get along no matter what. [It could be postulated that these people are needed for any population center as they will get fed up with how things are done here, and go explore elsewhere.. thus making sure that the population spreads or that new ideas are invented etc.] At a certain point in a 'purish democracy' people can gum up the works badly by disempowering the leadership through various means. There are multiple ways around this, [republics, federalism, etc], but in essence they strengthen the leadership (while putting checks and balances so that the leadership does not become a cult, dictatorship etc) So to learn this.. make sure you have a strong leadership that the population feels they have needed checks on. How you accomplish this (bi-cameral parliament, king for the year, etc) is up to the FAB to decide. -- 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 hp at redhat.com Mon Mar 19 18:55:18 2007 From: hp at redhat.com (Havoc Pennington) Date: Mon, 19 Mar 2007 14:55:18 -0400 Subject: Lessons Learned In-Reply-To: <45FED71D.3010801@redhat.com> References: <45FED71D.3010801@redhat.com> Message-ID: <45FEDC96.8010103@redhat.com> Martin Michlmayr has a great (though 200-page) paper in the works on open source release processes, including Debian and GNOME - it's not public yet but when it comes out I'd encourage reading it for some stuff to learn related to this. Keep an eye out for this one. Havoc Mike McGrath wrote: > What can we learn from this so we don't repeat it? From blizzard at redhat.com Mon Mar 19 19:00:11 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 19 Mar 2007 15:00:11 -0400 Subject: Lessons Learned In-Reply-To: <45FED71D.3010801@redhat.com> References: <45FED71D.3010801@redhat.com> Message-ID: <1174330811.16159.19.camel@localhost.localdomain> On Mon, 2007-03-19 at 13:31 -0500, Mike McGrath wrote: > What can we learn from this so we don't repeat it? > > http://linux.slashdot.org/linux/07/03/19/1522208.shtml > I was only half kidding with this: http://www.flickr.com/photos/christopherblizzard/376866932/ It's an important part of our story. I would say that there are few things that we need to keep in mind as a project that will make sure we don't fall down that path: 1. Getting releases out the door and into the hands of people on a short schedule is probably the most important thing. It keeps us out of process hell, keeps us focused on the software and keeps us in a constant feedback loop with our user base. We learn, produce, learn, produce. 2. Avoid the tendency to not trust ourselves. We have to understand that we'll make mistakes. As long as we're willing to face up to those mistakes as adults and learn from them as opposed to putting in process that ever ever prevents us from making mistakes, we'll do OK. People inside of Red Hat are fond of "Fail Often" as a mantra, even though we don't practice it enough ourselves. We should be OK that as a concept. 3. Process and democracy are not a replacement for strong leadership. We encourage leadership inside of our organization from packagers all the way up to the board. Encourage strong leadership instead of moving to a democratic process where power is completely watered down and no one has to take responsibility or is accountable. 4. Embracing and understanding corporate involvement. Red Hat sponsors our work, we should make sure that others are sponsors as well. It's a true sign of health if we can get more than one involved party. We've never figured out what that looks like, but it's something we should do at some point. Just saying "it's fine" is a big step. Counterpoint: people inside of Debian are so afraid of money affecting the process that they aren't willing to put things in place to make themselves successful. It's weird and I don't understand it. (This is my one big take away from Mozilla experiences. Companies can help if you know how to deal with them.) I think Ian's comments seem to agree with this list. My mantra for Fedora is "a better debian than debian" and I think these are some of the key mechanisms we need to keep in mind moving forward. --Chris From blizzard at redhat.com Mon Mar 19 19:04:14 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 19 Mar 2007 15:04:14 -0400 Subject: Lessons Learned In-Reply-To: <80d7e4090703191140n24a2e52fob7a2b8eb24ba32b9@mail.gmail.com> References: <45FED71D.3010801@redhat.com> <80d7e4090703191140n24a2e52fob7a2b8eb24ba32b9@mail.gmail.com> Message-ID: <1174331054.16159.24.camel@localhost.localdomain> On Mon, 2007-03-19 at 12:40 -0600, Stephen John Smoogen wrote: > This is a problem with pure democracies that show up time and time > again. Even in a democratic meritocracy it will show up at a certain > size of population. The reason seems to be the difference between the > theory of a democracy that people will get along if they are well > educated about the facts, and the reality that a certain segment of a > population will not get along no matter what. [It could be postulated > that these people are needed for any population center as they will > get fed up with how things are done here, and go explore elsewhere.. > thus making sure that the population spreads or that new ideas are > invented etc.] Keep in mind I think we're approaching Debian in terms of the size of the software that we distribute and the size of our contributor base. We don't seem to be suffering from the same problems that Debian is, although I see a lot of process wonkery going on at the edges. It's not all bad, helps us scale, but process for the sake of process and to avoid powerful leadership is dangerous. --Chris From mmcgrath at redhat.com Mon Mar 19 19:18:19 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 19 Mar 2007 14:18:19 -0500 Subject: Lessons Learned In-Reply-To: <1174331054.16159.24.camel@localhost.localdomain> References: <45FED71D.3010801@redhat.com> <80d7e4090703191140n24a2e52fob7a2b8eb24ba32b9@mail.gmail.com> <1174331054.16159.24.camel@localhost.localdomain> Message-ID: <45FEE1FB.2020107@redhat.com> Christopher Blizzard wrote: > Keep in mind I think we're approaching Debian in terms of the size of > the software that we distribute and the size of our contributor base. > We don't seem to be suffering from the same problems that Debian is, > although I see a lot of process wonkery going on at the edges. It's not > all bad, helps us scale, but process for the sake of process and to > avoid powerful leadership is dangerous. > We're scaling right now but I wonder how much longer that will last? Fortunately it seems we're pretty good at course corrections. -Mike From luis at tieguy.org Mon Mar 19 19:15:27 2007 From: luis at tieguy.org (Luis Villa) Date: Mon, 19 Mar 2007 15:15:27 -0400 Subject: Lessons Learned In-Reply-To: References: <45FED71D.3010801@redhat.com> Message-ID: <2cb10c440703191215y45df38f4y56ae7ced3c7e7158@mail.gmail.com> On 3/19/07, Greg Dekoenigsberg wrote: > On Mon, 19 Mar 2007, Mike McGrath wrote: > > > What can we learn from this so we don't repeat it? > > > > http://linux.slashdot.org/linux/07/03/19/1522208.shtml > > Make hard decisions when they need to be made. That isn't sufficiently specific. When do decisions 'need' to be made? Debian's answer to this question is that hard decisions get made only when there is consensus/a vote/lots and lots of talking. External factors (damage to market share, release schedules, etc.) are basically not considered in figuring out when decisions 'need' to be made. To the Debian culture, democracy and process are more important than the product. This is what kills them *as a product*.[1] The repeated slippage of release dates, and recent discussions about 'must have' features for the next release, make me suspect that Fedora has no answers to the question, or at least none that are any better than Debian's. Fedora may not value democracy over the product, but it doesn't seem to have replaced democracy with anything that is decisively better for the product. I'd suggest that to get in the habit of making hard choices earlier rather than later, you might start by picking some hard questions[2], trying to answer them quickly/effectively, and seeing what happens. If they are talked to death, you've already got a problem; if no one steps up to make/enforce the decisions; you've got a problem; etc. (FWIW, you could also replace 'when do you need to make decisions' with 'who makes hard decisions' through this entire email and get similar results.) (Also, what Blizzard said, esp. about the kittens ;) Luis [1] Ian blames this on democracy, but I think it comes from Debian cultural norms which would manifest themselves no matter what leadership method Debian had. [2] I suggested some hard, critical questions (which appear to have been punted) in December: "how does Fedora define a showstopper? What are the most-preferred/least-preferred methods for coping with a showstopper? For a given problem, who gets to choose between those methods? Who is in charge of proactively finding showstoppers as early as possible? Who is in charge of creating communities of people who find showstoppers as early as possible? What methods can be put in place to prevent showstoppers from getting into the trunk in the first place?" From mspevack at redhat.com Mon Mar 19 19:22:25 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 19 Mar 2007 15:22:25 -0400 (EDT) Subject: Board meeting tue 3/20 Message-ID: 10:00 AM Eastern time, 14:00 GMT. #fedora-meeting Agenda: (1) Koji, build system, feature freeze, release engineering type stuff. Jesse Keating will join us. (2) Go over the "must have" stuff for Fedora 7, see if there's any further feedback from the Board, see where we're on target or behind. http://fedoraproject.org/wiki/Releases/7/MustHave Especially since that list will be the starting point at the RHEL/Fedora meeting that we are having on Wednesday (and will be having twice a month from now on), which will focus on engineering issues in Fedora that are also particularly important for RHEL. (3) The thread on FAB about epel, packaging committee, and fesco (4) Check with mdomsch about mirrorman, make sure he's all set with what he needed from Red Hat legal. (5) Make sure we're rolling on the Red Hat Summit specific Live CD (this is a part of #2. Any other topics that folks want to bring up. -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From mspevack at redhat.com Mon Mar 19 19:28:48 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 19 Mar 2007 15:28:48 -0400 (EDT) Subject: Lessons Learned In-Reply-To: <80d7e4090703191140n24a2e52fob7a2b8eb24ba32b9@mail.gmail.com> References: <45FED71D.3010801@redhat.com> <80d7e4090703191140n24a2e52fob7a2b8eb24ba32b9@mail.gmail.com> Message-ID: On Mon, 19 Mar 2007, Stephen John Smoogen wrote: > So to learn this.. make sure you have a strong leadership that the > population feels they have needed checks on. How you accomplish this > (bi-cameral parliament, king for the year, etc) is up to the FAB to > decide. Without hijacking the thread completely, I will say that IMHO we do this pretty well. FPB makes the "hard calls" and delegates some of that down to other committees, which themselves have leaders -- FAB provides the oversight and checks and kicks in the ass. Community at large has no fear of complaining when it sees things it doesn't like. Could I see Fedora being even less centralized than it is and still having reasonably-paced decision making? Not really. Could I see Fedora being more centralized in its decision making? I suppose, but I don't know that it *needs* to be. I think the level of governance is more or less right as it is. We try to let the smartest people who are qualified to make the decisions do so. Especially once some of the questions in today's other main thread (FESCO, Packaging, EPEL) are sorted out. And the FPB is set to rotate about 50% of its seats following F7, which also brings in some fresh leadership and puts current "strong leaders" back into the community, where I'm sure they will continue to lead. My .02 -- 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 Mon Mar 19 19:33:10 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 19 Mar 2007 15:33:10 -0400 Subject: Lessons Learned In-Reply-To: <2cb10c440703191215y45df38f4y56ae7ced3c7e7158@mail.gmail.com> References: <45FED71D.3010801@redhat.com> <2cb10c440703191215y45df38f4y56ae7ced3c7e7158@mail.gmail.com> Message-ID: <1174332790.16159.47.camel@localhost.localdomain> On Mon, 2007-03-19 at 15:15 -0400, Luis Villa wrote: > The repeated slippage of release dates, and recent discussions about > 'must have' features for the next release, make me suspect that Fedora > has no answers to the question, or at least none that are any better > than Debian's. Fedora may not value democracy over the product, but it > doesn't seem to have replaced democracy with anything that is > decisively better for the product. We're pretty focused on time-based releases, as near as I can tell, except of course where we aren't. The F7 release is a good example, the only reason why it has slipped is because the most important feature (all outside the firewall) needs more time. But it's a problem that's defined by time and effort, not structure or because there's some decision we can't make. In general, things are there by the deadline or they aren't. --Chris From mspevack at redhat.com Mon Mar 19 19:36:48 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 19 Mar 2007 15:36:48 -0400 (EDT) Subject: Lessons Learned In-Reply-To: <2cb10c440703191215y45df38f4y56ae7ced3c7e7158@mail.gmail.com> References: <45FED71D.3010801@redhat.com> <2cb10c440703191215y45df38f4y56ae7ced3c7e7158@mail.gmail.com> Message-ID: On Mon, 19 Mar 2007, Luis Villa wrote: > The repeated slippage of release dates, and recent discussions about > 'must have' features for the next release, make me suspect that Fedora > has no answers to the question, or at least none that are any better > than Debian's. Fedora may not value democracy over the product, but it > doesn't seem to have replaced democracy with anything that is decisively > better for the product. My take on slipping release dates. We *always* slip. But then again, almost all software projects do. This is because we start out by saying we want to try to do the release every 6 months. And that can guarantee that it happens in 7 or 8, because the physical act of slipping the release causes some level of shame and urgency. If we just said at the beginning 7 months, then I think we'd *still* end up slipping, and it would really be 8 or 9 months. So I don't have a problem with slipping release dates. And I think having an enumerated list of "must have" features that is a subset of all the "features we said we wanted a few months ago" is also a good thing. Perhaps I'm missing your point a little bit, Luis. --Max P.S. There is a fine line, I suppose, between talking about things in public and talking them to death. I believe that if we don't talk about them in public before a final decision is made, overall that will hurt the project, because lots of people will feel like they weren't involved. On the other hand, having an open conversation leads to long threads because many people feel the need to chime in with their opinion. It takes extra time to listen to what everyone has to say. A little bit of speed is the price of openness, but it's a trade off that we choose to make. -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From mspevack at redhat.com Mon Mar 19 19:39:16 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 19 Mar 2007 15:39:16 -0400 (EDT) Subject: Lessons Learned In-Reply-To: References: <45FED71D.3010801@redhat.com> <2cb10c440703191215y45df38f4y56ae7ced3c7e7158@mail.gmail.com> Message-ID: On Mon, 19 Mar 2007, Max Spevack wrote: > So I don't have a problem with slipping release dates. This sentence should end with "to an extent". :-) --Max From mmcgrath at redhat.com Mon Mar 19 19:42:13 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 19 Mar 2007 14:42:13 -0500 Subject: Lessons Learned In-Reply-To: References: <45FED71D.3010801@redhat.com> <2cb10c440703191215y45df38f4y56ae7ced3c7e7158@mail.gmail.com> Message-ID: <45FEE795.5030400@redhat.com> Max Spevack wrote: > > My take on slipping release dates. We *always* slip. But then again, > almost all software projects do. > This is because no one ever sees that the last mile before a release is up hill, against the wind, towards the sun, in the snow. And the hill is infested with sharks. -Mike From tbm at cyrius.com Mon Mar 19 19:47:58 2007 From: tbm at cyrius.com (Martin Michlmayr) Date: Mon, 19 Mar 2007 20:47:58 +0100 Subject: Lessons Learned In-Reply-To: <45FEDC96.8010103@redhat.com> References: <45FED71D.3010801@redhat.com> <45FEDC96.8010103@redhat.com> Message-ID: <20070319194758.GB25331@deprecation.cyrius.com> * Havoc Pennington [2007-03-19 14:55]: > Martin Michlmayr has a great (though 200-page) paper in the works on > open source release processes, including Debian and GNOME - it's not > public yet but when it comes out I'd encourage reading it for some > stuff to learn related to this. Keep an eye out for this one. Newsforge will write an article about it, so you don't have to read the whole document. Also, I've started blogging about the results: http://www.cyrius.com/journal/phd?reverse=yes However, it's only about time based release management, not about leadership in general. -- Martin Michlmayr http://www.cyrius.com/ From jkeating at redhat.com Mon Mar 19 19:49:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Mar 2007 15:49:36 -0400 Subject: Lessons Learned In-Reply-To: References: <45FED71D.3010801@redhat.com> <2cb10c440703191215y45df38f4y56ae7ced3c7e7158@mail.gmail.com> Message-ID: <200703191549.36595.jkeating@redhat.com> On Monday 19 March 2007 15:36:48 Max Spevack wrote: > This is because we start out by saying we want to try to do the release > every 6 months. ?And that can guarantee that it happens in 7 or 8, because > the physical act of slipping the release causes some level of shame and > urgency. > > If we just said at the beginning 7 months, then I think we'd *still* end > up slipping, and it would really be 8 or 9 months. Right. We start with 6 months and think "What can we accomplish in the development time this gives us?" Then we make a list and set some goals. Come test release time we slip a little here/there for things that are in flux and could be broken. The big slips come when we decided a feature was a must have back in planning stage and it just isn't ready in time for the release. That's when we shift from a time based release to a feature based release. You're right though, if we said 7 or 8 months from the get go, we'd say "well, what can we accomplish in the time THIS gives us for development" and we'd play the game all over again. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From smooge at gmail.com Mon Mar 19 19:50:14 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 19 Mar 2007 13:50:14 -0600 Subject: Lessons Learned In-Reply-To: <45FEE795.5030400@redhat.com> References: <45FED71D.3010801@redhat.com> <2cb10c440703191215y45df38f4y56ae7ced3c7e7158@mail.gmail.com> <45FEE795.5030400@redhat.com> Message-ID: <80d7e4090703191250kce86211v7c20641929595e00@mail.gmail.com> On 3/19/07, Mike McGrath wrote: > Max Spevack wrote: > > > > My take on slipping release dates. We *always* slip. But then again, > > almost all software projects do. > > > This is because no one ever sees that the last mile before a release is > up hill, against the wind, towards the sun, in the snow. And the hill > is infested with sharks. > Actually every developer sees this.. its just that irrepressible optimist streak that says "maybe this time the shark-repellant will work!" -- 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 poelstra at redhat.com Mon Mar 19 20:22:39 2007 From: poelstra at redhat.com (John Poelstra) Date: Mon, 19 Mar 2007 13:22:39 -0700 Subject: Board meeting tue 3/20 In-Reply-To: References: Message-ID: <45FEF10F.3040102@redhat.com> Max Spevack said the following on 03/19/2007 12:22 PM Pacific Time: > 10:00 AM Eastern time, 14:00 GMT. #fedora-meeting > > Agenda: > > (1) Koji, build system, feature freeze, release engineering type stuff. > Jesse Keating will join us. > > (2) Go over the "must have" stuff for Fedora 7, see if there's any > further feedback from the Board, see where we're on target or behind. > http://fedoraproject.org/wiki/Releases/7/MustHave How about some specific milestones (due dates) for the items listed in #2 above? Some of these are pretty big dependencies which which will block other steps in the process if they are not completed in time, thus affecting the ending GA date. John From notting at redhat.com Mon Mar 19 20:18:09 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Mar 2007 16:18:09 -0400 Subject: Board meeting tue 3/20 In-Reply-To: <45FEF10F.3040102@redhat.com> References: <45FEF10F.3040102@redhat.com> Message-ID: <20070319201809.GA30667@nostromo.devel.redhat.com> John Poelstra (poelstra at redhat.com) said: > >(2) Go over the "must have" stuff for Fedora 7, see if there's any > >further feedback from the Board, see where we're on target or behind. > > http://fedoraproject.org/wiki/Releases/7/MustHave > > How about some specific milestones (due dates) for the items listed in #2 > above? Some of these are pretty big dependencies which which will block > other steps in the process if they are not completed in time, thus > affecting the ending GA date. For those things that were on the feature list, they have due dates in their feature entry. (This is the problem of redoing the feature list at this date.) Bill From poelstra at redhat.com Mon Mar 19 20:26:55 2007 From: poelstra at redhat.com (John Poelstra) Date: Mon, 19 Mar 2007 13:26:55 -0700 Subject: Board meeting tue 3/20 In-Reply-To: <20070319201809.GA30667@nostromo.devel.redhat.com> References: <45FEF10F.3040102@redhat.com> <20070319201809.GA30667@nostromo.devel.redhat.com> Message-ID: <45FEF20F.9010606@redhat.com> Bill Nottingham said the following on 03/19/2007 01:18 PM Pacific Time: > John Poelstra (poelstra at redhat.com) said: >>> (2) Go over the "must have" stuff for Fedora 7, see if there's any >>> further feedback from the Board, see where we're on target or behind. >>> http://fedoraproject.org/wiki/Releases/7/MustHave >> How about some specific milestones (due dates) for the items listed in #2 >> above? Some of these are pretty big dependencies which which will block >> other steps in the process if they are not completed in time, thus >> affecting the ending GA date. > > For those things that were on the feature list, they have due dates > in their feature entry. > Understood :) I don't believe most of the other items have due dates... or at least they aren't on the public schedule. John From mspevack at redhat.com Mon Mar 19 20:29:54 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 19 Mar 2007 16:29:54 -0400 (EDT) Subject: Board meeting tue 3/20 In-Reply-To: <45FEF20F.9010606@redhat.com> References: <45FEF10F.3040102@redhat.com> <20070319201809.GA30667@nostromo.devel.redhat.com> <45FEF20F.9010606@redhat.com> Message-ID: On Mon, 19 Mar 2007, John Poelstra wrote: > Bill Nottingham said the following on 03/19/2007 01:18 PM Pacific Time: >> John Poelstra (poelstra at redhat.com) said: >>>> (2) Go over the "must have" stuff for Fedora 7, see if there's any >>>> further feedback from the Board, see where we're on target or behind. >>>> http://fedoraproject.org/wiki/Releases/7/MustHave >>> How about some specific milestones (due dates) for the items listed in #2 >>> above? Some of these are pretty big dependencies which which will block >>> other steps in the process if they are not completed in time, thus >>> affecting the ending GA date. >> >> For those things that were on the feature list, they have due dates >> in their feature entry. >> > > Understood :) I don't believe most of the other items have due dates... or > at least they aren't on the public schedule. We'll either link to the larger feature page for each thing (with a due date) or if there is no due date, come up with one. --Max From jkeating at redhat.com Mon Mar 19 20:42:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Mar 2007 16:42:11 -0400 Subject: Board meeting tue 3/20 In-Reply-To: <45FEF10F.3040102@redhat.com> References: <45FEF10F.3040102@redhat.com> Message-ID: <200703191642.12180.jkeating@redhat.com> On Monday 19 March 2007 16:22:39 John Poelstra wrote: > How about some specific milestones (due dates) for the items listed in #2 > above? ?Some of these are pretty big dependencies which which will block > other steps in the process if they are not completed in time, thus > affecting the ending GA date. The problem is that we're already past the "due" date, so we're in a day to day slip. Setting a date isn't really going to help, we'll either make the date, or we'll slip the date again. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Mar 19 20:46:36 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Mar 2007 21:46:36 +0100 Subject: fesco, fpc and epel relationships In-Reply-To: <45FECA45.4070608@leemhuis.info> References: <20070319161837.GC2212@neu.nirvana> <45FEB8BA.2020100@redhat.com> <20070319162952.GE2212@neu.nirvana> <1174322315.3484.12.camel@dhcp120.install.boston.redhat.com> <20070319164424.GB14393@neu.nirvana> <1174322791.3484.14.camel@dhcp120.install.boston.redhat.com> <20070319165915.GF14393@neu.nirvana> <45FEC4A2.7070202@leemhuis.info> <20070319171938.GH14393@neu.nirvana> <45FECA45.4070608@leemhuis.info> Message-ID: <20070319204636.GE18607@neu.nirvana> On Mon, Mar 19, 2007 at 06:37:09PM +0100, Thorsten Leemhuis wrote: > >> Just to clarify: FESCo is the Committee above FPC (and below the Board) > >> afaics; see > > I thought that was always the case > > No, in the past the FPC was afaics kind of on the same level as Core and > Extras Committee's, just that the latter had a kind of veto right. Well, that probably feels just the same, if you can shutdown something, then by definition you're the boss ;=) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jrb at redhat.com Mon Mar 19 22:20:55 2007 From: jrb at redhat.com (Jonathan Blandford) Date: Mon, 19 Mar 2007 18:20:55 -0400 Subject: Lessons Learned In-Reply-To: References: <45FED71D.3010801@redhat.com> <2cb10c440703191215y45df38f4y56ae7ced3c7e7158@mail.gmail.com> Message-ID: <1174342855.3183.247.camel@localhost.localdomain> On Mon, 2007-03-19 at 15:36 -0400, Max Spevack wrote: > On Mon, 19 Mar 2007, Luis Villa wrote: > > > The repeated slippage of release dates, and recent discussions about > > 'must have' features for the next release, make me suspect that Fedora > > has no answers to the question, or at least none that are any better > > than Debian's. Fedora may not value democracy over the product, but it > > doesn't seem to have replaced democracy with anything that is decisively > > better for the product. > > My take on slipping release dates. We *always* slip. But then again, > almost all software projects do. > > This is because we start out by saying we want to try to do the release > every 6 months. And that can guarantee that it happens in 7 or 8, because > the physical act of slipping the release causes some level of shame and > urgency. > > If we just said at the beginning 7 months, then I think we'd *still* end > up slipping, and it would really be 8 or 9 months. Saying that we always slip seems to be a self fulfilling prophesy for Fedora. The fact that we always slip leads to us slipping more, as people worry about the next release. If they don't know exactly when the next one is and worry about it being delayed as well, they're much more inclined to rush to put things in. Thus, we get something like the MustHaves, which has two laudable but ambitious goals in it, and us running around trying to achieve them. FC6 had similar goals, as did FC5, both of which slipped. There are always more features to be had, and we have probably slipped at least one six month period over the past couple releases. If we really wanted to do time-base releases, the MustHaves page would just say: "Is it April 26th yet?" and we'd work backwards from there. Barring doing something that radical (which GNOME does, to somewhat mixed results), I bet we always slip a couple months, every release. Thanks, -Jonathan From poelstra at redhat.com Tue Mar 20 04:02:03 2007 From: poelstra at redhat.com (John Poelstra) Date: Mon, 19 Mar 2007 21:02:03 -0700 Subject: Lessons Learned In-Reply-To: <1174342855.3183.247.camel@localhost.localdomain> References: <45FED71D.3010801@redhat.com> <2cb10c440703191215y45df38f4y56ae7ced3c7e7158@mail.gmail.com> <1174342855.3183.247.camel@localhost.localdomain> Message-ID: <45FF5CBB.6060608@redhat.com> Jonathan Blandford wrote: > Saying that we always slip seems to be a self fulfilling prophesy for > Fedora. > > The fact that we always slip leads to us slipping more, as people worry > about the next release. If they don't know exactly when the next one is Interestingly the stats show that the slip rate is not increasing dramatically between releases. However, we have only been able to meet a 6 month schedule once (see attached spreadsheet). > and worry about it being delayed as well, they're much more inclined to > rush to put things in. Thus, we get something like the MustHaves, which > has two laudable but ambitious goals in it, and us running around trying > to achieve them. FC6 had similar goals, as did FC5, both of which > slipped. There are always more features to be had, and we have probably > slipped at least one six month period over the past couple releases. > My calcs show approximately 3.5 months of combined slippage over the past 2 releases. I would agree with Max that it is not unusual for software projects to slip, however if we never meet our original schedule or do not follow a predictable schedule, then it would seem reasonable to consider how more accurate goals might be set for the next release. The large standard deviations are interesting to consider. John -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora-averages.sxc Type: application/vnd.sun.xml.calc Size: 11014 bytes Desc: not available URL: From rc040203 at freenet.de Tue Mar 20 04:07:09 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Mar 2007 05:07:09 +0100 Subject: Lessons Learned In-Reply-To: <1174330811.16159.19.camel@localhost.localdomain> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> Message-ID: <1174363629.4531.13.camel@mccallum.corsepiu.local> On Mon, 2007-03-19 at 15:00 -0400, Christopher Blizzard wrote: > 3. Process and democracy are not a replacement for strong leadership. "process and democracy" are means to establish "an accepted leadership"! I.e. a "strong leadership" will only work, if it is "accepted by the anonymous masses". This where I feel Fedora leadership has always had and still has deficits. Ralf From jwboyer at jdub.homelinux.org Tue Mar 20 10:48:51 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 20 Mar 2007 05:48:51 -0500 Subject: Lessons Learned In-Reply-To: <1174363629.4531.13.camel@mccallum.corsepiu.local> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> Message-ID: <1174387732.2977.30.camel@vader.jdub.homelinux.org> On Tue, 2007-03-20 at 05:07 +0100, Ralf Corsepius wrote: > On Mon, 2007-03-19 at 15:00 -0400, Christopher Blizzard wrote: > > > 3. Process and democracy are not a replacement for strong leadership. > "process and democracy" are means to establish "an accepted leadership"! > > I.e. a "strong leadership" will only work, if it is "accepted by the > anonymous masses". This where I feel Fedora leadership has always had > and still has deficits. Could you provide examples of this where more than just one or two vocal people opposed something and it was done anyway? I cannot recall such a time, but if there is one it would be important to use as an example to learn from. josh From mspevack at redhat.com Tue Mar 20 15:11:02 2007 From: mspevack at redhat.com (Max Spevack) Date: Tue, 20 Mar 2007 11:11:02 -0400 (EDT) Subject: fesco, fpc and epel relationships In-Reply-To: <1174322791.3484.14.camel@dhcp120.install.boston.redhat.com> References: <45FD4EE1.3020309@leemhuis.info> <20070319161837.GC2212@neu.nirvana> <45FEB8BA.2020100@redhat.com> <20070319162952.GE2212@neu.nirvana> <1174322315.3484.12.camel@dhcp120.install.boston.redhat.com> <20070319164424.GB14393@neu.nirvana> <1174322791.3484.14.camel@dhcp120.install.boston.redhat.com> Message-ID: On Mon, 19 Mar 2007, Tom 'spot' Callaway wrote: > No one has said that FPC doesn't have the authority. EPEL is a Fedora > project. > > Thus, I hereby deem that FPC has the authority. Axel and thl gave this a +1 The Board does too. --Max From rc040203 at freenet.de Tue Mar 20 16:03:54 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Mar 2007 17:03:54 +0100 Subject: Lessons Learned In-Reply-To: <1174387732.2977.30.camel@vader.jdub.homelinux.org> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> Message-ID: <1174406634.4531.77.camel@mccallum.corsepiu.local> On Tue, 2007-03-20 at 05:48 -0500, Josh Boyer wrote: > On Tue, 2007-03-20 at 05:07 +0100, Ralf Corsepius wrote: > > On Mon, 2007-03-19 at 15:00 -0400, Christopher Blizzard wrote: > > > > > 3. Process and democracy are not a replacement for strong leadership. > > "process and democracy" are means to establish "an accepted leadership"! > > > > I.e. a "strong leadership" will only work, if it is "accepted by the > > anonymous masses". This where I feel Fedora leadership has always had > > and still has deficits. > > Could you provide examples of this where more than just one or two vocal > people opposed something and it was done anyway? I cannot recall such a > time, but if there is one it would be important to use as an example to > learn from. Why am I not really surprised about his answer? A successful "strong leadership" in a system run by volunteers, implies "leadership to provide guidance to the public" and "leadership to achieve acceptance by the public". So far, this has not taken place. Instead, Fedora has a leadership system, which is widely being ignored by the public, unless it interferes with individual contributor interests. Ralf From gdk at redhat.com Tue Mar 20 16:04:40 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Tue, 20 Mar 2007 12:04:40 -0400 (EDT) Subject: Lessons Learned In-Reply-To: <1174406634.4531.77.camel@mccallum.corsepiu.local> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> Message-ID: On Tue, 20 Mar 2007, Ralf Corsepius wrote: > Instead, Fedora has a leadership system, which is widely being ignored > by the public, unless it interferes with individual contributor > interests. Isn't that basically how governments work? The *real* question: when the Fedora leadership (government) interferes with the interests of the individual contributor (citizen) -- which is, of course, inevitable -- does the individual contributor (citizen) have meaningful recourse? --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From jwboyer at jdub.homelinux.org Tue Mar 20 16:17:57 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 20 Mar 2007 11:17:57 -0500 Subject: Lessons Learned In-Reply-To: <1174406634.4531.77.camel@mccallum.corsepiu.local> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> Message-ID: <1174407477.30079.147.camel@zod.rchland.ibm.com> On Tue, 2007-03-20 at 17:03 +0100, Ralf Corsepius wrote: > > > Could you provide examples of this where more than just one or two vocal > > people opposed something and it was done anyway? I cannot recall such a > > time, but if there is one it would be important to use as an example to > > learn from. > Why am I not really surprised about his answer? It was a question for you. Not an answer. > A successful "strong leadership" in a system run by volunteers, implies > "leadership to provide guidance to the public" and "leadership to > achieve acceptance by the public". > > So far, this has not taken place. Instead, Fedora has a leadership > system, which is widely being ignored by the public, unless it > interferes with individual contributor interests. I'm genuinely sorry but I do not see where things are being ignored by the public. The PC makes guidelines, those are followed, etc. And I honestly cannot think of a time when either FESCo or FAB or PC make a decision that was contrary to a majority of what people wanted[1]. If you could please provide some examples of what you're referring to, then we can have a discussion about it. But just saying things like this doesn't really provide a good basis to discuss and resolve any issues. josh [1] with perhaps the exception of patented items such as MP3 where there is no legal possibility for this to be included freely. From luis at tieguy.org Tue Mar 20 16:56:06 2007 From: luis at tieguy.org (Luis Villa) Date: Tue, 20 Mar 2007 12:56:06 -0400 Subject: Lessons Learned In-Reply-To: References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> Message-ID: <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> On 3/20/07, Greg Dekoenigsberg wrote: > On Tue, 20 Mar 2007, Ralf Corsepius wrote: > > > Instead, Fedora has a leadership system, which is widely being ignored > > by the public, unless it interferes with individual contributor > > interests. > > Isn't that basically how governments work? > > The *real* question: when the Fedora leadership (government) interferes > with the interests of the individual contributor (citizen) -- which is, of > course, inevitable -- does the individual contributor (citizen) have > meaningful recourse? That is one question you could ask. The other question you could ask is what tools government can use to convince the contributor to accept the interference, while still contributing. The tools could include strong community norms/peer pressure; this is where Debian fails- their community norm is that you should discuss the thing to death. Everyone is afraid to say 'STFU and code, or STFU and go away.' There is no strong leadership which feels empowered to say 'OK, we've discussed it, discussion is done, we're acting now.' Probably I'm overreacting about the specific issue of release dates (given my biases there). The core question I wanted to ask is how does Fedora say to contributors 'we love you, we love your ideas, but we apologize- we have to move on. So kindly please STFU so we can get on with our core business of _________.' Debian seems socially incapable of doing that; it would be a shame if in the name of democracy/deliberation Fedora went down the same route. Luis From rc040203 at freenet.de Tue Mar 20 18:13:33 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Mar 2007 19:13:33 +0100 Subject: Lessons Learned In-Reply-To: References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> Message-ID: <1174414413.4531.133.camel@mccallum.corsepiu.local> On Tue, 2007-03-20 at 12:04 -0400, Greg Dekoenigsberg wrote: > On Tue, 20 Mar 2007, Ralf Corsepius wrote: > > > Instead, Fedora has a leadership system, which is widely being ignored > > by the public, unless it interferes with individual contributor > > interests. > > Isn't that basically how governments work? Temporarily yes. History tells, in longer terms such governments inevitably will die. In democratic systems, they sooner or later will be replaced, in absolutist systems these governments will sooner or later be chased or die lonesome. > The *real* question: when the Fedora leadership (government) You are missing an essential detail: Governments must have control over a "people". OpenSource projects however are based on "mutually sharing interests", with nobody having control over anybody. If you try to pressurize people they will simply leave the government alone. > interferes > with the interests of the individual contributor (citizen) -- which is, of > course, inevitable -- does the individual contributor (citizen) have > meaningful recourse? Well, but being vocal on lists, there hardly is any means for it. Until recently FAB's most noteworthy feature was "complete absence". That's definitely not a "strong leadership" and definitely is not "providing guidance". FESCO is a different story. It once was merely a technical committee, then it was the community's counterpart/counterweight to RH, then there was a time when it had been democratically elected ... nowadays, it appears to be more as "Fedora administration" but a community representation. Ralf From smooge at gmail.com Tue Mar 20 18:23:01 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 20 Mar 2007 12:23:01 -0600 Subject: Lessons Learned In-Reply-To: <1174414413.4531.133.camel@mccallum.corsepiu.local> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <1174414413.4531.133.camel@mccallum.corsepiu.local> Message-ID: <80d7e4090703201123n4dbb65amd12fd0555cfecab2@mail.gmail.com> On 3/20/07, Ralf Corsepius wrote: > On Tue, 2007-03-20 at 12:04 -0400, Greg Dekoenigsberg wrote: > > On Tue, 20 Mar 2007, Ralf Corsepius wrote: > > > > > Instead, Fedora has a leadership system, which is widely being ignored > > > by the public, unless it interferes with individual contributor > > > interests. > > > > Isn't that basically how governments work? > Temporarily yes. > > History tells, in longer terms such governments inevitably will die. In > democratic systems, they sooner or later will be replaced, in absolutist > systems these governments will sooner or later be chased or die > lonesome. > Is this the "pure anarchy is the only true freedom!" argument? This seems to be resolved usually by the "I have the biggest rock, do what I say".. and then a 'government' occurs as people realize that if they all join their rocks together they can stop the guy bullying around. > > The *real* question: when the Fedora leadership (government) > You are missing an essential detail: Governments must have control over > a "people". OpenSource projects however are based on "mutually sharing > interests", with nobody having control over anybody. If you try to > pressurize people they will simply leave the government alone. Governments exist because people biologically can't get along and will try to solve/take/get things via violence. That governments succumb to this is because they are made of people and thus imperfect. The only long-term solution is paving over the earth, and mass extermination of all biological entities to make sure that intelligence never accidently appears again. -- 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 wtogami at redhat.com Tue Mar 20 19:49:18 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Mar 2007 15:49:18 -0400 Subject: Simplify: Update or Remove Content Message-ID: <46003ABE.1070601@redhat.com> I'm finding our Wiki to be increasingly a disaster. Part of this is due to stale and unnecessary content. Too much of this creates a distraction from important content, which only adds to the confusion. Example: http://fedoraproject.org/wiki/RenderingProject Sections like this are problematic. - Participants and drivers of the project do not write or update the pages. Thus they are stale, and will remain stale forever. - They might (rightly) say this doesn't belong in the Fedora Wiki. This information belongs upstream. The work here happens in places like Xorg, Freedesktop.org and GNOME. - This being upstream issues, this is not a "Fedora Rendering Project". In this case, we should wipe out this content and insert redirects and references to upstream resources where necessary. Does anyone want to clean this up? http://fedoraproject.org/wiki/Education In a general case, we should identify other pages that claim to be "Projects" and wipe them away in order to reduce the confusing noise. This page was one example of completely stale and useless content, not representative of reality. Warren Togami wtogami at redhat.com From gdk at redhat.com Tue Mar 20 19:52:28 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Tue, 20 Mar 2007 15:52:28 -0400 (EDT) Subject: Simplify: Update or Remove Content In-Reply-To: <46003ABE.1070601@redhat.com> References: <46003ABE.1070601@redhat.com> Message-ID: On Tue, 20 Mar 2007, Warren Togami wrote: > I'm finding our Wiki to be increasingly a disaster. Hyperbolic, I think. > Example: > http://fedoraproject.org/wiki/RenderingProject So the content is old. Pretty evident that the content is old. > http://fedoraproject.org/wiki/Education > > In a general case, we should identify other pages that claim to be > "Projects" and wipe them away in order to reduce the confusing noise. > This page was one example of completely stale and useless content, not > representative of reality. Is there an actual "Fedora Education" project that this is trampling on? --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From mspevack at redhat.com Tue Mar 20 19:58:00 2007 From: mspevack at redhat.com (Max Spevack) Date: Tue, 20 Mar 2007 15:58:00 -0400 (EDT) Subject: Simplify: Update or Remove Content In-Reply-To: <46003ABE.1070601@redhat.com> References: <46003ABE.1070601@redhat.com> Message-ID: On Tue, 20 Mar 2007, Warren Togami wrote: > In this case, we should wipe out this content and insert redirects and > references to upstream resources where necessary. Does anyone want to > clean this up? Removing stale and old content from the wiki is a mammoth job, and also one that is quite tedious. Seems like it definitely needs automation. Some moin moin instances that I've seen have an "AbandonedPages" option, that shows you which pages have gone the longest without being edited. Ours doesn't have that by default under /wiki/SiteNavigation -- possibly because of the size of the wiki? I would say that if someone on our infrastructure team can pipe together some commands to show us the top 500 wiki pages that either have gone the longest without being edited or being looked at, that would be an interesting starting point. my .02 --Max From blizzard at redhat.com Tue Mar 20 22:34:40 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 20 Mar 2007 18:34:40 -0400 Subject: Lessons Learned In-Reply-To: <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> Message-ID: <1174430081.4010.23.camel@localhost.localdomain> On Tue, 2007-03-20 at 12:56 -0400, Luis Villa wrote: > On 3/20/07, Greg Dekoenigsberg wrote: > > On Tue, 20 Mar 2007, Ralf Corsepius wrote: > > > > > Instead, Fedora has a leadership system, which is widely being ignored > > > by the public, unless it interferes with individual contributor > > > interests. > > > > Isn't that basically how governments work? > > > > The *real* question: when the Fedora leadership (government) interferes > > with the interests of the individual contributor (citizen) -- which is, of > > course, inevitable -- does the individual contributor (citizen) have > > meaningful recourse? > > That is one question you could ask. The other question you could ask > is what tools government can use to convince the contributor to accept > the interference, while still contributing. > > The tools could include strong community norms/peer pressure; this is > where Debian fails- their community norm is that you should discuss > the thing to death. Everyone is afraid to say 'STFU and code, or STFU > and go away.' There is no strong leadership which feels empowered to > say 'OK, we've discussed it, discussion is done, we're acting now.' > > Probably I'm overreacting about the specific issue of release dates > (given my biases there). The core question I wanted to ask is how does > Fedora say to contributors 'we love you, we love your ideas, but we > apologize- we have to move on. So kindly please STFU so we can get on > with our core business of _________.' Debian seems socially incapable > of doing that; it would be a shame if in the name of > democracy/deliberation Fedora went down the same route. I honestly believe that Greg, Max, Jeremy, Jesse, and the other folks who lead inside of the Fedora community are interested in building a community of doing, not a culture of talking. We respect those who Do Things and encourage them. Jesse, Jeremy, Mike McGrath are good examples of this - they are lead-by-doing people and it works. As to your specific suggestion about how to say to contributors 'we love you...' I think that saying that in those words is fine. I'm a tough love kind of guy, so maybe I'm OK with saying it exactly like that is fine as well. :) But in reality, I feel it's about making sure the culture we're building is based around that. Doing, not talking. "He who codes, leads." (Although sometimes we don't want the code, either, but that's a different story.) Here's another point. We need to make sure we're being pretty practical about governance models here. We could go for the purist democracy model or the pure fascism model or some other anarchist model, but what we have right now - a combination of corporate interest balanced with community contributions built around transparency and a culture of getting things done - is working pretty damned well and I am loathe to see it change at this point without a very very good reason. Most of us are honest enough and bright enough to see any abuses and point them out, and that's part of the culture of transparency we all believe in. So let's just keep to a "works well" model here and stay away from the political hyperbole and learn to trust ourselves a bit. We've self-selected into a good bunch of people and that's our biggest advantage - not the model. --Chris From luis at tieguy.org Tue Mar 20 22:38:14 2007 From: luis at tieguy.org (Luis Villa) Date: Tue, 20 Mar 2007 18:38:14 -0400 Subject: Lessons Learned In-Reply-To: <1174430081.4010.23.camel@localhost.localdomain> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> Message-ID: <2cb10c440703201538id05fae3q3bab87f0c3446823@mail.gmail.com> On 3/20/07, Christopher Blizzard wrote: > I honestly believe that Greg, Max, Jeremy, Jesse, and the other folks > who lead inside of the Fedora community are interested in building a > community of doing, not a culture of talking. > We've self-selected into a good bunch of people and that's our biggest > advantage - not the model. Yeah. I guess what I was trying to get across is that culture/personal leadership matters much more than model, and if you want to keep an eye on danger signs, keep an eye on the culture. You seem to have encapsulated that better than I did. :) Luis From jwboyer at jdub.homelinux.org Tue Mar 20 23:26:15 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 20 Mar 2007 18:26:15 -0500 Subject: Lessons Learned In-Reply-To: <1174430081.4010.23.camel@localhost.localdomain> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> Message-ID: <1174433175.2977.51.camel@vader.jdub.homelinux.org> On Tue, 2007-03-20 at 18:34 -0400, Christopher Blizzard wrote: > On Tue, 2007-03-20 at 12:56 -0400, Luis Villa wrote: > > On 3/20/07, Greg Dekoenigsberg wrote: > > > On Tue, 20 Mar 2007, Ralf Corsepius wrote: > > > > > > > Instead, Fedora has a leadership system, which is widely being ignored > > > > by the public, unless it interferes with individual contributor > > > > interests. > > > > > > Isn't that basically how governments work? > > > > > > The *real* question: when the Fedora leadership (government) interferes > > > with the interests of the individual contributor (citizen) -- which is, of > > > course, inevitable -- does the individual contributor (citizen) have > > > meaningful recourse? > > > > That is one question you could ask. The other question you could ask > > is what tools government can use to convince the contributor to accept > > the interference, while still contributing. > > > > The tools could include strong community norms/peer pressure; this is > > where Debian fails- their community norm is that you should discuss > > the thing to death. Everyone is afraid to say 'STFU and code, or STFU > > and go away.' There is no strong leadership which feels empowered to > > say 'OK, we've discussed it, discussion is done, we're acting now.' > > > > Probably I'm overreacting about the specific issue of release dates > > (given my biases there). The core question I wanted to ask is how does > > Fedora say to contributors 'we love you, we love your ideas, but we > > apologize- we have to move on. So kindly please STFU so we can get on > > with our core business of _________.' Debian seems socially incapable > > of doing that; it would be a shame if in the name of > > democracy/deliberation Fedora went down the same route. > > I honestly believe that Greg, Max, Jeremy, Jesse, and the other folks > who lead inside of the Fedora community are interested in building a > community of doing, not a culture of talking. We respect those who Do > Things and encourage them. Jesse, Jeremy, Mike McGrath are good > examples of this - they are lead-by-doing people and it works. Small caveat. Yes, those people (and many others) kick butt at doing. Yes, respecting those who Do Things is excellent. Yes, it works. I have no concerns with anything that has been done, nor do I see any immediate cause for change. I want to make it clear that I see no current problem that needs fixing. The only issue that arises out of this is that there are two categories of Doers. One includes all those people you mentioned. The other includes people like me, or Dennis, or Thorsten. Namely people paid to work on Fedora and people that aren't. And to be honest, I feel it puts the people that are paid to work on Fedora in an unfair position. They are tasked with getting things done in Fedora _and_ making sure the community is involved. And at times involving the community slows things down simply because the volunteers aren't available during the day. So now you have the interesting situation where the paid Doers can literally accomplish more than the rest of the group and therefore in a meritocracy they have an advantage of being more valuable. As I said earlier, I personally have no issues at the moment. It's just something we should keep in our minds while we move forward in our brave new world. josh From sundaram at fedoraproject.org Wed Mar 21 01:15:07 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Mar 2007 06:45:07 +0530 Subject: Fedora code of conduct Message-ID: <4600871B.8090908@fedoraproject.org> Hi The recent Gentoo mailing lists flamewar[1] leading to developers quitting and subsequent adoption of a code of conduct[2], it might be useful for us to proactively put in a code of conduct for all of Fedora mandatory for all the contributors and for users as well as a prominent note for all the mailing lists subscribers and possibly other means. We haven't had major issues such as these but as well as scale to more contributors it would good to have a mechanism like this and enforce that. Comments? Rahul [1] http://distrowatch.com/weekly.php?issue=20070312#future [2] http://www.gentoo.org/proj/en/council/coc.xml From tcallawa at redhat.com Tue Mar 20 20:15:39 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 20 Mar 2007 15:15:39 -0500 Subject: [Fwd: Re: Fedora free software?] Message-ID: <1174421739.4264.5.camel@localhost.localdomain> -------- Forwarded Message -------- > From: Richard Stallman > > I honestly wish we didn't have to have such a clause, but without binary > firmware, the vast majority of wireless hardware is completely > non-functional. > > We have to recommend that people buy the only products that don't > require non-free firmware. See the Hardware pages on fsf.org. > Can you help spread the word about this? The link that RMS is referring to is here: http://www.fsf.org/campaigns/hardware.html I don't think there is any harm in Fedora recommending that consumers purchase wireless products that don't require firmware. I'm not entirely sure the best way to go about this, though. Thoughts? ~spot From tcallawa at redhat.com Tue Mar 20 20:16:36 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 20 Mar 2007 15:16:36 -0500 Subject: Fedora code of conduct In-Reply-To: <4600871B.8090908@fedoraproject.org> References: <4600871B.8090908@fedoraproject.org> Message-ID: <1174421796.4264.7.camel@localhost.localdomain> On Wed, 2007-03-21 at 06:45 +0530, Rahul Sundaram wrote: > Hi > > The recent Gentoo mailing lists flamewar[1] leading to developers > quitting and subsequent adoption of a code of conduct[2], it might be > useful for us to proactively put in a code of conduct for all of Fedora > mandatory for all the contributors and for users as well as a prominent > note for all the mailing lists subscribers and possibly other means. We > haven't had major issues such as these but as well as scale to more > contributors it would good to have a mechanism like this and enforce > that. Comments? Honestly, I'd rather deal with that when we need to, and not before. ~spot From jkeating at redhat.com Wed Mar 21 01:22:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Mar 2007 21:22:45 -0400 Subject: Lessons Learned In-Reply-To: <1174433175.2977.51.camel@vader.jdub.homelinux.org> References: <45FED71D.3010801@redhat.com> <1174430081.4010.23.camel@localhost.localdomain> <1174433175.2977.51.camel@vader.jdub.homelinux.org> Message-ID: <200703202122.45415.jkeating@redhat.com> On Tuesday 20 March 2007 19:26:15 Josh Boyer wrote: > And to be honest, I feel it puts the people that are paid to work on > Fedora in an unfair position. ?They are tasked with getting things done > in Fedora _and_ making sure the community is involved. ?And at times > involving the community slows things down simply because the volunteers > aren't available during the day. ?So now you have the interesting > situation where the paid Doers can literally accomplish more than the > rest of the group and therefore in a meritocracy they have an advantage > of being more valuable. > > As I said earlier, I personally have no issues at the moment. ?It's just > something we should keep in our minds while we move forward in our brave > new world. I agree a LOT. I was very concerned how my taking a job at Red Hat to become a paid Doer would effect my ability to lead in the community. It's very easy to get stuff done when you're paid to do it, and I agree 100% that it puts us paid shills in an unfair light. This is why I have such respect for those that are able to accomplish great amounts of work all on personal or borrowed company time. I think we should recognize those that do this from time to time in some meaningful way. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Wed Mar 21 01:36:15 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 20 Mar 2007 21:36:15 -0400 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <1174421739.4264.5.camel@localhost.localdomain> References: <1174421739.4264.5.camel@localhost.localdomain> Message-ID: <20070321013615.GA22917@redhat.com> On Tue, Mar 20, 2007 at 03:15:39PM -0500, Tom spot Callaway wrote: > -------- Forwarded Message -------- > > From: Richard Stallman > > > > I honestly wish we didn't have to have such a clause, but without binary > > firmware, the vast majority of wireless hardware is completely > > non-functional. > > > > We have to recommend that people buy the only products that don't > > require non-free firmware. See the Hardware pages on fsf.org. > > Can you help spread the word about this? > > The link that RMS is referring to is here: > http://www.fsf.org/campaigns/hardware.html > > I don't think there is any harm in Fedora recommending that consumers > purchase wireless products that don't require firmware. I'm not entirely > sure the best way to go about this, though. We can certainly promote it, but I don't think we should go to the extreme of not shipping firmware just because it's "non free". This problem is much bigger than just wireless too. If we decide to go the crazy debian route of not shipping firmware, we can forget about a ton of storage hardware, a bunch of ethernet drivers, x86 microcode updates, some sound cards and probably a bunch of USB gadgets. Neutering our drivers just as we're starting to get somewhere with "works out of the box" would be a huge step backwards. Is it worth driving more users towards Ubuntu in the name of "freedom", especially given it's a freedom that few (if any) would ever exercise? "Buy something else" isn't really an answer for situations where you can't /get/ something else. Try finding a laptop with a wireless chipset that doesn't need firmware. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Mar 21 01:38:38 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 20 Mar 2007 21:38:38 -0400 Subject: Fedora code of conduct In-Reply-To: <1174421796.4264.7.camel@localhost.localdomain> References: <4600871B.8090908@fedoraproject.org> <1174421796.4264.7.camel@localhost.localdomain> Message-ID: <20070321013838.GB22917@redhat.com> On Tue, Mar 20, 2007 at 03:16:36PM -0500, Tom spot Callaway wrote: > On Wed, 2007-03-21 at 06:45 +0530, Rahul Sundaram wrote: > > Hi > > > > The recent Gentoo mailing lists flamewar[1] leading to developers > > quitting and subsequent adoption of a code of conduct[2], it might be > > useful for us to proactively put in a code of conduct for all of Fedora > > mandatory for all the contributors and for users as well as a prominent > > note for all the mailing lists subscribers and possibly other means. We > > haven't had major issues such as these but as well as scale to more > > contributors it would good to have a mechanism like this and enforce > > that. Comments? > > Honestly, I'd rather deal with that when we need to, and not before. Indeed. In light of the recent "debian has become a quagmire of process" revelations, I hope that Fedora doesn't follow suit. We _already_ have some people complaining that the barrier for entry for becoming a Fedora developer is too high. Adding more obstacles seems to be solving a non-problem. Just because one community distro is doing something doesn't mean we have to do it too. Dave -- http://www.codemonkey.org.uk From sundaram at fedoraproject.org Wed Mar 21 01:39:38 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Mar 2007 07:09:38 +0530 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <1174421739.4264.5.camel@localhost.localdomain> References: <1174421739.4264.5.camel@localhost.localdomain> Message-ID: <46008CDA.5040704@fedoraproject.org> Tom "spot" Callaway wrote: > -------- Forwarded Message -------- >> From: Richard Stallman >> >> I honestly wish we didn't have to have such a clause, but without binary >> firmware, the vast majority of wireless hardware is completely >> non-functional. >> >> We have to recommend that people buy the only products that don't >> require non-free firmware. See the Hardware pages on fsf.org. >> Can you help spread the word about this? > > The link that RMS is referring to is here: > http://www.fsf.org/campaigns/hardware.html > > I don't think there is any harm in Fedora recommending that consumers > purchase wireless products that don't require firmware. I'm not entirely > sure the best way to go about this, though. While talking to some of the Fedora games SIG folks on irc earlier there was general reluctance to put out a Fedora games spin which I was advocating for as a show case for all the nice games we have in the repository . The major reason is that 3D games require proprietary drivers to function on many systems and having just 2D games wouldn't be that appealing. If we include 3D games and users can't run them out of the box in a games spin on many systems that would just appear broken. The solution I thought of was having a driver buddy similar to codec buddy with the major difference that it wont install anything or add pointers to the location of the drivers but warn/educate users on alternatives. If they install the spin on systems where we do not provide have 3D acceleration by default which translates into everyone of these systems with ATI and Nvidia cards then we provide a quick notification on their desktop directing to more information pointing on what chipsets/systems work out of the box in Fedora with full 3D acceleration which translates mainly to the ones with Intel chipsets. Extending this we could do something similar for systems which require binary only firmware with or without redistribution rights. Rahul From skvidal at linux.duke.edu Wed Mar 21 01:47:58 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 20 Mar 2007 21:47:58 -0400 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <20070321013615.GA22917@redhat.com> References: <1174421739.4264.5.camel@localhost.localdomain> <20070321013615.GA22917@redhat.com> Message-ID: <1174441678.25818.91.camel@cutter> On Tue, 2007-03-20 at 21:36 -0400, Dave Jones wrote: > On Tue, Mar 20, 2007 at 03:15:39PM -0500, Tom spot Callaway wrote: > > -------- Forwarded Message -------- > > > From: Richard Stallman > > > > > > I honestly wish we didn't have to have such a clause, but without binary > > > firmware, the vast majority of wireless hardware is completely > > > non-functional. > > > > > > We have to recommend that people buy the only products that don't > > > require non-free firmware. See the Hardware pages on fsf.org. > > > Can you help spread the word about this? > > > > The link that RMS is referring to is here: > > http://www.fsf.org/campaigns/hardware.html > > > > I don't think there is any harm in Fedora recommending that consumers > > purchase wireless products that don't require firmware. I'm not entirely > > sure the best way to go about this, though. > > We can certainly promote it, but I don't think we should go to the extreme of > not shipping firmware just because it's "non free". > > This problem is much bigger than just wireless too. If we decide to go the > crazy debian route of not shipping firmware, we can forget about a ton of > storage hardware, a bunch of ethernet drivers, x86 microcode updates, some > sound cards and probably a bunch of USB gadgets. > > Neutering our drivers just as we're starting to get somewhere with "works out > of the box" would be a huge step backwards. Is it worth driving > more users towards Ubuntu in the name of "freedom", especially given > it's a freedom that few (if any) would ever exercise? > > "Buy something else" isn't really an answer for situations where you can't > /get/ something else. Try finding a laptop with a wireless chipset that > doesn't need firmware. Seems like there are 3 things we should convey, then: 1. you should attempt to buy hw with completely free drivers 2. if you cannot, we have some options to get the best ones available at current which are not quite free but they're closer than a lot of others. 3. if all else fails, be aware of the issue and why we need more pressure on hw vendors to do the right thing. So end users should tell the companies they purchase from that they won't completely open drivers. The whole point is we are educating users where we cannot do a more correct thing, right? -sv From davej at redhat.com Wed Mar 21 01:47:18 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 20 Mar 2007 21:47:18 -0400 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <46008CDA.5040704@fedoraproject.org> References: <1174421739.4264.5.camel@localhost.localdomain> <46008CDA.5040704@fedoraproject.org> Message-ID: <20070321014718.GC22917@redhat.com> On Wed, Mar 21, 2007 at 07:09:38AM +0530, Rahul Sundaram wrote: > While talking to some of the Fedora games SIG folks on irc earlier there > was general reluctance to put out a Fedora games spin which I was > advocating for as a show case for all the nice games we have in the > repository . The major reason is that 3D games require proprietary > drivers to function on many systems and having just 2D games wouldn't be > that appealing. If we include 3D games and users can't run them out of > the box in a games spin on many systems that would just appear broken. Please don't confuse the issues of binary firmware and binary drivers. The two are *not* the same, and have different issues. Endorsing binary drivers in any way (no matter how many "you really shouldn't be doing this" dialogs we throw in the users way) leads to a support nightmare. Over the last six months, the number of users filing kernel bugs tainted with nvidia, vmware and other crap has been increasing dramatically. (Probably a result of compiz/beryl etc). I really don't want this to get any worse than it already is. > The solution I thought of was having a driver buddy similar to codec > buddy with the major difference that it wont install anything or add > pointers to the location of the drivers but warn/educate users on > alternatives. If they install the spin on systems where we do not > provide have 3D acceleration by default which translates into everyone > of these systems with ATI and Nvidia cards then we provide a quick > notification on their desktop directing to more information pointing on > what chipsets/systems work out of the box in Fedora with full 3D > acceleration which translates mainly to the ones with Intel chipsets. Popping up notifications like this isn't going to make anyone think "Oh, ok. I'll rush out and buy a new motherboard/graphics card". > Extending this we could do something similar for systems which require > binary only firmware with or without redistribution rights. What good would this do me if my storage driver needs firmware? Or I need to download firmware for my network driver? Dave -- http://www.codemonkey.org.uk From tcallawa at redhat.com Tue Mar 20 20:47:19 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 20 Mar 2007 15:47:19 -0500 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <1174441678.25818.91.camel@cutter> References: <1174421739.4264.5.camel@localhost.localdomain> <20070321013615.GA22917@redhat.com> <1174441678.25818.91.camel@cutter> Message-ID: <1174423640.4264.10.camel@localhost.localdomain> On Tue, 2007-03-20 at 21:47 -0400, seth vidal wrote: > Seems like there are 3 things we should convey, then: > > 1. you should attempt to buy hw with completely free drivers > > 2. if you cannot, we have some options to get the best ones available at > current which are not quite free but they're closer than a lot of > others. > > 3. if all else fails, be aware of the issue and why we need more > pressure on hw vendors to do the right thing. So end users should tell > the companies they purchase from that they won't completely open > drivers. > > > The whole point is we are educating users where we cannot do a more > correct thing, right? Indeed, and while RMS doesn't like that Fedora is shipping firmware, he'd rather have us follow the above steps than do nothing. ~spot From jwboyer at jdub.homelinux.org Wed Mar 21 01:44:25 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 20 Mar 2007 20:44:25 -0500 Subject: Fedora code of conduct In-Reply-To: <4600871B.8090908@fedoraproject.org> References: <4600871B.8090908@fedoraproject.org> Message-ID: <1174441465.2977.55.camel@vader.jdub.homelinux.org> On Wed, 2007-03-21 at 06:45 +0530, Rahul Sundaram wrote: > Hi > > The recent Gentoo mailing lists flamewar[1] leading to developers > quitting and subsequent adoption of a code of conduct[2], it might be > useful for us to proactively put in a code of conduct for all of Fedora > mandatory for all the contributors and for users as well as a prominent > note for all the mailing lists subscribers and possibly other means. We > haven't had major issues such as these but as well as scale to more > contributors it would good to have a mechanism like this and enforce > that. Comments? I read their proposed code. While the idea behind it is basically "be nice to each other" and that is a good thing, I don't think Fedora needs this at the moment. I agree with spot in that I'd rather cross that bridge when it's needed. And I particularly dislike the whole "proctor" concept and introducing something like seems entirely pointless and draconian at the moment. josh From jwboyer at jdub.homelinux.org Wed Mar 21 01:49:35 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 20 Mar 2007 20:49:35 -0500 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <46008CDA.5040704@fedoraproject.org> References: <1174421739.4264.5.camel@localhost.localdomain> <46008CDA.5040704@fedoraproject.org> Message-ID: <1174441775.2977.61.camel@vader.jdub.homelinux.org> On Wed, 2007-03-21 at 07:09 +0530, Rahul Sundaram wrote: > what chipsets/systems work out of the box in Fedora with full 3D > acceleration which translates mainly to the ones with Intel chipsets. Um, no it doesn't. I have an ATI card in this laptop that has 3D acceleration support in the open source radeon driver. There are actually lots of cards that are supported by that. And noveau (or however it's spelled) is heading down that path for NVidia. No offense, but don't discredit the excellent developers that get 3D accel working on cards that completely lack any documentation by simplifying it the situation to "buy Intel". josh From tcallawa at redhat.com Tue Mar 20 20:50:43 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 20 Mar 2007 15:50:43 -0500 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <20070321013615.GA22917@redhat.com> References: <1174421739.4264.5.camel@localhost.localdomain> <20070321013615.GA22917@redhat.com> Message-ID: <1174423844.4264.13.camel@localhost.localdomain> On Tue, 2007-03-20 at 21:36 -0400, Dave Jones wrote: > This problem is much bigger than just wireless too. If we decide to go > the crazy debian route of not shipping firmware, we can forget about a > ton of storage hardware, a bunch of ethernet drivers, x86 microcode > updates, some sound cards and probably a bunch of USB gadgets. > > Neutering our drivers just as we're starting to get somewhere with > "works out > of the box" would be a huge step backwards. Is it worth driving > more users towards Ubuntu in the name of "freedom", especially given > it's a freedom that few (if any) would ever exercise? Nope. And we have no plans to drop the binary firmware exception at this time. I wish we didn't need it, but we do. ~spot From jwboyer at jdub.homelinux.org Wed Mar 21 01:52:01 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 20 Mar 2007 20:52:01 -0500 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <1174441678.25818.91.camel@cutter> References: <1174421739.4264.5.camel@localhost.localdomain> <20070321013615.GA22917@redhat.com> <1174441678.25818.91.camel@cutter> Message-ID: <1174441922.2977.63.camel@vader.jdub.homelinux.org> On Tue, 2007-03-20 at 21:47 -0400, seth vidal wrote: > On Tue, 2007-03-20 at 21:36 -0400, Dave Jones wrote: > > On Tue, Mar 20, 2007 at 03:15:39PM -0500, Tom spot Callaway wrote: > > > -------- Forwarded Message -------- > > > > From: Richard Stallman > > > > > > > > I honestly wish we didn't have to have such a clause, but without binary > > > > firmware, the vast majority of wireless hardware is completely > > > > non-functional. > > > > > > > > We have to recommend that people buy the only products that don't > > > > require non-free firmware. See the Hardware pages on fsf.org. > > > > Can you help spread the word about this? > > > > > > The link that RMS is referring to is here: > > > http://www.fsf.org/campaigns/hardware.html > > > > > > I don't think there is any harm in Fedora recommending that consumers > > > purchase wireless products that don't require firmware. I'm not entirely > > > sure the best way to go about this, though. > > > > We can certainly promote it, but I don't think we should go to the extreme of > > not shipping firmware just because it's "non free". > > > > This problem is much bigger than just wireless too. If we decide to go the > > crazy debian route of not shipping firmware, we can forget about a ton of > > storage hardware, a bunch of ethernet drivers, x86 microcode updates, some > > sound cards and probably a bunch of USB gadgets. > > > > Neutering our drivers just as we're starting to get somewhere with "works out > > of the box" would be a huge step backwards. Is it worth driving > > more users towards Ubuntu in the name of "freedom", especially given > > it's a freedom that few (if any) would ever exercise? > > > > "Buy something else" isn't really an answer for situations where you can't > > /get/ something else. Try finding a laptop with a wireless chipset that > > doesn't need firmware. > > Seems like there are 3 things we should convey, then: > > 1. you should attempt to buy hw with completely free drivers s/with completely free drivers/that needs no binary bits. The device drivers for several of the devices _are_ GPLed. It's the firmware that is loaded onto the cards that is not. There is a difference. josh From sundaram at fedoraproject.org Wed Mar 21 02:01:15 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Mar 2007 07:31:15 +0530 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <20070321014718.GC22917@redhat.com> References: <1174421739.4264.5.camel@localhost.localdomain> <46008CDA.5040704@fedoraproject.org> <20070321014718.GC22917@redhat.com> Message-ID: <460091EB.9000902@fedoraproject.org> Dave Jones wrote: > On Wed, Mar 21, 2007 at 07:09:38AM +0530, Rahul Sundaram wrote: > > > While talking to some of the Fedora games SIG folks on irc earlier there > > was general reluctance to put out a Fedora games spin which I was > > advocating for as a show case for all the nice games we have in the > > repository . The major reason is that 3D games require proprietary > > drivers to function on many systems and having just 2D games wouldn't be > > that appealing. If we include 3D games and users can't run them out of > > the box in a games spin on many systems that would just appear broken. > > Please don't confuse the issues of binary firmware and binary drivers. > The two are *not* the same, and have different issues. The messaging on both of these can be different. > Endorsing binary drivers in any way (no matter how many "you really > shouldn't be doing this" dialogs we throw in the users way) leads > to a support nightmare. Over the last six months, the number of > users filing kernel bugs tainted with nvidia, vmware and other crap > has been increasing dramatically. (Probably a result of compiz/beryl etc). > I really don't want this to get any worse than it already is. I did clearly specify that the driver buddy wont be installing anything at all and just pointing out users to alternatives. So I don't understand your concern here. > > The solution I thought of was having a driver buddy similar to codec > > buddy with the major difference that it wont install anything or add > > pointers to the location of the drivers but warn/educate users on > > alternatives. If they install the spin on systems where we do not > > provide have 3D acceleration by default which translates into everyone > > of these systems with ATI and Nvidia cards then we provide a quick > > notification on their desktop directing to more information pointing on > > what chipsets/systems work out of the box in Fedora with full 3D > > acceleration which translates mainly to the ones with Intel chipsets. > > Popping up notifications like this isn't going to make anyone > think "Oh, ok. I'll rush out and buy a new motherboard/graphics card". Probably it won't wont immediate effects but it might influence their next buy. It will also add more pressure to hardware manufacturers when we direct users to the ones with open drivers. > > Extending this we could do something similar for systems which require > > binary only firmware with or without redistribution rights. > > What good would this do me if my storage driver needs firmware? > Or I need to download firmware for my network driver? Since we arent removing those firmware end users wont have any change in functionality. There are storage systems or network drivers which dont require binary firmware and if we point users to them this might again this might help influence their next buy. Rahul From sundaram at fedoraproject.org Wed Mar 21 02:04:16 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Mar 2007 07:34:16 +0530 Subject: Fedora code of conduct In-Reply-To: <1174441465.2977.55.camel@vader.jdub.homelinux.org> References: <4600871B.8090908@fedoraproject.org> <1174441465.2977.55.camel@vader.jdub.homelinux.org> Message-ID: <460092A0.6090503@fedoraproject.org> Josh Boyer wrote: > On Wed, 2007-03-21 at 06:45 +0530, Rahul Sundaram wrote: >> Hi >> >> The recent Gentoo mailing lists flamewar[1] leading to developers >> quitting and subsequent adoption of a code of conduct[2], it might be >> useful for us to proactively put in a code of conduct for all of Fedora >> mandatory for all the contributors and for users as well as a prominent >> note for all the mailing lists subscribers and possibly other means. We >> haven't had major issues such as these but as well as scale to more >> contributors it would good to have a mechanism like this and enforce >> that. Comments? > > I read their proposed code. While the idea behind it is basically "be > nice to each other" and that is a good thing, I don't think Fedora needs > this at the moment. I agree with spot in that I'd rather cross that > bridge when it's needed. > > And I particularly dislike the whole "proctor" concept and introducing > something like seems entirely pointless and draconian at the moment. Asking the community to agree to a code of conduct which in your own words just reads as be nice to each others is somehow draconian? It is not pointless when someone indulge in trolling and name calling and few others quit contributing because of that. When we scale you can be rest assured that such behavior will happen. Rahul From davej at redhat.com Wed Mar 21 02:08:29 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 20 Mar 2007 22:08:29 -0400 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <1174441922.2977.63.camel@vader.jdub.homelinux.org> References: <1174421739.4264.5.camel@localhost.localdomain> <20070321013615.GA22917@redhat.com> <1174441678.25818.91.camel@cutter> <1174441922.2977.63.camel@vader.jdub.homelinux.org> Message-ID: <20070321020829.GD22917@redhat.com> On Tue, Mar 20, 2007 at 08:52:01PM -0500, Josh Boyer wrote: > > 1. you should attempt to buy hw with completely free drivers > > s/with completely free drivers/that needs no binary bits. > > The device drivers for several of the devices _are_ GPLed. It's the > firmware that is loaded onto the cards that is not. There is a > difference. The FSF also dislikes drivers including firmware marked as GPL if said firmware is just an array of hex. "Preferred form for modifications" and all that.. Dave -- http://www.codemonkey.org.uk From sundaram at fedoraproject.org Wed Mar 21 02:08:47 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Mar 2007 07:38:47 +0530 Subject: Simplify: Update or Remove Content In-Reply-To: <46003ABE.1070601@redhat.com> References: <46003ABE.1070601@redhat.com> Message-ID: <460093AF.5090306@fedoraproject.org> Warren Togami wrote: > I'm finding our Wiki to be increasingly a disaster. Part of this is due > to stale and unnecessary content. Too much of this creates a > distraction from important content, which only adds to the confusion. I spend a large amount of time every week editing the wiki to organize the content. I would like to think that has kept the wiki atleast consistently good if not increasingly better. Other that some pages with outdated content which we can remove do you have other major problems? Rahul From mmcgrath at redhat.com Wed Mar 21 02:10:47 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 20 Mar 2007 21:10:47 -0500 Subject: Fedora code of conduct In-Reply-To: <460092A0.6090503@fedoraproject.org> References: <4600871B.8090908@fedoraproject.org> <1174441465.2977.55.camel@vader.jdub.homelinux.org> <460092A0.6090503@fedoraproject.org> Message-ID: <46009427.4000908@redhat.com> Rahul Sundaram wrote: > Josh Boyer wrote: >> On Wed, 2007-03-21 at 06:45 +0530, Rahul Sundaram wrote: >>> Hi >>> >>> The recent Gentoo mailing lists flamewar[1] leading to developers >>> quitting and subsequent adoption of a code of conduct[2], it might >>> be useful for us to proactively put in a code of conduct for all of >>> Fedora mandatory for all the contributors and for users as well as a >>> prominent note for all the mailing lists subscribers and possibly >>> other means. We haven't had major issues such as these but as well >>> as scale to more contributors it would good to have a mechanism like >>> this and enforce that. Comments? >> >> I read their proposed code. While the idea behind it is basically "be >> nice to each other" and that is a good thing, I don't think Fedora needs >> this at the moment. I agree with spot in that I'd rather cross that >> bridge when it's needed. >> >> And I particularly dislike the whole "proctor" concept and introducing >> something like seems entirely pointless and draconian at the moment. > > Asking the community to agree to a code of conduct which in your own > words just reads as be nice to each others is somehow draconian? It is > not pointless when someone indulge in trolling and name calling and > few others quit contributing because of that. When we scale you can be > rest assured that such behavior will happen. A code of conduct shows a lack of respect for the community' autonomy. I think it ain't broke, lets not fix it. We've got far better things that need documenting. -Mike From jwboyer at jdub.homelinux.org Wed Mar 21 02:09:45 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 20 Mar 2007 21:09:45 -0500 Subject: Fedora code of conduct In-Reply-To: <460092A0.6090503@fedoraproject.org> References: <4600871B.8090908@fedoraproject.org> <1174441465.2977.55.camel@vader.jdub.homelinux.org> <460092A0.6090503@fedoraproject.org> Message-ID: <1174442985.2977.69.camel@vader.jdub.homelinux.org> On Wed, 2007-03-21 at 07:34 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > On Wed, 2007-03-21 at 06:45 +0530, Rahul Sundaram wrote: > >> Hi > >> > >> The recent Gentoo mailing lists flamewar[1] leading to developers > >> quitting and subsequent adoption of a code of conduct[2], it might be > >> useful for us to proactively put in a code of conduct for all of Fedora > >> mandatory for all the contributors and for users as well as a prominent > >> note for all the mailing lists subscribers and possibly other means. We > >> haven't had major issues such as these but as well as scale to more > >> contributors it would good to have a mechanism like this and enforce > >> that. Comments? > > > > I read their proposed code. While the idea behind it is basically "be > > nice to each other" and that is a good thing, I don't think Fedora needs > > this at the moment. I agree with spot in that I'd rather cross that > > bridge when it's needed. > > > > And I particularly dislike the whole "proctor" concept and introducing > > something like seems entirely pointless and draconian at the moment. > > Asking the community to agree to a code of conduct which in your own > words just reads as be nice to each others is somehow draconian? It is > not pointless when someone indulge in trolling and name calling and few > others quit contributing because of that. When we scale you can be rest > assured that such behavior will happen. No. I said the proctor part would be draconian _at the moment_. The draconian reference was only to the proctor part of that document. I'm not going to repeat my whole previous email. I said I don't think it's needed _at the moment_. That's my opinion and if others wish to adopt some kind of code of conduct which by and large just documents common sense then by all means go forth and adopt. josh From sundaram at fedoraproject.org Wed Mar 21 02:13:53 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Mar 2007 07:43:53 +0530 Subject: Fedora code of conduct In-Reply-To: <46009427.4000908@redhat.com> References: <4600871B.8090908@fedoraproject.org> <1174441465.2977.55.camel@vader.jdub.homelinux.org> <460092A0.6090503@fedoraproject.org> <46009427.4000908@redhat.com> Message-ID: <460094E1.9030709@fedoraproject.org> Mike McGrath wrote: > > A code of conduct shows a lack of respect for the community' autonomy. Do we need more hyperbole? Packaging guidelines show lack of respect for packagers? > I think it ain't broke, lets not fix it. We've got far better things > that need documenting. I consider it half broken right now. People trolling is not very uncommon behavior in Fedora lists. Rahul From davej at redhat.com Wed Mar 21 02:15:52 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 20 Mar 2007 22:15:52 -0400 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <460091EB.9000902@fedoraproject.org> References: <1174421739.4264.5.camel@localhost.localdomain> <46008CDA.5040704@fedoraproject.org> <20070321014718.GC22917@redhat.com> <460091EB.9000902@fedoraproject.org> Message-ID: <20070321021552.GE22917@redhat.com> On Wed, Mar 21, 2007 at 07:31:15AM +0530, Rahul Sundaram wrote: > > users filing kernel bugs tainted with nvidia, vmware and other crap > > has been increasing dramatically. (Probably a result of compiz/beryl etc). > > I really don't want this to get any worse than it already is. > > I did clearly specify that the driver buddy wont be installing anything > at all and just pointing out users to alternatives. So I don't > understand your concern here. That it's solving a problem that isn't there, and legitimising binary drivers. We don't get hundreds of bugs saying "my 3d on my nvidia card is slow" we just get contaminated kernel panics. > > Popping up notifications like this isn't going to make anyone > > think "Oh, ok. I'll rush out and buy a new motherboard/graphics card". > > Probably it won't wont immediate effects but it might influence their > next buy. It will also add more pressure to hardware manufacturers when > we direct users to the ones with open drivers. I wish I shared your faith. "Don't buy nvidia" has been the war-cry for how many years now? They're listening real good. For a long time I remember "buy Matrox, they have acceptable 3d, and are open" being the mantra. Where are they now? Shipping binary drivers for Parhelia. When they gave up, it was "Only ATI support open drivers". They paid so much attention to the 'pressure' that they're now actively preventing people from releasing code that's already been written. We aren't even a blip on the radar of these companies wrt sales compared to the unit volume they shift on that other OS. If the Linux community as a whole moves to a different vendor du jour, it barely affects their bottom line. Dave -- http://www.codemonkey.org.uk From sundaram at fedoraproject.org Wed Mar 21 02:16:27 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Mar 2007 07:46:27 +0530 Subject: Fedora code of conduct In-Reply-To: <1174442985.2977.69.camel@vader.jdub.homelinux.org> References: <4600871B.8090908@fedoraproject.org> <1174441465.2977.55.camel@vader.jdub.homelinux.org> <460092A0.6090503@fedoraproject.org> <1174442985.2977.69.camel@vader.jdub.homelinux.org> Message-ID: <4600957B.7080206@fedoraproject.org> Josh Boyer wrote: > On Wed, 2007-03-21 at 07:34 +0530, Rahul Sundaram wrote: >> Josh Boyer wrote: >>> On Wed, 2007-03-21 at 06:45 +0530, Rahul Sundaram wrote: >>>> Hi >>>> >>>> The recent Gentoo mailing lists flamewar[1] leading to developers >>>> quitting and subsequent adoption of a code of conduct[2], it might be >>>> useful for us to proactively put in a code of conduct for all of Fedora >>>> mandatory for all the contributors and for users as well as a prominent >>>> note for all the mailing lists subscribers and possibly other means. We >>>> haven't had major issues such as these but as well as scale to more >>>> contributors it would good to have a mechanism like this and enforce >>>> that. Comments? >>> I read their proposed code. While the idea behind it is basically "be >>> nice to each other" and that is a good thing, I don't think Fedora needs >>> this at the moment. I agree with spot in that I'd rather cross that >>> bridge when it's needed. >>> >>> And I particularly dislike the whole "proctor" concept and introducing >>> something like seems entirely pointless and draconian at the moment. >> Asking the community to agree to a code of conduct which in your own >> words just reads as be nice to each others is somehow draconian? It is >> not pointless when someone indulge in trolling and name calling and few >> others quit contributing because of that. When we scale you can be rest >> assured that such behavior will happen. > > No. I said the proctor part would be draconian _at the moment_. The > draconian reference was only to the proctor part of that document. We dont need to copy anything at all from Gentoo's code of conduct. That was just an example as concept. If you prefer here is another http://www.ubuntu.com/community/conduct Rahul From mmcgrath at redhat.com Wed Mar 21 02:21:15 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 20 Mar 2007 21:21:15 -0500 Subject: Fedora code of conduct In-Reply-To: <460094E1.9030709@fedoraproject.org> References: <4600871B.8090908@fedoraproject.org> <1174441465.2977.55.camel@vader.jdub.homelinux.org> <460092A0.6090503@fedoraproject.org> <46009427.4000908@redhat.com> <460094E1.9030709@fedoraproject.org> Message-ID: <4600969B.40801@redhat.com> Rahul Sundaram wrote: > Mike McGrath wrote: >> >> A code of conduct shows a lack of respect for the community' autonomy. > Do we need more hyperbole? Packaging guidelines show lack of respect > for packagers? Packaging guidelines exist because we need consistency in our OS, as is evident from our core reviews. It's also a technical matter. >> I think it ain't broke, lets not fix it. We've got far better things >> that need documenting. > I consider it half broken right now. People trolling is not very > uncommon behavior in Fedora lists. A code of conduct will not fix this. We may be able to cut down on specific things like vulgar language but people will always have beliefs and express them. -Mike From sundaram at fedoraproject.org Wed Mar 21 02:24:58 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Mar 2007 07:54:58 +0530 Subject: Fedora code of conduct In-Reply-To: <4600969B.40801@redhat.com> References: <4600871B.8090908@fedoraproject.org> <1174441465.2977.55.camel@vader.jdub.homelinux.org> <460092A0.6090503@fedoraproject.org> <46009427.4000908@redhat.com> <460094E1.9030709@fedoraproject.org> <4600969B.40801@redhat.com> Message-ID: <4600977A.3070306@fedoraproject.org> Mike McGrath wrote: > Packaging guidelines exist because we need consistency in our OS, as is > evident from our core reviews. It's also a technical matter. How about mailing list guidelines? They aren't technical. A code of conduct is not that far from having mailing list guidelines you know. > A code of conduct will not fix this. We may be able to cut down on > specific things like vulgar language but people will always have beliefs > and express them. I dont have a problem with people expressing their belief's. If you agree that it will cut down on specific things like vulgar language that's exactly what I am aiming to solve. Rahul From sundaram at fedoraproject.org Wed Mar 21 02:30:57 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Mar 2007 08:00:57 +0530 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <20070321021552.GE22917@redhat.com> References: <1174421739.4264.5.camel@localhost.localdomain> <46008CDA.5040704@fedoraproject.org> <20070321014718.GC22917@redhat.com> <460091EB.9000902@fedoraproject.org> <20070321021552.GE22917@redhat.com> Message-ID: <460098E1.4080401@fedoraproject.org> Dave Jones wrote: > On Wed, Mar 21, 2007 at 07:31:15AM +0530, Rahul Sundaram wrote: > > > > users filing kernel bugs tainted with nvidia, vmware and other crap > > > has been increasing dramatically. (Probably a result of compiz/beryl etc). > > > I really don't want this to get any worse than it already is. > > > > I did clearly specify that the driver buddy wont be installing anything > > at all and just pointing out users to alternatives. So I don't > > understand your concern here. > > That it's solving a problem that isn't there, and legitimising binary drivers. How does pointing users to systems with open drivers and encouraging their adoption legitimize binary drivers? > We don't get hundreds of bugs saying "my 3d on my nvidia card is slow" > we just get contaminated kernel panics. It seems part of that is atleast because many end users haven't understood why we don't do provide them the drivers by default. This might help. > > > Popping up notifications like this isn't going to make anyone > > > think "Oh, ok. I'll rush out and buy a new motherboard/graphics card". > > > > Probably it won't wont immediate effects but it might influence their > > next buy. It will also add more pressure to hardware manufacturers when > > we direct users to the ones with open drivers. > > I wish I shared your faith. "Don't buy nvidia" has been the war-cry > for how many years now? They're listening real good. We need a more systematic way to guide users towards hardware with open 3D drivers. Just having a list of such hardware is something users have explicitly requested before. If it doesn't have much of a effect that's ok. We didn't install mp3 codecs by default either. Atleast we get to explain our stand. Rahul From mmcgrath at redhat.com Wed Mar 21 02:41:02 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 20 Mar 2007 21:41:02 -0500 Subject: Fedora code of conduct In-Reply-To: <4600977A.3070306@fedoraproject.org> References: <4600871B.8090908@fedoraproject.org> <1174441465.2977.55.camel@vader.jdub.homelinux.org> <460092A0.6090503@fedoraproject.org> <46009427.4000908@redhat.com> <460094E1.9030709@fedoraproject.org> <4600969B.40801@redhat.com> <4600977A.3070306@fedoraproject.org> Message-ID: <46009B3E.5060908@redhat.com> Rahul Sundaram wrote: > I dont have a problem with people expressing their belief's. If you > agree that it will cut down on specific things like vulgar language > that's exactly what I am aiming to solve. I was unaware that vulgar language was a regular occurrence on the mailing lists. Write up some guidelines and see if people approve of them. -Mike From skvidal at linux.duke.edu Wed Mar 21 02:46:04 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 20 Mar 2007 22:46:04 -0400 Subject: Fedora code of conduct In-Reply-To: <4600977A.3070306@fedoraproject.org> References: <4600871B.8090908@fedoraproject.org> <1174441465.2977.55.camel@vader.jdub.homelinux.org> <460092A0.6090503@fedoraproject.org> <46009427.4000908@redhat.com> <460094E1.9030709@fedoraproject.org> <4600969B.40801@redhat.com> <4600977A.3070306@fedoraproject.org> Message-ID: <1174445164.25818.95.camel@cutter> On Wed, 2007-03-21 at 07:54 +0530, Rahul Sundaram wrote: > Mike McGrath wrote: > > > Packaging guidelines exist because we need consistency in our OS, as is > > evident from our core reviews. It's also a technical matter. > > How about mailing list guidelines? They aren't technical. A code of > conduct is not that far from having mailing list guidelines you know. > > > A code of conduct will not fix this. We may be able to cut down on > > specific things like vulgar language but people will always have beliefs > > and express them. > > I dont have a problem with people expressing their belief's. If you > agree that it will cut down on specific things like vulgar language > that's exactly what I am aiming to solve. My belief is that vulgar language is an invention of prurient busybodies. Or better yet: I'm offended by any references to eating meat, driving cars, closed source software and ALL religions. Make sure none of those things ever come up, especially not in personal sigs and never in conversation. and when you're done with that I'll find something else ridiculous to be offended by and go around yelling that you should change the code of conduct to encompass that, too. Seth 'Reductio ad absurdium' Vidal -sv From skvidal at linux.duke.edu Wed Mar 21 02:48:16 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 20 Mar 2007 22:48:16 -0400 Subject: Simplify: Update or Remove Content In-Reply-To: References: <46003ABE.1070601@redhat.com> Message-ID: <1174445296.25818.97.camel@cutter> On Tue, 2007-03-20 at 15:58 -0400, Max Spevack wrote: > On Tue, 20 Mar 2007, Warren Togami wrote: > > > In this case, we should wipe out this content and insert redirects and > > references to upstream resources where necessary. Does anyone want to > > clean this up? > > Removing stale and old content from the wiki is a mammoth job, and also > one that is quite tedious. Seems like it definitely needs automation. > > Some moin moin instances that I've seen have an "AbandonedPages" option, > that shows you which pages have gone the longest without being edited. > Ours doesn't have that by default under /wiki/SiteNavigation -- possibly > because of the size of the wiki? > > I would say that if someone on our infrastructure team can pipe together > some commands to show us the top 500 wiki pages that either have gone the > longest without being edited or being looked at, that would be an > interesting starting point. +1 for wiki janitors. hmm - sounds like a SIG. in fact. -sv From matt at domsch.com Wed Mar 21 03:37:49 2007 From: matt at domsch.com (Matt Domsch) Date: Tue, 20 Mar 2007 21:37:49 -0600 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <20070321021552.GE22917@redhat.com> References: <1174421739.4264.5.camel@localhost.localdomain> <46008CDA.5040704@fedoraproject.org> <20070321014718.GC22917@redhat.com> <460091EB.9000902@fedoraproject.org> <20070321021552.GE22917@redhat.com> Message-ID: <20070321033749.GB22845@domsch.com> On Tue, Mar 20, 2007 at 10:15:52PM -0400, Dave Jones wrote: > We aren't even a blip on the radar of these companies wrt sales compared > to the unit volume they shift on that other OS. > If the Linux community as a whole moves to a different vendor du jour, > it barely affects their bottom line. We're a blip, but if even all of the 100k votes on the dellideastorm.com site in the last few weeks for Linux systems bought two a year, that'd be <1% of the Windows volume. Doesn't mean we shouldn't try, but it is an uphill battle. I agree with our stance of 100% Free drivers, and our limited exception for binary firmware. -Matt From davej at redhat.com Wed Mar 21 04:00:53 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 21 Mar 2007 00:00:53 -0400 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <20070321033749.GB22845@domsch.com> References: <1174421739.4264.5.camel@localhost.localdomain> <46008CDA.5040704@fedoraproject.org> <20070321014718.GC22917@redhat.com> <460091EB.9000902@fedoraproject.org> <20070321021552.GE22917@redhat.com> <20070321033749.GB22845@domsch.com> Message-ID: <20070321040053.GA13218@redhat.com> On Tue, Mar 20, 2007 at 09:37:49PM -0600, Matt Domsch wrote: > On Tue, Mar 20, 2007 at 10:15:52PM -0400, Dave Jones wrote: > > We aren't even a blip on the radar of these companies wrt sales compared > > to the unit volume they shift on that other OS. > > If the Linux community as a whole moves to a different vendor du jour, > > it barely affects their bottom line. > > We're a blip, but if even all of the 100k votes on the > dellideastorm.com site in the last few weeks for Linux systems bought > two a year, that'd be <1% of the Windows volume. Doesn't mean we > shouldn't try, but it is an uphill battle. The difference is that Dell *are* listening. I see no signs that any of the big proprietary gfx driver vendors are doing so. ATI especially. Dave -- http://www.codemonkey.org.uk From mmcgrath at redhat.com Wed Mar 21 04:02:39 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 20 Mar 2007 23:02:39 -0500 Subject: Simplify: Update or Remove Content In-Reply-To: References: <46003ABE.1070601@redhat.com> Message-ID: <4600AE5F.10000@redhat.com> Max Spevack wrote: > On Tue, 20 Mar 2007, Warren Togami wrote: > >> In this case, we should wipe out this content and insert redirects >> and references to upstream resources where necessary. Does anyone >> want to clean this up? > > Removing stale and old content from the wiki is a mammoth job, and > also one that is quite tedious. Seems like it definitely needs > automation. > Some moin moin instances that I've seen have an "AbandonedPages" > option, that shows you which pages have gone the longest without being > edited. Ours doesn't have that by default under /wiki/SiteNavigation > -- possibly because of the size of the wiki? > > I would say that if someone on our infrastructure team can pipe > together some commands to show us the top 500 wiki pages that either > have gone the longest without being edited or being looked at, that > would be an interesting starting point. Here's the script for last edited. It should work... seriously - wget -qO- 'http://fedoraproject.org/wiki/?action=sitemap' | grep "loc\|lastmod" | sed -e 's/^ *//g' | sed '/<\/loc.*/ {N;s/<\/loc.*\n/ /}' | sed -e 's/\r//g' | sed -e :a -e 's/<[^>]*>//g;/ References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <1174414413.4531.133.camel@mccallum.corsepiu.local> <80d7e4090703201123n4dbb65amd12fd0555cfecab2@mail.gmail.com> Message-ID: <1174451530.4531.183.camel@mccallum.corsepiu.local> On Tue, 2007-03-20 at 12:23 -0600, Stephen John Smoogen wrote: > On 3/20/07, Ralf Corsepius wrote: > > On Tue, 2007-03-20 at 12:04 -0400, Greg Dekoenigsberg wrote: > > > On Tue, 20 Mar 2007, Ralf Corsepius wrote: > > > > > > > Instead, Fedora has a leadership system, which is widely being ignored > > > > by the public, unless it interferes with individual contributor > > > > interests. > > > > > > Isn't that basically how governments work? > > Temporarily yes. > > > > History tells, in longer terms such governments inevitably will die. In > > democratic systems, they sooner or later will be replaced, in absolutist > > systems these governments will sooner or later be chased or die > > lonesome. > > > > Is this the "pure anarchy is the only true freedom!" argument? No, this the a "government without supporters will not work" argument. A consequence from http://en.wikipedia.org/wiki/Social_contract and its reflection on modern democracy http://en.wikipedia.org/wiki/Social_Contract_%28Rousseau%29 Ralf From notting at redhat.com Wed Mar 21 05:56:38 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 21 Mar 2007 01:56:38 -0400 Subject: Fedora code of conduct In-Reply-To: <1174445164.25818.95.camel@cutter> References: <4600871B.8090908@fedoraproject.org> <1174441465.2977.55.camel@vader.jdub.homelinux.org> <460092A0.6090503@fedoraproject.org> <46009427.4000908@redhat.com> <460094E1.9030709@fedoraproject.org> <4600969B.40801@redhat.com> <4600977A.3070306@fedoraproject.org> <1174445164.25818.95.camel@cutter> Message-ID: <20070321055638.GC24435@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > Seth 'Reductio ad absurdium' Vidal Lingua mortua? Offendi. :P Bill From skvidal at linux.duke.edu Wed Mar 21 06:06:49 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 21 Mar 2007 02:06:49 -0400 Subject: Fedora code of conduct In-Reply-To: <20070321055638.GC24435@nostromo.devel.redhat.com> References: <4600871B.8090908@fedoraproject.org> <1174441465.2977.55.camel@vader.jdub.homelinux.org> <460092A0.6090503@fedoraproject.org> <46009427.4000908@redhat.com> <460094E1.9030709@fedoraproject.org> <4600969B.40801@redhat.com> <4600977A.3070306@fedoraproject.org> <1174445164.25818.95.camel@cutter> <20070321055638.GC24435@nostromo.devel.redhat.com> Message-ID: <1174457209.25818.101.camel@cutter> On Wed, 2007-03-21 at 01:56 -0400, Bill Nottingham wrote: > seth vidal (skvidal at linux.duke.edu) said: > > Seth 'Reductio ad absurdium' Vidal > > Lingua mortua? Offendi. :P > damn right! -sv From fedora at leemhuis.info Wed Mar 21 06:20:22 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 Mar 2007 07:20:22 +0100 Subject: Lessons Learned In-Reply-To: <1174430081.4010.23.camel@localhost.localdomain> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> Message-ID: <4600CEA6.3040200@leemhuis.info> Hi! Josh said some good stuff already, no need to repeat all of it. But: On 20.03.2007 23:34, Christopher Blizzard wrote: > I honestly believe that Greg, Max, Jeremy, Jesse, and the other folks > who lead inside of the Fedora community are interested in building a > community of doing, not a culture of talking. We respect those who Do > Things and encourage them. Jesse, Jeremy, Mike McGrath are good > examples of this - they are lead-by-doing people and it works. >From my point of view I'd say it works to get stuff done, but it doesn't work to get the community involved ATM. FESCo was good (but still far from perfect) in getting the community involved, as it had influence in certain decisions and meets in the open. With the merge happening now it seem FESCo seems to me much less important then before; to much small to medium stuff gets simply done without even bothering to ask FESCo -- that's a fault IMHO. A lot of medium to big stuff gets directly taken to the board -- FESCo afaics often gets circumvented, even if the tasks are engeneering tasks. And that's what FESCo is for afaics. One example: The "Packaging Committee is responsible for EPEL, too". I'd say this should have been acked in a FESCo meeting, as FESCo is the Committee that i responsible for both the Packaging Committee and EPEL. But it seems the Board simply took it up now and made it effective before FESCo could even talk about it in a meeting. The result if totally fine for me as I was one of those that asked for this setup. But IMHO it would have been FESCo's job to ack it -- after that it could have been brought to the board (if needed). Why is FESCo so important to me you might ask? Well, it's the committee where the community can get heard and get involved in the meeting. That's hardly the case in the Board meetings -- the broadcasting to IRC is nice, but it's goes mostly in one direction. FESCo meetings are way more interactive, and that's IMHO needed to get the community involved. This and a whole lot of similar really really bothers me ATM and I could write a whole lot about that. But I'm currently in the waiting state; the merge is a whole lot of work and I can understand that some things are not perfect yet and need getting them done is ATM a bit more important then to make sure we have a proper organization scheme. But I'd say we really need to work on improving it soon and need to be a bit more careful. CU thl From aoliva at redhat.com Wed Mar 21 06:47:28 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 21 Mar 2007 03:47:28 -0300 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <1174441678.25818.91.camel@cutter> (seth vidal's message of "Tue\, 20 Mar 2007 21\:47\:58 -0400") References: <1174421739.4264.5.camel@localhost.localdomain> <20070321013615.GA22917@redhat.com> <1174441678.25818.91.camel@cutter> Message-ID: On Mar 20, 2007, seth vidal wrote: > The whole point is we are educating users where we cannot do a more > correct thing, right? Educating users might very well be the best thing we can do, indeed. I presented a suggestion to spot and Rahul in private, maybe I should bring it up here, since we're on this topic. What if Fedora were to split the non-Free firmware into a separate repository and separate bootable media, such that the default bootable/installable media would still be 100% Free Software, and it would have a Firmware Buddy that would let users know about freedom-depriving hardware in their computers. When presented with such a message, the user would have the option of proceeding (if possible) with the 100% Free Software install, even if that would leave some hardware features unusable, or load the non-free firmware media (think drivers disk) or reboot into an alternate media (say a boot-non-free.iso) to perform even the install using such non-Free components. If we do this right, we may even be able to take these non-Free components completely out of the Fedora project per se, and leave it up to third parties to undertake the issue of integration of such non-Free components. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From fedora at leemhuis.info Wed Mar 21 07:08:33 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 Mar 2007 08:08:33 +0100 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: References: <1174421739.4264.5.camel@localhost.localdomain> <20070321013615.GA22917@redhat.com> <1174441678.25818.91.camel@cutter> Message-ID: <4600D9F1.70707@leemhuis.info> On 21.03.2007 07:47, Alexandre Oliva wrote: > What if Fedora were to split the non-Free firmware into a separate > repository and separate bootable media [...] My take: split firmware files into separate packages (the kernel includes a lot currently IIRC) as a middle-term goal to make a "firmware-less Fedora spin" easily possible. Maybe we then later can do a separate repository and separate bootable media as next step in the long term. But I'd say we revisit that idea when things got split and the kernel/its initial-ramdisk/all our other tools have support for firmwares found in separate packages. CU thl From thecubic at thecubic.net Wed Mar 21 08:58:31 2007 From: thecubic at thecubic.net (Dave Carlson) Date: Wed, 21 Mar 2007 03:58:31 -0500 Subject: Fedora code of conduct In-Reply-To: <46009B3E.5060908@redhat.com> References: <4600871B.8090908@fedoraproject.org> <4600977A.3070306@fedoraproject.org> <46009B3E.5060908@redhat.com> Message-ID: <200703210400.15106.thecubic@thecubic.net> On Tuesday 20 March 2007 21:41:02 Mike McGrath wrote: > Write up some guidelines and see if people approve of them. Here's a start: * Flaming and trolling are absolutely prohibited. * Unscrupulous personal comments lead to defections; avoid ad hominem. * Courtesy to all technical and linguistic skill levels is necessary. * Kindness and respect are mandatory in dealing with differing opinions. Kidding aside, I don't think we can get something concrete out of a code of conduct process. With that, we're left with what amounts to "No Jackassery". If someone crawls on to our list and (e.g.) calls Alan Cox a noob, well, we can all have a laugh. Or are we so easily offended and fragile that decorum necessitates bureaucracy? -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sankar at redhat.com Wed Mar 21 09:15:49 2007 From: sankar at redhat.com (Sankarshan Mukhopadhyay) Date: Wed, 21 Mar 2007 14:45:49 +0530 Subject: Fedora code of conduct In-Reply-To: <4600957B.7080206@fedoraproject.org> References: <4600871B.8090908@fedoraproject.org> <1174441465.2977.55.camel@vader.jdub.homelinux.org> <460092A0.6090503@fedoraproject.org> <1174442985.2977.69.camel@vader.jdub.homelinux.org> <4600957B.7080206@fedoraproject.org> Message-ID: <4600F7C5.1090602@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rahul Sundaram wrote: > We dont need to copy anything at all from Gentoo's code of conduct. That > was just an example as concept. If you prefer here is another > http://www.ubuntu.com/community/conduct and http://www.gentoo.org/proj/en/council/coc.xml in effect end up saying the same things: * Be respectful * Collaborate * Be considerate might not be a bad idea to have a document that sums up the philosophy. As to whether that document would be turned into the flaming sword of justice is another question :Sankarshan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGAPfF+g4kmZ76nyERAjVBAJ9T1Afk0Wj031l24j/2fbsivhqP1ACfU0gV MG9PpKlU/uTtVFku+ys+who= =Kwg/ -----END PGP SIGNATURE----- From david at lovesunix.net Wed Mar 21 10:13:17 2007 From: david at lovesunix.net (David Nielsen) Date: Wed, 21 Mar 2007 11:13:17 +0100 Subject: Fedora code of conduct In-Reply-To: <1174421796.4264.7.camel@localhost.localdomain> References: <4600871B.8090908@fedoraproject.org> <1174421796.4264.7.camel@localhost.localdomain> Message-ID: <1174471997.2780.10.camel@dawkins> tir, 20 03 2007 kl. 15:16 -0500, skrev Tom "spot" Callaway: > On Wed, 2007-03-21 at 06:45 +0530, Rahul Sundaram wrote: > > Hi > > > > The recent Gentoo mailing lists flamewar[1] leading to developers > > quitting and subsequent adoption of a code of conduct[2], it might be > > useful for us to proactively put in a code of conduct for all of Fedora > > mandatory for all the contributors and for users as well as a prominent > > note for all the mailing lists subscribers and possibly other means. We > > haven't had major issues such as these but as well as scale to more > > contributors it would good to have a mechanism like this and enforce > > that. Comments? > > Honestly, I'd rather deal with that when we need to, and not before. Absolutely, there's no need to add rules and guidelines just for the sake of it. It's a waste of time and it gets in the way. Honestly if we go back and read even the most heated debates we've seen in the community often when people realise they step over the line they will volunteer a apology for their behavior. I don't think we need to police our ranks just yet, I hope we never have to. - David -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Wed Mar 21 11:08:48 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 21 Mar 2007 12:08:48 +0100 Subject: Lessons Learned In-Reply-To: <4600CEA6.3040200@leemhuis.info> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> Message-ID: <20070321120848.4067496e.bugs.michael@gmx.net> On Wed, 21 Mar 2007 07:20:22 +0100, Thorsten Leemhuis wrote: > Hi! > > Josh said some good stuff already, no need to repeat all of it. True. > FESCo was good (but still far from perfect) in getting the community > involved, as it had influence in certain decisions and meets in the > open. Different than that. It had started as a group with the desire to move several things forward at the Extras front *actively*, which included boring but necessary tasks. Red Hat in turn made a few allowances for FESCo in order to remove some road blocks. A necessity. Else Extras would not have taken off. I wouldn't call the result "influence", though. The influence is mostly by a very few individuals, who sponsor hardware and access to it or who make things happen inside Red Hat. > With the merge happening now it seem FESCo seems to me much less > important then before; to much small to medium stuff gets simply done > without even bothering to ask FESCo -- that's a fault IMHO. A lot of > medium to big stuff gets directly taken to the board -- FESCo afaics > often gets circumvented, even if the tasks are engeneering tasks. And > that's what FESCo is for afaics. FESCo fails to define its field of activity. The moved Wiki pages for the new FESCo don't add any description, but are still in CategoryExtras, and it seems FESCo just picks random things that pop up here and there. There is no hint as whether any group still leads Extras -- trying to remove the word "Extras" everywhere is not the full show. What I'm missing is the regular presence of FESCo or its members in official day-to-day decisions and state-of-the-union addresses, so the community of contributors gets the feeling that there is some kind of leadership actually. Instead, it has increasingly become a sit-and-wait process, where hardly anyone seems to care about some things until somebody else complains. It also takes too long to create a low-traffic announce list, where to reach package maintainers actually. fedora-maintainers apparently is not the place where to reach them. Cross-posts to at least -devel, -extras and -maintainers are way too popular. Annoying. Surely the reason is that hardly anyone knows what the purpose of those lists is. Well, I don't either, looking at the thread index. When I remember how often we've practised preparing Extras for the next release of Core, I believe this time we perform badly. We have Matt Domsch's rebuild reports, the broken deps report, the broken upgrade paths report, a FE7Target tracker bug filled with lots of bugs. Are any of the reports on the mailing-lists evaluated by anybody in FESCo? It's interesting, for instance, that Zope and Plone, which are in the broken upgrade paths report for a very long time, don't support Python 2.5. Yet Extras bugzilla did not cover that. Huh? So: https://bugzilla.redhat.com/233187 https://bugzilla.redhat.com/233185 Nearly all the other upgrade path problems were not in bugzilla when I had a look yesterday. A big bunch now is in the FE7Target tracker, at least. Several I've fixed myself, but ACLs block access to other packages. I'm disappointed that FESCo (with 'E' as in Extras) in no longer involved in trying to reduce crap in the distribution, not even with a roll call. I don't mind the AWOL process, which I've tried with one maintainer I'm unable to reach for several weeks. But we're at test3. Time is getting short if we still want to offer something that doesn't bear too much of a risk of confronting users with broken deps and non-working components -- especially after Eric Raymonds complaints about [albeit house-made] dependency problems in Fedora-land. From fedora at leemhuis.info Wed Mar 21 11:35:56 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 Mar 2007 12:35:56 +0100 Subject: Lessons Learned In-Reply-To: <20070321120848.4067496e.bugs.michael@gmx.net> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> Message-ID: <4601189C.3000004@leemhuis.info> On 21.03.2007 12:08, Michael Schwendt wrote: > On Wed, 21 Mar 2007 07:20:22 +0100, Thorsten Leemhuis wrote: > [...] >> FESCo was good (but still far from perfect) in getting the community >> involved, as it had influence in certain decisions and meets in the >> open. > Different than that. It had started as a group with the desire to move > several things forward at the Extras front *actively*, which included > boring but necessary tasks. > > Red Hat in turn made a few allowances for FESCo in order to remove some > road blocks. A necessity. Else Extras would not have taken off. I wouldn't > call the result "influence", though. The influence is mostly by a very few > individuals, who sponsor hardware and access to it or who make things > happen inside Red Hat. Well, I think you are painting it more worse than it is, but I agree that you have some points in between it. >> With the merge happening now it seem FESCo seems to me much less >> important then before; to much small to medium stuff gets simply done >> without even bothering to ask FESCo -- that's a fault IMHO. A lot of >> medium to big stuff gets directly taken to the board -- FESCo afaics >> often gets circumvented, even if the tasks are engeneering tasks. And >> that's what FESCo is for afaics. > FESCo fails to define its field of activity. The moved Wiki pages for the > new FESCo don't add any description, The thing important for me is: it seems the pages were simply moved, without asking the public or FESCo for opinions first. Yes, the topic was discussed once in the public some weeks earlier (without a real outcome), but now it was simply done afaics, without even discussing FESCo first. Was such a hectic really necessary? Side note: I think the moving in general was a good idea, but how it was done without asking or announcing it beforehand was simply bad bad bad. I think even a board member should be a bit more careful and ask the proper committee (in this case FESCo) and the public for opinions before doing such a major task. Sure, simply doing stuff is easier often. But people that operate in "heads down, I don't care what other people think and do my way without asking the public or committees that are responsible for it because that is painful work" is as far as I can see not the way to get a community interested in Fedora. > but are still in CategoryExtras, and > it seems FESCo just picks random things that pop up here and there. There > is no hint as whether any group still leads Extras -- trying to remove the > word "Extras" everywhere is not the full show. Agreed. > What I'm missing is the regular presence of FESCo or its members in > official day-to-day decisions and state-of-the-union addresses, so the > community of contributors gets the feeling that there is some kind of > leadership actually. Instead, it has increasingly become a sit-and-wait > process, where hardly anyone seems to care about some things until > somebody else complains. Agreed. > It also takes too long to create a low-traffic announce list, where to > reach package maintainers actually. fedora-maintainers apparently is not > the place where to reach them. Cross-posts to at least -devel, -extras and > -maintainers are way too popular. Annoying. Surely the reason is that > hardly anyone knows what the purpose of those lists is. Well, I don't > either, looking at the thread index. Well, the list fedora-maintainers-announce actually exists, we just don't use it (and even worse -- there are people questing is usefulness...). > When I remember how often we've practised preparing Extras for the next > release of Core, I believe this time we perform badly. We have Matt > Domsch's rebuild reports, the broken deps report, the broken upgrade paths > report, a FE7Target tracker bug filled with lots of bugs. Are any of the > reports on the mailing-lists evaluated by anybody in FESCo? It's > interesting, for instance, that Zope and Plone, which are in the broken > upgrade paths report for a very long time, don't support Python 2.5. Yet > Extras bugzilla did not cover that. Huh? So: > > https://bugzilla.redhat.com/233187 > https://bugzilla.redhat.com/233185 > > Nearly all the other upgrade path problems were not in bugzilla when I had > a look yesterday. A big bunch now is in the FE7Target tracker, at least. > Several I've fixed myself, but ACLs block access to other packages. I'm > disappointed that FESCo (with 'E' as in Extras) in no longer involved in > trying to reduce crap in the distribution, not even with a roll call. > I don't mind the AWOL process, which I've tried with one maintainer I'm > unable to reach for several weeks. But we're at test3. Time is getting > short if we still want to offer something that doesn't bear too much of a > risk of confronting users with broken deps and non-working components -- > especially after Eric Raymonds complaints about [albeit house-made] > dependency problems in Fedora-land. Yeah, you have some point here. CU thl From jwboyer at jdub.homelinux.org Wed Mar 21 11:48:55 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 21 Mar 2007 06:48:55 -0500 Subject: Lessons Learned In-Reply-To: <4601189C.3000004@leemhuis.info> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> <4601189C.3000004@leemhuis.info> Message-ID: <1174477736.2977.73.camel@vader.jdub.homelinux.org> On Wed, 2007-03-21 at 12:35 +0100, Thorsten Leemhuis wrote: > > Nearly all the other upgrade path problems were not in bugzilla when I had > > a look yesterday. A big bunch now is in the FE7Target tracker, at least. > > Several I've fixed myself, but ACLs block access to other packages. I'm > > disappointed that FESCo (with 'E' as in Extras) in no longer involved in > > trying to reduce crap in the distribution, not even with a roll call. > > I don't mind the AWOL process, which I've tried with one maintainer I'm > > unable to reach for several weeks. But we're at test3. Time is getting > > short if we still want to offer something that doesn't bear too much of a > > risk of confronting users with broken deps and non-working components -- > > especially after Eric Raymonds complaints about [albeit house-made] > > dependency problems in Fedora-land. > > Yeah, you have some point here. Yes, he very much does. I'll add a "Broken Upgrade Paths" topic to the schedule. josh From bugs.michael at gmx.net Wed Mar 21 12:14:09 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 21 Mar 2007 13:14:09 +0100 Subject: Lessons Learned In-Reply-To: <4601189C.3000004@leemhuis.info> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> <4601189C.3000004@leemhuis.info> Message-ID: <20070321131409.73efe136.bugs.michael@gmx.net> On Wed, 21 Mar 2007 12:35:56 +0100, Thorsten Leemhuis wrote: > > FESCo fails to define its field of activity. The moved Wiki pages for the > > new FESCo don't add any description, > > The thing important for me is: it seems the pages were simply moved, > without asking the public or FESCo for opinions first. Yes, the topic > was discussed once in the public some weeks earlier (without a real > outcome), but now it was simply done afaics, without even discussing > FESCo first. Was such a hectic really necessary? 1) Having to search for the old Fedora Extras main page was "Very Funny"(TM). Apparently it's now called Fedora Packaging on the index. It's getting confusing. 2) The rename was incomplete in that everybody who is subscribed to the old page names, now has to update the Wiki preferences. E.g. presently I'm still subscribed to pages, which don't exist anymore because they have been moved somewhere. From blizzard at redhat.com Wed Mar 21 13:15:43 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 21 Mar 2007 09:15:43 -0400 Subject: Fedora code of conduct In-Reply-To: <20070321055638.GC24435@nostromo.devel.redhat.com> References: <4600871B.8090908@fedoraproject.org> <1174441465.2977.55.camel@vader.jdub.homelinux.org> <460092A0.6090503@fedoraproject.org> <46009427.4000908@redhat.com> <460094E1.9030709@fedoraproject.org> <4600969B.40801@redhat.com> <4600977A.3070306@fedoraproject.org> <1174445164.25818.95.camel@cutter> <20070321055638.GC24435@nostromo.devel.redhat.com> Message-ID: <1174482943.7776.6.camel@localhost.localdomain> http://tromey.com/blog/?p=328 --Chris From skvidal at linux.duke.edu Wed Mar 21 13:26:51 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 21 Mar 2007 09:26:51 -0400 Subject: Fedora code of conduct In-Reply-To: <1174482943.7776.6.camel@localhost.localdomain> References: <4600871B.8090908@fedoraproject.org> <1174441465.2977.55.camel@vader.jdub.homelinux.org> <460092A0.6090503@fedoraproject.org> <46009427.4000908@redhat.com> <460094E1.9030709@fedoraproject.org> <4600969B.40801@redhat.com> <4600977A.3070306@fedoraproject.org> <1174445164.25818.95.camel@cutter> <20070321055638.GC24435@nostromo.devel.redhat.com> <1174482943.7776.6.camel@localhost.localdomain> Message-ID: <1174483611.25818.129.camel@cutter> On Wed, 2007-03-21 at 09:15 -0400, Christopher Blizzard wrote: > http://tromey.com/blog/?p=328 > Interesting entry. In it he says: "The author offers two diagnostic tests to identify chronic assholes. First, does interacting with the person consistently drain your energy and leave you feeling oppressed or humiliated? Second, how does the person treat other people less powerful than him- (or her-) self?" What I'm trying to figure out is the occasions when I conflate the subject draining my energy and leaving me feeling oppressed or humiliated and the person leaving me feeling oppressed or humiliated. I've found there are lots of subjects or projects that steal my will to live. Anyone else? -sv From gdk at redhat.com Wed Mar 21 13:56:12 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 21 Mar 2007 09:56:12 -0400 (EDT) Subject: Lessons Learned In-Reply-To: <1174433175.2977.51.camel@vader.jdub.homelinux.org> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <1174433175.2977.51.camel@vader.jdub.homelinux.org> Message-ID: On Tue, 20 Mar 2007, Josh Boyer wrote: > And to be honest, I feel it puts the people that are paid to work on > Fedora in an unfair position. They are tasked with getting things done > in Fedora _and_ making sure the community is involved. And at times > involving the community slows things down simply because the volunteers > aren't available during the day. So now you have the interesting > situation where the paid Doers can literally accomplish more than the > rest of the group and therefore in a meritocracy they have an advantage > of being more valuable. Sometimes it works out that way -- but a lot of times it doesn't. Sometimes the paid Doers have to accomplish things that are Boring But Must Be Done -- and the great advantage of unpaid Doers is that they can frequently focus on the interesting/innovative work, because a manager isn't breathing down their neck. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From gdk at redhat.com Wed Mar 21 13:57:39 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 21 Mar 2007 09:57:39 -0400 (EDT) Subject: Fedora code of conduct In-Reply-To: <1174421796.4264.7.camel@localhost.localdomain> References: <4600871B.8090908@fedoraproject.org> <1174421796.4264.7.camel@localhost.localdomain> Message-ID: On Tue, 20 Mar 2007, Tom "spot" Callaway wrote: > Honestly, I'd rather deal with that when we need to, and not before. +1. Moar Reading is Bad. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From jwboyer at jdub.homelinux.org Wed Mar 21 14:01:45 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 21 Mar 2007 09:01:45 -0500 Subject: Fedora code of conduct In-Reply-To: <1174483611.25818.129.camel@cutter> References: <4600871B.8090908@fedoraproject.org> <1174441465.2977.55.camel@vader.jdub.homelinux.org> <460092A0.6090503@fedoraproject.org> <46009427.4000908@redhat.com> <460094E1.9030709@fedoraproject.org> <4600969B.40801@redhat.com> <4600977A.3070306@fedoraproject.org> <1174445164.25818.95.camel@cutter> <20070321055638.GC24435@nostromo.devel.redhat.com> <1174482943.7776.6.camel@localhost.localdomain> <1174483611.25818.129.camel@cutter> Message-ID: <1174485705.3416.61.camel@zod.rchland.ibm.com> On Wed, 2007-03-21 at 09:26 -0400, seth vidal wrote: > On Wed, 2007-03-21 at 09:15 -0400, Christopher Blizzard wrote: > > http://tromey.com/blog/?p=328 > > > > Interesting entry. In it he says: > > "The author offers two diagnostic tests to identify chronic assholes. > First, does interacting with the person consistently drain your energy > and leave you feeling oppressed or humiliated? Second, how does the > person treat other people less powerful than him- (or her-) self?" > > What I'm trying to figure out is the occasions when I conflate the > subject draining my energy and leaving me feeling oppressed or > humiliated and the person leaving me feeling oppressed or humiliated. > > I've found there are lots of subjects or projects that steal my will to > live. Anyone else? Yes. josh From gdk at redhat.com Wed Mar 21 14:01:12 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 21 Mar 2007 10:01:12 -0400 (EDT) Subject: Fedora code of conduct In-Reply-To: <460094E1.9030709@fedoraproject.org> References: <4600871B.8090908@fedoraproject.org> <1174441465.2977.55.camel@vader.jdub.homelinux.org> <460092A0.6090503@fedoraproject.org> <46009427.4000908@redhat.com> <460094E1.9030709@fedoraproject.org> Message-ID: On Wed, 21 Mar 2007, Rahul Sundaram wrote: > I consider it half broken right now. People trolling is not very uncommon > behavior in Fedora lists. All the codes of conduct on Earth aren't going to change that. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From gdk at redhat.com Wed Mar 21 14:06:51 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 21 Mar 2007 10:06:51 -0400 (EDT) Subject: Fedora code of conduct In-Reply-To: <200703210400.15106.thecubic@thecubic.net> References: <4600871B.8090908@fedoraproject.org> <4600977A.3070306@fedoraproject.org> <46009B3E.5060908@redhat.com> <200703210400.15106.thecubic@thecubic.net> Message-ID: On Wed, 21 Mar 2007, Dave Carlson wrote: > Kidding aside, I don't think we can get something concrete out of a code of > conduct process. With that, we're left with what amounts to "No Jackassery". A big +1 to "No Jackassery." Dave, I nominate you to start a page on the Fedora Wiki entitled "No Jackassery". We can then allow people to fill it up with all the things that annoy them. And when someone on the list is being a bit too troll-ish, someone can respond by linking to the "No Jackassery" page. I'm only partly kidding. Maybe I'm not kidding at all. Humor is an underrated mechanism for dealing with nonsense like this. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From mmcgrath at redhat.com Wed Mar 21 14:13:29 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 21 Mar 2007 09:13:29 -0500 Subject: Lessons Learned In-Reply-To: References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <1174433175.2977.51.camel@vader.jdub.homelinux.org> Message-ID: <46013D89.3000409@redhat.com> Greg Dekoenigsberg wrote: > On Tue, 20 Mar 2007, Josh Boyer wrote: > >> And to be honest, I feel it puts the people that are paid to work on >> Fedora in an unfair position. They are tasked with getting things done >> in Fedora _and_ making sure the community is involved. And at times >> involving the community slows things down simply because the volunteers >> aren't available during the day. So now you have the interesting >> situation where the paid Doers can literally accomplish more than the >> rest of the group and therefore in a meritocracy they have an advantage >> of being more valuable. > > Sometimes it works out that way -- but a lot of times it doesn't. > > Sometimes the paid Doers have to accomplish things that are Boring But > Must Be Done -- and the great advantage of unpaid Doers is that they > can frequently focus on the interesting/innovative work, because a > manager isn't breathing down their neck. That is true, though I think I lost a lot of street cred when I got hired. Even those in the know I think don't totally trust RH's actions but I'm not quite sure why. -Mike From skvidal at linux.duke.edu Wed Mar 21 14:23:54 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 21 Mar 2007 10:23:54 -0400 Subject: Lessons Learned In-Reply-To: <46013D89.3000409@redhat.com> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <1174433175.2977.51.camel@vader.jdub.homelinux.org> <46013D89.3000409@redhat.com> Message-ID: <1174487034.25818.143.camel@cutter> On Wed, 2007-03-21 at 09:13 -0500, Mike McGrath wrote: > Greg Dekoenigsberg wrote: > > On Tue, 20 Mar 2007, Josh Boyer wrote: > > > >> And to be honest, I feel it puts the people that are paid to work on > >> Fedora in an unfair position. They are tasked with getting things done > >> in Fedora _and_ making sure the community is involved. And at times > >> involving the community slows things down simply because the volunteers > >> aren't available during the day. So now you have the interesting > >> situation where the paid Doers can literally accomplish more than the > >> rest of the group and therefore in a meritocracy they have an advantage > >> of being more valuable. > > > > Sometimes it works out that way -- but a lot of times it doesn't. > > > > Sometimes the paid Doers have to accomplish things that are Boring But > > Must Be Done -- and the great advantage of unpaid Doers is that they > > can frequently focus on the interesting/innovative work, because a > > manager isn't breathing down their neck. > That is true, though I think I lost a lot of street cred when I got > hired. Even those in the know I think don't totally trust RH's actions > but I'm not quite sure why. > I dunno if I buy that. If you lost cred with someone then they're being ridiculous anyway. The only reason not to trust RH's actions is b/c of the number of actors. What I mean is that if the question was phrased: Do you totally trust Max and Greg to do the right thing. I don't see any issue saying yes. If the question is phrased: Do you totally trust all of the various managers and execs at red hat to do the right thing. I have a hard time saying yes. If only b/c I don't know what all of them are doing and/or how it will impact fedora. -sv From mspevack at redhat.com Wed Mar 21 15:16:33 2007 From: mspevack at redhat.com (Max Spevack) Date: Wed, 21 Mar 2007 11:16:33 -0400 (EDT) Subject: Fedora code of conduct In-Reply-To: <46009427.4000908@redhat.com> References: <4600871B.8090908@fedoraproject.org> <1174441465.2977.55.camel@vader.jdub.homelinux.org> <460092A0.6090503@fedoraproject.org> <46009427.4000908@redhat.com> Message-ID: On Tue, 20 Mar 2007, Mike McGrath wrote: > A code of conduct shows a lack of respect for the community' autonomy. > I think it ain't broke, lets not fix it. We've got far better things > that need documenting. I agree with the general sentiment of Mike and the others who said "not right now". And I would add that hopefully never. I think it's a bit patronizing. This isn't summer camp. We don't need to write down the school rules before we start playing. People should know what acceptable behavior is and isn't by the time they start contributing to Fedora. --Max From davej at redhat.com Wed Mar 21 16:15:21 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 21 Mar 2007 12:15:21 -0400 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <4600D9F1.70707@leemhuis.info> References: <1174421739.4264.5.camel@localhost.localdomain> <20070321013615.GA22917@redhat.com> <1174441678.25818.91.camel@cutter> <4600D9F1.70707@leemhuis.info> Message-ID: <20070321161521.GD13218@redhat.com> On Wed, Mar 21, 2007 at 08:08:33AM +0100, Thorsten Leemhuis wrote: > On 21.03.2007 07:47, Alexandre Oliva wrote: > > > What if Fedora were to split the non-Free firmware into a separate > > repository and separate bootable media [...] > > My take: split firmware files into separate packages (the kernel > includes a lot currently IIRC) as a middle-term goal to make a > "firmware-less Fedora spin" easily possible. Convince upstream kernel.org to do it, and we'll follow. We have far more important things to be working on with our limited resources. rewriting those drivers to use firmware loaders isn't as trivial as it sounds. Dave -- http://www.codemonkey.org.uk From smooge at gmail.com Wed Mar 21 16:20:53 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 21 Mar 2007 10:20:53 -0600 Subject: Lessons Learned In-Reply-To: <1174451530.4531.183.camel@mccallum.corsepiu.local> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <1174414413.4531.133.camel@mccallum.corsepiu.local> <80d7e4090703201123n4dbb65amd12fd0555cfecab2@mail.gmail.com> <1174451530.4531.183.camel@mccallum.corsepiu.local> Message-ID: <80d7e4090703210920o796729f6icf721289ffc4ca8b@mail.gmail.com> On 3/20/07, Ralf Corsepius wrote: > On Tue, 2007-03-20 at 12:23 -0600, Stephen John Smoogen wrote: > > On 3/20/07, Ralf Corsepius wrote: > > > On Tue, 2007-03-20 at 12:04 -0400, Greg Dekoenigsberg wrote: > > > > On Tue, 20 Mar 2007, Ralf Corsepius wrote: > > > > > > > > > Instead, Fedora has a leadership system, which is widely being ignored > > > > > by the public, unless it interferes with individual contributor > > > > > interests. > > > > > > > > Isn't that basically how governments work? > > > Temporarily yes. .> > > > > > History tells, in longer terms such governments inevitably will die. In > > > democratic systems, they sooner or later will be replaced, in absolutist > > > systems these governments will sooner or later be chased or die > > > lonesome. > > > > > > > Is this the "pure anarchy is the only true freedom!" argument? > > No, this the a "government without supporters will not work" argument. > > A consequence from http://en.wikipedia.org/wiki/Social_contract > and its reflection on modern democracy > http://en.wikipedia.org/wiki/Social_Contract_%28Rousseau%29 > Ok that is a different argument.. the social contract here is: Red Hat Inc is the corporate sponsor and will have to make decisions that people will not agree with because of unknown factors. You as a private "free" citizen agree that you realize this but this does not stop you from: complaining about those decisions, asking for those decisions to be explained etc etc. You are also free to take the code that Red Hat provided and collect enough other angry citizens to start your own city-state that you can rectify the bad decision. Red Hat realizes that if it makes too many bad decisions it will fail. If they fail, they die as a corporation. This is the balancing act they have to follow. Do I think that this is an enlightened government that I would want to physically live under... no. Do I think I can live with it currently.. yes. Are there better arrangements.. most likely, but I do not see it right now. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator ... Then they came for me and there was no one left to speak out for me. From smooge at gmail.com Wed Mar 21 17:02:28 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 21 Mar 2007 11:02:28 -0600 Subject: Lessons Learned In-Reply-To: <1174342855.3183.247.camel@localhost.localdomain> References: <45FED71D.3010801@redhat.com> <2cb10c440703191215y45df38f4y56ae7ced3c7e7158@mail.gmail.com> <1174342855.3183.247.camel@localhost.localdomain> Message-ID: <80d7e4090703211002r30d0c877kab0a0f6af663c2cf@mail.gmail.com> On 3/19/07, Jonathan Blandford wrote: > On Mon, 2007-03-19 at 15:36 -0400, Max Spevack wrote: > > On Mon, 19 Mar 2007, Luis Villa wrote: > > > > > The repeated slippage of release dates, and recent discussions about > > > 'must have' features for the next release, make me suspect that Fedora > > > has no answers to the question, or at least none that are any better > > > than Debian's. Fedora may not value democracy over the product, but it > > > doesn't seem to have replaced democracy with anything that is decisively > > > better for the product. > > > > My take on slipping release dates. We *always* slip. But then again, > > almost all software projects do. > > > > This is because we start out by saying we want to try to do the release > > every 6 months. And that can guarantee that it happens in 7 or 8, because > > the physical act of slipping the release causes some level of shame and > > urgency. > > > > If we just said at the beginning 7 months, then I think we'd *still* end > > up slipping, and it would really be 8 or 9 months. > > Saying that we always slip seems to be a self fulfilling prophesy for > Fedora. > I think that this is correct. It is probably the one thing that I know as true from the days of 4.2 and way before. You set the schedule, and then you silently add the extra 2-3 weeks that you know you will need because thats the way its always been. When I first got there the developers were working hard on this or that.. but the word was 'well we are just going to slip a bit.'. It is always something.. glibc needs a tweak, wait a week and we will ahve an X update, we almost made the KDE release date... etc etc. ..... > If we really wanted to do time-base releases, the MustHaves page would > just say: > > "Is it April 26th yet?" > ... I feel an extremely strong feeling of dejavu here. > and we'd work backwards from there. Barring doing something that > radical (which GNOME does, to somewhat mixed results), I bet we always > slip a couple months, every release. > > Thanks, > -Jonathan > > _______________________________________________ > 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 kwade at redhat.com Wed Mar 21 17:23:50 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 21 Mar 2007 10:23:50 -0700 Subject: CLA circling to a solution In-Reply-To: <1173740314.3935.445.camel@erato.phig.org> References: <1173740314.3935.445.camel@erato.phig.org> Message-ID: <1174497830.18755.360.camel@erato.phig.org> On Mon, 2007-03-12 at 14:58 -0800, Karsten Wade wrote: > A task I took from FUDCon was to write up a human-speak CLA, as well as > figure out the level of hoops people need to go through to contribute at > various levels. This is all covered. Results are: * Plain-English CLA is nixed on simple grounds -- basically, Fedora is not your lawyer, and interpreting a legal document is providing legal advice. * CLA hierarchies are cleared for usage. Wherever I post the policy, it comes down to this: A. Content (code, etc.) that goes into an RPM package must be covered by a GPG-signed CLA. B. Content that is for collaboration (wiki) must be covered by the CLA, but it can be a click-through agreement. So, I can take content on the Wiki that is click-through covered (and under the OPL therefore), move it to e.g. the release notes and put that in CVS (with my GPG-signed cla_done permissions.) This is an analogue to taking patches via bugzilla and mailing lists. Next steps are: 1. Enable click-through for new accounts 2. Populate that click-through with the CLA 3. Update the WikiLicense to reflect CLA + OPL 4. Remove EditGroup ACL site-wide so people can complete registration 100% self-service We'll let you know when that is done. At that point, I think an announcement is in order. - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Wed Mar 21 17:56:22 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 21 Mar 2007 10:56:22 -0700 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <1174421739.4264.5.camel@localhost.localdomain> References: <1174421739.4264.5.camel@localhost.localdomain> Message-ID: <1174499782.18755.364.camel@erato.phig.org> On Tue, 2007-03-20 at 15:15 -0500, Tom "spot" Callaway wrote: > I don't think there is any harm in Fedora recommending that consumers > purchase wireless products that don't require firmware. I'm not entirely > sure the best way to go about this, though. > > Thoughts? How about an entry in the release notes? http://fedoraproject.org/wiki/Docs/Beats/HardwareOverview Feel free to fix it to make it clearer and stronger. - 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 mspevack at redhat.com Wed Mar 21 20:12:11 2007 From: mspevack at redhat.com (Max Spevack) Date: Wed, 21 Mar 2007 16:12:11 -0400 (EDT) Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <20070321013615.GA22917@redhat.com> References: <1174421739.4264.5.camel@localhost.localdomain> <20070321013615.GA22917@redhat.com> Message-ID: On Tue, 20 Mar 2007, Dave Jones wrote: > This problem is much bigger than just wireless too. If we decide to go > the crazy debian route of not shipping firmware, we can forget about a > ton of storage hardware, a bunch of ethernet drivers, x86 microcode > updates, some sound cards and probably a bunch of USB gadgets. That's not even something we're talking about. Fedora's "freedom position" has been pretty consistent for a while now. There will always be people who don't like it, and so we'll have one of these threads from time to time, but that doesn't mean we're making any major new decisions. Certainly, Dave, no change like that would ever happen without you being part of the conversation. --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 aoliva at redhat.com Wed Mar 21 20:17:43 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 21 Mar 2007 17:17:43 -0300 Subject: [Fwd: Re: Fedora free software?] In-Reply-To: <4600D9F1.70707@leemhuis.info> (Thorsten Leemhuis's message of "Wed\, 21 Mar 2007 08\:08\:33 +0100") References: <1174421739.4264.5.camel@localhost.localdomain> <20070321013615.GA22917@redhat.com> <1174441678.25818.91.camel@cutter> <4600D9F1.70707@leemhuis.info> Message-ID: On Mar 21, 2007, Thorsten Leemhuis wrote: > On 21.03.2007 07:47, Alexandre Oliva wrote: >> What if Fedora were to split the non-Free firmware into a separate >> repository and separate bootable media [...] > My take: split firmware files into separate packages (the kernel > includes a lot currently IIRC) as a middle-term goal to make a > "firmware-less Fedora spin" easily possible. I was not talking about the firmware embedded in the kernel when I made the suggestion, I was talking about add-on firmware. That said, your suggestion is a good one in as much as it's doable. Unfortunately, in-kernel firmware is a far more difficult issue because the non-free firmware is not only in easily-separatable blobs that could be shipped separately, but rather embedded and disguised as source code. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From wtogami at redhat.com Wed Mar 21 22:01:38 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 21 Mar 2007 18:01:38 -0400 Subject: State a "Freedom Position"? In-Reply-To: References: <1174421739.4264.5.camel@localhost.localdomain> <20070321013615.GA22917@redhat.com> Message-ID: <4601AB42.7050201@redhat.com> Max Spevack wrote: > On Tue, 20 Mar 2007, Dave Jones wrote: > >> This problem is much bigger than just wireless too. If we decide to go >> the crazy debian route of not shipping firmware, we can forget about a >> ton of storage hardware, a bunch of ethernet drivers, x86 microcode >> updates, some sound cards and probably a bunch of USB gadgets. > > That's not even something we're talking about. > > Fedora's "freedom position" has been pretty consistent for a while now. > There will always be people who don't like it, and so we'll have one of > these threads from time to time, but that doesn't mean we're making any > major new decisions. > Max, We should state unequivocally what this freedom position is, and ordain it as "official". A freedom position would be based on elements something like: - Binary-only drivers are completely unacceptable, because they violate the GPL (and thus copyrights), and are ethically wrong. - Rarer situations like the ipw3945 driver with a GPL abusing interface for a binary-only daemon, is unacceptable. - Patented software without a perpetual and irrevocable license to FOSS is unacceptable. - Only reproducible FOSS licensed software is acceptable. - Exception: Binary firmware (narrowly defined, redistributable, not in violation of any licenses) is acceptable because it is essentially part of the hardware. This effectively puts Fedora furthest toward "freedom", even beyond Debian. Only we explicitly differ with the FSF's position on (narrowly defined specific) binary firmware. Assertions: 1) Redistributable binary-only firmware that operates only within the hardware (perhaps more narrowly defined than this, but the intent is understood here) does not violate any FOSS license or copyrights. 2) Furthermore, because it is part of the hardware's operation itself, there is no ethical problem. This seems to be the consensus of past discussions within Fedora. Perhaps I am just unaware, but are there logical arguments against these two assertions? Warren Togami wtogami at redhat.com From sundaram at fedoraproject.org Thu Mar 22 02:04:10 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 22 Mar 2007 07:34:10 +0530 Subject: Lessons Learned In-Reply-To: <20070321131409.73efe136.bugs.michael@gmx.net> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> <4601189C.3000004@leemhuis.info> <20070321131409.73efe136.bugs.michael@gmx.net> Message-ID: <4601E41A.5090101@fedoraproject.org> Michael Schwendt wrote: > On Wed, 21 Mar 2007 12:35:56 +0100, Thorsten Leemhuis wrote: > >>> FESCo fails to define its field of activity. The moved Wiki pages for the >>> new FESCo don't add any description, >> The thing important for me is: it seems the pages were simply moved, >> without asking the public or FESCo for opinions first. Yes, the topic >> was discussed once in the public some weeks earlier (without a real >> outcome), but now it was simply done afaics, without even discussing >> FESCo first. Was such a hectic really necessary? > > 1) Having to search for the old Fedora Extras main page was "Very Funny"(TM). > Apparently it's now called Fedora Packaging on the index. It's getting > confusing. > > 2) The rename was incomplete in that everybody who is subscribed to the > old page names, now has to update the Wiki preferences. E.g. presently > I'm still subscribed to pages, which don't exist anymore because they have > been moved somewhere. Every single page renamed has already had redirects setup. So you dont have to search for anything. I already send a announcement to fedora-maintainers list about this describing what has been done explicitly. Rahul From sundaram at fedoraproject.org Thu Mar 22 02:12:41 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 22 Mar 2007 07:42:41 +0530 Subject: Lessons Learned In-Reply-To: <4601189C.3000004@leemhuis.info> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> <4601189C.3000004@leemhuis.info> Message-ID: <4601E619.7000604@fedoraproject.org> Thorsten Leemhuis wrote: > > The thing important for me is: it seems the pages were simply moved, > without asking the public or FESCo for opinions first. Yes, the topic > was discussed once in the public some weeks earlier (without a real > outcome), but now it was simply done afaics, without even discussing > FESCo first. Was such a hectic really necessary? > > Side note: I think the moving in general was a good idea, but how it was > done without asking or announcing it beforehand was simply bad bad bad. > I think even a board member should be a bit more careful and ask the > proper committee (in this case FESCo) and the public for opinions before > doing such a major task. > > Sure, simply doing stuff is easier often. But people that operate in > "heads down, I don't care what other people think and do my way without > asking the public or committees that are responsible for it because that > is painful work" is as far as I can see not the way to get a community > interested in Fedora. I asked several times in fedora-devel list and fedora-maintainers list without any consensus. I setup redirects for every single renamed and I have announced it to fedora-maintainers list after it was done. The move is not complete yet as indicated in the announcement so categorization of the pages has not changed. I didn't do it as a board member but as someone who has been involved in the website content management. If I have to jump through hoops talking to committee's before I do things like these I rather not be involved. If anyone within FESCo has a problem with a simple page move feel free to let me know. Rahul From sundaram at fedoraproject.org Thu Mar 22 02:14:56 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 22 Mar 2007 07:44:56 +0530 Subject: CLA circling to a solution In-Reply-To: <369bce3b0703121603x7bfa73b1h1a80b19a3658dfd1@mail.gmail.com> References: <1173740314.3935.445.camel@erato.phig.org> <369bce3b0703121603x7bfa73b1h1a80b19a3658dfd1@mail.gmail.com> Message-ID: <4601E6A0.8020803@fedoraproject.org> Thomas Chung wrote: > On 3/12/07, Karsten Wade wrote: >> .. >> PS - watching the video from the FUDCon session "Lowering the >> Barriers ..." helped me to be sure all of our thoughts were caught here. >> Kudos to the value of video archives. > > Speaking of FUDCon videos, are we ever going to upload them on YouTube > or GoogleVideo? Can you do that? Rahul From blizzard at redhat.com Thu Mar 22 04:05:49 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 22 Mar 2007 00:05:49 -0400 Subject: Lessons Learned In-Reply-To: <46013D89.3000409@redhat.com> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <1174433175.2977.51.camel@vader.jdub.homelinux.org> <46013D89.3000409@redhat.com> Message-ID: <1174536349.2006.15.camel@localhost.localdomain> On Wed, 2007-03-21 at 09:13 -0500, Mike McGrath wrote: > > Sometimes the paid Doers have to accomplish things that are Boring But > > Must Be Done -- and the great advantage of unpaid Doers is that they > > can frequently focus on the interesting/innovative work, because a > > manager isn't breathing down their neck. > That is true, though I think I lost a lot of street cred when I got > hired. Even those in the know I think don't totally trust RH's actions > but I'm not quite sure why. http://tieguy.org/blog/2007/01/21/red-hats-mindshare-and-my-summer-internship/ Note about the conflict of interest. And on that note, Miguel made this really interesting point once about the Mono project. He said that Novell paid people to work on all the really boring stuff because then the community could be build around building all the interesting stuff. Not sure if he was kidding or not, but it was an interesting idea. But in Mike's case I think it was "Mike's doing great work. I'll bet if we hire him he will do even more great work because then he doesn't have any distractions." I think it's as simple as that. A chance to do more of what you were doing before. --Chris From blizzard at redhat.com Thu Mar 22 04:06:38 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 22 Mar 2007 00:06:38 -0400 Subject: Lessons Learned In-Reply-To: <1174487034.25818.143.camel@cutter> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <1174433175.2977.51.camel@vader.jdub.homelinux.org> <46013D89.3000409@redhat.com> <1174487034.25818.143.camel@cutter> Message-ID: <1174536398.2006.17.camel@localhost.localdomain> On Wed, 2007-03-21 at 10:23 -0400, seth vidal wrote: > The only reason not to trust RH's actions is b/c of the number of > actors. What I mean is that if the question was phrased: Do you totally > trust Max and Greg to do the right thing. I don't see any issue saying > yes. If the question is phrased: Do you totally trust all of the various > managers and execs at red hat to do the right thing. I have a hard time > saying yes. If only b/c I don't know what all of them are doing and/or > how it will impact fedora. > That's why Max + Greg lead the project - and the execs don't. --Chris From fedora at leemhuis.info Thu Mar 22 06:04:28 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 22 Mar 2007 07:04:28 +0100 Subject: Lessons Learned In-Reply-To: <4601E619.7000604@fedoraproject.org> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> <4601189C.3000004@leemhuis.info> <4601E619.7000604@fedoraproject.org> Message-ID: <46021C6C.20303@leemhuis.info> On 22.03.2007 03:12, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: > > I asked several times in fedora-devel list and fedora-maintainers list > without any consensus. That's why FESCo and similar committee's exists, to find the consensus. In this case I'd even said that could have been found in less then ten minutes in a meeting. > I setup redirects for every single renamed and I > have announced it to fedora-maintainers list after it was done. The > move is not complete yet as indicated in the announcement so > categorization of the pages has not changed. I didn't do it as a board > member but as someone who has been involved in the website content > management. > > If I have to jump through hoops talking to committee's before I do > things like these I rather not be involved. Okay, so that means that everyone/everyone involved in the website content can go to the wiki now and move some things around where they would like them to belong? Interesting approach. To you really want that? Sure, for small pages that's okay, but they are also easily moved back or somewhere else if needed. But for a whole category of pages like Extras/ that's IMHO a strict no go without asking the Committee that takes care of those Pages. > [...] CU thl P.S.: Sorry Rahul, but this kind of behavior is in my humble opinion exactly what you should *not* do when you are a Red Hat employee. We afaics want to get the community more involved in Fedora; but from the outside this and similar stuff looks like "well, I tried to ask the community, but they didn't find a consensus so I simply made what I think is right without asking anyone again". That is totally the wrong way to get the community involved. If you want to let the community do work for the project you have to give them the feeling they are involved in important decisions. From rc040203 at freenet.de Thu Mar 22 06:18:10 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 22 Mar 2007 07:18:10 +0100 Subject: Lessons Learned In-Reply-To: <80d7e4090703210920o796729f6icf721289ffc4ca8b@mail.gmail.com> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <1174414413.4531.133.camel@mccallum.corsepiu.local> <80d7e4090703201123n4dbb65amd12fd0555cfecab2@mail.gmail.com> <1174451530.4531.183.camel@mccallum.corsepiu.local> <80d7e4090703210920o796729f6icf721289ffc4ca8b@mail.gmail.com> Message-ID: <1174544291.4531.213.camel@mccallum.corsepiu.local> On Wed, 2007-03-21 at 10:20 -0600, Stephen John Smoogen wrote: > On 3/20/07, Ralf Corsepius wrote: > > On Tue, 2007-03-20 at 12:23 -0600, Stephen John Smoogen wrote: > > > Is this the "pure anarchy is the only true freedom!" argument? > > > > No, this the a "government without supporters will not work" argument. > > > > A consequence from http://en.wikipedia.org/wiki/Social_contract > > and its reflection on modern democracy > > http://en.wikipedia.org/wiki/Social_Contract_%28Rousseau%29 > > > > Ok that is a different argument.. the social contract here is: > > Red Hat Inc is the corporate sponsor and will have to make decisions > that people will not agree with because of unknown factors. > > You as a private "free" citizen agree that you realize this but this > does not stop you from: complaining about those decisions, asking for > those decisions to be explained etc etc. You are also free to take the > code that Red Hat provided and collect enough other angry citizens to > start your own city-state that you can rectify the bad decision. Right. > Red Hat realizes that if it makes too many bad decisions it will fail. > If they fail, they die as a corporation. This is the balancing act > they have to follow. > > Do I think that this is an enlightened government that I would want to > physically live under... no. Right, it's a despotic government in Rousseau's sense[1]. It will only work as long as this government finds sufficient supporters within their "people", who are willing to support them ("opportunists"). If you want to regard Fedora Leadership as "enlightened monarchy", then the natural consequence would be this monarchy's to demonstrate their "enlightedness" to find supporters. > Do I think I can live with it currently.. > yes. Well, my perspective is a bit different: I do not consider me to be living under this government, but consider me to "collaborate"/"make business" with this "foreign government". Wrt. this I regard my involvement into FPC not as "governing" but as involvement into finding "regulations/standards" (a technical, bureaucratic act). This is not any different from everyday live: You don't have to fully accept/agree to a "foreign entity" (nation, enterprise, individual). Where to draw the line with whom to collaborate is subject to individual considerations. > Are there better arrangements.. most likely, but I do not see it > right now. One approach would be to clearly separate Fedora from RH. This had been the case with fedora.us and had been the case when Fedora had an elected FESCo. Nowadays, doubts are justified. Ralf [1] http://en.wikipedia.org/wiki/Social_Contract_%28Rousseau%29 From bugs.michael at gmx.net Thu Mar 22 08:14:36 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 22 Mar 2007 09:14:36 +0100 Subject: Lessons Learned In-Reply-To: <4601E41A.5090101@fedoraproject.org> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> <4601189C.3000004@leemhuis.info> <20070321131409.73efe136.bugs.michael@gmx.net> <4601E41A.5090101@fedoraproject.org> Message-ID: <20070322091436.82eba57a.bugs.michael@gmx.net> On Thu, 22 Mar 2007 07:34:10 +0530, Rahul Sundaram wrote: > > 1) Having to search for the old Fedora Extras main page was "Very Funny"(TM). > > Apparently it's now called Fedora Packaging on the index. It's getting > > confusing. > > > > 2) The rename was incomplete in that everybody who is subscribed to the > > old page names, now has to update the Wiki preferences. E.g. presently > > I'm still subscribed to pages, which don't exist anymore because they have > > been moved somewhere. > > Every single page renamed has already had redirects setup. So you dont > have to search for anything. I already send a announcement to > fedora-maintainers list about this describing what has been done explicitly. My personal subscriptions have not been changed to point to the moved pages. Updating them is a manual process, apparently. I've missed notifications about changes to one page till the person mailed me privately to ask about progress. I'm sure this was just an oversight in the reorganisation of the Wiki structure. But it should be allowed to point out that it caused trouble for some of us, and I'm certain it is not just me who is still not subscribed to the right pages again. From sundaram at fedoraproject.org Thu Mar 22 08:27:37 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 22 Mar 2007 13:57:37 +0530 Subject: Lessons Learned In-Reply-To: <20070322091436.82eba57a.bugs.michael@gmx.net> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> <4601189C.3000004@leemhuis.info> <20070321131409.73efe136.bugs.michael@gmx.net> <4601E41A.5090101@fedoraproject.org> <20070322091436.82eba57a.bugs.michael@gmx.net> Message-ID: <46023DF9.6010703@fedoraproject.org> Michael Schwendt wrote: > On Thu, 22 Mar 2007 07:34:10 +0530, Rahul Sundaram wrote: > >>> 1) Having to search for the old Fedora Extras main page was "Very Funny"(TM). >>> Apparently it's now called Fedora Packaging on the index. It's getting >>> confusing. >>> >>> 2) The rename was incomplete in that everybody who is subscribed to the >>> old page names, now has to update the Wiki preferences. E.g. presently >>> I'm still subscribed to pages, which don't exist anymore because they have >>> been moved somewhere. >> Every single page renamed has already had redirects setup. So you dont >> have to search for anything. I already send a announcement to >> fedora-maintainers list about this describing what has been done explicitly. > > My personal subscriptions have not been changed to point to the moved > pages. Updating them is a manual process, apparently. I've missed > notifications about changes to one page till the person mailed me > privately to ask about progress. > > I'm sure this was just an oversight in the reorganisation of the Wiki > structure. But it should be allowed to point out that it caused trouble > for some of us, and I'm certain it is not just me who is still not > subscribed to the right pages again. I believe page renames dont automatically change the subscriptions too. If anyone has a easy way around that let me know. Otherwise maintainers would have to change it manually themselves. Rahul From sundaram at fedoraproject.org Thu Mar 22 08:30:38 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 22 Mar 2007 14:00:38 +0530 Subject: Lessons Learned In-Reply-To: <46021C6C.20303@leemhuis.info> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> <4601189C.3000004@leemhuis.info> <4601E619.7000604@fedoraproject.org> <46021C6C.20303@leemhuis.info> Message-ID: <46023EAE.8060706@fedoraproject.org> Thorsten Leemhuis wrote: > On 22.03.2007 03:12, Rahul Sundaram wrote: >> Thorsten Leemhuis wrote: >> >> I asked several times in fedora-devel list and fedora-maintainers list >> without any consensus. > > That's why FESCo and similar committee's exists, to find the consensus. > In this case I'd even said that could have been found in less then ten > minutes in a meeting. If we have to go to a committee before getting consensus on a simple page rename we have failed in a pretty big way. > Okay, so that means that everyone/everyone involved in the website > content can go to the wiki now and move some things around where they > would like them to belong? Interesting approach. To you really want that? I did not just go into the website and start renaming pages all of a sudden. The discussions around reorganizing them was initiated by me months back and I have tried several times again to form consensus.So your description of what I did is pretty misleading. I dont think go to FESCo is the right answer here at all. > P.S.: Sorry Rahul, but this kind of behavior is in my humble opinion > exactly what you should *not* do when you are a Red Hat employee. We > afaics want to get the community more involved in Fedora; but from the > outside this and similar stuff looks like "well, I tried to ask the > community, but they didn't find a consensus so I simply made what I > think is right without asking anyone again". That is totally the wrong > way to get the community involved. If you want to let the community do > work for the project you have to give them the feeling they are involved > in important decisions. I am part of the community just the way you are. Artificially separating this as a Red Hat or board vs community thing is very much damaging and insulting to the work we do in our own time. If folks are bothered about the change so much the right place to discuss this would have been as a reply to my announcement to fedora-maintainers list. No one in FESCo did and now you claim that this is somehow damaging the community involved which I find unnecessarily dramatic. If you are making a personal opinion that's fine. If you are speaking for the community in general you need to be sure that more people carry the same opinion in this matter. Rahul From fedora at leemhuis.info Thu Mar 22 08:57:23 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 22 Mar 2007 09:57:23 +0100 Subject: Lessons Learned In-Reply-To: <46023EAE.8060706@fedoraproject.org> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> <4601189C.3000004@leemhuis.info> <4601E619.7000604@fedoraproject.org> <46021C6C.20303@leemhuis.info> <46023EAE.8060706@fedoraproject.org> Message-ID: <460244F3.2010202@leemhuis.info> On 22.03.2007 09:30, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: >> On 22.03.2007 03:12, Rahul Sundaram wrote: >>> Thorsten Leemhuis wrote: >>> I asked several times in fedora-devel list and fedora-maintainers list >>> without any consensus. >> That's why FESCo and similar committee's exists, to find the consensus. >> In this case I'd even said that could have been found in less then ten >> minutes in a meeting. > If we have to go to a committee before getting consensus on a simple > page rename we have failed in a pretty big way. Moving quite a lot of important pages IMHO is no "a simple page rename". >> Okay, so that means that everyone/everyone involved in the website >> content can go to the wiki now and move some things around where they >> would like them to belong? Interesting approach. To you really want that? > I did not just go into the website and start renaming pages all of a > sudden. The discussions around reorganizing them was initiated by me > months back and I have tried several times again to form consensus.So > your description of what I did is pretty misleading. Those three lines from me above were not a description of what you did. They were meant to outline the problems such a approach afaics can have . > I dont think go to > FESCo is the right answer here at all. I strongly think it would have been. >> P.S.: Sorry Rahul, but this kind of behavior is in my humble opinion >> exactly what you should *not* do when you are a Red Hat employee. We >> afaics want to get the community more involved in Fedora; but from the >> outside this and similar stuff looks like "well, I tried to ask the >> community, but they didn't find a consensus so I simply made what I >> think is right without asking anyone again". That is totally the wrong >> way to get the community involved. If you want to let the community do >> work for the project you have to give them the feeling they are involved >> in important decisions. > I am part of the community just the way you are. Artificially separating > this as a Red Hat or board vs community thing is very much damaging and > insulting to the work we do in our own time. Sure, in an ideal world it would make no difference. But it is a difference. I think as a Red Hat employee you need to be a bit more extra careful. Fedora has the fame of being Red Hat controlled, and that IMHO what many people fear. So we IMHO need to work a bit against that to show "Okay, Red Hat has control over the Fedora Board, but the Red Hat employees these days just act like any good community citizen would do and go through the committees that were set in place to give the community some control over Fedora". > If folks are bothered about > the change so much the right place to discuss this would have been as a > reply to my announcement to fedora-maintainers list. It was not that important so I choose to stay quite. Then this discussion involved in a direction where that issue was a perfect example. > No one in FESCo did > and now you claim that this is somehow damaging the community involved > which I find unnecessarily dramatic. If you are making a personal > opinion that's fine. If you are speaking for the community in general > you need to be sure that more people carry the same opinion in this matter. I was speaking for myself and the impressions I got. That why the part above starts with "in my humble opinion". CU thl /me will probably step away from this thread now, this doesn't lead to anything productive afaics... From sundaram at fedoraproject.org Thu Mar 22 09:27:00 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 22 Mar 2007 14:57:00 +0530 Subject: Lessons Learned In-Reply-To: <460244F3.2010202@leemhuis.info> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> <4601189C.3000004@leemhuis.info> <4601E619.7000604@fedoraproject.org> <46021C6C.20303@leemhuis.info> <46023EAE.8060706@fedoraproject.org> <460244F3.2010202@leemhuis.info> Message-ID: <46024BE4.8060901@fedoraproject.org> Thorsten Leemhuis wrote: > On 22.03.2007 09:30, Rahul Sundaram wrote: > > Moving quite a lot of important pages IMHO is no "a simple page rename". Maybe it wasnt but FESCo is not setup to manage web pages nor should it be. I along with others like Patrick Barnes and Thomas Chung have been doing it and I have been doing it more than anyone else by far. If anyone in FESCo has a problem with the page move let me know. > Those three lines from me above were not a description of what you did. > They were meant to outline the problems such a approach afaics can have . Since I did not just going around changing webpages all of a sudden the problems from such a approach has no bearing on what I did. >> I dont think go to >> FESCo is the right answer here at all. > > I strongly think it would have been. Since you are no longer in FESCo the right thing to do is to make sure FESCo shares that opinion and define its scope to include managing web content. I will then stay off the web pages and FESCo can be micro managing that. > Sure, in an ideal world it would make no difference. But it is a > difference. I think as a Red Hat employee you need to be a bit more > extra careful. Fedora has the fame of being Red Hat controlled, and that > IMHO what many people fear. So we IMHO need to work a bit against that > to show "Okay, Red Hat has control over the Fedora Board, but the Red > Hat employees these days just act like any good community citizen would > do and go through the committees that were set in place to give the > community some control over Fedora". I have been involved in Fedora for a long time and before I have been in Red Hat. I am not going to go down to somehow demonstrate community involvement in a artificial way just because I work for Red Hat now. IO have been doing that in ways far more meaningful than this. Red Hat hasn't controlled the Fedora Board in anyway so far and I dont think it will either. Unless FESCo wants to get involved and want me to go through them on things like wiki pages I see no point in continuing this discussion based on your opinions. Rahul From fedora at leemhuis.info Thu Mar 22 10:00:50 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 22 Mar 2007 11:00:50 +0100 Subject: Lessons Learned In-Reply-To: <46024BE4.8060901@fedoraproject.org> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> <4601189C.3000004@leemhuis.info> <4601E619.7000604@fedoraproject.org> <46021C6C.20303@leemhuis.info> <46023EAE.8060706@fedoraproject.org> <460244F3.2010202@leemhuis.info> <46024BE4.8060901@fedoraproject.org> Message-ID: <460253D2.7010209@leemhuis.info> On 22.03.2007 10:27, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: >> On 22.03.2007 09:30, Rahul Sundaram wrote: > [...] >>> I dont think go to >>> FESCo is the right answer here at all. >> I strongly think it would have been. > Since you are no longer in FESCo the right thing to do is to make sure > FESCo shares that opinion and define its scope to include managing web > content. I will then stay off the web pages and FESCo can be micro > managing that. [...] Well, I wrote a private mail to some Fedora and FESCo people members some days ago on this particular issue and received some replies. So I know that I'm not alone with opinion. But it's up to those people to speak up here -- I'm not going to forward private mails to a public list. CU thl From luis at tieguy.org Thu Mar 22 11:27:39 2007 From: luis at tieguy.org (Luis Villa) Date: Thu, 22 Mar 2007 07:27:39 -0400 Subject: Lessons Learned In-Reply-To: <1174536349.2006.15.camel@localhost.localdomain> References: <45FED71D.3010801@redhat.com> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <1174433175.2977.51.camel@vader.jdub.homelinux.org> <46013D89.3000409@redhat.com> <1174536349.2006.15.camel@localhost.localdomain> Message-ID: <2cb10c440703220427g4407fe9ala640157c43b457a8@mail.gmail.com> On 3/22/07, Christopher Blizzard wrote: > On Wed, 2007-03-21 at 09:13 -0500, Mike McGrath wrote: > > > Sometimes the paid Doers have to accomplish things that are Boring But > > > Must Be Done -- and the great advantage of unpaid Doers is that they > > > can frequently focus on the interesting/innovative work, because a > > > manager isn't breathing down their neck. > > That is true, though I think I lost a lot of street cred when I got > > hired. Even those in the know I think don't totally trust RH's actions > > but I'm not quite sure why. > > http://tieguy.org/blog/2007/01/21/red-hats-mindshare-and-my-summer-internship/ > > Note about the conflict of interest. To be fair, make sure you also read the next sentence, where I point out that even though RH is unusually good on this count, it still can't eliminate the temptation to bite the hand that feeds. I probably should update and elaborate on this post, too: http://tieguy.org/blog/2006/06/07/on-trusting-open-source-companies/ RH is better than Sun in that respect, but it still shouldn't be trusted further than their legal obligations can be thrown. Luis From Christian.Iseli at licr.org Thu Mar 22 12:31:58 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 22 Mar 2007 13:31:58 +0100 Subject: Lessons Learned In-Reply-To: <460253D2.7010209@leemhuis.info> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> <4601189C.3000004@leemhuis.info> <4601E619.7000604@fedoraproject.org> <46021C6C.20303@leemhuis.info> <46023EAE.8060706@fedoraproject.org> <460244F3.2010202@leemhuis.info> <46024BE4.8060901@fedoraproject.org> <460253D2.7010209@leemhuis.info> Message-ID: <20070322133158.07e12c57@ludwig-alpha.unil.ch> On Thu, 22 Mar 2007 11:00:50 +0100, Thorsten Leemhuis wrote: > Well, I wrote a private mail to some Fedora and FESCo people members > some days ago on this particular issue and received some replies. So I > know that I'm not alone with opinion. But it's up to those people to > speak up here -- I'm not going to forward private mails to a public list. FWIW, here is mine... On Sun, 18 Mar 2007 10:47:59 +0100, Christian Iseli wrote: > Yea, I get that feeling too at times. When I take some time to think > about it, it boils down to a lack of communications... and not much > else. I haven't yet seen any signs of harmful intentions. Some > reasons I've seen: > - intent on getting things done in time > - security and integrity worries > - maybe some unawareness of how to proceed properly > > Many of the things done can get undone if necessary. What is less easy > to undo is a feeling of carelessness for the community, especially when > coming from RH people it seems. > > My take is that we should probably kindly remind them to at least send > a shout on maintainers and/or devel right *before* starting to do bold > changes in the organizations of things (wiki, build system, vcs, etc), > or bring it up to FESCo if things seem controversial... > > No need for the orbital laser right now... To summarize my opinion: I think reorganizing the wiki was a necessary thing, and I'm glad and thankful Rahul did it. I'm aware he sent messages to the list a while ago about the need to do a reorg. My only kind request is as noted above: "send a shout on maintainers and/or devel right *before* starting to do bold changes in the organizations", where bold means it's going to affect more than a couple maintainers and/or users. Something with a clear deadline so that people know they have to react quickly if they have objections, e.g. "in a few hours I'll start moving pages around in such and such way, please yell now or keep your peace" and later "changes done", rather than "I just moved pages around in such and such way, just so you know" No need for lengthy discussions in general. Just an advance warning with a short deadline please. Thanks, Christian From fedora at leemhuis.info Thu Mar 22 12:50:32 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 22 Mar 2007 13:50:32 +0100 Subject: Lessons Learned In-Reply-To: <20070322133158.07e12c57@ludwig-alpha.unil.ch> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> <4601189C.3000004@leemhuis.info> <4601E619.7000604@fedoraproject.org> <46021C6C.20303@leemhuis.info> <46023EAE.8060706@fedoraproject.org> <460244F3.2010202@leemhuis.info> <46024BE4.8060901@fedoraproject.org> <460253D2.7010209@leemhuis.info> <20070322133158.07e12c57@ludwig-alpha.unil.ch> Message-ID: <46027B98.80104@leemhuis.info> On 22.03.2007 13:31, Christian Iseli wrote: > On Thu, 22 Mar 2007 11:00:50 +0100, Thorsten Leemhuis wrote: > > To summarize my opinion: Just to note: it is IMHO a general thing -- the wiki move was only meant as an example. > I think reorganizing the wiki was a necessary > thing, and I'm glad and thankful Rahul did it. +1 > I'm aware he sent > messages to the list a while ago about the need to do a reorg. My only > kind request is as noted above: "send a shout on maintainers and/or > devel right *before* starting to do bold changes in the organizations", > where bold means it's going to affect more than a couple maintainers > and/or users. Something with a clear deadline so that people know they > have to react quickly if they have objections, e.g. "in a few hours > I'll start moving pages around in such and such way, please yell now or > keep your peace" and later "changes done", rather than "I just moved > pages around in such and such way, just so you know" +1 > No need for lengthy discussions in general. Just an advance warning > with a short deadline please. I'd say "short" should be at least 48 or 72 hours for a task that was controversial discussed without a outcome beforehand, as "simply doing stuff" otherwise looks like "I do it my way now without bothering what the others say". That would be bad IMHO for a community project. CU thl From sundaram at fedoraproject.org Thu Mar 22 14:29:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 22 Mar 2007 19:59:55 +0530 Subject: Lessons Learned In-Reply-To: <20070322133158.07e12c57@ludwig-alpha.unil.ch> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> <4601189C.3000004@leemhuis.info> <4601E619.7000604@fedoraproject.org> <46021C6C.20303@leemhuis.info> <46023EAE.8060706@fedoraproject.org> <460244F3.2010202@leemhuis.info> <46024BE4.8060901@fedoraproject.org> <460253D2.7010209@leemhuis.info> <20070322133158.07e12c57@ludwig-alpha.unil.ch> Message-ID: <460292E3.5020401@fedoraproject.org> Christian Iseli wrote: > No need for lengthy discussions in general. Just an advance warning > with a short deadline please. > I dont have a problem with that. What I find poor practice is going through a committee / before doing routine things. Good governance on a distributed project in general is all about enabling and facilitating contributors to do what they want instead of centralizing all decisions. Notifications are easy to do in a asynchronous fashion. That's fine. Moving decisions to a committee is not. It is very much dangerous to a project to encourage that. Every time we treat processes more important than the individual contributors involved we are going to end up damaging ourselves. Rahul From mspevack at redhat.com Thu Mar 22 14:37:28 2007 From: mspevack at redhat.com (Max Spevack) Date: Thu, 22 Mar 2007 10:37:28 -0400 (EDT) Subject: Lessons Learned In-Reply-To: <1174536349.2006.15.camel@localhost.localdomain> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <1174433175.2977.51.camel@vader.jdub.homelinux.org> <46013D89.3000409@redhat.com> <1174536349.2006.15.camel@localhost.localdomain> Message-ID: On Thu, 22 Mar 2007, Christopher Blizzard wrote: > But in Mike's case I think it was "Mike's doing great work. I'll bet if > we hire him he will do even more great work because then he doesn't have > any distractions." I think it's as simple as that. A chance to do more > of what you were doing before. Yes, exactly. "Wow, person $FOO does so much great stuff, basically in their spare time and with no managerial oversight. Let's make it so this person can do that full time, and also give them a bit more guidance/help than before, and the results should be incredible." And that's what it will be everytime Red Hat fills a job with someone from the Fedora community -- and we will continue to do so a little bit at a time. -- 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 Christian.Iseli at licr.org Thu Mar 22 14:55:02 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 22 Mar 2007 15:55:02 +0100 Subject: Lessons Learned In-Reply-To: <460292E3.5020401@fedoraproject.org> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> <4601189C.3000004@leemhuis.info> <4601E619.7000604@fedoraproject.org> <46021C6C.20303@leemhuis.info> <46023EAE.8060706@fedoraproject.org> <460244F3.2010202@leemhuis.info> <46024BE4.8060901@fedoraproject.org> <460253D2.7010209@leemhuis.info> <20070322133158.07e12c57@ludwig-alpha.unil.ch> <460292E3.5020401@fedoraproject.org> Message-ID: <20070322155502.1344a8a6@ludwig-alpha.unil.ch> On Thu, 22 Mar 2007 19:59:55 +0530, Rahul Sundaram wrote: > I dont have a problem with that. Then I think we are in violent agreement :-) > What I find poor practice is going > through a committee / before doing routine > things. Good governance on a distributed project in general is all > about enabling and facilitating contributors to do what they want > instead of centralizing all decisions. yes > Notifications are easy to do in a > asynchronous fashion. That's fine. exactly > Moving decisions to a committee is > not. It is very much dangerous to a project to encourage that. I'd say it depends on the kind of decisions that need to be taken... > Every > time we treat processes more important than the individual contributors > involved we are going to end up damaging ourselves. I'd tend to agree to that too. Cheers, C From mspevack at redhat.com Thu Mar 22 14:58:58 2007 From: mspevack at redhat.com (Max Spevack) Date: Thu, 22 Mar 2007 10:58:58 -0400 (EDT) Subject: Lessons Learned In-Reply-To: <460292E3.5020401@fedoraproject.org> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> <4601189C.3000004@leemhuis.info> <4601E619.7000604@fedoraproject.org> <46021C6C.20303@leemhuis.info> <46023EAE.8060706@fedoraproject.org> <460244F3.2010202@leemhuis.info> <46024BE4.8060901@fedoraproject.org> <460253D2.7010209@leemhuis.info> <20070322133158.07e12c57@ludwig-alpha.unil.ch> <460292E3.5020401@fedoraproject.org> Message-ID: On Thu, 22 Mar 2007, Rahul Sundaram wrote: >> No need for lengthy discussions in general. Just an advance warning >> with a short deadline please. > > I dont have a problem with that. What I find poor practice is going > through a committee / before doing routine > things. This thread is going in circles. I'm going to speak about the general case here, not this specific wiki page topic. Like it or not, everyone, these are the facts of the game: (1) Red Hat employees are also members of the Fedora community. (2) With the Core/Extras merge, we are taking a big step (at least in the source code area) in making sure that everyone, regardless of where they work, is held to the same level of expectation in terms of how they get access. Most Red Hat engineers are fine with this. Some are complaining and don't think they should have to get Fedora accounts, etc. I have no sympathy for that second group. Getting a Fedora account should be a requirement of every new engineering hire. Every new hire period, actually, but I'll start with eng. (3) Separate from (2) -- an action, seemingly innocuous, can be interpreted differently if it is taken by a Red Hat employee versus a community member. I have no comment on whether or not this is "fair" -- it's the reality. Red Hat employees need to force themselves to go the extra step in communication back outside of the Red Hat walls and to the Fedora community, even if they think no one is reading it, and even if it seems like "too much" or more than would be required if the same action was being taken by a non-RH person. It builds trust and confidence. And anyone who works for Red Hat on Fedora needs to understand that every day, their actions need to continue to build trust with the rest of the community. The larger the action, the more this is necessary. So yes, there is a higher standard. And by being @redhat.com and working on Fedora, you agree to be held to it. I'm not saying I'm perfect about it -- I'm not. But that doesn't stop me from standing up on my soap box a bit. ;-) -- 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 Thu Mar 22 15:25:10 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 22 Mar 2007 16:25:10 +0100 Subject: Lessons Learned In-Reply-To: <20070322155502.1344a8a6@ludwig-alpha.unil.ch> References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> <4601189C.3000004@leemhuis.info> <4601E619.7000604@fedoraproject.org> <46021C6C.20303@leemhuis.info> <46023EAE.8060706@fedoraproject.org> <460244F3.2010202@leemhuis.info> <46024BE4.8060901@fedoraproject.org> <460253D2.7010209@leemhuis.info> <20070322133158.07e12c57@ludwig-alpha.unil.ch> <460292E3.5020401@fedoraproject.org> <20070322155502.1344a8a6@ludwig-alpha.unil.ch> Message-ID: <46029FD6.9090600@leemhuis.info> Christian Iseli schrieb: > On Thu, 22 Mar 2007 19:59:55 +0530, Rahul Sundaram wrote: >> I dont have a problem with that. > Then I think we are in violent agreement :-) >> What I find poor practice is going >> through a committee / before doing routine >> things. Good governance on a distributed project in general is all >> about enabling and facilitating contributors to do what they want >> instead of centralizing all decisions. > yes >> Notifications are easy to do in a >> asynchronous fashion. That's fine. > exactly >> Moving decisions to a committee is >> not. It is very much dangerous to a project to encourage that. > I'd say it depends on the kind of decisions that need to be taken... >> Every >> time we treat processes more important than the individual contributors >> involved we are going to end up damaging ourselves. > I'd tend to agree to that too. +1 from me, too -- the only reasons I mentioned that this should have been brought to FESCo was: If the page moving would have been announced probably beforehand on the list then the chances would have been high afaics that once again no consensus would have been found there. And then it's FESCo's job to find the final solution. Cu thl From fedora at leemhuis.info Thu Mar 22 15:27:40 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 22 Mar 2007 16:27:40 +0100 Subject: Lessons Learned In-Reply-To: References: <45FED71D.3010801@redhat.com> <1174330811.16159.19.camel@localhost.localdomain> <1174363629.4531.13.camel@mccallum.corsepiu.local> <1174387732.2977.30.camel@vader.jdub.homelinux.org> <1174406634.4531.77.camel@mccallum.corsepiu.local> <2cb10c440703200956g73fedd66sad0528c3d6deeeb1@mail.gmail.com> <1174430081.4010.23.camel@localhost.localdomain> <4600CEA6.3040200@leemhuis.info> <20070321120848.4067496e.bugs.michael@gmx.net> <4601189C.3000004@leemhuis.info> <4601E619.7000604@fedoraproject.org> <46021C6C.20303@leemhuis.info> <46023EAE.8060706@fedoraproject.org> <460244F3.2010202@leemhuis.info> <46024BE4.8060901@fedoraproject.org> <460253D2.7010209@leemhuis.info> <20070322133158.07e12c57@ludwig-alpha.unil.ch> <460292E3.5020401@fedoraproject.org> Message-ID: <4602A06C.2080009@leemhuis.info> Max Spevack schrieb: > [...] > (3) Separate from (2) -- an action, seemingly innocuous, can be > interpreted differently if it is taken by a Red Hat employee versus a > community member. I have no comment on whether or not this is "fair" -- > it's the reality. Red Hat employees need to force themselves to go the > extra step in communication back outside of the Red Hat walls and to the > Fedora community, even if they think no one is reading it, and even if it > seems like "too much" or more than would be required if the same action > was being taken by a non-RH person. It builds trust and confidence. And > anyone who works for Red Hat on Fedora needs to understand that every day, > their actions need to continue to build trust with the rest of the > community. The larger the action, the more this is necessary. Thanks Max, especially for the quoted para! Cu thl From mspevack at redhat.com Thu Mar 22 16:40:16 2007 From: mspevack at redhat.com (Max Spevack) Date: Thu, 22 Mar 2007 12:40:16 -0400 (EDT) Subject: mspevack outage Message-ID: I'm traveling to see some family from Thursday afternoon until Sunday night, EDT. Unclear how much internet time there will be, but probably not too much. --Max From mmcgrath at redhat.com Sat Mar 24 15:16:16 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 24 Mar 2007 10:16:16 -0500 Subject: GPL and storage requirements Message-ID: <460540C0.9060108@redhat.com> Matt Domsch recently posted this to the Fedora Infrastructure List: Everything (Core + Extras, FC 1 through 6, 7test[12], development, updates, repodata): 492GB FC1: 21.5GB FC2: 35.5GB FC3: 33.1GB FC4: 52.4GB FC5: 69.6GB FC6: 77.5GB development: 50.8GB FC+E6/i386: 22.6GB FC+E6/ppc: 23.5GB FC+E6/x86_64: 24.4GB FC+E6/source: 5.1GB FC6test2: 26.8GB so we're already expecting mirrors to carry ~25GB per arch per release or thereabouts. If we continue with 3 arches, 2 releases per year, that's at least 150GB per year growth. If we add arches, Unity respins, more CD/DVD objects, and the like, it'll grow faster. ============================= My question is, who knows the finer details of what the GPL requires us to keep? -Mike From luis at tieguy.org Sat Mar 24 16:32:03 2007 From: luis at tieguy.org (Luis Villa) Date: Sat, 24 Mar 2007 12:32:03 -0400 Subject: GPL and storage requirements In-Reply-To: <460540C0.9060108@redhat.com> References: <460540C0.9060108@redhat.com> Message-ID: <2cb10c440703240932v1df43a01y49db319cb2a2efb8@mail.gmail.com> On 3/24/07, Mike McGrath wrote: > My question is, who knows the finer details of what the GPL requires us > to keep? My quickie analysis follows. This is not legal advice, IANAL[1], and I'm certainly not an expert on the GPL. To top it off, the GPL is unfortunately vague on this point. But I think the analysis is likely fundamentally sound. I believe non-commercial mirrors are not required to keep source. They need only "accompany [the Program] with the information [they] received as to the offer to distribute corresponding source code." (Sec. 3(c)). To allow mirrors to take advantage of Sec. 3(c), Fedora would need to provide to the mirrors a 'written offer ... to give any third party ... a complete machine-readable copy of the corresponding source code.' (Sec. 3(b)) This offer would need to be good for three years from the date of distribution- presumably from the date of the last, rather than the first, distribution, though the language is vague on that point. As to what constitutes a 'written' offer... I believe that an email/web page would suffice to fulfill the spirit of the requirement. The text could read something like 'In keeping with the requirements of the GPL v2 Sec. 3(b), the Fedora Project offers a copy of the corresponding source code to any third party who downloads these binaries. This corresponding source code is available from the master source server at __________.' You'd give this text to the mirrors to put in any directories with binaries in them, and perhaps (to be safe) put it in a text file on the top level of every ISO as well. The more places you put the offer, the better off you likely are ;) *****Note that the term 'written' may have magical/mystical legal meanings in a license context. I strongly recommend asking a real lawyer about that.***** So, to summarize what I think to be the correct situation for minimum storage requirements in keeping with GPL v2: (1) the master server hosted by the party which created the new binaries from the modified source (i.e., Fedora) must publicly host a 'written' offer to freely distribute source code to anyone who asks, good for three years after the date of the *last* distribution of the binaries. (2) the master server must maintain a copy of that same source code for three years after the date of the last distribution of the binaries. (3) assuming that mirrors are non-commercial and do not modify the binaries, mirrors don't need to keep source, as long as they prominently host a copy of the official 'written' offer mentioned in (1). Two further notes: (1) Are you sure GPL is the only license with applicable source code redistribution requirements? GPL may allow mirrors to not mirror source, but other licenses may not be so forgiving. I have no idea what breadth of licenses are in Fedora. (2) Assuming the language in the latest draft stays roughly the same, these instructions should be valid for GPL v3 as well. The requirements there are slightly different, but overlap enough that they should not pose a problem. (As a bonus, v3 clarifies 'written' in the network mirror context to mean "clear directions next to the object code saying where to find the Corresponding Source." I think following that language would be a good guideline for fulfilling the v2 requirements, though again IANAL and written may have special magicolegalist[2] meanings.) HTH, sorry it is a little rambling- Luis [1] I need a blog post explaining this in more detail. [2] Yes, I just made that up. And I love it. From Axel.Thimm at ATrpms.net Sat Mar 24 16:49:35 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 24 Mar 2007 17:49:35 +0100 Subject: GPL and storage requirements In-Reply-To: <460540C0.9060108@redhat.com> References: <460540C0.9060108@redhat.com> Message-ID: <20070324164935.GA17442@neu.nirvana> On Sat, Mar 24, 2007 at 10:16:16AM -0500, Mike McGrath wrote: > Matt Domsch recently posted this to the Fedora Infrastructure List: > > Everything (Core + Extras, FC 1 through 6, 7test[12], development, > updates, repodata): 492GB > FC1: 21.5GB > FC2: 35.5GB > FC3: 33.1GB > FC4: 52.4GB > FC5: 69.6GB > FC6: 77.5GB > development: 50.8GB > > FC+E6/i386: 22.6GB > FC+E6/ppc: 23.5GB > FC+E6/x86_64: 24.4GB > FC+E6/source: 5.1GB > > FC6test2: 26.8GB > > so we're already expecting mirrors to carry ~25GB per arch per release > or thereabouts. > > If we continue with 3 arches, 2 releases per year, that's at least 150GB > per year growth. If we add arches, Unity respins, more CD/DVD objects, > and the like, it'll grow faster. > > ============================= > > My question is, who knows the finer details of what the GPL requires us > to keep? The question is what is your favourite nuke target? Whole distros including binaries and sources or sources only? In theory you can nuke the sources and place a note that you will be sending out DVD copies to whomever asks for it, but that's probably not what you want :) How about moving EOL'd (or EOL'd + DeltaT, where DeltaT is something like 0.5 or one year) distros out of downloads.... and into archives.... similar to the RHL releases? You keep the bits around indefinitely w/o heavying the mirrors. GPL and IT archeologists are happy and mirrors are happy, too. Or you trust Moore's law that is exponential mirror capacity increase compared to Fedora's linear :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aoliva at redhat.com Sun Mar 25 10:32:32 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Sun, 25 Mar 2007 07:32:32 -0300 Subject: GPL and storage requirements In-Reply-To: <2cb10c440703240932v1df43a01y49db319cb2a2efb8@mail.gmail.com> (Luis Villa's message of "Sat\, 24 Mar 2007 12\:32\:03 -0400") References: <460540C0.9060108@redhat.com> <2cb10c440703240932v1df43a01y49db319cb2a2efb8@mail.gmail.com> Message-ID: On Mar 24, 2007, "Luis Villa" wrote: > I believe non-commercial mirrors are not required to keep source. They > need only "accompany [the Program] with the information [they] > received as to the offer to distribute corresponding source code." > (Sec. 3(c)). IANAL, but Fedora distributes code under 3(a) (sources along with binaries), not 3(b), so third-parties don't get to use 3(c), they must use either 3(a) or 3(b). Using 3(a) means Fedora can blow away anything it carries any time it wants, no further requirements. Using 3(b) would mean we'd have to keep, at least internally, the corresponding sources of GPLed and LGPLed code in every binary released package, for at least 3 years after we take it out of the download site, just in case someone asks us for it. AFAIK, mirrors who carry our binaries without sources enter precisely this kind of obligation. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From luis at tieguy.org Sun Mar 25 13:00:39 2007 From: luis at tieguy.org (Luis Villa) Date: Sun, 25 Mar 2007 09:00:39 -0400 Subject: GPL and storage requirements In-Reply-To: References: <460540C0.9060108@redhat.com> <2cb10c440703240932v1df43a01y49db319cb2a2efb8@mail.gmail.com> Message-ID: <2cb10c440703250600m769343b8s3631e5f1129acfb4@mail.gmail.com> On 3/25/07, Alexandre Oliva wrote: > On Mar 24, 2007, "Luis Villa" wrote: > > > I believe non-commercial mirrors are not required to keep source. They > > need only "accompany [the Program] with the information [they] > > received as to the offer to distribute corresponding source code." > > (Sec. 3(c)). > > IANAL, I'm not either, I just go to law school, *HUGE DIFFERENCE*. To remind everyone, you should run this by a real lawyer :) > but Fedora distributes code under 3(a) (sources along with > binaries), not 3(b), so third-parties don't get to use 3(c), they must > use either 3(a) or 3(b). This is why I said later that Fedora should distribute sources under 3(b), not 3(a). (Though the two aren't mutually exclusive; it'd be more like '3(a) plus 3(b) offer.') > Using 3(a) means Fedora can blow away anything it carries any time it > wants, no further requirements. > > Using 3(b) would mean we'd have to keep, at least internally, the > corresponding sources of GPLed and LGPLed code in every binary > released package, for at least 3 years after we take it out of the > download site, just in case someone asks us for it. AFAIK, mirrors > who carry our binaries without sources enter precisely this kind of > obligation. No, that is what 3(c) is for. Only Fedora carries the long-term storage requirements in that case. (And as far as I can see, if you're still distributing FC1, Fedora has no problem with nearly indefinite storage.) Luis (glad GPL v3 clears this confusion up) From matt at domsch.com Sun Mar 25 13:11:06 2007 From: matt at domsch.com (Matt Domsch) Date: Sun, 25 Mar 2007 07:11:06 -0600 Subject: GPL and storage requirements In-Reply-To: <2cb10c440703250600m769343b8s3631e5f1129acfb4@mail.gmail.com> References: <460540C0.9060108@redhat.com> <2cb10c440703240932v1df43a01y49db319cb2a2efb8@mail.gmail.com> <2cb10c440703250600m769343b8s3631e5f1129acfb4@mail.gmail.com> Message-ID: <20070325131105.GA3388@domsch.com> On Sun, Mar 25, 2007 at 09:00:39AM -0400, Luis Villa wrote: > On 3/25/07, Alexandre Oliva wrote: > >On Mar 24, 2007, "Luis Villa" wrote: > > > >> I believe non-commercial mirrors are not required to keep source. They > >> need only "accompany [the Program] with the information [they] > >> received as to the offer to distribute corresponding source code." > >> (Sec. 3(c)). > > > >IANAL, > > I'm not either, I just go to law school, *HUGE DIFFERENCE*. To remind > everyone, you should run this by a real lawyer :) > > >but Fedora distributes code under 3(a) (sources along with > >binaries), not 3(b), so third-parties don't get to use 3(c), they must > >use either 3(a) or 3(b). > > This is why I said later that Fedora should distribute sources under > 3(b), not 3(a). (Though the two aren't mutually exclusive; it'd be > more like '3(a) plus 3(b) offer.') > > >Using 3(a) means Fedora can blow away anything it carries any time it > >wants, no further requirements. > > > >Using 3(b) would mean we'd have to keep, at least internally, the > >corresponding sources of GPLed and LGPLed code in every binary > >released package, for at least 3 years after we take it out of the > >download site, just in case someone asks us for it. AFAIK, mirrors > >who carry our binaries without sources enter precisely this kind of > >obligation. > > No, that is what 3(c) is for. Only Fedora carries the long-term > storage requirements in that case. (And as far as I can see, if you're > still distributing FC1, Fedora has no problem with nearly indefinite > storage.) That's the problem. We don't have infinite and indefinite storage, but folks have wanted to honor the GPL 3(b). If it's 3 years after the last distribution of the binaries, then we should nuke the binaries ASAP and leave the source. The SRPMS dir for FC1 is ~3GB, FC2 is ~3GB, FC3 is ~4.5GB, ... However, if mirrors keep carrying FC(early) after we've deleted it, and they're using 3(b) and passing it on to us, don't we need to carry source until the last mirror doesn't? > Luis (glad GPL v3 clears this confusion up) From luis at tieguy.org Sun Mar 25 13:31:43 2007 From: luis at tieguy.org (Luis Villa) Date: Sun, 25 Mar 2007 09:31:43 -0400 Subject: GPL and storage requirements In-Reply-To: <20070325131105.GA3388@domsch.com> References: <460540C0.9060108@redhat.com> <2cb10c440703240932v1df43a01y49db319cb2a2efb8@mail.gmail.com> <2cb10c440703250600m769343b8s3631e5f1129acfb4@mail.gmail.com> <20070325131105.GA3388@domsch.com> Message-ID: <2cb10c440703250631w10dcaaafn712c58adfac8c088@mail.gmail.com> On 3/25/07, Matt Domsch wrote: > > No, that is what 3(c) is for. Only Fedora carries the long-term > > storage requirements in that case. (And as far as I can see, if you're > > still distributing FC1, Fedora has no problem with nearly indefinite > > storage.) > > That's the problem. We don't have infinite and indefinite storage, Which 'we'? Fedora? or Fedora's mirrors? I guess I assumed the primary goal here was to reduce demands on mirrors, not on Fedora. [If disk for Fedora is really a serious problem, have you looked at Amazon S3? For something that can't be downloaded very often (like FC1 source) I'd imagine it would be fairly cheap.] > but folks have wanted to honor the GPL 3(b). If it's 3 years after > the last distribution of the binaries, then we should nuke the > binaries ASAP and leave the source. The SRPMS dir for FC1 is ~3GB, > FC2 is ~3GB, FC3 is ~4.5GB, ... However, if mirrors keep carrying > FC(early) after we've deleted it, and they're using 3(b) and passing > it on to us, don't we need to carry source until the last mirror > doesn't? My reading of Sec. 3 (IANAL, this is not a legal opinion, etc.) is that Fedora's liability ends three years after Fedora stops distributing, and that mirrors are not violating the terms if they continue to distribute binaries once you've stopped distributing source. They merely have to distribute your offer, even though it may no longer be valid. GPL v3 may actually be less clear on this particular point than v2; I'll write an email to my GPL committee about that. Luis P.S. Why are mirrors still distributing completely unsupported, security-nightmareish software like FC1? I have a feeling I've asked this before, but humor me :) From skvidal at linux.duke.edu Sun Mar 25 13:36:33 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 25 Mar 2007 09:36:33 -0400 Subject: GPL and storage requirements In-Reply-To: <2cb10c440703250631w10dcaaafn712c58adfac8c088@mail.gmail.com> References: <460540C0.9060108@redhat.com> <2cb10c440703240932v1df43a01y49db319cb2a2efb8@mail.gmail.com> <2cb10c440703250600m769343b8s3631e5f1129acfb4@mail.gmail.com> <20070325131105.GA3388@domsch.com> <2cb10c440703250631w10dcaaafn712c58adfac8c088@mail.gmail.com> Message-ID: <1174829793.30355.2.camel@cutter> On Sun, 2007-03-25 at 09:31 -0400, Luis Villa wrote: > On 3/25/07, Matt Domsch wrote: > > > No, that is what 3(c) is for. Only Fedora carries the long-term > > > storage requirements in that case. (And as far as I can see, if you're > > > still distributing FC1, Fedora has no problem with nearly indefinite > > > storage.) > > > > That's the problem. We don't have infinite and indefinite storage, > > Which 'we'? Fedora? or Fedora's mirrors? I guess I assumed the primary > goal here was to reduce demands on mirrors, not on Fedora. > > [If disk for Fedora is really a serious problem, have you looked at > Amazon S3? For something that can't be downloaded very often (like FC1 > source) I'd imagine it would be fairly cheap.] > > > but folks have wanted to honor the GPL 3(b). If it's 3 years after > > the last distribution of the binaries, then we should nuke the > > binaries ASAP and leave the source. The SRPMS dir for FC1 is ~3GB, > > FC2 is ~3GB, FC3 is ~4.5GB, ... However, if mirrors keep carrying > > FC(early) after we've deleted it, and they're using 3(b) and passing > > it on to us, don't we need to carry source until the last mirror > > doesn't? > > My reading of Sec. 3 (IANAL, this is not a legal opinion, etc.) is > that Fedora's liability ends three years after Fedora stops > distributing, and that mirrors are not violating the terms if they > continue to distribute binaries once you've stopped distributing > source. They merely have to distribute your offer, even though it may > no longer be valid. > > GPL v3 may actually be less clear on this particular point than v2; > I'll write an email to my GPL committee about that. > > Luis > > P.S. Why are mirrors still distributing completely unsupported, > security-nightmareish software like FC1? I have a feeling I've asked > this before, but humor me :) mirrors are lazy. Unless upstream deletes it then they'll leave it there. The mirrors just run something like: rsync -avH --delete-after /someplace/ dest/ If it's not deleted on the mirror master it won't be deleted for them. The only time they delete stuff is when their monitoring software tells them they are low on a disk space. -sv From mmcgrath at redhat.com Sun Mar 25 13:41:27 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 25 Mar 2007 08:41:27 -0500 Subject: GPL and storage requirements In-Reply-To: <2cb10c440703250631w10dcaaafn712c58adfac8c088@mail.gmail.com> References: <460540C0.9060108@redhat.com> <2cb10c440703240932v1df43a01y49db319cb2a2efb8@mail.gmail.com> <2cb10c440703250600m769343b8s3631e5f1129acfb4@mail.gmail.com> <20070325131105.GA3388@domsch.com> <2cb10c440703250631w10dcaaafn712c58adfac8c088@mail.gmail.com> Message-ID: <46067C07.5050405@redhat.com> Luis Villa wrote: > On 3/25/07, Matt Domsch wrote: >> > No, that is what 3(c) is for. Only Fedora carries the long-term >> > storage requirements in that case. (And as far as I can see, if you're >> > still distributing FC1, Fedora has no problem with nearly indefinite >> > storage.) >> >> That's the problem. We don't have infinite and indefinite storage, > > Which 'we'? Fedora? or Fedora's mirrors? I guess I assumed the primary > goal here was to reduce demands on mirrors, not on Fedora. Fedora, right now we've got 43G free on the primary mirror. I want to know what our options are. -Mike From matt at domsch.com Sun Mar 25 13:42:28 2007 From: matt at domsch.com (Matt Domsch) Date: Sun, 25 Mar 2007 07:42:28 -0600 Subject: GPL and storage requirements In-Reply-To: <2cb10c440703250631w10dcaaafn712c58adfac8c088@mail.gmail.com> References: <460540C0.9060108@redhat.com> <2cb10c440703240932v1df43a01y49db319cb2a2efb8@mail.gmail.com> <2cb10c440703250600m769343b8s3631e5f1129acfb4@mail.gmail.com> <20070325131105.GA3388@domsch.com> <2cb10c440703250631w10dcaaafn712c58adfac8c088@mail.gmail.com> Message-ID: <20070325134228.GB3388@domsch.com> On Sun, Mar 25, 2007 at 09:31:43AM -0400, Luis Villa wrote: > On 3/25/07, Matt Domsch wrote: > >> No, that is what 3(c) is for. Only Fedora carries the long-term > >> storage requirements in that case. (And as far as I can see, if you're > >> still distributing FC1, Fedora has no problem with nearly indefinite > >> storage.) > > > >That's the problem. We don't have infinite and indefinite storage, > > Which 'we'? Fedora? or Fedora's mirrors? I guess I assumed the primary > goal here was to reduce demands on mirrors, not on Fedora. It's both. The Fedora master storage boxes are at capacity now, and getting sufficient additional storage in each of the 3 data centers has so far been problematic. > [If disk for Fedora is really a serious problem, have you looked at > Amazon S3? For something that can't be downloaded very often (like FC1 > source) I'd imagine it would be fairly cheap.] It's crossed my mind, but I'd prefer if we could get such donated rather than paid-for given we don't know how many folks could wind up downloading it thus how much it would cost us. > >but folks have wanted to honor the GPL 3(b). If it's 3 years after > >the last distribution of the binaries, then we should nuke the > >binaries ASAP and leave the source. The SRPMS dir for FC1 is ~3GB, > >FC2 is ~3GB, FC3 is ~4.5GB, ... However, if mirrors keep carrying > >FC(early) after we've deleted it, and they're using 3(b) and passing > >it on to us, don't we need to carry source until the last mirror > >doesn't? > > My reading of Sec. 3 (IANAL, this is not a legal opinion, etc.) is > that Fedora's liability ends three years after Fedora stops > distributing, and that mirrors are not violating the terms if they > continue to distribute binaries once you've stopped distributing > source. They merely have to distribute your offer, even though it may > no longer be valid. If we (Fedora and all its public mirrors) aren't under 3(a), then we probably need to keep all SRPMS for all updates ever published too, which I'm not sure we do presently (we might, I just don't know - that may be a feature of the build system). We wouldn't have to keep them online live for the mirrors necessarily, but would have to make them available "on demand" via the written offer, which is in the docs files at the top of every CD/DVD produced for a while. I've thought, and again, IANAL, that Fedora is covered by 3(a) because we distribute source and binaries concurrently. If that isn't sufficient because mirrors exist, wow... -Matt From luis at tieguy.org Sun Mar 25 13:56:10 2007 From: luis at tieguy.org (Luis Villa) Date: Sun, 25 Mar 2007 09:56:10 -0400 Subject: GPL and storage requirements In-Reply-To: <20070325134228.GB3388@domsch.com> References: <460540C0.9060108@redhat.com> <2cb10c440703240932v1df43a01y49db319cb2a2efb8@mail.gmail.com> <2cb10c440703250600m769343b8s3631e5f1129acfb4@mail.gmail.com> <20070325131105.GA3388@domsch.com> <2cb10c440703250631w10dcaaafn712c58adfac8c088@mail.gmail.com> <20070325134228.GB3388@domsch.com> Message-ID: <2cb10c440703250656t58ade7a1p446e01967f91d188@mail.gmail.com> On 3/25/07, Matt Domsch wrote: > > My reading of Sec. 3 (IANAL, this is not a legal opinion, etc.) is > > that Fedora's liability ends three years after Fedora stops > > distributing, and that mirrors are not violating the terms if they > > continue to distribute binaries once you've stopped distributing > > source. They merely have to distribute your offer, even though it may > > no longer be valid. > > If we (Fedora and all its public mirrors) aren't under 3(a), then we > probably need to keep all SRPMS for all updates ever published too, > which I'm not sure we do presently (we might, I just don't know - that > may be a feature of the build system). We wouldn't have to keep them > online live for the mirrors necessarily, but would have to make them > available "on demand" via the written offer, which is in the docs > files at the top of every CD/DVD produced for a while. > > I've thought, and again, IANAL, that Fedora is covered by 3(a) because > we distribute source and binaries concurrently. If that isn't > sufficient because mirrors exist, wow... Don't panic! I was unclear. You and your mirrors are clearly[1] 3(a) right now. So you can stop distributing whenever you want (as long as you stop distributing both binary and source at the same time.) I was under the impression that the focus of the request was 'how do we reduce space usage on the mirrors', rather than 'how do we reduce space usage on the master'. That is why I suggested that you move to 3(a) + a 3(b) notice that source would always be available from the master server. That would reduce mirror load, but clearly not help the master at all. If the goal is to reduce load on the master server, then yeah... if you just stop distributing binaries whenever you choose to stop distributing source, you should be in the clear.[2] As far as source rpms for updates... I think you're right that switching to a reliance on 3(b) would require keeping those around. Good catch. Luis [1] subject to all the disclaimers I keep spewing! [2] The historian in me says that would be a shame, though. From mmcgrath at redhat.com Sun Mar 25 13:59:28 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 25 Mar 2007 08:59:28 -0500 Subject: GPL and storage requirements In-Reply-To: <2cb10c440703250656t58ade7a1p446e01967f91d188@mail.gmail.com> References: <460540C0.9060108@redhat.com> <2cb10c440703240932v1df43a01y49db319cb2a2efb8@mail.gmail.com> <2cb10c440703250600m769343b8s3631e5f1129acfb4@mail.gmail.com> <20070325131105.GA3388@domsch.com> <2cb10c440703250631w10dcaaafn712c58adfac8c088@mail.gmail.com> <20070325134228.GB3388@domsch.com> <2cb10c440703250656t58ade7a1p446e01967f91d188@mail.gmail.com> Message-ID: <46068040.9000504@redhat.com> Luis Villa wrote: > On 3/25/07, Matt Domsch wrote: >> > My reading of Sec. 3 (IANAL, this is not a legal opinion, etc.) is >> > that Fedora's liability ends three years after Fedora stops >> > distributing, and that mirrors are not violating the terms if they >> > continue to distribute binaries once you've stopped distributing >> > source. They merely have to distribute your offer, even though it may >> > no longer be valid. >> >> If we (Fedora and all its public mirrors) aren't under 3(a), then we >> probably need to keep all SRPMS for all updates ever published too, >> which I'm not sure we do presently (we might, I just don't know - that >> may be a feature of the build system). We wouldn't have to keep them >> online live for the mirrors necessarily, but would have to make them >> available "on demand" via the written offer, which is in the docs >> files at the top of every CD/DVD produced for a while. >> >> I've thought, and again, IANAL, that Fedora is covered by 3(a) because >> we distribute source and binaries concurrently. If that isn't >> sufficient because mirrors exist, wow... > > Don't panic! I was unclear. You and your mirrors are clearly[1] 3(a) > right now. So you can stop distributing whenever you want (as long as > you stop distributing both binary and source at the same time.) > > I was under the impression that the focus of the request was 'how do > we reduce space usage on the mirrors', rather than 'how do we reduce > space usage on the master'. That is why I suggested that you move to > 3(a) + a 3(b) notice that source would always be available from the > master server. That would reduce mirror load, but clearly not help the > master at all. > > If the goal is to reduce load on the master server, then yeah... if > you just stop distributing binaries whenever you choose to stop > distributing source, you should be in the clear.[2] > > As far as source rpms for updates... I think you're right that > switching to a reliance on 3(b) would require keeping those around. > Good catch. > > Luis > > [1] subject to all the disclaimers I keep spewing! > [2] The historian in me says that would be a shame, though. I think we'll be fine soon, the hardware just isn't there right now. -Mike From Axel.Thimm at ATrpms.net Sun Mar 25 14:03:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 25 Mar 2007 16:03:15 +0200 Subject: GPL and storage requirements In-Reply-To: <46067C07.5050405@redhat.com> References: <460540C0.9060108@redhat.com> <2cb10c440703240932v1df43a01y49db319cb2a2efb8@mail.gmail.com> <2cb10c440703250600m769343b8s3631e5f1129acfb4@mail.gmail.com> <20070325131105.GA3388@domsch.com> <2cb10c440703250631w10dcaaafn712c58adfac8c088@mail.gmail.com> <46067C07.5050405@redhat.com> Message-ID: <20070325140315.GC4287@neu.nirvana> On Sun, Mar 25, 2007 at 08:41:27AM -0500, Mike McGrath wrote: > Luis Villa wrote: > >On 3/25/07, Matt Domsch wrote: > >>> No, that is what 3(c) is for. Only Fedora carries the long-term > >>> storage requirements in that case. (And as far as I can see, if you're > >>> still distributing FC1, Fedora has no problem with nearly indefinite > >>> storage.) > >> > >>That's the problem. We don't have infinite and indefinite storage, > > > >Which 'we'? Fedora? or Fedora's mirrors? I guess I assumed the primary > >goal here was to reduce demands on mirrors, not on Fedora. > Fedora, right now we've got 43G free on the primary mirror. I want to > know what our options are. I guess for the primary mirror we could stock up its capacities or split into download and archives, or not? It would be sad to lose the binaries of FC1 and friends, even for historical and statistical purposes. There was just a thread on another list seeking old RH releases of the 90s. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From luis at tieguy.org Sun Mar 25 14:07:09 2007 From: luis at tieguy.org (Luis Villa) Date: Sun, 25 Mar 2007 10:07:09 -0400 Subject: S3 [was Re: GPL and storage requirements] Message-ID: <2cb10c440703250707p4e8d7b56h161dd95f79cc716f@mail.gmail.com> On 3/25/07, Matt Domsch wrote: > > [If disk for Fedora is really a serious problem, have you looked at > > Amazon S3? For something that can't be downloaded very often (like FC1 > > source) I'd imagine it would be fairly cheap.] > > It's crossed my mind, but I'd prefer if we could get such donated > rather than paid-for given we don't know how many folks could wind up > downloading it thus how much it would cost us. Reasonable. Amazon is a big RH user, right? Surely someone could talk them into giving you a gratis S3 account? :) Luis From luis at tieguy.org Mon Mar 26 02:29:39 2007 From: luis at tieguy.org (Luis Villa) Date: Sun, 25 Mar 2007 22:29:39 -0400 Subject: GPL and storage requirements In-Reply-To: <460540C0.9060108@redhat.com> References: <460540C0.9060108@redhat.com> Message-ID: <2cb10c440703251929p45d609d4y62f7221a48545014@mail.gmail.com> On 3/24/07, Mike McGrath wrote: > My question is, who knows the finer details of what the GPL requires us > to keep? Two things: (1) Brett Smith (FSF's GPL compliance guy) pointed me at this: http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites So mirrors can get rid of their sources, assuming you've guaranteed to them that you'll keep them available, and likely assuming that you notify them when the sources go away, so that their binaries can go away. Frankly, I think their interpretation of "from the same place" is even more strained than my interpretation of "written offer", but hey, they are the FSF, so they get to choose these things ;) (2) Brett says that if you'd like, feel free to contact him to answer more questions. He is brett @ fsf . Given that they are the people most likely to nag you about GPL violations, it seems like he's likely the best person to ask future questions to ;) HTH- Luis From mspevack at redhat.com Mon Mar 26 14:09:48 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 26 Mar 2007 10:09:48 -0400 (EDT) Subject: i wasn't around much fri/sat/sun Message-ID: I've got a few items left over from last week (including linuxtag related stuff) that I'm working on today, and so I may be a bit behind on any friday or weekend email. I wasn't really computer-available over the weekend. Just a heads up. Thanks. --Max From skvidal at linux.duke.edu Mon Mar 26 14:16:04 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 26 Mar 2007 10:16:04 -0400 Subject: i wasn't around much fri/sat/sun In-Reply-To: References: Message-ID: <1174918564.30355.9.camel@cutter> On Mon, 2007-03-26 at 10:09 -0400, Max Spevack wrote: > I've got a few items left over from last week (including linuxtag related > stuff) that I'm working on today, and so I may be a bit behind on any > friday or weekend email. > > I wasn't really computer-available over the weekend. > you mean you went home and had a weekend off and didn't use the computer? SHAME! :) No need to explain why you didn't work on the weekend, Max. It's enough to say it was a weekend, I hope. -sv From mspevack at redhat.com Mon Mar 26 17:06:22 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 26 Mar 2007 13:06:22 -0400 (EDT) Subject: fedora board tuesday 3/27, 17:00 EDT Message-ID: #fedora-meeting 17:00 EDT, 21:00 GMT We'll start with: (1) Donald Fischer (dff at redhat.com), VP Online Services will join us. Donald's previous jobs have been as the project manager/leader for Mugshot, as well as the product manager for RHEL a few years back. He'll talk about some of the things he has been working on both in the Red Hat and Fedora spaces, to share that with the Board and get our feedback. Donald has another appointment at :30 past the hour, so we'll start with him. Once he's done, I'll talk a bit more on a similar vein, and then we'll move into the other important topic. (2) Clearing up any confusion in mandate between the Board and FESCO and making sure that the lines between the two are clear, especially due to the fact that there are some people who sit on both, and that creates the opportunity for confusion. Thorsten and I have been chatting a bit about this offline, and I'll present some of our conversation to the Board. The Board does tend to (inadvertantly) poach some of FESCO's topics, and we need to fix that. (3) Talk about Fedora Board succession, especially with regard to the Red Hat seats, and thinking about it in a "role-based" way. Especially if we can properly delegate to FESCO, we have a lot of potentially good options in how we set up the Board. Off the top of my head (and incorporating lots of feedback that I've heard): * Chair -- Max * Red Hat appointed seats 1) RHEL engineering manager -- ??? 2) Fedora "downstream" stakeholder -- Chris Blizzard (OLPC) 3) product/marketing focus -- ??? 4) Fedora engineer -- Bill/Jeremy/??? 5) Potentially flipping this to a community seat * Community elected seats * open election for anyone (Red Hat or not) I think it's probably best for us to figure out who will be in the Red Hat appointed seats before we go ahead and figure out which 2 community seats will "stay" and which two will open up for election. Also because in the interest of having a well balanced Board (in terms of skills and focus), the appointed seats might have an impact on the community seats. -- 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 gdk at redhat.com Tue Mar 27 14:32:05 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Tue, 27 Mar 2007 10:32:05 -0400 (EDT) Subject: What do we think of this? Message-ID: http://www.oreillynet.com/linux/blog/2007/03/where_fedora_went_wrong.html Michael Schwendt has made a spirited and passionate response (thanks, Michael) to Caitlyn's comments. Is there any substance to these comments? --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From skvidal at linux.duke.edu Tue Mar 27 14:47:05 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 27 Mar 2007 10:47:05 -0400 Subject: What do we think of this? In-Reply-To: References: Message-ID: <1175006825.30355.62.camel@cutter> On Tue, 2007-03-27 at 10:32 -0400, Greg Dekoenigsberg wrote: > http://www.oreillynet.com/linux/blog/2007/03/where_fedora_went_wrong.html > > Michael Schwendt has made a spirited and passionate response (thanks, > Michael) to Caitlyn's comments. > > Is there any substance to these comments? Well, rawhide is frequently broken/out of sync. I don't think we expect but so much there. I think Michael has a point about deps not being broken in any given repo. However, due to the different mgmt/deployment practices/behavior b/t extras and core I know there have been cases where one is out of sync with the other for a little while and then it takes the mirrors X amount of time to catch up - but in the mean time the user has a broken dep dangling. A couple of things we can do/are doing to ameliorate this: 1. the repo merger will help make keeping up with whatever just moved around easier 2. updates-testing for all repos will help 3. repoclosure running before updates are pushed - michael schwendt has done some great work to make this happen in extras but it needs to be happen distro-wide. I think once we have the merge done his code will be valuable there. 4. the --skip-broken plugin for yum probably needs to be merged into base yum. That would allow us a nice(r) way to fallback if there's a dep problem in any repo. that'd be my take. -sv From fedora at leemhuis.info Tue Mar 27 14:51:32 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 27 Mar 2007 16:51:32 +0200 Subject: What do we think of this? In-Reply-To: References: Message-ID: <46092F74.6000207@leemhuis.info> Greg Dekoenigsberg schrieb: > http://www.oreillynet.com/linux/blog/2007/03/where_fedora_went_wrong.html > > Michael Schwendt has made a spirited and passionate response (thanks, > Michael) to Caitlyn's comments. > > Is there any substance to these comments? My 2 cent: "When upgrading a system with yum or pup I ended up with upgrades that couldn?t be run because of dependency issues." -- that happened in the past, and it IMHO happened much to often. But I think with the Core and Extras merge *and* the new updates systems it will hopefully happen a lot less. And if not then we need to find ways to improve. Cu thl From tcallawa at redhat.com Tue Mar 27 14:53:47 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 27 Mar 2007 09:53:47 -0500 Subject: What do we think of this? In-Reply-To: <1175006825.30355.62.camel@cutter> References: <1175006825.30355.62.camel@cutter> Message-ID: <1175007227.6493.101.camel@localhost.localdomain> On Tue, 2007-03-27 at 10:47 -0400, seth vidal wrote: > On Tue, 2007-03-27 at 10:32 -0400, Greg Dekoenigsberg wrote: > > http://www.oreillynet.com/linux/blog/2007/03/where_fedora_went_wrong.html > > > > Michael Schwendt has made a spirited and passionate response (thanks, > > Michael) to Caitlyn's comments. > > > > Is there any substance to these comments? Honestly, I think all of these comments come from one pivotal issue: Fedora won't break US law. Debian will. Ubuntu will. SuSE will. Gentoo will. Thus, there is no need for "extra" repositories to arise for these Linux distributions. And the average user wants to have software that breaks the law (mp3, dvd, etc). So they have to go outside the safety zone that is the distribution for Fedora, and here there be dragons. This problem sucks. It has always sucked. We're playing by the rules, where no one else is, and we're getting punished for it, while they prosper. The rules (US law) are broken. I just have no idea how to fix it in my lifetime, much less in the period of relevance for Fedora. ~spot From gdk at redhat.com Tue Mar 27 14:51:09 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Tue, 27 Mar 2007 10:51:09 -0400 (EDT) Subject: What do we think of this? In-Reply-To: <1175006825.30355.62.camel@cutter> References: <1175006825.30355.62.camel@cutter> Message-ID: On Tue, 27 Mar 2007, seth vidal wrote: > 2. updates-testing for all repos will help Meaning 3rd party repos? > 4. the --skip-broken plugin for yum probably needs to be merged into > base yum. That would allow us a nice(r) way to fallback if there's a dep > problem in any repo. Any compelling reason *not* to do this? --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From gdk at redhat.com Tue Mar 27 14:53:36 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Tue, 27 Mar 2007 10:53:36 -0400 (EDT) Subject: What do we think of this? In-Reply-To: <1175007227.6493.101.camel@localhost.localdomain> References: <1175006825.30355.62.camel@cutter> <1175007227.6493.101.camel@localhost.localdomain> Message-ID: On Tue, 27 Mar 2007, Tom "spot" Callaway wrote: > Honestly, I think all of these comments come from one pivotal issue: > > Fedora won't break US law. > > Debian will. Ubuntu will. SuSE will. Gentoo will. > > Thus, there is no need for "extra" repositories to arise for these Linux > distributions. And the average user wants to have software that breaks > the law (mp3, dvd, etc). So they have to go outside the safety zone that > is the distribution for Fedora, and here there be dragons. > > This problem sucks. It has always sucked. We're playing by the rules, > where no one else is, and we're getting punished for it, while they > prosper. > > The rules (US law) are broken. I just have no idea how to fix it in my > lifetime, much less in the period of relevance for Fedora. I think you're right. So let me ask this question. For other distros, do they mix free/non-free in the same repo? And for the ones that do not do this -- for the ones who have separate free/non-free repos -- how do they manage to keep content in sync between them? --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From jkeating at redhat.com Tue Mar 27 15:01:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Mar 2007 11:01:44 -0400 Subject: What do we think of this? In-Reply-To: <1175006825.30355.62.camel@cutter> References: <1175006825.30355.62.camel@cutter> Message-ID: <200703271101.45099.jkeating@redhat.com> On Tuesday 27 March 2007 10:47:05 seth vidal wrote: > 3. repoclosure running before updates are pushed - michael schwendt has > done some great work to make this happen in extras but it needs to be > happen distro-wide. I think once we have the merge done his code will be > valuable there. This already happens, although with the current push tools there is a race condition. The new update tool Luke is working on closes that condition a bit. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laroche at redhat.com Tue Mar 27 15:01:33 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 27 Mar 2007 17:01:33 +0200 Subject: What do we think of this? In-Reply-To: References: Message-ID: <20070327150133.GA13754@dudweiler.stuttgart.redhat.com> On Tue, Mar 27, 2007 at 10:32:05AM -0400, Greg Dekoenigsberg wrote: > > http://www.oreillynet.com/linux/blog/2007/03/where_fedora_went_wrong.html > > Michael Schwendt has made a spirited and passionate response (thanks, > Michael) to Caitlyn's comments. > > Is there any substance to these comments? Hello Greg, Seems to be a balance act between new development funstuff and a more controlled environment that a bigger user base can consume. Compared to rawhide only, using the update repos to get new code reviewed/stabilized/integrated is a very fast and powerful tool we have within Fedora which keeps us moving along pretty rapidly. We should add more dependency checks, maybe more rpmlint-type other checks in the future. Also an automated process to move between the "test" updates to the official released updates might be a good idea. >From what I've heard many Fedora users changed over to not automatically install updates, but rather do that e.g. every 4 weeks only. (The balance between a developer-oriented and a bigger user base will always stay a problem area.) regards, Florian La Roche From tcallawa at redhat.com Tue Mar 27 15:01:26 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 27 Mar 2007 10:01:26 -0500 Subject: What do we think of this? In-Reply-To: References: <1175006825.30355.62.camel@cutter> Message-ID: <1175007686.6493.104.camel@localhost.localdomain> On Tue, 2007-03-27 at 10:51 -0400, Greg Dekoenigsberg wrote: > On Tue, 27 Mar 2007, seth vidal wrote: > > > 2. updates-testing for all repos will help > > Meaning 3rd party repos? I continue to stand firm that its not updates-testing.repo that is needed, but "updates testers". We can barely manage formalized QA for Fedora (no disrespect to wwoods), how can we in good conscience impose that on other repositories? ~spot From jkeating at redhat.com Tue Mar 27 15:04:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Mar 2007 11:04:45 -0400 Subject: What do we think of this? In-Reply-To: References: <1175007227.6493.101.camel@localhost.localdomain> Message-ID: <200703271104.45898.jkeating@redhat.com> On Tuesday 27 March 2007 10:53:36 Greg Dekoenigsberg wrote: > For other distros, do they mix free/non-free in the same repo? ?And for > the ones that do not do this -- for the ones who have separate > free/non-free repos -- how do they manage to keep content in sync between > them? Danger Will, mixing terms. They have "non-free" as in not open source in different repos, but "non-free" as in "against US law" while it is still opensource may not be in a different repo. That said, even if the non-free stuff is in a different repo, they still maintain that repo and can coordinate the deps across and such. Fedora by nature makes it so that the non-free stuff has to exist outside the Fedora umbrella where we have no control over the repo and no good integration. -- 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 tcallawa at redhat.com Tue Mar 27 15:03:34 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 27 Mar 2007 10:03:34 -0500 Subject: What do we think of this? In-Reply-To: References: <1175006825.30355.62.camel@cutter> <1175007227.6493.101.camel@localhost.localdomain> Message-ID: <1175007814.6493.108.camel@localhost.localdomain> On Tue, 2007-03-27 at 10:53 -0400, Greg Dekoenigsberg wrote: > On Tue, 27 Mar 2007, Tom "spot" Callaway wrote: > > > Honestly, I think all of these comments come from one pivotal issue: > > > > Fedora won't break US law. > > > > Debian will. Ubuntu will. SuSE will. Gentoo will. > > > > Thus, there is no need for "extra" repositories to arise for these Linux > > distributions. And the average user wants to have software that breaks > > the law (mp3, dvd, etc). So they have to go outside the safety zone that > > is the distribution for Fedora, and here there be dragons. > > > > This problem sucks. It has always sucked. We're playing by the rules, > > where no one else is, and we're getting punished for it, while they > > prosper. > > > > The rules (US law) are broken. I just have no idea how to fix it in my > > lifetime, much less in the period of relevance for Fedora. > > I think you're right. > > So let me ask this question. > > For other distros, do they mix free/non-free in the same repo? And for > the ones that do not do this -- for the ones who have separate > free/non-free repos -- how do they manage to keep content in sync between > them? Debian interprets free/non-free in the FSF sense of the term, not in a legal sense. Ubuntu does the same. This means that they have mp3 code in their "free" repo. SuSE doesn't have any distinction that I can say, and Gentoo's closest repository equivalent is wholly merged. If you're asking if they have a legal/illegal split, the answer is no for all. ~spot From sundaram at fedoraproject.org Tue Mar 27 15:14:45 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 27 Mar 2007 20:44:45 +0530 Subject: What do we think of this? In-Reply-To: References: Message-ID: <460934E5.5020505@fedoraproject.org> Greg Dekoenigsberg wrote: > > http://www.oreillynet.com/linux/blog/2007/03/where_fedora_went_wrong.html > > Michael Schwendt has made a spirited and passionate response (thanks, > Michael) to Caitlyn's comments. > > Is there any substance to these comments? Sure, there is. * Out of sync mirrors - Should be solved by better mirror management systems being tested currently. Yum fails with a missing dependency error or keeps downloading packages which fail checksums due to the package being outdated and iterating through mirrors otherwise which doesn't give a good impression and often is blamed as a "yum issue". * Updates with missing dependencies (this is rare but happens on occasions due to some issue with the current update system which fails to catch this), package evr issues and missing gpg signatures. Expected to be solved via the new update system which Luke Macken agreed to take on. Not sure of its current status but the plan was to have this in place before the Fedora 7 release. * Mixing of incompatible third party repositories or conflict between Fedora repositories and a third party repository when a new package is introduced in the formal Fedora repositories - I suspect there are no easy answers to this. If we can coordinate better we should. The core/extras merge and resulting common infrastructure would make the process much better. If other features are in place before Fedora 7 release we are good. Rahul From wwoods at redhat.com Tue Mar 27 16:04:56 2007 From: wwoods at redhat.com (Will Woods) Date: Tue, 27 Mar 2007 12:04:56 -0400 Subject: What do we think of this? In-Reply-To: <1175007686.6493.104.camel@localhost.localdomain> References: <1175006825.30355.62.camel@cutter> <1175007686.6493.104.camel@localhost.localdomain> Message-ID: <1175011496.17842.111.camel@metroid.rdu.redhat.com> On Tue, 2007-03-27 at 10:01 -0500, Tom "spot" Callaway wrote: > On Tue, 2007-03-27 at 10:51 -0400, Greg Dekoenigsberg wrote: > > On Tue, 27 Mar 2007, seth vidal wrote: > > > > > 2. updates-testing for all repos will help > > > > Meaning 3rd party repos? > > I continue to stand firm that its not updates-testing.repo that is > needed, but "updates testers". We can barely manage formalized QA for > Fedora (no disrespect to wwoods), how can we in good conscience impose > that on other repositories? You're right - simply imposing that on other repos is not going to solve anything for them, just like the mere presence of updates-testing does not magically solve any of our problems. But: having updates-testing *does* allow us to build a proper testing workflow for proposed updates. So we're doing that. Hopefully the other repos can follow suit and benefit from this work. So yeah, it's not the presence of the -testing repo that helps, it's the workflow you build around it. I hope that we'll lead by example rather than demand compliance. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Tue Mar 27 16:05:18 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 27 Mar 2007 18:05:18 +0200 Subject: What do we think of this? In-Reply-To: <20070327150133.GA13754@dudweiler.stuttgart.redhat.com> References: <20070327150133.GA13754@dudweiler.stuttgart.redhat.com> Message-ID: <460940BE.7040700@leemhuis.info> Florian La Roche schrieb: > On Tue, Mar 27, 2007 at 10:32:05AM -0400, Greg Dekoenigsberg wrote: >>From what I've heard many Fedora users changed over to not automatically > install updates, but rather do that e.g. every 4 weeks only. > (The balance between a developer-oriented and a bigger user base will > always stay a problem area.) and somewhere else in this thread: Tom "spot" Callaway schrieb: > I continue to stand firm that its not updates-testing.repo that is > needed, but "updates testers". Sometimes I'm wondering if we should have two totally separate update channels/repos for Fedora releases: - one similar maintained then the current updates, with a slightly more bold approach (for example it could include a Firefox2 update for FC6) - one more traditional, careful maintained update repo where only stuff that fixes security problem/real bugs got pushed to that got tested a bit in the other repo first; the firefox2 update for example would never get build for this repo and only be available in the other. Then users could choose which of those tow they want. RHEL5/CentOS would still exist on one end for being even more careful and longer supported and rawhide on the other end for even more experimental stuff. But well, that would be a lot of work to maintain -- probably to much to realize it ATM. Maybe in one or two years from now, when the Core and Extras merge is done and we have lots of maintainers per package that would need to support such a idea. CU thl P.S.: Yes, that's more a general thought and does not solve the "updates don't work due to missing deps" problem at hand. From bugs.michael at gmx.net Tue Mar 27 16:17:43 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 27 Mar 2007 18:17:43 +0200 Subject: What do we think of this? In-Reply-To: <1175006825.30355.62.camel@cutter> References: <1175006825.30355.62.camel@cutter> Message-ID: <20070327181743.540eb2bd.bugs.michael@gmx.net> On Tue, 27 Mar 2007 10:47:05 -0400, seth vidal wrote: > On Tue, 2007-03-27 at 10:32 -0400, Greg Dekoenigsberg wrote: > > http://www.oreillynet.com/linux/blog/2007/03/where_fedora_went_wrong.html > > > > Michael Schwendt has made a spirited and passionate response (thanks, > > Michael) to Caitlyn's comments. > > > > Is there any substance to these comments? > > Well, rawhide is frequently broken/out of sync. I don't think we expect > but so much there. > > I think Michael has a point about deps not being broken in any given > repo. However, due to the different mgmt/deployment practices/behavior > b/t extras and core I know there have been cases where one is out of > sync with the other for a little while and then it takes the mirrors X > amount of time to catch up - but in the mean time the user has a broken > dep dangling. The term "broken dependency" is used differently here, though, which creates a blurred picture of the primary complaints. It is not [just] referred to the plain unresolved RPM dependencies that made it impossible for ESR to install something. The term is also used to refer to all sorts of bugs in packages for a stable dist, especially regression found after an update or after a dist-upgrade. The message in short: no bug whatsoever ought to find its way into the packages in the public repositories. Bugs in the packages <=> sloppy repository management <=> insufficient testing. It is accumulated grief, expressed as general criticism of Fedora's testing. Personal experience, a friend's experience, everyone of those who complain loudly could tell of unpleasant memories with one release of Fedora, even if it's just single bug in something as old as FC5 or even FC2. For one it's an update that broke Exchange Connector, for another one it's a kernel panic after a kernel update (and with poor trouble-shooting, e.g. no attempt at booting the previous kernel). Even another one has built up a lot of hate for Yum (its slowness or GUIs), RPM (database corruption anyone? [1]), trouble with proprietary drivers, or the FOSS/proprietary/non-free separation of repositories. [...] With regard to the mirroring problems, I don't understand yet why we push FE-6 and FE-5 daily (on average) even when the updates don't contain any important fixes, such as security fixes. Some packages apparently are updated daily with either snapshots from VCS or with minor updates. IMO this is over-ambitious. -- [1] Unstable RAM chips or unstable hardware are one way to reproduce it, but else? From bugs.michael at gmx.net Tue Mar 27 16:23:30 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 27 Mar 2007 18:23:30 +0200 Subject: What do we think of this? In-Reply-To: <460934E5.5020505@fedoraproject.org> References: <460934E5.5020505@fedoraproject.org> Message-ID: <20070327182330.23cd9a36.bugs.michael@gmx.net> On Tue, 27 Mar 2007 20:44:45 +0530, Rahul Sundaram wrote: > * Updates with missing dependencies (this is rare but happens on > occasions due to some issue with the current update system which fails > to catch this), Another pair of eyes from somebody with x86_64 experience would be appreciated here: https://bugzilla.redhat.com/230194 From tbm at cyrius.com Tue Mar 27 17:03:33 2007 From: tbm at cyrius.com (Martin Michlmayr) Date: Tue, 27 Mar 2007 18:03:33 +0100 Subject: What do we think of this? In-Reply-To: <1175007814.6493.108.camel@localhost.localdomain> References: <1175006825.30355.62.camel@cutter> <1175007227.6493.101.camel@localhost.localdomain> <1175007814.6493.108.camel@localhost.localdomain> Message-ID: <20070327170332.GE25388@deprecation.cyrius.com> * Tom spot Callaway [2007-03-27 10:03]: > Debian interprets free/non-free in the FSF sense of the term, not in > a legal sense. Debian used to have a "non-US" repository, but that was mainly for crypto software before the crypto export laws got relaxed. Sometimes people ask for the re-introduction of non-US to allow software that is not allowed in the US, but there are no plans to do this since the problem is not just with US law. Unlike Tom asserted, Debian isn't willing to break US law. For example, we don't distribute video encoding software. (*) Regarding patents, the stand is basically that software with patents is okay as long the patents are not actively enforced. ("free" is actually called "main") (*) Yes, MP3 playback software is included. I'm not quite sure why but possibly there's simply a different interpretation of the status of playback software. -- Martin Michlmayr http://www.cyrius.com/ From blizzard at redhat.com Tue Mar 27 17:32:49 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 27 Mar 2007 13:32:49 -0400 Subject: What do we think of this? In-Reply-To: <1175007227.6493.101.camel@localhost.localdomain> References: <1175006825.30355.62.camel@cutter> <1175007227.6493.101.camel@localhost.localdomain> Message-ID: <1175016769.19209.2.camel@localhost.localdomain> On Tue, 2007-03-27 at 09:53 -0500, Tom "spot" Callaway wrote: > Honestly, I think all of these comments come from one pivotal issue: > > Fedora won't break US law. > > Debian will. Ubuntu will. SuSE will. Gentoo will. > > Thus, there is no need for "extra" repositories to arise for these Linux > distributions. And the average user wants to have software that breaks > the law (mp3, dvd, etc). So they have to go outside the safety zone that > is the distribution for Fedora, and here there be dragons. > > This problem sucks. It has always sucked. We're playing by the rules, > where no one else is, and we're getting punished for it, while they > prosper. > > The rules (US law) are broken. I just have no idea how to fix it in my > lifetime, much less in the period of relevance for Fedora. Is there a reason why we don't say this widely? It's a compelling and simple to understand meme (free/non-free/illegal/illegal aside.) --Chris From gdk at redhat.com Tue Mar 27 17:47:19 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Tue, 27 Mar 2007 13:47:19 -0400 (EDT) Subject: What do we think of this? In-Reply-To: <200703271104.45898.jkeating@redhat.com> References: <1175007227.6493.101.camel@localhost.localdomain> <200703271104.45898.jkeating@redhat.com> Message-ID: On Tue, 27 Mar 2007, Jesse Keating wrote: > They have "non-free" as in not open source in different repos, but > "non-free" as in "against US law" while it is still opensource may not > be in a different repo. That said, even if the non-free stuff is in a > different repo, they still maintain that repo and can coordinate the > deps across and such. Fedora by nature makes it so that the non-free > stuff has to exist outside the Fedora umbrella where we have no control > over the repo and no good integration. Surely it's not in the interests of the 3rd party repos to contribute to Fedora breakage. Right? Is it *theroetically* possible to have a set of standards that unofficial repos could follow to be less likely to break us? And if so, what prevents those standards from being created, and met? Maybe these are stupid questions -- but I like putting stupid questions on the record. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From mmcgrath at redhat.com Tue Mar 27 17:56:34 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 27 Mar 2007 12:56:34 -0500 Subject: What do we think of this? In-Reply-To: References: <1175007227.6493.101.camel@localhost.localdomain> <200703271104.45898.jkeating@redhat.com> Message-ID: <46095AD2.20502@redhat.com> Greg Dekoenigsberg wrote: > On Tue, 27 Mar 2007, Jesse Keating wrote: > >> They have "non-free" as in not open source in different repos, but >> "non-free" as in "against US law" while it is still opensource may >> not be in a different repo. That said, even if the non-free stuff is >> in a different repo, they still maintain that repo and can coordinate >> the deps across and such. Fedora by nature makes it so that the >> non-free stuff has to exist outside the Fedora umbrella where we have >> no control over the repo and no good integration. > > Surely it's not in the interests of the 3rd party repos to contribute > to Fedora breakage. Right? > > Is it *theroetically* possible to have a set of standards that > unofficial repos could follow to be less likely to break us? And if > so, what prevents those standards from being created, and met? > > Maybe these are stupid questions -- but I like putting stupid > questions on the record. > > --g We could do a better job in coordinating with them and while its not in their interests to break Fedora its not always in their interests to do the work, which can be significant, to make sure it doesn't break anything. We as a community tend to take the stance "If its not free in every sense of the word, its not fedora" I think that some of the 3rd party repos out there have left a bad taste in our mouths as a result. I think we should embrace any work that people do for fedora as much as the law allows. This includes things like paid mp3 support and such. This might make these non-official fedora repos seem less... 3rd party and easier to work with. -Mike From skvidal at linux.duke.edu Tue Mar 27 18:00:42 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 27 Mar 2007 14:00:42 -0400 Subject: What do we think of this? In-Reply-To: <46095AD2.20502@redhat.com> References: <1175007227.6493.101.camel@localhost.localdomain> <200703271104.45898.jkeating@redhat.com> <46095AD2.20502@redhat.com> Message-ID: <1175018442.30355.78.camel@cutter> On Tue, 2007-03-27 at 12:56 -0500, Mike McGrath wrote: > Greg Dekoenigsberg wrote: > > On Tue, 27 Mar 2007, Jesse Keating wrote: > > > >> They have "non-free" as in not open source in different repos, but > >> "non-free" as in "against US law" while it is still opensource may > >> not be in a different repo. That said, even if the non-free stuff is > >> in a different repo, they still maintain that repo and can coordinate > >> the deps across and such. Fedora by nature makes it so that the > >> non-free stuff has to exist outside the Fedora umbrella where we have > >> no control over the repo and no good integration. > > > > Surely it's not in the interests of the 3rd party repos to contribute > > to Fedora breakage. Right? > > > > Is it *theroetically* possible to have a set of standards that > > unofficial repos could follow to be less likely to break us? And if > > so, what prevents those standards from being created, and met? > > > > Maybe these are stupid questions -- but I like putting stupid > > questions on the record. > > > > --g > We could do a better job in coordinating with them and while its not in > their interests to break Fedora its not always in their interests to do > the work, which can be significant, to make sure it doesn't break > anything. We as a community tend to take the stance "If its not free in > every sense of the word, its not fedora" I think that some of the 3rd > party repos out there have left a bad taste in our mouths as a result. > I think we should embrace any work that people do for fedora as much as > the law allows. This includes things like paid mp3 support and such. > This might make these non-official fedora repos seem less... 3rd party > and easier to work with. We need some bright delineation if we were to take something like this on. So we can tell the difference from when we are just helping free software that happens to be non-kosher in the US and when we're actually start being shills for closed-source software. I don't want any part of the latter. -sv From jkeating at redhat.com Tue Mar 27 18:14:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Mar 2007 14:14:51 -0400 Subject: What do we think of this? In-Reply-To: References: <200703271104.45898.jkeating@redhat.com> Message-ID: <200703271414.51765.jkeating@redhat.com> On Tuesday 27 March 2007 13:47:19 Greg Dekoenigsberg wrote: > Surely it's not in the interests of the 3rd party repos to contribute to > Fedora breakage. ?Right? > > Is it *theroetically* possible to have a set of standards that unofficial > repos could follow to be less likely to break us? ?And if so, what > prevents those standards from being created, and met? > > Maybe these are stupid questions -- but I like putting stupid questions on > the record. Standards are great, and we can ask that of them, but since we don't allow our name to be on it, and we aren't allowed to link to it in any way so long as they hold non-legal software, we don't have much recourse for enforcement. Add to that the implicit problem of two(or more) disconnected repositories. When we push updates in Fedora, we can and do break deps in the 3rd party repos. They have to rebuild against what we're publishing as updates before their deps are fixed. For OUR repos, we can prepare all these builds before pushing live so that the repos stay consistant. External parties do not have this luxury. And I'm not about to run repoclosure on N+ 3rd party repos before pushing out an update. -- 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 Tue Mar 27 18:19:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Mar 2007 14:19:17 -0400 Subject: What do we think of this? In-Reply-To: <20070327181743.540eb2bd.bugs.michael@gmx.net> References: <1175006825.30355.62.camel@cutter> <20070327181743.540eb2bd.bugs.michael@gmx.net> Message-ID: <200703271419.17768.jkeating@redhat.com> On Tuesday 27 March 2007 12:17:43 Michael Schwendt wrote: > With regard to the mirroring problems, I don't understand yet why we push > FE-6 and FE-5 daily (on average) even when the updates don't contain any > important fixes, such as security fixes. Some packages apparently are > updated daily with either snapshots from VCS or with minor updates. IMO > this is over-ambitious. I agree, and I feel that there needs to be guidelines as to what is an 'acceptable update' for a released Fedora. Extras has been wide open, push whatever you want, whenever you want. This can lead to a poor user experience, drinking from the firehose of updates leading to an unstable system. If that's the kind of experience they wanted, they'd use rawhide. We need to be more careful about what we push and why, as well as testing it to make sure we're not just lobbing grenades over the wall. New infrastructure and workflow will help setup the framework for this, but it still requires participation and man hours to do the testing. -- 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 tcallawa at redhat.com Tue Mar 27 18:17:50 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 27 Mar 2007 13:17:50 -0500 Subject: What do we think of this? In-Reply-To: <20070327170332.GE25388@deprecation.cyrius.com> References: <1175006825.30355.62.camel@cutter> <1175007227.6493.101.camel@localhost.localdomain> <1175007814.6493.108.camel@localhost.localdomain> <20070327170332.GE25388@deprecation.cyrius.com> Message-ID: <1175019470.6493.136.camel@localhost.localdomain> On Tue, 2007-03-27 at 18:03 +0100, Martin Michlmayr wrote: > * Tom spot Callaway [2007-03-27 10:03]: > > Debian interprets free/non-free in the FSF sense of the term, not in > > a legal sense. > > Debian used to have a "non-US" repository, but that was mainly for > crypto software before the crypto export laws got relaxed. Sometimes > people ask for the re-introduction of non-US to allow software that is > not allowed in the US, but there are no plans to do this since the > problem is not just with US law. > > Unlike Tom asserted, Debian isn't willing to break US law. For > example, we don't distribute video encoding software. (*) Regarding > patents, the stand is basically that software with patents is okay as > long the patents are not actively enforced. > > ("free" is actually called "main") > > (*) Yes, MP3 playback software is included. I'm not quite sure why > but possibly there's simply a different interpretation of the status > of playback software. Its patented. The patents are being actively enforced (by multiple parties): http://en.wikipedia.org/wiki/Alcatel-Lucent_v._Microsoft Also, I'm pretty sure that Debian is shipping DVD playback code, which violates the DMCA. ~spot From tibbs at math.uh.edu Tue Mar 27 18:21:29 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Mar 2007 13:21:29 -0500 Subject: What do we think of this? In-Reply-To: <200703271419.17768.jkeating@redhat.com> References: <1175006825.30355.62.camel@cutter> <20070327181743.540eb2bd.bugs.michael@gmx.net> <200703271419.17768.jkeating@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> I agree, and I feel that there needs to be guidelines as to what JK> is an 'acceptable update' for a released Fedora. I wrote a section into the draft maintainer responsibility policy about this a long time ago, but I'm not sure what ended up happening to that document. - J< From tcallawa at redhat.com Tue Mar 27 18:55:09 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 27 Mar 2007 13:55:09 -0500 Subject: What do we think of this? In-Reply-To: <1175016769.19209.2.camel@localhost.localdomain> References: <1175006825.30355.62.camel@cutter> <1175007227.6493.101.camel@localhost.localdomain> <1175016769.19209.2.camel@localhost.localdomain> Message-ID: <1175021709.6493.142.camel@localhost.localdomain> On Tue, 2007-03-27 at 13:32 -0400, Christopher Blizzard wrote: > On Tue, 2007-03-27 at 09:53 -0500, Tom "spot" Callaway wrote: > > Honestly, I think all of these comments come from one pivotal issue: > > > > Fedora won't break US law. > > > > Debian will. Ubuntu will. SuSE will. Gentoo will. > > > > Thus, there is no need for "extra" repositories to arise for these Linux > > distributions. And the average user wants to have software that breaks > > the law (mp3, dvd, etc). So they have to go outside the safety zone that > > is the distribution for Fedora, and here there be dragons. > > > > This problem sucks. It has always sucked. We're playing by the rules, > > where no one else is, and we're getting punished for it, while they > > prosper. > > > > The rules (US law) are broken. I just have no idea how to fix it in my > > lifetime, much less in the period of relevance for Fedora. > > Is there a reason why we don't say this widely? It's a compelling and > simple to understand meme (free/non-free/illegal/illegal aside.) Because we'd be accusing other groups of breaking the law. Thats potentially libel. I doubt Red Hat wants to take that kind of risk, whereas I am personally willing (I've got a pretty strong case that they're violating US patent law and the DMCA, and while I'd be more than happy to see these laws repealed, they're still the laws on the books). ~spot From blizzard at redhat.com Tue Mar 27 19:01:22 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 27 Mar 2007 15:01:22 -0400 Subject: What do we think of this? In-Reply-To: <1175021709.6493.142.camel@localhost.localdomain> References: <1175006825.30355.62.camel@cutter> <1175007227.6493.101.camel@localhost.localdomain> <1175016769.19209.2.camel@localhost.localdomain> <1175021709.6493.142.camel@localhost.localdomain> Message-ID: <1175022082.19209.13.camel@localhost.localdomain> On Tue, 2007-03-27 at 13:55 -0500, Tom "spot" Callaway wrote: > On Tue, 2007-03-27 at 13:32 -0400, Christopher Blizzard wrote: > > On Tue, 2007-03-27 at 09:53 -0500, Tom "spot" Callaway wrote: > > > Honestly, I think all of these comments come from one pivotal issue: > > > > > > Fedora won't break US law. > > > > > > Debian will. Ubuntu will. SuSE will. Gentoo will. > > > > > > Thus, there is no need for "extra" repositories to arise for these Linux > > > distributions. And the average user wants to have software that breaks > > > the law (mp3, dvd, etc). So they have to go outside the safety zone that > > > is the distribution for Fedora, and here there be dragons. > > > > > > This problem sucks. It has always sucked. We're playing by the rules, > > > where no one else is, and we're getting punished for it, while they > > > prosper. > > > > > > The rules (US law) are broken. I just have no idea how to fix it in my > > > lifetime, much less in the period of relevance for Fedora. > > > > Is there a reason why we don't say this widely? It's a compelling and > > simple to understand meme (free/non-free/illegal/illegal aside.) > > Because we'd be accusing other groups of breaking the law. Thats > potentially libel. I doubt Red Hat wants to take that kind of risk, > whereas I am personally willing (I've got a pretty strong case that > they're violating US patent law and the DMCA, and while I'd be more than > happy to see these laws repealed, they're still the laws on the books). That's easy to flip around into a positive personal assertion: "We don't do it because we feel it risks breaking the law and we can't impose that risk on our users, either." --Chris From a.badger at gmail.com Tue Mar 27 19:31:35 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 27 Mar 2007 12:31:35 -0700 Subject: What do we think of this? In-Reply-To: <200703271414.51765.jkeating@redhat.com> References: <200703271104.45898.jkeating@redhat.com> <200703271414.51765.jkeating@redhat.com> Message-ID: <1175023895.16371.10.camel@localhost.localdomain> On Tue, 2007-03-27 at 14:14 -0400, Jesse Keating wrote: > On Tuesday 27 March 2007 13:47:19 Greg Dekoenigsberg wrote: > > Surely it's not in the interests of the 3rd party repos to contribute to > > Fedora breakage. Right? > > > > Is it *theroetically* possible to have a set of standards that unofficial > > repos could follow to be less likely to break us? And if so, what > > prevents those standards from being created, and met? > > > > Maybe these are stupid questions -- but I like putting stupid questions on > > the record. > > Standards are great, and we can ask that of them, but since we don't allow our > name to be on it, and we aren't allowed to link to it in any way so long as > they hold non-legal software, we don't have much recourse for enforcement. > > Add to that the implicit problem of two(or more) disconnected repositories. > When we push updates in Fedora, we can and do break deps in the 3rd party > repos. They have to rebuild against what we're publishing as updates before > their deps are fixed. For OUR repos, we can prepare all these builds before > pushing live so that the repos stay consistant. External parties do not have > this luxury. And I'm not about to run repoclosure on N+ 3rd party repos > before pushing out an update. Here's where things could get interesting -- Can we make it easy for third party repositories to stay informed of what dep-breaking packages have been built and are waiting to be pushed to the repository? Can we make it easy for them to grab those packages and do a rebuild that waits in the wings for our push to make the new package live? And most importantly, how much work do they want to put into taking the data we provide and turning it into something that helps them keep up to date? -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 blizzard at redhat.com Tue Mar 27 19:35:28 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 27 Mar 2007 15:35:28 -0400 Subject: What do we think of this? In-Reply-To: <1175023895.16371.10.camel@localhost.localdomain> References: <200703271104.45898.jkeating@redhat.com> <200703271414.51765.jkeating@redhat.com> <1175023895.16371.10.camel@localhost.localdomain> Message-ID: <1175024128.19209.18.camel@localhost.localdomain> On Tue, 2007-03-27 at 12:31 -0700, Toshio Kuratomi wrote: > Here's where things could get interesting -- Can we make it easy for > third party repositories to stay informed of what dep-breaking packages > have been built and are waiting to be pushed to the repository? Can we > make it easy for them to grab those packages and do a rebuild that waits > in the wings for our push to make the new package live? > > And most importantly, how much work do they want to put into taking the > data we provide and turning it into something that helps them keep up to > date? Yes yes yes yes, I like how you're thinking. --Chris From matt at domsch.com Tue Mar 27 19:39:45 2007 From: matt at domsch.com (Matt Domsch) Date: Tue, 27 Mar 2007 13:39:45 -0600 Subject: What do we think of this? In-Reply-To: <1175023895.16371.10.camel@localhost.localdomain> References: <200703271104.45898.jkeating@redhat.com> <200703271414.51765.jkeating@redhat.com> <1175023895.16371.10.camel@localhost.localdomain> Message-ID: <20070327193944.GA17132@domsch.com> On Tue, Mar 27, 2007 at 12:31:35PM -0700, Toshio Kuratomi wrote: > On Tue, 2007-03-27 at 14:14 -0400, Jesse Keating wrote: > > On Tuesday 27 March 2007 13:47:19 Greg Dekoenigsberg wrote: > > > Surely it's not in the interests of the 3rd party repos to contribute to > > > Fedora breakage. Right? > > > > > > Is it *theroetically* possible to have a set of standards that unofficial > > > repos could follow to be less likely to break us? And if so, what > > > prevents those standards from being created, and met? > > > > > > Maybe these are stupid questions -- but I like putting stupid questions on > > > the record. > > > > Standards are great, and we can ask that of them, but since we don't allow our > > name to be on it, and we aren't allowed to link to it in any way so long as > > they hold non-legal software, we don't have much recourse for enforcement. > > > > Add to that the implicit problem of two(or more) disconnected repositories. > > When we push updates in Fedora, we can and do break deps in the 3rd party > > repos. They have to rebuild against what we're publishing as updates before > > their deps are fixed. For OUR repos, we can prepare all these builds before > > pushing live so that the repos stay consistant. External parties do not have > > this luxury. And I'm not about to run repoclosure on N+ 3rd party repos > > before pushing out an update. > > Here's where things could get interesting -- Can we make it easy for > third party repositories to stay informed of what dep-breaking packages > have been built and are waiting to be pushed to the repository? Can we > make it easy for them to grab those packages and do a rebuild that waits > in the wings for our push to make the new package live? AFAIK, the needsign repo is available for mirroring from the builders, and if it isn't available by public rsync, probably could be. -Matt From mmcgrath at redhat.com Tue Mar 27 19:45:14 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 27 Mar 2007 14:45:14 -0500 Subject: What do we think of this? In-Reply-To: <20070327193944.GA17132@domsch.com> References: <200703271104.45898.jkeating@redhat.com> <200703271414.51765.jkeating@redhat.com> <1175023895.16371.10.camel@localhost.localdomain> <20070327193944.GA17132@domsch.com> Message-ID: <4609744A.8030106@redhat.com> Matt Domsch wrote: > AFAIK, the needsign repo is available for mirroring from the builders, > and if it isn't available by public rsync, probably could be. > > -Matt > > http://buildsys.fedoraproject.org/needsign/ -Mike From jkeating at redhat.com Tue Mar 27 19:47:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Mar 2007 15:47:05 -0400 Subject: What do we think of this? In-Reply-To: <20070327193944.GA17132@domsch.com> References: <1175023895.16371.10.camel@localhost.localdomain> <20070327193944.GA17132@domsch.com> Message-ID: <200703271547.05860.jkeating@redhat.com> On Tuesday 27 March 2007 15:39:45 Matt Domsch wrote: > AFAIK, the needsign repo is available for mirroring from the builders, > and if it isn't available by public rsync, probably could be. This repo may not exist the way you think it is once we move to Koji. Needsign is more of a sideeffect of how plague and the extras system operates. Koji does not operate in this way. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Tue Mar 27 19:47:44 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 27 Mar 2007 14:47:44 -0500 Subject: What do we think of this? In-Reply-To: <20070327193944.GA17132@domsch.com> References: <1175023895.16371.10.camel@localhost.localdomain> <20070327193944.GA17132@domsch.com> Message-ID: <200703271447.45078.dennis@ausil.us> On Tuesday 27 March 2007 02:39:45 pm Matt Domsch wrote: > On Tue, Mar 27, 2007 at 12:31:35PM -0700, Toshio Kuratomi wrote: > > Here's where things could get interesting -- Can we make it easy for > > third party repositories to stay informed of what dep-breaking packages > > have been built and are waiting to be pushed to the repository? Can we > > make it easy for them to grab those packages and do a rebuild that waits > > in the wings for our push to make the new package live? > > AFAIK, the needsign repo is available for mirroring from the builders, > and if it isn't available by public rsync, probably could be. > Extras is available by http Core is not. right now there are no plans to enable it for the merged world. though things could be built against updates-testing and be ready for when it goes live. the only problem then is security fixes that need to be rushed through. One of the longer term goals is to have a means to announce out what was built so that Red Hat can do their own builds of rawhide for RHEL. there is no reason that this couldnt be made available to 3rd parties to trigger builds for them. -- Dennis Gilmore, RHCE From jkeating at redhat.com Tue Mar 27 19:53:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Mar 2007 15:53:38 -0400 Subject: What do we think of this? In-Reply-To: <1175023895.16371.10.camel@localhost.localdomain> References: <200703271414.51765.jkeating@redhat.com> <1175023895.16371.10.camel@localhost.localdomain> Message-ID: <200703271553.38619.jkeating@redhat.com> On Tuesday 27 March 2007 15:31:35 Toshio Kuratomi wrote: > Here's where things could get interesting -- Can we make it easy for > third party repositories to stay informed of what dep-breaking packages > have been built and are waiting to be pushed to the repository? Koji can send build notifications to any email address any user tells it to. > Can we > make it easy for them to grab those packages and do a rebuild that waits > in the wings for our push to make the new package live? Grabbing might be a bit trickier than needsign, as the contents go into a file system like /mnt/koji/packages///// There are repos for these packages but A) not in static locations, and B) not guaranteed to have the package just built in it. Jeremy and I kicked around the idea of having a two stage like rawhide, a nightly tree that is potentially made installable and synced around the world, and then a 'current' repo that is kept current by the buildsystem for each given tag. This repo can and will fluctuate during the day and may not always be consistant nor accurate if you try to hit it during a createrepo call. But it would allow for easily getting the absolutely latest built packages before the nightly push. However this only makes things harder for 3rd party as the 'rawhide' repo is now a moving target throughout the day. There may or may not be something like this for the updates collections, that a 3rd party repo could pay attention to. > > And most importantly, how much work do they want to put into taking the > data we provide and turning it into something that helps them keep up to > date? I don't want to put a lot of specific work into this. If the generic work we're doing for our own needs satisfies some of what they're doing, that's fine, but I'm not all that keen in putting a ton of effort into supporting something that doesn't fit under the Fedora umbrella either because it is A) illegal or B) non-free. I especially don't want to put in effort for supporting another repo that is just can't be bothered with doing their packages within Fedora and insist on doing them externally, even if the software is suitable for 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 skvidal at linux.duke.edu Tue Mar 27 19:55:03 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 27 Mar 2007 15:55:03 -0400 Subject: What do we think of this? In-Reply-To: <200703271447.45078.dennis@ausil.us> References: <1175023895.16371.10.camel@localhost.localdomain> <20070327193944.GA17132@domsch.com> <200703271447.45078.dennis@ausil.us> Message-ID: <1175025303.5762.2.camel@cutter> On Tue, 2007-03-27 at 14:47 -0500, Dennis Gilmore wrote: > On Tuesday 27 March 2007 02:39:45 pm Matt Domsch wrote: > > On Tue, Mar 27, 2007 at 12:31:35PM -0700, Toshio Kuratomi wrote: > > > > Here's where things could get interesting -- Can we make it easy for > > > third party repositories to stay informed of what dep-breaking packages > > > have been built and are waiting to be pushed to the repository? Can we > > > make it easy for them to grab those packages and do a rebuild that waits > > > in the wings for our push to make the new package live? > > > > AFAIK, the needsign repo is available for mirroring from the builders, > > and if it isn't available by public rsync, probably could be. > > > Extras is available by http Core is not. right now there are no plans to > enable it for the merged world. though things could be built against > updates-testing and be ready for when it goes live. the only problem then is > security fixes that need to be rushed through. > > One of the longer term goals is to have a means to announce out what was > built so that Red Hat can do their own builds of rawhide for RHEL. there is > no reason that this couldnt be made available to 3rd parties to trigger > builds for them. so let me make sure I understand this correctly. if I want to do a mock build on my local system using the latest of everything in all the just-built repos in koji then I can't? that seems to be a big negative. We should be able to export the repositories koji uses in mock internally to the outside world. It just needs to have an http server pointing to a path. If we can't then it means if someone wants to do a test build of their srpm before submitting and eating up bandwidth and cpu time, then they can't? -sv From dennis at ausil.us Tue Mar 27 19:59:00 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 27 Mar 2007 14:59:00 -0500 Subject: What do we think of this? In-Reply-To: <1175025303.5762.2.camel@cutter> References: <200703271447.45078.dennis@ausil.us> <1175025303.5762.2.camel@cutter> Message-ID: <200703271459.01192.dennis@ausil.us> On Tuesday 27 March 2007 02:55:03 pm seth vidal wrote: > On Tue, 2007-03-27 at 14:47 -0500, Dennis Gilmore wrote: > > On Tuesday 27 March 2007 02:39:45 pm Matt Domsch wrote: > > > On Tue, Mar 27, 2007 at 12:31:35PM -0700, Toshio Kuratomi wrote: > > > > Here's where things could get interesting -- Can we make it easy for > > > > third party repositories to stay informed of what dep-breaking > > > > packages have been built and are waiting to be pushed to the > > > > repository? Can we make it easy for them to grab those packages and > > > > do a rebuild that waits in the wings for our push to make the new > > > > package live? > > > > > > AFAIK, the needsign repo is available for mirroring from the builders, > > > and if it isn't available by public rsync, probably could be. > > > > Extras is available by http Core is not. right now there are no plans to > > enable it for the merged world. though things could be built against > > updates-testing and be ready for when it goes live. the only problem > > then is security fixes that need to be rushed through. > > > > One of the longer term goals is to have a means to announce out what was > > built so that Red Hat can do their own builds of rawhide for RHEL. there > > is no reason that this couldnt be made available to 3rd parties to > > trigger builds for them. > > so let me make sure I understand this correctly. > > if I want to do a mock build on my local system using the latest of > everything in all the just-built repos in koji then I can't? that seems > to be a big negative. We should be able to export the repositories koji > uses in mock internally to the outside world. It just needs to have an > http server pointing to a path. the repo does not exist in the format that needsign does in plague. we could script an export and create it. but right now we cant do that > If we can't then it means if someone wants to do a test build of their > srpm before submitting and eating up bandwidth and cpu time, then they > can't? If they want to do a testbuild they can by doing koji build --scratch f7-updates which will upload the srpm and do a build -- Dennis Gilmore, RHCE From fedora at leemhuis.info Wed Mar 28 04:57:11 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 28 Mar 2007 06:57:11 +0200 Subject: What do we think of this? In-Reply-To: References: <1175007227.6493.101.camel@localhost.localdomain> <200703271104.45898.jkeating@redhat.com> Message-ID: <4609F5A7.5070904@leemhuis.info> On 27.03.2007 19:47, Greg Dekoenigsberg wrote: > On Tue, 27 Mar 2007, Jesse Keating wrote: > > Surely it's not in the interests of the 3rd party repos to contribute to > Fedora breakage. Right? > > Is it *theroetically* possible to have a set of standards that unofficial > repos could follow to be less likely to break us? And if so, what > prevents those standards from being created, and met? > > Maybe these are stupid questions -- but I like putting stupid questions on > the record. /me put his 3rd party repo hat on Hopefully the 3rd party stuff should get better soon with a potential merge of some 3rd party repos (which got already mentioned in a board meeting afaik). The plan for this merged repo is to use Fedora infrastructure as much as possible. That includes repoclosure scripts and similar stuff, so it that should help to break stuff less often. But this stuff must be documented probably -- if it's to complicated to setup (like the accounts systems, that is tied into a LDAP server, that makes it quite hard to setup) then it's likely that 3rd party repo search for an alternative, that maybe is not that good, but easier to set up. Further: the need to be aware what updates gets pushed and especially when (as discussed in this thread already) would be helpful, as 3rd party repos then could prepare everything in time push their package updates build against the new Fedora update at the same time as Fedora. That would be helpful especially for things that break a lot of stuff -- kernel updates for example. At 24 hours or 48 hours heads-up "we plan to push kernel update foo at Friday 10:00 UTC" would be good. And sure, that's sometimes not possible (e.g. security updates), but often it is. CU thl From sundaram at fedoraproject.org Wed Mar 28 10:46:31 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 28 Mar 2007 16:16:31 +0530 Subject: What do we think of this? In-Reply-To: <4609F5A7.5070904@leemhuis.info> References: <1175007227.6493.101.camel@localhost.localdomain> <200703271104.45898.jkeating@redhat.com> <4609F5A7.5070904@leemhuis.info> Message-ID: <460A4787.50208@fedoraproject.org> Thorsten Leemhuis wrote: > On 27.03.2007 19:47, Greg Dekoenigsberg wrote: >> On Tue, 27 Mar 2007, Jesse Keating wrote: >> >> Surely it's not in the interests of the 3rd party repos to contribute to >> Fedora breakage. Right? >> >> Is it *theroetically* possible to have a set of standards that unofficial >> repos could follow to be less likely to break us? And if so, what >> prevents those standards from being created, and met? >> >> Maybe these are stupid questions -- but I like putting stupid questions on >> the record. > > /me put his 3rd party repo hat on > > Hopefully the 3rd party stuff should get better soon with a potential > merge of some 3rd party repos (which got already mentioned in a board > meeting afaik). I believe it was but I dont think I was in that meeting. Can you provide more details on the merger? If it was discussed anywhere else pointers would be just fine. Rahul From gdk at redhat.com Wed Mar 28 13:34:31 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 28 Mar 2007 09:34:31 -0400 (EDT) Subject: What do we think of this? In-Reply-To: <1175023895.16371.10.camel@localhost.localdomain> References: <200703271104.45898.jkeating@redhat.com> <200703271414.51765.jkeating@redhat.com> <1175023895.16371.10.camel@localhost.localdomain> Message-ID: On Tue, 27 Mar 2007, Toshio Kuratomi wrote: >> Add to that the implicit problem of two(or more) disconnected repositories. >> When we push updates in Fedora, we can and do break deps in the 3rd party >> repos. They have to rebuild against what we're publishing as updates before >> their deps are fixed. For OUR repos, we can prepare all these builds before >> pushing live so that the repos stay consistant. External parties do not have >> this luxury. And I'm not about to run repoclosure on N+ 3rd party repos >> before pushing out an update. > > Here's where things could get interesting -- Can we make it easy for > third party repositories to stay informed of what dep-breaking packages > have been built and are waiting to be pushed to the repository? Can we > make it easy for them to grab those packages and do a rebuild that waits > in the wings for our push to make the new package live? > > And most importantly, how much work do they want to put into taking the > data we provide and turning it into something that helps them keep up to > date? +1. Because here's the thing: I think that, all things being equal, the 3rd party repos would really prefer *not* breaking us or bring broken themselves. Right now, we point our fingers at 3rd party repos and say "their fault". Surely no one is actually happy with that scenario. Surely everyone would be amenable to looking for solutions. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From fedora at leemhuis.info Wed Mar 28 13:52:15 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 28 Mar 2007 15:52:15 +0200 Subject: What do we think of this? In-Reply-To: <460A4787.50208@fedoraproject.org> References: <1175007227.6493.101.camel@localhost.localdomain> <200703271104.45898.jkeating@redhat.com> <4609F5A7.5070904@leemhuis.info> <460A4787.50208@fedoraproject.org> Message-ID: <460A730F.8070109@leemhuis.info> On 28.03.2007 12:46, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: >> On 27.03.2007 19:47, Greg Dekoenigsberg wrote: >>> On Tue, 27 Mar 2007, Jesse Keating wrote: >>> Surely it's not in the interests of the 3rd party repos to contribute to >>> Fedora breakage. Right? >>> Is it *theroetically* possible to have a set of standards that unofficial >>> repos could follow to be less likely to break us? And if so, what >>> prevents those standards from being created, and met? >>> Maybe these are stupid questions -- but I like putting stupid questions on >>> the record. >> /me put his 3rd party repo hat on >> Hopefully the 3rd party stuff should get better soon with a potential >> merge of some 3rd party repos (which got already mentioned in a board >> meeting afaik). > I believe it was but I dont think I was in that meeting. I'm quite sure it was once on IRC during a meeting some weeks ago that someone else involved in the effort informed to board about the happenings (I think it got mentioned on this list, too). > Can you provide > more details on the merger? If it was discussed anywhere else pointers > would be just fine. Google finds pointers if you use the the proper wording. But no, I can't provide any more details regarding the repo merge ATM, as the plan was/is to not announce it when the rough plan how to actually do it was worked out. Sorry -- I disagree with that, but it's not my decision alone. CU thl From fedora at leemhuis.info Wed Mar 28 13:54:16 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 28 Mar 2007 15:54:16 +0200 Subject: What do we think of this? In-Reply-To: References: <200703271104.45898.jkeating@redhat.com> <200703271414.51765.jkeating@redhat.com> <1175023895.16371.10.camel@localhost.localdomain> Message-ID: <460A7388.6080507@leemhuis.info> On 28.03.2007 15:34, Greg Dekoenigsberg wrote: > On Tue, 27 Mar 2007, Toshio Kuratomi wrote: >>> Add to that the implicit problem of two(or more) disconnected repositories. >>> When we push updates in Fedora, we can and do break deps in the 3rd party >>> repos. They have to rebuild against what we're publishing as updates before >>> their deps are fixed. For OUR repos, we can prepare all these builds before >>> pushing live so that the repos stay consistant. External parties do not have >>> this luxury. And I'm not about to run repoclosure on N+ 3rd party repos >>> before pushing out an update. >> Here's where things could get interesting -- Can we make it easy for >> third party repositories to stay informed of what dep-breaking packages >> have been built and are waiting to be pushed to the repository? Can we >> make it easy for them to grab those packages and do a rebuild that waits >> in the wings for our push to make the new package live? >> >> And most importantly, how much work do they want to put into taking the >> data we provide and turning it into something that helps them keep up to >> date? > > +1. [...] Greg, thanks for your support. I know of at least one 3rd party repo that actually asked once or twice to get a heads up before kernel updates before they get pushed, but the request was denied :-/ CU thl From tbm at cyrius.com Wed Mar 28 13:58:47 2007 From: tbm at cyrius.com (Martin Michlmayr) Date: Wed, 28 Mar 2007 14:58:47 +0100 Subject: Lessons Learned In-Reply-To: <20070319194758.GB25331@deprecation.cyrius.com> References: <45FED71D.3010801@redhat.com> <45FEDC96.8010103@redhat.com> <20070319194758.GB25331@deprecation.cyrius.com> Message-ID: <20070328135847.GA14252@deprecation.cyrius.com> * Martin Michlmayr [2007-03-19 20:47]: > * Havoc Pennington [2007-03-19 14:55]: > > Martin Michlmayr has a great (though 200-page) paper in the works on > > open source release processes, including Debian and GNOME - it's not > > public yet but when it comes out I'd encourage reading it for some > > stuff to learn related to this. Keep an eye out for this one. > > Newsforge will write an article about it, so you don't have to read > the whole document. http://www.linux.com/article.pl?sid=07/03/21/1838230 The full thesis: http://www.cyrius.com/publications/michlmayr-phd.html -- Martin Michlmayr http://www.cyrius.com/ From mspevack at redhat.com Wed Mar 28 14:55:55 2007 From: mspevack at redhat.com (Max Spevack) Date: Wed, 28 Mar 2007 10:55:55 -0400 (EDT) Subject: yesterday's board meeting Message-ID: http://fedoraproject.org/wiki/Board/Meetings/2007-03-27 Actual details reprinted below, in case people want to comment. --Max ------------- === General Business === '''Donald Fischer''' The first 40 minutes of the meeting was spent talking with DonaldFischer, Red Hat's VP of Online Services. Previously Donald has led the [http://www.mugshot.org Mugshot] group, and also been the product manager for RHEL. Donald's Mugshot team has been doing a tremendous amount of work in the Fedora space, and he wanted to take some time to tell us about it, and begin thinking about how it can play into Fedora 8's feature set. The best link to look at, in order to get an idea of the vision: * http://developer.mugshot.org/wiki/Big_Board_Design We'd like to stress that this wasn't the Board deciding "we're going to put all of this directly into Fedora". It was Donald showing off (on behalf of his larger team) a lot of the things they are playing around with, and wanting the Fedora community to be up to speed on it. One of the things that was discussed was the fact that Fedora 7 will allow a group like Donald's all the tools necessary to put together a "Experimental Desktop" spin anytime they want, which can be really useful for testing and getting their ideas into people's hands in a very consumable way. '''Live USB''' Jeremy indicated to us that LiveUSB keys are close to becoming a reality. It will basically be Jeremy's decision as to whether we can do a LiveUSB key or just plain LiveCD for the Red Hat Summit. '''Fedora Board and Fedora Engineering Steering Committee''' Max summarized his recent conversation with ThorstenLeemhuis in which they discussed the fact that the Fedora Board is inadvertantly poaching some of the topics that are more appropriately discussed by FESCO. Examples include (1) EPEL guildelines, (2) release schedule details, and (3) status checks on the most important Fedora 7 features. The Board needs to do a better job of *understanding* what is going on with all those items and being informed, but not necessarily making the decisions itself -- that takes away a bit from FESCO, which should have the first opportunity to act. Further clarification can be provided, but the general sentiment was agreed upon by all. '''General Fedora Board stuff''' We talked about the need to do a better job of making it clear how the Board's decisions (at least the controversial ones) are made, and indicating whether there is generally consensus in those decisions, or if there is a lot of dissent. The next time a "tough" decision is made by the Board, there will be more conversation about it in this way. We are also taking the steps necessary to figure out how the Board succession will look, since there will be some changes after Fedora 7. Right now this is being discussed on the private fedora-board-list, but it will jump over to fedora-advisory-board soon. It is also being discussed [:Board/SuccessionPlanning: on the wiki]. From mspevack at redhat.com Wed Mar 28 16:21:53 2007 From: mspevack at redhat.com (Max Spevack) Date: Wed, 28 Mar 2007 12:21:53 -0400 (EDT) Subject: mspevack/mmcgrath out thursday Message-ID: Mike and I are in an all day (8:00 AM - 6:00 PM) Red Hat Summit prep event all day on Thursday 3/29, and in theory, also until Noon on Friday. --Max From tcallawa at redhat.com Wed Mar 28 16:22:54 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 28 Mar 2007 11:22:54 -0500 Subject: mspevack/mmcgrath out thursday In-Reply-To: References: Message-ID: <1175098974.6493.208.camel@localhost.localdomain> On Wed, 2007-03-28 at 12:21 -0400, Max Spevack wrote: > Mike and I are in an all day (8:00 AM - 6:00 PM) Red Hat Summit prep event > all day on Thursday 3/29, and in theory, also until Noon on Friday. Jesse Keating and I will be in the same tortu...training. ~spot From fedora at leemhuis.info Thu Mar 29 05:12:30 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 29 Mar 2007 07:12:30 +0200 Subject: yesterday's board meeting In-Reply-To: References: Message-ID: <460B4ABE.5080509@leemhuis.info> Hi all! On 28.03.2007 16:55, Max Spevack wrote: > http://fedoraproject.org/wiki/Board/Meetings/2007-03-27 thx for the Summary Max! > Actual details reprinted below, in case people want to comment. > [...] > '''Fedora Board and Fedora Engineering Steering Committee''' > [...] > > '''General Fedora Board stuff''' > > We talked about the need to do a better job of making it clear how the > Board's decisions (at least the controversial ones) are made, and > indicating whether there is generally consensus in those decisions, or if > there is a lot of dissent. The next time a "tough" decision is made by > the Board, there will be more conversation about it in this way. > > We are also taking the steps necessary to figure out how the Board > succession will look, since there will be some changes after Fedora 7. > Right now this is being discussed on the private fedora-board-list, but it > will jump over to fedora-advisory-board soon. It is also being discussed > [:Board/SuccessionPlanning: on the wiki]. Quoting the wiki: "RH 3: Engineer/Engineering manager with strong relationship to RHEL; We get a lot of complaints that RHEL folks don't have enough insight into Fedora. This is an attempt to fix that. We will gather some suggestions from RHEL managers and evaluate from there.". Just wondering: Might it be better to get someone from RHEL engineering into FESCo or both the Board and FESCo? FESCo afaics should be the one that does the technical decisions -- those have a strong impact for RHEL so having someone from RHEL there might be better. On the other hand: FESCo does meetings and nearly all other things in the open, so RHEL people can join there easily if they want. CU thl From tchung at fedoraproject.org Thu Mar 29 18:03:57 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Thu, 29 Mar 2007 11:03:57 -0700 Subject: Releases wiki page Message-ID: <369bce3b0703291103w18e8f65fxae4642c3183baebd@mail.gmail.com> All, We need some content for Releases wiki page. http://fedoraproject.org/wiki/Releases/ For the moment, it's place holder for all Fedora Releases. We need some introduction and point to current/past/future Fedora Releases. Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung