From mspevack at redhat.com Mon Apr 2 14:37:49 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 2 Apr 2007 10:37:49 -0400 (EDT) Subject: Board Meeting April 3 Message-ID: We'll have a Fedora Board Meeting tomorrow (April 3) at 10:00 AM Eastern Time (14:00 GMT). We'll be in #fedora-meeting as much as possible. Topic 1 is the LiveFoo for the Red Hat Summit. * Jesse and Max gave LiveUSB demo to mszulik on Friday. I will share his feedback (which was all positive) * We need to answer any open questions about the LiveFoo for the Red Hat Summit, and have a deadline in place for an image that can go into QA, and also one that can pass QA. * Greg's been talking to some of the RH marketing folks about multimedia we can add to this image (like the Truth Happens video, for example). That probably forces us to a > 700 MB image, which means LiveDVD or LiveUSB and not LiveCD. Topic 2 is a private one, that can't quite yet be shared publicly. --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 jwboyer at jdub.homelinux.org Mon Apr 2 15:15:24 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 02 Apr 2007 10:15:24 -0500 Subject: Board Meeting April 3 In-Reply-To: References: Message-ID: <1175526924.32658.42.camel@vader.jdub.homelinux.org> On Mon, 2007-04-02 at 10:37 -0400, Max Spevack wrote: > > Topic 2 is a private one, that can't quite yet be shared publicly. As a suggestion, you could leave things like this off these emails. If the public can't know anything about it yet, then there's no reason to tell people you're talking about it. It's just a tease. That would also help the cases where the "quite yet" part disappears and you never can talk about it publicly. josh From mspevack at redhat.com Mon Apr 2 16:19:37 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 2 Apr 2007 12:19:37 -0400 (EDT) Subject: Board Meeting April 3 In-Reply-To: <1175526924.32658.42.camel@vader.jdub.homelinux.org> References: <1175526924.32658.42.camel@vader.jdub.homelinux.org> Message-ID: On Mon, 2 Apr 2007, Josh Boyer wrote: >> Topic 2 is a private one, that can't quite yet be shared publicly. > > As a suggestion, you could leave things like this off these emails. If > the public can't know anything about it yet, then there's no reason to > tell people you're talking about it. It's just a tease. Sure. I guess I was just trying to be transparent -- because when there's no more meeting minutes in IRC halfway through, someone's bound to ask why anyway. > That would also help the cases where the "quite yet" part disappears and > you never can talk about it publicly. Well, in this case that won't happen, but I hear what you're saying. --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 wtogami at redhat.com Mon Apr 2 17:16:39 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 02 Apr 2007 13:16:39 -0400 Subject: Board Meeting April 3 In-Reply-To: References: Message-ID: <46113A77.6040403@redhat.com> Please make a decision for the redhat CLA change as a top priority. This is seen by RH engineering management as a blocker for the merge. Warren From matt at domsch.com Mon Apr 2 18:05:21 2007 From: matt at domsch.com (Matt Domsch) Date: Mon, 2 Apr 2007 13:05:21 -0500 Subject: Board Meeting April 3 In-Reply-To: <46113A77.6040403@redhat.com> References: <46113A77.6040403@redhat.com> Message-ID: <20070402180520.GA12035@domsch.com> On Mon, Apr 02, 2007 at 01:16:39PM -0400, Warren Togami wrote: > Please make a decision for the redhat CLA change as a top priority. > This is seen by RH engineering management as a blocker for the merge. It's received 3 +1s already, no other comments, so I expect it'll go through just fine. -Matt From jwboyer at jdub.homelinux.org Mon Apr 2 18:17:50 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 02 Apr 2007 13:17:50 -0500 Subject: Board Meeting April 3 In-Reply-To: <20070402180520.GA12035@domsch.com> References: <46113A77.6040403@redhat.com> <20070402180520.GA12035@domsch.com> Message-ID: <1175537870.32658.45.camel@vader.jdub.homelinux.org> On Mon, 2007-04-02 at 13:05 -0500, Matt Domsch wrote: > On Mon, Apr 02, 2007 at 01:16:39PM -0400, Warren Togami wrote: > > Please make a decision for the redhat CLA change as a top priority. > > This is seen by RH engineering management as a blocker for the merge. > > It's received 3 +1s already, no other comments, so I expect it'll go > through just fine. For the peanut gallery, where's this change at again? josh From mmcgrath at redhat.com Mon Apr 2 18:28:32 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 02 Apr 2007 13:28:32 -0500 Subject: Board Meeting April 3 In-Reply-To: <1175537870.32658.45.camel@vader.jdub.homelinux.org> References: <46113A77.6040403@redhat.com> <20070402180520.GA12035@domsch.com> <1175537870.32658.45.camel@vader.jdub.homelinux.org> Message-ID: <46114B50.5080805@redhat.com> Josh Boyer wrote: > On Mon, 2007-04-02 at 13:05 -0500, Matt Domsch wrote: > >> On Mon, Apr 02, 2007 at 01:16:39PM -0400, Warren Togami wrote: >> >>> Please make a decision for the redhat CLA change as a top priority. >>> This is seen by RH engineering management as a blocker for the merge. >>> >> It's received 3 +1s already, no other comments, so I expect it'll go >> through just fine. >> > > For the peanut gallery, where's this change at again? > > https://www.redhat.com/archives/fedora-infrastructure-list/2007-March/msg00248.html -Mike From jwboyer at jdub.homelinux.org Mon Apr 2 22:42:46 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 02 Apr 2007 17:42:46 -0500 Subject: Board Meeting April 3 In-Reply-To: <46114B50.5080805@redhat.com> References: <46113A77.6040403@redhat.com> <20070402180520.GA12035@domsch.com> <1175537870.32658.45.camel@vader.jdub.homelinux.org> <46114B50.5080805@redhat.com> Message-ID: <1175553767.32658.52.camel@vader.jdub.homelinux.org> On Mon, 2007-04-02 at 13:28 -0500, Mike McGrath wrote: > Josh Boyer wrote: > > On Mon, 2007-04-02 at 13:05 -0500, Matt Domsch wrote: > > > >> On Mon, Apr 02, 2007 at 01:16:39PM -0400, Warren Togami wrote: > >> > >>> Please make a decision for the redhat CLA change as a top priority. > >>> This is seen by RH engineering management as a blocker for the merge. > >>> > >> It's received 3 +1s already, no other comments, so I expect it'll go > >> through just fine. > >> > > > > For the peanut gallery, where's this change at again? > > > > > https://www.redhat.com/archives/fedora-infrastructure-list/2007-March/msg00248.html > The original thread says "We both realize there are potential problems in this..." What would those problems be? And is the Red Hat CLA available anywhere for the public to read? Just curious. josh From mspevack at redhat.com Tue Apr 3 20:10:55 2007 From: mspevack at redhat.com (Max Spevack) Date: Tue, 3 Apr 2007 16:10:55 -0400 (EDT) Subject: Board Meeting April 3 In-Reply-To: <46113A77.6040403@redhat.com> References: <46113A77.6040403@redhat.com> Message-ID: On Mon, 2 Apr 2007, Warren Togami wrote: > Please make a decision for the redhat CLA change as a top priority. This is > seen by RH engineering management as a blocker for the merge. Everyone agrees. Make it happen, Warren. :-) --Max From nman64 at n-man.com Wed Apr 4 17:48:22 2007 From: nman64 at n-man.com (Patrick W. Barnes) Date: Wed, 4 Apr 2007 12:48:22 -0500 Subject: Seeking reviewers for Summer of Code applications Message-ID: <200704041248.29269.nman64@n-man.com> We've got nearly 40 applications, not counting those that have been marked as ineligible, from potential Summer of Code students. We must review these applications and select which ones will be most valuable to the Fedora Project and have a real chance of success. I would appreciate any contributor volunteers that would like to assist in reviewing and ranking the applications. I would also still welcome any more volunteer mentors to handle the applications we end up accepting. We've only got a few days to decide, so, if you can help, please sign up and start providing feedback right away. The resources you need are listed on the wiki: http://fedoraproject.org/wiki/SummerOfCode/Mentors If you have questions, let me know. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://n-man.com/ LinkedIn: http://linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gdk at redhat.com Wed Apr 4 17:54:25 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 4 Apr 2007 13:54:25 -0400 (EDT) Subject: Seeking reviewers for Summer of Code applications In-Reply-To: <200704041248.29269.nman64@n-man.com> References: <200704041248.29269.nman64@n-man.com> Message-ID: Please, please, please do this. It'll take you five minutes to fill out the application. Note: it's listed as "The Fedora Project," which means look under "T" instead of "F", heh. Patrick: will we be having regular meetings of SoC mentors? --g On Wed, 4 Apr 2007, Patrick W. Barnes wrote: > > We've got nearly 40 applications, not counting those that have been marked as > ineligible, from potential Summer of Code students. We must review these > applications and select which ones will be most valuable to the Fedora > Project and have a real chance of success. > > I would appreciate any contributor volunteers that would like to assist in > reviewing and ranking the applications. I would also still welcome any more > volunteer mentors to handle the applications we end up accepting. We've only > got a few days to decide, so, if you can help, please sign up and start > providing feedback right away. > > The resources you need are listed on the wiki: > > http://fedoraproject.org/wiki/SummerOfCode/Mentors > > If you have questions, let me know. > > -- Greg DeKoenigsberg Community Development Manager Red Hat, Inc. :: 1-919-754-4255 "To whomsoever much hath been given... ...from him much shall be asked" From nman64 at n-man.com Mon Apr 9 05:11:52 2007 From: nman64 at n-man.com (Patrick W. Barnes) Date: Mon, 9 Apr 2007 00:11:52 -0500 Subject: Deadline for Summer of Code app reviews approaches Message-ID: <200704090011.58887.nman64@n-man.com> We need to finish evaluations on the Summer of Code applications before Wednesday (2007-04-11 00:00 Pacific, 07:00 UTC). On Wednesday, the student allotments will be finalized and we'll lose any applications that don't have mentors assigned. Our current projected allotment is 6 projects, though we might pick up extra slots if we have mentors assigned for more. After my last call, we had several more people sign up to help review (thanks!), but only a few have gone back and entered comments or evaluations. While we could proceed with the evaluations we have so far, I think we'd all be happier if we had stronger reviews of the proposals before making any decisions. On Tuesday, I'll make any arbitrary decisions I have to in order to accept the right proposals, and I'll assign mentors from among the volunteers. I'll mentor as many students as I need to, but it would really be best if each student had their own primary mentor with any number of backup mentors. It doesn't take much to serve as a mentor, so please volunteer if you see a proposal you like. Once again, the necessary resources can be found from the wiki: http://fedoraproject.org/wiki/SummerOfCode/Mentors If you need help, please email me directly for the sake of speed. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://n-man.com/ LinkedIn: http://linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mspevack at redhat.com Mon Apr 9 13:58:41 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 9 Apr 2007 09:58:41 -0400 (EDT) Subject: Board Meeting Tuesday April 10 Message-ID: 17:00 EDT, 21:00 GMT, in #fedora-meeting Unlike last week's meeting, I expect tomorrow's meeting to be very IRC intensive, and I would like to invite some of the members of this list, as well as folks who are active in FESCO, to "hang around" during the meeting. In fact, I'd like to experiment tomorrow and hold the entire meeting on IRC -- not have a phone call that we are also transcribing. I want to use the hour to completely go over the main deliverables for Fedora 7, and get a sense of where everything is from a quality and readiness perspective. And in an effort to make sure that the Board isn't passing judgement on topics that should be handled at a "lower" level, I'd like to make sure that some of the other leaders of major F7 areas are around. In particular, in addition to the Board members, if the following folks can be around, or pingable, I'd appreciate it: - Will Woods - Jesse Keating - KDE Spin leaders - Revisor leaders - Karsten Wade - Mike McGrath Thanks, Max -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From jkeating at redhat.com Mon Apr 9 14:10:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 9 Apr 2007 10:10:45 -0400 Subject: Board Meeting Tuesday April 10 In-Reply-To: References: Message-ID: <200704091010.45326.jkeating@redhat.com> On Monday 09 April 2007 09:58:41 Max Spevack wrote: > ????????- Jesse Keating I'll be there. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwade at redhat.com Mon Apr 9 15:12:15 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 09 Apr 2007 08:12:15 -0700 Subject: Board Meeting Tuesday April 10 In-Reply-To: References: Message-ID: <1176131535.3347.126.camel@erato.phig.org> On Mon, 2007-04-09 at 09:58 -0400, Max Spevack wrote: > 17:00 EDT, 21:00 GMT, in #fedora-meeting Sorry, I've got an existing appointment that puts me AFK until 2230 UTC. You'll have to rely upon Paul's knowledge for documentation, or ask me any questions in advance. - 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 blizzard at redhat.com Mon Apr 9 17:02:00 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 09 Apr 2007 13:02:00 -0400 Subject: Board Meeting Tuesday April 10 In-Reply-To: References: Message-ID: <1176138120.19569.12.camel@localhost.localdomain> On Mon, 2007-04-09 at 09:58 -0400, Max Spevack wrote: > 17:00 EDT, 21:00 GMT, in #fedora-meeting Sending my regrets. I have the engineering manager meetings in boston. --Chris From kanarip at kanarip.com Mon Apr 9 18:31:26 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 09 Apr 2007 20:31:26 +0200 Subject: Board Meeting Tuesday April 10 In-Reply-To: References: Message-ID: <461A867E.6070604@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Max Spevack wrote: > 17:00 EDT, 21:00 GMT, in #fedora-meeting > > Unlike last week's meeting, I expect tomorrow's meeting to be very IRC > intensive, and I would like to invite some of the members of this list, > as well as folks who are active in FESCO, to "hang around" during the > meeting. > > In fact, I'd like to experiment tomorrow and hold the entire meeting on > IRC -- not have a phone call that we are also transcribing. > > I want to use the hour to completely go over the main deliverables for > Fedora 7, and get a sense of where everything is from a quality and > readiness perspective. And in an effort to make sure that the Board > isn't passing judgement on topics that should be handled at a "lower" > level, I'd like to make sure that some of the other leaders of major F7 > areas are around. > > In particular, in addition to the Board members, if the following folks > can be around, or pingable, I'd appreciate it: > > - Will Woods > - Jesse Keating > - KDE Spin leaders > - Revisor leaders > - Karsten Wade > - Mike McGrath > > Thanks, > Max > I'll be there for Revisor. Kind regards, Jeroen van Meeuwen - -kanarip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGGoZ+KN6f2pNCvwgRAhn/AJ9JUnlsUj+lfZwqpMs5GqmFYWPAxACbBdgb Xx/Wm9hbSo4royvnSbj2lNU= =4opH -----END PGP SIGNATURE----- From rdieter at math.unl.edu Tue Apr 10 14:52:56 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 10 Apr 2007 09:52:56 -0500 Subject: Board Meeting Tuesday April 10 In-Reply-To: References: Message-ID: <461BA4C8.1020803@math.unl.edu> Max Spevack wrote: > 17:00 EDT, 21:00 GMT, in #fedora-meeting ... > In particular, in addition to the Board members, if the following folks > can be around, or pingable, I'd appreciate it: > - KDE Spin leaders I and Sebastian Vahl will be present, Than Ngo regrettably will be unable to attend. -- Rex From blizzard at redhat.com Tue Apr 10 16:54:07 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 10 Apr 2007 12:54:07 -0400 Subject: cross-site bug tracking Message-ID: <1176224048.3069.30.camel@localhost.localdomain> Some good comments and questions from the desktop-arch list. Worth thinking about as Fedora is one of the few places that has to bridge between itself and a huge number of upstream projects and at the same time have a commitment to free software for our infrastructure as well as what we distribute. Thoughts? (For the record, before it's mentioned, re-implement Launchpad as free software is not a solution, I suspect. We can do something with the rest of the free software community that everyone could adopt if we try and solve it the right way.) --Chris -------------- next part -------------- An embedded message was scrubbed... From: John Cherry Subject: [Desktop_architects] Cross-site bug tracking Date: Tue, 10 Apr 2007 08:13:22 -0700 Size: 4759 URL: -------------- next part -------------- An embedded message was scrubbed... From: "Aaron J. Seigo" Subject: Re: [Desktop_architects] Cross-site bug tracking Date: Tue, 10 Apr 2007 10:23:15 -0600 Size: 8450 URL: From fedora at leemhuis.info Tue Apr 10 17:35:48 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 10 Apr 2007 19:35:48 +0200 Subject: Board Meeting Tuesday April 10 In-Reply-To: References: Message-ID: <461BCAF4.5010602@leemhuis.info> Hi! Max Spevack schrieb: > [...] > I want to use the hour to completely go over the main deliverables for > Fedora 7, and get a sense of where everything is from a quality and > readiness perspective. And in an effort to make sure that the Board isn't > passing judgement on topics that should be handled at a "lower" level, I'd > like to make sure that some of the other leaders of major F7 areas are > around. This is probably something a bit more for FESCo, but well, if F7 as a whole gets discussed it might be worth discussing this for two or three minutes (not more, as the merge reviews will be stopped soon after test4 until F7 anyway iirc). I noticed that there were some merge reviews comments today like this: https://www.redhat.com/archives/fedora-package-review/2007-April/msg00988.html (Just look at the five or six before it by clicking on "Date Prev" -- those are similar). E.g. the reviewer gives up due to lack of replies from the Core maintainers of said packages. Should we do something about that and poke said maintainers somehow with a stick ;-) so they cooperate more when the merge reviews continue after F7? CU thl From gdk at redhat.com Tue Apr 10 18:43:51 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Tue, 10 Apr 2007 14:43:51 -0400 (EDT) Subject: cross-site bug tracking In-Reply-To: <1176224048.3069.30.camel@localhost.localdomain> References: <1176224048.3069.30.camel@localhost.localdomain> Message-ID: On Tue, 10 Apr 2007, Christopher Blizzard wrote: > Some good comments and questions from the desktop-arch list. Worth > thinking about as Fedora is one of the few places that has to bridge > between itself and a huge number of upstream projects and at the same > time have a commitment to free software for our infrastructure as well > as what we distribute. > > Thoughts? (For the record, before it's mentioned, re-implement > Launchpad as free software is not a solution, I suspect. We can do > something with the rest of the free software community that everyone > could adopt if we try and solve it the right way.) > > --Chris You all know my thoughts on this -- but to recap: 1. Get engaged with the xmlrpc work that's going on in upstream bugzilla. Make sure it's good. That takes care of the transport layer. 2. Work to get OpenID support into upstream bugzilla. That takes care of the authentication layer. 3. Work on the web UI to implement the "send this bug to another instance of bugzilla". That takes care of the interface layer. That's the winning strategy, I think. The question is, who has the time to implement, or to oversee implementation? FWIW, I think it's pretty strategic, and a lot of these pieces are already happening, so it's probably a matter of someone doing a strong design exercise -- but my hands are full elsewhere. --g -- Greg DeKoenigsberg Community Development Manager Red Hat, Inc. :: 1-919-754-4255 "To whomsoever much hath been given... ...from him much shall be asked" From laroche at redhat.com Tue Apr 10 18:51:13 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 10 Apr 2007 20:51:13 +0200 Subject: Board Meeting Tuesday April 10 In-Reply-To: <461BCAF4.5010602@leemhuis.info> References: <461BCAF4.5010602@leemhuis.info> Message-ID: <20070410185113.GB18876@dudweiler.stuttgart.redhat.com> > I noticed that there were some merge reviews comments today like this: > https://www.redhat.com/archives/fedora-package-review/2007-April/msg00988.html > (Just look at the five or six before it by clicking on "Date Prev" -- > those are similar). E.g. the reviewer gives up due to lack of replies > from the Core maintainers of said packages. Should we do something about > that and poke said maintainers somehow with a stick ;-) so they > cooperate more when the merge reviews continue after F7? I noticed that many reports stay assigned to nobody at fp.org. Normally we heavily depend on assignment of bugzillas to individual people. Only few people query bz by components. regards, Florian La Roche From rdieter at math.unl.edu Tue Apr 10 18:59:40 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 10 Apr 2007 13:59:40 -0500 Subject: Board Meeting Tuesday April 10 In-Reply-To: <20070410185113.GB18876@dudweiler.stuttgart.redhat.com> References: <461BCAF4.5010602@leemhuis.info> <20070410185113.GB18876@dudweiler.stuttgart.redhat.com> Message-ID: <461BDE9C.1040001@math.unl.edu> Florian La Roche wrote: > I noticed that many reports stay assigned to nobody at fp.org. > Normally we heavily depend on assignment of bugzillas to > individual people. Only few people query bz by components. afaik, (for better or worse) all(most?) the automated merge reviews initially are/were assigned to nobody. -- Rex From lmacken at redhat.com Tue Apr 10 20:53:21 2007 From: lmacken at redhat.com (Luke Macken) Date: Tue, 10 Apr 2007 16:53:21 -0400 Subject: cross-site bug tracking In-Reply-To: References: <1176224048.3069.30.camel@localhost.localdomain> Message-ID: <20070410205321.GH5871@tomservo.rh.rit.edu> On Tue, Apr 10, 2007 at 02:43:51PM -0400, Greg Dekoenigsberg wrote: > You all know my thoughts on this -- but to recap: > > 1. Get engaged with the xmlrpc work that's going on in upstream bugzilla. > Make sure it's good. That takes care of the transport layer. > > 2. Work to get OpenID support into upstream bugzilla. That takes care of > the authentication layer. > > 3. Work on the web UI to implement the "send this bug to another instance > of bugzilla". That takes care of the interface layer. > > That's the winning strategy, I think. The question is, who has the time > to implement, or to oversee implementation? > > FWIW, I think it's pretty strategic, and a lot of these pieces are already > happening, so it's probably a matter of someone doing a strong design > exercise -- but my hands are full elsewhere. +1 Bugzilla hacker Max Kanat-Alexander has been offering to help us maintain our own Bugzilla instance for a while now. Will would know better than I, but from what I've heard there is internal resistance to push forward with this due to the added overhead of having to deal with yet *another* Bugzilla instance. If we implement what Greg mentioned above, the issue of dealing with another Bugzilla instance essentially becomes irrelevant. luke From tcallawa at redhat.com Tue Apr 10 21:08:20 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 10 Apr 2007 16:08:20 -0500 Subject: cross-site bug tracking In-Reply-To: <20070410205321.GH5871@tomservo.rh.rit.edu> References: <1176224048.3069.30.camel@localhost.localdomain> <20070410205321.GH5871@tomservo.rh.rit.edu> Message-ID: <1176239300.3970.91.camel@localhost.localdomain> On Tue, 2007-04-10 at 16:53 -0400, Luke Macken wrote: > On Tue, Apr 10, 2007 at 02:43:51PM -0400, Greg Dekoenigsberg wrote: > > You all know my thoughts on this -- but to recap: > > > > 1. Get engaged with the xmlrpc work that's going on in upstream bugzilla. > > Make sure it's good. That takes care of the transport layer. > > > > 2. Work to get OpenID support into upstream bugzilla. That takes care of > > the authentication layer. > > > > 3. Work on the web UI to implement the "send this bug to another instance > > of bugzilla". That takes care of the interface layer. > > > > That's the winning strategy, I think. The question is, who has the time > > to implement, or to oversee implementation? > > > > FWIW, I think it's pretty strategic, and a lot of these pieces are already > > happening, so it's probably a matter of someone doing a strong design > > exercise -- but my hands are full elsewhere. > > +1 > > Bugzilla hacker Max Kanat-Alexander has been offering to help us > maintain our own Bugzilla instance for a while now. Will would know > better than I, but from what I've heard there is internal resistance to > push forward with this due to the added overhead of having to deal with > yet *another* Bugzilla instance. > > If we implement what Greg mentioned above, the issue of dealing with > another Bugzilla instance essentially becomes irrelevant. I've been working on getting all of the perl bits into Fedora to support the latest Bugzilla codebase. Several of them still need a review: perl-Email-Send [234791] \ perl-Email-Abstract [234790] perl-Email-Reply [234787] \ perl-Email-MIME-Creator [234786] \\ perl-Email-Simple-Creator [234785] \\\ perl-Email-Date [234784] ~spot From luis at tieguy.org Tue Apr 10 21:20:23 2007 From: luis at tieguy.org (Luis Villa) Date: Tue, 10 Apr 2007 17:20:23 -0400 Subject: cross-site bug tracking In-Reply-To: <20070410205321.GH5871@tomservo.rh.rit.edu> References: <1176224048.3069.30.camel@localhost.localdomain> <20070410205321.GH5871@tomservo.rh.rit.edu> Message-ID: <2cb10c440704101420j43fd246avf9e633119ee175e8@mail.gmail.com> On 4/10/07, Luke Macken wrote: > On Tue, Apr 10, 2007 at 02:43:51PM -0400, Greg Dekoenigsberg wrote: > > You all know my thoughts on this -- but to recap: > > > > 1. Get engaged with the xmlrpc work that's going on in upstream bugzilla. > > Make sure it's good. That takes care of the transport layer. > > > > 2. Work to get OpenID support into upstream bugzilla. That takes care of > > the authentication layer. > > > > 3. Work on the web UI to implement the "send this bug to another instance > > of bugzilla". That takes care of the interface layer. Yeah, so all that leaves is, uh, policy, strategy, maintenance... So, for example: 1) bug gets filed in fedora bugzilla against package foo 2) copy goes to RHEL bugzilla and to upstream project foo, which is also using the latest, greatest, up-to-date bugzilla. (Highly unlikely, but we can hope.) 3) foo fixes the bug in CVS and the bug is marked fixed. 4) foo's bugzilla notifies fedora bugzilla that the bug is fixed. 5) ________________ 6) profit! About step (5). Does Fedora also automatically mark it fixed? Do they wait until the fix hits a tarball? (How do they know when it hits a tarball?) Does RHEL mark it fixed? What about other derivatives? What happens if the problem originated in RHEL instead of Fedora? These questions are difficult to answer, and the least-bad answers are very labor intensive. I'm not a big fan of Launchpad (proprietary[1] and the UI is terrible), but I think aseigo is probably right- this doesn't get solved in anything more than a very, very labor-intensive way until there is a distributed bug system which is tightly tied to a distributed revision control system- conceptually, some combination of launchpad and rpath. Until then, the payoff for working hard on this is (IMHO) likely to be very low for Fedora, because no one will do the extra labor necessary to make it useful. It won't harm anyone to have a more up-to-date bugzilla with openid and good inter-bugzilla transport mechanisms, but my sense is that no one should hold their breaths expecting it to solve substantial problems for Fedora. Luis [1] Don't get me started on how angry Shuttleworth's hypocrisy makes me... From mspevack at redhat.com Wed Apr 11 00:56:37 2007 From: mspevack at redhat.com (Max Spevack) Date: Tue, 10 Apr 2007 20:56:37 -0400 (EDT) Subject: the all IRC Board meeting Message-ID: What did people think? Good, bad, too slow, not enough detail? Should we keep doing it this way, and only have Board phone calls for the issues that absolutely can't be discussed on IRC? Looking for feedback, because I really want this stuff to run in a way that makes both the Board members and the community happy. My personal opinion -- we covered a decent amount of ground, though it did take 90 minutes instead of an hour, but there was a lot of participation that otherwise wouldn't happen. It felt more like a mini version of the Fedora Summit that we had last year in Boston and on IRC. --Max From notting at redhat.com Wed Apr 11 00:57:19 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 10 Apr 2007 20:57:19 -0400 Subject: the all IRC Board meeting In-Reply-To: References: Message-ID: <20070411005719.GA7206@nostromo.devel.redhat.com> Max Spevack (mspevack at redhat.com) said: > What did people think? Good, bad, too slow, not enough detail? Should we > keep doing it this way, and only have Board phone calls for the issues > that absolutely can't be discussed on IRC? > > Looking for feedback, because I really want this stuff to run in a way > that makes both the Board members and the community happy. Good: - enabled easily pulling in other people as needed - very effective for getting status of various things Bad: - runs much slower - I'm not sure we actually *decided* anything For things where we're polling for the status of various projects, I think it's highly appropriate. For things where we need to stick our heads together and decide stuff, I'm not so sure. Bill From mmcgrath at redhat.com Wed Apr 11 01:08:52 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 10 Apr 2007 20:08:52 -0500 Subject: the all IRC Board meeting In-Reply-To: <20070411005719.GA7206@nostromo.devel.redhat.com> References: <20070411005719.GA7206@nostromo.devel.redhat.com> Message-ID: <461C3524.80907@redhat.com> Bill Nottingham wrote: > Good: > > - enabled easily pulling in other people as needed > - very effective for getting status of various things > > Bad: > > - runs much slower > - I'm not sure we actually *decided* anything > > For things where we're polling for the status of various projects, > I think it's highly appropriate. For things where we need to stick > our heads together and decide stuff, I'm not so sure. > Agreed, it seemed very... busy. Maybe if this is done again by the board they could do an IRC meeting where talking is by invitation only. I have no idea how to do that but I've seen the freenode ops do it before. It may be more trouble then its worth but as long as everyone is given proper channels to communicate, like notification before the meeting or some such thing, I think others would be fine with it. -Mike From a.badger at gmail.com Wed Apr 11 02:27:55 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 10 Apr 2007 19:27:55 -0700 Subject: the all IRC Board meeting In-Reply-To: <461C3524.80907@redhat.com> References: <20070411005719.GA7206@nostromo.devel.redhat.com> <461C3524.80907@redhat.com> Message-ID: <1176258475.30783.148.camel@localhost.localdomain> On Tue, 2007-04-10 at 20:08 -0500, Mike McGrath wrote: > Bill Nottingham wrote: > > Good: > > > > - enabled easily pulling in other people as needed > > - very effective for getting status of various things > > > > Bad: > > > > - runs much slower > > - I'm not sure we actually *decided* anything > > > > For things where we're polling for the status of various projects, > > I think it's highly appropriate. For things where we need to stick > > our heads together and decide stuff, I'm not so sure. > > > Agreed, it seemed very... busy. Maybe if this is done again by the > board they could do an IRC meeting where talking is by invitation only. > I have no idea how to do that but I've seen the freenode ops do it > before. It may be more trouble then its worth but as long as everyone > is given proper channels to communicate, like notification before the > meeting or some such thing, I think others would be fine with it. > FWIW, I think this meeting was a great success in terms of communication between the Board and the community. I'd rather see a mixture of both types of meetings rather than limiting voice as I think there's a need for open community feedback sometimes as well as (I'm interpolating from the "Bad" points above here) speedy decision making. Perhaps one meeting a month could be held this way? The "actually decided" criticism might be a bit too harsh. There's two points I'd like to make: 1) I don't know whether that was inherent in the medium or not. In the Packaging Committee meetings spot sometimes has to say "Let's vote on this now. [Item to vote on]". This breaks into ongoing discussions but helps to define where we are at the moment and if there's a clear majority with no quibbling (+/-0.5 and +0 votes), it becomes apparent that although we won't reach consensus we've already made a decision and need to move on. For the board, where action items seem to predominate, maybe someone needs to break in when they think an impasse has been reached and say "This is where I think we're at. How about PersonA does this by next meeting to further our understanding of the issue?" 2) In that vein, my review of the meeting log finds these action items: Merged Infrastructure: f13 and mmcgrath: - Test the builders in high load situations and decide what HW to buy by Friday. - Status report and preliminary estimate of where we'll be by F7 release by next week's Board Meeting. Revisor: jeremy, kanarip, daMaestro, BobJensen: - Meet tomorrow to try to find the best way for revisor to include livecd functionality. LiveDVD: (I assumed that mspevack was doing this but could be wrong): - Get the spin and art to the DVD producers in California by early next week. jeremy: Make the liveCD kickstart available later today. KDE spin: rdieter: To send f13 a list of packages that need to be commitable by the community. f3: To evaluate and hopefully implement a way to do that by tomorrow. Docs: f13: will take a snapshot of the release notes after the translators are done on the 14th. -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 skvidal at linux.duke.edu Wed Apr 11 03:09:37 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 10 Apr 2007 23:09:37 -0400 Subject: cross-site bug tracking In-Reply-To: <2cb10c440704101420j43fd246avf9e633119ee175e8@mail.gmail.com> References: <1176224048.3069.30.camel@localhost.localdomain> <20070410205321.GH5871@tomservo.rh.rit.edu> <2cb10c440704101420j43fd246avf9e633119ee175e8@mail.gmail.com> Message-ID: <1176260977.32458.102.camel@cutter> On Tue, 2007-04-10 at 17:20 -0400, Luis Villa wrote: > Yeah, so all that leaves is, uh, policy, strategy, maintenance... > > So, for example: > 1) bug gets filed in fedora bugzilla against package foo > 2) copy goes to RHEL bugzilla and to upstream project foo, which is > also using the latest, greatest, up-to-date bugzilla. (Highly > unlikely, but we can hope.) > 3) foo fixes the bug in CVS and the bug is marked fixed. > 4) foo's bugzilla notifies fedora bugzilla that the bug is fixed. > > 5) ________________ > > 6) profit! > > About step (5). Does Fedora also automatically mark it fixed? Do they > wait until the fix hits a tarball? (How do they know when it hits a > tarball?) Does RHEL mark it fixed? What about other derivatives? What > happens if the problem originated in RHEL instead of Fedora? These > questions are difficult to answer, and the least-bad answers are very > labor intensive. Except that even if the upstream project bugzilla just tells the fedora/rhel bugzillas that the bug is closed in upstream and what the resolution is in a comment it is still an improvement. It isn't robotic-bugzilla-army-of-doom perfect but it is MUCH better communication than before. > It won't harm anyone to have a more up-to-date bugzilla with openid > and good inter-bugzilla transport mechanisms, but my sense is that no > one should hold their breaths expecting it to solve substantial > problems for Fedora. See I think if we even just got it working for a couple of minor cases the movement would come along faster for later ones. ie: tie gnome bugzilla and fedora bugzilla together using it. mozilla and friends wouldn't be far behind, I bet. Then if launchpad could talk to the xmlrpc interface on bugzilla, too, that'd be great. but it's got to start small, somewhere, right? hell, if we want to be crazy make a separate fedora bugzilla and just tie it with red hat's. -sv From luis at tieguy.org Wed Apr 11 03:13:45 2007 From: luis at tieguy.org (Luis Villa) Date: Tue, 10 Apr 2007 23:13:45 -0400 Subject: cross-site bug tracking In-Reply-To: <1176260977.32458.102.camel@cutter> References: <1176224048.3069.30.camel@localhost.localdomain> <20070410205321.GH5871@tomservo.rh.rit.edu> <2cb10c440704101420j43fd246avf9e633119ee175e8@mail.gmail.com> <1176260977.32458.102.camel@cutter> Message-ID: <2cb10c440704102013i3fa42667na303323bc3d446e3@mail.gmail.com> On 4/10/07, seth vidal wrote: > On Tue, 2007-04-10 at 17:20 -0400, Luis Villa wrote: > > Yeah, so all that leaves is, uh, policy, strategy, maintenance... > > > > So, for example: > > 1) bug gets filed in fedora bugzilla against package foo > > 2) copy goes to RHEL bugzilla and to upstream project foo, which is > > also using the latest, greatest, up-to-date bugzilla. (Highly > > unlikely, but we can hope.) > > 3) foo fixes the bug in CVS and the bug is marked fixed. > > 4) foo's bugzilla notifies fedora bugzilla that the bug is fixed. > > > > 5) ________________ > > > > 6) profit! > > > > About step (5). Does Fedora also automatically mark it fixed? Do they > > wait until the fix hits a tarball? (How do they know when it hits a > > tarball?) Does RHEL mark it fixed? What about other derivatives? What > > happens if the problem originated in RHEL instead of Fedora? These > > questions are difficult to answer, and the least-bad answers are very > > labor intensive. > > Except that even if the upstream project bugzilla just tells the > fedora/rhel bugzillas that the bug is closed in upstream and what the > resolution is in a comment it is still an improvement. It isn't > robotic-bugzilla-army-of-doom perfect but it is MUCH better > communication than before. Yeah, it is definitely better than not communicating. > See I think if we even just got it working for a couple of minor cases > the movement would come along faster for later ones. > > ie: tie gnome bugzilla and fedora bugzilla together using it. I'm sure GNOME would be pretty happy to work together with you on it. The current talk of Ubuntu and Debian doing their own collection of GNOME stack traces just screams bad idea to me, at least until there is better communication between the trackers. And yes, that would at least be a start. Luis Luis From notting at redhat.com Wed Apr 11 03:13:34 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 10 Apr 2007 23:13:34 -0400 Subject: the all IRC Board meeting In-Reply-To: <1176258475.30783.148.camel@localhost.localdomain> References: <20070411005719.GA7206@nostromo.devel.redhat.com> <461C3524.80907@redhat.com> <1176258475.30783.148.camel@localhost.localdomain> Message-ID: <20070411031334.GA7698@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: > LiveDVD: > (I assumed that mspevack was doing this but could be wrong): > - Get the spin and art to the DVD producers in California by early > next week. > jeremy: Make the liveCD kickstart available later today. This was essentially Max stating what's being done - there was no discussion per-se. Other items: > KDE spin: > rdieter: To send f13 a list of packages that need to be commitable by > the community. > f3: To evaluate and hopefully implement a way to do that by tomorrow. > > Docs: > f13: will take a snapshot of the release notes after the translators are > done on the 14th. So... is it just me, or does it seem horribly wrong that this is being done at the *board* meeting? Shouldn't we be having release meetings for this sort of thing? It seems to me that much of the benefit of this meeting was merely getting various people (f13 + mmcgrath for build, katzj + the revisor people) in the same place to work through some issues. Maybe that's a function of this weeks agenda more than the meeting format. Bill From a.badger at gmail.com Wed Apr 11 03:38:37 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 10 Apr 2007 20:38:37 -0700 Subject: cross-site bug tracking In-Reply-To: <20070410205321.GH5871@tomservo.rh.rit.edu> References: <1176224048.3069.30.camel@localhost.localdomain> <20070410205321.GH5871@tomservo.rh.rit.edu> Message-ID: <1176262717.30783.153.camel@localhost.localdomain> On Tue, 2007-04-10 at 16:53 -0400, Luke Macken wrote: > On Tue, Apr 10, 2007 at 02:43:51PM -0400, Greg Dekoenigsberg wrote: > > You all know my thoughts on this -- but to recap: > > > > 1. Get engaged with the xmlrpc work that's going on in upstream bugzilla. > > Make sure it's good. That takes care of the transport layer. > > > > 2. Work to get OpenID support into upstream bugzilla. That takes care of > > the authentication layer. > > > > 3. Work on the web UI to implement the "send this bug to another instance > > of bugzilla". That takes care of the interface layer. > > > > That's the winning strategy, I think. The question is, who has the time > > to implement, or to oversee implementation? > > > > FWIW, I think it's pretty strategic, and a lot of these pieces are already > > happening, so it's probably a matter of someone doing a strong design > > exercise -- but my hands are full elsewhere. > > +1 > > Bugzilla hacker Max Kanat-Alexander has been offering to help us > maintain our own Bugzilla instance for a while now. Will would know > better than I, but from what I've heard there is internal resistance to > push forward with this due to the added overhead of having to deal with > yet *another* Bugzilla instance. > > If we implement what Greg mentioned above, the issue of dealing with > another Bugzilla instance essentially becomes irrelevant. I was against having another bugzilla on the grounds that Red Hat doesn't even have one full time bugzilla hacker (last time this came up. I don't know about now.) If we have some community members who are willing to maintain and hack on a fedora bugzilla then that changes my take on things. It would be great to have better bugzilla integration and if Fedora was part of driving development of that it would be even better. -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 skvidal at linux.duke.edu Wed Apr 11 04:37:06 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 11 Apr 2007 00:37:06 -0400 Subject: cross-site bug tracking In-Reply-To: <1176262717.30783.153.camel@localhost.localdomain> References: <1176224048.3069.30.camel@localhost.localdomain> <20070410205321.GH5871@tomservo.rh.rit.edu> <1176262717.30783.153.camel@localhost.localdomain> Message-ID: <1176266226.32458.117.camel@cutter> On Tue, 2007-04-10 at 20:38 -0700, Toshio Kuratomi wrote: > I was against having another bugzilla on the grounds that Red Hat > doesn't even have one full time bugzilla hacker (last time this came up. > I don't know about now.) If we have some community members who are > willing to maintain and hack on a fedora bugzilla then that changes my > take on things. It would be great to have better bugzilla integration > and if Fedora was part of driving development of that it would be even > better. > So it sounds like we have the beginnings of a plan here: 1. get a couple of xen instances setup for the base of the bugzillas for development of the xml-rpc communication layer. 2. see if we have anyone who wants to look at the coding for the xml-rpc communication 3. give the people in #2 access to #1 4. move forward as things are possible. does that make sense? -sv From jwboyer at jdub.homelinux.org Wed Apr 11 10:39:06 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 11 Apr 2007 05:39:06 -0500 Subject: the all IRC Board meeting In-Reply-To: <20070411031334.GA7698@nostromo.devel.redhat.com> References: <20070411005719.GA7206@nostromo.devel.redhat.com> <461C3524.80907@redhat.com> <1176258475.30783.148.camel@localhost.localdomain> <20070411031334.GA7698@nostromo.devel.redhat.com> Message-ID: <1176287947.4506.7.camel@vader.jdub.homelinux.org> On Tue, 2007-04-10 at 23:13 -0400, Bill Nottingham wrote: > Toshio Kuratomi (a.badger at gmail.com) said: > > LiveDVD: > > (I assumed that mspevack was doing this but could be wrong): > > - Get the spin and art to the DVD producers in California by early > > next week. > > jeremy: Make the liveCD kickstart available later today. > > This was essentially Max stating what's being done - there was no > discussion per-se. > > Other items: > > > KDE spin: > > rdieter: To send f13 a list of packages that need to be commitable by > > the community. > > f3: To evaluate and hopefully implement a way to do that by tomorrow. > > > > Docs: > > f13: will take a snapshot of the release notes after the translators are > > done on the 14th. > > So... is it just me, or does it seem horribly wrong that this is being > done at the *board* meeting? Shouldn't we be having release meetings > for this sort of thing? Yes, but Max wanted to go over the F7 deliverables in that meeting. This is one of them. I don't see it as a recurring theme. josh From jkeating at redhat.com Wed Apr 11 11:54:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Apr 2007 07:54:44 -0400 Subject: cross-site bug tracking In-Reply-To: <1176262717.30783.153.camel@localhost.localdomain> References: <1176224048.3069.30.camel@localhost.localdomain> <20070410205321.GH5871@tomservo.rh.rit.edu> <1176262717.30783.153.camel@localhost.localdomain> Message-ID: <200704110754.44874.jkeating@redhat.com> On Tuesday 10 April 2007 23:38:37 Toshio Kuratomi wrote: > I was against having another bugzilla on the grounds that Red Hat > doesn't even have one full time bugzilla hacker (last time this came up. > I don't know about now.) ?If we have some community members who are > willing to maintain and hack on a fedora bugzilla then that changes my > take on things. ?It would be great to have better bugzilla integration > and if Fedora was part of driving development of that it would be even > better. I was against it because of how closely our other Red Hat products work with the Fedora bugs. I think they work closely enough that even the best bugzilla linking software isn't going to make it as easy as things are today. I'm far more interested in making a custom Fedora landing page for our bugzilla and cleaning out all the accumulated cruft/versions/etc in our Fedora products, as well as clearing out all the things under Fedora that add to confusion. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Apr 11 11:56:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Apr 2007 07:56:43 -0400 Subject: the all IRC Board meeting In-Reply-To: <20070411031334.GA7698@nostromo.devel.redhat.com> References: <1176258475.30783.148.camel@localhost.localdomain> <20070411031334.GA7698@nostromo.devel.redhat.com> Message-ID: <200704110756.44030.jkeating@redhat.com> On Tuesday 10 April 2007 23:13:34 Bill Nottingham wrote: > So... is it just me, or does it seem horribly wrong that this is being > done at the *board* meeting? Shouldn't we be having release meetings > for this sort of thing? > > It seems to me that much of the benefit of this meeting was merely > getting various people (f13 + mmcgrath for build, katzj + the revisor > people) in the same place to work through some issues. Maybe that's > a function of this weeks agenda more than the meeting format. Not just you. My feeling is that these things should have been met and decided over, then reported by the right person during the Fedora Board meeting. Now, I'm not usually a fan of pre meeting meetings, but in this case.... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Apr 11 12:29:10 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 11 Apr 2007 14:29:10 +0200 Subject: the all IRC Board meeting In-Reply-To: <200704110756.44030.jkeating@redhat.com> References: <1176258475.30783.148.camel@localhost.localdomain> <20070411031334.GA7698@nostromo.devel.redhat.com> <200704110756.44030.jkeating@redhat.com> Message-ID: <461CD496.2050205@leemhuis.info> On 11.04.2007 13:56, Jesse Keating wrote: > On Tuesday 10 April 2007 23:13:34 Bill Nottingham wrote: >> So... is it just me, or does it seem horribly wrong that this is being >> done at the *board* meeting? Shouldn't we be having release meetings >> for this sort of thing? >> It seems to me that much of the benefit of this meeting was merely >> getting various people (f13 + mmcgrath for build, katzj + the revisor >> people) in the same place to work through some issues. Maybe that's >> a function of this weeks agenda more than the meeting format. > Not just you. My feeling is that these things should have been met and > decided over, +1 > then reported by the right person during the Fedora Board > meeting. Now, I'm not usually a fan of pre meeting meetings, but in this > case.... Correct me if I'm wrong, but I'd say most of those things are engineering tasks that would have been dealed by the Core Cabal in the past. So these things maybe should be discussed in "pre meeting meetings" (e.g. Live-CD meeting, release team meeting) and then reported to the Core Cabal successor, which is FESCO, and not the Board. Of course the Board is free to get involved in those Live-CD/release team/FESCo meeting if it's a big picture task where the Board is interested in helping getting it done; or even bring it up in a Board meeting itself if needed. CU thl From jkeating at redhat.com Wed Apr 11 13:13:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Apr 2007 09:13:15 -0400 Subject: the all IRC Board meeting In-Reply-To: <461CD496.2050205@leemhuis.info> References: <200704110756.44030.jkeating@redhat.com> <461CD496.2050205@leemhuis.info> Message-ID: <200704110913.15669.jkeating@redhat.com> On Wednesday 11 April 2007 08:29:10 Thorsten Leemhuis wrote: > Correct me if I'm wrong, but I'd say most of those things are > engineering tasks that would have been dealed by the Core Cabal in the > past. So these things maybe should be discussed in "pre meeting > meetings" (e.g. Live-CD meeting, release team meeting) and then reported > to the Core Cabal successor, which is FESCO, and not the Board. > > Of course the Board is free to get involved in those Live-CD/release > team/FESCo meeting if it's a big picture task where the Board is > interested in helping getting it done; or even bring it up in a Board > meeting itself if needed. Sure, whatever. Seems a bit silly to repeat the same report to multiple places, but... maybe we can find better ways of getting this information spread around. -- 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 Wed Apr 11 14:49:11 2007 From: mspevack at redhat.com (Max Spevack) Date: Wed, 11 Apr 2007 10:49:11 -0400 (EDT) Subject: the all IRC Board meeting In-Reply-To: <200704110913.15669.jkeating@redhat.com> References: <200704110756.44030.jkeating@redhat.com> <461CD496.2050205@leemhuis.info> <200704110913.15669.jkeating@redhat.com> Message-ID: On Wed, 11 Apr 2007, Jesse Keating wrote: >> Of course the Board is free to get involved in those Live-CD/release >> team/FESCo meeting if it's a big picture task where the Board is >> interested in helping getting it done; or even bring it up in a Board >> meeting itself if needed. > > Sure, whatever. Seems a bit silly to repeat the same report to multiple > places, but... maybe we can find better ways of getting this information > spread around. I guess my purpose in yesterday was that I felt like all the topics I brought up were ones in which I *personally* wasn't 100% sure that sufficient progress or communication was being made. Maybe that was just me being behind on email -- but I don't think it's out of line to sit down 6 weeks before the release and say "ok, we've got all the leaders of various sub-groups more or less in the same place. Let's go down the list and try to touch on everything." If I go around and personally ask the KDE spin guys about that, and Jesse/Jeremy/Mike about the build system, and do the Summit DVD stuff myself, then things get done, but information doesn't really flow. Or I could go to the IRC meeting for each of those groups and spend my whole week in chat rooms. Neither option seems particulalry good. My goal with yesterday's meeting was to get the general status of all things F7 out there for everyone to be at a pretty similar baseline, and allow people to talk out their issues in one place. Basically it was a big Engineering Status Meeting, that we used the Board meeting time for. -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From kwade at redhat.com Wed Apr 11 15:21:27 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 11 Apr 2007 08:21:27 -0700 Subject: the all IRC Board meeting In-Reply-To: References: <200704110756.44030.jkeating@redhat.com> <461CD496.2050205@leemhuis.info> <200704110913.15669.jkeating@redhat.com> Message-ID: <1176304887.5208.50.camel@erato.phig.org> On Wed, 2007-04-11 at 10:49 -0400, Max Spevack wrote: > Basically it was a big Engineering Status Meeting, that we used the Board > meeting time for. How about a monthly one of these that doesn't tie up a Board meeting? All together on IRC at one time, for the reasons stated. We could schedule three or four of them in advance, which increases the chances that most leaders will be there. The thing I like about a meeting is the chance to get an interactive distillation of important issues from people who are paying attention to them. Something at this level is too much to do very often, so monthly, and maybe twice a month once we enter testing cycle. - 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 blizzard at redhat.com Wed Apr 11 14:05:22 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 11 Apr 2007 10:05:22 -0400 Subject: cross-site bug tracking In-Reply-To: <2cb10c440704102013i3fa42667na303323bc3d446e3@mail.gmail.com> References: <1176224048.3069.30.camel@localhost.localdomain> <20070410205321.GH5871@tomservo.rh.rit.edu> <2cb10c440704101420j43fd246avf9e633119ee175e8@mail.gmail.com> <1176260977.32458.102.camel@cutter> <2cb10c440704102013i3fa42667na303323bc3d446e3@mail.gmail.com> Message-ID: <1176300322.12574.1.camel@localhost.localdomain> On Tue, 2007-04-10 at 23:13 -0400, Luis Villa wrote: > I'm sure GNOME would be pretty happy to work together with you on it. > The current talk of Ubuntu and Debian doing their own collection of > GNOME stack traces just screams bad idea to me, at least until there > is better communication between the trackers. And yes, that would at > least be a start. More info on that? I'm happy with collecting stack traces and I also believe that trying to open one bug per stack trace is a nightmare to triage. Wondering what form they were looking at? --Chris From blizzard at redhat.com Wed Apr 11 14:12:34 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 11 Apr 2007 10:12:34 -0400 Subject: cross-site bug tracking In-Reply-To: <2cb10c440704101420j43fd246avf9e633119ee175e8@mail.gmail.com> References: <1176224048.3069.30.camel@localhost.localdomain> <20070410205321.GH5871@tomservo.rh.rit.edu> <2cb10c440704101420j43fd246avf9e633119ee175e8@mail.gmail.com> Message-ID: <1176300754.12574.9.camel@localhost.localdomain> On Tue, 2007-04-10 at 17:20 -0400, Luis Villa wrote: > About step (5). Does Fedora also automatically mark it fixed? Do they > wait until the fix hits a tarball? (How do they know when it hits a > tarball?) Does RHEL mark it fixed? What about other derivatives? What > happens if the problem originated in RHEL instead of Fedora? These > questions are difficult to answer, and the least-bad answers are very > labor intensive. > > I'm not a big fan of Launchpad (proprietary[1] and the UI is > terrible), but I think aseigo is probably right- this doesn't get > solved in anything more than a very, very labor-intensive way until > there is a distributed bug system which is tightly tied to a > distributed revision control system- conceptually, some combination of > launchpad and rpath. Until then, the payoff for working hard on this > is (IMHO) likely to be very low for Fedora, because no one will do the > extra labor necessary to make it useful. > > It won't harm anyone to have a more up-to-date bugzilla with openid > and good inter-bugzilla transport mechanisms, but my sense is that no > one should hold their breaths expecting it to solve substantial > problems for Fedora. > > Luis > > [1] Don't get me started on how angry Shuttleworth's hypocrisy makes me... A little pontificating, sorry: Over time I've become less and less of a fan of bugzilla. Mostly because people see it as a hammer for all their nails: bug fixing, task assignment, customer defect resolution and even release management. I think that other than "here's the issues that as a developer I know I need to fix" it does a crappy job. So for me, it's a question of leadership in this area to lead everyone to something that just plain works better. In my head I see a collection of tools. If you're a release manager, you can see what the state of a release is. If a program crashes it goes into a repo for program crashes which can be mined for data (see mozilla topcrashes.) Some of this is "better views of data" - i.e. different views of bugzilla data - but I really believe that adding workflow that isn't just flags on bugs is a great first step. Bugzilla has been around a long time, and it's served itself pretty well. But I think that you've hit it right on the head there. That connecting defects to source control and letting fixes flow between projects is important. But no one has taken that first step to say "we're going to go out and try to make this happen." Should it be us? Does Red Hat want to fund it? (Based on the history of ownership of both our internal and external tools, the answer is probably no.) Can we organize a community around solving that problem? It's hard, since everyone has their own vision of what it should be, and very often it's "bugzilla, with even more stuff on top!" And things don't really move. It's hard to know what the next step is. But I would love to hear more ideas. --Chris From luis at tieguy.org Wed Apr 11 22:38:14 2007 From: luis at tieguy.org (Luis Villa) Date: Wed, 11 Apr 2007 18:38:14 -0400 Subject: cross-site bug tracking In-Reply-To: <1176300322.12574.1.camel@localhost.localdomain> References: <1176224048.3069.30.camel@localhost.localdomain> <20070410205321.GH5871@tomservo.rh.rit.edu> <2cb10c440704101420j43fd246avf9e633119ee175e8@mail.gmail.com> <1176260977.32458.102.camel@cutter> <2cb10c440704102013i3fa42667na303323bc3d446e3@mail.gmail.com> <1176300322.12574.1.camel@localhost.localdomain> Message-ID: <2cb10c440704111538s3edab8b4p97d404978026d50f@mail.gmail.com> On 4/11/07, Christopher Blizzard wrote: > On Tue, 2007-04-10 at 23:13 -0400, Luis Villa wrote: > > I'm sure GNOME would be pretty happy to work together with you on it. > > The current talk of Ubuntu and Debian doing their own collection of > > GNOME stack traces just screams bad idea to me, at least until there > > is better communication between the trackers. And yes, that would at > > least be a start. > > More info on that? Discussion here: http://mail.gnome.org/archives/desktop-devel-list/2007-April/msg00068.html I don't know any details. > I'm happy with collecting stack traces Frankly, I don't trust distros to get the relevant information upstream, so I think GNOME is a better place to collect the traces than Ubuntu/Debian/Fedora. > and I also > believe that trying to open one bug per stack trace is a nightmare to > triage. Agreed; GNOME is trying to move to the google/mozilla backend for that, but it will be a bit before that happens. > Wondering what form they were looking at? Not sure what form you're referring to. Luis From luis at tieguy.org Wed Apr 11 22:49:29 2007 From: luis at tieguy.org (Luis Villa) Date: Wed, 11 Apr 2007 18:49:29 -0400 Subject: cross-site bug tracking In-Reply-To: <1176300754.12574.9.camel@localhost.localdomain> References: <1176224048.3069.30.camel@localhost.localdomain> <20070410205321.GH5871@tomservo.rh.rit.edu> <2cb10c440704101420j43fd246avf9e633119ee175e8@mail.gmail.com> <1176300754.12574.9.camel@localhost.localdomain> Message-ID: <2cb10c440704111549n50ad94dbu260dbaa6072cacbd@mail.gmail.com> On 4/11/07, Christopher Blizzard wrote: > A little pontificating, sorry: Over time I've become less and less of a > fan of bugzilla. Mostly because people see it as a hammer for all their > nails: bug fixing, task assignment, customer defect resolution and even > release management. I think that other than "here's the issues that as > a developer I know I need to fix" it does a crappy job. Agree. In particular, bugzilla flags are the most horrible kludge in the history of UI kludges. And even for developers, it is only a least-bad option, like democracy or capitalism. > connecting defects to source control and letting fixes flow between > projects is important. But no one has taken that first step to say > "we're going to go out and try to make this happen." Well, Canonical has. I think their execution has been poor, but they have had the right vision for several years now. > Should it be us? Does Red Hat want to fund it? (Based on the history > of ownership of both our internal and external tools, the answer is > probably no.) Can we organize a community around solving that problem? > It's hard, since everyone has their own vision of what it should be, and > very often it's "bugzilla, with even more stuff on top!" And things > don't really move. It's hard to know what the next step is. But I > would love to hear more ideas. My random-ass-guess? If you want traction, talk to the kernel people. They have achieved agreement on an RCS, and appear to be reaching a consensus that bug tracking is important (I hear talk that they are hiring a bugmaster.) Tying bug tracking into git (git bisect-submit!) is an obvious next step for them, and bugzilla is even more completely broken for them than it is for anyone else. No other big community has made the full jump to a modern distributed RCS yet; my sense is that this is a prereq for modern bugtracking. So start there. (I think GNOME would be happy to switch away from bugzilla to something distributed, but has ~ 0 manpower to write the tool in the first place. You obviously know mozilla better than I do, but I'd be shocked if they are ready to move away from bugzilla- too tied into it.) Luis From kwade at redhat.com Thu Apr 12 00:27:49 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 11 Apr 2007 17:27:49 -0700 Subject: cross-site bug tracking In-Reply-To: <1176300754.12574.9.camel@localhost.localdomain> References: <1176224048.3069.30.camel@localhost.localdomain> <20070410205321.GH5871@tomservo.rh.rit.edu> <2cb10c440704101420j43fd246avf9e633119ee175e8@mail.gmail.com> <1176300754.12574.9.camel@localhost.localdomain> Message-ID: <1176337669.5208.134.camel@erato.phig.org> On Wed, 2007-04-11 at 10:12 -0400, Christopher Blizzard wrote: > Should it be us? Does Red Hat want to fund it? (Based on the history > of ownership of both our internal and external tools, the answer is > probably no.) Which "us" is that? Fedora can have successes and lead the way for Red Hat + more, and we can learn to do it in ways that don't scare the pants off people (although thrill-the-pants-off would be fine.) Can Fedora take this on? - 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 Apr 12 00:39:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Apr 2007 20:39:56 -0400 Subject: cross-site bug tracking In-Reply-To: <2cb10c440704111549n50ad94dbu260dbaa6072cacbd@mail.gmail.com> References: <1176224048.3069.30.camel@localhost.localdomain> <1176300754.12574.9.camel@localhost.localdomain> <2cb10c440704111549n50ad94dbu260dbaa6072cacbd@mail.gmail.com> Message-ID: <200704112040.00495.jkeating@redhat.com> On Wednesday 11 April 2007 18:49:29 Luis Villa wrote: > No other big community has made the full jump to a modern distributed > RCS yet; my sense is that this is a prereq for modern bugtracking. So > start there. We've looked at it and I've done a lot of research and talking to people. The solution I came up with was that I don't want to switch SCMs because there are new options out there, and build up a workflow around an SCM. I want to see a new workflow imagined for our operating system development and taking that wishful workflow and seeing which of the now available SCMs happen to work for that workflow or can be adapted. Switching just to switch is not interesting. Finding a new ideal workflow, which should include things like bug / defect management, feature tracking, distribution status, project management, etc... and building up tools around that workflow is. I also don't want to do it this release, nor next, with all the other changes we've got going on. However we can start dreaming 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 matt at domsch.com Thu Apr 12 00:49:41 2007 From: matt at domsch.com (Matt Domsch) Date: Wed, 11 Apr 2007 19:49:41 -0500 Subject: LWN headline: Blame Fedora = High Praise Message-ID: <461D8225.4050907@domsch.com> Check out LWN.net for today's weekly edition. Subscribers (and I do encourage folks to subscribe) will find it interesting. Non-subscribers should look at this: http://lwn.net/SubscriberLink/230042/5181766fe793aa6b/ From luis at tieguy.org Thu Apr 12 00:53:30 2007 From: luis at tieguy.org (Luis Villa) Date: Wed, 11 Apr 2007 20:53:30 -0400 Subject: cross-site bug tracking In-Reply-To: <200704112040.00495.jkeating@redhat.com> References: <1176224048.3069.30.camel@localhost.localdomain> <1176300754.12574.9.camel@localhost.localdomain> <2cb10c440704111549n50ad94dbu260dbaa6072cacbd@mail.gmail.com> <200704112040.00495.jkeating@redhat.com> Message-ID: <2cb10c440704111753o6764dbf8ke533156573f2e46a@mail.gmail.com> On 4/11/07, Jesse Keating wrote: > Switching just to switch is not interesting. Finding a new ideal workflow, > which should include things like bug / defect management, feature tracking, > distribution status, project management, etc... and building up tools around > that workflow is. Of course. Not just 'interesting', though. Well more than 'interesting'. It seems obvious to me (from my experience at Novell) that having such a workflow will be a major competitive advantage for whatever distro achieves it first and gets buyin to the workflow from major upstream providers. [And yes, despite their execution problems, Canonical has a two year head start on this. That should scare RH Corporate as much or more so than anything else Canonical is doing.] Luis From jkeating at redhat.com Thu Apr 12 01:17:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Apr 2007 21:17:06 -0400 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <461D8225.4050907@domsch.com> References: <461D8225.4050907@domsch.com> Message-ID: <200704112117.06856.jkeating@redhat.com> On Wednesday 11 April 2007 20:49:41 Matt Domsch wrote: > ? ? Check out LWN.net for today's weekly edition. ?Subscribers (and I do > encourage folks to subscribe) will find it interesting. ?Non-subscribers > should look at this: > http://lwn.net/SubscriberLink/230042/5181766fe793aa6b/ Interesting read! -- 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 Apr 12 02:18:07 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 11 Apr 2007 22:18:07 -0400 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <461D8225.4050907@domsch.com> References: <461D8225.4050907@domsch.com> Message-ID: <1176344287.13177.23.camel@cutter> On Wed, 2007-04-11 at 19:49 -0500, Matt Domsch wrote:b > Check out LWN.net for today's weekly edition. Subscribers (and I do > encourage folks to subscribe) will find it interesting. Non-subscribers > should look at this: > http://lwn.net/SubscriberLink/230042/5181766fe793aa6b/ lwn not abusing fedora. reality slipping sideways bizarro-world coming into focus down is up left is right :) A good read, thanks, -sv From kwade at redhat.com Thu Apr 12 02:20:04 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 11 Apr 2007 19:20:04 -0700 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <1176344287.13177.23.camel@cutter> References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> Message-ID: <1176344404.5208.155.camel@erato.phig.org> On Wed, 2007-04-11 at 22:18 -0400, seth vidal wrote: > A good read, thanks, Note the implied "call to action" for Fedora to *do* something about people not understanding what we are about. I'll bounce this article to f-marketing-l and we can take up the discussion of that challenge over there. - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mmcgrath at redhat.com Thu Apr 12 02:25:33 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 11 Apr 2007 21:25:33 -0500 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <1176344404.5208.155.camel@erato.phig.org> References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> Message-ID: <461D989D.5060201@redhat.com> Karsten Wade wrote: > > Note the implied "call to action" for Fedora to *do* something about > people not understanding what we are about. > I really believe separating our content into end user (CMS) and developer content (wiki) will help this. Coordination on the CMS will help maintain a constant message. It's coming, I swear! -Mike From jwboyer at jdub.homelinux.org Thu Apr 12 10:40:46 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 12 Apr 2007 05:40:46 -0500 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <1176344287.13177.23.camel@cutter> References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> Message-ID: <1176374447.25283.0.camel@vader.jdub.homelinux.org> On Wed, 2007-04-11 at 22:18 -0400, seth vidal wrote: > On Wed, 2007-04-11 at 19:49 -0500, Matt Domsch wrote:b > > Check out LWN.net for today's weekly edition. Subscribers (and I do > > encourage folks to subscribe) will find it interesting. Non-subscribers > > should look at this: > > http://lwn.net/SubscriberLink/230042/5181766fe793aa6b/ > > lwn not abusing fedora. > reality slipping sideways > bizarro-world coming into focus > > down is up > left is right Just remember, the enemy's gate is down. ;) josh From gdk at redhat.com Thu Apr 12 14:50:55 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Thu, 12 Apr 2007 10:50:55 -0400 (EDT) Subject: cross-site bug tracking In-Reply-To: <2cb10c440704111549n50ad94dbu260dbaa6072cacbd@mail.gmail.com> References: <1176224048.3069.30.camel@localhost.localdomain> <20070410205321.GH5871@tomservo.rh.rit.edu> <2cb10c440704101420j43fd246avf9e633119ee175e8@mail.gmail.com> <1176300754.12574.9.camel@localhost.localdomain> <2cb10c440704111549n50ad94dbu260dbaa6072cacbd@mail.gmail.com> Message-ID: On Wed, 11 Apr 2007, Luis Villa wrote: > On 4/11/07, Christopher Blizzard wrote: >> A little pontificating, sorry: Over time I've become less and less of a >> fan of bugzilla. Mostly because people see it as a hammer for all their >> nails: bug fixing, task assignment, customer defect resolution and even >> release management. I think that other than "here's the issues that as >> a developer I know I need to fix" it does a crappy job. > > Agree. In particular, bugzilla flags are the most horrible kludge in > the history of UI kludges. > > And even for developers, it is only a least-bad option, like democracy > or capitalism. As always, the choice is: 1. Continue to make incremental fixes to a system that is engineered suboptimally. Low risk, low cost, moderate reward. 2. Design a totally kick-ass new system that is engineered optimally -- unless, of course, it isn't. High risk, high cost, high reward. > Well, Canonical has. I think their execution has been poor, but they > have had the right vision for several years now. Their vision is wrong because, no matter the architecture decisions they've made, they *think* they're smart enough to build it as a proprietary application -- and they're not. This is *exactly* the class of application that *must* be open source if it's got any hope of success. > No other big community has made the full jump to a modern distributed > RCS yet; my sense is that this is a prereq for modern bugtracking. So > start there. +1 to this. In theory, anyway. > (I think GNOME would be happy to switch away from bugzilla to > something distributed, but has ~ 0 manpower to write the tool in the > first place. You obviously know mozilla better than I do, but I'd be > shocked if they are ready to move away from bugzilla- too tied into > it.) And this is the problem in a nutshell. Everyone agrees with the idea in theory, but no one has the manpower to make it happen in practice. --g -- Greg DeKoenigsberg Community Development Manager Red Hat, Inc. :: 1-919-754-4255 "To whomsoever much hath been given... ...from him much shall be asked" From luis at tieguy.org Thu Apr 12 15:21:28 2007 From: luis at tieguy.org (Luis Villa) Date: Thu, 12 Apr 2007 11:21:28 -0400 Subject: cross-site bug tracking In-Reply-To: References: <1176224048.3069.30.camel@localhost.localdomain> <20070410205321.GH5871@tomservo.rh.rit.edu> <2cb10c440704101420j43fd246avf9e633119ee175e8@mail.gmail.com> <1176300754.12574.9.camel@localhost.localdomain> <2cb10c440704111549n50ad94dbu260dbaa6072cacbd@mail.gmail.com> Message-ID: <2cb10c440704120821l1b2f3599h24874b3a57387cbc@mail.gmail.com> On 4/12/07, Greg Dekoenigsberg wrote: > > Well, Canonical has. I think their execution has been poor, but they > > have had the right vision for several years now. > > Their vision is wrong because, no matter the architecture decisions > they've made, they *think* they're smart enough to build it as a > proprietary application -- and they're not. This is *exactly* the class > of application that *must* be open source if it's got any hope of success. Method of production is orthogonal to goals of production. Don't confuse the two, or make the mistake of writing off what they are trying to do just because how they are doing it is dumb. [Or to put it another way- RH has gone a long, long time with a proprietary build system. There is very little reason to think that Canonical can't similarly succeed with a proprietary development infrastructure.] > > (I think GNOME would be happy to switch away from bugzilla to > > something distributed, but has ~ 0 manpower to write the tool in the > > first place. You obviously know mozilla better than I do, but I'd be > > shocked if they are ready to move away from bugzilla- too tied into > > it.) > > And this is the problem in a nutshell. Everyone agrees with the idea in > theory, but no one has the manpower to make it happen in practice. No one besides Canonical (and maybe rpath). They may not be doing it well, but they are doing it, and they will get smarter with time. Red Hat and Novell should see this as a serious threat to their business models, and should be investing appropriately. Luis From jkeating at redhat.com Thu Apr 12 15:43:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Apr 2007 11:43:52 -0400 Subject: the all IRC Board meeting In-Reply-To: References: <200704110913.15669.jkeating@redhat.com> Message-ID: <200704121143.52718.jkeating@redhat.com> On Wednesday 11 April 2007 10:49:11 Max Spevack wrote: > Maybe that was just me being behind on email -- but I don't think it's out > of line to sit down 6 weeks before the release and say "ok, we've got all > the leaders of various sub-groups more or less in the same place. ?Let's > go down the list and try to touch on everything." > > If I go around and personally ask the KDE spin guys about that, and > Jesse/Jeremy/Mike about the build system, and do the Summit DVD stuff > myself, then things get done, but information doesn't really flow. ?Or I > could go to the IRC meeting for each of those groups and spend my whole > week in chat rooms. ?Neither option seems particulalry good. > > My goal with yesterday's meeting was to get the general status of all > things F7 out there for everyone to be at a pretty similar baseline, and > allow people to talk out their issues in one place. > > Basically it was a big Engineering Status Meeting, that we used the Board > meeting time for. That works for me. Take away the connotations of it being a Board Meeting and it seemed fine. -- 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 luis at tieguy.org Thu Apr 12 15:51:58 2007 From: luis at tieguy.org (Luis Villa) Date: Thu, 12 Apr 2007 11:51:58 -0400 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <1176344404.5208.155.camel@erato.phig.org> References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> Message-ID: <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> On 4/11/07, Karsten Wade wrote: > On Wed, 2007-04-11 at 22:18 -0400, seth vidal wrote: > > > A good read, thanks, > > Note the implied "call to action" for Fedora to *do* something about > people not understanding what we are about. > > I'll bounce this article to f-marketing-l and we can take up the > discussion of that challenge over there. You might also discuss the new announcement that the next ubuntu release will have a Libre version. Again, I know direct confrontations aren't fun, but Fedora should at least consider publicly asking 'what took you so long?' and 'why isn't the main distro free?' instead of allowing Mark to take credit for what he should have been doing all along. Luis From tbm at cyrius.com Thu Apr 12 16:01:39 2007 From: tbm at cyrius.com (Martin Michlmayr) Date: Thu, 12 Apr 2007 09:01:39 -0700 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> Message-ID: <20070412160139.GW15933@deprecation.cyrius.com> * Luis Villa [2007-04-12 11:51]: > You might also discuss the new announcement that the next ubuntu > release will have a Libre version. Again, I know direct > confrontations aren't fun, but Fedora should at least consider > publicly asking 'what took you so long?' and 'why isn't the main > distro free?' instead of allowing Mark to take credit for what he > should have been doing all along. >From what I understand, that flavour of Ubuntu will be more free (*) than Fedora (e.g. no firmware, no images/sound that don't include full source), so such an announcement might backfire. (*) Depending on how you define freedom, obviously. I'm well aware that there's little agreement what "freedom" means when applied to firmware, images/sound, documentation etc. -- Martin Michlmayr http://www.cyrius.com/ From tcallawa at redhat.com Thu Apr 12 16:07:06 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 12 Apr 2007 11:07:06 -0500 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <20070412160139.GW15933@deprecation.cyrius.com> References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> Message-ID: <1176394026.3970.165.camel@localhost.localdomain> On Thu, 2007-04-12 at 09:01 -0700, Martin Michlmayr wrote: > * Luis Villa [2007-04-12 11:51]: > > You might also discuss the new announcement that the next ubuntu > > release will have a Libre version. Again, I know direct > > confrontations aren't fun, but Fedora should at least consider > > publicly asking 'what took you so long?' and 'why isn't the main > > distro free?' instead of allowing Mark to take credit for what he > > should have been doing all along. > > >From what I understand, that flavour of Ubuntu will be more free (*) > than Fedora (e.g. no firmware, no images/sound that don't include full > source), so such an announcement might backfire. > > (*) Depending on how you define freedom, obviously. I'm well aware > that there's little agreement what "freedom" means when applied to > firmware, images/sound, documentation etc. Yep. It looks like GNUbuntu will be more "Free" than Fedora. Think GNUsense. ~spot From sundaram at fedoraproject.org Thu Apr 12 16:09:11 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 12 Apr 2007 21:39:11 +0530 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <20070412160139.GW15933@deprecation.cyrius.com> References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> Message-ID: <461E59A7.2060106@fedoraproject.org> Martin Michlmayr wrote: > * Luis Villa [2007-04-12 11:51]: >> You might also discuss the new announcement that the next ubuntu >> release will have a Libre version. Again, I know direct >> confrontations aren't fun, but Fedora should at least consider >> publicly asking 'what took you so long?' and 'why isn't the main >> distro free?' instead of allowing Mark to take credit for what he >> should have been doing all along. > >>From what I understand, that flavour of Ubuntu will be more free (*) > than Fedora (e.g. no firmware, no images/sound that don't include full > source), so such an announcement might backfire. Even if it is more free relegating such freedom to a side project makes it a move that is less beneficial compared to dealing with the complexity of managing that primarily in a mainstream distribution. Free software is not a niche. Rahul From besfahbo at redhat.com Thu Apr 12 17:26:56 2007 From: besfahbo at redhat.com (Behdad Esfahbod) Date: Thu, 12 Apr 2007 13:26:56 -0400 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <20070412160139.GW15933@deprecation.cyrius.com> References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> Message-ID: <1176398816.9217.25.camel@behdad> On Thu, 2007-04-12 at 09:01 -0700, Martin Michlmayr wrote: > > >From what I understand, that flavour of Ubuntu will be more free (*) > than Fedora (e.g. no firmware, no images/sound that don't include full > source), so such an announcement might backfire. Good point about image sources. Do we publish Inkscape sources of background/etc in source RPMs? -- behdad http://behdad.org/ -------------- 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 Apr 12 17:42:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Apr 2007 13:42:12 -0400 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <1176398816.9217.25.camel@behdad> References: <461D8225.4050907@domsch.com> <20070412160139.GW15933@deprecation.cyrius.com> <1176398816.9217.25.camel@behdad> Message-ID: <200704121342.12572.jkeating@redhat.com> On Thursday 12 April 2007 13:26:56 Behdad Esfahbod wrote: > Good point about image sources. ?Do we publish Inkscape sources of > background/etc in source RPMs? Not that I'm aware of. It's just the images in a tarball IIRC. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Thu Apr 12 17:42:30 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 12 Apr 2007 23:12:30 +0530 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <1176398816.9217.25.camel@behdad> References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> <1176398816.9217.25.camel@behdad> Message-ID: <461E6F86.7090201@fedoraproject.org> Behdad Esfahbod wrote: > On Thu, 2007-04-12 at 09:01 -0700, Martin Michlmayr wrote: >> >From what I understand, that flavour of Ubuntu will be more free (*) >> than Fedora (e.g. no firmware, no images/sound that don't include full >> source), so such an announcement might backfire. > > Good point about image sources. Do we publish Inkscape sources of > background/etc in source RPMs? We could but that won't cover things like logos. The original source for these are usually not provided. The free variant of Ubuntu planned can't include say Firefox for example. Rahul From smooge at gmail.com Thu Apr 12 18:57:59 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 12 Apr 2007 12:57:59 -0600 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <1176344287.13177.23.camel@cutter> References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> Message-ID: <80d7e4090704121157m6fb9c95btfc246cb3d6efbf25@mail.gmail.com> On 4/11/07, seth vidal wrote: > On Wed, 2007-04-11 at 19:49 -0500, Matt Domsch wrote:b > > Check out LWN.net for today's weekly edition. Subscribers (and I do > > encourage folks to subscribe) will find it interesting. Non-subscribers > > should look at this: > > http://lwn.net/SubscriberLink/230042/5181766fe793aa6b/ > > lwn not abusing fedora. > reality slipping sideways > bizarro-world coming into focus Actually I havent seen Corbet 'abuse' fedora in any of its links. The people who post below it and the fellow who used to write the Distro page.. that is a different story. -- 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 skvidal at linux.duke.edu Thu Apr 12 19:01:45 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 12 Apr 2007 15:01:45 -0400 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <80d7e4090704121157m6fb9c95btfc246cb3d6efbf25@mail.gmail.com> References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <80d7e4090704121157m6fb9c95btfc246cb3d6efbf25@mail.gmail.com> Message-ID: <1176404505.19158.4.camel@cutter> On Thu, 2007-04-12 at 12:57 -0600, Stephen John Smoogen wrote: > On 4/11/07, seth vidal wrote: > > On Wed, 2007-04-11 at 19:49 -0500, Matt Domsch wrote:b > > > Check out LWN.net for today's weekly edition. Subscribers (and I do > > > encourage folks to subscribe) will find it interesting. Non-subscribers > > > should look at this: > > > http://lwn.net/SubscriberLink/230042/5181766fe793aa6b/ > > > > lwn not abusing fedora. > > reality slipping sideways > > bizarro-world coming into focus > > Actually I havent seen Corbet 'abuse' fedora in any of its links. The > people who post below it and the fellow who used to write the Distro > page.. that is a different story. That's a fair point. And I didn't say corbet - but what was the guy's name? zonker? used to beat on us a lot. -sv From tibbs at math.uh.edu Thu Apr 12 19:19:01 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Apr 2007 14:19:01 -0500 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <80d7e4090704121157m6fb9c95btfc246cb3d6efbf25@mail.gmail.com> References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <80d7e4090704121157m6fb9c95btfc246cb3d6efbf25@mail.gmail.com> Message-ID: >>>>> "SJS" == Stephen John Smoogen writes: SJS> Actually I havent seen Corbet 'abuse' fedora in any of its SJS> links. Especially since it seems he actually uses rawhide on his desktop. - J< From notting at redhat.com Thu Apr 12 21:20:27 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 12 Apr 2007 17:20:27 -0400 Subject: RFC: Release team meetings Message-ID: <20070412212027.GB3357@nostromo.devel.redhat.com> Given what was discussed at the last board meeting, I'm suggesting that even more than the monthly engineering meetings tossed about, we have regular release meetings. Draft at: http://fedoraproject.org/wiki/BillNottingham/ReleaseMeetingsDraft - reproduced inline. ... In order to sanely coordinate our releases, we should have regular release meetings. These meetings should be at least weekly, possibly semiweekly near the end of freeze cycles. Time: TBD, pending approval of required attendees Attendees: Representatives from: * Fedora Release Engineering * Fedora QA * Fedora Docs * Fedora L10N * Fedora Infrastructure * Representatives of major subsystems of Fedora * Kernel * GNOME * KDE * others? * Other attendees as requested. These would generally be representatives for particular features or subprojects that need discussed. (Example: someone from LiveCD, or someone working on TeX.) Agenda: Including, but not limited to: * Freeze status and schedules * Test status of current trees * Blocking bugs * Potential slips * Feature status * Coordination of subgroups (handoff of release notes to rel-eng, for example) Reports from these meetings would be made to FESCo, and to the Fedora board. ... This probably falls under FESCo's umbrella, but I'm not sure it's appropriate to dominate the weekly FESCo meeting with this stuff. Opinions? Bill From jkeating at redhat.com Thu Apr 12 21:30:07 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Apr 2007 17:30:07 -0400 Subject: RFC: Release team meetings In-Reply-To: <20070412212027.GB3357@nostromo.devel.redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> Message-ID: <200704121730.08353.jkeating@redhat.com> On Thursday 12 April 2007 17:20:27 Bill Nottingham wrote: > This probably falls under FESCo's umbrella, but I'm not sure it's > appropriate to dominate the weekly FESCo meeting with this stuff. Opinions? I think it's great, and you beat me to doing the wiki work to pitch it (: I think these should be on their own and not dominate either FESCo nor Fedora Board with it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Thu Apr 12 21:31:26 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 12 Apr 2007 16:31:26 -0500 Subject: RFC: Release team meetings In-Reply-To: <200704121730.08353.jkeating@redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704121730.08353.jkeating@redhat.com> Message-ID: <1176413487.25283.2.camel@vader.jdub.homelinux.org> On Thu, 2007-04-12 at 17:30 -0400, Jesse Keating wrote: > On Thursday 12 April 2007 17:20:27 Bill Nottingham wrote: > > This probably falls under FESCo's umbrella, but I'm not sure it's > > appropriate to dominate the weekly FESCo meeting with this stuff. Opinions? > > I think it's great, and you beat me to doing the wiki work to pitch it (: I > think these should be on their own and not dominate either FESCo nor Fedora > Board with it. Agreed. josh From poelstra at redhat.com Fri Apr 13 00:28:33 2007 From: poelstra at redhat.com (John Poelstra) Date: Thu, 12 Apr 2007 17:28:33 -0700 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <20070412160139.GW15933@deprecation.cyrius.com> References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> Message-ID: <461ECEB1.7000301@redhat.com> Martin Michlmayr said the following on 04/12/2007 09:01 AM Pacific Time: > * Luis Villa [2007-04-12 11:51]: >> You might also discuss the new announcement that the next ubuntu >> release will have a Libre version. Again, I know direct >> confrontations aren't fun, but Fedora should at least consider >> publicly asking 'what took you so long?' and 'why isn't the main >> distro free?' instead of allowing Mark to take credit for what he >> should have been doing all along. > >>From what I understand, that flavour of Ubuntu will be more free (*) > than Fedora (e.g. no firmware, no images/sound that don't include full > source), so such an announcement might backfire. > > (*) Depending on how you define freedom, obviously. I'm well aware > that there's little agreement what "freedom" means when applied to > firmware, images/sound, documentation etc. On a related topic... from the Fedora main page... "...All in pursuit of the best operating system and platform that free software can provide." What don't we have a link there to the Fedora definition of "free software?" John From open07 at gmail.com Fri Apr 13 01:34:13 2007 From: open07 at gmail.com (Koh Choon Lin) Date: Fri, 13 Apr 2007 09:34:13 +0800 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <461ECEB1.7000301@redhat.com> References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> <461ECEB1.7000301@redhat.com> Message-ID: > >>From what I understand, that flavour of Ubuntu will be more free (*) > > than Fedora (e.g. no firmware, no images/sound that don't include full > > source), so such an announcement might backfire. Will the coming Fedora Core 7 be completely free? The last I heard, it is still cooperating with the FSF. From fedora at leemhuis.info Fri Apr 13 05:05:05 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 13 Apr 2007 07:05:05 +0200 Subject: RFC: Release team meetings In-Reply-To: <1176413487.25283.2.camel@vader.jdub.homelinux.org> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704121730.08353.jkeating@redhat.com> <1176413487.25283.2.camel@vader.jdub.homelinux.org> Message-ID: <461F0F81.7010603@leemhuis.info> On 12.04.2007 23:31, Josh Boyer wrote: > On Thu, 2007-04-12 at 17:30 -0400, Jesse Keating wrote: >> On Thursday 12 April 2007 17:20:27 Bill Nottingham wrote: >>> This probably falls under FESCo's umbrella, but I'm not sure it's >>> appropriate to dominate the weekly FESCo meeting with this stuff. Opinions? >> I think it's great, and you beat me to doing the wiki work to pitch it (: I >> think these should be on their own and not dominate either FESCo nor Fedora >> Board with it. > Agreed. +1 -- but it might be good to bring important topics up in the FESCo meetings -- similar how Packaging Committee or EPEL topics sometimes get brought up now. That requires that the "Release team" writes proper minutes of their decisions and doings. I'd further would like to see more informations what the Release Team is (number of people and names), how it is constituted (approved, elected, mixed?), who's responsible (chairmen?) and what its works areas exactly are (what remains FESCo work and what will the Release Team take care of? and when does the Board get into the game?). Especially the latter seems quite important to me as there seems to be a bit of confusion now with the Board and FESCo already who of those two takes care of what. CU thl From sundaram at fedoraproject.org Fri Apr 13 09:03:38 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 13 Apr 2007 14:33:38 +0530 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> <461ECEB1.7000301@redhat.com> Message-ID: <461F476A.1020400@fedoraproject.org> Koh Choon Lin wrote: >> >>From what I understand, that flavour of Ubuntu will be more free (*) >> > than Fedora (e.g. no firmware, no images/sound that don't include full >> > source), so such an announcement might backfire. > > Will the coming Fedora Core 7 be completely free? The last I heard, it > is still cooperating with the FSF. You have to be more specific on what you consider free. Rahul From stickster at gmail.com Fri Apr 13 12:23:13 2007 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 13 Apr 2007 08:23:13 -0400 Subject: Privacy policy status Message-ID: <1176466993.27197.11.camel@localhost.localdomain> Does anyone have any information on the status of our privacy policy? We really ought to have something non-draft, spelled out where our users and account holders can be assured of how their information is or isn't used. The existing draft is pretty good but I'm certain this is something legal should be (and probably was already tasked with) reviewing. Max and Greg have a lot on their respective plates; is there anyone else who can carry this to completion? -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- An embedded message was scrubbed... From: Karsten Wade Subject: Re: Moin question Date: Wed, 11 Apr 2007 17:40:15 -0700 Size: 4755 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Fri Apr 13 12:35:16 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 13 Apr 2007 18:05:16 +0530 Subject: Privacy policy status In-Reply-To: <1176466993.27197.11.camel@localhost.localdomain> References: <1176466993.27197.11.camel@localhost.localdomain> Message-ID: <461F7904.2010106@fedoraproject.org> Paul W. Frields wrote: > Does anyone have any information on the status of our privacy policy? > We really ought to have something non-draft, spelled out where our users > and account holders can be assured of how their information is or isn't > used. The existing draft is pretty good but I'm certain this is > something legal should be (and probably was already tasked with) > reviewing. Max and Greg have a lot on their respective plates; is there > anyone else who can carry this to completion? Anyone else can't do it. It requires the Red Hat legal team to look at it. Greg and Max are the gateway there. Rahul From jkeating at redhat.com Fri Apr 13 13:04:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Apr 2007 09:04:00 -0400 Subject: RFC: Release team meetings In-Reply-To: <461F0F81.7010603@leemhuis.info> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <1176413487.25283.2.camel@vader.jdub.homelinux.org> <461F0F81.7010603@leemhuis.info> Message-ID: <200704130904.01185.jkeating@redhat.com> On Friday 13 April 2007 01:05:05 Thorsten Leemhuis wrote: > I'd further would like to see more informations what the Release Team is > (number of people and names), how it is constituted (approved, elected, > mixed?), who's responsible (chairmen?) and what its works areas exactly > are (what remains FESCo work and what will the Release Team take care > of? and when does the Board get into the game?). It's things like this that start to frustrate me. Sure it's neat information to have, but for the sake of getting a few people together to get some work done, I really don't want to have to go through the headache of creating all this red tape and governance. Now, I don't think that some of this is bad to have, it just makes the barrier of entry to having a group of people work on something pretty daunting. It's part of the reason why I _haven't_ yet created the sig page for the release team, thinking about this crud gives me a headache. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Apr 13 13:37:32 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 13 Apr 2007 15:37:32 +0200 Subject: RFC: Release team meetings In-Reply-To: <200704130904.01185.jkeating@redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <1176413487.25283.2.camel@vader.jdub.homelinux.org> <461F0F81.7010603@leemhuis.info> <200704130904.01185.jkeating@redhat.com> Message-ID: <461F879C.10708@leemhuis.info> Jesse Keating schrieb: > On Friday 13 April 2007 01:05:05 Thorsten Leemhuis wrote: >> I'd further would like to see more informations what the Release Team is >> (number of people and names), how it is constituted (approved, elected, >> mixed?), who's responsible (chairmen?) and what its works areas exactly >> are (what remains FESCo work and what will the Release Team take care >> of? and when does the Board get into the game?). > > It's things like this that start to frustrate me. Sure it's neat information > to have, but for the sake of getting a few people together to get some work > done, I really don't want to have to go through the headache of creating all > this red tape and governance. Now, I don't think that some of this is bad to > have, it just makes the barrier of entry to having a group of people work on > something pretty daunting. It's part of the reason why I _haven't_ yet > created the sig page for the release team, thinking about this crud gives me > a headache. I can feel with you and understand your point. But that *IMHO* the overhead you have to live with if you want to get the community involved, as they afaics want to have a chance to influence stuff if they spend lots of their time working on that stuff (Fedora in this case). But that overhead IMHO worth the trouble *if you do it right*, because the community then will do work that you otherwise would have to do. But if you don't do it right it can easily fail and you have some overhead, but get nearly nothing back, or even worse, you have to continue to do all the work. Further: One of the reasons for merging Core and Extras afaics (correct me if I'm wrong) was that the community showed well what they can do if you let them -- that includes the working structures (e.g. governance modell) . And during the public merge discussions it seemed to me that it was important for some of the important people that FESCo stays to exist as it worked well and the community felt represented by it. But it seems to me we are working in the opposite direction: FESCo still exists, but it seems to me it is less important than before. And there was a lot of chaos in the past months -- the hectic ACL implementation for example. The merge reviews and the rules around it (e.g. blocker bugs vs. flags). Lots of other minor stuff. I first said "okay, things are new to everyone and everything will work out to something good somehow" but I have reached the point where it seemed to me that things are not improving; in fact they were getting worse. Some people told me in private they were unhappy and concerned as well. And that why I'm pressing on this whole "governance" issues ATM, to make sure the community still feels well involved and represented. Getting that roughly right from the start of the merge imho is quite important, as it will influence Fedora in the long term quite heavily. Sorry if that's creating a headache for you. CU thl From jkeating at redhat.com Fri Apr 13 13:59:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Apr 2007 09:59:06 -0400 Subject: RFC: Release team meetings In-Reply-To: <461F879C.10708@leemhuis.info> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704130904.01185.jkeating@redhat.com> <461F879C.10708@leemhuis.info> Message-ID: <200704130959.07225.jkeating@redhat.com> On Friday 13 April 2007 09:37:32 Thorsten Leemhuis wrote: > I can feel with you and understand your point. But that *IMHO* the > overhead you have to live with if you want to get the community > involved, as they afaics want to have a chance to influence stuff if > they spend lots of their time working on that stuff (Fedora in this case). > > But that overhead IMHO worth the trouble *if you do it right*, because > the community then will do work that you otherwise would have to do. But > if you don't do it right it can easily fail and you have some overhead, > but get nearly nothing back, or even worse, you have to continue to do > all the work. I see you've taken this as an US vs THEM stance again. It's not. The fact is there _are_ community people in the release team and as far as I've seen they're just as interested in just getting work done than spending the next 2 weeks arguing over how to structure the governance, meeting schedule, voting style, reporting officers, etc... In fact, I'd go so far as to say that everybody _but_ me in the group is a community member. I am the only person that is paid to release engineer Fedora. Everybody else participates outside their normal day job which would make them community members regardless of who their employer is. -- 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 kwade at redhat.com Fri Apr 13 14:26:43 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 13 Apr 2007 07:26:43 -0700 Subject: RFC: Release team meetings In-Reply-To: <200704130959.07225.jkeating@redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704130904.01185.jkeating@redhat.com> <461F879C.10708@leemhuis.info> <200704130959.07225.jkeating@redhat.com> Message-ID: <1176474403.5208.231.camel@erato.phig.org> On Fri, 2007-04-13 at 09:59 -0400, Jesse Keating wrote: > I see you've taken this as an US vs THEM stance again. Slightly differently, I think Thorsten is describing general feelings that are out there, not his personal reaction. Jesse -- the seed is in your post: "It's part of the reason why I _haven't_ yet created the sig page for the release team, thinking about this crud gives me a headache." I agree that you don't want to slow down progressing on the idea that Bill put forward. But you are basically saying that you are allergic to governance details. In that case, pick someone else to do them. Like them or not, governance details are vital. They break real or perceived cabals. Doesn't matter who the cabals are or where they are paid, etc. Cabal is as cabal does. Your reaction reminds of what happened nine months ago when I suggested we get some proper project management to make Fedora releases go more smoothly. "Oh, no, project management, this is sounding too much like RHEL engineering." Well, no ... but Fedora is not some kid Linux distro produced in spare time by basement hackers. Its success is pretty vital to all of us. Shying away from "ickle project management" and "ucky governance" is shortsighted. And it will get us in trouble nearly every time we do it. - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri Apr 13 14:27:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Apr 2007 10:27:40 -0400 Subject: RFC: Release team meetings In-Reply-To: <1176474403.5208.231.camel@erato.phig.org> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704130959.07225.jkeating@redhat.com> <1176474403.5208.231.camel@erato.phig.org> Message-ID: <200704131027.41031.jkeating@redhat.com> On Friday 13 April 2007 10:26:43 Karsten Wade wrote: > "It's part of the reason why I _haven't_ yet created the sig page for > the release team, thinking about this crud gives me a headache." > > I agree that you don't want to slow down progressing on the idea that > Bill put forward. ?But you are basically saying that you are allergic to > governance details. ?In that case, pick someone else to do them. I never said I wouldn't be happy if somebody else did that. I applauded Bill for stepping up. I stated that _I_ get frustrated when _I_ want to get a group of people together to accomplish something, and _I_ get faced with all kinds of procedural red tape. Doesn't mean that somebody else doesn't love this kind of stuff and would be willing to do that kind of legwork for each group. I don't, and I won't. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Apr 13 15:11:35 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 13 Apr 2007 17:11:35 +0200 Subject: RFC: Release team meetings In-Reply-To: <200704130959.07225.jkeating@redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704130904.01185.jkeating@redhat.com> <461F879C.10708@leemhuis.info> <200704130959.07225.jkeating@redhat.com> Message-ID: <461F9DA7.6060208@leemhuis.info> Jesse Keating schrieb: > On Friday 13 April 2007 09:37:32 Thorsten Leemhuis wrote: >> I can feel with you and understand your point. But that *IMHO* the >> overhead you have to live with if you want to get the community >> involved, as they afaics want to have a chance to influence stuff if >> they spend lots of their time working on that stuff (Fedora in this case). >> >> But that overhead IMHO worth the trouble *if you do it right*, because >> the community then will do work that you otherwise would have to do. But >> if you don't do it right it can easily fail and you have some overhead, >> but get nearly nothing back, or even worse, you have to continue to do >> all the work. > > I see you've taken this as an US vs THEM stance again. No, that was as is not my intention. It's a "it happens behind closed door" vs "it happens in the open and everyone that wants to get involved or heard at least can try". > It's not. The fact is > there _are_ community people in the release team and as far as I've seen > they're just as interested in just getting work done than spending the next 2 > weeks arguing over how to structure the governance, meeting schedule, voting > style, reporting officers, etc... That not needed now imho, as we are close to F7 (?); just a list of names in the wiki, and some form of report now and then with "the release team decided foo and bar" (only the important stuff of course, not the details) would be a good start for now at this point of time so close before F7. > In fact, I'd go so far as to say that > everybody _but_ me in the group is a community member. Currently it's happens in the dark to outsiders like me; even worse: it seems even FESCo doesn't know or discuss what got decided by the release team. Other groups like the packaging committee or EPEL send reports that get discussed (and sometimes even vetoed, like yesterday). > I am the only person > that is paid to release engineer Fedora. Then it's a Release Cabal with non-paid Fedora community members now instead of a Core cabal -- I'd say that isn't much of an improvement as long as things happen behind closed doors. > Everybody else participates outside > their normal day job which would make them community members regardless of > who their employer is. And we really need someone that can work on it release engeneering task full time, so it's good to have your here Jesse. I really appreciate your work (?); it's just that I'd like it to happen more in the open so people that want to get involved can. CU thl (?) -- well, all those stuff could have been worked out months ago as it was foreseeable that a release group was needed. It was mentioned multiple times during the "FESCo successor" discussions and everyone iirc agreed (well, nobody complained) that you are the person for running this team. From tibbs at math.uh.edu Fri Apr 13 15:33:20 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 13 Apr 2007 10:33:20 -0500 Subject: RFC: Release team meetings In-Reply-To: <200704130904.01185.jkeating@redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <1176413487.25283.2.camel@vader.jdub.homelinux.org> <461F0F81.7010603@leemhuis.info> <200704130904.01185.jkeating@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> Sure it's neat information to have, but for the sake of getting a JK> few people together to get some work done, I really don't want to JK> have to go through the headache of creating all this red tape and JK> governance. As far as I can tell all you really need is something that tells people where to look if they want to become involved in the process. What list should they join (if there's a list)? What IRC channel should they join (if there's IRC discussion)? If you decide to have meetings (and nothing requires that as far as I can see) then say when and where the meetings are held. That's about it. It might be nice to list out the people who are currently on the team so that everyone knows who they're talking to and who to ping. But I agree that if folks are really wanting you to elect a chairman and list out the parliamentary procedure you're using then that indeed is a bit over the top and I can see why you'd object. And if you hate dealing with the wiki as much as I do, just post that info here and ask nicely and I'm sure that someone will cook up a page. - J< From fedora at leemhuis.info Fri Apr 13 15:49:30 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 13 Apr 2007 17:49:30 +0200 Subject: RFC: Release team meetings In-Reply-To: References: <20070412212027.GB3357@nostromo.devel.redhat.com> <1176413487.25283.2.camel@vader.jdub.homelinux.org> <461F0F81.7010603@leemhuis.info> <200704130904.01185.jkeating@redhat.com> Message-ID: <461FA68A.1060208@leemhuis.info> Jason L Tibbitts III schrieb: >>>>>> "JK" == Jesse Keating writes: > > JK> Sure it's neat information to have, but for the sake of getting a > JK> few people together to get some work done, I really don't want to > JK> have to go through the headache of creating all this red tape and > JK> governance. > > As far as I can tell all you really need is something that tells > people where to look if they want to become involved in the process. > What list should they join (if there's a list)? What IRC channel > should they join (if there's IRC discussion)? If you decide to have > meetings (and nothing requires that as far as I can see) then say when > and where the meetings are held. > > That's about it. Agreed if you add a "post a summary of important decisions so the public and FESCo (and thus the board) know what got decided" CU thl From fedora at leemhuis.info Fri Apr 13 16:11:20 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 13 Apr 2007 18:11:20 +0200 Subject: RFC: Release team meetings In-Reply-To: <200704130959.07225.jkeating@redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704130904.01185.jkeating@redhat.com> <461F879C.10708@leemhuis.info> <200704130959.07225.jkeating@redhat.com> Message-ID: <461FABA8.7000103@leemhuis.info> > I see you've taken this as an US vs THEM stance again. BTW, I'd like to add something. I know my mails might look like "US vs THEM" or "Red Hat vs. community" sometimes. But always keep in mind: I'm spending a lot of time for Fedora because I think its politics are good and because I trust Red Hat and its decisions (well, not completely [that would be stupid], but a lot more then all other big Linux vendors). And I also really appreciate the work and the open-source efforts of Red Hat and it's employees. That's why I'm participating in Fedora. But the community and Red Hat employees didn't interact to well when Fedora was started years ago (they in fact didn't interact much more than in the RHL days when Fedora was young [say up to FC3/FC$]). It got a whole lot better in between, but the interaction between those two groups still needs to improve imho. Both sides afaics needs to learn how to interact better with each other to understand each others position and workflow -- then we'll hopefully sooner or later have a real Fedora *Project* with a community where it doesn't matter if someone is working for Red Hat or not, or if he is getting payed for his work by someone or does it in his spare time. We are on that way, but it's still a lot work to do. And even worse: I think we need to put the focus a bit more on community for some time to really send out the sign "Fedora is a community project" to the press and the Linux enthusiast out there. Then we hopefully might get rid of things like http://www.arouse.net/despair-linux/fedora.jpg in the end. That's by the way the reason why I request things like "the goal should be that all packages that formerly were part of Fedora Core should have co-maintainers from the community after the merge" (?) or "FESCo should have at least 50% community members". CU thl (?) "Non-RH-employees" might be the better term than community in fact, as Red Hat employees are of course community members as well From gdk at redhat.com Fri Apr 13 16:15:26 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Fri, 13 Apr 2007 12:15:26 -0400 (EDT) Subject: RFC: Release team meetings In-Reply-To: <461FABA8.7000103@leemhuis.info> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704130904.01185.jkeating@redhat.com> <461F879C.10708@leemhuis.info> <200704130959.07225.jkeating@redhat.com> <461FABA8.7000103@leemhuis.info> Message-ID: On Fri, 13 Apr 2007, Thorsten Leemhuis wrote: > But the community and Red Hat employees didn't interact to well when > Fedora was started years ago (they in fact didn't interact much more > than in the RHL days when Fedora was young [say up to FC3/FC$]). It got > a whole lot better in between, but the interaction between those two > groups still needs to improve imho. Both sides afaics needs to learn how > to interact better with each other to understand each others position > and workflow -- then we'll hopefully sooner or later have a real Fedora > *Project* with a community where it doesn't matter if someone is working > for Red Hat or not, or if he is getting payed for his work by someone or > does it in his spare time. > > We are on that way, but it's still a lot work to do. And even worse: I > think we need to put the focus a bit more on community for some time to > really send out the sign "Fedora is a community project" to the press > and the Linux enthusiast out there. Then we hopefully might get rid of > things like http://www.arouse.net/despair-linux/fedora.jpg > in the end. That's by the way the reason why I request things like "the > goal should be that all packages that formerly were part of Fedora Core > should have co-maintainers from the community after the merge" (?) or > "FESCo should have at least 50% community members". +1. The purpose for governance, in this context, is to ensure "external to Red Hat" participation. In an ideal world, we wouldn't need to do this; Redhatters and non-Redhatters would participate easily together. In the real world, Redhatters have hallway conversations all the time, and it requires effort and discipline, and sometimes rules, to make sure that those hallway conversations do not dominate the project. --g -- Greg DeKoenigsberg Community Development Manager Red Hat, Inc. :: 1-919-754-4255 "To whomsoever much hath been given... ...from him much shall be asked" From jkeating at redhat.com Fri Apr 13 17:37:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Apr 2007 13:37:56 -0400 Subject: RFC: Release team meetings In-Reply-To: <461FABA8.7000103@leemhuis.info> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704130959.07225.jkeating@redhat.com> <461FABA8.7000103@leemhuis.info> Message-ID: <200704131337.56668.jkeating@redhat.com> On Friday 13 April 2007 12:11:20 Thorsten Leemhuis wrote: > But the community and Red Hat employees didn't interact to well when > Fedora was started years ago (they in fact didn't interact much more > than in the RHL days when Fedora was young [say up to FC3/FC$]). This is another case. You make it seem like those that work on Fedora interacted very well with other parts of Red Hat all along and that's just _not_ the case. In fact, in many cases, the non-Red Hat community members knew more about whats going on in Fedora than on Red Hat employed community members. Where we suck at communication, we suck across the board, whether you work for Red Hat or not. Pitching the problem as a Red Hat vs the rest of the world doesn't do any good what so ever. The real problem is getting those that are deeply ingrained in the Fedora work (whether you work for RH or not) to communicate better (2 way street!) with those that are not so deeply ingrained (whether that's inside Red Hat or not). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From smooge at gmail.com Fri Apr 13 18:22:53 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 13 Apr 2007 12:22:53 -0600 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <461F476A.1020400@fedoraproject.org> References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> <461ECEB1.7000301@redhat.com> <461F476A.1020400@fedoraproject.org> Message-ID: <80d7e4090704131122w56cd1539yee25e7551d96768c@mail.gmail.com> On 4/13/07, Rahul Sundaram wrote: > Koh Choon Lin wrote: > >> >>From what I understand, that flavour of Ubuntu will be more free (*) > >> > than Fedora (e.g. no firmware, no images/sound that don't include full > >> > source), so such an announcement might backfire. > > > > Will the coming Fedora Core 7 be completely free? The last I heard, it > > is still cooperating with the FSF. > > You have to be more specific on what you consider free. > Not in any order. Free[0] == Free of Cost Free[1] == Free to do whatever you want with without having to share [ALA BSD] Free[2] == Free to do whatever you want but having to share Free[3] == Free without problems with Patents/Trademarks on source code. ... Free[Aleph-0] == Free of any restrictions to do what you want however you wish without anything impinging via binary blogs for hardware that should all be open to anyone to build at any time if they had the circuit diagrams and the other equiptment. -- 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 a.badger at gmail.com Fri Apr 13 19:27:27 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 13 Apr 2007 12:27:27 -0700 Subject: RFC: Release team meetings In-Reply-To: <200704130904.01185.jkeating@redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <1176413487.25283.2.camel@vader.jdub.homelinux.org> <461F0F81.7010603@leemhuis.info> <200704130904.01185.jkeating@redhat.com> Message-ID: <1176492447.11234.77.camel@localhost.localdomain> On Fri, 2007-04-13 at 07:05 +0200, Thorsten Leemhuis wrote: > +1 -- but it might be good to bring important topics up in the FESCo > meetings -- similar how Packaging Committee or EPEL topics sometimes get > brought up now. That requires that the "Release team" writes proper > minutes of their decisions and doings. I agree. Information flow is extremely important. Note that I think the Packaging Committee is not a good model for the release team, though. The PC isn't just reporting to FESCo, we're also having our items approved. As a FESCo member, I envision the releng team having broader powers to do things first and report on them after. There _will_ be contentious issues and a way of dealing with them needs to be figured out. I think a retrospective look on how cvs ACLs and the new review processes were created, how they were decided, how they felt to someone outside the decision making process, and whether they were implemented in a timely fashion would be a good place to find ideas on how to make things both efficient and keep everybody feeling involved and empowered. On Fri, 2007-04-13 at 09:04 -0400, Jesse Keating wrote: > On Friday 13 April 2007 01:05:05 Thorsten Leemhuis wrote: > > I'd further would like to see more informations what the Release Team is > > (number of people and names), how it is constituted (approved, elected, > > mixed?), who's responsible (chairmen?) and what its works areas exactly > > are (what remains FESCo work and what will the Release Team take care > > of? and when does the Board get into the game?). > > It's things like this that start to frustrate me. Sure it's neat information > to have, but for the sake of getting a few people together to get some work > done, I really don't want to have to go through the headache of creating all > this red tape and governance. I don't think there needs to be a lot of governance, just some information on who's doing what. Jesse, Thorsten, releng team, what do you think of this proposal: --- = Release Engineering Team = == Composition == * Jesse Keating (f13) * Josh Boyer (jwb) * Bill Nottingham (notting) * Jeremy Katz (katzj) * [Please fill in and correct] Release Team members are approved by FESCo. However, FESCo has delegated this power to the Release Team itself. If you want to join the team, contact releng at fedoraproject.org. == Who's in Charge == Jesse Keating. Leadership is currently appointed by FESCo with input from the current release team. == Things we Do == * Set the schedule for releases including freeze dates, final release, slips, etc. * Set blocker criteria for the release. * Decide what packages go onto a spin. * Create official Fedora Spins. * Report progress towards release from Feature Freeze on. * Give reports to FESCo on changes to processes. * If something is known to be controversial, we let FESCo know before implementing otherwise implementation generally happens concurrently to reporting. * [Fill in anything related to release management you want] == Where we do it == * IRC: [Select an IRC Channel] * Mailing List: releng at fedoraproject.org * Meetings: Not currently. We just discuss things on [IRC channel] when we think of something. [If Bill's meeting plan comes to fruition, add a link and general information here] ------ Action Items: * Have releng fill in all the bracketed items. * Have releng team +1 this :-) * Have FESCo +1 this * Change releng at fedoraproject.org from an alias to a mailing list so there's an archive of past discussions to look at. -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 notting at redhat.com Fri Apr 13 19:29:10 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 13 Apr 2007 15:29:10 -0400 Subject: RFC: Release team meetings In-Reply-To: <1176492447.11234.77.camel@localhost.localdomain> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <1176413487.25283.2.camel@vader.jdub.homelinux.org> <461F0F81.7010603@leemhuis.info> <200704130904.01185.jkeating@redhat.com> <1176492447.11234.77.camel@localhost.localdomain> Message-ID: <20070413192910.GB7462@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: > I don't think there needs to be a lot of governance, just some > information on who's doing what. Jesse, Thorsten, releng team, what do > you think of this proposal: Well, there's a dichotomoy here - there's the 'release engineering team' (rel-eng at fedoraproject.org) which you have described. However, for this meeting, there is essentially the *release* team, which consists of members from rel-eng, qa, docs, etc. The meeting is for the release team; if rel-eng also wants to have meetings, that can happen. Bill From jkeating at redhat.com Fri Apr 13 19:42:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Apr 2007 15:42:12 -0400 Subject: RFC: Release team meetings In-Reply-To: <1176492447.11234.77.camel@localhost.localdomain> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704130904.01185.jkeating@redhat.com> <1176492447.11234.77.camel@localhost.localdomain> Message-ID: <200704131542.12514.jkeating@redhat.com> On Friday 13 April 2007 15:27:27 Toshio Kuratomi wrote: > I don't think there needs to be a lot of governance, just some > information on who's doing what. ?Jesse, Thorsten, releng team, what do > you think of this proposal: A page already exists... http://fedoraproject.org/wiki/ReleaseEngineering and there is some draft work going on: http://fedoraproject.org/wiki/JesseKeating/RelEng Information from those could get shared around or merged or vice versa. -ETIME (: > --- > > = Release Engineering Team = > > == Composition == > ?* Jesse Keating (f13) > ?* Josh Boyer (jwb) > ?* Bill Nottingham (notting) > ?* Jeremy Katz (katzj) > ?* [Please fill in and correct] > > Release Team members are approved by FESCo. ?However, FESCo has > delegated this power to the Release Team itself. ?If you want to join > the team, contact releng at fedoraproject.org. rel-eng at fedoraproject.org > == Who's in Charge == > Jesse Keating. ?Leadership is currently appointed by FESCo with input > from the current release team. > > == Things we Do == > ?* Set the schedule for releases including freeze dates, final release, > slips, etc. > ?* Set blocker criteria for the release. > ?* Decide what packages go onto a spin. > ?* Create official Fedora Spins. > ?* Report progress towards release from Feature Freeze on. > ?* Give reports to FESCo on changes to processes. > ? * If something is known to be controversial, we let FESCo know before > implementing otherwise implementation generally happens concurrently to > reporting. > ?* [Fill in anything related to release management you want] > > == Where we do it == > ?* IRC: [Select an IRC Channel] > ?* Mailing List: releng at fedoraproject.org > ?* Meetings: Not currently. ?We just discuss things on [IRC channel] > when we think of something. [If Bill's meeting plan comes to fruition, > add a link and general information here] > > ------ > > Action Items: > * Have releng fill in all the bracketed items. > * Have releng team +1 this :-) > * Have FESCo +1 this > * Change releng at fedoraproject.org from an alias to a mailing list so > there's an archive of past discussions to look at. These seem mostly good, but more of a release team and less of a release engineer team. I guess I see it as this, a Release Team makes a lot of these types of decisions in the broad scope before and during a release, while the release engineering team are the people who actually _do_ something, such as tagging a build, approving a freeze override, set up freeze tags, etc... More of the doers, and thus a smaller group, while the release team is more ad hoc depending on the release features and such. Man I'm having a hard time writing this out... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Apr 13 20:12:18 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 13 Apr 2007 22:12:18 +0200 Subject: RFC: Release team meetings In-Reply-To: <1176492447.11234.77.camel@localhost.localdomain> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <1176413487.25283.2.camel@vader.jdub.homelinux.org> <461F0F81.7010603@leemhuis.info> <200704130904.01185.jkeating@redhat.com> <1176492447.11234.77.camel@localhost.localdomain> Message-ID: <461FE422.1000705@leemhuis.info> Toshio Kuratomi schrieb: > On Fri, 2007-04-13 at 07:05 +0200, Thorsten Leemhuis wrote: >> +1 -- but it might be good to bring important topics up in the FESCo >> meetings -- similar how Packaging Committee or EPEL topics sometimes get >> brought up now. That requires that the "Release team" writes proper >> minutes of their decisions and doings. > I agree. Information flow is extremely important. Note that I think > the Packaging Committee is not a good model for the release team, > though. The PC isn't just reporting to FESCo, we're also having our > items approved. Well, that was IIRC not planed this way and "just happened". The model that was planed iirc was something similar (but not exactly) to what I outline below. > As a FESCo member, I envision the releng team having > broader powers to do things first and report on them after. How about something like this as a general scheme: Package Committee, EPEL, Release team and other groups below FESCO at might arise in the future act on their own mostly; they need to meet in the public now and then (e.g. IRC) and discuss their things in public (mailing list); important decisions and happenings get reported to some list (fedora-maintainers?) and to FESCO (?) to get everyone and FESCo up2date. If one FESCo member things stuff needs to be discussed by FESCo (aka maybe vetoed) then he should mention that on the list in less then 72 hours after that report got send. The group then should wait until the next FESCO meeting and the outcome of that discussion before implementing what was agreed (of course the issue might be solved on the list as well). Something like that should be be a good mix of getting stuff done without to much delays/overhead and keeping everyone informed. > I don't think there needs to be a lot of governance, just some > information on who's doing what. +1 > Jesse, Thorsten, releng team, what do you think of this proposal: Some comments on details below, but in general agreed. > --- > > = Release Engineering Team = > > == Composition == > * Jesse Keating (f13) > * Josh Boyer (jwb) > * Bill Nottingham (notting) > * Jeremy Katz (katzj) > * [Please fill in and correct] I'd say the maybe the body that makes the decisions should have a defined size. Maybe 7 or 9 members -- that's not to much (otherwise nobody might feel responsible) and not to less (to much work for everyone). The size of the group/team/SIG itself of course is not limited. > * Give reports to FESCo on changes to processes. s/FESCo/&and the public/ > == Where we do it == > * IRC: [Select an IRC Channel] #fedora-devel > * Mailing List: releng at fedoraproject.org Do we really need a separate mailing list? I'd say "no" (for now). [...] CU thl From notting at redhat.com Fri Apr 13 20:18:50 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 13 Apr 2007 16:18:50 -0400 Subject: RFC: Release team meetings In-Reply-To: <461FE422.1000705@leemhuis.info> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <1176413487.25283.2.camel@vader.jdub.homelinux.org> <461F0F81.7010603@leemhuis.info> <200704130904.01185.jkeating@redhat.com> <1176492447.11234.77.camel@localhost.localdomain> <461FE422.1000705@leemhuis.info> Message-ID: <20070413201850.GC4590@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > > == Composition == > > * Jesse Keating (f13) > > * Josh Boyer (jwb) > > * Bill Nottingham (notting) > > * Jeremy Katz (katzj) > > * [Please fill in and correct] > > I'd say the maybe the body that makes the decisions should have a > defined size. Maybe 7 or 9 members -- that's not to much (otherwise > nobody might feel responsible) and not to less (to much work for > everyone). The size of the group/team/SIG itself of course is not limited. OK, this is where I start yelling. We've got a release coming up, and we need to coordinate to make sure things get done. So a proposal is made on how to make sure the right people meet with the right people to get things done and organized. So, of course, it then moves to: - discussion of meeting times - naming of representatives suggestions of representatives - agenda for the first meeting - discussion of blockers Wait, no, *all the discussion is around GROUP SIZE and MAILING LIST NAMES*? Gah. If people need people to write interminable process documents before they feel they can get involved, then we've screwed up this project so bad it's not funny. Bill From jkeating at redhat.com Fri Apr 13 20:24:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Apr 2007 16:24:12 -0400 Subject: RFC: Release team meetings In-Reply-To: <20070412212027.GB3357@nostromo.devel.redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> Message-ID: <200704131624.13163.jkeating@redhat.com> On Thursday 12 April 2007 17:20:27 Bill Nottingham wrote: > Time: TBD, pending approval of required attendees My Monday's look very clear, and Monday is a good day to figure out where we are and what needs to be done for the week. Any objections to a reasonable time on Monday, say 1700 UTC (1pm Eastern Time) in #fedora-meeting ? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Apr 13 20:37:48 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 13 Apr 2007 22:37:48 +0200 Subject: RFC: Release team meetings In-Reply-To: <20070413201850.GC4590@nostromo.devel.redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <1176413487.25283.2.camel@vader.jdub.homelinux.org> <461F0F81.7010603@leemhuis.info> <200704130904.01185.jkeating@redhat.com> <1176492447.11234.77.camel@localhost.localdomain> <461FE422.1000705@leemhuis.info> <20070413201850.GC4590@nostromo.devel.redhat.com> Message-ID: <461FEA1C.1050104@leemhuis.info> Bill Nottingham schrieb: > Thorsten Leemhuis (fedora at leemhuis.info) said: >>> == Composition == >>> * Jesse Keating (f13) >>> * Josh Boyer (jwb) >>> * Bill Nottingham (notting) >>> * Jeremy Katz (katzj) >>> * [Please fill in and correct] >> I'd say the maybe the body that makes the decisions should have a >> defined size. Maybe 7 or 9 members -- that's not to much (otherwise >> nobody might feel responsible) and not to less (to much work for >> everyone). The size of the group/team/SIG itself of course is not limited. > > OK, this is where I start yelling. > > We've got a release coming up, and we need to coordinate to make sure things > get done. So a proposal is made on how to make sure the right people meet > with the right people to get things done and organized. As I indicated earlier in this thread multiple time already: I'm fine with finding a rough and easy scheme for now and sorting details like... > So, of course, it then moves to: > - discussion of meeting times > - naming of representatives suggestions of representatives > - agenda for the first meeting > - discussion of blockers > > Wait, no, *all the discussion is around GROUP SIZE and MAILING LIST NAMES*? ...out after F7. Toshio just asked for comments and I gave some. Yeah, maybe I should have kept that one out for now ;-) Sorry. > [...] CU thl From notting at redhat.com Fri Apr 13 20:46:00 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 13 Apr 2007 16:46:00 -0400 Subject: RFC: Release team meetings In-Reply-To: <200704131624.13163.jkeating@redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704131624.13163.jkeating@redhat.com> Message-ID: <20070413204600.GA5713@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > > Time: TBD, pending approval of required attendees > > My Monday's look very clear, and Monday is a good day to figure out where we > are and what needs to be done for the week. Any objections to a reasonable > time on Monday, say 1700 UTC (1pm Eastern Time) in #fedora-meeting ? Not sure everyone who may need to be there is on this list. CC'ing some more people. Background: we'd like to start having weekly meetings to discuss the state of the release, potential slips, etc. More information is at: http://fedoraproject.org/wiki/BillNottingham/ReleaseMeetingsDraft As leaders/prominent members of the projects mentioned in the initial draft, we'd like to know your availability (or a delegate's availability) for the meeting. Jesse has suggested Mondays, 1700 UTC (1PM Eastern). Is this suitable? Bill From davej at redhat.com Fri Apr 13 20:49:15 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 13 Apr 2007 16:49:15 -0400 Subject: RFC: Release team meetings In-Reply-To: <20070413204600.GA5713@nostromo.devel.redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704131624.13163.jkeating@redhat.com> <20070413204600.GA5713@nostromo.devel.redhat.com> Message-ID: <20070413204915.GG27682@redhat.com> On Fri, Apr 13, 2007 at 04:46:00PM -0400, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > > Time: TBD, pending approval of required attendees > > > > My Monday's look very clear, and Monday is a good day to figure out where we > > are and what needs to be done for the week. Any objections to a reasonable > > time on Monday, say 1700 UTC (1pm Eastern Time) in #fedora-meeting ? > > Not sure everyone who may need to be there is on this list. CC'ing some > more people. > > Background: we'd like to start having weekly meetings to discuss the > state of the release, potential slips, etc. > > More information is at: > > http://fedoraproject.org/wiki/BillNottingham/ReleaseMeetingsDraft > > As leaders/prominent members of the projects mentioned in the initial draft, we'd > like to know your availability (or a delegate's availability) for the meeting. > > Jesse has suggested Mondays, 1700 UTC (1PM Eastern). Is this suitable? ACK. Dave -- http://www.codemonkey.org.uk From mmcgrath at redhat.com Fri Apr 13 20:50:54 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 13 Apr 2007 15:50:54 -0500 Subject: RFC: Release team meetings In-Reply-To: <20070413204915.GG27682@redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704131624.13163.jkeating@redhat.com> <20070413204600.GA5713@nostromo.devel.redhat.com> <20070413204915.GG27682@redhat.com> Message-ID: <461FED2E.6040101@redhat.com> > > Jesse has suggested Mondays, 1700 UTC (1PM Eastern). Is this suitable? > I'll be there. -Mike From wwoods at redhat.com Fri Apr 13 21:35:15 2007 From: wwoods at redhat.com (Will Woods) Date: Fri, 13 Apr 2007 17:35:15 -0400 Subject: RFC: Release team meetings In-Reply-To: <20070413204600.GA5713@nostromo.devel.redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704131624.13163.jkeating@redhat.com> <20070413204600.GA5713@nostromo.devel.redhat.com> Message-ID: <1176500115.5178.72.camel@metroid.rdu.redhat.com> On Fri, 2007-04-13 at 16:46 -0400, Bill Nottingham wrote: > As leaders/prominent members of the projects mentioned in the initial draft, we'd > like to know your availability (or a delegate's availability) for the meeting. > > Jesse has suggested Mondays, 1700 UTC (1PM Eastern). Is this suitable? Sounds good to me. -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 a.badger at gmail.com Fri Apr 13 21:44:22 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 13 Apr 2007 14:44:22 -0700 Subject: RFC: Release team meetings In-Reply-To: <20070413192910.GB7462@nostromo.devel.redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <1176413487.25283.2.camel@vader.jdub.homelinux.org> <461F0F81.7010603@leemhuis.info> <200704130904.01185.jkeating@redhat.com> <1176492447.11234.77.camel@localhost.localdomain> <20070413192910.GB7462@nostromo.devel.redhat.com> Message-ID: <1176500662.11234.136.camel@localhost.localdomain> On Fri, 2007-04-13 at 15:29 -0400, Bill Nottingham wrote: > Toshio Kuratomi (a.badger at gmail.com) said: > > I don't think there needs to be a lot of governance, just some > > information on who's doing what. Jesse, Thorsten, releng team, what do > > you think of this proposal: > > Well, there's a dichotomoy here - there's the 'release engineering team' > (rel-eng at fedoraproject.org) which you have described. However, for this > meeting, there is essentially the *release* team, which consists of members > from rel-eng, qa, docs, etc. The meeting is for the release team; if rel-eng > also wants to have meetings, that can happen. > Ah okay. In that case, I see no reason for there to be "governance" per se for a release team meeting. I would think that the releng team, since they're going to bear the brunt of getting the release out the door on time, should be in charge of the meeting (to make sure they get what they need to coordinate the release) but governance is for groups that need to work on a project together for a longer period of time. This sounds more like a status report and temporary collaboration by people who need to coordinate for a short period of time before release. -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 jwboyer at jdub.homelinux.org Sat Apr 14 11:46:58 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 14 Apr 2007 06:46:58 -0500 Subject: RFC: Release team meetings In-Reply-To: <200704131624.13163.jkeating@redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704131624.13163.jkeating@redhat.com> Message-ID: <1176551218.25283.10.camel@vader.jdub.homelinux.org> On Fri, 2007-04-13 at 16:24 -0400, Jesse Keating wrote: > On Thursday 12 April 2007 17:20:27 Bill Nottingham wrote: > > Time: TBD, pending approval of required attendees > > My Monday's look very clear, and Monday is a good day to figure out where we > are and what needs to be done for the week. Any objections to a reasonable > time on Monday, say 1700 UTC (1pm Eastern Time) in #fedora-meeting ? I have a standing meeting at 17:30UTC, but this should still be ok. josh From jwboyer at jdub.homelinux.org Sat Apr 14 13:50:46 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 14 Apr 2007 08:50:46 -0500 Subject: RFC: Release team meetings In-Reply-To: <461FA68A.1060208@leemhuis.info> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <1176413487.25283.2.camel@vader.jdub.homelinux.org> <461F0F81.7010603@leemhuis.info> <200704130904.01185.jkeating@redhat.com> <461FA68A.1060208@leemhuis.info> Message-ID: <1176558646.25283.14.camel@vader.jdub.homelinux.org> On Fri, 2007-04-13 at 17:49 +0200, Thorsten Leemhuis wrote: > Jason L Tibbitts III schrieb: > >>>>>> "JK" == Jesse Keating writes: > > > > JK> Sure it's neat information to have, but for the sake of getting a > > JK> few people together to get some work done, I really don't want to > > JK> have to go through the headache of creating all this red tape and > > JK> governance. > > > > As far as I can tell all you really need is something that tells > > people where to look if they want to become involved in the process. > > What list should they join (if there's a list)? What IRC channel > > should they join (if there's IRC discussion)? If you decide to have > > meetings (and nothing requires that as far as I can see) then say when > > and where the meetings are held. > > > > That's about it. > > Agreed if you add a "post a summary of important decisions so the public > and FESCo (and thus the board) know what got decided" To clarify, there actually haven't been very many discussions so far. A few update requests during the freeze, and that's about it. What Bill proposed would actually _be_ the first important discussion. Everything of sufficient importance has so far been discussed in public or at least disclosed to the public shortly thereafter. Do not mistake silence for a cabal. Sometimes there just aren't any discussions going on :). josh From jkeating at redhat.com Mon Apr 16 12:01:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 16 Apr 2007 08:01:49 -0400 Subject: RFC: Release team meetings In-Reply-To: <20070413204600.GA5713@nostromo.devel.redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704131624.13163.jkeating@redhat.com> <20070413204600.GA5713@nostromo.devel.redhat.com> Message-ID: <200704160801.50696.jkeating@redhat.com> On Friday 13 April 2007 16:46:00 Bill Nottingham wrote: > Not sure everyone who may need to be there is on this list. CC'ing some > more people. > > Background: we'd like to start having weekly meetings to discuss the > state of the release, potential slips, etc. > > More information is at: > > http://fedoraproject.org/wiki/BillNottingham/ReleaseMeetingsDraft > > As leaders/prominent members of the projects mentioned in the initial > draft, we'd like to know your availability (or a delegate's availability) > for the meeting. > > Jesse has suggested Mondays, 1700 UTC (1PM Eastern). Is this suitable? So far we have an ack from me, Bill N, Dave J, Mike McG, Will Woods, Josh Boyer. Still seeking input from jrb, mclasen, Rex, dimitris, Karsten, aalam, and the rest of the rel-eng team. Notably we're missing somebody from the installer team, somebody from Base OS (all the non-desktop userland type stuff), and maybe tools folks like the gcc/glibc folks (adding jakub). Please reply as soon as possible so that I can allocate this time today. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Apr 16 13:03:37 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 16 Apr 2007 08:03:37 -0500 Subject: RFC: Release team meetings In-Reply-To: <200704160801.50696.jkeating@redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704131624.13163.jkeating@redhat.com> <20070413204600.GA5713@nostromo.devel.redhat.com> <200704160801.50696.jkeating@redhat.com> Message-ID: <46237429.4090403@math.unl.edu> Jesse Keating wrote: > On Friday 13 April 2007 16:46:00 Bill Nottingham wrote: >> Jesse has suggested Mondays, 1700 UTC (1PM Eastern). Is this suitable? > > So far we have an ack from me, Bill N, Dave J, Mike McG, Will Woods, Josh > Boyer. Still seeking input from jrb, mclasen, Rex... ACK. -- Rex From dimitris at glezos.com Mon Apr 16 13:56:29 2007 From: dimitris at glezos.com (Dimitris Glezos) Date: Mon, 16 Apr 2007 14:56:29 +0100 Subject: RFC: Release team meetings In-Reply-To: <20070413204600.GA5713@nostromo.devel.redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704131624.13163.jkeating@redhat.com> <20070413204600.GA5713@nostromo.devel.redhat.com> Message-ID: <4623808D.7020507@glezos.com> O/H Bill Nottingham ??????: > Background: we'd like to start having weekly meetings to discuss the > state of the release, potential slips, etc. > > More information is at: > > http://fedoraproject.org/wiki/BillNottingham/ReleaseMeetingsDraft > > As leaders/prominent members of the projects mentioned in the initial draft, we'd > like to know your availability (or a delegate's availability) for the meeting. > > Jesse has suggested Mondays, 1700 UTC (1PM Eastern). Is this suitable? ack. -d -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From tibbs at math.uh.edu Mon Apr 16 15:16:00 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 Apr 2007 10:16:00 -0500 Subject: RFC: Release team meetings In-Reply-To: <20070413204600.GA5713@nostromo.devel.redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704131624.13163.jkeating@redhat.com> <20070413204600.GA5713@nostromo.devel.redhat.com> Message-ID: >>>>> "BN" == Bill Nottingham writes: BN> Background: we'd like to start having weekly meetings to discuss BN> the state of the release, potential slips, etc. I know this isn't the right channel, but at this point I'm not sure that the proper channel has even be decided. I just want to ask if it would be appropriate for release team to consider the whole cdrkit mash-up and if so if they could please do that as soon as possible. For background, cdrkit replaces (i.d. Obsoletes: and Provides:) the old CD-writing stack, but cdrkit is in extras and the old stack is in Core and seems to still be receiving updates. So one needs to go or users feel pain. I reviewed cdrkit originally and asked people and found that the old stack was slated for deletion, but that never happened. - J< From kwade at redhat.com Mon Apr 16 15:20:36 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 16 Apr 2007 08:20:36 -0700 Subject: RFC: Release team meetings In-Reply-To: <20070413204600.GA5713@nostromo.devel.redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704131624.13163.jkeating@redhat.com> <20070413204600.GA5713@nostromo.devel.redhat.com> Message-ID: <1176736836.3286.59.camel@erato.phig.org> On Fri, 2007-04-13 at 16:46 -0400, Bill Nottingham wrote: > Jesse has suggested Mondays, 1700 UTC (1PM Eastern). Is this suitable? ACK - 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 Mon Apr 16 16:03:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 16 Apr 2007 12:03:01 -0400 Subject: RFC: Release team meetings In-Reply-To: <200704160801.50696.jkeating@redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <20070413204600.GA5713@nostromo.devel.redhat.com> <200704160801.50696.jkeating@redhat.com> Message-ID: <200704161203.01698.jkeating@redhat.com> On Monday 16 April 2007 08:01:49 Jesse Keating wrote: > On Friday 13 April 2007 16:46:00 Bill Nottingham wrote: > > Not sure everyone who may need to be there is on this list. CC'ing some > > more people. > > > > Background: we'd like to start having weekly meetings to discuss the > > state of the release, potential slips, etc. > > > > More information is at: > > > > http://fedoraproject.org/wiki/BillNottingham/ReleaseMeetingsDraft > > > > As leaders/prominent members of the projects mentioned in the initial > > draft, we'd like to know your availability (or a delegate's availability) > > for the meeting. > > > > Jesse has suggested Mondays, 1700 UTC (1PM Eastern). Is this suitable? > > So far we have an ack from me, Bill N, Dave J, Mike McG, Will Woods, Josh > Boyer. Still seeking input from jrb, mclasen, Rex, dimitris, Karsten, > aalam, and the rest of the rel-eng team. > > Notably we're missing somebody from the installer team, somebody from Base > OS (all the non-desktop userland type stuff), and maybe tools folks like > the gcc/glibc folks (adding jakub). Please reply as soon as possible so > that I can allocate this time today. Enough people has said yes. We'll be doing this as an IRC meeting on Freenode IRC network, #fedora-meeting. See ya'll in an hour. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Mon Apr 16 17:56:40 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 16 Apr 2007 13:56:40 -0400 Subject: RFC: Release team meetings In-Reply-To: References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704131624.13163.jkeating@redhat.com> <20070413204600.GA5713@nostromo.devel.redhat.com> Message-ID: <20070416175640.GE5800@nostromo.devel.redhat.com> Jason L Tibbitts III (tibbs at math.uh.edu) said: > I know this isn't the right channel, but at this point I'm not sure > that the proper channel has even be decided. I just want to ask if it > would be appropriate for release team to consider the whole cdrkit > mash-up and if so if they could please do that as soon as possible. > > For background, cdrkit replaces (i.d. Obsoletes: and Provides:) the > old CD-writing stack, but cdrkit is in extras and the old stack is in > Core and seems to still be receiving updates. So one needs to go or > users feel pain. I reviewed cdrkit originally and asked people and > found that the old stack was slated for deletion, but that never > happened. Sure, bring it up. You can also send to rel-eng at fedoraproject.org, cc'ing both the extras cdrkit and core old-stuff maintainer. Bill From jkeating at redhat.com Mon Apr 16 21:47:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 16 Apr 2007 17:47:14 -0400 Subject: RFC: Release team meetings In-Reply-To: <1176492447.11234.77.camel@localhost.localdomain> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704130904.01185.jkeating@redhat.com> <1176492447.11234.77.camel@localhost.localdomain> Message-ID: <200704161747.14312.jkeating@redhat.com> On Friday 13 April 2007 15:27:27 Toshio Kuratomi wrote: > I don't think there needs to be a lot of governance, just some > information on who's doing what. ?Jesse, Thorsten, releng team, what do > you think of this proposal: FYI, I've tossed and edited this up at http://fedoraproject.org/wiki/ReleaseEngineering -- 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 max at spevack.org Tue Apr 17 00:12:08 2007 From: max at spevack.org (Max Spevack) Date: Mon, 16 Apr 2007 20:12:08 -0400 (EDT) Subject: Board Meeting, 2007-04-17 Message-ID: We have a Board meeting at 10:00 AM EDT, 14:00 GMT, tomorrow. Sorry for the late reminder. Here's what I'd like to do with tomorrow's meeting. One of the things that has been talked around, but needs to be solidified by the Board, is giving clarity to exactly what sort of topics FESCO should be responsible for deciding. I know that in particular thl and bpepple have shared some of their thoughts with me off-list. So I'd like to use tomorrow's time to have that discussion in #fedora-meeting, with whoever is available from FESCO to feel free to join in. Hopefully we can make some decisions and start to put a clear line in place. I think some of this exists already, but it doesn't hurt to solidify it. Like last week, we'll do the whole thing on IRC, but this time instead of having a release meeting, we'll talk about these specific governance questions. Thanks, and sorry for the somewhat shorter than usual notice. --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 skvidal at linux.duke.edu Tue Apr 17 02:34:36 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 16 Apr 2007 22:34:36 -0400 Subject: Board Meeting, 2007-04-17 In-Reply-To: References: Message-ID: <1176777276.26357.7.camel@cutter> On Mon, 2007-04-16 at 20:12 -0400, Max Spevack wrote: > We have a Board meeting at 10:00 AM EDT, 14:00 GMT, tomorrow. Sorry for > the late reminder. > > Here's what I'd like to do with tomorrow's meeting. > > One of the things that has been talked around, but needs to be solidified > by the Board, is giving clarity to exactly what sort of topics FESCO > should be responsible for deciding. I know that in particular thl and > bpepple have shared some of their thoughts with me off-list. > > So I'd like to use tomorrow's time to have that discussion in > #fedora-meeting, with whoever is available from FESCO to feel free to join > in. Hopefully we can make some decisions and start to put a clear line in > place. I think some of this exists already, but it doesn't hurt to > solidify it. > > Like last week, we'll do the whole thing on IRC, but this time instead of > having a release meeting, we'll talk about these specific governance > questions. > > Thanks, and sorry for the somewhat shorter than usual notice. I will probably not be able to be there tomorrow. I'll try but right now I'm 'borrowing' internet access until wednesday and I'm only half-way around due to moving some final things. :) If I'm there, I'll say hi, but don't expect me. thanks, -sv From poelstra at redhat.com Tue Apr 17 04:36:50 2007 From: poelstra at redhat.com (John Poelstra) Date: Mon, 16 Apr 2007 21:36:50 -0700 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 Message-ID: <46244EE2.5060002@redhat.com> Formatted text and full IRC log here: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-apr-16 Please make edits to the wiki if I've mis-characterized an issue or left something out. John == Executive Summary == 1. Freezing for Test4 tomorrow (17-APR-07) * f13 to create tag and start signing packages on 17-APR-07 * start of continuous freeze until Fedora 7 goes GOLD * potential checkins for F8 starting in June (assuming all goes well) * any builds will have to be brought to rel-eng at fedoraproject.org before it'll get included in: a. Rawhide a. the final release. * Eventually need documentation surrounding the freeze and distro build process 1. Merge of extras and core * will not delay F7 * will most likely not be completed until after F7 * held up because of equipment needed in the colo * post-merge some packages will need to be rebuilt to pick up deps that used to be in Extras 1. In the future we should consider a mass rebuild of all packages around, but no later than test2 1. Still working on increasing build capacity 1. Discussion of Features * incomplete features at this stage of the release will be dropped * incomplete features will not block the release * poelcat will go ping feature owners and update the wiki * Unclear whether codecbuddy is in or out: controversy over whether it should block the release or not * Known feature which are OUT: boot/shutdown, customdistro (as written) fix wakeups, newinit, syslogng, texlive * Known feature which are IN: fast-user-switching, fds, everything, kde, prime, targeted spins, firewire, libata, livecd, nouveau, rpm/yum, wireless, tickless, pungi, firmware, smolt 1. wwoods reported on the state of the trees + discussion of important areas needing testing * looking pretty solid * most concerned about the pata/libata changeover * concerns about iwlwifi and e1000 changes * upgrade testing from FC6 and FC5 * automated testing is being conducted using KATE * SNAKE scheduled for release around May 3 * Friday is a kernel bug triaging day * bad mkinitrd bug which hoses scsi *BZ 220470 1. wwoods will write the test4 announcement which will include known problems, newly added features, and upgrade issues 1. Blocker bugs * Blocker bugs are best effort; not *all* blocker bugs must be fixed to go GA * Blocker bug criteria: http://fedoraproject.org/wiki/QA/ReleaseCriteria * F7 blocker bug https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=150226 is the big blocker for FC7 * F7T4 blocker bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=F7Test4 1. Potential schedule slips * none known at this time 1. Open discussion * cdrkit * need to decide what to do with it * Extras vs. Core and when to merge * wwoods "I got confirmation from the bluez maintainer that the firmware is freely redistributable (although non-modifiable), just like the intel firmware" 1. Next Release Engineering Meeting * Thursday 19-APR-07 at 18:00 UTC (14:00 EDT) * Coordination of sub-groups * Test4 status * When should we branch for F8? From fedora at leemhuis.info Tue Apr 17 04:58:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Apr 2007 06:58:52 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <46244EE2.5060002@redhat.com> References: <46244EE2.5060002@redhat.com> Message-ID: <4624540C.7010109@leemhuis.info> > 1. In the future we should consider a mass rebuild of all packages > around, but no later than test2 Hmmm, this was discussed in depth at the end of this thread: https://www.redhat.com/archives/fedora-packaging/2007-April/msg00017.html Some people would like to see a mass rebuild, some others are against it. I'm one of those against it. Reasons: - Seems we have quite some users in country were internet bandwidth is unreliable and costly. If we mass-rebuild everything each time those users have to download a lot of new stuff where nothing changed besides the release. that makes Fedora harder to use for them. - the update process gets much longer for each and everyone of us if each package has to be downloaded and updated. - the packages out in the wild are tested and known to work. Rebuild packages have to proof again that everything is fine (which should be the case most of the time, but in rare cases isn't) IOW: The benefits of a mass rebuild *each* devel cycle is IMHO not worth the trouble we create for our users. I think a mass rebuild now and then when the toolchain (things like gcc or other crucial stuff like rpm, python,...) changed massively (round about probably every second or third release cycle) is more then enough. CU thl From davej at redhat.com Tue Apr 17 05:48:14 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 17 Apr 2007 01:48:14 -0400 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <4624540C.7010109@leemhuis.info> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> Message-ID: <20070417054814.GA11690@redhat.com> On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote: > > 1. In the future we should consider a mass rebuild of all packages > > around, but no later than test2 > > Hmmm, this was discussed in depth at the end of this thread: > https://www.redhat.com/archives/fedora-packaging/2007-April/msg00017.html > Some people would like to see a mass rebuild, some others are against it. > > I'm one of those against it. Reasons: > - Seems we have quite some users in country were internet bandwidth is > unreliable and costly. If we mass-rebuild everything each time those > users have to download a lot of new stuff where nothing changed besides > the release. that makes Fedora harder to use for them. And these users are running rawhide ? > - the update process gets much longer for each and everyone of us if > each package has to be downloaded and updated. > - the packages out in the wild are tested and known to work. Rebuild > packages have to proof again that everything is fine (which should be > the case most of the time, but in rare cases isn't) > > IOW: The benefits of a mass rebuild *each* devel cycle is IMHO not worth > the trouble we create for our users. I think a mass rebuild now and then > when the toolchain (things like gcc or other crucial stuff like rpm, > python,...) changed massively (round about probably every second or > third release cycle) is more then enough. Yeah, I'll agree with that. Off the top of my head, I can come up with three scenarios where rebuilds make sense. - Considerable bugfixes which fix up bad code generation. - new/enhanced features (such as more FORTIFY_SOURCE improvements) - new optimisations (We could even narrow the scope on this one to rebuild just packages that would show a notable difference. Ie, don't bother rebuilding fileutils, but do rebuild say, bzip2). Taking a look at the packages in my f7 mirror, I spot 52 packages that still have a .fc6 tag, none of which look particularly "omg, we have to rebuild this". There are also 713 with no %{dist} tag which include some which we definitly have rebuilt, so it's harder to figure out which of those got updated and which didn't. Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Tue Apr 17 06:22:44 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Apr 2007 08:22:44 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070417054814.GA11690@redhat.com> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417054814.GA11690@redhat.com> Message-ID: <462467B4.8000608@leemhuis.info> On 17.04.2007 07:48, Dave Jones wrote: > On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote: > > > 1. In the future we should consider a mass rebuild of all packages > > > around, but no later than test2 > > Hmmm, this was discussed in depth at the end of this thread: > > https://www.redhat.com/archives/fedora-packaging/2007-April/msg00017.html > > Some people would like to see a mass rebuild, some others are against it. > > > > I'm one of those against it. Reasons: > > - Seems we have quite some users in country were internet bandwidth is > > unreliable and costly. If we mass-rebuild everything each time those > > users have to download a lot of new stuff where nothing changed besides > > the release. that makes Fedora harder to use for them. > And these users are running rawhide ? Probably not, but they will have to download and install the new packages that got build during the mass-rebuild when they do the Fedora (x) -> Fedora (x+1 or x+2) update. Currently packages where nothing changed in between simply stay installed and no action is needed. > > - the update process gets much longer for each and everyone of us if > > each package has to be downloaded and updated. > > - the packages out in the wild are tested and known to work. Rebuild > > packages have to proof again that everything is fine (which should be > > the case most of the time, but in rare cases isn't) > > > > IOW: The benefits of a mass rebuild *each* devel cycle is IMHO not worth > > the trouble we create for our users. I think a mass rebuild now and then > > when the toolchain (things like gcc or other crucial stuff like rpm, > > python,...) changed massively (round about probably every second or > > third release cycle) is more then enough. > > Yeah, I'll agree with that. > Off the top of my head, I can come up with three scenarios where > rebuilds make sense. > > - Considerable bugfixes which fix up bad code generation. > - new/enhanced features (such as more FORTIFY_SOURCE improvements) > - new optimisations > (We could even narrow the scope on this one to rebuild just > packages that would show a notable difference. Ie, don't > bother rebuilding fileutils, but do rebuild say, bzip2). +1 > Taking a look at the packages in my f7 mirror, I spot 52 packages > that still have a .fc6 tag, none of which look particularly > "omg, we have to rebuild this". There are also 713 with no %{dist} tag > which include some which we definitly have rebuilt, so it's harder > to figure out which of those got updated and which didn't. Some numbers: $ fc6release=$(date -d "24 Oct 2006" +%s); sudo repoquery --repoid=development-source --repoid=extras-development-source --archlist="src" -qa --qf '%{buildtime} %{name}' | sort | while read date name; do [[ ${date} < ${fc6release} ]] && echo ${date} ${name} || break ; done | wc -l 1206 $ sudo repoquery --repoid=development-source --repoid=extras-development-source --archlist="src" -qa --qf '%{buildtime} %{name}' | wc -l 4073 $ echo $((4073-1206)) 2867 IOW: 1206 out of 4073 source packages were not rebuild in devel (both core and extras) between release of FC6 and now. CU thl From Axel.Thimm at ATrpms.net Tue Apr 17 07:42:04 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 17 Apr 2007 09:42:04 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <462467B4.8000608@leemhuis.info> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417054814.GA11690@redhat.com> <462467B4.8000608@leemhuis.info> Message-ID: <20070417074204.GF5695@neu.nirvana> On Tue, Apr 17, 2007 at 08:22:44AM +0200, Thorsten Leemhuis wrote: > On 17.04.2007 07:48, Dave Jones wrote: > >On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote: > > > > 1. In the future we should consider a mass rebuild of all packages > > > > around, but no later than test2 > >Taking a look at the packages in my f7 mirror, I spot 52 packages > >that still have a .fc6 tag, none of which look particularly > >"omg, we have to rebuild this". There are also 713 with no %{dist} tag > >which include some which we definitly have rebuilt, so it's harder > >to figure out which of those got updated and which didn't. > > Some numbers: > $ echo $((4073-1206)) > 2867 > > IOW: 1206 out of 4073 source packages were not rebuild in devel (both > core and extras) between release of FC6 and now. But that's by choice and now what the usual Fedora policy was until now. Here is the historical data, that shows that we've been doing effectively full rebuilds ever until now. On Tue, Apr 10, 2007 at 03:33:29PM +0200, Axel Thimm wrote: > Here are the numbers of the amount of Core packages rebuilt per > release. FC1 gets 100% because I don't have the RHL9 packages handy, > but anyway (for > 99% I added as many digits as neccessary to show > what wasn't rebuilt): > > 1 100% > 2 99.7% > 3 100% > 4 96.6% > 5 99.991% > 6 95% > 7 80% > > So as you see, up to F7 Core had really been effectively rebuilt on > each release with FC4 and FC5 being the most "sloppy" ones leaving > 3.4% and 5% resp. not rebuilt. With F7 Core drops down to 80% > rebuild > rate. This *is* a new release model. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Apr 17 08:13:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 17 Apr 2007 10:13:11 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <4624540C.7010109@leemhuis.info> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> Message-ID: <20070417081311.GG5695@neu.nirvana> On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote: > > > 1. In the future we should consider a mass rebuild of all packages > >around, but no later than test2 > > Hmmm, this was discussed in depth at the end of this thread: > https://www.redhat.com/archives/fedora-packaging/2007-April/msg00017.html > Some people would like to see a mass rebuild, some others are against it. > > I'm one of those against it. Reasons: I'm one of those for it. > - Seems we have quite some users in country were internet bandwidth is > unreliable and costly. If we mass-rebuild everything each time those > users have to download a lot of new stuff where nothing changed besides > the release. that makes Fedora harder to use for them. The big players that are always on the user's choicelist are being rebuilt almost by definition. The savings are therefore marginal at best. > - the update process gets much longer for each and everyone of us if > each package has to be downloaded and updated. > - the packages out in the wild are tested and known to work. Rebuild > packages have to proof again that everything is fine (which should be > the case most of the time, but in rare cases isn't) That's a contradiction: Either the packages are stable and will survive a rebuild, or they are fragile enough to break apart if they are rebuilt in the current environment. Furthermore the testing these packages have received was on another release offering a different build and run-time environment, so they may not be as stable or tested as you think they are. The dangers of letting packages go to seed are the following: o non deterministic package rebuilds: It is not guaranteed that some package will rebuild and function the same for the current release (we may have automated rebuild facilities, but no one tests runtime behaviour), a simple rebuild may unearth that the package needs further attention (in fact that is Thorsten's argument to not rebuild, but the attention will be needed, the question is when to spend the time on it, see below) o slow security responses: A one-line fix may result to a package breaking due to the above. This means that security issues may start shipping broken packages out, or may require more time in QA to ensure that an ancient-not-rebuilt package really properly works. o The choice of what to rebuild or not requires more developer time than fixing broken rebuilds: Currently some heuristics were uses to cherry-pick what to rebuild. This requires a careful examination that if doen properly consumes as much or more developer time than to fix any broken rebuilds. If not done careful, then some dependencies will be missed. For example the current upgrade sees the following changes in the buildtools FC6 F7 gcc 4.1.1-30 4.1.2-8 glibc 2.5-3 2.5.90-20 binutils 2.17.50.0.3-6 2.17.50.0.12-3 Perhaps the gcc or binutils changes are not that big, but the glibc ones seem to be, e.g. 2.5.90 is the prequel to 2.6 and just checking the API (the glibc-headers) gives: 41 files changed, 297 insertions(+), 220 deletions(-) Other examples are packages (like bridge-utils) being built against kernel-headers. F7 is now shipping a bridge-utils that was built agains 2.6.18 kernel headers at the very beginning of the FC6 cycle. The questions that come up are: Did anyone check whether the bridging interface of the kernel changed between 2.6.18-21? Were any interfaces deprecated? Will bridge-utils work on F7, if not will a rebuild suffice? I've picked bridge-utils as an example as it was the first package that looked suspicious when I looked at an alphabetical list, that doesn't mean that bridge-utils is now broken. Still the questions raised are valid for any package depending on kernel-headers. o Moving bugs from development cycle to maintenance cycle: Effectively the argument for not rebuilding during development time and breaking N fragile packages means that once these N broken packages are spotted after the release they will need the developer's attention just the same. We are only moving the bugs from the devlopment cycle to mainenance. Do we really want that? From a technical and *marketing* POV we don't. It is better to ship a good release from the start, than to stumble over rebuild bugs over and over again, and that includes both deelopers and now users. And from a *business* POV the resources that are spent are the same, someone must fix the packages. So let's do it during the development cycle instead of during maintenance where the users will feel like guinea pigs. In a nutshell: There are no significant savings in user downloads, and there are no savings in developer resources when not rebuilding packages to match the upcoming release environment. But there is bad publicity if packages will break after the release and this could had been prevented with a simple mass rebuild during devlopment time instead of outsourcing this to the maintenance cycle. -- 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 Tue Apr 17 08:14:15 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Apr 2007 10:14:15 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070417074204.GF5695@neu.nirvana> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417054814.GA11690@redhat.com> <462467B4.8000608@leemhuis.info> <20070417074204.GF5695@neu.nirvana> Message-ID: <462481D7.5050802@leemhuis.info> On 17.04.2007 09:42, Axel Thimm wrote: > On Tue, Apr 17, 2007 at 08:22:44AM +0200, Thorsten Leemhuis wrote: >> On 17.04.2007 07:48, Dave Jones wrote: >>> On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote: >>>>> 1. In the future we should consider a mass rebuild of all packages >>>>> around, but no later than test2 >>> Taking a look at the packages in my f7 mirror, I spot 52 packages >>> that still have a .fc6 tag, none of which look particularly >>> "omg, we have to rebuild this". There are also 713 with no %{dist} tag >>> which include some which we definitly have rebuilt, so it's harder >>> to figure out which of those got updated and which didn't. >> Some numbers: >> $ echo $((4073-1206)) >> 2867 >> IOW: 1206 out of 4073 source packages were not rebuild in devel (both >> core and extras) between release of FC6 and now. > > But that's by choice and now what the usual Fedora policy was until > now. There is no "policy" afaik. The maintainer simply decided what to do if no mass-rebuild was announced. There were for example mass rebuilds performed in FC6 and FE6. > Here is the historical data, that shows that we've been doing > effectively full rebuilds ever until now. [...] Just a heads up for the readers (as it's not obvious in the first sight): The data from Axel is for Core only afaics, my data included Extras. CU thl From Axel.Thimm at ATrpms.net Tue Apr 17 08:35:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 17 Apr 2007 10:35:15 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <462481D7.5050802@leemhuis.info> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417054814.GA11690@redhat.com> <462467B4.8000608@leemhuis.info> <20070417074204.GF5695@neu.nirvana> <462481D7.5050802@leemhuis.info> Message-ID: <20070417083515.GH5695@neu.nirvana> On Tue, Apr 17, 2007 at 10:14:15AM +0200, Thorsten Leemhuis wrote: > On 17.04.2007 09:42, Axel Thimm wrote: > >On Tue, Apr 17, 2007 at 08:22:44AM +0200, Thorsten Leemhuis wrote: > >>On 17.04.2007 07:48, Dave Jones wrote: > >>>On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote: > >>>>> 1. In the future we should consider a mass rebuild of all packages > >>>>>around, but no later than test2 > >>>Taking a look at the packages in my f7 mirror, I spot 52 packages > >>>that still have a .fc6 tag, none of which look particularly > >>>"omg, we have to rebuild this". There are also 713 with no %{dist} tag > >>>which include some which we definitly have rebuilt, so it's harder > >>>to figure out which of those got updated and which didn't. > >>Some numbers: > >>$ echo $((4073-1206)) > >>2867 > >>IOW: 1206 out of 4073 source packages were not rebuild in devel (both > >>core and extras) between release of FC6 and now. > > > >But that's by choice and now what the usual Fedora policy was until > >now. > > There is no "policy" afaik. The maintainer simply decided what to do if > no mass-rebuild was announced. There were for example mass rebuilds > performed in FC6 and FE6. Well, let's not play with wording, the numbers speak for themselves: In the history of Fedora until F7 both FC and FE did effectively full rebuilds. > >Here is the historical data, that shows that we've been doing > >effectively full rebuilds ever until now. > On Tue, Apr 10, 2007 at 03:33:29PM +0200, Axel Thimm wrote: > > Here are the numbers of the amount of Core packages rebuilt per > > release. FC1 gets 100% because I don't have the RHL9 packages handy, > > but anyway (for > 99% I added as many digits as neccessary to show > > what wasn't rebuilt): > > > > 1 100% > > 2 99.7% > > 3 100% > > 4 96.6% > > 5 99.991% > > 6 95% > > 7 80% > > > > So as you see, up to F7 Core had really been effectively rebuilt on > > each release with FC4 and FC5 being the most "sloppy" ones leaving > > 3.4% and 5% resp. not rebuilt. With F7 Core drops down to 80% > > rebuild > > rate. This *is* a new release model. > > Just a heads up for the readers (as it's not obvious in the first > sight): The data from Axel is for Core only afaics, my data included Extras. Well, I can include Extras, too, the data above was from a mail to Jesse when it was about Core. For Extras the numbers are far more striking, here is a common table including the FC data: FC FE 1 100% - 2 99.7% - 3 100% 100% 4 96.6% 99.4% 5 99.991% 99.0% 6 95% 99.4% 7 80% 62% So Extras was even closer to a complete rebuilds, leaving out 0.6% to 1% of packages at most until FC6 inclusive. Since FE has more packages the merged full repo will look more like FE's rebuild rates. But since the CD/DVD spins are made mostly out of former Core bits the actual rate of bugs found due to non-rebuilds will be closer to FC's. That's a bit comforting, since FC has seen some more rebuilds. We are on new territory with F7, both on the FC and FE side. Let's prey for the best. -- 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 Tue Apr 17 09:10:18 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Apr 2007 11:10:18 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070417083515.GH5695@neu.nirvana> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417054814.GA11690@redhat.com> <462467B4.8000608@leemhuis.info> <20070417074204.GF5695@neu.nirvana> <462481D7.5050802@leemhuis.info> <20070417083515.GH5695@neu.nirvana> Message-ID: <46248EFA.40304@leemhuis.info> On 17.04.2007 10:35, Axel Thimm wrote: > [...] > Well, I can include Extras, too, the data above was from a mail to > Jesse when it was about Core. For Extras the numbers are far more > striking, here is a common table including the FC data [...] Hmmm, do you sill have a tree of FE[3-6] how it looked like when FC[3-6] were released? Otherwise your numbers are IMHO totally misleading, as they show what got rebuild between release of FC[3-6] and *today*. CU thl From Axel.Thimm at ATrpms.net Tue Apr 17 09:32:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 17 Apr 2007 11:32:15 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <46248EFA.40304@leemhuis.info> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417054814.GA11690@redhat.com> <462467B4.8000608@leemhuis.info> <20070417074204.GF5695@neu.nirvana> <462481D7.5050802@leemhuis.info> <20070417083515.GH5695@neu.nirvana> <46248EFA.40304@leemhuis.info> Message-ID: <20070417093215.GM5695@neu.nirvana> On Tue, Apr 17, 2007 at 11:10:18AM +0200, Thorsten Leemhuis wrote: > On 17.04.2007 10:35, Axel Thimm wrote: > >[...] > >Well, I can include Extras, too, the data above was from a mail to > >Jesse when it was about Core. For Extras the numbers are far more > >striking, here is a common table including the FC data [...] > > Hmmm, do you sill have a tree of FE[3-6] how it looked like when FC[3-6] > were released? No, do you? > Otherwise your numbers are IMHO totally misleading, as they show > what got rebuild between release of FC[3-6] and *today*. No, they compare the latest state of FE and the latest state of FE. For FE5 and FE6 for example it compares the latest state as of today. For FE4 and FE5 it compares FE4's EOL date (~FC6) and today. So there is no time discrepancy as you assume. And it comes as no suprise since as we all should know FE was always doing mass rebuilds until including FC6. I wonder how the 0.6% and 1% were forgotten in the process. Perhaps someone did a rebuild with the same EVR - we didn't catch these in the old days. -- 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 Tue Apr 17 10:19:21 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Apr 2007 12:19:21 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070417093215.GM5695@neu.nirvana> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417054814.GA11690@redhat.com> <462467B4.8000608@leemhuis.info> <20070417074204.GF5695@neu.nirvana> <462481D7.5050802@leemhuis.info> <20070417083515.GH5695@neu.nirvana> <46248EFA.40304@leemhuis.info> <20070417093215.GM5695@neu.nirvana> Message-ID: <46249F29.9090003@leemhuis.info> On 17.04.2007 11:32, Axel Thimm wrote: > On Tue, Apr 17, 2007 at 11:10:18AM +0200, Thorsten Leemhuis wrote: >> On 17.04.2007 10:35, Axel Thimm wrote: >>> [...] >>> Well, I can include Extras, too, the data above was from a mail to >>> Jesse when it was about Core. For Extras the numbers are far more >>> striking, here is a common table including the FC data [...] >> Hmmm, do you sill have a tree of FE[3-6] how it looked like when FC[3-6] >> were released? > No, do you? No, sorry, I don't have any local Extras trees at all. >> Otherwise your numbers are IMHO totally misleading, as they show >> what got rebuild between release of FC[3-6] and *today*. > No, they compare the latest state of FE and the latest state of > FE. For FE5 and FE6 for example it compares the latest state as > of today. For FE4 and FE5 it compares FE4's EOL date (~FC6) and > today. So there is no time discrepancy as you assume. Assume package foo-1.0-1.noarch was in FE5 and devel. The FE6 got branched, so foo was not rebuild during that devel cycle (this is thus a example of a package we are up to: one that didn't get rebuild during a devel cycle). Some weeks later foo got a update to foo-1.1-1.noarch; it got build in both FE5, FE6 and FE-devel. Got a bugfix with foo-1.1-2.noarch; the old one foo-1.0-1.noarch gets deleted from the tree then, as we only ship the two latest versions. So how can your scripts detect now that foo-1.0-1.noarch wasn't rebuild during the devel-period FE5->FE6 by looking at todays repos? > And it comes as no suprise since as we all should know FE was always > doing mass rebuilds until including FC6. I wonder how the 0.6% and 1% > were forgotten in the process. Perhaps someone did a rebuild with the > same EVR - we didn't catch these in the old days. We never did full rebuilds. Data-packages never had to be rebuild. Noarch packages (python, perl) did not have to be rebuild during those mass rebuilds either iirc (but we adviced to do it when preparing FE6 iirc). CU thl From Axel.Thimm at ATrpms.net Tue Apr 17 11:05:48 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 17 Apr 2007 13:05:48 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <46249F29.9090003@leemhuis.info> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417054814.GA11690@redhat.com> <462467B4.8000608@leemhuis.info> <20070417074204.GF5695@neu.nirvana> <462481D7.5050802@leemhuis.info> <20070417083515.GH5695@neu.nirvana> <46248EFA.40304@leemhuis.info> <20070417093215.GM5695@neu.nirvana> <46249F29.9090003@leemhuis.info> Message-ID: <20070417110548.GN5695@neu.nirvana> On Tue, Apr 17, 2007 at 12:19:21PM +0200, Thorsten Leemhuis wrote: > >And it comes as no suprise since as we all should know FE was always > >doing mass rebuilds until including FC6. I wonder how the 0.6% and 1% > >were forgotten in the process. Perhaps someone did a rebuild with the > >same EVR - we didn't catch these in the old days. > > We never did full rebuilds. Data-packages never had to be rebuild. OK, that accounts for the 0.6-1% then. As you know I'm not advocating rebuilding stuff like firmware that are known to be content-invariant over time. -- 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 Tue Apr 17 11:31:49 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Apr 2007 13:31:49 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070417110548.GN5695@neu.nirvana> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417054814.GA11690@redhat.com> <462467B4.8000608@leemhuis.info> <20070417074204.GF5695@neu.nirvana> <462481D7.5050802@leemhuis.info> <20070417083515.GH5695@neu.nirvana> <46248EFA.40304@leemhuis.info> <20070417093215.GM5695@neu.nirvana> <46249F29.9090003@leemhuis.info> <20070417110548.GN5695@neu.nirvana> Message-ID: <4624B025.10205@leemhuis.info> On 17.04.2007 13:05, Axel Thimm wrote: > On Tue, Apr 17, 2007 at 12:19:21PM +0200, Thorsten Leemhuis wrote: >>> And it comes as no suprise since as we all should know FE was always >>> doing mass rebuilds until including FC6. I wonder how the 0.6% and 1% >>> were forgotten in the process. Perhaps someone did a rebuild with the >>> same EVR - we didn't catch these in the old days. >> We never did full rebuilds. Data-packages never had to be rebuild. > OK, that accounts for the 0.6-1% then. [...] Well, you carefully didn't reply to the part where I explained that you can't get to a proper number "how many packages weren't rebuild in the devel cycle FE5 -> FE6" by looking at todays repos. So the 0.6-1% are FUD in my eyes. I don't have hard numbers either -- but from memory I'd say we didn't rebuild round about 1/3 of the packages in the FE mass rebuild for FC6. Some of those not rebuild received updates earlier or later in the devel cycle. So if I should guess I'd say the number of packages that didn't get rebuild between FE5 and FE6 was somewhere between 7.5 and 25 percent. Maybe Ville has more data, he did a lot of work back then for the mass rebuild. CU thl /me will try to resist from this thread now, this doesn't lead to anything From jkeating at redhat.com Tue Apr 17 11:38:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Apr 2007 07:38:58 -0400 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <46244EE2.5060002@redhat.com> References: <46244EE2.5060002@redhat.com> Message-ID: <200704170739.02657.jkeating@redhat.com> First, thank you very much for doing this John, it is a BIG help. I have a couple corrections I'll make here and then in the wiki. On Tuesday 17 April 2007 00:36:50 John Poelstra wrote: > ? ? ?* Eventually need documentation surrounding the freeze and distro > build process As discussed, this would be for technical reason only, such as a toolchain change, a rpm format change, a discovered problem with Matt's on the side rebuild, etc... To the best of my knowledge, we are not planning mass rebuilds for the sake of mass rebuilds. > ? 1. Merge of extras and core > ? ? ?* will not delay F7 > ? ? ?* will most likely not be completed until after F7 Actually we still plan on merging before the release of F7. -- 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 Tue Apr 17 11:56:51 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 17 Apr 2007 13:56:51 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070417110039.GK355@devserv.devel.redhat.com> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417081311.GG5695@neu.nirvana> <20070417110039.GK355@devserv.devel.redhat.com> Message-ID: <20070417115651.GO5695@neu.nirvana> On Tue, Apr 17, 2007 at 07:00:39AM -0400, Jakub Jelinek wrote: > On Tue, Apr 17, 2007 at 10:13:11AM +0200, Axel Thimm wrote: > > o The choice of what to rebuild or not requires more developer time > > than fixing broken rebuilds: Currently some heuristics were uses to > > cherry-pick what to rebuild. This requires a careful examination > > that if doen properly consumes as much or more developer time than > > to fix any broken rebuilds. If not done careful, then some > > dependencies will be missed. For example the current upgrade sees > > the following changes in the buildtools > > > > FC6 F7 > > gcc 4.1.1-30 4.1.2-8 > > glibc 2.5-3 2.5.90-20 > > binutils 2.17.50.0.3-6 2.17.50.0.12-3 > > > > Perhaps the gcc or binutils changes are not that big, but the glibc > > ones seem to be, e.g. 2.5.90 is the prequel to 2.6 and just checking > > the API (the glibc-headers) gives: > > > > 41 files changed, 297 insertions(+), 220 deletions(-) > > Even the glibc changes in F7 are mostly glibc internal changes, bugfixes > and addition of a few new symbols (epoll_wait, sync_file_range, > strerror_l, __sched_cpucount) and only on PPC a new version for existing > symbols (pthread_attr_setstack{,size}). So neither gcc nor glibc > changes necessitate a mass rebuild (and I'm not aware of any huge changes > in redhat-rpm-config either) at this time and that's why F7 rebuild status > is so low. GCC 4.2 has been stagnating for 6 months now and we have > several important things backported anyway in GCC 4.1.x-RH (OpenMP, > visibility stuff, Java stack, numerous Fortran improvements, many bugfixes, > ...). When did these backports happen between 4.1.1-30 and 4.1.2-8 or earlier? > If gcc, binutils or glibc changes substantially in say F8, we'll > of course need to do a mass rebuild. gcc should finally have made it to 4.2 by then. > I'd note that sometimes it makes sense to rebuild all packages, including > noarch ones, e.g. when there are significant rpm-build, redhat-rpm-config > etc. changes that affect all packages. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Apr 17 12:10:50 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 17 Apr 2007 14:10:50 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <4624B025.10205@leemhuis.info> References: <20070417054814.GA11690@redhat.com> <462467B4.8000608@leemhuis.info> <20070417074204.GF5695@neu.nirvana> <462481D7.5050802@leemhuis.info> <20070417083515.GH5695@neu.nirvana> <46248EFA.40304@leemhuis.info> <20070417093215.GM5695@neu.nirvana> <46249F29.9090003@leemhuis.info> <20070417110548.GN5695@neu.nirvana> <4624B025.10205@leemhuis.info> Message-ID: <20070417121050.GP5695@neu.nirvana> On Tue, Apr 17, 2007 at 01:31:49PM +0200, Thorsten Leemhuis wrote: > > > On 17.04.2007 13:05, Axel Thimm wrote: > >On Tue, Apr 17, 2007 at 12:19:21PM +0200, Thorsten Leemhuis wrote: > >>>And it comes as no suprise since as we all should know FE was always > >>>doing mass rebuilds until including FC6. I wonder how the 0.6% and 1% > >>>were forgotten in the process. Perhaps someone did a rebuild with the > >>>same EVR - we didn't catch these in the old days. > >>We never did full rebuilds. Data-packages never had to be rebuild. > >OK, that accounts for the 0.6-1% then. [...] > > Well, you carefully didn't reply to the part where I explained that you > can't get to a proper number "how many packages weren't rebuild in the > devel cycle FE5 -> FE6" by looking at todays repos. So the 0.6-1% are > FUD in my eyes. Please be careful with using the word FUD. Not everything that doesn't suit your needs is FUD. > I don't have hard numbers either -- but from memory I'd say we didn't > rebuild round about 1/3 of the packages in the FE mass rebuild for FC6. Your memory doesn't serve you well. You even asked for two mass rebuilds for FC6, one for new rpm signing/sped up dynamic linking/new minimal buildroots and another "semi-mass rebuild" for fixing the gdb-backtrace bug for packages build in September. In fact all (but 1%) packages in FE6 got rebuilt at least once. On Sun, Jan 15, 2006 at 07:59:20PM +0100, Thorsten Leemhuis wrote: > We probably will have to do a rebuild of all (most?) packages in > Fedora Extras before FC5 is released. Why? Some reasons: On Sat, Jul 01, 2006 at 12:25:54PM +0200, Thorsten Leemhuis wrote: > Now it makes four good reasons to build all Extras packages in devel > before FC6. On Sat, Dec 09, 2006 at 07:13:16PM +0100, Thorsten Leemhuis wrote: > Yes, we did a lot of mass-rebuilds in for the last releases, -- 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 Tue Apr 17 15:48:27 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 17 Apr 2007 21:18:27 +0530 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <200704170739.02657.jkeating@redhat.com> References: <46244EE2.5060002@redhat.com> <200704170739.02657.jkeating@redhat.com> Message-ID: <4624EC4B.7010002@fedoraproject.org> Jesse Keating wrote: > First, thank you very much for doing this John, it is a BIG help. I have a > couple corrections I'll make here and then in the wiki. > > On Tuesday 17 April 2007 00:36:50 John Poelstra wrote: >> * Eventually need documentation surrounding the freeze and distro >> build process > > As discussed, this would be for technical reason only, such as a toolchain > change, a rpm format change, a discovered problem with Matt's on the side > rebuild, etc... To the best of my knowledge, we are not planning mass > rebuilds for the sake of mass rebuilds. Are we not rebuilding the packages with "fc6" names in Fedora 7? I did ask FESCo but afaik no final decision was made. What about packages that dist tags in the future releases? Rahul From jkeating at redhat.com Tue Apr 17 16:07:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Apr 2007 12:07:08 -0400 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <4624EC4B.7010002@fedoraproject.org> References: <46244EE2.5060002@redhat.com> <200704170739.02657.jkeating@redhat.com> <4624EC4B.7010002@fedoraproject.org> Message-ID: <200704171207.08703.jkeating@redhat.com> On Tuesday 17 April 2007 11:48:27 Rahul Sundaram wrote: > Are we not rebuilding the packages with "fc6" names in Fedora 7? I did > ask FESCo but afaik no final decision was made. What about packages that > dist tags in the future releases? No. Rebuilding just to change dist tags is a completely silly operation. Our distribution releases do inherit from previous releases, the dist tag just makes that point visually. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Tue Apr 17 16:12:45 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 17 Apr 2007 21:42:45 +0530 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <200704171207.08703.jkeating@redhat.com> References: <46244EE2.5060002@redhat.com> <200704170739.02657.jkeating@redhat.com> <4624EC4B.7010002@fedoraproject.org> <200704171207.08703.jkeating@redhat.com> Message-ID: <4624F1FD.6070807@fedoraproject.org> Jesse Keating wrote: > On Tuesday 17 April 2007 11:48:27 Rahul Sundaram wrote: >> Are we not rebuilding the packages with "fc6" names in Fedora 7? I did >> ask FESCo but afaik no final decision was made. What about packages that >> dist tags in the future releases? > > No. Rebuilding just to change dist tags is a completely silly operation. I think we just disagree on that. The value of rebuilding is more than just changing the dist tag. The fear against is exactly the reason why we should be doing it in the first place. Ensuring that they don't "accidentally" get new features during a security update after the release is a measure of quality. Our > distribution releases do inherit from previous releases, the dist tag just > makes that point visually. So one might have "fc6" packages in Fedora 8 and "fc7" packages on Fedora 10 too? You don't think that's "silly"? Btw did FESCo even discuss this at all? Rahul From jwboyer at jdub.homelinux.org Tue Apr 17 16:26:33 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 17 Apr 2007 11:26:33 -0500 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <4624F1FD.6070807@fedoraproject.org> References: <46244EE2.5060002@redhat.com> <200704170739.02657.jkeating@redhat.com> <4624EC4B.7010002@fedoraproject.org> <200704171207.08703.jkeating@redhat.com> <4624F1FD.6070807@fedoraproject.org> Message-ID: <1176827194.25513.5.camel@vader.jdub.homelinux.org> On Tue, 2007-04-17 at 21:42 +0530, Rahul Sundaram wrote: > Jesse Keating wrote: > > On Tuesday 17 April 2007 11:48:27 Rahul Sundaram wrote: > >> Are we not rebuilding the packages with "fc6" names in Fedora 7? I did > >> ask FESCo but afaik no final decision was made. What about packages that > >> dist tags in the future releases? > > > > No. Rebuilding just to change dist tags is a completely silly operation. > > I think we just disagree on that. The value of rebuilding is more than > just changing the dist tag. The fear against is exactly the reason why > we should be doing it in the first place. Ensuring that they don't > "accidentally" get new features during a security update after the > release is a measure of quality. > > Our > > distribution releases do inherit from previous releases, the dist tag just > > makes that point visually. > > So one might have "fc6" packages in Fedora 8 and "fc7" packages on > Fedora 10 too? You don't think that's "silly"? Btw did FESCo even > discuss this at all? It was not discussed last week. I will explicitly add it to the agenda this week. josh From jkeating at redhat.com Tue Apr 17 16:28:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Apr 2007 12:28:06 -0400 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <4624F1FD.6070807@fedoraproject.org> References: <46244EE2.5060002@redhat.com> <200704171207.08703.jkeating@redhat.com> <4624F1FD.6070807@fedoraproject.org> Message-ID: <200704171228.06358.jkeating@redhat.com> On Tuesday 17 April 2007 12:12:45 Rahul Sundaram wrote: > I think we just disagree on that. The value of rebuilding is more than > just changing the dist tag. The fear against is exactly the reason why > we should be doing it in the first place. Ensuring that they don't > "accidentally" get new features during a security update after the > release is a measure of quality. I'm not going to have yet ANOTHER argument about this. See the last 20 friggin thread that came up before on this. > ? Our > > > distribution releases do inherit from previous releases, the dist tag > > just makes that point visually. > > So one might have "fc6" packages in Fedora 8 and "fc7" packages on > Fedora 10 too? You don't think that's "silly"? ?Btw did FESCo even > discuss this at all? If a package needs not be rebuilt for any technical reason between F7 and F10, then no, that isn't silly at all. Rebuilding it for no reason other than to change the dist tag is entirely silly. Rebuilding for a technical reason such as a compiler change, an rpm change, a build chain change, etc... that's perfectly fine. -- 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 poelstra at redhat.com Tue Apr 17 16:56:32 2007 From: poelstra at redhat.com (John Poelstra) Date: Tue, 17 Apr 2007 09:56:32 -0700 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <200704171228.06358.jkeating@redhat.com> References: <46244EE2.5060002@redhat.com> <200704171207.08703.jkeating@redhat.com> <4624F1FD.6070807@fedoraproject.org> <200704171228.06358.jkeating@redhat.com> Message-ID: <4624FC40.9080704@redhat.com> Jesse Keating said the following on 04/17/2007 09:28 AM Pacific Time: > If a package needs not be rebuilt for any technical reason between F7 and F10, > then no, that isn't silly at all. Rebuilding it for no reason other than to > change the dist tag is entirely silly. Rebuilding for a technical reason > such as a compiler change, an rpm change, a build chain change, etc... that's > perfectly fine. > This is too binary... if there is a technical reason, then it is justified; if there is no technical reason then there is no justification. Perception, ease of use, artwork, etc. are also important parts of a good release. If we want Fedora to be widely accepted and understood we need to make decisions from more than one dimension, and at times, dimensions we are not as good at (non-technical). If changing the dist tag helps someone not as technically inclined or gives the impression of better put together release, fixing it has a high ROI and is worth it to me. John From notting at redhat.com Tue Apr 17 16:56:19 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 17 Apr 2007 12:56:19 -0400 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <4624FC40.9080704@redhat.com> References: <46244EE2.5060002@redhat.com> <200704171207.08703.jkeating@redhat.com> <4624F1FD.6070807@fedoraproject.org> <200704171228.06358.jkeating@redhat.com> <4624FC40.9080704@redhat.com> Message-ID: <20070417165619.GA18429@nostromo.devel.redhat.com> John Poelstra (poelstra at redhat.com) said: > If changing the dist tag helps someone not as technically inclined or gives > the impression of better put together release, fixing it has a high ROI and > is worth it to me. Someone who is non-technical doesn't necessarily *see* the version/release. Bill From fedora at leemhuis.info Tue Apr 17 17:11:47 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Apr 2007 19:11:47 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070417165619.GA18429@nostromo.devel.redhat.com> References: <46244EE2.5060002@redhat.com> <200704171207.08703.jkeating@redhat.com> <4624F1FD.6070807@fedoraproject.org> <200704171228.06358.jkeating@redhat.com> <4624FC40.9080704@redhat.com> <20070417165619.GA18429@nostromo.devel.redhat.com> Message-ID: <4624FFD3.7070103@leemhuis.info> Bill Nottingham schrieb: > John Poelstra (poelstra at redhat.com) said: >> If changing the dist tag helps someone not as technically inclined or gives >> the impression of better put together release, fixing it has a high ROI and >> is worth it to me. > Someone who is non-technical doesn't necessarily *see* the version/release. +1 -- and we could solve most of the problem by educating packagers to not use the disttag in the devel branch for packages that change seldom. Cu thl From tibbs at math.uh.edu Tue Apr 17 18:16:54 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 17 Apr 2007 13:16:54 -0500 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070417165619.GA18429@nostromo.devel.redhat.com> References: <46244EE2.5060002@redhat.com> <200704171207.08703.jkeating@redhat.com> <4624F1FD.6070807@fedoraproject.org> <200704171228.06358.jkeating@redhat.com> <4624FC40.9080704@redhat.com> <20070417165619.GA18429@nostromo.devel.redhat.com> Message-ID: >>>>> "BN" == Bill Nottingham writes: BN> Someone who is non-technical doesn't necessarily *see* the BN> version/release. I think the problem is the people who have enough knowledge to get that info but not enough to understand why the dist tag might not have changed. The naive answer "thank us for making your upgrade go quicker" should be sufficient, but probably isn't. - J< From jamatos at fc.up.pt Tue Apr 17 18:26:45 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Tue, 17 Apr 2007 19:26:45 +0100 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: References: <46244EE2.5060002@redhat.com> <20070417165619.GA18429@nostromo.devel.redhat.com> Message-ID: <200704171926.45881.jamatos@fc.up.pt> On Tuesday 17 April 2007 7:16:54 pm Jason L Tibbitts III wrote: I agree with Jason. And yes, I know "A foolish consistency is the hobgoblin of little minds". :-) > I think the problem is the people who have enough knowledge to get > that info but not enough to understand why the dist tag might not have > changed. Imagine someone coming from other distribution and try to explain them this small quirks. :-) > The naive answer "thank us for making your upgrade go quicker" should > be sufficient, but probably isn't. +1 But this argument does not buy if you are installing it the first time. :-) > ?- J< -- Jos? Ab?lio From laroche at redhat.com Tue Apr 17 21:01:11 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 17 Apr 2007 23:01:11 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <4624FFD3.7070103@leemhuis.info> References: <46244EE2.5060002@redhat.com> <200704171207.08703.jkeating@redhat.com> <4624F1FD.6070807@fedoraproject.org> <200704171228.06358.jkeating@redhat.com> <4624FC40.9080704@redhat.com> <20070417165619.GA18429@nostromo.devel.redhat.com> <4624FFD3.7070103@leemhuis.info> Message-ID: <20070417210111.GA2765@dudweiler.stuttgart.redhat.com> On Tue, Apr 17, 2007 at 07:11:47PM +0200, Thorsten Leemhuis wrote: > Bill Nottingham schrieb: > > John Poelstra (poelstra at redhat.com) said: > >> If changing the dist tag helps someone not as technically inclined or gives > >> the impression of better put together release, fixing it has a high ROI and > >> is worth it to me. > > Someone who is non-technical doesn't necessarily *see* the version/release. > > +1 -- and we could solve most of the problem by educating packagers to > not use the disttag in the devel branch for packages that change seldom. I've suggested before to leave away the dist tag for the devel branch completely and only add it for updates once a release is put together. This would be a change where packages now start depending on the dist tag to identify certain releases. regards, Florian La Roche From jkeating at redhat.com Tue Apr 17 21:09:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Apr 2007 17:09:41 -0400 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070417210111.GA2765@dudweiler.stuttgart.redhat.com> References: <46244EE2.5060002@redhat.com> <4624FFD3.7070103@leemhuis.info> <20070417210111.GA2765@dudweiler.stuttgart.redhat.com> Message-ID: <200704171709.41389.jkeating@redhat.com> On Tuesday 17 April 2007 17:01:11 Florian La Roche wrote: > I've suggested before to leave away the dist tag for the > devel branch completely and only add it for updates once a > release is put together. > > This would be a change where packages now start depending on the > dist tag to identify certain releases. And I've shown you before where that utterly fails and completely misses the usefulness of the disttag. Either you have to fork all your specs between release and devel (which the disttag is supposed to save you from doing) or you run into broken upgrade paths were foo-1.3%{?dist} equates to foo-1.3.fc7 for F7 and foo-1.3 for rawhide (F8) and you wind up with an broken upgrade path. -- 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 Apr 17 21:17:56 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 17 Apr 2007 23:17:56 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <200704171709.41389.jkeating@redhat.com> References: <46244EE2.5060002@redhat.com> <4624FFD3.7070103@leemhuis.info> <20070417210111.GA2765@dudweiler.stuttgart.redhat.com> <200704171709.41389.jkeating@redhat.com> Message-ID: <20070417211756.GA3859@dudweiler.stuttgart.redhat.com> On Tue, Apr 17, 2007 at 05:09:41PM -0400, Jesse Keating wrote: > On Tuesday 17 April 2007 17:01:11 Florian La Roche wrote: > > I've suggested before to leave away the dist tag for the > > devel branch completely and only add it for updates once a > > release is put together. > > > > This would be a change where packages now start depending on the > > dist tag to identify certain releases. > > And I've shown you before where that utterly fails and completely misses the > usefulness of the disttag. > > Either you have to fork all your specs between release and devel (which the > disttag is supposed to save you from doing) or you run into broken upgrade > paths were foo-1.3%{?dist} equates to foo-1.3.fc7 for F7 and foo-1.3 for > rawhide (F8) and you wind up with an broken upgrade path. Hello Jesse, This just means that you have to pick a version for updates, but can then just built into FC-devel without the current discussion about dist tags in releases. Picking working version numbers for the updates isn't that hard, but then the whole disttag discussion is also not an overly critical discussion to have. regards, Florian La Roche From jkeating at redhat.com Wed Apr 18 00:07:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Apr 2007 20:07:57 -0400 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070417211756.GA3859@dudweiler.stuttgart.redhat.com> References: <46244EE2.5060002@redhat.com> <200704171709.41389.jkeating@redhat.com> <20070417211756.GA3859@dudweiler.stuttgart.redhat.com> Message-ID: <200704172007.57645.jkeating@redhat.com> On Tuesday 17 April 2007 17:17:56 Florian La Roche wrote: > This just means that you have to pick a version for updates, but can then > just built into FC-devel without the current discussion about dist tags > in releases. Picking working version numbers for the updates isn't that > hard, but then the whole disttag discussion is also not an overly critical > discussion to have. If you're going to manually version everything, there is no need to actually use the dist tags, and then the problem becomes moot. However it is handy to make use of them and makes developer lives easier so I'm just not all that interested in "solutions" which remove the usefulness of dist tags. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Apr 18 05:00:51 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 18 Apr 2007 07:00:51 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <200704171709.41389.jkeating@redhat.com> References: <46244EE2.5060002@redhat.com> <4624FFD3.7070103@leemhuis.info> <20070417210111.GA2765@dudweiler.stuttgart.redhat.com> <200704171709.41389.jkeating@redhat.com> Message-ID: <4625A603.6060105@leemhuis.info> On 17.04.2007 23:09, Jesse Keating wrote: > On Tuesday 17 April 2007 17:01:11 Florian La Roche wrote: >> I've suggested before to leave away the dist tag for the >> devel branch completely and only add it for updates once a >> release is put together. >> This would be a change where packages now start depending on the >> dist tag to identify certain releases. Yeah, that would be nice, but.... > And I've shown you before where that utterly fails and completely misses the > usefulness of the disttag. ...I tend to agree with Jesse here. > Either you have to fork all your specs between release and devel (which the > disttag is supposed to save you from doing) or you run into broken upgrade > paths were foo-1.3%{?dist} equates to foo-1.3.fc7 for F7 and foo-1.3 for > rawhide (F8) and you wind up with an broken upgrade path. Well, why don't we just expand the disttag to something else without the "fcn" in it in the devel branch? A simple ".1" maybe -- that should make everybody happy afaics: [thl at thl tmp]$ # this is how we do it right now: [thl at thl tmp]$ rpmdev-vercmp 0 1.0 5.fc6 0 1.0 5.fc7 0:1.0-5.fc7 is newer [thl at thl tmp]$ # why not do it like this: [thl at thl tmp]$ rpmdev-vercmp 0 1.0 5.fc6 0 1.0 5.1 0:1.0-5.1 is newer Or am I or rpmdev-vercmp missing something here? /me always gets a bit confused when it comes to letters in %{release} BTW, sure, the changelog entry and the actual release won't match fully this way, but that's the same with disttags. Just my 2 cent. CU thl From bpepple at fedoraproject.org Wed Apr 18 14:40:34 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 18 Apr 2007 10:40:34 -0400 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <1176827194.25513.5.camel@vader.jdub.homelinux.org> References: <46244EE2.5060002@redhat.com> <200704170739.02657.jkeating@redhat.com> <4624EC4B.7010002@fedoraproject.org> <200704171207.08703.jkeating@redhat.com> <4624F1FD.6070807@fedoraproject.org> <1176827194.25513.5.camel@vader.jdub.homelinux.org> Message-ID: <1176907234.10056.1.camel@lincoln> On Tue, 2007-04-17 at 11:26 -0500, Josh Boyer wrote: > On Tue, 2007-04-17 at 21:42 +0530, Rahul Sundaram wrote: > > Jesse Keating wrote: > > > On Tuesday 17 April 2007 11:48:27 Rahul Sundaram wrote: > > >> Are we not rebuilding the packages with "fc6" names in Fedora 7? I did > > >> ask FESCo but afaik no final decision was made. What about packages that > > >> dist tags in the future releases? > > > > > > No. Rebuilding just to change dist tags is a completely silly operation. > > > > I think we just disagree on that. The value of rebuilding is more than > > just changing the dist tag. The fear against is exactly the reason why > > we should be doing it in the first place. Ensuring that they don't > > "accidentally" get new features during a security update after the > > release is a measure of quality. > > > > Our > > > distribution releases do inherit from previous releases, the dist tag just > > > makes that point visually. > > > > So one might have "fc6" packages in Fedora 8 and "fc7" packages on > > Fedora 10 too? You don't think that's "silly"? Btw did FESCo even > > discuss this at all? > > It was not discussed last week. I will explicitly add it to the agenda > this week. Do we want to address this again? We've said for a while now that we were not planning on doing a mass rebuild for this release. http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070301 /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 jwboyer at jdub.homelinux.org Wed Apr 18 15:48:45 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 18 Apr 2007 10:48:45 -0500 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <1176907234.10056.1.camel@lincoln> References: <46244EE2.5060002@redhat.com> <200704170739.02657.jkeating@redhat.com> <4624EC4B.7010002@fedoraproject.org> <200704171207.08703.jkeating@redhat.com> <4624F1FD.6070807@fedoraproject.org> <1176827194.25513.5.camel@vader.jdub.homelinux.org> <1176907234.10056.1.camel@lincoln> Message-ID: <1176911325.25513.30.camel@vader.jdub.homelinux.org> On Wed, 2007-04-18 at 10:40 -0400, Brian Pepple wrote: > On Tue, 2007-04-17 at 11:26 -0500, Josh Boyer wrote: > > On Tue, 2007-04-17 at 21:42 +0530, Rahul Sundaram wrote: > > > Jesse Keating wrote: > > > > On Tuesday 17 April 2007 11:48:27 Rahul Sundaram wrote: > > > >> Are we not rebuilding the packages with "fc6" names in Fedora 7? I did > > > >> ask FESCo but afaik no final decision was made. What about packages that > > > >> dist tags in the future releases? > > > > > > > > No. Rebuilding just to change dist tags is a completely silly operation. > > > > > > I think we just disagree on that. The value of rebuilding is more than > > > just changing the dist tag. The fear against is exactly the reason why > > > we should be doing it in the first place. Ensuring that they don't > > > "accidentally" get new features during a security update after the > > > release is a measure of quality. > > > > > > Our > > > > distribution releases do inherit from previous releases, the dist tag just > > > > makes that point visually. > > > > > > So one might have "fc6" packages in Fedora 8 and "fc7" packages on > > > Fedora 10 too? You don't think that's "silly"? Btw did FESCo even > > > discuss this at all? > > > > It was not discussed last week. I will explicitly add it to the agenda > > this week. > > Do we want to address this again? We've said for a while now that we > were not planning on doing a mass rebuild for this release. > > http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070301 That was before the disttag discussion started IIRC. Rahul has asked a few times for FESCo to discuss this again. I added it to the agenda and we should take a quick vote on it. josh From jovel_juan at hotmail.com Wed Apr 18 15:20:04 2007 From: jovel_juan at hotmail.com (Juan Jovel) Date: Wed, 18 Apr 2007 15:20:04 +0000 Subject: Printer installation Message-ID: Hi Guy! I am just starting to use FEDORA and would like to know how can I configure my printers... I would appreciate any input on this topic... thanks a lot, JUAN _________________________________________________________________ Consigue aqu? las mejores y mas recientes ofertas de trabajo en Am?rica Latina y USA: http://latam.msn.com/empleos/ From sundaram at fedoraproject.org Wed Apr 18 16:00:34 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 18 Apr 2007 21:30:34 +0530 Subject: Printer installation In-Reply-To: References: Message-ID: <462640A2.6090306@fedoraproject.org> Juan Jovel wrote: > Hi Guy! > > I am just starting to use FEDORA and would like to know how can I > configure my printers... > > I would appreciate any input on this topic... > > thanks a lot, You can use system-config-printer accessible from System=>Administration => Printing in GNOME or the main menu in KDE. This is offtopic for this list. Post to fedoraforums.org or fedora-list for further questions. http://fedoraproject.org/wiki/Communicate. Rahul From sundaram at fedoraproject.org Wed Apr 18 16:03:09 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 18 Apr 2007 21:33:09 +0530 Subject: Printer installation In-Reply-To: References: Message-ID: <4626413D.7070002@fedoraproject.org> Juan Jovel wrote: > Hi Guy! > > I am just starting to use FEDORA and would like to know how can I > configure my printers... > > I would appreciate any input on this topic... > > thanks a lot, You can use system-config-printer accessible from System=>Administration => Printing in GNOME or the main menu in KDE. This is offtopic for this list. Post to fedoraforum.org or fedora-list for further questions. http://fedoraproject.org/wiki/Communicate. Rahul From sundaram at fedoraproject.org Wed Apr 18 20:22:42 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 19 Apr 2007 01:52:42 +0530 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <461ECEB1.7000301@redhat.com> References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> <461ECEB1.7000301@redhat.com> Message-ID: <46267E12.4090500@fedoraproject.org> John Poelstra wrote: > > On a related topic... from the Fedora main page... > > "...All in pursuit of the best operating system and platform that free > software can provide." > > What don't we have a link there to the Fedora definition of "free > software?" Done. http://fedoraproject.org/wiki/FedoraMain Rahul From poelstra at redhat.com Thu Apr 19 03:29:10 2007 From: poelstra at redhat.com (John Poelstra) Date: Wed, 18 Apr 2007 20:29:10 -0700 Subject: Getting to a final F7 feature list In-Reply-To: <4624F7EC.8040905@redhat.com> References: <4624F7EC.8040905@redhat.com> Message-ID: <4626E206.4050508@redhat.com> John Poelstra said the following on 04/17/2007 09:38 AM Pacific Time: > Now I'm off to check in and update status for each of these: > http://fedoraproject.org/wiki/Releases/7/FeatureList > If you are a feature owner and can get there first that would be a big > help. > > I'll send a summary once I am done. > Thanks to everyone who updated each feature with a status. I added one of three descriptors to each feature on the wiki page summarizing the features for F7. http://fedoraproject.org/wiki/Releases/7/FeatureList IN == A good portion of the feature (or more) is completed and is already in F7 OUT == Feature will not be completed in time for F7 and is not in F7 UNCERTAIN == Status of the feature is unclear or I was unable to determine if the feature is in F7. John From sundaram at fedoraproject.org Thu Apr 19 03:40:15 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 19 Apr 2007 09:10:15 +0530 Subject: Getting to a final F7 feature list In-Reply-To: <4626E206.4050508@redhat.com> References: <4624F7EC.8040905@redhat.com> <4626E206.4050508@redhat.com> Message-ID: <4626E49F.4010006@fedoraproject.org> John Poelstra wrote: > John Poelstra said the following on 04/17/2007 09:38 AM Pacific Time: >> Now I'm off to check in and update status for each of these: >> http://fedoraproject.org/wiki/Releases/7/FeatureList >> If you are a feature owner and can get there first that would be a big >> help. >> >> I'll send a summary once I am done. >> > > Thanks to everyone who updated each feature with a status. > > I added one of three descriptors to each feature on the wiki page > summarizing the features for F7. > > http://fedoraproject.org/wiki/Releases/7/FeatureList > > IN == A good portion of the feature (or more) is completed and is > already in F7 > OUT == Feature will not be completed in time for F7 and is not in F7 > UNCERTAIN == Status of the feature is unclear or I was unable to > determine if the feature is in F7. I think Fedora Directory Server would qualify as PARTIAL rather than OUT. The base system is in after a number of patches and extensive review to make it fit into the Fedora packaging guidelines. Though the gui parts are not in yet I think we need to acknowledge the work done better. Similar situation for RANDR. The framework is in and Intel driver supports it. Yum enhancements planned are already in. Whether they have a significant boost in performance or not is a entirely different question. Rahul From sundaram at fedoraproject.org Thu Apr 19 04:13:33 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 19 Apr 2007 09:43:33 +0530 Subject: Getting to a final F7 feature list In-Reply-To: <4626E49F.4010006@fedoraproject.org> References: <4624F7EC.8040905@redhat.com> <4626E206.4050508@redhat.com> <4626E49F.4010006@fedoraproject.org> Message-ID: <4626EC6D.6030905@fedoraproject.org> Rahul Sundaram wrote: > John Poelstra wrote: >> John Poelstra said the following on 04/17/2007 09:38 AM Pacific Time: >>> Now I'm off to check in and update status for each of these: >>> http://fedoraproject.org/wiki/Releases/7/FeatureList >>> If you are a feature owner and can get there first that would be a >>> big help. >>> >>> I'll send a summary once I am done. >>> >> >> Thanks to everyone who updated each feature with a status. >> >> I added one of three descriptors to each feature on the wiki page >> summarizing the features for F7. >> >> http://fedoraproject.org/wiki/Releases/7/FeatureList >> >> IN == A good portion of the feature (or more) is completed and is >> already in F7 >> OUT == Feature will not be completed in time for F7 and is not in F7 >> UNCERTAIN == Status of the feature is unclear or I was unable to >> determine if the feature is in F7. > Additional notes: Dictionary proliferation fixing status should only be PARTIAL. There is still work left on fixing it completely. Build system is not OUT. It is a requirement for the merge which itself is a release blocker. Is test 4 going to have a everything release? Rahul From kwade at redhat.com Thu Apr 19 07:23:49 2007 From: kwade at redhat.com (Karsten Wade) Date: Thu, 19 Apr 2007 00:23:49 -0700 Subject: new Join page(s), where is this on-topic? Message-ID: <1176967430.3286.258.camel@erato.phig.org> We want to announce to all project leadership that there is a new all-one destination page for helping people who are interested in joining Fedora: http://fedoraproject.org/wiki/Join We also want to encourage all projects to create a project-specific page in a similar namespace, so it is always easy to find. For example: http://fedoraproject.org/wiki/ProjectName/Join Some of us (such as the Docs Project) have legacy pages that need to be renamed to Foo/Join and all links fixed. Meanwhile, a redirect works fine. The idea of a common namespace for finding join information is to help make it easier for everyone inside and outside of the project to know where to go when someone wants to join Fedora. Now, why is fedora-advisory-board getting this? Um, I think it's because I have no clue where to send this. There was some discussion of having a project discussion list (fedora-project-list?) Did this ever get off the ground? I don't want to announce this on f-announce-l until project leadership has had a chance to clean up their Join pages. Regardless, that is not the place or method for posting something like this for discussion. What would you do with this tasty tidbit? Where would you post this email, if not f-a-b? - 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 poelstra at redhat.com Thu Apr 19 16:41:10 2007 From: poelstra at redhat.com (John Poelstra) Date: Thu, 19 Apr 2007 09:41:10 -0700 Subject: Getting to a final F7 feature list In-Reply-To: <20070419163725.GB27754@wolff.to> References: <4624F7EC.8040905@redhat.com> <4626E206.4050508@redhat.com> <20070419163725.GB27754@wolff.to> Message-ID: <46279BA6.6040206@redhat.com> Bruno Wolff III said the following on 04/19/2007 09:37 AM Pacific Time: > On Wed, Apr 18, 2007 at 20:29:10 -0700, > John Poelstra wrote: >> I added one of three descriptors to each feature on the wiki page >> summarizing the features for F7. >> >> http://fedoraproject.org/wiki/Releases/7/FeatureList > > Encrypted File Systems (http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems) > seems to have just been dropped from the list rather than updated. > I'd be interested in knowing if it least the mkinitrd patches are going to > make it in, so that I can set up an encrypted root file system manually > without having to use a custom mkinitrd. I don't recall ever seeing it on the list. When was it dropped? John From sundaram at fedoraproject.org Thu Apr 19 16:45:12 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 19 Apr 2007 22:15:12 +0530 Subject: Getting to a final F7 feature list In-Reply-To: <46279BA6.6040206@redhat.com> References: <4624F7EC.8040905@redhat.com> <4626E206.4050508@redhat.com> <20070419163725.GB27754@wolff.to> <46279BA6.6040206@redhat.com> Message-ID: <46279C98.40405@fedoraproject.org> John Poelstra wrote: > Bruno Wolff III said the following on 04/19/2007 09:37 AM Pacific Time: >> On Wed, Apr 18, 2007 at 20:29:10 -0700, >> John Poelstra wrote: >>> I added one of three descriptors to each feature on the wiki page >>> summarizing the features for F7. >>> >>> http://fedoraproject.org/wiki/Releases/7/FeatureList >> >> Encrypted File Systems >> (http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems) >> seems to have just been dropped from the list rather than updated. >> I'd be interested in knowing if it least the mkinitrd patches are >> going to >> make it in, so that I can set up an encrypted root file system manually >> without having to use a custom mkinitrd. > > I don't recall ever seeing it on the list. When was it dropped? http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems?action=info Rahul From jkeating at redhat.com Thu Apr 19 18:04:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 19 Apr 2007 14:04:02 -0400 Subject: RFC: Release team meetings In-Reply-To: <200704161203.01698.jkeating@redhat.com> References: <20070412212027.GB3357@nostromo.devel.redhat.com> <200704160801.50696.jkeating@redhat.com> <200704161203.01698.jkeating@redhat.com> Message-ID: <200704191404.06252.jkeating@redhat.com> On Monday 16 April 2007 12:03:01 Jesse Keating wrote: > Enough people has said yes. ?We'll be doing this as an IRC meeting on > Freenode IRC network, #fedora-meeting. ?See ya'll in an hour. Reminder, as decided last meeting, we'd be meeting now to go over more stuff. Join us on #fedora-meeting -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tchung at fedoraproject.org Thu Apr 19 21:52:59 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Thu, 19 Apr 2007 14:52:59 -0700 Subject: new Join page(s), where is this on-topic? In-Reply-To: <1176967430.3286.258.camel@erato.phig.org> References: <1176967430.3286.258.camel@erato.phig.org> Message-ID: <369bce3b0704191452h34609764g436bf6c1ad24c111@mail.gmail.com> On 4/19/07, Karsten Wade wrote: > We also want to encourage all projects to create a project-specific page > in a similar namespace, so it is always easy to find. For example: > > http://fedoraproject.org/wiki/ProjectName/Join > > Some of us (such as the Docs Project) have legacy pages that need to be > renamed to Foo/Join and all links fixed. Meanwhile, a redirect works > fine. > > The idea of a common namespace for finding join information is to help > make it easier for everyone inside and outside of the project to know > where to go when someone wants to join Fedora. Fedora Ambassadors Project is now compliant. :) http://fedoraproject.org/wiki/Ambassadors/Join Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From jwboyer at jdub.homelinux.org Fri Apr 20 01:17:22 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 19 Apr 2007 20:17:22 -0500 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <1176911325.25513.30.camel@vader.jdub.homelinux.org> References: <46244EE2.5060002@redhat.com> <200704170739.02657.jkeating@redhat.com> <4624EC4B.7010002@fedoraproject.org> <200704171207.08703.jkeating@redhat.com> <4624F1FD.6070807@fedoraproject.org> <1176827194.25513.5.camel@vader.jdub.homelinux.org> <1176907234.10056.1.camel@lincoln> <1176911325.25513.30.camel@vader.jdub.homelinux.org> Message-ID: <1177031842.25513.44.camel@vader.jdub.homelinux.org> On Wed, 2007-04-18 at 10:48 -0500, Josh Boyer wrote: > > > > So one might have "fc6" packages in Fedora 8 and "fc7" packages on > > > > Fedora 10 too? You don't think that's "silly"? Btw did FESCo even > > > > discuss this at all? > > > > > > It was not discussed last week. I will explicitly add it to the agenda > > > this week. > > > > Do we want to address this again? We've said for a while now that we > > were not planning on doing a mass rebuild for this release. > > > > http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070301 > > That was before the disttag discussion started IIRC. Rahul has asked a > few times for FESCo to discuss this again. I added it to the agenda and > we should take a quick vote on it. So people don't have to wait for the meeting minutes to come out, this was discussed today in the FESCo meeting. The issue was voted down. A mass rebuild for this will not be done. josh From sundaram at fedoraproject.org Fri Apr 20 01:24:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 20 Apr 2007 06:54:55 +0530 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <1177031842.25513.44.camel@vader.jdub.homelinux.org> References: <46244EE2.5060002@redhat.com> <200704170739.02657.jkeating@redhat.com> <4624EC4B.7010002@fedoraproject.org> <200704171207.08703.jkeating@redhat.com> <4624F1FD.6070807@fedoraproject.org> <1176827194.25513.5.camel@vader.jdub.homelinux.org> <1176907234.10056.1.camel@lincoln> <1176911325.25513.30.camel@vader.jdub.homelinux.org> <1177031842.25513.44.camel@vader.jdub.homelinux.org> Message-ID: <46281667.5050500@fedoraproject.org> Josh Boyer wrote: > On Wed, 2007-04-18 at 10:48 -0500, Josh Boyer wrote: >>>>> So one might have "fc6" packages in Fedora 8 and "fc7" packages on >>>>> Fedora 10 too? You don't think that's "silly"? Btw did FESCo even >>>>> discuss this at all? >>>> It was not discussed last week. I will explicitly add it to the agenda >>>> this week. >>> Do we want to address this again? We've said for a while now that we >>> were not planning on doing a mass rebuild for this release. >>> >>> http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070301 >> That was before the disttag discussion started IIRC. Rahul has asked a >> few times for FESCo to discuss this again. I added it to the agenda and >> we should take a quick vote on it. > > So people don't have to wait for the meeting minutes to come out, this > was discussed today in the FESCo meeting. The issue was voted down. A > mass rebuild for this will not be done. For this release or even in the future? To clarify, everyone is FESCo was ok with packages with "fcX", where X can be very different from what release it is included in depending on when it was last rebuilt? Rahul From jwboyer at jdub.homelinux.org Fri Apr 20 01:42:28 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 19 Apr 2007 20:42:28 -0500 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <46281667.5050500@fedoraproject.org> References: <46244EE2.5060002@redhat.com> <200704170739.02657.jkeating@redhat.com> <4624EC4B.7010002@fedoraproject.org> <200704171207.08703.jkeating@redhat.com> <4624F1FD.6070807@fedoraproject.org> <1176827194.25513.5.camel@vader.jdub.homelinux.org> <1176907234.10056.1.camel@lincoln> <1176911325.25513.30.camel@vader.jdub.homelinux.org> <1177031842.25513.44.camel@vader.jdub.homelinux.org> <46281667.5050500@fedoraproject.org> Message-ID: <1177033348.25513.55.camel@vader.jdub.homelinux.org> On Fri, 2007-04-20 at 06:54 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > On Wed, 2007-04-18 at 10:48 -0500, Josh Boyer wrote: > >>>>> So one might have "fc6" packages in Fedora 8 and "fc7" packages on > >>>>> Fedora 10 too? You don't think that's "silly"? Btw did FESCo even > >>>>> discuss this at all? > >>>> It was not discussed last week. I will explicitly add it to the agenda > >>>> this week. > >>> Do we want to address this again? We've said for a while now that we > >>> were not planning on doing a mass rebuild for this release. > >>> > >>> http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070301 > >> That was before the disttag discussion started IIRC. Rahul has asked a > >> few times for FESCo to discuss this again. I added it to the agenda and > >> we should take a quick vote on it. > > > > So people don't have to wait for the meeting minutes to come out, this > > was discussed today in the FESCo meeting. The issue was voted down. A > > mass rebuild for this will not be done. > > For this release or even in the future? To clarify, everyone is FESCo > was ok with packages with "fcX", where X can be very different from what > release it is included in depending on when it was last rebuilt? This release was all that was discussed. If new proposals for future releases come to bear, this topic can be revisited. For now, a note will be placed in the Release Notes for F7 about packages potentially containing .fcX where X can be different from the current release. Here is the voting record: Jesse Keating: -1 Dennis Gilmore: -1 Josh Boyer: -1 Christian Iseli: -1 Bill Nottingham: -1 Brian Pepple: -1 Kevin Fenzi: -1 Jeremy Katz: -1 Jason Tibbitts: -1 Tom Callaway: No vote Warren Togami: No vote Rex Dieter: No vote Toshio Kuratomi: No vote The no votes were either absent people or really not vote. Either way, the majority of FESCo is against the rebuild. josh From sundaram at fedoraproject.org Fri Apr 20 01:58:27 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 20 Apr 2007 07:28:27 +0530 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <1177033348.25513.55.camel@vader.jdub.homelinux.org> References: <46244EE2.5060002@redhat.com> <200704170739.02657.jkeating@redhat.com> <4624EC4B.7010002@fedoraproject.org> <200704171207.08703.jkeating@redhat.com> <4624F1FD.6070807@fedoraproject.org> <1176827194.25513.5.camel@vader.jdub.homelinux.org> <1176907234.10056.1.camel@lincoln> <1176911325.25513.30.camel@vader.jdub.homelinux.org> <1177031842.25513.44.camel@vader.jdub.homelinux.org> <46281667.5050500@fedoraproject.org> <1177033348.25513.55.camel@vader.jdub.homelinux.org> Message-ID: <46281E43.3070208@fedoraproject.org> Josh Boyer wrote: > This release was all that was discussed. If new proposals for future > releases come to bear, this topic can be revisited. For now, a note > will be placed in the Release Notes for F7 about packages potentially > containing .fcX where X can be different from the current release. You have just a day before the docs are frozen. http://fedoraproject.org/wiki/DocsProject/Schedule. I am editing the release notes right now so if anyone has suggestions for the wording let me know. My proposal for the future release is essentially the same as the one now preferably early during the devel cycle and no later than the feature freeze https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00137.html I wanted FESCo to decide on the issue on the whole rather than just for this release as the last time I requested it was before the test 4 release. That was ignored somehow it a bit too late to do rebuilds. So let me place a request now for FESCo to consider a general approach on dealing with dist tags early during Fedora 8 development. Also we might have delta rpms by default then so the argument of lesser churn of packages becomes weak. Rahul From jwboyer at jdub.homelinux.org Fri Apr 20 02:12:44 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 19 Apr 2007 21:12:44 -0500 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <46281E43.3070208@fedoraproject.org> References: <46244EE2.5060002@redhat.com> <200704170739.02657.jkeating@redhat.com> <4624EC4B.7010002@fedoraproject.org> <200704171207.08703.jkeating@redhat.com> <4624F1FD.6070807@fedoraproject.org> <1176827194.25513.5.camel@vader.jdub.homelinux.org> <1176907234.10056.1.camel@lincoln> <1176911325.25513.30.camel@vader.jdub.homelinux.org> <1177031842.25513.44.camel@vader.jdub.homelinux.org> <46281667.5050500@fedoraproject.org> <1177033348.25513.55.camel@vader.jdub.homelinux.org> <46281E43.3070208@fedoraproject.org> Message-ID: <1177035164.25513.68.camel@vader.jdub.homelinux.org> On Fri, 2007-04-20 at 07:28 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > This release was all that was discussed. If new proposals for future > > releases come to bear, this topic can be revisited. For now, a note > > will be placed in the Release Notes for F7 about packages potentially > > containing .fcX where X can be different from the current release. > > You have just a day before the docs are frozen. > > http://fedoraproject.org/wiki/DocsProject/Schedule. I am editing the > release notes right now so if anyone has suggestions for the wording let > me know. My proposal for the future release is essentially the same as > the one now preferably early during the devel cycle and no later than > the feature freeze > > https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00137.html > > I wanted FESCo to decide on the issue on the whole rather than just for > this release as the last time I requested it was before the test 4 > release. That was ignored somehow it a bit too late to do rebuilds. Given that test4 is so close, and the release in general is approaching rapidly, FESCo decided to delay a general ruling until after the release of F7. This allows us to gage the magnitude of the "confusion" factor, as well as allow time for further disttag discussions to take place before determining a general policy. > So let me place a request now for FESCo to consider a general approach > on dealing with dist tags early during Fedora 8 development. Also we > might have delta rpms by default then so the argument of lesser churn of > packages becomes weak. Your request is noted. There are other proposals at the moment as well. Thorsten mentioned changing what the disttag was in devel. Could you take a look at his proposal and see if you find it to be better/worse/complementary to yours? Given the questioning on the content of the meeting, I've disclosed the full logs of the discussion below. josh Apr 19 12:07:44 * bpepple has changed the topic to: FESCO-Meeting -- MISC -- Vote on rebuilding packages with old disttag - jwb Apr 19 12:07:50 f13: -1 Apr 19 12:07:54 dgilmore: -1 Apr 19 12:07:59 1 Apr 19 12:08:00 from the mailing lists. Apr 19 12:08:08 -1 Apr 19 12:08:23 -1 Apr 19 12:08:28 is anyone not familiar with the discussion? Apr 19 12:08:29 -1 here also, since it's pretty much a cosmetic reason. Apr 19 12:08:30 -1 (too late in the cycle). I would suggest we revist mass rebuilding per cycle after f7 is out. Apr 19 12:08:55 -1 Apr 19 12:08:55 that's a majority -1 already Apr 19 12:08:56 * bpepple agrees with nirik on having a discussion about future rebuilds. Apr 19 12:09:06 nirik: yes Apr 19 12:09:08 -1. But the users may freak out so much that we'll have to reconsider. Apr 19 12:09:09 all the dist tag/repotag mess... I think we should push for tools to be better about saying what repo/dist a package is from.... Apr 19 12:09:26 yep. i agree Apr 19 12:09:28 tibbs: maybe we should put something in the release notes regarding it? Apr 19 12:09:32 * cweyl|work belatedly grabs a seat in the rabble section Apr 19 12:09:37 nirik, we could try to get that into the vendor field Apr 19 12:09:38 bpepple: sure Apr 19 12:09:47 nirik, or some of the other fields in the rpm header maybe Apr 19 12:09:50 The people who freak are probably the ones who will never read the release notes. Apr 19 12:09:52 yeah, release notes would be a good idea Apr 19 12:10:00 yes: right now, to find out where a package is from, one looks at Buildhost Apr 19 12:10:06 tibbs: true, but they only have themselves to blame for that. Apr 19 12:10:10 But of course, it really needs to be documented. Apr 19 12:10:11 tibbs, doesn't matter. when they freak, we at least have it written down somewhere to point them at Apr 19 12:10:13 ie, have yum say: package clamav-0.90.2 (fedora) conflicts with clamav-0.90.2 (dag) or whatever... Apr 19 12:10:41 nirik, can we have that discussion later? Apr 19 12:10:59 nirik, sounds good, too Apr 19 12:10:59 * abadger1999 apologizes for being late Apr 19 12:11:00 who do we need to poke to get that into the release notes? Apr 19 12:11:08 yes, later is good. Just thought I would mention the idea. Apr 19 12:11:25 Ideally the repo flavor could get into the RPM header somewhere. Apr 19 12:11:26 bpepple: write it into Docs/Beats/ directly is the best way Apr 19 12:11:40 Ok, so FESCo is against the rebuild, and we'll add it to the release notes. Apr 19 12:11:53 alt find the beat writer on DocsProject/ReleaseNotes/Beats and ask that person to help Apr 19 12:12:04 moving on, unless someone has something to add. Apr 19 12:12:08 quaid: ok, thanks. Apr 19 12:12:17 Some note about how Fedora moves quickly and not all packages change, and Apr 19 12:12:36 how upgrades go faster when we aren't needlessly replacing packages might placate a few folks, I guess. From sundaram at fedoraproject.org Mon Apr 23 02:37:54 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 23 Apr 2007 08:07:54 +0530 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <1177035164.25513.68.camel@vader.jdub.homelinux.org> References: <46244EE2.5060002@redhat.com> <200704170739.02657.jkeating@redhat.com> <4624EC4B.7010002@fedoraproject.org> <200704171207.08703.jkeating@redhat.com> <4624F1FD.6070807@fedoraproject.org> <1176827194.25513.5.camel@vader.jdub.homelinux.org> <1176907234.10056.1.camel@lincoln> <1176911325.25513.30.camel@vader.jdub.homelinux.org> <1177031842.25513.44.camel@vader.jdub.homelinux.org> <46281667.5050500@fedoraproject.org> <1177033348.25513.55.camel@vader.jdub.homelinux.org> <46281E43.3070208@fedoraproject.org> <1177035164.25513.68.camel@vader.jdub.homelinux.org> Message-ID: <462C1C02.1000806@fedoraproject.org> Josh Boyer wrote: > Your request is noted. There are other proposals at the moment as well. > Thorsten mentioned changing what the disttag was in devel. Could you > take a look at his proposal and see if you find it to be > better/worse/complementary to yours? I don't like the idea. I agree with the analysis in https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00412.html. I would prefer a rebuild but if we are not going to rebuild all the packages with dist tags in future releases just dropping the number in "fcX" and instead using "fc" in all packages might just be better. It would send the clear message that you can't rely on the number (since there won't be any) in the package name to match the release. What other purpose does the number in the package name serve other than to indicate the release it was meant for? Rahul From davej at redhat.com Mon Apr 23 03:56:18 2007 From: davej at redhat.com (Dave Jones) Date: Sun, 22 Apr 2007 23:56:18 -0400 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <462C1C02.1000806@fedoraproject.org> References: <4624F1FD.6070807@fedoraproject.org> <1176827194.25513.5.camel@vader.jdub.homelinux.org> <1176907234.10056.1.camel@lincoln> <1176911325.25513.30.camel@vader.jdub.homelinux.org> <1177031842.25513.44.camel@vader.jdub.homelinux.org> <46281667.5050500@fedoraproject.org> <1177033348.25513.55.camel@vader.jdub.homelinux.org> <46281E43.3070208@fedoraproject.org> <1177035164.25513.68.camel@vader.jdub.homelinux.org> <462C1C02.1000806@fedoraproject.org> Message-ID: <20070423035618.GG4293@redhat.com> On Mon, Apr 23, 2007 at 08:07:54AM +0530, Rahul Sundaram wrote: > I would prefer a rebuild but if we are not going to rebuild all the > packages with dist tags in future releases just dropping the number in > "fcX" and instead using "fc" in all packages might just be better. The entire purpose of the dist tag is to discriminate between two otherwise same version packages across two releases. Changing it to 'fc' serves no purpose at all. > It would send the clear message that you can't rely on the number (since > there won't be any) in the package name to match the release. What other > purpose does the number in the package name serve other than to indicate > the release it was meant for? 1.0.fc6 and 1.0.fc7 of a package are not necessary just a rebuild, they may contain different configuration options for example. For this reason, getting bugs against '1.0.fc' would leave the question of "which 1.0" unanswered. Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Mon Apr 23 04:49:20 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 23 Apr 2007 06:49:20 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070423035618.GG4293@redhat.com> References: <4624F1FD.6070807@fedoraproject.org> <1176827194.25513.5.camel@vader.jdub.homelinux.org> <1176907234.10056.1.camel@lincoln> <1176911325.25513.30.camel@vader.jdub.homelinux.org> <1177031842.25513.44.camel@vader.jdub.homelinux.org> <46281667.5050500@fedoraproject.org> <1177033348.25513.55.camel@vader.jdub.homelinux.org> <46281E43.3070208@fedoraproject.org> <1177035164.25513.68.camel@vader.jdub.homelinux.org> <462C1C02.1000806@fedoraproject.org> <20070423035618.GG4293@redhat.com> Message-ID: <462C3AD0.8010206@leemhuis.info> On 23.04.2007 05:56, Dave Jones wrote: > On Mon, Apr 23, 2007 at 08:07:54AM +0530, Rahul Sundaram wrote: > > > I would prefer a rebuild Even with deltarpms it's IMHO to much risk and overhead (slower dist updates due to more packages needing updates; reassembling the rpms also takes time) for a small gain. > > but if we are not going to rebuild all the > > packages with dist tags in future releases just dropping the number in > > "fcX" and instead using "fc" in all packages might just be better. $ rpmdev-vercmp 0 1.0 5.fc 0 1.0 5.fc6 0:1.0-5.fc6 is newer IOW: Changing it to be just "fc" does not work. Changing it to ".1" or something else that is higher then "fc" would work. > The entire purpose of the dist tag is to discriminate between > two otherwise same version packages across two releases. > Changing it to 'fc' serves no purpose at all. Changing it to something like ".1" can get us rid of the confusion of disttag "fc6" in "Fedora 7"; see the thread starting at https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00395.html But yes, it's a kind of (dirty?) trick. > [...] @jwb (and brian, too): You mentioned that FESCo wants to look at this after F7 -- can you make sure it's somewhere on the schedule so it's not forgotten (and hopefully discussed early in the devel cycle)? CU thl From Axel.Thimm at ATrpms.net Mon Apr 23 09:34:02 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 23 Apr 2007 11:34:02 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <462C3AD0.8010206@leemhuis.info> References: <1176907234.10056.1.camel@lincoln> <1176911325.25513.30.camel@vader.jdub.homelinux.org> <1177031842.25513.44.camel@vader.jdub.homelinux.org> <46281667.5050500@fedoraproject.org> <1177033348.25513.55.camel@vader.jdub.homelinux.org> <46281E43.3070208@fedoraproject.org> <1177035164.25513.68.camel@vader.jdub.homelinux.org> <462C1C02.1000806@fedoraproject.org> <20070423035618.GG4293@redhat.com> <462C3AD0.8010206@leemhuis.info> Message-ID: <20070423093402.GE1248@neu.nirvana> On Mon, Apr 23, 2007 at 06:49:20AM +0200, Thorsten Leemhuis wrote: > On 23.04.2007 05:56, Dave Jones wrote: > > On Mon, Apr 23, 2007 at 08:07:54AM +0530, Rahul Sundaram wrote: > > > > > I would prefer a rebuild > > Even with deltarpms it's IMHO to much risk and overhead (slower dist > updates due to more packages needing updates; reassembling the rpms also > takes time) for a small gain. Didn't we already ban this as an urban legend? Can you otherwise show what savings FC6 -> F7 will give? Unless you have a full install, which is strongly discouraged and only possible with kickstart tricks, it's is close to none already. > IOW: Changing it to be just "fc" does not work. Changing it to ".1" or > something else that is higher then "fc" would > work. Changing to ".1" either means dropping disttags forever, or obscuring disttags into integers, so people don't notice. As Rahul noticed, if disttags were to be banned, what will happen with F8, F9 etc? Start manually adjusting the releases to have proper upgrade paths? That would be a giant step backwards, we already have disttags in 89% of all packages with a steady increase of >10% per release for the last three releases. I don't want to see giant lists of "EVR package problems" returning. The matter of having disttags like ".1", ".2", etc, has been discussed at langths already several years ago and was proven to be quite buggy and messing with the release tag more than you'd like. So that's not a solution either. > > The entire purpose of the dist tag is to discriminate between > > two otherwise same version packages across two releases. And to ensure proper upgrade paths, e.g. releated releases should have disttags that > > Changing it to 'fc' serves no purpose at all. > > Changing it to something like ".1" can get us rid of the confusion of > disttag "fc6" in "Fedora 7"; see the thread starting at > https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00395.html > > But yes, it's a kind of (dirty?) trick. and useless and broken. Please do think this through for the long-term implications your suggestion has. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Apr 23 10:17:29 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 23 Apr 2007 12:17:29 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070423093402.GE1248@neu.nirvana> References: <1176911325.25513.30.camel@vader.jdub.homelinux.org> <1177031842.25513.44.camel@vader.jdub.homelinux.org> <46281667.5050500@fedoraproject.org> <1177033348.25513.55.camel@vader.jdub.homelinux.org> <46281E43.3070208@fedoraproject.org> <1177035164.25513.68.camel@vader.jdub.homelinux.org> <462C1C02.1000806@fedoraproject.org> <20070423035618.GG4293@redhat.com> <462C3AD0.8010206@leemhuis.info> <20070423093402.GE1248@neu.nirvana> Message-ID: <20070423101729.GG1248@neu.nirvana> Sorry, my last mail had some sort of unvoluntarily embedded "fill the blanks" contest :) On Mon, Apr 23, 2007 at 11:34:02AM +0200, Axel Thimm wrote: > > On 23.04.2007 05:56, Dave Jones wrote: > > > The entire purpose of the dist tag is to discriminate between > > > two otherwise same version packages across two releases. > > And to ensure proper upgrade paths, e.g. releated releases should have > disttags that "are orderable in rpm's sort semantics" is the proper fill. Did you all find the right answer? ;) Next time I'll do multiple choices ;) -- 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 Apr 23 10:26:33 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 23 Apr 2007 12:26:33 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070423093402.GE1248@neu.nirvana> References: <1176907234.10056.1.camel@lincoln> <1176911325.25513.30.camel@vader.jdub.homelinux.org> <1177031842.25513.44.camel@vader.jdub.homelinux.org> <46281667.5050500@fedoraproject.org> <1177033348.25513.55.camel@vader.jdub.homelinux.org> <46281E43.3070208@fedoraproject.org> <1177035164.25513.68.camel@vader.jdub.homelinux.org> <462C1C02.1000806@fedoraproject.org> <20070423035618.GG4293@redhat.com> <462C3AD0.8010206@leemhuis.info> <20070423093402.GE1248@neu.nirvana> Message-ID: <462C89D9.9040100@leemhuis.info> On 23.04.2007 11:34, Axel Thimm wrote: > On Mon, Apr 23, 2007 at 06:49:20AM +0200, Thorsten Leemhuis wrote: >> On 23.04.2007 05:56, Dave Jones wrote: >>> On Mon, Apr 23, 2007 at 08:07:54AM +0530, Rahul Sundaram wrote: >>> > I would prefer a rebuild >> Even with deltarpms it's IMHO to much risk and overhead (slower dist >> updates due to more packages needing updates; reassembling the rpms also >> takes time) for a small gain. > Didn't we already ban this as an urban legend? No, I simply stopped replying to the thread where you calculated the number of packages that got rebuild since there was obviously a disagreement between us two if the numbers are correct or not for Extras. And it seemed to be just a discussion between us two anyway, so I assumed it didn't make much sense to continue it and annoy everyone as we both IMHO look like fools in the end. But not replying doesn't mean that I agree with you, so no, we did not "ban this as an urban legend". > Can you otherwise show > what savings FC6 -> F7 will give? [...] I'd be simply glad if every package that doesn't need to be touched doesn't get touched (downloads, risk of changes, rpmnewfiles, rpmsavefiles, ...). Even if the number is low -- for example it are currently 1/10 of the package on the rawhide machine I'm currently using. >> IOW: Changing it to be just "fc" does not work. Changing it to ".1" or >> something else that is higher then "fc" would >> work. > Changing to ".1" either means dropping disttags forever, or obscuring > disttags into integers, so people don't notice. As Rahul noticed, if > disttags were to be banned, what will happen with F8, F9 etc? Start > manually adjusting the releases to have proper upgrade paths? That > would be a giant step backwards, we already have disttags in 89% of > all packages with a steady increase of >10% per release for the last > three releases. I don't want to see giant lists of "EVR package > problems" returning. > > The matter of having disttags like ".1", ".2", etc, has been discussed > at langths already several years ago and was proven to be quite buggy > and messing with the release tag more than you'd like. So that's not a > solution either. Seems we didn't understand each other what I was up to and you bring in stuff that was never part of what I meant to do -- a disttag like ".2" for example was never mentioned in my mails in the way you describe it above and should not be needed for it (it can be used if we want to for a specific reasons, but I didn't mention that to not make the stuff even more complicated then it is already). >>> The entire purpose of the dist tag is to discriminate between >>> two otherwise same version packages across two releases. > And to ensure proper upgrade paths, e.g. releated releases should have > disttags that /me wonders if something is missing here. Anyway, if you don't do exciting and unusual stuff then the upgrade path with my ".1" example is just the same as with ".fc7" as disttag. >>> Changing it to 'fc' serves no purpose at all. >> Changing it to something like ".1" can get us rid of the confusion of >> disttag "fc6" in "Fedora 7"; see the thread starting at >> https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00395.html >> But yes, it's a kind of (dirty?) trick. > and useless and broken. Please do think this through for the long-term > implications your suggestion has. I did and explained in on fedora-maintainers. But seems you have something different in mind then I have and outlined. My fault, as my description probably wasn't good enough then. Anyway, it was just a idea that came up in my mind that IMHO could solve the problem "fc(n) disttags in fc(n+x)" if we choose to continue to not rebuild everything each cycle. Axel, let's stop arguing endlessly over detail here. Let's wait for FESCo to look at the issue after F7 is out. Maybe it decides to do a rebuild now each devel cycle in the future -- then the whole time discussing over details of the ".1" as disttag idea would be wasted time. CU thl From Axel.Thimm at ATrpms.net Mon Apr 23 11:09:46 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 23 Apr 2007 13:09:46 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <462C89D9.9040100@leemhuis.info> References: <1177031842.25513.44.camel@vader.jdub.homelinux.org> <46281667.5050500@fedoraproject.org> <1177033348.25513.55.camel@vader.jdub.homelinux.org> <46281E43.3070208@fedoraproject.org> <1177035164.25513.68.camel@vader.jdub.homelinux.org> <462C1C02.1000806@fedoraproject.org> <20070423035618.GG4293@redhat.com> <462C3AD0.8010206@leemhuis.info> <20070423093402.GE1248@neu.nirvana> <462C89D9.9040100@leemhuis.info> Message-ID: <20070423110946.GH1248@neu.nirvana> On Mon, Apr 23, 2007 at 12:26:33PM +0200, Thorsten Leemhuis wrote: > On 23.04.2007 11:34, Axel Thimm wrote: > > On Mon, Apr 23, 2007 at 06:49:20AM +0200, Thorsten Leemhuis wrote: > >> On 23.04.2007 05:56, Dave Jones wrote: > >>> On Mon, Apr 23, 2007 at 08:07:54AM +0530, Rahul Sundaram wrote: > >>> > I would prefer a rebuild > >> Even with deltarpms it's IMHO to much risk and overhead (slower dist > >> updates due to more packages needing updates; reassembling the rpms also > >> takes time) for a small gain. > > Didn't we already ban this as an urban legend? > > No, I simply stopped replying to the thread where you calculated the > number of packages that got rebuild since there was obviously a > disagreement between us two if the numbers are correct or not for > Extras. I wasn't referring to our discssion, there were more people that considered the "churn" issue to to be one. > But not replying doesn't mean that I agree with you, so no, we did not > "ban this as an urban legend". We != you and me alone. > > Can you otherwise show what savings FC6 -> F7 will give? [...] > > I'd be simply glad if every package that doesn't need to be touched > doesn't get touched (downloads, risk of changes, rpmnewfiles, > rpmsavefiles, ...). Even if the number is low -- for example it are > currently 1/10 of the package on the rawhide machine I'm currently using. Perhaps your system is either not updating properly, or you have a very distinct pick of packages, at the very least it is not typical for a common Fedora user (see below why). Please do check the real numbers on a mirror. I'll do that for you: I already quoted that FC usually had a repo build rate of 95-100% and now for the first time dropped to 80% (that was two weeks ago and the number has changed, still let's not have daily rebuild numbers). I won't get trapped in discussing again about how to interprete FE rebuilds since the data needs to be retrieved from the CVS or elsewhere. The typical user is anyway using mostly Fedora Core components by definition, since until now avery DVD/CD downloaded only had FC inside and the bits for FE were cherry-picked and net-downloaded. So there are 80% or new rebuilds, but is this 80% of the bandwidth? We know that the big players like kernels, openoffice and friends have been rebuild, let's look at the true size-weighted rebuild rate: 97.69% In order to emphasize this, the savings in Fedora Core upgrades from FC6 to F7 are 2.21% And that is the mean over i386/x86_64/ppc/source, it even get's less when looking at the binaries only: i386: 2.05% x86_64: 1.70% ppc: 1.48% source: 4.88% So, for me the "churn" argument puffs into thin air. Blocking the rebuilds of the remaining 20% of packages for saving 2% or less of download bandwidth? It's a joke. Can we consider the "big churn" an urban legend now? And if there are still doubters amongst us, then lest them install FC6 on their systems and upgarde to rawhide. May the bandwidth be with them. They will return crying that they only saved less than 2% of what they had on disk ... > > Changing to ".1" either means dropping disttags forever, or obscuring > > disttags into integers, so people don't notice. [...] > Seems we didn't understand each other what I was up to and you bring in > stuff that was never part of what I meant to do -- a disttag like ".2" > for example was never mentioned in my mails in the way you describe it > above OK, so you are for dropping disttags forever. This was covered in my mail and Rahul's. > >>> The entire purpose of the dist tag is to discriminate between > >>> two otherwise same version packages across two releases. > > And to ensure proper upgrade paths, e.g. releated releases should have > > disttags that > > /me wonders if something is missing here. fill the blanks. > Anyway, if you don't do exciting and unusual stuff then the upgrade path > with my ".1" example is just the same as with ".fc7" as disttag. And what about F8? Please think further than F7. See my comments on EVR havok if we start dropping the disttags. There is a reason the disttags became that popular that by F8 every package (more correct 98%) will have one. Unless they die in FUD, of course. > > and useless and broken. Please do think this through for the long-term > > implications your suggestion has. > > I did and explained in on fedora-maintainers. But seems you have > something different in mind then I have and outlined. No, see above I had both cases covered. > Axel, let's stop arguing endlessly over detail here. But the devil is in the details. You "overlook" details like the size of the churn (which is only 2%), often Fedora Extras did rebuilds (you assumed 2/3, while you yourself involked full rebuilds for FC6 and before), it's far better to use factual numbers than to make false assumptions based on fear, uncertainty and doubt. If we don't examine the details and present a sane analysis based on the details wrong decisions will be made once more. So, please do look at details and facts and do think stuff through to the end and to the next to the next release. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Mon Apr 23 11:44:12 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 23 Apr 2007 06:44:12 -0500 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070423110946.GH1248@neu.nirvana> References: <1177031842.25513.44.camel@vader.jdub.homelinux.org> <46281667.5050500@fedoraproject.org> <1177033348.25513.55.camel@vader.jdub.homelinux.org> <46281E43.3070208@fedoraproject.org> <1177035164.25513.68.camel@vader.jdub.homelinux.org> <462C1C02.1000806@fedoraproject.org> <20070423035618.GG4293@redhat.com> <462C3AD0.8010206@leemhuis.info> <20070423093402.GE1248@neu.nirvana> <462C89D9.9040100@leemhuis.info> <20070423110946.GH1248@neu.nirvana> Message-ID: <1177328652.25513.83.camel@vader.jdub.homelinux.org> On Mon, 2007-04-23 at 13:09 +0200, Axel Thimm wrote: > > If we don't examine the details and present a sane analysis based on > the details wrong decisions will be made once more. > > So, please do look at details and facts and do think stuff through to > the end and to the next to the next release. Which is why it will be revisited after F7 is released. josh From bpepple at fedoraproject.org Mon Apr 23 16:22:13 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 23 Apr 2007 12:22:13 -0400 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <462C3AD0.8010206@leemhuis.info> References: <4624F1FD.6070807@fedoraproject.org> <1176827194.25513.5.camel@vader.jdub.homelinux.org> <1176907234.10056.1.camel@lincoln> <1176911325.25513.30.camel@vader.jdub.homelinux.org> <1177031842.25513.44.camel@vader.jdub.homelinux.org> <46281667.5050500@fedoraproject.org> <1177033348.25513.55.camel@vader.jdub.homelinux.org> <46281E43.3070208@fedoraproject.org> <1177035164.25513.68.camel@vader.jdub.homelinux.org> <462C1C02.1000806@fedoraproject.org> <20070423035618.GG4293@redhat.com> <462C3AD0.8010206@leemhuis.info> Message-ID: <1177345333.5869.2.camel@lincoln> On Mon, 2007-04-23 at 06:49 +0200, Thorsten Leemhuis wrote: > > @jwb (and brian, too): You mentioned that FESCo wants to look at this > after F7 -- can you make sure it's somewhere on the schedule so it's not > forgotten (and hopefully discussed early in the devel cycle)? I'll add it to the schedule to look at after F7. /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 mlum at redhat.com Fri Apr 27 07:29:45 2007 From: mlum at redhat.com (Margaret Lum) Date: Fri, 27 Apr 2007 00:29:45 -0700 Subject: Help with Fedora's criteria for project imports? Message-ID: <4631A669.20304@redhat.com> Hi folks, I work for Red Hat, in the Identity Management team. I'm a release engineer, and my team is working on further open sourcing the Certificate System. The section on ForbiddenItems appears rather vague, so is it possible for a member of the board to assist our team with reviewing (or helping to review) some of what we are planning to open source. Does this include code reviews (meetings thereof), upload-reject-re-upload-re-review scenarios, or could the process be relatively simple for our 13-odd packages that need to be migrated? If a particular board individual could contact me to discuss the process moving forward, along with providing some level of assistance to ensure we can have our RFRs approved, this would be greatly appreciated. Thank you for your time, and I look forward to your reply. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3229 bytes Desc: S/MIME Cryptographic Signature URL: From gdk at redhat.com Fri Apr 27 13:24:21 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Fri, 27 Apr 2007 09:24:21 -0400 (EDT) Subject: Help with Fedora's criteria for project imports? In-Reply-To: <4631A669.20304@redhat.com> References: <4631A669.20304@redhat.com> Message-ID: On Fri, 27 Apr 2007, Margaret Lum wrote: > Hi folks, > > I work for Red Hat, in the Identity Management team. I'm a release engineer, > and my team is working on further open sourcing the Certificate System. The > section on ForbiddenItems appears rather vague, so is it possible for a > member of the board to assist our team with reviewing (or helping to review) > some of what we are planning to open source. Does this include code reviews > (meetings thereof), upload-reject-re-upload-re-review scenarios, or could the > process be relatively simple for our 13-odd packages that need to be > migrated? There's two sets of issues, I'm guessing: pacakaging (technical) and licenses (legal/policy). Which are you more concerned about? Because they're probably separate conversations. --g -- Greg DeKoenigsberg Community Development Manager Red Hat, Inc. :: 1-919-754-4255 "To whomsoever much hath been given... ...from him much shall be asked" From rdieter at math.unl.edu Fri Apr 27 13:41:11 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 27 Apr 2007 08:41:11 -0500 Subject: Help with Fedora's criteria for project imports? In-Reply-To: References: <4631A669.20304@redhat.com> Message-ID: <4631FD77.4040005@math.unl.edu> Greg Dekoenigsberg wrote: > On Fri, 27 Apr 2007, Margaret Lum wrote: >> I work for Red Hat, in the Identity Management team. I'm a release >> engineer, and my team is working on further open sourcing the >> Certificate System. The section on ForbiddenItems appears rather ^^^^^^^^^^^^^^ > There's two sets of issues, I'm guessing: packaging (technical) and > licenses (legal/policy). > Which are you more concerned about? Because they're probably separate > conversations. The mention of ForbiddenItems seems to imply the latter, though imo, both issues can/should be addressed by the usual package review process. In the meantime, Margaret, I will volunteer as liason for your questions/concerns. -- Rex From mlum at redhat.com Fri Apr 27 23:49:29 2007 From: mlum at redhat.com (Margaret Lum) Date: Fri, 27 Apr 2007 16:49:29 -0700 Subject: Help with Fedora's criteria for project imports? In-Reply-To: References: <4631A669.20304@redhat.com> Message-ID: <46328C09.70903@redhat.com> Greg Dekoenigsberg wrote: > On Fri, 27 Apr 2007, Margaret Lum wrote: > >> Hi folks, >> >> I work for Red Hat, in the Identity Management team. I'm a release >> engineer, and my team is working on further open sourcing the >> Certificate System. The section on ForbiddenItems appears rather >> vague, so is it possible for a member of the board to assist our team >> with reviewing (or helping to review) some of what we are planning to >> open source. Does this include code reviews (meetings thereof), >> upload-reject-re-upload-re-review scenarios, or could the process be >> relatively simple for our 13-odd packages that need to be migrated? > > There's two sets of issues, I'm guessing: pacakaging (technical) and > licenses (legal/policy). > > Which are you more concerned about? Because they're probably separate > conversations. > > --g > Hi Greg, I'm concerned about the prospect of submitting requests for approval to import our sanitized components, but being rejected for non-licensing issues. Technically, I believe we have our ducks in a row, but the "legal stuff" is where a nebulous cloud currently hangs. Rex offered to help us out, so I'm going to speak with him. I know that we need to have our licenses updated to (L)GPL, be package-able through Koji, have all the necessary mailing lists, groups, ACLs, remove branded-proprietary code (we came from Netscape/AOL and have government contracts), adopt the Fedora development process, and likely exclude signing from our releng process (until there's a RH-sponsored non-ncipher possibility in the near future). What I'm wondering is -- what else is there? Thanks for any help/thoughts. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3229 bytes Desc: S/MIME Cryptographic Signature URL: From mlum at redhat.com Sat Apr 28 00:13:59 2007 From: mlum at redhat.com (Margaret Lum) Date: Fri, 27 Apr 2007 17:13:59 -0700 Subject: Help with Fedora's criteria for project imports? In-Reply-To: <4631FD77.4040005@math.unl.edu> References: <4631A669.20304@redhat.com> <4631FD77.4040005@math.unl.edu> Message-ID: <463291C7.6050204@redhat.com> Rex Dieter wrote: > Greg Dekoenigsberg wrote: >> On Fri, 27 Apr 2007, Margaret Lum wrote: > >>> I work for Red Hat, in the Identity Management team. I'm a release >>> engineer, and my team is working on further open sourcing the >>> Certificate System. The section on ForbiddenItems appears rather > ^^^^^^^^^^^^^^ >> There's two sets of issues, I'm guessing: packaging (technical) and >> licenses (legal/policy). >> Which are you more concerned about? Because they're probably >> separate conversations. > > The mention of ForbiddenItems seems to imply the latter, though imo, > both issues can/should be addressed by the usual package review process. > > In the meantime, Margaret, I will volunteer as liason for your > questions/concerns. > > -- Rex > Hi Rex, Thank you very much for responding with your offer to help -- we will be taking you up on this! I left you a voicemail. I will try to contact you again early Monday morning (PST) to discuss further. Thanks again for volunteering to help us out. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3229 bytes Desc: S/MIME Cryptographic Signature URL: From gdk at redhat.com Sat Apr 28 04:53:58 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Sat, 28 Apr 2007 00:53:58 -0400 (EDT) Subject: Help with Fedora's criteria for project imports? In-Reply-To: <46328C09.70903@redhat.com> References: <4631A669.20304@redhat.com> <46328C09.70903@redhat.com> Message-ID: On Fri, 27 Apr 2007, Margaret Lum wrote: > I'm concerned about the prospect of submitting requests for approval to > import our sanitized components, but being rejected for non-licensing issues. > Technically, I believe we have our ducks in a row, but the "legal stuff" is > where a nebulous cloud currently hangs. > > Rex offered to help us out, so I'm going to speak with him. I know that we > need to have our licenses updated to (L)GPL, be package-able through Koji, > have all the necessary mailing lists, groups, ACLs, remove > branded-proprietary code (we came from Netscape/AOL and have government > contracts), adopt the Fedora development process, and likely exclude signing > from our releng process (until there's a RH-sponsored non-ncipher possibility > in the near future). What I'm wondering is -- what else is there? Rex will definitely be able to help you along -- but really, I don't think there is much else. So long as the code is under an approved license, the RPMs are packaged according to the guidelines, and your team sticks around to maintain the packages, there really *shouldn't* be much else. Any legal issues remaining are likely to be inside the RH fenceline, not in Fedora-land. --g -- Greg DeKoenigsberg Community Development Manager Red Hat, Inc. :: 1-919-754-4255 "To whomsoever much hath been given... ...from him much shall be asked" From mlum at redhat.com Fri Apr 27 21:34:26 2007 From: mlum at redhat.com (Margaret Lum) Date: Fri, 27 Apr 2007 14:34:26 -0700 Subject: Help with Fedora's criteria for project imports? In-Reply-To: References: <4631A669.20304@redhat.com> <46328C09.70903@redhat.com> Message-ID: <46326C62.8050407@redhat.com> Greg Dekoenigsberg wrote: > On Fri, 27 Apr 2007, Margaret Lum wrote: > >> I'm concerned about the prospect of submitting requests for approval >> to import our sanitized components, but being rejected for >> non-licensing issues. Technically, I believe we have our ducks in a >> row, but the "legal stuff" is where a nebulous cloud currently hangs. >> >> Rex offered to help us out, so I'm going to speak with him. I know >> that we need to have our licenses updated to (L)GPL, be package-able >> through Koji, have all the necessary mailing lists, groups, ACLs, >> remove branded-proprietary code (we came from Netscape/AOL and have >> government contracts), adopt the Fedora development process, and >> likely exclude signing from our releng process (until there's a >> RH-sponsored non-ncipher possibility in the near future). What I'm >> wondering is -- what else is there? > > > Rex will definitely be able to help you along -- but really, I don't > think there is much else. So long as the code is under an approved > license, the RPMs are packaged according to the guidelines, and your > team sticks around to maintain the packages, there really *shouldn't* > be much else. Any legal issues remaining are likely to be inside the > RH fenceline, not in Fedora-land. > > --g > Is there someone, in particular, within Red Hat/within Fedora with whom we should speak about the potential legal issues? (I assume there might be an offline answer to this..) From tcallawa at redhat.com Sun Apr 29 03:41:32 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 28 Apr 2007 22:41:32 -0500 Subject: Help with Fedora's criteria for project imports? In-Reply-To: <46326C62.8050407@redhat.com> References: <4631A669.20304@redhat.com> <46328C09.70903@redhat.com> <46326C62.8050407@redhat.com> Message-ID: <1177818092.4390.1.camel@localhost.localdomain> On Fri, 2007-04-27 at 14:34 -0700, Margaret Lum wrote: > Is there someone, in particular, within Red Hat/within Fedora with whom > we should speak about the potential legal issues? (I assume there might > be an offline answer to this..) You want quick advice? Rex, or myself. You want a lawyer to look at something and get back to you sometime before the sun explodes? That's probably Mark Webbink. ~spot From tcallawa at redhat.com Sun Apr 29 03:42:25 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 28 Apr 2007 22:42:25 -0500 Subject: Help with Fedora's criteria for project imports? In-Reply-To: <1177818092.4390.1.camel@localhost.localdomain> References: <4631A669.20304@redhat.com> <46328C09.70903@redhat.com> <46326C62.8050407@redhat.com> <1177818092.4390.1.camel@localhost.localdomain> Message-ID: <1177818145.4390.3.camel@localhost.localdomain> On Sat, 2007-04-28 at 22:41 -0500, Tom "spot" Callaway wrote: > On Fri, 2007-04-27 at 14:34 -0700, Margaret Lum wrote: > > > Is there someone, in particular, within Red Hat/within Fedora with whom > > we should speak about the potential legal issues? (I assume there might > > be an offline answer to this..) > > You want quick advice? Rex, or myself. > > You want a lawyer to look at something and get back to you sometime > before the sun explodes? That's probably Mark Webbink. Note that this is not intended as a slam against Mark, he's awesome, just very busy. :) ~spot From aoliva at redhat.com Sun Apr 29 22:48:41 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Sun, 29 Apr 2007 19:48:41 -0300 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <46267E12.4090500@fedoraproject.org> (Rahul Sundaram's message of "Thu\, 19 Apr 2007 01\:52\:42 +0530") References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> <461ECEB1.7000301@redhat.com> <46267E12.4090500@fedoraproject.org> Message-ID: On Apr 18, 2007, Rahul Sundaram wrote: > John Poelstra wrote: >> >> On a related topic... from the Fedora main page... >> >> "...All in pursuit of the best operating system and platform that >> free software can provide." >> >> What don't we have a link there to the Fedora definition of "free >> software?" > Done. > http://fedoraproject.org/wiki/FedoraMain Thank you for this. Too bad Fedora is taking a step away from its goal in release 7, introducing non-Free Software (even if only firmware), but it's very good to know that the goal is what I'd always thought it to be. Now, those who dismiss firmware freedom issues as irrelevant might want to have a look at the material FSFLA prepared for FLISoL, a Free Software install fest all over Latin American, that took place yesterday, that in part addresses this very issue. http://www.fsfla.org/svnwiki/flisol2007 Enjoy, -- 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 jkeating at redhat.com Sun Apr 29 22:46:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 29 Apr 2007 15:46:05 -0700 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: References: <461D8225.4050907@domsch.com> <46267E12.4090500@fedoraproject.org> Message-ID: <200704291546.05450.jkeating@redhat.com> On Sunday 29 April 2007 15:48:41 Alexandre Oliva wrote: > Now, those who dismiss firmware freedom issues as irrelevant might > want to have a look at the material FSFLA prepared for FLISoL, a Free > Software install fest all over Latin American, that took place > yesterday, that in part addresses this very issue. > > ? http://www.fsfla.org/svnwiki/flisol2007 Page not found -- 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 aoliva at redhat.com Sun Apr 29 22:52:15 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Sun, 29 Apr 2007 19:52:15 -0300 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: (Alexandre Oliva's message of "Sun\, 29 Apr 2007 19\:48\:41 -0300") References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> <461ECEB1.7000301@redhat.com> <46267E12.4090500@fedoraproject.org> Message-ID: On Apr 29, 2007, Alexandre Oliva wrote: > Now, those who dismiss firmware freedom issues as irrelevant might > want to have a look at the material FSFLA prepared for FLISoL, a Free > Software install fest all over Latin American, that took place > yesterday, that in part addresses this very issue. Sorry, the URL I just posted was wrong. Here's the correct one: http://fsfla.org/svnwiki/texto/flisol2007/ -- 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 tcallawa at redhat.com Mon Apr 30 00:08:49 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 29 Apr 2007 19:08:49 -0500 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> <461ECEB1.7000301@redhat.com> <46267E12.4090500@fedoraproject.org> Message-ID: <1177891729.3836.27.camel@localhost.localdomain> > Now, those who dismiss firmware freedom issues as irrelevant might > want to have a look at the material FSFLA prepared for FLISoL, a Free > Software install fest all over Latin American, that took place > yesterday, that in part addresses this very issue. It addresses it how? With rhetoric? Rhetoric is good, but it doesn't solve the primary problem: Users need working drivers for their hardware. 3d can be seen as a luxury, an acceptable sacrifice, but wireless? It cannot. I agree that we need to aggressively work with vendors to either remove the need for firmware blobs (Alan Cox can document (has documented?) how this is possible) or open the "source" for those firmware files. However, Fedora is not in a position where we can simply tell our users that we will not ship these files on political or moral grounds. They will simply go to Ubuntu. Or SuSE. Or any number of other distributions. We do the best that we can to compromise. We don't ship any "code" that is proprietary. We only permit firmware that is freely redistributable without restrictions. This compromise gives our users working wireless out of the box. Since the users cannot choose to download the firmware over their non-functional network, the only other step that I think we could take would be to prompt the user during install that in order to make their wireless work, Fedora needs to install firmware that is not-free. Perhaps thats not a bad idea for F8. I want to see the FSF advising Fedora what it can do to influence the hardware vendors to not use firmware blobs without killing off our user base. But that is a much harder problem to solve, and involves less rhetoric. ~spot From open07 at gmail.com Mon Apr 30 02:03:42 2007 From: open07 at gmail.com (Koh Choon Lin) Date: Mon, 30 Apr 2007 02:03:42 +0000 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <1177891729.3836.27.camel@localhost.localdomain> References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> <461ECEB1.7000301@redhat.com> <46267E12.4090500@fedoraproject.org> <1177891729.3836.27.camel@localhost.localdomain> Message-ID: > I want to see the FSF advising Fedora what it can do to influence the > hardware vendors to not use firmware blobs without killing off our user > base. But that is a much harder problem to solve, and involves less > rhetoric. We need to convince the open source movement to join with us in boycotting those companies whose hardware has no drivers. Regards Koh Choon Lin Singapore GNU Group singapore.gnu.googlepages.com From mmcgrath at redhat.com Mon Apr 30 02:28:06 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 29 Apr 2007 21:28:06 -0500 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> <461ECEB1.7000301@redhat.com> <46267E12.4090500@fedoraproject.org> <1177891729.3836.27.camel@localhost.localdomain> Message-ID: <46355436.7010004@redhat.com> Koh Choon Lin wrote: >> I want to see the FSF advising Fedora what it can do to influence the >> hardware vendors to not use firmware blobs without killing off our user >> base. But that is a much harder problem to solve, and involves less >> rhetoric. > > We need to convince the open source movement to join with us in > boycotting those companies whose hardware has no drivers. > Our efforts would be better spent educating users and providing a platform for the companies. In the instance of firmware drivers the difference between utopia and what is reasonable isn't that large. Most users won't go out of their way to boycott a company since "binary drivers" != "killing kittens" -Mike From jwboyer at jdub.homelinux.org Mon Apr 30 03:19:37 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 29 Apr 2007 22:19:37 -0500 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <46355436.7010004@redhat.com> References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> <461ECEB1.7000301@redhat.com> <46267E12.4090500@fedoraproject.org> <1177891729.3836.27.camel@localhost.localdomain> <46355436.7010004@redhat.com> Message-ID: <1177903177.4903.17.camel@vader.jdub.homelinux.org> On Sun, 2007-04-29 at 21:28 -0500, Mike McGrath wrote: > Koh Choon Lin wrote: > >> I want to see the FSF advising Fedora what it can do to influence the > >> hardware vendors to not use firmware blobs without killing off our user > >> base. But that is a much harder problem to solve, and involves less > >> rhetoric. > > > > We need to convince the open source movement to join with us in > > boycotting those companies whose hardware has no drivers. > > > > Our efforts would be better spent educating users and providing a > platform for the companies. In the instance of firmware drivers the > difference between utopia and what is reasonable isn't that large. Most > users won't go out of their way to boycott a company since "binary > drivers" != "killing kittens" We don't ship binary drivers. We ship freely redistributable firmware that only runs on the card in question. And every time someone installs a binary driver, a kitten dies?. josh ? I'm fairly confident that given the kitten mortality rate, and the frequency at which users install binary drivers, this statement will be statistically correct. And even if they don't die, they turn bad and get into your glibc and break your fgets. From sundaram at fedoraproject.org Mon Apr 30 08:59:35 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 30 Apr 2007 14:29:35 +0530 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> <461ECEB1.7000301@redhat.com> <46267E12.4090500@fedoraproject.org> Message-ID: <4635AFF7.6070204@fedoraproject.org> Alexandre Oliva wrote: > Thank you for this. > > Too bad Fedora is taking a step away from its goal in release 7, > introducing non-Free Software (even if only firmware), but it's very > good to know that the goal is what I'd always thought it to be. I am having some discussions off list with Brett Smith from FSF on how we can deal with this which has moved the discussions forward as you can see from the comments in the LWN article . I am now waiting on further responses from him. Like Spot says we need more constructive action and understanding on solving the problems of usability and getting stuff to work. If you can help you got to do that. I don't think articles in FSFLA website is the answer there. Rahul From aoliva at redhat.com Mon Apr 30 14:31:58 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 30 Apr 2007 11:31:58 -0300 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <1177891729.3836.27.camel@localhost.localdomain> (Tom Callaway's message of "Sun\, 29 Apr 2007 19\:08\:49 -0500") References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> <461ECEB1.7000301@redhat.com> <46267E12.4090500@fedoraproject.org> <1177891729.3836.27.camel@localhost.localdomain> Message-ID: On Apr 29, 2007, "Tom \"spot\" Callaway" wrote: > It addresses it how? With rhetoric? If you take rhetoric as an synonym with education, yes. > Rhetoric is good, but it doesn't solve the primary problem: It does, just not in the short term. The more people accept freedom-incompatible hardware, the more they feed the monster that turns against them and all the community. If people learn to reject that, such vendors will still be free to offer such freedom-incompatible hardware, but their marketshare will shrink, and more vendors will seek to respect people's freedom. This is why it is so important to make people aware of the fact that their hardware is incompatible with freedom. Such that they can know what to avoid next time they go shopping for computers or parts. I've actually suggested a way Fedora could accomplish this: http://www.redhat.com/archives/fedora-advisory-board/2007-March/msg00169.html But AFAIK nothing to this end was done. Is it just because the suggestion came in too late, is it unclear, or was it deemed too much engineering effort to remain faithful to our stated goals? > However, Fedora is not in a position where we can simply tell our users > that we will not ship these files on political or moral grounds. Is any part of my suggestion incompatible with your statement? > We do the best that we can to compromise. Compromising is precisely the problem ;-) There's a way to not compromise and still let users take the step if they want to, but instead we decide to take ourselves the step away from our stated goals. > We don't ship any "code" that is proprietary. We only permit > firmware that is freely redistributable without restrictions. Well, sorry, but that is proprietary code. This line-drawing is just double-thinking. Proprietary firmware and proprietary BIOSes are just as inconvenient as any kind of proprietary software. I know I've suffered because I couldn't fix a number of BIOSes in computers I've had, and upgradable firmware in other devices I have. > This compromise gives our users working wireless out of the box. I understand the goal and I've suggested a way to accomplish this that doesn't involve taking this step ourselves. > Since the users cannot choose to download the firmware over their > non-functional network, That's why the suggestion involved driver disk-like media. > the only other step that I think we could take would be to prompt > the user during install that in order to make their wireless work, > Fedora needs to install firmware that is not-free. This would at least give more assurance to someone involved in the development of clean-room firmware. But just having downloaded the software as part of Fedora could get someone covered by a no-reverse-engineering clause in a license of this kind of firmware. Do we really want to spread not only the message that using non-Free Software is acceptable, but that it's ok to actively spread software that limits the freedoms of others? > I want to see the FSF advising Fedora what it can do to influence the > hardware vendors to not use firmware blobs without killing off our user > base. I'm not involved with the FSF. I've done what I could from the FSFLA standpoint, to no avail. > But that is a much harder problem to solve, and involves less > rhetoric. It involves education. And by silently loading such firmware into people's computers, the opposite goal is achieved. (Wrong) Way to go! -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From sundaram at fedoraproject.org Mon Apr 30 14:44:10 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 30 Apr 2007 20:14:10 +0530 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> <461ECEB1.7000301@redhat.com> <46267E12.4090500@fedoraproject.org> <1177891729.3836.27.camel@localhost.localdomain> Message-ID: <463600BA.5010402@fedoraproject.org> Alexandre Oliva wrote: > On Apr 29, 2007, "Tom \"spot\" Callaway" wrote: > > >> We don't ship any "code" that is proprietary. We only permit >> firmware that is freely redistributable without restrictions. > > Well, sorry, but that is proprietary code. This line-drawing is just > double-thinking. Look at http://www.gnu.org/links/links.html. In these only one does not have non-free firmware inside the kernel. Where is the user being education or the difference being highlighted? Rahul From mspevack at redhat.com Mon Apr 30 18:18:03 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 30 Apr 2007 14:18:03 -0400 (EDT) Subject: Tuesday May 1 Fedora Board Meeting topics Message-ID: There are several issues worth discussing tomorrow morning (10:00 AM eastern time, 14:00 GMT) in #fedora-meeting. (1) Thorsten's draft proposal suggesting a division of responsibility between the Board and FESCO is worth people's time reading. http://fedoraproject.org/wiki/ThorstenLeemhuis/FESCoAndBoard My guess is we can probably get some email list discussion of it prior to tomorrow's meeting, and then hash out in IRC any of the biggest concerns. (2) In a similar vein, any current topics that FESCO is working through that need input or decision making from the Board. Basically an update to the Board from FESCO, that includes anything that FESCO would like the Board to act on. (3) Just because this is an area that I'm personally a bit behind on, I wonder if one of the people who is leading up EPEL would like to share with the Board (and anyone else who is on IRC at the time) what the current status of EPEL is, if there's any big issues that need to be resolved, etc. (4) Any other topics that need to be brought up. I am hesitant to talk in great detail about anything post-F7 yet, simply because with the Red Hat Summit coming next week, and F7 release on May 24th, we're very much in pre-release crunch time. But if there are any topics people feel need to be brought up tomorrow, we will set aside some time. Again, I'd like to try to handle tomorrow's meeting entirely on IRC, with no phone call component. There will be NO meeting next Tuesday (May 8th), since many of the people on the Board will be going to the Red Hat Summit. Thanks, Max -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From aoliva at redhat.com Mon Apr 30 18:50:35 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 30 Apr 2007 15:50:35 -0300 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: <463600BA.5010402@fedoraproject.org> (Rahul Sundaram's message of "Mon\, 30 Apr 2007 20\:14\:10 +0530") References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> <461ECEB1.7000301@redhat.com> <46267E12.4090500@fedoraproject.org> <1177891729.3836.27.camel@localhost.localdomain> <463600BA.5010402@fedoraproject.org> Message-ID: On Apr 30, 2007, Rahul Sundaram wrote: > Alexandre Oliva wrote: >> On Apr 29, 2007, "Tom \"spot\" Callaway" wrote: >> >> >>> We don't ship any "code" that is proprietary. We only permit >>> firmware that is freely redistributable without restrictions. >> >> Well, sorry, but that is proprietary code. This line-drawing is just >> double-thinking. > Look at http://www.gnu.org/links/links.html. In these only one does > not have non-free firmware inside the kernel. Once more time, I'm not talking about the firmware in the kernel. That's harder to remove, I agree. One has to get out of one's way to do that. I'm talking about going out of our way to *add* firmware that we could perfectly well leave for others to ship. If there's indeed commitment to Free Software, one would hope we'd eventually get to inside the kernel, but all I'm talking about ATM is the non-Free stuff that we add to the distro ourselves. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From sundaram at fedoraproject.org Mon Apr 30 18:57:51 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 01 May 2007 00:27:51 +0530 Subject: LWN headline: Blame Fedora = High Praise In-Reply-To: References: <461D8225.4050907@domsch.com> <1176344287.13177.23.camel@cutter> <1176344404.5208.155.camel@erato.phig.org> <2cb10c440704120851j45984dabi273f57389e4aa37a@mail.gmail.com> <20070412160139.GW15933@deprecation.cyrius.com> <461ECEB1.7000301@redhat.com> <46267E12.4090500@fedoraproject.org> <1177891729.3836.27.camel@localhost.localdomain> <463600BA.5010402@fedoraproject.org> Message-ID: <46363C2F.5070401@fedoraproject.org> Alexandre Oliva wrote: > Once more time, I'm not talking about the firmware in the kernel. > > That's harder to remove, I agree. One has to get out of one's way to > do that. Just pointing out that you are drawing a line between firmware inside the kernel and firmware outside of it while Fedora is drawing a line between firmware and other forms of proprietary software. If one of these is double thinking so is the other one. Atleast in Fedora the division is clearly documented in the packaging guidelines. > I'm talking about going out of our way to *add* firmware that we could > perfectly well leave for others to ship. > > If there's indeed commitment to Free Software, one would hope we'd > eventually get to inside the kernel, but all I'm talking about ATM is > the non-Free stuff that we add to the distro ourselves. You need to bring this up Fedora 7 launch. Now is too late to be making changes for this release. Rahul