From buildsys at fedoraproject.org Mon Apr 2 21:20:38 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 2 Apr 2007 17:20:38 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-04-02 Message-ID: <20070402212038.85C4E152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 4 pgfouine-1.0-1.el5 NEW python-metar-1.3.0-2.el5 NEW yaz-2.1.54-1.el5 zabbix-1.1.7-1.el5 Packages built and released for Fedora EPEL 4: 5 firmware-addon-dell-1.2.6-1.el4 pgfouine-1.0-1.el4 NEW python-metar-1.3.0-2.el4 NEW yaz-2.1.54-1.el4 zabbix-1.1.7-1.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From Axel.Thimm at ATrpms.net Tue Apr 3 15:07:48 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 3 Apr 2007 17:07:48 +0200 Subject: Log from last EPEL SIG meeting In-Reply-To: <20070329123349.20773c9e@python3.es.egwn.lan> References: <46094ED1.7090204@leemhuis.info> <20070329123349.20773c9e@python3.es.egwn.lan> Message-ID: <20070403150748.GL29856@neu.nirvana> On Thu, Mar 29, 2007 at 12:33:49PM +0200, Matthias Saou wrote: > Thorsten Leemhuis wrote : > > > * RHEL5 final should be on the builders soon (maybe already when you > > read this); thl will announce to Fedora contributors to actually start > > to build for EPEL5 -- seems to him a lot of people wait for a "Go" > > signal. The packages currently in EPEL5 probably need a rebuild; it was > > discussed to simply delete the repo and build the packages again, but > > between the meeting and writing the logs this issue was raised again on > > the list > > So, what is it going to be? Delete everything and rebuild or append .1 > to the release and make new builds? I hope we'll go with the non-forking version, but another unresolved, but related matter came up: What happened to the disttag/repotag discussion? If the disttag is extended to include some repotag the rebuilds will be newer and thus we don't need to append .1 and fork specfiles. (Assuming that most packages that need a rebuild do have a %{?dist}) We should settle the disttag/repotag issue now to avoid further rebuilds again. -- 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 FamilleCollet.com Tue Apr 3 18:40:46 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Tue, 03 Apr 2007 20:40:46 +0200 Subject: EL5 Builder status Message-ID: <46129FAE.3010103@FamilleCollet.com> Hi, What is the status of the EL5 builder ? Just trying to build a php-pear extension result in : No Package Found for php-pear >= 1:1.4.9-1.2 RHEL 5 come with php-pear-1.4.9-4 (i have successfully build my RPM on a local RHEL 5 builder) Regards From fedora at leemhuis.info Wed Apr 4 18:54:43 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 04 Apr 2007 20:54:43 +0200 Subject: Votings via the wiki Message-ID: <4613F473.9000005@leemhuis.info> Hi all, I prepared a wiki page to be used for votings in the future; see http://fedoraproject.org/wiki/EPEL/SteeringCommittee for details. Does the outlined procedure look sane to everybody? Find it below for discussion and easier inline replying (but it's a wiki; feel free to enhance it directly there if you want). ---- = Votings = The [:EPEL/SteeringCommittee: EPEL Steering Committee] often decides stuff in the regular IRC meetings of the EPEL SIG. But not all SIG and steering committee members can attend each meeting. So for decisions that are controversial or can't wait until the next meeting we'll use this page to collect the opinions and ideas. Please prepare votings by * adding them to this page, including details like * a short statement what the vote is about * the available options including their pros and cons; please try to be fair to each side, even if you prefer a option * announcing the vote to the mailing list so people can discuss the options -- or yell at you if you missed pros and cons ;-) * if needed: improve the voting description and send it to the list again if bigger changes were done * wait a bit to give people a chance to discuss stuff before the actually voting starts -- normally at least three days. This gives non-steering committee members a chance to express their opinions and get heard before the voting starts * votings should have a target date ---- CU thl From fedora at leemhuis.info Wed Apr 4 18:58:33 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 04 Apr 2007 20:58:33 +0200 Subject: First voting: Rebuild of EPEL5 (was: Re: Votings via the wiki) In-Reply-To: <4613F473.9000005@leemhuis.info> References: <4613F473.9000005@leemhuis.info> Message-ID: <4613F559.90400@leemhuis.info> Me again! Thorsten Leemhuis schrieb: > I prepared a wiki page to be used for votings in the future; see > http://fedoraproject.org/wiki/EPEL/SteeringCommittee > for details. Does the outlined procedure look sane to everybody? Find it > below for discussion and easier inline replying (but it's a wiki; feel > free to enhance it directly there if you want). I actually created the first voting in the wiki to try the procedure for the first time. Find it below for comments from the public before the actual voting by the EPEL Steering Committee begins. This is your chance to get your opinion heard, so feel free to send your opinions or enhancements for the voting description itself. ---- === Rebuild of EPEL5 === Background: The packages currently in EPEL5 got build against RHEL5beta1; the plan is to rebuild them against RHEL5. The question is: how? Options: 1. Tell users to manually rebuild their stuff; for those packages that didn't get rebuild: Use a script that adds a ".1" to the Release of each spec file, commit the changes, tag, build 2. Simply delete the current repo and rebuild all packages Pros and cons: * With "1" ENVR stays unique, with "2" it doesn't; therefore in the latter case different packages with the same ENVR are in the wild (the new ones in the repo, the older ones on people that have them installed already), which can lead to confusing situations: * bug reports: user still has the old package installed that has a bug while packager fails to reproduce as he uses the new one * debuginfo packages from the new packages don't work for the older ones * With "1" can (if they want) make sure the build order is correct, with "2" not * With "2" Specs stay in sync between different Fedora branches, which isn't the case with "1" ---- CU thl From Axel.Thimm at ATrpms.net Wed Apr 4 20:30:29 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 4 Apr 2007 22:30:29 +0200 Subject: Voting: repotag for EPEL Message-ID: <20070404203029.GE15113@neu.nirvana> http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting#head-efb18a3ff4ed343c4a8aa17dc0a8466bab8c9024 Voting topic: Should EPEL carry a repotag? If yes, the technical details will be delegated to the Packaging Committee. Background: Last month's discussions under https://www.redhat.com/archives/epel-devel-list/2007-March/msg00276.html, https://www.redhat.com/archives/epel-devel-list/2007-March/msg00258.html, https://www.redhat.com/archives/epel-devel-list/2007-March/msg00224.html Voting period: until 20070410 UTC 23:59 -- 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 Wed Apr 4 20:31:26 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 4 Apr 2007 22:31:26 +0200 Subject: Voting: Vetoing fedora-usermgmt until FPC makes a decision Message-ID: <20070404203126.GF15113@neu.nirvana> Voting topic: Packages should not use fedora-usermgmt or other non-standard useradd replacements. Background: Large thread starting at https://www.redhat.com/archives/epel-devel-list/2007-March/msg00029.html, also many threads on various non-epel lists, too many to list here. Voting period: until 20070410 UTC 23:59 -- 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 Thu Apr 5 04:42:06 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 Apr 2007 06:42:06 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <20070404203029.GE15113@neu.nirvana> References: <20070404203029.GE15113@neu.nirvana> Message-ID: <46147E1E.5040302@leemhuis.info> On 04.04.2007 22:30, Axel Thimm wrote: > http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting#head-efb18a3ff4ed343c4a8aa17dc0a8466bab8c9024 > Voting topic: Should EPEL carry a repotag? If yes, the technical > details will be delegated to the Packaging Committee. I'm not going to vote on something where I don't know the technical details yet. I also strongly dislike the kind of voting -- the threads you pointed to are much to confusing and have FUD and personal attacks in it. Before doing a voting on a controversial topic like this it's IMHO really necessary to write a summary about the whole stuff. CU thl From fedora at leemhuis.info Thu Apr 5 04:44:55 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 Apr 2007 06:44:55 +0200 Subject: Voting: Vetoing fedora-usermgmt until FPC makes a decision In-Reply-To: <20070404203126.GF15113@neu.nirvana> References: <20070404203126.GF15113@neu.nirvana> Message-ID: <46147EC7.2040307@leemhuis.info> On 04.04.2007 22:31, Axel Thimm wrote: > Voting topic: Packages should not use fedora-usermgmt or other > non-standard useradd replacements. > > Background: Large thread starting at > https://www.redhat.com/archives/epel-devel-list/2007-March/msg00029.html, > also many threads on various non-epel lists, too many to list here. > > Voting period: until 20070410 UTC 23:59 Same as in the other mail. Sum the discussions up before asking for a voting. CU thl From fedora at leemhuis.info Thu Apr 5 04:58:03 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 Apr 2007 06:58:03 +0200 Subject: Voting: Vetoing fedora-usermgmt until FPC makes a decision In-Reply-To: <46147EC7.2040307@leemhuis.info> References: <20070404203126.GF15113@neu.nirvana> <46147EC7.2040307@leemhuis.info> Message-ID: <461481DB.6080405@leemhuis.info> On 05.04.2007 06:44, Thorsten Leemhuis wrote: > > On 04.04.2007 22:31, Axel Thimm wrote: >> Voting topic: Packages should not use fedora-usermgmt or other >> non-standard useradd replacements. >> >> Background: Large thread starting at >> https://www.redhat.com/archives/epel-devel-list/2007-March/msg00029.html, >> also many threads on various non-epel lists, too many to list here. >> >> Voting period: until 20070410 UTC 23:59 > > Same as in the other mail. Sum the discussions up before asking for a > voting. BTW, the whole voting via the wiki is IMHO a experiment ATM. I'd really like to see the repotag and the fedora-usermgmt stuff discussed in a meeting. CU thl From Axel.Thimm at ATrpms.net Thu Apr 5 06:59:46 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 5 Apr 2007 08:59:46 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <46147E1E.5040302@leemhuis.info> References: <20070404203029.GE15113@neu.nirvana> <46147E1E.5040302@leemhuis.info> Message-ID: <20070405065946.GG15113@neu.nirvana> On Thu, Apr 05, 2007 at 06:42:06AM +0200, Thorsten Leemhuis wrote: > On 04.04.2007 22:30, Axel Thimm wrote: > > http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting#head-efb18a3ff4ed343c4a8aa17dc0a8466bab8c9024 > > Voting topic: Should EPEL carry a repotag? If yes, the technical > > details will be delegated to the Packaging Committee. > > I'm not going to vote on something where I don't know the technical > details yet. Yetserday you didn't even want to have EPEL be authoritative opn that and wanted to outsource the whole decision to the FPC. Why the change of heart? The voting above is the political aspect which we as EPEL need to make. > I also strongly dislike the kind of voting -- the threads you > pointed to are much to confusing and have FUD and personal attacks > in it. Before doing a voting on a controversial topic like this it's > IMHO really necessary to write a summary about the whole stuff. I'm sorry, but I can't control the content of this list, it is free for everyone and a thread can have both helpful and less helpful content. Dumping the whole discussion because someone tried to sabotage it by making it a flamewar is a good tool to stall us forever. It's really been beaten to death in great lengths over the last month and everyone on the committee must have an opinion by now. You participated in the discussions as well. So, let's get this finalized and move on to other topics. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Apr 5 07:04:21 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 5 Apr 2007 09:04:21 +0200 Subject: Voting: Vetoing fedora-usermgmt until FPC makes a decision In-Reply-To: <46147EC7.2040307@leemhuis.info> References: <20070404203126.GF15113@neu.nirvana> <46147EC7.2040307@leemhuis.info> Message-ID: <20070405070421.GH15113@neu.nirvana> On Thu, Apr 05, 2007 at 06:44:55AM +0200, Thorsten Leemhuis wrote: > > > On 04.04.2007 22:31, Axel Thimm wrote: > > Voting topic: Packages should not use fedora-usermgmt or other > > non-standard useradd replacements. > > > > Background: Large thread starting at > > https://www.redhat.com/archives/epel-devel-list/2007-March/msg00029.html, > > also many threads on various non-epel lists, too many to list here. > > > > Voting period: until 20070410 UTC 23:59 > > Same as in the other mail. Sum the discussions up before asking for a > voting. I'm probably too biased (or at least I can't see any cons in dropping this), and I think people here have seen way too much of this discussion on 3 lists over a month by now. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Thu Apr 5 07:22:37 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 Apr 2007 09:22:37 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <20070405065946.GG15113@neu.nirvana> References: <20070404203029.GE15113@neu.nirvana> <46147E1E.5040302@leemhuis.info> <20070405065946.GG15113@neu.nirvana> Message-ID: <4614A3BD.8000007@leemhuis.info> On 05.04.2007 08:59, Axel Thimm wrote: > On Thu, Apr 05, 2007 at 06:42:06AM +0200, Thorsten Leemhuis wrote: >> On 04.04.2007 22:30, Axel Thimm wrote: >>> http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting#head-efb18a3ff4ed343c4a8aa17dc0a8466bab8c9024 >>> Voting topic: Should EPEL carry a repotag? If yes, the technical >>> details will be delegated to the Packaging Committee. >> I'm not going to vote on something where I don't know the technical >> details yet. > Yetserday you didn't even want to have EPEL be authoritative opn that > and wanted to outsource the whole decision to the FPC. Why the change > of heart? The voting above is the political aspect which we as EPEL > need to make. I still want to "outsource the whole decision to the FPC". The reasons why I don't vote like this ATM: Currently I would vote "no", as there is no proper solution for repotags in our spec files ATM (abusing dist is more them sub-optimal, as dist is optional, and thus we would have a repotag only in a subset of out packages, which IMHO makes not much sense). But in real life it's no "no" -- if the Packaging Committee is fine with having a repotag and presents a solution that makes it easy to move packages between Fedora and EPEL without adjustments then I would "abstrain", because I don't care about it (well, in fact I'm a slightly bit against repotags, as we have a field in the rpm header that serves the same purpose; having a information in two places sounds wrong to me, but I'm willing to ignore that). >> I also strongly dislike the kind of voting -- the threads you >> pointed to are much to confusing and have FUD and personal attacks >> in it. Before doing a voting on a controversial topic like this it's >> IMHO really necessary to write a summary about the whole stuff. > > I'm sorry, but I can't control the content of this list, it is free > for everyone and a thread can have both helpful and less helpful > content. Dumping the whole discussion because someone tried to > sabotage it by making it a flamewar is a good tool to stall us > forever. [...] Then please write a summary for those that got annoyed after the first flamebit and stopped reading the thread further. I suppose many people did. Summing up seems quite important to me, that why I added it to the voting rules that I proposed for discussion: https://www.redhat.com/archives/epel-devel-list/2007-April/msg00003.html CU thl From wolfy at nobugconsulting.ro Thu Apr 5 07:30:02 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Thu, 05 Apr 2007 10:30:02 +0300 Subject: Voting: repotag for EPEL In-Reply-To: <4614A3BD.8000007@leemhuis.info> References: <20070404203029.GE15113@neu.nirvana> <46147E1E.5040302@leemhuis.info> <20070405065946.GG15113@neu.nirvana> <4614A3BD.8000007@leemhuis.info> Message-ID: <4614A57A.1020805@nobugconsulting.ro> Thorsten Leemhuis wrote: > [...] > The reasons why I don't vote like this ATM: Currently I would vote "no", > as there is no proper solution for repotags in our spec files ATM > (abusing dist is more them sub-optimal, as dist is optional, and thus we > would have a repotag only in a subset of out packages, which IMHO makes > not much sense). But in real life it's no "no" -- if the Packaging > Committee is fine with having a repotag and presents a solution that > makes it easy to move packages between Fedora and EPEL without > adjustments then I would "abstrain", because I don't care about it > (well, in fact I'm a slightly bit against repotags, as we have a field > in the rpm header that serves the same purpose; having a information in > two places sounds wrong to me, but I'm willing to ignore that). Maybe we could ship an alias or something which would execute a command similar to rpm -q --qf %{vendor} ? I suggest this because I am afraid that adding this flag by default to rpm -q would break other things.. . From fedora at leemhuis.info Thu Apr 5 07:31:18 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 Apr 2007 09:31:18 +0200 Subject: Voting: Vetoing fedora-usermgmt until FPC makes a decision In-Reply-To: <20070405070421.GH15113@neu.nirvana> References: <20070404203126.GF15113@neu.nirvana> <46147EC7.2040307@leemhuis.info> <20070405070421.GH15113@neu.nirvana> Message-ID: <4614A5C6.6020001@leemhuis.info> On 05.04.2007 09:04, Axel Thimm wrote: > On Thu, Apr 05, 2007 at 06:44:55AM +0200, Thorsten Leemhuis wrote: >> >> On 04.04.2007 22:31, Axel Thimm wrote: >>> Voting topic: Packages should not use fedora-usermgmt or other >>> non-standard useradd replacements. >>> >>> Background: Large thread starting at >>> https://www.redhat.com/archives/epel-devel-list/2007-March/msg00029.html, >>> also many threads on various non-epel lists, too many to list here. >>> >>> Voting period: until 20070410 UTC 23:59 >> Same as in the other mail. Sum the discussions up before asking for a >> voting. > > I'm probably too biased (or at least I can't see any cons in dropping > this), and I think people here have seen way too much of this > discussion on 3 lists over a month by now. Con: several packages that are in Fedora can't get into EPEL right now and would need to be adjusted; that's would be a burden for the maintainer that then might say "well, if they make it hard for me then I don't care about EPEL and stick to Fedora" Con: several packages would have to wait for the decision of the Packaging committee before they can enter EPEL; that can take some time. Two quite big Cons for me. CU thl From Axel.Thimm at ATrpms.net Thu Apr 5 07:33:46 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 5 Apr 2007 09:33:46 +0200 Subject: Voting: Vetoing fedora-usermgmt until FPC makes a decision In-Reply-To: <4614A5C6.6020001@leemhuis.info> References: <20070404203126.GF15113@neu.nirvana> <46147EC7.2040307@leemhuis.info> <20070405070421.GH15113@neu.nirvana> <4614A5C6.6020001@leemhuis.info> Message-ID: <20070405073346.GI15113@neu.nirvana> On Thu, Apr 05, 2007 at 09:31:18AM +0200, Thorsten Leemhuis wrote: > > > On 05.04.2007 09:04, Axel Thimm wrote: > > On Thu, Apr 05, 2007 at 06:44:55AM +0200, Thorsten Leemhuis wrote: > >> > >> On 04.04.2007 22:31, Axel Thimm wrote: > >>> Voting topic: Packages should not use fedora-usermgmt or other > >>> non-standard useradd replacements. > >>> > >>> Background: Large thread starting at > >>> https://www.redhat.com/archives/epel-devel-list/2007-March/msg00029.html, > >>> also many threads on various non-epel lists, too many to list here. > >>> > >>> Voting period: until 20070410 UTC 23:59 > >> Same as in the other mail. Sum the discussions up before asking for a > >> voting. > > > > I'm probably too biased (or at least I can't see any cons in dropping > > this), and I think people here have seen way too much of this > > discussion on 3 lists over a month by now. > > Con: [...] > > Con: [...] Looks like you aren't biased at all. ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Apr 5 07:50:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 5 Apr 2007 09:50:13 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <4614A3BD.8000007@leemhuis.info> References: <20070404203029.GE15113@neu.nirvana> <46147E1E.5040302@leemhuis.info> <20070405065946.GG15113@neu.nirvana> <4614A3BD.8000007@leemhuis.info> Message-ID: <20070405075013.GJ15113@neu.nirvana> On Thu, Apr 05, 2007 at 09:22:37AM +0200, Thorsten Leemhuis wrote: > On 05.04.2007 08:59, Axel Thimm wrote: > > On Thu, Apr 05, 2007 at 06:42:06AM +0200, Thorsten Leemhuis wrote: > >> On 04.04.2007 22:30, Axel Thimm wrote: > >>> http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting#head-efb18a3ff4ed343c4a8aa17dc0a8466bab8c9024 > >>> Voting topic: Should EPEL carry a repotag? If yes, the technical > >>> details will be delegated to the Packaging Committee. > >> I'm not going to vote on something where I don't know the technical > >> details yet. > > Yetserday you didn't even want to have EPEL be authoritative opn that > > and wanted to outsource the whole decision to the FPC. Why the change > > of heart? The voting above is the political aspect which we as EPEL > > need to make. > > I still want to "outsource the whole decision to the FPC". > > [...] Currently I would vote "no", [...] But in real life it's no > "no" -- if the Packaging Committee is [doing certain things to your > liking] That's not outsourcing a decision - that is outsourcing a decision only if it fits your mindset ;) It's either us doing the whole act, e.g. decide on the political content and decide on the technical implementation, or we can move out the technical implementation to the group that does stuff like that and trust their (technical) judgement. I don't care about either model, I just don't want to see the *political* decision being made *outside* of EPEL. > >> I also strongly dislike the kind of voting -- the threads you > >> pointed to are much to confusing and have FUD and personal attacks > >> in it. Before doing a voting on a controversial topic like this it's > >> IMHO really necessary to write a summary about the whole stuff. > > > > I'm sorry, but I can't control the content of this list, it is free > > for everyone and a thread can have both helpful and less helpful > > content. Dumping the whole discussion because someone tried to > > sabotage it by making it a flamewar is a good tool to stall us > > forever. [...] > > Then please write a summary for those that got annoyed after the first > flamebit and stopped reading the thread further. I suppose many people did. > > Summing up seems quite important to me, that why I added it to the > voting rules that I proposed for discussion: > https://www.redhat.com/archives/epel-devel-list/2007-April/msg00003.html I checked the threads and all names of the people voting appeared in there, I'm really not game for rereading about 100 emails and summing them up - if you feel you need to do so, nobody will stop you. Please, Thorsten, we did set up a voting body to overcome situation like these w/o endless debates which will eventually all contain some flamesets or another. That is not to say we don't want discussion of things that come up for voting, but if it's been discussed ad nausea already we should spare ourselved the pain and proceed to finalizing it. And there are already mechanisms set into the voting procedure to avoid any sneaking in of stuff nobody knew about. That's certainly not the case here, most people know too much about these discussions to keep their lunch in their stomach and want to see us finalize things and move on. -- 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 Thu Apr 5 08:19:29 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 Apr 2007 10:19:29 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <20070405075013.GJ15113@neu.nirvana> References: <20070404203029.GE15113@neu.nirvana> <46147E1E.5040302@leemhuis.info> <20070405065946.GG15113@neu.nirvana> <4614A3BD.8000007@leemhuis.info> <20070405075013.GJ15113@neu.nirvana> Message-ID: <4614B111.8000703@leemhuis.info> On 05.04.2007 09:50, Axel Thimm wrote: > On Thu, Apr 05, 2007 at 09:22:37AM +0200, Thorsten Leemhuis wrote: >> On 05.04.2007 08:59, Axel Thimm wrote: >>> On Thu, Apr 05, 2007 at 06:42:06AM +0200, Thorsten Leemhuis wrote: >>>> On 04.04.2007 22:30, Axel Thimm wrote: >>>>> http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting#head-efb18a3ff4ed343c4a8aa17dc0a8466bab8c9024 >>>>> Voting topic: Should EPEL carry a repotag? If yes, the technical >>>>> details will be delegated to the Packaging Committee. >>>> I'm not going to vote on something where I don't know the technical >>>> details yet. >>> Yetserday you didn't even want to have EPEL be authoritative opn that >>> and wanted to outsource the whole decision to the FPC. Why the change >>> of heart? The voting above is the political aspect which we as EPEL >>> need to make. >> I still want to "outsource the whole decision to the FPC". >> >> [...] Currently I would vote "no", [...] But in real life it's no >> "no" -- if the Packaging Committee is [doing certain things to your >> liking] "doing certain things to your liking"??? I don't care what they decide, but in this case I think it's their business as the results have strong impact for people that want to write spec files for Fedora and EPEL and want to exchange then between the two. > It's either us doing the whole act, e.g. decide on the political > content and decide on the technical implementation, [...] That's why we made sure we have people in both EPEL and the PC (e.g. you) to work out a political and a technical solution that later works for both sides. Political and technical are hand in hand here, and IMHO should be solved together. >>>> I also strongly dislike the kind of voting -- the threads you >>>> pointed to are much to confusing and have FUD and personal attacks >>>> in it. Before doing a voting on a controversial topic like this it's >>>> IMHO really necessary to write a summary about the whole stuff. >>> I'm sorry, but I can't control the content of this list, it is free >>> for everyone and a thread can have both helpful and less helpful >>> content. Dumping the whole discussion because someone tried to >>> sabotage it by making it a flamewar is a good tool to stall us >>> forever. [...] >> Then please write a summary for those that got annoyed after the first >> flamebit and stopped reading the thread further. I suppose many people did. >> Summing up seems quite important to me, that why I added it to the >> voting rules that I proposed for discussion: >> https://www.redhat.com/archives/epel-devel-list/2007-April/msg00003.html > I checked the threads and all names of the people voting appeared in > there, I'm really not game for rereading about 100 emails and summing > them up - if you feel you need to do so, nobody will stop you. > > Please, Thorsten, we did set up a voting body to overcome situation > like these w/o endless debates which will eventually all contain some > flamesets or another. [...] People that vote should know what they vote about to make the decision, and that's not the case here afaics. CU thl From Axel.Thimm at ATrpms.net Thu Apr 5 09:04:49 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 5 Apr 2007 11:04:49 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <4614B111.8000703@leemhuis.info> References: <20070404203029.GE15113@neu.nirvana> <46147E1E.5040302@leemhuis.info> <20070405065946.GG15113@neu.nirvana> <4614A3BD.8000007@leemhuis.info> <20070405075013.GJ15113@neu.nirvana> <4614B111.8000703@leemhuis.info> Message-ID: <20070405090449.GK15113@neu.nirvana> On Thu, Apr 05, 2007 at 10:19:29AM +0200, Thorsten Leemhuis wrote: > I don't care what they decide, but in this case I think it's [FPC's] > business [...] > > People [of the EPEL committee] that vote should know what they vote > about to make the decision, and that's not the case here afaics. You need to decide, do you make it FPC's call or not? You can't have it both ways, e.g. put the FPC through making a decision and then turning it down. And the FPC is not a political organ, EPEL is (in this context). Don't pass on the Old Maid to the FPC. The decision on whether or not to introduce repotags is ours, and that's all what the voting proposal is about. Consider the EPEL/FPC relation here like management and engineering. The manager decides, the engineer turns the decision into bits. If you like to decide on implementation details within EPEL the FPC will be grateful to only get a ready EPEL-releated guideline to vote on. Otherwise you can rightfully pass it on to the FPC and they/we will form adequate mechanisms like they do for all issues they get thrown at. Which if the FPC foobars can still be stopped at fesco level, every EPEL/FPC decision ultimatively goes through fesco, in this case it will even have to go twice. So, as you see everything has its proper procedures and mechanisms. But it is *you* (as a member of EPEL) that will make a political decision on using repotags or not and what signal of cooperation this will beam onto other 3rd party repos. -- 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 Thu Apr 5 09:55:31 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 Apr 2007 11:55:31 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <20070405090449.GK15113@neu.nirvana> References: <20070404203029.GE15113@neu.nirvana> <46147E1E.5040302@leemhuis.info> <20070405065946.GG15113@neu.nirvana> <4614A3BD.8000007@leemhuis.info> <20070405075013.GJ15113@neu.nirvana> <4614B111.8000703@leemhuis.info> <20070405090449.GK15113@neu.nirvana> Message-ID: <4614C793.7030806@leemhuis.info> On 05.04.2007 11:04, Axel Thimm wrote: > On Thu, Apr 05, 2007 at 10:19:29AM +0200, Thorsten Leemhuis wrote: >> I don't care what they decide, but in this case I think it's [FPC's] >> business [...] >> People [of the EPEL committee] that vote should know what they vote >> about to make the decision, and that's not the case here afaics. > You need to decide, do you make it FPC's call or not? You can't have > it both ways, e.g. put the FPC through making a decision and then > turning it down. Sure. > And the FPC is not a political organ, EPEL is (in this context). Don't > pass on the Old Maid to the FPC. The decision on whether or not to > introduce repotags is ours, and that's all what the voting proposal is > about. I disagree. The decision about to introduce repotags is IMHO one that needs to be done by EPEL and FPC together, as the decisions, if repotags are worth the trouble IMHO depends on how the technical solution looks like and what kind of trouble it creates for the package maintainers. That just fair to everyone (including the FPC) as we can't simply dump work on the FPC like this. > Consider the EPEL/FPC relation here like management and > engineering. The manager decides, the engineer turns the decision into > bits. So "Manager=EPEL" and "Engineering=FPC"? Then I strongly disagree. The Fedora Board is the only manager in Fedora-land afaics. FESCo is some kind of manager for SIGs/Groups below it (like EPEL and FPC), but also does a lot of engineering. EPEL and FPC further are on the same hierarchy in Fedora-land, and they can ask each other kindly to do something, but they can't say "you have to do foo now because we want it like that". I other words: FPC is no dumping ground for realizing something EPEL wants. > If you like to decide on implementation details within EPEL the FPC > will be grateful to only get a ready EPEL-releated guideline to vote > on. I don't want do decide on implementation details. But the decision how I vote if repotags are worth the trouble is influenced by the rough concept how to realize them. And that's why I'd like to see that solved first before the vote. > [...] Axel, the best thing at this point of time afaics is not a binding vote with the question "Should EPEL carry a repotag". A more simple questioning "Should we investigate further if we want to use a repotag and how it could be realize it if we want to" would be much better. My option on this whole issue, in case it matters: "Should EPEL carry a repotag" -> I don't want to make that decisions now, before I know if the gain is worth the pain (if there is pain). "Should we investigate further if we want to use a repotag and how to realize it if we want to" -> yes CU thl From Axel.Thimm at ATrpms.net Thu Apr 5 10:02:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 5 Apr 2007 12:02:40 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <4614C793.7030806@leemhuis.info> References: <20070404203029.GE15113@neu.nirvana> <46147E1E.5040302@leemhuis.info> <20070405065946.GG15113@neu.nirvana> <4614A3BD.8000007@leemhuis.info> <20070405075013.GJ15113@neu.nirvana> <4614B111.8000703@leemhuis.info> <20070405090449.GK15113@neu.nirvana> <4614C793.7030806@leemhuis.info> Message-ID: <20070405100240.GL15113@neu.nirvana> On Thu, Apr 05, 2007 at 11:55:31AM +0200, Thorsten Leemhuis wrote: > I other words: FPC is no dumping ground for realizing something EPEL wants. No, we will certainly resist that. That was not what I was implying, you probably know that. The point is - once again - that the political decision is not FPC's to make, but EPELs, don't push that away. The engineering/implementation parts are FPC's to make. > Axel, the best thing at this point of time afaics is not a binding vote > with the question "Should EPEL carry a repotag". A more simple > questioning "Should we investigate further if we want to use a repotag > and how it could be realize it if we want to" would be much better. Aka postpone, work w/o a repotag and later noone wants to touch it again. Aka effectivly vote against it, but pretend we care. Why didn't you "investigate" when it was discussed? Everyone else including the FPC did. We need to finalize it and face it with a proper decision, no more pushing away to FPC, future or any other place/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 Thu Apr 5 10:30:31 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 Apr 2007 12:30:31 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <20070405100240.GL15113@neu.nirvana> References: <20070404203029.GE15113@neu.nirvana> <46147E1E.5040302@leemhuis.info> <20070405065946.GG15113@neu.nirvana> <4614A3BD.8000007@leemhuis.info> <20070405075013.GJ15113@neu.nirvana> <4614B111.8000703@leemhuis.info> <20070405090449.GK15113@neu.nirvana> <4614C793.7030806@leemhuis.info> <20070405100240.GL15113@neu.nirvana> Message-ID: <4614CFC7.9090108@leemhuis.info> On 05.04.2007 12:02, Axel Thimm wrote: > On Thu, Apr 05, 2007 at 11:55:31AM +0200, Thorsten Leemhuis wrote: >> I other words: FPC is no dumping ground for realizing something EPEL wants. > No, we will certainly resist that. I would, too. ;-) > That was not what I was implying, you probably know that. Then I'd say your example was quite bad. > The point is - once again - that the political > decision is not FPC's to make, but EPELs, don't push that away. The > engineering/implementation parts are FPC's to make. It's a hand in hand process by both afaics. >> Axel, the best thing at this point of time afaics is not a binding vote >> with the question "Should EPEL carry a repotag". A more simple >> questioning "Should we investigate further if we want to use a repotag >> and how it could be realize it if we want to" would be much better. > Aka postpone, work w/o a repotag and later noone wants to touch it > again. Aka effectivly vote against it, but pretend we care. Why didn't > you "investigate" when it was discussed? Everyone else including the > FPC did. > > We need to finalize it and face it with a proper decision, no more > pushing away to FPC, future or any other place/time. We just need someone to work out how the technical solution roughly could look like before I'm willig to vote. Someone that wants repotag should do that to get some "+1 for repotags" on his side afaics. You seem to be interested in repotags and you are in both committees; you look like the ideal candidate to do that to me. Propose a rough concept how it could look like and you'll get a "abstrains" or maybe even a "+1" from me. Currently it's a 'don't want to vote at all; but if I'm forced to vote now it's definitely a "no repotags"'. Is the latter what you want? CU thl From Axel.Thimm at ATrpms.net Thu Apr 5 13:51:51 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 5 Apr 2007 15:51:51 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <4614CFC7.9090108@leemhuis.info> References: <20070404203029.GE15113@neu.nirvana> <46147E1E.5040302@leemhuis.info> <20070405065946.GG15113@neu.nirvana> <4614A3BD.8000007@leemhuis.info> <20070405075013.GJ15113@neu.nirvana> <4614B111.8000703@leemhuis.info> <20070405090449.GK15113@neu.nirvana> <4614C793.7030806@leemhuis.info> <20070405100240.GL15113@neu.nirvana> <4614CFC7.9090108@leemhuis.info> Message-ID: <20070405135151.GA4531@neu.nirvana> On Thu, Apr 05, 2007 at 12:30:31PM +0200, Thorsten Leemhuis wrote: > Someone that wants repotag should do that to get some "+1 for > repotags" on his side afaics. You seem to be interested in repotags So do obviously you. > and you are in both committees; you look like the ideal candidate to > do that to me. And you look like the ideal candidate from my POV, because even though you once "didn't really care", you now do care quite a lot and obviously don't want repotags in EPEL. > Currently it's a 'don't want to vote at all; but if I'm forced to > vote now it's definitely a "no repotags"'. Is the latter what you > want? No, don't put the blame on me (or the FPC or the future), it's your vote. There was enough, even too much discussion on this already, and we just add to it. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Thu Apr 5 14:09:09 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 05 Apr 2007 09:09:09 -0500 Subject: Voting: repotag for EPEL In-Reply-To: <46147E1E.5040302@leemhuis.info> References: <20070404203029.GE15113@neu.nirvana> <46147E1E.5040302@leemhuis.info> Message-ID: <46150305.4040605@math.unl.edu> Thorsten Leemhuis wrote: > On 04.04.2007 22:30, Axel Thimm wrote: >> http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting#head-efb18a3ff4ed343c4a8aa17dc0a8466bab8c9024 >> Voting topic: Should EPEL carry a repotag? If yes, the technical >> details will be delegated to the Packaging Committee. ... > Before doing a voting on a controversial topic like this it's > IMHO really necessary to write a summary about the whole stuff. +1 imo... This is, a "well, duh, of course" common-sense kind of thing. The FPC wouldn't likely consider voting on anything without a proper proposal/summary-of-issues either. Yes, it's more work, but it's a necessary evil if you want voting done right. -- Rex From fedora at leemhuis.info Thu Apr 5 14:47:35 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 Apr 2007 16:47:35 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <20070405135151.GA4531@neu.nirvana> References: <20070404203029.GE15113@neu.nirvana> <46147E1E.5040302@leemhuis.info> <20070405065946.GG15113@neu.nirvana> <4614A3BD.8000007@leemhuis.info> <20070405075013.GJ15113@neu.nirvana> <4614B111.8000703@leemhuis.info> <20070405090449.GK15113@neu.nirvana> <4614C793.7030806@leemhuis.info> <20070405100240.GL15113@neu.nirvana> <4614CFC7.9090108@leemhuis.info> <20070405135151.GA4531@neu.nirvana> Message-ID: <46150C07.5050404@leemhuis.info> Axel Thimm schrieb: > On Thu, Apr 05, 2007 at 12:30:31PM +0200, Thorsten Leemhuis wrote: >> Someone that wants repotag should do that to get some "+1 for >> repotags" on his side afaics. You seem to be interested in repotags > So do obviously you. No, I don't care about repotags. But I care about the procedures how decisions are going to be made in EPEL, and I dislike this "let's simply do a vote on foo because bar would like to vote on it, even if there are no background informations provided on the topic and it's unclear what the consequences are". Especially when the "voting via wiki" is still in the experimental stages. >> and you are in both committees; you look like the ideal candidate to >> do that to me. > And you look like the ideal candidate from my POV, because even though > you once "didn't really care", you now do care quite a lot and > obviously don't want repotags in EPEL. Please be so kind don't put things in my mouth that are not mine. I really dislike that (and I assume most people would dislike it, too). As I said earlier in this thread: "in fact I'm a slightly bit against repotags, as we have a field in the rpm header that serves the same purpose; having a information in two places sounds wrong to me, but I'm willing to ignore that." (add a "for the sake of making for example dag happy" if you want to make it more clear). This is/was a general statement and even if it would contain a EPEL in it is far away from "I don't want repotags in EPEL." >> Currently it's a 'don't want to vote at all; but if I'm forced to >> vote now it's definitely a "no repotags"'. Is the latter what you >> want? > No, don't put the blame on me (or the FPC or the future), it's your > vote. You started it and you have to support it if you want people to vote. You can cancel it. I plan to not vote, as I would vote with "no" currently because I'm not sure what consequences a "yes" might result in for the repo and the packagers that have to write spec files. But as I said, if someone show a sane way how to actually realize the repotag in the packages in a way that doesn't make spec file exchanges between Fedora and EPEL harder I'll "abstrain" from a vote or might even support the idea. > There was enough, even too much discussion on this already, and we > just add to it. I disagree. Even yesterday in the meeting new stuff like "how to actually realize a repotag" or "use the repotag everywhere or abuse dist and ignore the rest that don't use the disttag" came up. CU thl From bjohnson-sender-11eeb1 at symetrix.com Thu Apr 5 15:22:21 2007 From: bjohnson-sender-11eeb1 at symetrix.com (Bernard Johnson) Date: Thu, 05 Apr 2007 09:22:21 -0600 Subject: Voting: Vetoing fedora-usermgmt until FPC makes a decision In-Reply-To: <4614A5C6.6020001@leemhuis.info> References: <20070404203126.GF15113@neu.nirvana> <46147EC7.2040307@leemhuis.info> <20070405070421.GH15113@neu.nirvana> <4614A5C6.6020001@leemhuis.info> Message-ID: <4615142D.3020303@symetrix.com> Thorsten Leemhuis wrote: > Con: several packages that are in Fedora can't get into EPEL right now > and would need to be adjusted; that's would be a burden for the > maintainer that then might say "well, if they make it hard for me then I > don't care about EPEL and stick to Fedora" > > I already have two packages that use fedora-usermgmt that have been branched to EPEL. What about them? I don't feel strongly either way regarding using or not using fedora-usermgmt, however, I do feel strongly about branching the spec file because one repo can use it and another doesn't allow it. /me currently awaiting someone's decision :) From fedora at leemhuis.info Thu Apr 5 15:39:36 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 Apr 2007 17:39:36 +0200 Subject: Summary from yesterdays EPEL SIG meeting Message-ID: <46151838.30803@leemhuis.info> = Meeting 20070405 = [[TableOfContents]] == Attending == >From the Steering Committee: * mmcgrath * nirik * quaid * thimm * thl Active on the rabble seats: * che * entr0py == Summary == * RHEL5 final on the builders -- did still not happen due to legal problems, that hopefully get solved soon * Mass rebuild of EPEL5 -- thl prepared a page on the wiki to try the voting-via-the-wiki with this topic; details got send to the list in between * the mass rebuild discussion drifted of into the repotag issue. Some discussions how to actually realize a repotag if we want one. Abusing dist would result in a repo where only some packages use the disttag, as using dist is optional in Fedora. * entr0py> | any comments on my request for brp-python-bytecompile? -> thimm> | entr0py: brp-python-bytecompile is currently under discussion for other issues, too ; So an improved version may appear in *-rpm-config which would fix your issue as well * RHEL5's $RELEASEVER translates to 5Server instead of 5 -> the plan is to hardcode 5 in the repo file to avoid problems == Full Log == {{{ 00:00 < thimm> | epel meeting? 00:00 < entr0py> | here 00:01 < thl> | hi thimm entr0py 00:01 * | nirik was just going to ask. 00:01 --- | thl has changed the topic to: EPEL meeting 00:01 * | thl looks closer at his clock 00:01 < thl> | I was in wokring in the wiki and lost time 00:01 < thl> | ping mmcgrath 00:02 < thl> | ping quaid 00:02 --> | sharkcz (Dan Horak) has joined #fedora-meeting 00:02 < thl> | dgilmore is busy, he can't join us today 00:02 < thl> | mmcgrath is in phx iirc, so probably busy with other stuff as well 00:02 < quaid> | oh yeah! 00:03 < thl> | hi quaid 00:03 < quaid> | hi thl 00:03 --> | Kylixen (Kylixen) has joined #fedora-meeting 00:03 < thl> | so, some infors first 00:03 < thl> | RHEL5 still not on the builders 00:03 < thl> | there were some legal problems that stopped the work for some days 00:04 < thl> | but the problems gfot sorted out 00:04 --> | che (Rudolf Kastl) has joined #fedora-meeting 00:04 < nirik> | centos5 isn't out yet is it? 00:04 < mmcgrath> | pong 00:04 < mmcgrath> | I actually haven't left yet. 00:04 < thimm> | what legal problem? 00:04 < thl> | nirik, end of this week / beginning of next week afaik 00:04 * | skvidal nods at thl 00:04 < thl> | thimm, well, I think it was no real problem 00:05 < thl> | thimm, someone feared a problems and asked legal afaik 00:05 < thl> | and everything got sorted out 00:05 < thl> | I don't know any details about it 00:05 < mmcgrath> | I sent a follow up email this morning regarding RHEL this morning. 00:05 <-- | amitphukan has quit ("Leaving (????? ?????)") 00:05 < mmcgrath> | Haven't heard back. 00:05 < thimm> | Is there anyway I can help with getting RHEL5 on builders? 00:05 < thl> | mmcgrath, afaics someone just needs to find the time to install rhel5 00:06 < thl> | mmcgrath, is that correct? 00:06 < mmcgrath> | OH, are you talking about running RHEL5 on the builders or having a RHEL5 repo for the mock to pull from? 00:06 < thl> | mmcgrath, sorry, 00:07 < nirik> | epel building will also be moving to koji this weekend with fedora I imagine? 00:07 < thl> | mmcgrath, I just meant: isntall a RHEL5 repo for mock 00:07 < thl> | nirik, I suppose so 00:07 < thimm> | Hm, I have a RHEL5 repo for mock ... 00:07 * | skvidal does too 00:07 < thimm> | I could rsync it somewhere 00:08 < skvidal> | thimm: that's where legal gets cranky 00:08 < mmcgrath> | thl: We actually have some RPM's there, the issue is whether or not we have RH's thumbs up to use them. 00:08 < thimm> | skvidal: but we have licenses for epel use, or? 00:08 < thl> | mmcgrath, I thought we had the "thumbs up" now? 00:08 < mmcgrath> | nope 00:08 < thl> | :-/ 00:09 < mmcgrath> | Thats the email I sent this morning. 00:09 < thimm> | mmcgrath: what is the problem? 00:09 < mmcgrath> | Yep. 00:09 < mmcgrath> | At first people thought we were going to be distributing RHEL5 through Fedora (which caused WAY more people to get involved then needed) 00:09 < mmcgrath> | When I finally educated legal about what mock does they were fine with it but worried that non RH employees would have access to the RPMs. 00:10 < mmcgrath> | I quelled that fear and now I'm literally waiting for the person with the initial concern to have one final discussion with Legal (AFAIK anyway) 00:10 < skvidal> | ooo 00:10 < skvidal> | yes 00:10 < mmcgrath> | thats where its at now. 00:10 < skvidal> | let's distribute rhel5 through fedora 00:10 < skvidal> | that'd be fun 00:10 < thl> | mmcgrath, is there any way we can speed solving this porblem up? 00:10 < thl> | mmcgrath, can quaid help? 00:10 < mmcgrath> | thl: use CentOS. 00:11 < mmcgrath> | This is why I sent that email earlier. 00:11 < mmcgrath> | Max is involved so I don't think quaid can help. 00:11 * | quaid nods 00:11 < mmcgrath> | This is one of those things where I've been sending 2 emails a week and people just don't think its much of a priority. 00:11 < thimm> | mmcgrath: Is this about getting licenses? 00:11 < mmcgrath> | Though, and I really mean this, I'm pretty hopeful that it will happen. 00:12 < mmcgrath> | thimm: what licenses? 00:12 < thimm> | For RHEL5 00:12 < mmcgrath> | We're waiting on a phone call between two people, one of which is in Phoenix and I'll be meeting with tonight and tomorow. 00:13 < mmcgrath> | thimm: I'm not sure. Because technically I don't think we need a license to posess the RHEL rpms. 00:13 < thl> | mmcgrath, okay, so I#d say let's hope and pray for now 00:13 < mmcgrath> | And even still we have 150 licenses to use for Fedora (though there's strict rules about 3rd party stuff) 00:13 < thl> | hopefully that stuff will sort out somehow over the next few days 00:13 < mmcgrath> | either way, the actual RHEL RPM's will never be public. 00:13 < mmcgrath> | thl: I'm hopeful... seriously. 00:13 < mmcgrath> | :) 00:14 * | thl will move on if that's okay for everybody 00:14 --- | thl has changed the topic to: EPEL Meeting -- Mass rebuild of EPEL5 00:14 < thl> | I was preparing a page in the wiki 00:14 < thl> | to actually try voting via the wiki 00:14 < thl> | and see how it works 00:15 < thl> | not ready yet http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting 00:15 * | mmcgrath is never afraid to try new things. 00:15 --> | ClausReheis has joined #fedora-meeting 00:15 --> | ClausReheis is Claus Reheis 00:15 < thl> | shall we discuss this thing here again 00:15 < thl> | we discussed it already once 00:15 < thl> | and I know, I'm the one that changes his opinion after the last meeting 00:15 < nirik> | the voting? or the mass rebuilding? 00:15 --> | XulChris (Christopher Stone) has joined #fedora-meeting 00:16 < thl> | nirik, that we want to do a mass rebuild is settled afaics 00:16 < thimm> | I still don't like forking specfiles 00:16 < thl> | the question is how: 00:16 < thl> | - delete and rebuild 00:16 < thl> | - add a .1 top the spec files and rebuild 00:16 < thimm> | - add a repotag and rebuild? 00:17 < thl> | repotag is a different point 00:17 < thimm> | No specfile forks with repotag 00:17 < thl> | but yes, it could solve this problem, too 00:17 < thl> | thimm, what's the PC's opinion on the repo tag these days? 00:17 < thimm> | Maybe we should decide on repotag, then this is no issue anymore? 00:17 < thimm> | I think the decision on using one is ours 00:18 < thimm> | The PC will tell us how 00:18 < thl> | thimm, I disagree 00:18 < thl> | thimm, wehn we want to enforce a repotag then spec files for EPEL have to look different then those for Fedora 00:18 < nirik> | so what problem does repo tags solve? easy for people to see who produced the rpm? 00:18 < thimm> | No 00:18 < thl> | thus it's IMHO something the packaging commitee has to decide 00:18 < thimm> | specfiles remain the same 00:18 < thl> | thimm, how? 00:19 < thimm> | The repotag is part of the %{?dist} 00:19 < thl> | but dist is optional 00:19 < nirik> | dist is not required 00:19 < thimm> | See my packages I moved over from ATrpms 00:19 < thimm> | nirik: If dist is not used, then that's another item, and perhaps needs no rebuild (firmware etc) 00:19 < thl> | thimm, as long as dist isn't enforced this does not work 00:20 < thl> | thimm, a repotag makes IMHO only sense if we use it everywhere 00:20 < thimm> | Where dist is not used the packages does "manual disttagging" 00:20 < nirik> | then non dist packages will have no repo tag either 00:20 < thimm> | No, no mandatory repotag or mandatory disttag 00:20 * | thl doesn't like what thimm outlines 00:20 < nirik> | then what does the repotag get us? 00:20 < thl> | nirik, exactly 00:20 < thimm> | The repotag discussion is all about extending %{dist}, nothing more 00:20 < thl> | thimm, I disagree 00:20 < thimm> | nirik: see epel-devel, there threads are endless 00:21 < thl> | a repotag only makes really sense IMHO if it is used everywhere 00:22 < mmcgrath> | thl: +1 00:22 < thimm> | Hm, it does look like all EPEL packages are using %{dist}, at least at the first glance 00:22 < thl> | thimm, doesn#t count IMHO 00:22 < thl> | there are many Fedora pacakges that don#t use it 00:23 < nirik> | epel-release doesn't IIRC... 00:23 * | thl takes a strong look at the "'#" key -- do what I mean 00:23 < thimm> | We don't want to suggest repotags for Fedora 00:24 < thl> | my opinion: a) enforce a %{repotag} everywhere (including fedora, even if the repotag is not extended) or b) no repotag for epel 00:24 < nirik> | well, do we want to do a wiki based vote on it then? or ? 00:25 < thl> | nirik, I'd say we should discuss this on the list first 00:25 < thimm> | thl: we can't decide on what Fedora doeas 00:25 < thl> | to make sure people vote about the same thing 00:25 < nirik> | it's been discussed a lot on the list already. ;( 00:25 < thimm> | indeed 00:25 < thl> | thimm, that's why this is IMHO something for the PC 00:25 < thimm> | ? 00:25 < thimm> | The PC is just a technical committee 00:25 < thimm> | Not political 00:26 < thl> | nirik, well, seems even here people have different expectation about the repotag and it's use 00:26 < thimm> | And the repotag stuff is 99% political 00:26 * | nirik is leaning toward no repotag... I don't think it gets us that much, and it won't be on everything, so it would be inconsistant. 00:26 < thl> | so we IMHO need to agree how to actually do it before we can vote 00:26 < entr0py> | nirik: +1, thl +1 00:26 < thimm> | nirik: It will get us war or peace, I prefer peace 00:26 * | thl is currently leaning toward no repotag, too 00:26 < nirik> | thimm: who will it get us war with? and why? 00:27 < thimm> | Centos, Dag, rpmforge 00:27 < nirik> | perhaps we should look at it from the political angle... 00:27 < thl> | thimm, Centos? 00:27 < thl> | thimm, never heard of that; pointers? 00:27 < mmcgrath> | thimm: Our concern with the repo tag is that we don't use dist tags everywhere. Maybe we should shift the focus to no repo tag or manditory dist tags. 00:27 < thimm> | No, no mandatory disttags 00:27 < thimm> | That doesn't exist in Fedora 00:27 < thl> | then no repotags 00:27 < thimm> | And we should not enforce it suddenly out of EPEL 00:28 < mmcgrath> | Thats the point, why don't we try to make them manditory (take it to packaging or Fesco) 00:28 < mmcgrath> | if its that big of a concern. 00:28 < nirik> | why does centos/dag/rf care about us using disttags? I guess I should go back and look at the thread on the mailing list... I can't recall. 00:28 < thimm> | Personally I'm very much in favour of mandatory disttags 00:28 < thimm> | Just not out of this context 00:28 < thimm> | E.g. mandatory disttags should stand per se and not be intorduced for repotags 00:29 < thimm> | But you'll get my vote on mandatory disttags any day of the week. 00:29 < thl> | not the mass rebuild with chaning disttags discussion again 00:29 * | mmcgrath feels this discussion is becoming more academic then anything. 00:29 < thimm> | Then let's get pragmatic 00:29 < nirik> | dist doesn't make sense in some cases where you don't want to have to rebuild for a new release, but ok... 00:29 < thimm> | Let's just vote on repotag or not 00:30 < thimm> | nirik: only whereit does make snes, of course 00:30 < che> | how about having a single sheet with pro and con arguments written down 00:30 < thimm> | Not firmwar for example 00:30 < che> | this would make the decision transparent 00:30 < thimm> | che: care to setup a page? 00:30 < thl> | che, you know, world isn#t black and white ;-) 00:31 < che> | thimm, this is how i always did make decisions in a professional way when i was still working for a process consulting company 00:31 < thl> | my vote currently is: repotag only if we have them in all packages 00:31 < che> | thl, i live in the perfect world... forgot that? 00:31 < nirik> | I am thinking no disttags based on tech arguments, but on the political side I would really like rf/dag to be happy and join us. 00:31 < thl> | that's not easily possible right now, so my vote is no repotags (for now) 00:32 * | thl wonders what drugs che takes ;-) 00:32 < quaid> | ... and where to get some 00:33 < che> | hah you wish! 00:33 < thl> | deadlock? 00:33 < thimm> | thl: will you prepare the votes for repotag and rebuilds in the wiki? 00:33 < nirik> | part of the problem is that the thread between dag and mschwent really went academic... didn't help to clarify anything for me. 00:33 < thl> | for rebuilds yes, as a example 00:33 < thl> | for repotags: no 00:33 --> | lutter (David Lutterkort) has joined #fedora-meeting 00:33 < che> | thl, well how else could one reproduce how decisions were made? 00:34 < thimm> | thl: why not? 00:34 < che> | thl, how else does one see if there are new arguments that can fire up another "decision making" process 00:34 < nirik> | perhaps che would be willing to make a repotags page for voting? 00:34 < thl> | thimm, why don't you do it? 00:34 < thl> | thimm, you seem to be interested in it 00:34 < che> | nirik, if you are going to work on other things i have on my todo list sure. 00:34 < thl> | but such a controversial issue IMHO needs to be discused again to make sure people vote about the same thing 00:34 < thimm> | Ok, finish up your vote proposal and I'l copy and paste ... ... ... 00:35 < thl> | thimm, no 00:35 < thl> | you IMHO need to go to the list again 00:35 < nirik> | well, it could be 'repotags: yes or no' If 'no' then stop. If yes then 'how needs more discussion' 00:35 < thimm> | thl: Did chec give you the drugs already? 00:35 < thimm> | Why can't I write down a vote propoasl? 00:35 < nirik> | che: :) Wish I had time for the things on my own todo list. ;) 00:36 < thimm> | About somethign we discussed weeks ago on the list 00:36 < thimm> | in two endless threads 00:36 < che> | nirik, well i feel with you :) 00:36 < thl> | thimm, nobody stops you 00:36 < che> | nirik, for me theres a difference between rational decision and an election 00:36 < thl> | but I'll oppose a vote where I got the impression that people don't know the details to actually come to a decisions 00:36 < thl> | that's importatn in my eyes 00:37 < nirik> | how about someone who wants dist tags writes a short (small paragraph) PRO: section for the wiki vote, and someone against writes a CON: (like the do for real elections here) 00:37 < thl> | details in this case: %{?dist} or %{?repotag} 00:37 < thimm> | thl: That's a bad way to go 00:37 < thl> | use it everyhwere or now 00:37 < thimm> | That way everyone not liking a vote can "oppose" to it 00:37 < thl> | thimm, it worked fine for FESCo afaics, as it works like this 00:38 < che> | nirik, i am just sad that i cant stress this topic without going offtopic :) 00:38 < thimm> | Anyway, thl, anyone around here can throw in something for voting, right? 00:38 < thimm> | Let's move on 00:38 < nirik> | thimm: I would think so. If people fear they don't have the info they need they can say no or abstain. 00:39 < thimm> | nirik++ 00:39 < thl> | before we move on one thing 00:39 < thl> | nirik, thimm, others: what do you prefer: delete and rebuild or add a .1 and rebuild? 00:39 < nirik> | delete and rebuild is what I would prefer. 00:39 < thimm> | the former 00:39 < thl> | nirik, well, agreed in parts, but it might look bad to the outside 00:40 < nirik> | anyone using our not announced rh5 rpms that were compiled against beta should know better... 00:40 < thl> | nirik, you know that some people out there will have different packages under the same name? 00:40 < thl> | the debuginfo pacakges won#t match 00:40 < nirik> | what do you mean? same name? 00:40 < thl> | and in bug reports you don#t know which of the pacakges people are using 00:40 < thl> | nirik, say I isntall a package from EPEL5 today 00:40 < thl> | nirik, we delete and rebuild 00:40 < thimm> | but you assume actual users of the pre-repo 00:41 < thl> | nirik, user has a problem in two weeks from now 00:41 < thl> | nirik, debuginfo package does not match 00:41 < thl> | nirik, bug refers to pacakge foo-1.1 00:41 < nirik> | sure. So in the bug report: please remove and instlal the new one. 00:41 < thl> | and people don#t know if that the old or the new one 00:41 < thimm> | thl: how die the user get the package in the first place? 00:41 < thl> | thimm, repo is public since some weeks now 00:41 < nirik> | I don't think it will be that much of a problem. 00:41 < thimm> | s/die/did/ 00:42 < thimm> | Yes, public means not that one randomly installs stuff, right=? 00:42 < thimm> | It isn't installed 00:42 < thimm> | s/installed/announced/ 00:42 < thl> | thimm, well, some people might have installed stuff from it already 00:42 < thimm> | Some peopl may have installed from SLES, too 00:42 < mmcgrath> | Some people have installed stuff, and announced stuff on their own already. 00:43 < thl> | adding a .1 isn't such a big deal IMHO 00:43 < thimm> | mmcgrath: which ones? 00:43 < thl> | well, let's move on 00:43 * | thl waits 00:43 < mmcgrath> | thimm: just random people on the net. I don't think anything major. 00:45 * | thl will move on 00:45 --- | thl has changed the topic to: EPEL Meeting 00:45 < thl> | so, what else? 00:45 < entr0py> | any comments on my request for brp-python-bytecompile? 00:45 < thl> | quaid, there is "Investigate single RHEL subscription for EPEL maintainers" on the schedule 00:46 < thimm> | entr0py: brp-python-bytecompile is currently under discussion for other issues, too 00:46 < thimm> | So an improved version may appear in *-rpm-config 00:46 < thimm> | Which would fix your issue as well 00:46 < thl> | thimm, will the PC take care of the bytecompile stuff? 00:47 < entr0py> | thimm: excellent 00:47 < mmcgrath> | thl: I don't think that would happen any time soon. 00:47 < thimm> | About thy pyc/pyo stuff 00:47 < mmcgrath> | not to discourage but it would be a long time before we could actually have something. 00:47 < thimm> | But at the end it will be a suggestion for the redhat-rpm-config maintainer 00:47 < thl> | mmcgrath, the idea wasn't mine; I actually agree with you 00:48 < thimm> | mmcgrath: Yes, this will not be done soon 00:48 < nirik> | so voting on the wiki would take place until when? next meeting? 00:48 < thl> | nirik, I'll annouce it on the list 00:48 < nirik> | ok. 00:48 < thl> | anything else? 00:49 * | nirik looks at the schedule page 00:50 < mmcgrath> | OH, 00:50 < mmcgrath> | I've got one thing. If its been discussed sorry I missed it. 00:50 < mmcgrath> | So RHEL5's $RELEASEVER translates to 5Server instead of 5 00:50 < mmcgrath> | Should we have the mirrors list script 'correct' this? 00:51 < thimm> | You mean making this a "5"? +1 00:51 < thimm> | cobbler also bails out on 5Server 00:51 < thl> | mmcgrath, could we have a symlink maybe that fixes this? 00:51 < thimm> | But, it's an easyfix 00:51 < mmcgrath> | I'm not sure how well the mirrors handle symlinks. 00:52 < mmcgrath> | I'd think the mirrors can handle symlinks fine but I don't want to assume that. 00:52 < thl> | mmcgrath, so we should hardcode it in the repo files? 00:52 < mmcgrath> | We can, thats what I've done on my boxes. 00:53 < thl> | hardcoding seems fine to me 00:53 < thimm> | +1 00:53 --> | sharkcz_ (Dan Horak) has joined #fedora-meeting 00:53 < mmcgrath> | k, I won't worry about it then :) 00:54 < thl> | so I'll tell stahma to update the repo files to use a hardcoded 5 instead of $RELEASEVER 00:54 < thl> | that okay for everybody? 00:54 * | thl waits a bit if someone yells 00:54 < nirik> | thl: +1 00:55 < thl> | seems nobody yelled 00:55 < thl> | anything else? 00:55 * | thl will close the meeting in 60 00:55 < mmcgrath> | not here 00:55 < thl> | btw, any volunteers for writing the summary? 00:56 * | thl will close the meeting in 30 00:56 * | thl will close the meeting in 10 00:56 < thl> | -- MARK -- Meeting end }}} From pertusus at free.fr Thu Apr 5 15:51:10 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 5 Apr 2007 17:51:10 +0200 Subject: Summary from yesterdays EPEL SIG meeting In-Reply-To: <46151838.30803@leemhuis.info> References: <46151838.30803@leemhuis.info> Message-ID: <20070405155110.GJ2899@free.fr> On Thu, Apr 05, 2007 at 05:39:36PM +0200, Thorsten Leemhuis wrote: > > * RHEL5's $RELEASEVER translates to 5Server instead of 5 -> the plan > is to hardcode 5 in the repo file to avoid problems I can read the log to understand that, but if it isn't too long could this be expanded a bit? -- Pat From fedora at leemhuis.info Thu Apr 5 16:06:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 Apr 2007 18:06:52 +0200 Subject: Summary from yesterdays EPEL SIG meeting In-Reply-To: <20070405155110.GJ2899@free.fr> References: <46151838.30803@leemhuis.info> <20070405155110.GJ2899@free.fr> Message-ID: <46151E9C.2090804@leemhuis.info> Patrice Dumas schrieb: > On Thu, Apr 05, 2007 at 05:39:36PM +0200, Thorsten Leemhuis wrote: >> * RHEL5's $RELEASEVER translates to 5Server instead of 5 -> the plan >> is to hardcode 5 in the repo file to avoid problems > I can read the log to understand that, but if it isn't too long could > this be expanded a bit? Not sure what you mean. The thing is this: http://download.fedora.redhat.com/pub/epel/$releasever/ gets translated to http://download.fedora.redhat.com/pub/epel/5server/ by yum. That dir doesn't exists, so we simply use "5" instead of "$releasever" in yum pointers. CU thl From mastahnke at gmail.com Thu Apr 5 16:08:04 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 5 Apr 2007 11:08:04 -0500 Subject: Summary from yesterdays EPEL SIG meeting In-Reply-To: <20070405155110.GJ2899@free.fr> References: <46151838.30803@leemhuis.info> <20070405155110.GJ2899@free.fr> Message-ID: <7874d9dd0704050908h5ab140e5teb09f09e5ea0bde1@mail.gmail.com> This is fixed in the epel-release waitning to be pushed to EPEL. On 4/5/07, Patrice Dumas wrote: > On Thu, Apr 05, 2007 at 05:39:36PM +0200, Thorsten Leemhuis wrote: > > > > * RHEL5's $RELEASEVER translates to 5Server instead of 5 -> the plan > > is to hardcode 5 in the repo file to avoid problems > > I can read the log to understand that, but if it isn't too long could > this be expanded a bit? > > -- > Pat > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From fedora at leemhuis.info Thu Apr 5 16:09:17 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 Apr 2007 18:09:17 +0200 Subject: Summary from yesterdays EPEL SIG meeting In-Reply-To: <46151E9C.2090804@leemhuis.info> References: <46151838.30803@leemhuis.info> <20070405155110.GJ2899@free.fr> <46151E9C.2090804@leemhuis.info> Message-ID: <46151F2D.9010400@leemhuis.info> Thorsten Leemhuis schrieb: > Patrice Dumas schrieb: >> On Thu, Apr 05, 2007 at 05:39:36PM +0200, Thorsten Leemhuis wrote: >>> * RHEL5's $RELEASEVER translates to 5Server instead of 5 -> the plan >>> is to hardcode 5 in the repo file to avoid problems >> I can read the log to understand that, but if it isn't too long could >> this be expanded a bit? > > Not sure what you mean. The thing is this: > > http://download.fedora.redhat.com/pub/epel/$releasever/ > gets translated to > http://download.fedora.redhat.com/pub/epel/5server/ > by yum. That dir doesn't exists, so we simply use "5" instead of > "$releasever" in yum pointers. > stahnma did this already, the new package is just waiting for the push. CU thl From pertusus at free.fr Thu Apr 5 16:07:22 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 5 Apr 2007 18:07:22 +0200 Subject: Summary from yesterdays EPEL SIG meeting In-Reply-To: <46151E9C.2090804@leemhuis.info> References: <46151838.30803@leemhuis.info> <20070405155110.GJ2899@free.fr> <46151E9C.2090804@leemhuis.info> Message-ID: <20070405160722.GM2899@free.fr> On Thu, Apr 05, 2007 at 06:06:52PM +0200, Thorsten Leemhuis wrote: > Patrice Dumas schrieb: > > On Thu, Apr 05, 2007 at 05:39:36PM +0200, Thorsten Leemhuis wrote: > >> * RHEL5's $RELEASEVER translates to 5Server instead of 5 -> the plan > >> is to hardcode 5 in the repo file to avoid problems > > I can read the log to understand that, but if it isn't too long could > > this be expanded a bit? > > Not sure what you mean. The thing is this: > > http://download.fedora.redhat.com/pub/epel/$releasever/ > gets translated to > http://download.fedora.redhat.com/pub/epel/5server/ > by yum. That dir doesn't exists, so we simply use "5" instead of > "$releasever" in yum pointers. Thanks for the explanation. -- Pat From buildsys at fedoraproject.org Thu Apr 5 16:24:17 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 5 Apr 2007 12:24:17 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-04-05 Message-ID: <20070405162417.935CB152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 5 NEW conmux-0.0-5.493svn.el5 NEW epel-release-5-2 NEW facter-1.3.7-1.el5 NEW mod_auth_shadow-2.2-4.el5 NEW puppet-0.22.3-1.el5 Packages built and released for Fedora EPEL 4: 3 epel-release-4-6 NEW mod_auth_shadow-2.2-3.el4 uw-imap-2006g-2.el4.1 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From Michael_E_Brown at Dell.com Thu Apr 5 16:56:12 2007 From: Michael_E_Brown at Dell.com (Michael E Brown) Date: Thu, 5 Apr 2007 11:56:12 -0500 Subject: Summary from yesterdays EPEL SIG meeting In-Reply-To: <46151E9C.2090804@leemhuis.info> References: <46151838.30803@leemhuis.info> <20070405155110.GJ2899@free.fr> <46151E9C.2090804@leemhuis.info> Message-ID: <20070405165611.GA20412@humbolt.us.dell.com> On Thu, Apr 05, 2007 at 06:06:52PM +0200, Thorsten Leemhuis wrote: > Patrice Dumas schrieb: > > On Thu, Apr 05, 2007 at 05:39:36PM +0200, Thorsten Leemhuis wrote: > >> * RHEL5's $RELEASEVER translates to 5Server instead of 5 -> the plan > >> is to hardcode 5 in the repo file to avoid problems > > I can read the log to understand that, but if it isn't too long could > > this be expanded a bit? > > Not sure what you mean. The thing is this: > > http://download.fedora.redhat.com/pub/epel/$releasever/ > gets translated to > http://download.fedora.redhat.com/pub/epel/5server/ > by yum. That dir doesn't exists, so we simply use "5" instead of > "$releasever" in yum pointers. This doesnt sound like a good idea. You lose the automatic, "I upgrade from RHEL5 to RHEL6 and automatically get EPEL 6 stuff". I would suggest simply making a symlink: "ln -s 5 5Server" That is what I did for the unofficial Dell yum repos. -- Michael From Axel.Thimm at ATrpms.net Thu Apr 5 17:56:36 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 5 Apr 2007 19:56:36 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <46150C07.5050404@leemhuis.info> References: <20070405065946.GG15113@neu.nirvana> <4614A3BD.8000007@leemhuis.info> <20070405075013.GJ15113@neu.nirvana> <4614B111.8000703@leemhuis.info> <20070405090449.GK15113@neu.nirvana> <4614C793.7030806@leemhuis.info> <20070405100240.GL15113@neu.nirvana> <4614CFC7.9090108@leemhuis.info> <20070405135151.GA4531@neu.nirvana> <46150C07.5050404@leemhuis.info> Message-ID: <20070405175636.GD4531@neu.nirvana> On Thu, Apr 05, 2007 at 04:47:35PM +0200, Thorsten Leemhuis wrote: > > No, don't put the blame on me (or the FPC or the future), it's your > > vote. > > You started it and you have to support it if you want people to vote. No, I didn't start it, it was brought up here by (another) 3rd party repo manager. I just recorded the need for voting on it and did my part of voting. -- 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 bjohnson-sender-11eeb1 at symetrix.com Thu Apr 5 18:25:29 2007 From: bjohnson-sender-11eeb1 at symetrix.com (Bernard Johnson) Date: Thu, 05 Apr 2007 12:25:29 -0600 Subject: Voting: repotag for EPEL In-Reply-To: <20070405175636.GD4531@neu.nirvana> References: <20070405065946.GG15113@neu.nirvana> <4614A3BD.8000007@leemhuis.info> <20070405075013.GJ15113@neu.nirvana> <4614B111.8000703@leemhuis.info> <20070405090449.GK15113@neu.nirvana> <4614C793.7030806@leemhuis.info> <20070405100240.GL15113@neu.nirvana> <4614CFC7.9090108@leemhuis.info> <20070405135151.GA4531@neu.nirvana> <46150C07.5050404@leemhuis.info> <20070405175636.GD4531@neu.nirvana> Message-ID: <46153F19.1010209@symetrix.com> Axel Thimm wrote: > On Thu, Apr 05, 2007 at 04:47:35PM +0200, Thorsten Leemhuis wrote: > >>> No, don't put the blame on me (or the FPC or the future), it's your >>> vote. >>> >> You started it and you have to support it if you want people to vote. >> > > No, I didn't start it, it was brought up here by (another) 3rd party > repo manager. I just recorded the need for voting on it and did my > part of voting. > I don't think thl is being unreasonable here. *Someone* has to support it. If you consider it to be a big enough issue to warrant a vote, then you should support it. There is not nearly enough bandwidth in the group to go out and "look" for issues. If a 3rd party repo manager has a strong opinion on repotag, then he should be here supporting his views. In lieu of that, if you are wanting a vote, then it should be you. From Axel.Thimm at ATrpms.net Thu Apr 5 18:39:54 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 5 Apr 2007 20:39:54 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <46153F19.1010209@symetrix.com> References: <20070405075013.GJ15113@neu.nirvana> <4614B111.8000703@leemhuis.info> <20070405090449.GK15113@neu.nirvana> <4614C793.7030806@leemhuis.info> <20070405100240.GL15113@neu.nirvana> <4614CFC7.9090108@leemhuis.info> <20070405135151.GA4531@neu.nirvana> <46150C07.5050404@leemhuis.info> <20070405175636.GD4531@neu.nirvana> <46153F19.1010209@symetrix.com> Message-ID: <20070405183954.GH4531@neu.nirvana> On Thu, Apr 05, 2007 at 12:25:29PM -0600, Bernard Johnson wrote: > Axel Thimm wrote: > > On Thu, Apr 05, 2007 at 04:47:35PM +0200, Thorsten Leemhuis wrote: > > > >>> No, don't put the blame on me (or the FPC or the future), it's your > >>> vote. > >>> > >> You started it and you have to support it if you want people to vote. > >> > > > > No, I didn't start it, it was brought up here by (another) 3rd party > > repo manager. I just recorded the need for voting on it and did my > > part of voting. > > > > I don't think thl is being unreasonable here. *Someone* has to support > it. If you consider it to be a big enough issue to warrant a vote, then > you should support it. > > There is not nearly enough bandwidth in the group to go out and "look" > for issues. If a 3rd party repo manager has a strong opinion on > repotag, then he should be here supporting his views. That already happened a month ago and generated lots of discussion on this list: 22% of this list's traffic ever is about that! And just for fun with stats: 21% of the traffic was about banning fedora-usermgr. It is really beaten to death and beyond. Please check the archives if you weren't subscribed back then. > In lieu of that, if you are wanting a vote, then it should be you. If I were really a proxy introducing a 3rd party's vote proposal that the 3rd party couldn't/wouldn't represent itself I would agree, but the situation is that there *was* already a loadful of discussion initiated by that person and discussed with that person, only that we didn't have someone to do the actual decision. Now that we finally have a decisive EPEL it needs to finish the open issues, not rehash them for the umpteenth 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 bjohnson-sender-11eeb1 at symetrix.com Thu Apr 5 18:52:03 2007 From: bjohnson-sender-11eeb1 at symetrix.com (Bernard Johnson) Date: Thu, 05 Apr 2007 12:52:03 -0600 Subject: Voting: repotag for EPEL In-Reply-To: <20070405183954.GH4531@neu.nirvana> References: <20070405075013.GJ15113@neu.nirvana> <4614B111.8000703@leemhuis.info> <20070405090449.GK15113@neu.nirvana> <4614C793.7030806@leemhuis.info> <20070405100240.GL15113@neu.nirvana> <4614CFC7.9090108@leemhuis.info> <20070405135151.GA4531@neu.nirvana> <46150C07.5050404@leemhuis.info> <20070405175636.GD4531@neu.nirvana> <46153F19.1010209@symetrix.com> <20070405183954.GH4531@neu.nirvana> Message-ID: <46154553.9080907@symetrix.com> Axel Thimm wrote: > That already happened a month ago and generated lots of discussion on > this list: 22% of this list's traffic ever is about that! And just for > fun with stats: 21% of the traffic was about banning > fedora-usermgr. It is really beaten to death and beyond. > > Please check the archives if you weren't subscribed back then. > (my comments on this apply to repotag as well) I read every single message. Not a fun read. No one was listening to anyone else. You are right, we do not need to rehash that. But what we do need is a clear concise summary of the pros and cons (both fedora-usermgmt and repotag). This should be 2-3 paragraphs written by someone with a strong opinion on either side. There is almost nothing in those long threads that can't be boiled down to a couple of paragraphs for voting purposes. And if you don't feel strongly *for*, and no one is willing to step up to that small task, I don't even see how this is vote worthy. From Axel.Thimm at ATrpms.net Thu Apr 5 19:00:49 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 5 Apr 2007 21:00:49 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <46154553.9080907@symetrix.com> References: <20070405090449.GK15113@neu.nirvana> <4614C793.7030806@leemhuis.info> <20070405100240.GL15113@neu.nirvana> <4614CFC7.9090108@leemhuis.info> <20070405135151.GA4531@neu.nirvana> <46150C07.5050404@leemhuis.info> <20070405175636.GD4531@neu.nirvana> <46153F19.1010209@symetrix.com> <20070405183954.GH4531@neu.nirvana> <46154553.9080907@symetrix.com> Message-ID: <20070405190049.GJ4531@neu.nirvana> On Thu, Apr 05, 2007 at 12:52:03PM -0600, Bernard Johnson wrote: > Axel Thimm wrote: > > That already happened a month ago and generated lots of discussion on > > this list: 22% of this list's traffic ever is about that! And just for > > fun with stats: 21% of the traffic was about banning > > fedora-usermgr. It is really beaten to death and beyond. > > > > Please check the archives if you weren't subscribed back then. > > > (my comments on this apply to repotag as well) > > I read every single message. Not a fun read. No one was listening to > anyone else. You are right, we do not need to rehash that. > > But what we do need is a clear concise summary of the pros and cons > (both fedora-usermgmt and repotag). This should be 2-3 paragraphs > written by someone with a strong opinion on either side. There is > almost nothing in those long threads that can't be boiled down to a > couple of paragraphs for voting purposes. > > And if you don't feel strongly *for*, and no one is willing to step up > to that small task, I don't even see how this is vote worthy. That's a wrong conclusion, people just get burned out and "don't want to be that guy" (grep the archives to understand the latter quote). Especially in a topic like fedora-usermgmt that spanned into three different lists by now. Anyway the need to vote on that is undisputed, alone the magnitude of list space these topics consume require an official EPEL stand-up. And if you feel like there should be more information in the wiki or elsewhere, since you read all mails, maybe you could volunteer to do "that small task" and make Thorsten happy. FWIW "I don't want to be that guy". -- 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 Thu Apr 5 19:06:32 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 Apr 2007 21:06:32 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <46153F19.1010209@symetrix.com> References: <20070405065946.GG15113@neu.nirvana> <4614A3BD.8000007@leemhuis.info> <20070405075013.GJ15113@neu.nirvana> <4614B111.8000703@leemhuis.info> <20070405090449.GK15113@neu.nirvana> <4614C793.7030806@leemhuis.info> <20070405100240.GL15113@neu.nirvana> <4614CFC7.9090108@leemhuis.info> <20070405135151.GA4531@neu.nirvana> <46150C07.5050404@leemhuis.info> <20070405175636.GD4531@neu.nirvana> <46153F19.1010209@symetrix.com> Message-ID: <461548B8.40307@leemhuis.info> Bernard Johnson schrieb: > Axel Thimm wrote: >> On Thu, Apr 05, 2007 at 04:47:35PM +0200, Thorsten Leemhuis wrote: >> >>>> No, don't put the blame on me (or the FPC or the future), it's your >>>> vote. >>> You started it and you have to support it if you want people to vote. >> No, I didn't start it, it was brought up here by (another) 3rd party >> repo manager. I just recorded the need for voting on it and did my >> part of voting. > I don't think thl is being unreasonable here. *Someone* has to support > it. If you consider it to be a big enough issue to warrant a vote, then > you should support it. [...] +1 -- further: if no one is supporting to give proper overview over the rpos and cons for a topic before a vote then it's IMHO likely that nobody later will work out the details how to actually realize something that was voted upon. CU thl From fedora at leemhuis.info Thu Apr 5 19:25:50 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 Apr 2007 21:25:50 +0200 Subject: moving on? Message-ID: <46154D3E.7090706@leemhuis.info> Hi, I'd like to propose: - let's stop the discussions about the votings on fedora-usermgmt and repotag as well as the votings itself; instead discuss the issues in the EPEL SIG meeting next week. Both issues are lingering around for weeks already so giving is some days more shouldn't hurt much (the voting ends just 17 hours before the next meeting in any case). Continue with the "Rebuild of EPEL5" voting to see if this wiki votings are working. - in the next week meeting further discuss how we actually create votings; I get the impression we need more coordination there to avoid endless discussions like the one from today. E.g. some rules like "at least three Steering committee members are needed to start a wiki voting" or "only the Steering committee chair or his deputy officially can start votings via the wiki" (if we want such positions). Well, something like that, not yet sure how to do it exactly. Does that sound sane? CU thl From bjohnson-sender-11eeb1 at symetrix.com Thu Apr 5 19:49:26 2007 From: bjohnson-sender-11eeb1 at symetrix.com (Bernard Johnson) Date: Thu, 05 Apr 2007 13:49:26 -0600 Subject: Voting: repotag for EPEL In-Reply-To: <20070405190049.GJ4531@neu.nirvana> References: <20070405090449.GK15113@neu.nirvana> <4614C793.7030806@leemhuis.info> <20070405100240.GL15113@neu.nirvana> <4614CFC7.9090108@leemhuis.info> <20070405135151.GA4531@neu.nirvana> <46150C07.5050404@leemhuis.info> <20070405175636.GD4531@neu.nirvana> <46153F19.1010209@symetrix.com> <20070405183954.GH4531@neu.nirvana> <46154553.9080907@symetrix.com> <20070405190049.GJ4531@neu.nirvana> Message-ID: <461552C6.3050605@symetrix.com> Axel Thimm wrote: > Anyway the need to vote on that is undisputed, alone the magnitude of > list space these topics consume require an official EPEL stand-up. And > if you feel like there should be more information in the wiki or > elsewhere, since you read all mails, maybe you could volunteer to do > "that small task" and make Thorsten happy. > > FWIW "I don't want to be that guy". > I'm not trying to push you into being something that you don't want. You just seem to be the biggest proponent if the idea, today. If it's put up for a vote and not well represented, it will be a disservice to those who do want it to happen. And if needed, I can do "that small task", however, it will be as an opponent to repotag, so we would still need a proponent. Frankly, I don't see a big benefit, so I'm not the best person to write it :) From orion at cora.nwra.com Thu Apr 5 20:35:32 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 05 Apr 2007 14:35:32 -0600 Subject: Summary from yesterdays EPEL SIG meeting In-Reply-To: <20070405165611.GA20412@humbolt.us.dell.com> References: <46151838.30803@leemhuis.info> <20070405155110.GJ2899@free.fr> <46151E9C.2090804@leemhuis.info> <20070405165611.GA20412@humbolt.us.dell.com> Message-ID: <46155D94.3080308@cora.nwra.com> Michael E Brown wrote: > On Thu, Apr 05, 2007 at 06:06:52PM +0200, Thorsten Leemhuis wrote: >> Not sure what you mean. The thing is this: >> >> http://download.fedora.redhat.com/pub/epel/$releasever/ >> gets translated to >> http://download.fedora.redhat.com/pub/epel/5server/ >> by yum. That dir doesn't exists, so we simply use "5" instead of >> "$releasever" in yum pointers. > > This doesnt sound like a good idea. You lose the automatic, "I upgrade from RHEL5 to RHEL6 and automatically get EPEL 6 stuff". > > I would suggest simply making a symlink: "ln -s 5 5Server" > > That is what I did for the unofficial Dell yum repos. Don't forget about "5Client" too. Not sure what else... -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From Michael_E_Brown at dell.com Thu Apr 5 21:19:45 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 5 Apr 2007 16:19:45 -0500 Subject: Summary from yesterdays EPEL SIG meeting In-Reply-To: <46155D94.3080308@cora.nwra.com> References: <46151838.30803@leemhuis.info> <20070405155110.GJ2899@free.fr> <46151E9C.2090804@leemhuis.info> <20070405165611.GA20412@humbolt.us.dell.com> <46155D94.3080308@cora.nwra.com> Message-ID: <20070405211945.GG20412@humbolt.us.dell.com> On Thu, Apr 05, 2007 at 02:35:32PM -0600, Orion Poplawski wrote: > Michael E Brown wrote: > >On Thu, Apr 05, 2007 at 06:06:52PM +0200, Thorsten Leemhuis wrote: > >>Not sure what you mean. The thing is this: > >> > >>http://download.fedora.redhat.com/pub/epel/$releasever/ > >>gets translated to > >>http://download.fedora.redhat.com/pub/epel/5server/ > >>by yum. That dir doesn't exists, so we simply use "5" instead of > >>"$releasever" in yum pointers. > > > >This doesnt sound like a good idea. You lose the automatic, "I upgrade > >from RHEL5 to RHEL6 and automatically get EPEL 6 stuff". > > > >I would suggest simply making a symlink: "ln -s 5 5Server" > > > >That is what I did for the unofficial Dell yum repos. > > Don't forget about "5Client" too. Not sure what else... In any case, the number of symlinks is finite. I have 4AS, 4ES, 4WS, 4Desktop symlinks in my repo for RHEL4, and I dont consider that to be excessive, considering the benefits of using $releasever. -- Michael (Who had several RHEL4 upgraded machines pointing at RHEl3 repo as well as many FC6 boxes pointing at FC4/5 repos until he discovered $releasever for his repository config files.) From Axel.Thimm at ATrpms.net Thu Apr 5 23:07:46 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 6 Apr 2007 01:07:46 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <461552C6.3050605@symetrix.com> References: <20070405100240.GL15113@neu.nirvana> <4614CFC7.9090108@leemhuis.info> <20070405135151.GA4531@neu.nirvana> <46150C07.5050404@leemhuis.info> <20070405175636.GD4531@neu.nirvana> <46153F19.1010209@symetrix.com> <20070405183954.GH4531@neu.nirvana> <46154553.9080907@symetrix.com> <20070405190049.GJ4531@neu.nirvana> <461552C6.3050605@symetrix.com> Message-ID: <20070405230746.GO16463@neu.nirvana> On Thu, Apr 05, 2007 at 01:49:26PM -0600, Bernard Johnson wrote: > Axel Thimm wrote: > > Anyway the need to vote on that is undisputed, alone the magnitude of > > list space these topics consume require an official EPEL stand-up. And > > if you feel like there should be more information in the wiki or > > elsewhere, since you read all mails, maybe you could volunteer to do > > "that small task" and make Thorsten happy. > > > > FWIW "I don't want to be that guy". > > > > I'm not trying to push you into being something that you don't want. > You just seem to be the biggest proponent if the idea, today. > > If it's put up for a vote and not well represented, it will be a > disservice to those who do want it to happen. > > And if needed, I can do "that small task", however, it will be as an > opponent to repotag, so we would still need a proponent. Frankly, I > don't see a big benefit, so I'm not the best person to write it :) Gosh, contrary to my vanishing sanity I succumb, and I fed the votings with some notes, I even did some research with my FPC hat on on what the best implementation would be and added that as a note, too. Which since it was just *my* FPC hat is just a suggestion about how the FPC may attack this, it is neither part of the EPEL voting, nor a guarantee that the FPC will do so. There may be even smarter and better implementations. Happy Easter. -- 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 Fri Apr 6 09:25:46 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 06 Apr 2007 11:25:46 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <20070405230746.GO16463@neu.nirvana> References: <20070405100240.GL15113@neu.nirvana> <4614CFC7.9090108@leemhuis.info> <20070405135151.GA4531@neu.nirvana> <46150C07.5050404@leemhuis.info> <20070405175636.GD4531@neu.nirvana> <46153F19.1010209@symetrix.com> <20070405183954.GH4531@neu.nirvana> <46154553.9080907@symetrix.com> <20070405190049.GJ4531@neu.nirvana> <461552C6.3050605@symetrix.com> <20070405230746.GO16463@neu.nirvana> Message-ID: <4616121A.6080306@leemhuis.info> Axel Thimm schrieb: > On Thu, Apr 05, 2007 at 01:49:26PM -0600, Bernard Johnson wrote: >> Axel Thimm wrote: > > Gosh, contrary to my vanishing sanity I succumb, and I fed the votings > with some notes, I even did some research with my FPC hat on on what > the best implementation would be and added that as a note, too. Which > since it was just *my* FPC hat is just a suggestion about how the FPC > may attack this, it is neither part of the EPEL voting, nor a > guarantee that the FPC will do so. There may be even smarter and > better implementations. The critique I issued multiple times somewhere else in this thread still is the same: I don't want to give a binding vote on a "Should EPEL carry a repotag? If yes, the technical details will be delegated to the Packaging Committee." question at this point of time. I want to see what burden a repotag might create for packagers before I'll feel safe to bless repotags. So I would vote "no" to currently; but I would vote "yes" to a question "Should we further investigate the use of a repotag and the technical details how to realize them", as long as someone is willing to do the investigating work. CU thl From Axel.Thimm at ATrpms.net Fri Apr 6 09:38:25 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 6 Apr 2007 11:38:25 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <4616121A.6080306@leemhuis.info> References: <20070405135151.GA4531@neu.nirvana> <46150C07.5050404@leemhuis.info> <20070405175636.GD4531@neu.nirvana> <46153F19.1010209@symetrix.com> <20070405183954.GH4531@neu.nirvana> <46154553.9080907@symetrix.com> <20070405190049.GJ4531@neu.nirvana> <461552C6.3050605@symetrix.com> <20070405230746.GO16463@neu.nirvana> <4616121A.6080306@leemhuis.info> Message-ID: <20070406093825.GB31685@neu.nirvana> On Fri, Apr 06, 2007 at 11:25:46AM +0200, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > > On Thu, Apr 05, 2007 at 01:49:26PM -0600, Bernard Johnson wrote: > >> Axel Thimm wrote: > > > > Gosh, contrary to my vanishing sanity I succumb, and I fed the votings > > with some notes, I even did some research with my FPC hat on on what > > the best implementation would be and added that as a note, too. Which > > since it was just *my* FPC hat is just a suggestion about how the FPC > > may attack this, it is neither part of the EPEL voting, nor a > > guarantee that the FPC will do so. There may be even smarter and > > better implementations. > > The critique I issued multiple times somewhere else in this thread still > is the same: I don't want to give a binding vote on a "Should EPEL carry > a repotag? If yes, the technical details will be delegated to the > Packaging Committee." question at this point of time. I want to see what > burden a repotag might create for packagers before I'll feel safe to > bless repotags. So I would vote "no" to currently; but I would vote > "yes" to a question "Should we further investigate the use of a repotag > and the technical details how to realize them", as long as someone is > willing to do the investigating work. Since you already brought that up and I already answered to that, and now it's a rehash of the rehash, I'm just going to quote. On Thu, Apr 05, 2007 at 11:04:49AM +0200, Axel Thimm wrote: > On Thu, Apr 05, 2007 at 10:19:29AM +0200, Thorsten Leemhuis wrote: > > I don't care what they decide, but in this case I think it's > > [FPC's] business [...] > > > > People [of the EPEL committee] that vote should know what they > > vote about to make the decision, and that's not the case here > > afaics. > > You need to decide, do you make it FPC's call or not? You can't have > it both ways, e.g. put the FPC through making a decision and then > turning it down. On Thu, Apr 05, 2007 at 12:02:40PM +0200, Axel Thimm wrote: > Aka postpone, work w/o a repotag and later noone wants to touch it > again. Aka effectivly vote against it, but pretend we care. Why > didn't you "investigate" when it was discussed? Everyone else > including the FPC did. -- 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 Fri Apr 6 10:09:28 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 06 Apr 2007 12:09:28 +0200 Subject: Voting: repotag for EPEL In-Reply-To: <20070406093825.GB31685@neu.nirvana> References: <20070405135151.GA4531@neu.nirvana> <46150C07.5050404@leemhuis.info> <20070405175636.GD4531@neu.nirvana> <46153F19.1010209@symetrix.com> <20070405183954.GH4531@neu.nirvana> <46154553.9080907@symetrix.com> <20070405190049.GJ4531@neu.nirvana> <461552C6.3050605@symetrix.com> <20070405230746.GO16463@neu.nirvana> <4616121A.6080306@leemhuis.info> <20070406093825.GB31685@neu.nirvana> Message-ID: <46161C58.4030107@leemhuis.info> Axel Thimm schrieb: > On Fri, Apr 06, 2007 at 11:25:46AM +0200, Thorsten Leemhuis wrote: >> Axel Thimm schrieb: >>> On Thu, Apr 05, 2007 at 01:49:26PM -0600, Bernard Johnson wrote: >>>> Axel Thimm wrote: >>> Gosh, contrary to my vanishing sanity I succumb, and I fed the votings >>> with some notes, I even did some research with my FPC hat on on what >>> the best implementation would be and added that as a note, too. Which >>> since it was just *my* FPC hat is just a suggestion about how the FPC >>> may attack this, it is neither part of the EPEL voting, nor a >>> guarantee that the FPC will do so. There may be even smarter and >>> better implementations. >> The critique I issued multiple times somewhere else in this thread still >> is the same: I don't want to give a binding vote on a "Should EPEL carry >> a repotag? If yes, the technical details will be delegated to the >> Packaging Committee." question at this point of time. I want to see what >> burden a repotag might create for packagers before I'll feel safe to >> bless repotags. So I would vote "no" to currently; but I would vote >> "yes" to a question "Should we further investigate the use of a repotag >> and the technical details how to realize them", as long as someone is >> willing to do the investigating work. > > Since you already brought that up and I already answered to that, and > now it's a rehash of the rehash, I'm just going to quote. [...] Seems we are going in circles. Well, I was just trying to be helpful as I thought you would be interested in that as that would be the chance to get me to support your voting, but well, seems this is going nowhere. CU thl From Axel.Thimm at ATrpms.net Sat Apr 7 14:56:56 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 7 Apr 2007 16:56:56 +0200 Subject: Deleted minutes Message-ID: <20070407145656.GD15052@neu.nirvana> Hi Thorsten, you're deleting the minutes in the wiki replacing with a link to the mailing list. Keeping the minutes in the wiki is making life easier for using the wiki's search engine to check what had been said in a meeting. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Sat Apr 7 15:01:45 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 07 Apr 2007 10:01:45 -0500 Subject: Deleted minutes In-Reply-To: <20070407145656.GD15052@neu.nirvana> References: <20070407145656.GD15052@neu.nirvana> Message-ID: <4617B259.9010902@redhat.com> Axel Thimm wrote: > Hi Thorsten, > > you're deleting the minutes in the wiki replacing with a link to the > mailing list. Keeping the minutes in the wiki is making life easier > for using the wiki's search engine to check what had been said in a > meeting. > > https://www.redhat.com/archives/fedora-infrastructure-list/2007-April/msg00031.html We've been discussing this on the infrastructure list. We are having wiki issues. Moin doesn't scale very well. Since the content isn't being deleted (it still exists on the mailing list) I don't see an issue. -Mike From fedora at leemhuis.info Sat Apr 7 15:42:55 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 07 Apr 2007 17:42:55 +0200 Subject: Deleted minutes In-Reply-To: <4617B259.9010902@redhat.com> References: <20070407145656.GD15052@neu.nirvana> <4617B259.9010902@redhat.com> Message-ID: <4617BBFF.4030906@leemhuis.info> Mike McGrath schrieb: > Axel Thimm wrote: >> you're deleting the minutes in the wiki replacing with a link to the >> mailing list. Keeping the minutes in the wiki is making life easier >> for using the wiki's search engine to check what had been said in a >> meeting. > https://www.redhat.com/archives/fedora-infrastructure-list/2007-April/msg00031.html > We've been discussing this on the infrastructure list. We are having > wiki issues. Moin doesn't scale very well. Since the content isn't > being deleted (it still exists on the mailing list) I don't see an issue. In addition: I added a link to the mailing list post for the last meeting (the one two weeks ago) only and didn't put the log in the wiki. Nobody yelled, then came the discussion mike pointed to, so I thought it was a good idea to be consisted when I added the link to this weeks meeting and pointed the old ones to the mailing list, too. Cu thl From buildsys at fedoraproject.org Mon Apr 9 19:47:42 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 9 Apr 2007 15:47:42 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-04-09 Message-ID: <20070409194742.8ECA1152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 4 conmux-0.0-6.493svn.el5 firmware-addon-dell-1.2.11-1.el5 rrdtool-1.2.19-1.el5 NEW websec-1.9.0-3.5 Packages built and released for Fedora EPEL 4: 5 firmware-addon-dell-1.2.11-1.el4 nas-1.9-1.el4 rrdtool-1.2.19-1.el4 tmda-1.1.11-3.el4 NEW websec-1.9.0-3.4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From rayvd at bludgeon.org Mon Apr 9 21:19:49 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Mon, 9 Apr 2007 14:19:49 -0700 Subject: Packaging question (new packager) Message-ID: <20070409211949.GA19732@bludgeon.org> Hello all. Have been wanting to get involved with Fedora/CentOS for some time, and though helping package up a few programs which I use frequently would be a good way to get my feet wet. I've built an RPM for 'remind', which is a pretty cool little scheduling utility that I use in place of a GUI Calendar. I have a few questions on the "proper" (Fedora) way that this utility should be packaged up however. remind includes a couple scripts: rem2ps, tkremind, cm2rem.tcl to name a few that obviously would depend on TCL/TK being present on the system. Is the proper way to handle this to make a subpackage for these few scripts (remind-extras or remind-gui, etc)? Or, since remind itself works fine without them, just to exclude them completely from the RPM? Or perhaps throw them in /usr/share/doc ... Also, remind distributes their source with a source tarball name as follows: remind-03.00.24.tar.gz This corresponds with v3.00.24 of the program. I've left this version number intact in my spec file, but perhaps I should tuncate it to 3.00.24? The naming guidelines don't seem to cover a scenario like this. I left it at 03.00.24 because it made my %prep and %setup steps simpler. :) Thanks in advance for any guidance. Ray From tcallawa at redhat.com Tue Apr 10 00:24:35 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 09 Apr 2007 19:24:35 -0500 Subject: Packaging question (new packager) In-Reply-To: <20070409211949.GA19732@bludgeon.org> References: <20070409211949.GA19732@bludgeon.org> Message-ID: <1176164675.3970.61.camel@localhost.localdomain> On Mon, 2007-04-09 at 14:19 -0700, Ray Van Dolson wrote: > I have a few questions on the "proper" (Fedora) way that this utility > should be packaged up however. > > remind includes a couple scripts: rem2ps, tkremind, cm2rem.tcl to name > a few that obviously would depend on TCL/TK being present on the > system. Is the proper way to handle this to make a subpackage for > these few scripts (remind-extras or remind-gui, etc)? Or, since remind > itself works fine without them, just to exclude them completely from > the RPM? Or perhaps throw them in /usr/share/doc ... I would put them in a subpackage that Requires: tk. > Also, remind distributes their source with a source tarball name as > follows: > > remind-03.00.24.tar.gz > > This corresponds with v3.00.24 of the program. I've left this version > number intact in my spec file, but perhaps I should tuncate it to > 3.00.24? The naming guidelines don't seem to cover a scenario like > this. I left it at 03.00.24 because it made my %prep and %setup steps > simpler. :) Following upstream is fine. Just make sure you are careful with ordering as versions change. ~spot From buildsys at fedoraproject.org Wed Apr 11 01:49:50 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 10 Apr 2007 21:49:50 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-04-10 Message-ID: <20070411014950.14EB5152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 1 python-formencode-0.7.1-1.el5 Packages built and released for Fedora EPEL 4: 1 NEW mod_evasive-1.10.1-3.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From Axel.Thimm at ATrpms.net Wed Apr 11 11:35:27 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 11 Apr 2007 13:35:27 +0200 Subject: Outcome of first EPEL votes: Rebuild, Repotag and fedora-usermgmt Message-ID: <20070411113527.GE11448@neu.nirvana> This is the report on the outcome of the EPEL votings to date. The one that passed needs a ratification by fesco (details are on http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting): 1) Rebuild of EPEL5 Topic: The packages currently in EPEL5 got build against RHEL5beta1; the plan is to rebuild them against RHEL5. The question is: how? Winning option: Simply delete the current repo and rebuild all packages 2) Introduction of a repotag Topic: Should EPEL carry a repotag? If yes, the technical details will be delegated to the Packaging Committee. Vote turned down 3) Vetoing fedora-usermgmt until FPC makes a decision Topic: Packages should not use fedora-usermgmt or other non-standard useradd replacements. Vote turned down fesco needs to ratify the outcome of vote 1) above, the turned down votes don't need any ratification of course. -- 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 Wed Apr 11 11:37:03 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 11 Apr 2007 13:37:03 +0200 Subject: Meeting today Message-ID: <20070411113703.GF11448@neu.nirvana> Hi, I will not be able to make it to (the first half of) the meeting today. -- 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 Wed Apr 11 12:13:56 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 11 Apr 2007 14:13:56 +0200 Subject: Outcome of first EPEL votes: Rebuild, Repotag and fedora-usermgmt In-Reply-To: <1176292756.6379.2.camel@zod.rchland.ibm.com> References: <20070411113527.GE11448@neu.nirvana> <1176292756.6379.2.camel@zod.rchland.ibm.com> Message-ID: <20070411121356.GA18875@neu.nirvana> On Wed, Apr 11, 2007 at 06:59:16AM -0500, Josh Boyer wrote: > On Wed, 2007-04-11 at 13:35 +0200, Axel Thimm wrote: > > This is the report on the outcome of the EPEL votings to date. The > > one that passed needs a ratification by fesco (details are on > > http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting): > > > > 1) Rebuild of EPEL5 > > > > Topic: The packages currently in EPEL5 got build against RHEL5beta1; the plan > > is to rebuild them against RHEL5. The question is: how? > > > > Winning option: Simply delete the current repo and rebuild all packages > > Why can't you just bump the release for the packages and rebuild against > a new buildroot? > > /me is confused by "delete the current repo". There is a discussion thread (or more than one) on the epel-devel list and the key points are presented on the URL given above. -- 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 Wed Apr 11 11:59:16 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 11 Apr 2007 06:59:16 -0500 Subject: Outcome of first EPEL votes: Rebuild, Repotag and fedora-usermgmt In-Reply-To: <20070411113527.GE11448@neu.nirvana> References: <20070411113527.GE11448@neu.nirvana> Message-ID: <1176292756.6379.2.camel@zod.rchland.ibm.com> On Wed, 2007-04-11 at 13:35 +0200, Axel Thimm wrote: > This is the report on the outcome of the EPEL votings to date. The > one that passed needs a ratification by fesco (details are on > http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting): > > 1) Rebuild of EPEL5 > > Topic: The packages currently in EPEL5 got build against RHEL5beta1; the plan > is to rebuild them against RHEL5. The question is: how? > > Winning option: Simply delete the current repo and rebuild all packages Why can't you just bump the release for the packages and rebuild against a new buildroot? /me is confused by "delete the current repo". josh From jwboyer at jdub.homelinux.org Wed Apr 11 12:20:00 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 11 Apr 2007 07:20:00 -0500 Subject: Outcome of first EPEL votes: Rebuild, Repotag and fedora-usermgmt In-Reply-To: <20070411121356.GA18875@neu.nirvana> References: <20070411113527.GE11448@neu.nirvana> <1176292756.6379.2.camel@zod.rchland.ibm.com> <20070411121356.GA18875@neu.nirvana> Message-ID: <1176294000.6379.8.camel@zod.rchland.ibm.com> On Wed, 2007-04-11 at 14:13 +0200, Axel Thimm wrote: > On Wed, Apr 11, 2007 at 06:59:16AM -0500, Josh Boyer wrote: > > On Wed, 2007-04-11 at 13:35 +0200, Axel Thimm wrote: > > > This is the report on the outcome of the EPEL votings to date. The > > > one that passed needs a ratification by fesco (details are on > > > http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting): > > > > > > 1) Rebuild of EPEL5 > > > > > > Topic: The packages currently in EPEL5 got build against RHEL5beta1; the plan > > > is to rebuild them against RHEL5. The question is: how? > > > > > > Winning option: Simply delete the current repo and rebuild all packages > > > > Why can't you just bump the release for the packages and rebuild against > > a new buildroot? > > > > /me is confused by "delete the current repo". > > There is a discussion thread (or more than one) on the epel-devel list > and the key points are presented on the URL given above. fedoraproject.org is down at the moment. I'll read it when it's back up. josh From dennis at ausil.us Wed Apr 11 17:31:48 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 11 Apr 2007 12:31:48 -0500 Subject: EPEL Chairperson Message-ID: <200704111231.48482.dennis@ausil.us> So now that we have our own steering committee we should elect a chairperson to keep things in line and running smoothly. We have two nominees for Chair Person they are Michael Stahnke and Thorsten Leemhuis So now we need to decide on who it should be. As well as a time line to elect a new chairperson so that one does not get burnt out. I would like the chairperson to be there for 6 months. -- Dennis Gilmore, RHCE From fedora at leemhuis.info Wed Apr 11 18:04:54 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 11 Apr 2007 20:04:54 +0200 Subject: EPEL Chairperson In-Reply-To: <200704111231.48482.dennis@ausil.us> References: <200704111231.48482.dennis@ausil.us> Message-ID: <461D2346.6010506@leemhuis.info> Dennis Gilmore schrieb: > [...] As well as a time line to elect > a new chairperson so that one does not get burnt out. I would like the > chairperson to be there for 6 months. The mandate for the EPEL Steering Committee is limited until 30.09.2007 anyway -- see http://fedoraproject.org/wiki/EPEL/SteeringCommittee ; quoting that page "Then then a new committee will be formed; FESCo and the EPEL Steering Committee until then will work out how this committee will get constituted; a mix of appointed and elected members is likely." That re-formation should IMHO include the chairmen. CU thl From mastahnke at gmail.com Wed Apr 11 20:54:55 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 11 Apr 2007 15:54:55 -0500 Subject: EPEL Chairperson In-Reply-To: <461D2346.6010506@leemhuis.info> References: <200704111231.48482.dennis@ausil.us> <461D2346.6010506@leemhuis.info> Message-ID: <7874d9dd0704111354p5d597efbx1dd7dd8303b6dc9e@mail.gmail.com> On 4/11/07, Thorsten Leemhuis wrote: > Dennis Gilmore schrieb: > > [...] As well as a time line to elect > > a new chairperson so that one does not get burnt out. I would like the > > chairperson to be there for 6 months. > > The mandate for the EPEL Steering Committee is limited until 30.09.2007 > anyway -- see http://fedoraproject.org/wiki/EPEL/SteeringCommittee ; > quoting that page "Then then a new committee will be formed; FESCo and > the EPEL Steering Committee until then will work out how this committee > will get constituted; a mix of appointed and elected members is likely." > That re-formation should IMHO include the chairmen. Agreed. That's close enough to 6 months anyway. > > CU > thl > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From fedora at leemhuis.info Thu Apr 12 15:35:14 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 12 Apr 2007 17:35:14 +0200 Subject: Summary of EPEL Steering Committee meeting 20070412 Message-ID: <461E51B2.3050608@leemhuis.info> = Meeting 20070412 = [[TableOfContents]] == Attending == >From the Steering Committee: * dgilmore * mmcgrath * nirik * quaid * stahnma * thl Active on the rabble seats: * entr0py * wolfy == Summary == * wiki votings -- some people on the list complained about hardcoding releasever in the repofile. stahnma will look into the issue closer and ask the infrasturcute guys if a symlink could be set in place * votings via the wiki -- might need a bit more coordination in the future; reminders ("vote now") probably also; "we need more info on some of the issues"; all things of course can get revisited if we want, but we should probably take a issue as solved for the near future when it got voted upon; stahnma asked 'should I be voting "on behalf of epel consumers" or as a fedora developer? '; thl answered that it's probably a mix; * the idea to have a chairmen that coordinates was liked by some people (quiad: "I thought it was a requirement of a steering committee (or I think it should be) ") ; dgilmore brought this to the list for public discussion. * RHEL5 on the builders - legal problems got solved and should happen real soon now; dgilmore will look after the mass-rebuild as voted and then thl will announce the "Go" signal afterwards to those Fedora packages that are still waiting for it * pushing scripts/repo layout: thl will bring this to the list for further discussion * stahnma will help quiad with his "Communication plan for enterprise customers/ISVs/IHVs" http://fedoraproject.org/wiki/EPEL/CommunicationPlan ; will get send to the list for further discussion, too. == MISC == There were three votings by the EPEL steering committee done via the wiki; see https://www.redhat.com/archives/epel-devel-list/2007-April/msg00055.html for details. In short: no repotags, fedora-usermgmt does not get forbidden and the mass-rebuild will happen in a "delete repo and just rebuild everything again with RHEL5 final on the builders now"-style. == Full Log == {{{ 00:01 --- | thl has changed the topic to: EPEL Meeting 00:01 < thl> | hi everyone 00:01 * | entr0py grabs first set of rocks to volley into the group :) 00:01 < thl> | ping dgilmore mmcgrath_ stahnma quaid nirik 00:02 < stahnma> | ack 00:03 < nirik> | I'm mostly here. 00:03 < thl> | that makes 2,5 people afaics 00:03 < quaid> | howdy 00:04 < thl> | 3,5 00:04 < stahnma> | almost a quarum 00:04 < quaid> | depends on your def. of a quorum; "enough to be the majority of the vote if the consensus is 100%" is good enough for me :) 00:04 < quaid> | also, thimm said he'd be ... late? half way through, right? 00:05 < thl> | quaid, yes, that's what he said 00:05 < stahnma> | do we have topics? 00:05 * | thl really would like to know what the status of RHEL5 final on the builders is; but we need mmcgrath_ and dgilmore for that 00:05 < thl> | stahnma, well, we have a schedule 00:05 < stahnma> | I know dgilmore was working on it the other night when i was chatting with him 00:06 < stahnma> | good enough :) 00:06 < thl> | afaics we should talk about these topics: 00:06 < nirik> | is centos5 out yet? I think I saw something about it starting to mirror.. 00:06 < stahnma> | oooh 00:06 < stahnma> | haven't seen it 00:06 < thl> | RHEL5 final on the builders 00:06 < thl> | did we like the wiki votings 00:06 < thl> | anything to further discuss about the wiki votings 00:06 < entr0py> | c5 still mirroring 00:07 < thl> | revisit the hardcoding of releasever in the repo file 00:07 < nirik> | it's not hit my mirror yet, oh well. 00:07 < stahnma> | I guess since our votings are quite public, I think we should be able to say why we vote the way we do 00:07 < stahnma> | currently the release is harded in epel-release 00:07 < stahnma> | it can change if the repo changes 00:07 < thl> | stahnma, yeah, I know; but some people complained on the list 00:07 < stahnma> | and that's an infrastructure call 00:08 < stahnma> | yeah, I can go either way 00:08 < stahnma> | I normally wouldn't recommend an upgrade from EL n to EL n+1 00:08 < stahnma> | via yum 00:08 < thl> | yeah, but we need dgilmore and mmcgrath_ for that, as those two could create the proper links on the server 00:08 < stahnma> | or up2date 00:08 < stahnma> | but whatever 00:08 < nirik> | I've had 3->4 work with centos yum updates anyhow... 00:09 < nirik> | but yeah, not something supported, but nice to have the option for people if they want to try. 00:09 < stahnma> | well, they can edit the repo files also... 00:09 < stahnma> | isn't that how you have to start an upgrade? 00:09 < stahnma> | change what repo you point at? 00:10 < thl> | stahnma, installing a new fedora-release in enough in fedora 00:10 < stahnma> | in which case, the repo files being hard-coded or not doesn't matter correct? 00:10 < nirik> | upgrade the release file... no changing of the files. 00:10 < stahnma> | oh ok 00:10 < thl> | I suspect it will be similar in RHEL/Centos 00:10 < stahnma> | been a long time since I have done an upgrade like that 00:10 < stahnma> | as I said, i will happily change it 00:10 < stahnma> | if it will work 00:10 < stahnma> | I changed to hard-coding after it didn't work on RHEL 00:10 < thl> | stahnma, could you work on getting the whole issue solved? 00:10 < stahnma> | thl: sure 00:10 < thl> | stahnma, e.g. ask dgilmore and mmcgrath_ for their opinion 00:11 < stahnma> | no problem 00:11 < stahnma> | I speak with dgilmore daily 00:11 < thl> | and get is discussed on the mailig list if needed 00:11 < thl> | stahnma, k, sounds good 00:11 < stahnma> | yup, next item 00:11 --- | thl has changed the topic to: EPEL meeting -- votings via the wiki 00:11 * | rdieter is lurking in the shadows... 00:11 < thl> | so, did we like it? 00:11 < thl> | I'd say we need more coordination 00:11 <-- | llaumgui has quit (Read error: 110 (Connection timed out)) 00:11 * | quaid is pretty sure that updating redhat-release is similar 00:11 < nirik> | well, it was ok, but we need more info on some of the issues I think. 00:12 < thl> | otherwise each and everyone might issue votings 00:12 < stahnma> | reminders sent va email would be cool 00:12 < thl> | and that could lead to chaos 00:12 * | entr0py agrees with nirik 00:12 < quaid> | I explained my problems in my comment field of my vote 00:12 < thl> | it was a hard discussion this time already 00:12 --> | llaumgui (LLaumgui) has joined #fedora-meeting 00:12 < thl> | quaid, that's okay; but I think it's nevertheless good to have you here 00:12 < quaid> | I had to abstain because of ignorance, and I couldn't tell if I was ignorant because the issues were too complex, or because this was a molehill being made into a mountain. 00:12 --> | kital (Joerg Simon) has joined #fedora-meeting 00:13 < thl> | nirik, agreed to "more info" 00:13 < GeroldKa> | hello kital 00:13 < thl> | nirik, that what I mean with more "coordination", too 00:13 < nirik> | it's also unclear... does this mean those issues are decided forever? (I hope not) or just for "a while" 00:13 < stahnma> | I question my voting: should I be voting "on behalf of epel consumers" or as a fedora developer? 00:13 < quaid> | thl: so, I had to have faith that a vote was useful in this case 00:13 < kital> | hi GeroldKa 00:13 < quaid> | stahnma: good question 00:13 < thl> | nirik, I'd say wiki votings are similar to votings here 00:13 < thl> | e.g. we can always revisit stuff if we like to 00:14 --> | wolfy (Manuel Wolfshant) has joined #fedora-meeting 00:14 < nirik> | good, althought not every week I hope. ;) 00:14 < thl> | nirik, agreed :) 00:14 < stahnma> | maybe we say a vote cast drops an item for 60 days or something? 00:14 < stahnma> | or maybe need a policy that formal 00:14 < thl> | stahnma, no rules, for details like that IMHO 00:14 < nirik> | hopefully folks will push a replacement for fedora-usermgmt in fedora and we can just do the same thing when they do. 00:14 < thl> | stahnma, that makes it just hard 00:14 < stahnma> | s/need/don't\ need 00:15 < thl> | s/hard/complicated/ 00:15 < stahnma> | ok 00:15 * | dgilmore is here 00:15 < thl> | stahnma, and I'd say you should vote as someone that wants the best for epel (which in parts is "on behalf of epel consumers" and as "fedora developer" IMHO) 00:16 * | thl welcomes dgilmore 00:16 < thl> | dgilmore, will you stick around for the rest of the meeting? 00:16 < dgilmore> | nirik: fedora-usermgmt from FC-3 will work fine on RHEL4 00:16 < dgilmore> | thl: ill be here 00:16 < nirik> | right. and it's already in, so thats the way it will be for now. 00:17 < dgilmore> | yep 00:17 * | nirik needs to look at branching munin at some point now. 00:17 < stahnma> | thl: sometimes those are conflicting though 00:17 < thl> | stahnma, that's life ;-) 00:17 < stahnma> | thl: from a consumer prospective, I want a repo-tag, from a developer prospective, I understand not wanting it 00:17 < stahnma> | thl: true 00:17 < dgilmore> | nirik: im going to branch mysql-gui-tools it has some other things it needs 00:18 < thl> | so, how do we get more coordination into the wiki votes in the future? 00:18 < thl> | do we need a chair that coordinates this and other stuff? 00:18 < nirik> | I don't think so... 00:18 < thl> | or do we want rules like "at least two Steering committee members are needed to start a voting"? 00:19 < nirik> | I would like to see 2 people setup a vote... one "for" and one "against" the item, so they could each write the pros and cons. 00:19 < stahnma> | I didn't think it was too bad. I think reminder emails to vote are good. And, I agree that starting the vote needs to be looked at 00:19 < dgilmore> | nirik: if everyone agrees then we will never vote 00:19 < stahnma> | nirik: +1 00:19 < nirik> | having input from people on both sides would help. 00:19 < quaid> | seems like the question of "to chair or not to chair" is maybe not ours to make; I thought it was a requirement of a steering committee (or I think it should be) 00:19 < nirik> | dgilmore: don't want them to agree on the issue, just agree to summarize it for a vote... 00:20 < entr0py> | nirik, i agree, which is what i was pointing out to thimm. without opposing views, what is the vote really worth 00:20 < quaid> | once a project reaches the size or scope to need a *SCo ... 00:20 < thl> | quaid, well, we never discussed it; but yes, I also tend to say a steering committee normally should have a chairmen 00:20 < dgilmore> | i think that we need a chair person and that they put up the votes 00:20 < quaid> | it needs an identified single person that all the rst of the world recognizes as "in charge" and "person to go to" 00:20 < quaid> | it can be nominal, etc., but it helps 00:21 < thl> | quaid, +1 00:21 < stahnma> | quaid +1 00:22 < dgilmore> | anyone want to nominate themselves as the chair person 00:22 < stahnma> | so do we need to figure out a chairperson for vote postings? 00:22 < stahnma> | I'd do it 00:22 < mmcgrath_> | crizap 00:22 * | mmcgrath_ here 00:22 < quaid> | we could discuss on list, too, since all aren't here right now. :) 00:22 * | thl could do the chair as well 00:23 < thl> | quaid, well, we should at least wait one week before lecting a chairmen 00:23 < quaid> | +1 00:23 * | stahnma votes for thl since he has experince and withdraws earlier statement 00:23 < dgilmore> | stahnma: too late 00:23 < stahnma> | haha 00:23 < quaid> | stahnma: well, how do you think he got the experience? 00:23 < stahnma> | good point 00:23 < quaid> | stahnma: have to start somewhere :D 00:23 < stahnma> | yeah, I have the time to put into it for the most part, so that's a plus 00:24 * | dgilmore feels he would not be able to be a good chair person. 00:24 < nirik> | I think it should get discussed on the list... 00:24 < stahnma> | + 00:24 < dgilmore> | ok so we have two nominees lets take it to the list 00:24 * | nirik would be happy with thl or stahnma 00:25 < stahnma> | ok, back to RHEL 5 on the builders? (now that infrastructure folk are here) 00:25 < thl> | so, shall we mention it in the summary or shall someone open a seperate discusion? 00:25 < thl> | seperate discussion +1 00:25 < stahnma> | either way is fine with me 00:25 < dgilmore> | thl: ill start a seperate discussion 00:25 < thl> | dgilmore, k, thx 00:25 < thl> | and I'll write the summary 00:25 --- | thl has changed the topic to: RHEL5 on the builders 00:26 < thl> | mmcgrath_, dgilmore, any news? 00:26 < mmcgrath_> | Yeah, we finally have approval. 00:26 --- | thl has changed the topic to: EPEL meeting -- RHEL5 on the builders 00:26 < thl> | hurray! 00:26 < mmcgrath_> | so we can put it up whenever we're ready. 00:26 < thl> | mmcgrath_, when are we ready? 00:26 < mmcgrath_> | we can do it now 00:26 < thl> | now sounds really good to me :-) 00:27 < thl> | I'd really like to start, and we need RHEL5 final for that 00:27 < dgilmore> | mmcgrath_: want me to do it tonight? 00:27 < mmcgrath_> | dgilmore: sounds good to me. 00:27 < thl> | dgilmore, thx 00:28 < thl> | who can kick off the rebuild after RHEL5 is installed? 00:28 < thl> | and when? 00:28 < mmcgrath_> | when, any time. 00:29 < thl> | can we get that done until Sunday maybe? 00:29 < thl> | then I could send out a "now start for realy guys" mail out on sunday evening/Monday 00:29 < mmcgrath_> | I think anyone can request a rebuild, I've been late on catching up on EPEL traffic. Did we decide exactly how we're going to do it? 00:29 < dgilmore> | mmcgrath_: rm -rf 00:30 < thl> | mmcgrath_, the wiki-voting was "delete and just rebuild" 00:30 < thl> | s/was/agreed on/ 00:30 < mmcgrath_> | excellent. 00:30 < thl> | but that requires that either you or dgilmore do it afaics 00:31 < thl> | I can help if you tell me what to do 00:31 < thl> | but I think there are scripts that automate everything? 00:32 < mmcgrath_> | not that I know of. 00:32 < dgilmore> | thl: ill work out an easy way to get it done 00:32 < thl> | dgilmore, thx 00:32 < dgilmore> | the scripts we have do a bump and build 00:32 < thl> | k 00:33 --- | thl has changed the topic to: EPEL meeting -- what else? 00:33 < thl> | anything else to discuss? 00:33 < stahnma> | thl: will this "for real now guys" message ask people to get their packages into EPEL? 00:33 * | dgilmore has nothing right now 00:33 < dgilmore> | stahnma: yes 00:33 < entr0py> | is there any target date for announcement of the repos? 00:34 < thl> | stahnma, well, it more a "if you waited for the signal to start then this is it" mail 00:34 < dgilmore> | along with if you dont want to and someone else does we will let them 00:34 < nirik> | so do we have all the pushing scripts set? what about with the testing repo? 00:34 < stahnma> | thl: that's fine. 00:34 < thl> | entr0py, not yet 00:34 < stahnma> | what about mirrors? 00:34 < thl> | entr0py, I#d say we need to test a bit more 00:34 < dgilmore> | nirik: that will be in the next week 00:34 < thl> | and we need the final repo layout 00:34 < dgilmore> | we need boshi for that 00:34 < dgilmore> | bodhi 00:35 < dgilmore> | lmacken: where you at? 00:35 < nirik> | how do developers push from testing to release? ah... bodhi will be available? 00:35 * | thl for a moment thought he got confused with all those codenames 00:35 * | dgilmore needs to help lmacken 00:35 < lmacken> | dgilmore: i'm here 00:35 < entr0py> | will the rebuild push everything to testing? 00:35 * | nirik is eager to break^H^H^H^H^Htry out bodhi. 00:35 < dgilmore> | lmacken:everything other than the bit i said i would do in place 00:36 < thl> | entr0py, everything should be in testing IMHO, but isn't :-/ 00:36 < lmacken> | dgilmore: yeah. I have yet to make sure my updates stage matches the EPEL layout that you guys voted on 00:37 < dgilmore> | ok 00:37 < stahnma> | do we have a process to move from testing to proper? 00:37 < lmacken> | there is a "Mark as stable" button in bodhi 00:37 < thl> | lmacken, the layout can be adjusted if we need to, but I think the current proposal should make most people happy 00:37 < lmacken> | which will request that it be mvoed from testing=>final 00:37 < dgilmore> | stahnma: i thought we were going to do votes or 2 weeks 00:37 < lmacken> | thl: ok 00:37 < stahnma> | dgilmore: that's fine, I was just curious if we had a method. (I didn't remember) 00:38 < thl> | stahnma, most stuff normally should go to testing anyway 00:38 < thl> | and stay there until the next quarterly update 00:38 < dgilmore> | security updates can bypass testing thats it 00:38 < thl> | only security or other bad bugs should go to stable directly 00:38 < stahnma> | thl: I agree , just want to make sure I understand how things work 00:39 < entr0py> | thl: agree, weren't we working on formalizing an approach for epel? 00:39 < thl> | stahnma, I'd say we should take a closer look at it when we know how bodhi works 00:39 < stahnma> | maybe make that a future topic 00:39 <-- | kital has quit (Read error: 110 (Connection timed out)) 00:39 < stahnma> | for discussion 00:39 < wwoods> | The method is evolving but should involve some testing by a QA-type person 00:39 < stahnma> | seems fair 00:39 < nirik> | yeah, testing ++ 00:39 < thl> | wwoods, for epel there was actually a three stage mechanism under discussion 00:40 < wwoods> | we want to start writing how-to-test docs for each package, but basically the short version will be that some QA person needs to actually install the package and make sure it actually works 00:40 --> | kital (Joerg Simon) has joined #fedora-meeting 00:40 < wwoods> | what are the three stages? 00:40 < nirik> | http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies 00:40 < thl> | wwoods, kind of "testing-testing" (new builds), "testing" (becomes stable with the next quearterly update and "stable" (only serios bugfixes) 00:41 <-- | kital has quit (Remote closed the connection) 00:41 < nirik> | oh wait, that wasn't the right link... 00:41 < wwoods> | In my mind there's quite a few possible stages - automated package sanity testing, manual functional verification by a QA dude, automated regression tests 00:42 < lmacken> | wwoods: as well as updates-testing community testing 00:42 < wwoods> | the updates-testing repo is basically a work queue for QA 00:42 < thl> | we probably should discuss this on the list 00:42 < nirik> | wwoods: the diffrence between fedora and epel here is that epel would be considered to be in "freeze" all the time... only bugfixes to the release... new functionality/versions only happen at new minor RHEL releases. 00:42 < thl> | that might make things a bit easier 00:42 < mmcgrath_> | thl: +1 00:42 < wwoods> | well, when I say "QA dude", that's kind of a vague handwave for "Either an official QA guy or, until we have a big enough QA team, community folks" 00:43 < wwoods> | but yeah 00:43 <-- | bpepple has left #fedora-meeting ( "Ex-Chat") 00:43 < wwoods> | we can take this to the list, but I'd like to sit down and define a QA process for stuff in updates-testing 00:43 < thl> | mmcgrath_, I'll write everything up and send it to the list over the next week 00:43 < lmacken> | wwoods: https://hosted.fedoraproject.org/projects/bodhi/wiki/DesignTesting 00:43 < lmacken> | poelstra helped get that ball rolling 00:44 < wwoods> | awesome 00:44 < lmacken> | wwoods: the actual files are in the bodhi code.. feel free to modify 00:44 < thl> | k, so anything else regarding EPEL? 00:45 < stahnma> | I still would like to see us work on something encouraging involvment from companies 00:45 < stahnma> | I don't know exactly how/what 00:45 < stahnma> | but I think first step is to have EPEL in existance 00:45 < stahnma> | so maybe not today 00:45 < dgilmore> | stahnma: as would i quaid is best to do that 00:45 < thl> | stahnma, didn't quaid work on something in that area? 00:45 * | dgilmore needs to go get food soon 00:45 < thl> | stahnma, "Communication plan for enterprise customers/ISVs/IHVs" is on the schedule 00:45 < nirik> | having a functioning setup will help with community and company involvement. 00:46 < thl> | and it's assigned to quaid 00:46 < thl> | stahnma, there is a wiki page 00:46 < thl> | stahnma, maybe you can help him with that a bit? 00:46 * | stahnma apparently can't read and forgets what he reads after the fact :) 00:46 < stahnma> | yeah, i will help with that 00:46 < nirik> | lmacken: that chart is great. Just what I was thinking the process would be. ;) 00:46 < quaid> | there is a page 00:46 * | quaid looks for URL 00:46 < lmacken> | nirik: nice 00:47 < thl> | quaid, http://fedoraproject.org/wiki/EPEL/CommunicationPlan 00:47 < quaid> | ah, that one yes 00:47 < quaid> | right 00:47 < stahnma> | quaid: ah , I remember that 00:47 < quaid> | the help I need is the part i don't have in my head, the rebuild developers/packagers 00:47 < stahnma> | quaid: great start :) 00:47 < quaid> | and the rebuild users 00:47 < quaid> | stahnma: thanks :) 00:48 < quaid> | I'll either write or coordinate the RHEL Customers section, since I do somewhat understand that audience :) 00:48 < quaid> | same with the isv/ihv part 00:48 < stahnma> | great 00:48 * | stahnma is out of random topics 00:48 < thl> | quaid, maybe sending what you have to the list and asking for opinions and feedback might help to evolve it further 00:48 < quaid> | we could take this to the list for discussion, whenever we are ready 00:48 < quaid> | heh, jinx! 00:48 < quaid> | thl: right-O, will do 00:49 < thl> | k, anything else? 00:49 < dgilmore> | thl: nope 00:49 * | thl will close the meeting in 60 00:49 < stahnma> | later all, lunch time here... 00:50 * | thl will close the meeting in 30 00:50 * | thl will close the meeting in 15 00:50 < thl> | -- MARK -- Meeting end 00:50 < thl> | thx everyone 00:50 < wolfy> | thank you, guys 00:51 < nirik> | thanks all 00:51 * | wolfy waiting eagerly for the countdown till real launch of EPEL :) 00:51 --- | thl has changed the topic to: http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel -- Meetings often get logged -- see schedule in the wiki for next meeting 00:51 < quaid> | do we have a timeline set for that then? 00:52 < thl> | quaid, no, we haven't yet 00:52 < quaid> | ok, just checking :) 00:52 < thl> | and I don#t really feel compfortable setting one yet 00:52 * | quaid misses things, at times 00:52 < quaid> | thl: yes, seems a little premature 00:52 < thl> | let's see how it works out after we open the flood gates 00:52 < thl> | now that we have RHEL5 on the builders soon 00:53 < thl> | then we need the proper layout 00:53 < thl> | and well, if the repo is in a good shape then we can announce quickly 00:53 < thl> | good shape and big enough 00:53 < wolfy> | ... and QA policy 00:53 < entr0py> | will integration of bodhi be soon? 00:53 < entr0py> | or is it even finished? 00:53 < thl> | but it seem there are a lot of packages in EPEL already 00:54 < thl> | entr0py, "soon" afaik 00:54 < entr0py> | nice 00:54 < thl> | wolfy, are you volunteering for writing a QA policy? 00:54 < thl> | wolfy, we didn#t talk about such a policy yet 00:54 < thl> | s/yet/much &/ 00:55 < wolfy> | thl: I would if I knew how. Unfortunately I am much closer to sysadm then to policy design 00:55 < thl> | wolfy, well, keep it in mind and bring it up again when we get closer to the final annoucement 00:55 < wolfy> | roger that 00:56 <-- | giallu has quit (Read error: 110 (Connection timed out)) 00:57 < entr0py> | thanks thl }}} From fedora at leemhuis.info Thu Apr 12 18:26:25 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 12 Apr 2007 20:26:25 +0200 Subject: Revisiting the mass rebuild plans for EPEL5 Message-ID: <461E79D1.70401@leemhuis.info> Hi, FESCo today nacked the rebuild plan from voting "1" in https://www.redhat.com/archives/epel-devel-list/2007-April/msg00055.html See the end of this mail for details. In short: FESCo afaics didn't like to leave release unchanged. So I'd like to propose we switch back to the alternate plan (should still be in the wiki at http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting but the wiki is down currently aaics :-( ) that I proposed in the vote. That would mean: We announce when RHEL5 is on the builders to the public and give people round about 72 (?) hours to rebuild their EPEL5 packages manually on their own (in case they want to do it themselves). Everything that didn't get rebuild gets a ".1" added to release in cvs; that change gets committed, tagged and build -- we afaik have a script that should be able to do that and I can take care of running it if that's okay for everyone. Does that sounds sane to everyone? CU thl P.S.:here is the relevant part from the FESCo meeting: 19:42 --- | bpepple has changed the topic to: FESCO-Meeting -- EPEL 19:42 < bpepple> | anything in regard to EPEL need to be discussed? 19:42 < jwb> | yes 19:42 * | thl send some notes from this week to the list 19:43 < thl> | one hour or so ago 19:43 < tibbs> | notting: If you do have any ideas about that, please let us know. 19:43 < jwb> | there was the buildroot issue Axel wanted acked by FESCo 19:43 < notting> | tibbs: get out baseball bats and beat upstream? :) 19:43 * | bpepple hasn't had a chance to read his e-mail today. :( 19:44 < thl> | bpepple, it's about the "mass-rebuild of EPEL5 now that we soon have RHEL5 final on the builders" 19:44 < thl> | bpepple, it was voted to delete everything and just rebuild 19:44 < bpepple> | thl: ok. 19:44 < jwb> | -1 19:44 < thl> | everything, without chaning ENVR 19:44 < f13> | er.. 19:44 < jwb> | yeah, -1 19:44 < f13> | that may not bode well for clients whom already ahve stuff installed 19:45 < nirik> | (note: only EPEL-5... not 4) 19:45 < thl> | f13, tell those that voted like that 19:45 < f13> | as noted many times before, packages changing checksums and such get messy 19:45 < jwb> | f13, it was noted in their discussion. apparently it didn't seem that big of a deal 19:45 * | thl disliked that plan, too 19:45 < jwb> | are we voting on this yet? 19:45 < f13> | *shrug* I don't run rhel5 so I won't get effected by it. 19:45 < jwb> | f13, more than rhel5 19:45 < bpepple> | jwb: Yeah, we should do a quick vote. 19:46 < tibbs> | I'm still not understanding why you wouldn't want to bump, and I read the IRC logs. 19:46 < jwb> | tibbs, me either 19:46 < dgilmore> | tibbs: becaue people did not want to fork the spec 19:46 < jwb> | that is just lazy 19:46 < thl> | jwb, +1 19:46 < jwb> | you're pissing on your users because you don't want to make a 2 character change 19:46 < dgilmore> | i wanted to add a .1 and rebuild 19:46 < tibbs> | Ah, that is a point, but I don't think it's a terribly good point. 19:46 < jwb> | dgilmore, that would be very acceptable 19:46 < c4chris> | yea, .1 and rebuild 19:46 < rdieter> | dgilmore: +1 19:46 < tibbs> | The spec will diverge pretty much immediately anyway. 19:47 < jwb> | right 19:47 < thl> | dgilmore, why did you vote for deleting the packges then? 19:47 * | thl is confused 19:47 < notting> | ? you don't need to fork the spec. just b/c the release changes, doesn't mean you have to build and push for older releases 19:47 < jwb> | notting, fork it vs. the fedora spec 19:47 <-- | sankarshan has quit (Connection timed out) 19:47 < f13> | notting: er, they have to bump the spec there, but nowhere else, so now the specs are diverged 19:48 < notting> | *horrors* 19:48 < tibbs> | As I understand things, EPEL has no reason to attempt to keep any kind of release ordering with Fedora. 19:48 < dgilmore> | thl: i was confused by then. 19:48 < f13> | not that I find anything _wrong_ with that. 19:48 < tibbs> | So it's not even appending ".1"; just bump the release. 19:48 < f13> | nod 19:48 < thl> | dgilmore, np, I was just confused now 19:48 < notting> | thl: well, two issues. i'd be all for 'rebuild and delete all old packages', but with a release bump 19:48 < thl> | tibbs, some people prefer to appending ".1" ovefr bumpin the release 19:48 < f13> | is there a call for fesco vote? 19:48 < thl> | I think they have a point 19:49 < jwb> | f13, axel requested one 19:49 < f13> | or a point 1 19:49 < f13> | (: 19:49 < thl> | notting, sounds fine for me 19:49 < c4chris> | :-) 19:49 < tibbs> | OTOH, not rebuilding at all seems to be working for Fedora at this point. What's the reason they absolutely must be rebuilt? 19:49 < abadger1999> | tibbs: If they want to use the vanilla spec later, using .1 lets them come back on the next Fedora Release rather than the next upstream bump 19:49 < nirik> | tibbs: they were build against beta1 19:49 < tibbs> | abadger1999: Extremely good point. 19:49 < f13> | abadger1999: but that actually overwrites history 19:50 < f13> | unless they merge that .1 somewhere into the history of hte FEdora spec 19:50 < nirik> | abadger1999: yeah, changelog is lost then if you merge 19:50 < tibbs> | nirik: And we have .fc6 packages in F7; surely F7 diverges from FC6 more than rhel5b1 diverges from rhel5release. 19:50 < thl> | f13, is that really a big problem if it was just a "rebuild" in the chanelog? 19:50 < notting> | dgilmore, this is only rebuilding things actually built for EPEL, not everything in EPEL cvs, right? 19:50 < thl> | notting, yes, only what has been build up to now 19:51 < f13> | thl: it's not a really big problem, but I generally don't like to see history get stomped 19:51 < nirik> | tibbs: yeah, you would think so... dunno for sure. 19:51 < thl> | f13, agreed; I think in this case it's still not nice, but acceptable 19:51 < f13> | and who k nows what happens with the rebuild, something may end up needing changed to build again against RHEL5 GA 19:51 < f13> | tibbs: you'd be surprised what all changed from B1 to GOLD 19:52 * | rdieter thinks we're not here to (re)make epel's decision for them (or not?), just ack or nack it. 19:52 < f13> | -1 19:52 < f13> | (for their current plan) 19:52 < jwb> | -1 19:52 < c4chris> | (plan == rebuild and no bump, right) 19:52 < jwb> | rdieter, but we can nack with a suggested improvement 19:52 < thl> | c4chris, yes 19:52 < f13> | c4chris: yep 19:53 < bpepple> | c4chris: correct. 19:53 < c4chris> | k, -1 then 19:53 < notting> | -1 19:53 < bpepple> | -1 here also. 19:53 < tibbs> | Yeah, I hate to be an obstruction, but -1 to rebuilding with no bump. 19:53 < abadger1999> | -1 19:53 < thl> | jwb, I can take care of that if you want; i was against this in any case ;-) 19:53 < bpepple> | so it looks like we against EPEL suggested plan. 19:53 < jwb> | thl, great 19:54 <-- | gregdek has quit (Read error: 104 (Connection reset by peer)) 19:54 < thl> | bpepple, I'll get that out to epel and will take care of it 19:54 < dgilmore> | notting: yeah just whats built 19:54 < bpepple> | thl: great, thanks. From mastahnke at gmail.com Thu Apr 12 19:56:13 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 12 Apr 2007 14:56:13 -0500 Subject: Revisiting the mass rebuild plans for EPEL5 In-Reply-To: <461E79D1.70401@leemhuis.info> References: <461E79D1.70401@leemhuis.info> Message-ID: <7874d9dd0704121256l7e2e2933g427b4983f4effed3@mail.gmail.com> Yes, this is fine from my point of view. Do we have guidelines on where the EPEL SIG/SC roles stops and FESCO starts? I would just like some clarification on what items the EPEL SC can actually decide and what is still left up to ratification of a higher power. stahnma On 4/12/07, Thorsten Leemhuis wrote: > Hi, > > FESCo today nacked the rebuild plan from voting "1" in > https://www.redhat.com/archives/epel-devel-list/2007-April/msg00055.html > See the end of this mail for details. In short: FESCo afaics didn't like > to leave release unchanged. > > So I'd like to propose we switch back to the alternate plan (should > still be in the wiki at > http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting > but the wiki is down currently aaics :-( ) that I proposed in the vote. > > That would mean: We announce when RHEL5 is on the builders to the public > and give people round about 72 (?) hours to rebuild their EPEL5 packages > manually on their own (in case they want to do it themselves). > Everything that didn't get rebuild gets a ".1" added to release in cvs; > that change gets committed, tagged and build -- we afaik have a script > that should be able to do that and I can take care of running it if > that's okay for everyone. > > Does that sounds sane to everyone? > > CU > thl > > P.S.:here is the relevant part from the FESCo meeting: > > 19:42 --- | bpepple has changed the topic to: FESCO-Meeting > -- EPEL > 19:42 < bpepple> | anything in regard to EPEL need to be discussed? > 19:42 < jwb> | yes > 19:42 * | thl send some notes from this week to the list > 19:43 < thl> | one hour or so ago > 19:43 < tibbs> | notting: If you do have any ideas about that, > please let us know. > 19:43 < jwb> | there was the buildroot issue Axel wanted acked > by FESCo > 19:43 < notting> | tibbs: get out baseball bats and beat upstream? :) > 19:43 * | bpepple hasn't had a chance to read his e-mail > today. :( > 19:44 < thl> | bpepple, it's about the "mass-rebuild of EPEL5 > now that we soon have RHEL5 final on the builders" > 19:44 < thl> | bpepple, it was voted to delete everything and > just rebuild > 19:44 < bpepple> | thl: ok. > 19:44 < jwb> | -1 > 19:44 < thl> | everything, without chaning ENVR > 19:44 < f13> | er.. > 19:44 < jwb> | yeah, -1 > 19:44 < f13> | that may not bode well for clients whom already > ahve stuff installed > 19:45 < nirik> | (note: only EPEL-5... not 4) > 19:45 < thl> | f13, tell those that voted like that > 19:45 < f13> | as noted many times before, packages changing > checksums and such get messy > 19:45 < jwb> | f13, it was noted in their discussion. > apparently it didn't seem that big of a deal > 19:45 * | thl disliked that plan, too > 19:45 < jwb> | are we voting on this yet? > 19:45 < f13> | *shrug* I don't run rhel5 so I won't get > effected by it. > 19:45 < jwb> | f13, more than rhel5 > 19:45 < bpepple> | jwb: Yeah, we should do a quick vote. > 19:46 < tibbs> | I'm still not understanding why you wouldn't want > to bump, and I read the IRC logs. > 19:46 < jwb> | tibbs, me either > 19:46 < dgilmore> | tibbs: becaue people did not want to fork the spec > 19:46 < jwb> | that is just lazy > 19:46 < thl> | jwb, +1 > 19:46 < jwb> | you're pissing on your users because you don't > want to make a 2 character change > 19:46 < dgilmore> | i wanted to add a .1 and rebuild > 19:46 < tibbs> | Ah, that is a point, but I don't think it's a > terribly good point. > 19:46 < jwb> | dgilmore, that would be very acceptable > 19:46 < c4chris> | yea, .1 and rebuild > 19:46 < rdieter> | dgilmore: +1 > 19:46 < tibbs> | The spec will diverge pretty much immediately anyway. > 19:47 < jwb> | right > 19:47 < thl> | dgilmore, why did you vote for deleting the > packges then? > 19:47 * | thl is confused > 19:47 < notting> | ? you don't need to fork the spec. just b/c the > release changes, doesn't mean you have to build and push for older releases > 19:47 < jwb> | notting, fork it vs. the fedora spec > 19:47 <-- | sankarshan has quit (Connection timed out) > 19:47 < f13> | notting: er, they have to bump the spec there, > but nowhere else, so now the specs are diverged > 19:48 < notting> | *horrors* > 19:48 < tibbs> | As I understand things, EPEL has no reason to > attempt to keep any kind of release ordering with Fedora. > 19:48 < dgilmore> | thl: i was confused by then. > 19:48 < f13> | not that I find anything _wrong_ with that. > 19:48 < tibbs> | So it's not even appending ".1"; just bump the > release. > 19:48 < f13> | nod > 19:48 < thl> | dgilmore, np, I was just confused now > 19:48 < notting> | thl: well, two issues. i'd be all for 'rebuild > and delete all old packages', but with a release bump > 19:48 < thl> | tibbs, some people prefer to appending ".1" ovefr > bumpin the release > 19:48 < f13> | is there a call for fesco vote? > 19:48 < thl> | I think they have a point > 19:49 < jwb> | f13, axel requested one > 19:49 < f13> | or a point 1 > 19:49 < f13> | (: > 19:49 < thl> | notting, sounds fine for me > 19:49 < c4chris> | :-) > 19:49 < tibbs> | OTOH, not rebuilding at all seems to be working > for Fedora at this point. What's the reason they absolutely must be > rebuilt? > 19:49 < abadger1999> | tibbs: If they want to use the vanilla spec > later, using .1 lets them come back on the next Fedora Release rather > than the next upstream bump > 19:49 < nirik> | tibbs: they were build against beta1 > 19:49 < tibbs> | abadger1999: Extremely good point. > 19:49 < f13> | abadger1999: but that actually overwrites history > 19:50 < f13> | unless they merge that .1 somewhere into the > history of hte FEdora spec > 19:50 < nirik> | abadger1999: yeah, changelog is lost then if you > merge > 19:50 < tibbs> | nirik: And we have .fc6 packages in F7; surely F7 > diverges from FC6 more than rhel5b1 diverges from rhel5release. > 19:50 < thl> | f13, is that really a big problem if it was just > a "rebuild" in the chanelog? > 19:50 < notting> | dgilmore, this is only rebuilding things actually > built for EPEL, not everything in EPEL cvs, right? > 19:50 < thl> | notting, yes, only what has been build up to now > 19:51 < f13> | thl: it's not a really big problem, but I > generally don't like to see history get stomped > 19:51 < nirik> | tibbs: yeah, you would think so... dunno for sure. > 19:51 < thl> | f13, agreed; I think in this case it's still not > nice, but acceptable > 19:51 < f13> | and who k nows what happens with the rebuild, > something may end up needing changed to build again against RHEL5 GA > 19:51 < f13> | tibbs: you'd be surprised what all changed from > B1 to GOLD > 19:52 * | rdieter thinks we're not here to (re)make epel's > decision for them (or not?), just ack or nack it. > 19:52 < f13> | -1 > 19:52 < f13> | (for their current plan) > 19:52 < jwb> | -1 > 19:52 < c4chris> | (plan == rebuild and no bump, right) > 19:52 < jwb> | rdieter, but we can nack with a suggested improvement > 19:52 < thl> | c4chris, yes > 19:52 < f13> | c4chris: yep > 19:53 < bpepple> | c4chris: correct. > 19:53 < c4chris> | k, -1 then > 19:53 < notting> | -1 > 19:53 < bpepple> | -1 here also. > 19:53 < tibbs> | Yeah, I hate to be an obstruction, but -1 to > rebuilding with no bump. > 19:53 < abadger1999> | -1 > 19:53 < thl> | jwb, I can take care of that if you want; i was > against this in any case ;-) > 19:53 < bpepple> | so it looks like we against EPEL suggested plan. > 19:53 < jwb> | thl, great > 19:54 <-- | gregdek has quit (Read error: 104 (Connection > reset by peer)) > 19:54 < thl> | bpepple, I'll get that out to epel and will take > care of it > 19:54 < dgilmore> | notting: yeah just whats built > 19:54 < bpepple> | thl: great, thanks. > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From fedora at leemhuis.info Fri Apr 13 19:00:23 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 13 Apr 2007 21:00:23 +0200 Subject: Revisiting the mass rebuild plans for EPEL5 In-Reply-To: <7874d9dd0704121256l7e2e2933g427b4983f4effed3@mail.gmail.com> References: <461E79D1.70401@leemhuis.info> <7874d9dd0704121256l7e2e2933g427b4983f4effed3@mail.gmail.com> Message-ID: <461FD347.7040007@leemhuis.info> Michael Stahnke schrieb: > Yes, this is fine from my point of view. k; other opinions? > Do we have guidelines on where the EPEL SIG/SC roles stops and FESCO > starts? Well, I think we can normally act on our own. But FESCo is in the hierarchy above us (and below the board); I'd expect they will leave us alone as long as we do sane things and as long as they get notices of important decisions or doings. > I would just like some clarification on what items the EPEL > SC can actually decide and what is still left up to ratification of a > higher power. Well, you probably should better ask FESCo or some of it's members in that case. Only real important things afaics needs "ratification", but FESCo might always want to now what up and jump in if they don't like something. CU thl > On 4/12/07, Thorsten Leemhuis wrote: >> Hi, >> >> FESCo today nacked the rebuild plan from voting "1" in >> https://www.redhat.com/archives/epel-devel-list/2007-April/msg00055.html >> See the end of this mail for details. In short: FESCo afaics didn't like >> to leave release unchanged. >> >> So I'd like to propose we switch back to the alternate plan (should >> still be in the wiki at >> http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting >> but the wiki is down currently aaics :-( ) that I proposed in the vote. >> >> That would mean: We announce when RHEL5 is on the builders to the public >> and give people round about 72 (?) hours to rebuild their EPEL5 packages >> manually on their own (in case they want to do it themselves). >> Everything that didn't get rebuild gets a ".1" added to release in cvs; >> that change gets committed, tagged and build -- we afaik have a script >> that should be able to do that and I can take care of running it if >> that's okay for everyone. >> >> Does that sounds sane to everyone? >> >> CU >> thl >> >> P.S.:here is the relevant part from the FESCo meeting: >> >> 19:42 --- | bpepple has changed the topic to: FESCO-Meeting >> -- EPEL >> 19:42 < bpepple> | anything in regard to EPEL need to be discussed? >> 19:42 < jwb> | yes >> 19:42 * | thl send some notes from this week to the list >> 19:43 < thl> | one hour or so ago >> 19:43 < tibbs> | notting: If you do have any ideas about that, >> please let us know. >> 19:43 < jwb> | there was the buildroot issue Axel wanted acked >> by FESCo >> 19:43 < notting> | tibbs: get out baseball bats and beat upstream? :) >> 19:43 * | bpepple hasn't had a chance to read his e-mail >> today. :( >> 19:44 < thl> | bpepple, it's about the "mass-rebuild of EPEL5 >> now that we soon have RHEL5 final on the builders" >> 19:44 < thl> | bpepple, it was voted to delete everything and >> just rebuild >> 19:44 < bpepple> | thl: ok. >> 19:44 < jwb> | -1 >> 19:44 < thl> | everything, without chaning ENVR >> 19:44 < f13> | er.. >> 19:44 < jwb> | yeah, -1 >> 19:44 < f13> | that may not bode well for clients whom already >> ahve stuff installed >> 19:45 < nirik> | (note: only EPEL-5... not 4) >> 19:45 < thl> | f13, tell those that voted like that >> 19:45 < f13> | as noted many times before, packages changing >> checksums and such get messy >> 19:45 < jwb> | f13, it was noted in their discussion. >> apparently it didn't seem that big of a deal >> 19:45 * | thl disliked that plan, too >> 19:45 < jwb> | are we voting on this yet? >> 19:45 < f13> | *shrug* I don't run rhel5 so I won't get >> effected by it. >> 19:45 < jwb> | f13, more than rhel5 >> 19:45 < bpepple> | jwb: Yeah, we should do a quick vote. >> 19:46 < tibbs> | I'm still not understanding why you wouldn't want >> to bump, and I read the IRC logs. >> 19:46 < jwb> | tibbs, me either >> 19:46 < dgilmore> | tibbs: becaue people did not want to fork the spec >> 19:46 < jwb> | that is just lazy >> 19:46 < thl> | jwb, +1 >> 19:46 < jwb> | you're pissing on your users because you don't >> want to make a 2 character change >> 19:46 < dgilmore> | i wanted to add a .1 and rebuild >> 19:46 < tibbs> | Ah, that is a point, but I don't think it's a >> terribly good point. >> 19:46 < jwb> | dgilmore, that would be very acceptable >> 19:46 < c4chris> | yea, .1 and rebuild >> 19:46 < rdieter> | dgilmore: +1 >> 19:46 < tibbs> | The spec will diverge pretty much immediately anyway. >> 19:47 < jwb> | right >> 19:47 < thl> | dgilmore, why did you vote for deleting the >> packges then? >> 19:47 * | thl is confused >> 19:47 < notting> | ? you don't need to fork the spec. just b/c the >> release changes, doesn't mean you have to build and push for older releases >> 19:47 < jwb> | notting, fork it vs. the fedora spec >> 19:47 <-- | sankarshan has quit (Connection timed out) >> 19:47 < f13> | notting: er, they have to bump the spec there, >> but nowhere else, so now the specs are diverged >> 19:48 < notting> | *horrors* >> 19:48 < tibbs> | As I understand things, EPEL has no reason to >> attempt to keep any kind of release ordering with Fedora. >> 19:48 < dgilmore> | thl: i was confused by then. >> 19:48 < f13> | not that I find anything _wrong_ with that. >> 19:48 < tibbs> | So it's not even appending ".1"; just bump the >> release. >> 19:48 < f13> | nod >> 19:48 < thl> | dgilmore, np, I was just confused now >> 19:48 < notting> | thl: well, two issues. i'd be all for 'rebuild >> and delete all old packages', but with a release bump >> 19:48 < thl> | tibbs, some people prefer to appending ".1" ovefr >> bumpin the release >> 19:48 < f13> | is there a call for fesco vote? >> 19:48 < thl> | I think they have a point >> 19:49 < jwb> | f13, axel requested one >> 19:49 < f13> | or a point 1 >> 19:49 < f13> | (: >> 19:49 < thl> | notting, sounds fine for me >> 19:49 < c4chris> | :-) >> 19:49 < tibbs> | OTOH, not rebuilding at all seems to be working >> for Fedora at this point. What's the reason they absolutely must be >> rebuilt? >> 19:49 < abadger1999> | tibbs: If they want to use the vanilla spec >> later, using .1 lets them come back on the next Fedora Release rather >> than the next upstream bump >> 19:49 < nirik> | tibbs: they were build against beta1 >> 19:49 < tibbs> | abadger1999: Extremely good point. >> 19:49 < f13> | abadger1999: but that actually overwrites history >> 19:50 < f13> | unless they merge that .1 somewhere into the >> history of hte FEdora spec >> 19:50 < nirik> | abadger1999: yeah, changelog is lost then if you >> merge >> 19:50 < tibbs> | nirik: And we have .fc6 packages in F7; surely F7 >> diverges from FC6 more than rhel5b1 diverges from rhel5release. >> 19:50 < thl> | f13, is that really a big problem if it was just >> a "rebuild" in the chanelog? >> 19:50 < notting> | dgilmore, this is only rebuilding things actually >> built for EPEL, not everything in EPEL cvs, right? >> 19:50 < thl> | notting, yes, only what has been build up to now >> 19:51 < f13> | thl: it's not a really big problem, but I >> generally don't like to see history get stomped >> 19:51 < nirik> | tibbs: yeah, you would think so... dunno for sure. >> 19:51 < thl> | f13, agreed; I think in this case it's still not >> nice, but acceptable >> 19:51 < f13> | and who k nows what happens with the rebuild, >> something may end up needing changed to build again against RHEL5 GA >> 19:51 < f13> | tibbs: you'd be surprised what all changed from >> B1 to GOLD >> 19:52 * | rdieter thinks we're not here to (re)make epel's >> decision for them (or not?), just ack or nack it. >> 19:52 < f13> | -1 >> 19:52 < f13> | (for their current plan) >> 19:52 < jwb> | -1 >> 19:52 < c4chris> | (plan == rebuild and no bump, right) >> 19:52 < jwb> | rdieter, but we can nack with a suggested improvement >> 19:52 < thl> | c4chris, yes >> 19:52 < f13> | c4chris: yep >> 19:53 < bpepple> | c4chris: correct. >> 19:53 < c4chris> | k, -1 then >> 19:53 < notting> | -1 >> 19:53 < bpepple> | -1 here also. >> 19:53 < tibbs> | Yeah, I hate to be an obstruction, but -1 to >> rebuilding with no bump. >> 19:53 < abadger1999> | -1 >> 19:53 < thl> | jwb, I can take care of that if you want; i was >> against this in any case ;-) >> 19:53 < bpepple> | so it looks like we against EPEL suggested plan. >> 19:53 < jwb> | thl, great >> 19:54 <-- | gregdek has quit (Read error: 104 (Connection >> reset by peer)) >> 19:54 < thl> | bpepple, I'll get that out to epel and will take >> care of it >> 19:54 < dgilmore> | notting: yeah just whats built >> 19:54 < bpepple> | thl: great, thanks. >> >> _______________________________________________ >> epel-devel-list mailing list >> epel-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/epel-devel-list >> > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From sheltren at cs.ucsb.edu Sat Apr 14 10:47:08 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 14 Apr 2007 06:47:08 -0400 Subject: Revisiting the mass rebuild plans for EPEL5 In-Reply-To: <461FD347.7040007@leemhuis.info> References: <461E79D1.70401@leemhuis.info> <7874d9dd0704121256l7e2e2933g427b4983f4effed3@mail.gmail.com> <461FD347.7040007@leemhuis.info> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 13, 2007, at 3:00 PM, Thorsten Leemhuis wrote: > Michael Stahnke schrieb: >> Yes, this is fine from my point of view. > > k; other opinions? +1 - -Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGILEsKe7MLJjUbNMRArTDAJoDFwoQHh6tnIxPnML05QKEMnbtrwCePB0k 49ic08znUmFRW8K3jSntTrM= =Aw/C -----END PGP SIGNATURE----- From Axel.Thimm at ATrpms.net Sat Apr 14 11:17:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 14 Apr 2007 13:17:11 +0200 Subject: Relationship to existing 3rd party repos/CentOS/SL? Message-ID: <20070414111711.GA25962@neu.nirvana> Hi, the voting/decision on repotags was labeled as being 99% a political one, and no one objected against that old statement. Does the outcome of EPEL not carrying repotags mean that there is no interest in cooperation with 3rd party repos? I'm not after answers on pseudo-technical details, so consider the above question as rhetorical, instead let me rephrase completely outside the scope of repotags: What is EPEL's intended relation to the existing third party repos? * Will it jump in the game ignoring that 3rd party repos exist and let Darwinism prevail? * Will it try to work together with these repos? If yes, in what concrete way? * Does EPEL consider itself at the same level as these repos, or does it place itself higher, pushing any compatibility issues to the workload of these repos? The Fedora/3rd party rift created several years ago is still in the healing process, I think everyone agrees in retrospect that it wasn't neccessary and we'd be better off not to allow it to happen in the first place. But I see the danger of this history pattern to repeat itself, and standing with one feet in a 3rd party repo and another in EPEL I'm in conflict with myself right now, so I'd like us to clarify this. -- 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 Sat Apr 14 11:19:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 14 Apr 2007 13:19:38 +0200 Subject: Revisiting the mass rebuild plans for EPEL5 In-Reply-To: <461E79D1.70401@leemhuis.info> References: <461E79D1.70401@leemhuis.info> Message-ID: <20070414111938.GB25962@neu.nirvana> On Thu, Apr 12, 2007 at 08:26:25PM +0200, Thorsten Leemhuis wrote: > FESCo today nacked the rebuild plan from voting "1" in > https://www.redhat.com/archives/epel-devel-list/2007-April/msg00055.html > See the end of this mail for details. In short: FESCo afaics didn't like > to leave release unchanged. Did you mention that adding the repotag, which we nacked would solve this issue completely (no forks, and still proper upgrade paths for all packages)? Maybe they would ack our nack ... -- 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 sheltren at cs.ucsb.edu Sat Apr 14 14:11:26 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 14 Apr 2007 10:11:26 -0400 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <20070414111711.GA25962@neu.nirvana> References: <20070414111711.GA25962@neu.nirvana> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 14, 2007, at 7:17 AM, Axel Thimm wrote: > Hi, > > the voting/decision on repotags was labeled as being 99% a political > one, and no one objected against that old statement. Does the outcome > of EPEL not carrying repotags mean that there is no interest in > cooperation with 3rd party repos? > > I'm not after answers on pseudo-technical details, so consider the > above question as rhetorical, instead let me rephrase completely > outside the scope of repotags: > > What is EPEL's intended relation to the existing third party repos? > > * Will it jump in the game ignoring that 3rd party repos exist and > let Darwinism prevail? > * Will it try to work together with these repos? If yes, in what > concrete way? > * Does EPEL consider itself at the same level as these repos, or does > it place itself higher, pushing any compatibility issues to the > workload of these repos? > > The Fedora/3rd party rift created several years ago is still in the > healing process, I think everyone agrees in retrospect that it wasn't > neccessary and we'd be better off not to allow it to happen in the > first place. > > But I see the danger of this history pattern to repeat itself, and > standing with one feet in a 3rd party repo and another in EPEL I'm in > conflict with myself right now, so I'd like us to clarify this. > -- > Axel.Thimm at ATrpms.net > Hi Axel, I'm a bit confused about which statement you are referring to in your first sentence, could you please clarify for me? I'm glad that you brought up this subject directly as I feel it does need to be addressed. In your questions, are you referring to all possible "3rd party" repos, or only to a few of the biggest ones - if so, which are considered big enough to be considered? In my opinion it is difficult at best to enable multiple repos on a single machine. Too many variables come into play that could wreak havoc on a system. This is not meant to be a jab at the packages/ packagers for these repos, but simply a fact that if they don't work with some very strict rules about what is packaged and how it is packaged then people can end up with very strange results. Clearly there are circumstances when a package included in multiple repos could be upgraded in one at which point a system using the package from "repo A" is suddenly upgraded to a package from "repo B" with perhaps unintended/bad results. Repo tags, etc. aside, how is it decided which repo can carry which packages? What if a package that "repo A" wants to include has a dependency in "repo B"? What if the maintainer of a "3rd party" repo suddenly looses interest or ability to maintain the repo and it goes away? It seems it would be a full time job for a group of people to work out all these possibilities and create/enforce rules to try to prevent bad things from happening to unknowing users. Again, this is only my opinion, but I feel that one good solution is to merge all these external repos as much as possible much as Fedora Extras as done, and EPEL seems to be doing. "3rd party" repo packagers should be encouraged to submit their packages to EPEL so that users can easily access a large number of wanted/needed packages without having to enable separate repos and worry each time that something may conflict, etc. It seems to me that pushing towards one "super repo" ala EPEL ends up with much less overhead and work than trying to make a lot of rules, etc. for all the repos to follow (and argue about). I don't think this means that "3rd party" repos are any less important, but perhaps they should be used more for specialized packages and things that Fedora/RedHat is not legally willing/able to provide. This does not mean I'm saying EPEL is "on a higher level", but I think that there needs to be one central repo which can provide the majority of packages that people want to install. Axel, I would also be interested to know what your thoughts are on the questions you posed to the list. How would you like to see EPEL and other repos interact (if at all)? - -Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGIOEOKe7MLJjUbNMRAjziAJ9EeFyeBxUXNnfuEK0KAR0tjBupXQCgm6t4 8mtvOaTH9PTTLeZOlUoEDOU= =ugR4 -----END PGP SIGNATURE----- From Axel.Thimm at ATrpms.net Sat Apr 14 14:21:52 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 14 Apr 2007 16:21:52 +0200 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: References: <20070414111711.GA25962@neu.nirvana> Message-ID: <20070414142152.GL25962@neu.nirvana> On Sat, Apr 14, 2007 at 10:11:26AM -0400, Jeff Sheltren wrote: > On Apr 14, 2007, at 7:17 AM, Axel Thimm wrote: > > the voting/decision on repotags was labeled as being 99% a political > > one, and no one objected against that old statement. Does the outcome > > of EPEL not carrying repotags mean that there is no interest in > > cooperation with 3rd party repos? > > > > I'm not after answers on pseudo-technical details, so consider the > > above question as rhetorical, instead let me rephrase completely > > outside the scope of repotags: > > > > What is EPEL's intended relation to the existing third party repos? > Hi Axel, I'm a bit confused about which statement you are referring > to in your first sentence, could you please clarify for me? That voting about repotags is a 99% political decision of playing nice with other 3rd party repos. The remaining 1% was shared between confusion between RHEL and EPEL packages and technical implementation. > I'm glad that you brought up this subject directly as I feel it does > need to be addressed. In your questions, are you referring to all > possible "3rd party" repos, or only to a few of the biggest ones - if > so, which are considered big enough to be considered? I'm a fair player, I'm not casting away small or new repos. This sounds like you're running one yourself, which one is it? > In my opinion it is difficult at best to enable multiple repos on a > single machine. Which is due to lack of coordination of these repos. > Axel, I would also be interested to know what your thoughts are on > the questions you posed to the list. How would you like to see EPEL > and other repos interact (if at all)? Well, I'm one of the few that voted in favour of EPEL playing nice with other repos, so I'm interested in a healthy two-way interaction. -- 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 sheltren at cs.ucsb.edu Sat Apr 14 15:06:32 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 14 Apr 2007 11:06:32 -0400 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <20070414142152.GL25962@neu.nirvana> References: <20070414111711.GA25962@neu.nirvana> <20070414142152.GL25962@neu.nirvana> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 14, 2007, at 10:21 AM, Axel Thimm wrote: > On Sat, Apr 14, 2007 at 10:11:26AM -0400, Jeff Sheltren wrote: > >> Hi Axel, I'm a bit confused about which statement you are referring >> to in your first sentence, could you please clarify for me? > > That voting about repotags is a 99% political decision of playing nice > with other 3rd party repos. The remaining 1% was shared between > confusion between RHEL and EPEL packages and technical implementation. > >> I'm glad that you brought up this subject directly as I feel it does >> need to be addressed. In your questions, are you referring to all >> possible "3rd party" repos, or only to a few of the biggest ones - if >> so, which are considered big enough to be considered? > > I'm a fair player, I'm not casting away small or new repos. This > sounds like you're running one yourself, which one is it? > >> In my opinion it is difficult at best to enable multiple repos on a >> single machine. > > Which is due to lack of coordination of these repos. > >> Axel, I would also be interested to know what your thoughts are on >> the questions you posed to the list. How would you like to see EPEL >> and other repos interact (if at all)? > > Well, I'm one of the few that voted in favour of EPEL playing nice > with other repos, so I'm interested in a healthy two-way interaction. No, I'm not running anything other than private local repos packages which I need to customize, etc. A lot of that is stuff that I hopefully won't have to do once EPEL is up and running. The point I was trying to make is, there is the possibility of having many small repos floating around - and if we're trying to look out for everyone's interests, as you are implying we should, then they should certainly be considered as well. I'm all for playing nice with other repos, but I still believe that trying to work out all the technical and political issues is far more trouble than it is worth. There seem to be so many issues that need rules/guidelines that we would be spending all our time voting/ debating and be left with no time for actually creating packages. - -Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGIO34Ke7MLJjUbNMRAgkzAKDK40+NBZ85gMSH+CAf13dy5lr1+ACfdvs+ NjNu17OFLRB5ILXsy5Xi6Y8= =sikZ -----END PGP SIGNATURE----- From rdieter at math.unl.edu Sat Apr 14 15:42:45 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 14 Apr 2007 10:42:45 -0500 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: References: <20070414111711.GA25962@neu.nirvana> <20070414142152.GL25962@neu.nirvana> Message-ID: <4620F675.8060607@math.unl.edu> Jeff Sheltren wrote: > I'm all for playing nice with other repos, but I still believe that > trying to work out all the technical and political issues is far more > trouble than it is worth. Jeff, I think I know where you're coming from, but you simply can't have it both ways. One either plays nice or not. Frankly, if someone feels that they don't think it important to play nice (and do the right thing, imo), I would rather they not be involved in this project. -- Rex From sheltren at cs.ucsb.edu Sat Apr 14 15:40:26 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 14 Apr 2007 11:40:26 -0400 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <4620F675.8060607@math.unl.edu> References: <20070414111711.GA25962@neu.nirvana> <20070414142152.GL25962@neu.nirvana> <4620F675.8060607@math.unl.edu> Message-ID: <3EEDEBF0-C35A-44CC-BD09-EF7651CC436B@cs.ucsb.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 14, 2007, at 11:42 AM, Rex Dieter wrote: > Jeff Sheltren wrote: > >> I'm all for playing nice with other repos, but I still believe that >> trying to work out all the technical and political issues is far more >> trouble than it is worth. > > Jeff, I think I know where you're coming from, but you simply can't > have > it both ways. One either plays nice or not. > > Frankly, if someone feels that they don't think it important to play > nice (and do the right thing, imo), I would rather they not be > involved > in this project. > > -- Rex Hi Rex, I'm confused if you are suggesting you'd rather I'd not be involved in EPEL because of my above statement? That seems rather blunt and unnecessary. The point I am trying to make is that it may be possible to write down a few guidelines on how repos should get along together but after all that is done, the amount of work to actually enforce all repos to follow those rules/guidelines will be near impossible. Maybe I am blowing this out of proportion. Has someone proposed a set of guidelines for repos to follow that you feel would be somewhat easy to enforce? - -Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGIPXrKe7MLJjUbNMRAuhPAJ94IPwJg5XJj39ZeYso0qudzhKGfgCgyXGV SKfdmM/f95+AgOyLXKrH3bQ= =42vF -----END PGP SIGNATURE----- From rdieter at math.unl.edu Sat Apr 14 16:12:38 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 14 Apr 2007 11:12:38 -0500 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <3EEDEBF0-C35A-44CC-BD09-EF7651CC436B@cs.ucsb.edu> References: <20070414111711.GA25962@neu.nirvana> <20070414142152.GL25962@neu.nirvana> <4620F675.8060607@math.unl.edu> <3EEDEBF0-C35A-44CC-BD09-EF7651CC436B@cs.ucsb.edu> Message-ID: <4620FD76.4070203@math.unl.edu> Jeff Sheltren wrote: > On Apr 14, 2007, at 11:42 AM, Rex Dieter wrote: >> Frankly, if someone feels that they don't think it important to play >> nice (and do the right thing, imo), I would rather they not be involved >> in this project. > That seems rather blunt and unnecessary. Blunt, yes. Necessary, I think so. For me personally anyway, this is very important for project relations. > Hi Rex, I'm confused if you are suggesting you'd rather I'd not be > involved in EPEL because of my above statement? ... > Maybe I am blowing this out of proportion. I think so, and certainly not my intention to imply anything against you personally. Please stay. :) > Has someone proposed a set > of guidelines for repos to follow that you feel would be somewhat easy > to enforce? No one is suggesting red-tape, rules, regulations, enforcement (I hope not, anyway). I'd argue public/stated intentions/goals (to play nice) and a best effort to follow through on said intentions is wholly sufficient. -- Rex From mastahnke at gmail.com Sat Apr 14 15:54:56 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Sat, 14 Apr 2007 10:54:56 -0500 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <4620FD76.4070203@math.unl.edu> References: <20070414111711.GA25962@neu.nirvana> <20070414142152.GL25962@neu.nirvana> <4620F675.8060607@math.unl.edu> <3EEDEBF0-C35A-44CC-BD09-EF7651CC436B@cs.ucsb.edu> <4620FD76.4070203@math.unl.edu> Message-ID: <7874d9dd0704140854i7977c069o2d2b4b7b715def6b@mail.gmail.com> On 4/14/07, Rex Dieter wrote: > Jeff Sheltren wrote: > > On Apr 14, 2007, at 11:42 AM, Rex Dieter wrote: > > >> Frankly, if someone feels that they don't think it important to play > >> nice (and do the right thing, imo), I would rather they not be involved > >> in this project. > > > That seems rather blunt and unnecessary. > > Blunt, yes. Necessary, I think so. For me personally anyway, this is > very important for project relations. > > > Hi Rex, I'm confused if you are suggesting you'd rather I'd not be > > involved in EPEL because of my above statement? > ... > > Maybe I am blowing this out of proportion. > > I think so, and certainly not my intention to imply anything against you > personally. Please stay. :) > > > Has someone proposed a set > > of guidelines for repos to follow that you feel would be somewhat easy > > to enforce? > > No one is suggesting red-tape, rules, regulations, enforcement (I hope > not, anyway). I'd argue public/stated intentions/goals (to play nice) > and a best effort to follow through on said intentions is wholly sufficient. > > -- Rex > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > >From my perspecitive, and from my company's prospective, EPEL is going to be a very nice thing. Today (my team) we grab packages for RHEL from several big third party repos and then recompile them ourselves. The main reason is, we don't know what type of QA/Testing/Packaging Guidelines have been applied.[1] There have been several src.rpm packages over the years that we grabbed from one repo and gave up on becuase of odd macros, strange dependencies, or replacing a core package from RHEL. With EPEL, I am quite sure that won't happen. Also, the QA process is understood and recognized. I admit it isn't the greatest QA process, and leaves room for improvement, but at least it is understood, and "trusted" by companies who realize that RHEL is spawned from Fedora. This isn't a knock on other 3rd party repos, I like them a lot, and they have done a bunch for the open source community. I guess I feel that if the package can be part of EPEL, it should. It will make life easier for the EL consumer, and that's who I want to please, EL customers who need packages traditionally not available in EL. I would love 3rd party repos to continue to carry newer packages, kernel modules and those fun non-US-legal packages. I do think working *with* the owners of these repos is critical. I want their expertise. I want their years of knowledge and point of view. (I also voted for the repo tag becuase EPEL isn't the only game in town). So, Axel brings up some very good questions about how EPEL can and will interact with 3rd party repos. Could the Fedora permissable packages move to EPEL without a political battle? I have no idea. Could the major 3rd party repos become very compatible with EPEL? I hope so. stahnma [1]Someone could quickly argue that I/my team should have looked into the QA/build processes of these 3rd party repos, understood them, joined mailing lists, etc. And, it's a valid argument, but it didn't happen. One package we needed was from one repo, another from another and so on. From fedora at leemhuis.info Sat Apr 14 16:38:36 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 14 Apr 2007 18:38:36 +0200 Subject: Revisiting the mass rebuild plans for EPEL5 In-Reply-To: <20070414111938.GB25962@neu.nirvana> References: <461E79D1.70401@leemhuis.info> <20070414111938.GB25962@neu.nirvana> Message-ID: <4621038C.4080302@leemhuis.info> Axel Thimm schrieb: > On Thu, Apr 12, 2007 at 08:26:25PM +0200, Thorsten Leemhuis wrote: >> FESCo today nacked the rebuild plan from voting "1" in >> https://www.redhat.com/archives/epel-devel-list/2007-April/msg00055.html >> See the end of this mail for details. In short: FESCo afaics didn't like >> to leave release unchanged. > Did you mention that adding the repotag, which we nacked would solve > this issue completely (no forks, and still proper upgrade paths for > all packages)? Maybe they would ack our nack ... No, I didn't mention it. See the log that I attached and the mail I send to fedora-maintainers. CU thl From mmcgrath at redhat.com Sat Apr 14 16:49:17 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 14 Apr 2007 11:49:17 -0500 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <20070414111711.GA25962@neu.nirvana> References: <20070414111711.GA25962@neu.nirvana> Message-ID: <4621060D.3010306@redhat.com> Axel Thimm wrote: > Hi, You brought it up, didn't convince us, we voted it's done, get over it. -Mike From fedora at leemhuis.info Sat Apr 14 17:16:07 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 14 Apr 2007 19:16:07 +0200 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <20070414111711.GA25962@neu.nirvana> References: <20070414111711.GA25962@neu.nirvana> Message-ID: <46210C57.4030004@leemhuis.info> Just some random thoughts from me here; I didn't want to reply on Axels statements directly as I feared that it tracks the discussion and my answers into a direction I don't want them. My view on the whole thing: - I don't see my vote on the repotag decision as a political one. Different repos IMHO make different decisions how to "solve" technical problems. - On relationship to 3rd party repos in general: cooperation is good, but mixing different repos can lead to problems as we know. I'd say we should try to sort them out if that's possible easily and when we get aware of them; hard cases need to be decided on a case by case basis. - On relationship with rpmforge in special: EPEL serves a different goal than rpmforge afaics. I think those two can exists side by side. EPEL takes the more careful approach and doesn't replace packages from the base; packages in EPEL will normally not be updated that often to the latest and greatest (similar to RHEL). rpmforge on the other hand has more newer packages and replaces packages from the base. There are users out there for both approaches, so I think both can side by side and users can choose what they want. - there might probably be 3rd part repos that stack on top of EPEL. Nobody will be forced to cooperating with them, but if contributors want, why not. But we can't force our contributors to cooperate with external parties that ship software that might be illegal in the place where the contributor lives. - Some contributors might act in multiple repos; those are the best ones that can act as middle man. Please let's not make this a repowar; this discussion could easily start one (the repotag discussion was bad enough already). Thanks. CU thl From Axel.Thimm at ATrpms.net Sat Apr 14 17:21:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 14 Apr 2007 19:21:11 +0200 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <46210C57.4030004@leemhuis.info> References: <20070414111711.GA25962@neu.nirvana> <46210C57.4030004@leemhuis.info> Message-ID: <20070414172111.GQ25962@neu.nirvana> > What is EPEL's intended relation to the existing third party repos? > > * Will it jump in the game ignoring that 3rd party repos exist and > let Darwinism prevail? > * Will it try to work together with these repos? If yes, in what > concrete way? > * Does EPEL consider itself at the same level as these repos, or does > it place itself higher, pushing any compatibility issues to the > workload of these repos? > On Sat, Apr 14, 2007 at 07:16:07PM +0200, Thorsten Leemhuis wrote: > Just some random thoughts from me here; I didn't want to reply on Axels > statements directly as I feared that it tracks the discussion and my > answers into a direction I don't want them. > > My view on the whole thing: The questions are simple to answer, why evade them? > Please let's not make this a repowar; this discussion could easily start > one (the repotag discussion was bad enough already). Thanks. We need to clarify things and agendas, both internally and externally. -- 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 Sat Apr 14 17:25:34 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 14 Apr 2007 19:25:34 +0200 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <4621060D.3010306@redhat.com> References: <20070414111711.GA25962@neu.nirvana> <4621060D.3010306@redhat.com> Message-ID: <20070414172534.GR25962@neu.nirvana> On Sat, Apr 14, 2007 at 11:49:17AM -0500, Mike McGrath wrote: > Axel Thimm wrote: > > What is EPEL's intended relation to the existing third party repos? > > > > * Will it jump in the game ignoring that 3rd party repos exist and > > let Darwinism prevail? > > * Will it try to work together with these repos? If yes, in what > > concrete way? > > * Does EPEL consider itself at the same level as these repos, or does > > it place itself higher, pushing any compatibility issues to the > > workload of these repos? > You brought it up, didn't convince us, we voted it's done, get over it. What you are implying, is that your voting was effectively shooting down cooperation and coexistance with other 3rd parties. I'm sure other people that voted like you have a different interpretation of their vote, at least I hope so. But at the very least this requires the clarification I asked for. Did the other 4 people that voted against it also vote against working with other repos? If so, then you are right, and it takes me a while to understand it and get over it. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Sat Apr 14 17:29:18 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 14 Apr 2007 12:29:18 -0500 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <20070414172111.GQ25962@neu.nirvana> References: <20070414111711.GA25962@neu.nirvana> <46210C57.4030004@leemhuis.info> <20070414172111.GQ25962@neu.nirvana> Message-ID: <46210F6E.1070008@redhat.com> Axel Thimm wrote: > > We need to clarify things and agendas, both internally and externally. > But we need to be careful to respect each others autonomy. Working together, to me, doesn't mean that I'll continue to spout off about something that atrpms.net does against my will. Also, this entire thread was started with you claiming we (and myself) voted politically. I take offense at that. Trying to guess someones motives based off of their actions is a fallacy. If you think I voted against the repo tag for any other reason then technical you are just plain wrong. -Mike From mmcgrath at redhat.com Sat Apr 14 17:36:07 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 14 Apr 2007 12:36:07 -0500 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <20070414172534.GR25962@neu.nirvana> References: <20070414111711.GA25962@neu.nirvana> <4621060D.3010306@redhat.com> <20070414172534.GR25962@neu.nirvana> Message-ID: <46211107.9070909@redhat.com> Axel Thimm wrote: > What you are implying, is that your voting was effectively shooting > down cooperation and coexistance with other 3rd parties. I'm sure > other people that voted like you have a different interpretation of > their vote, at least I hope so. > > But at the very least this requires the clarification I asked for. Did > the other 4 people that voted against it also vote against working > with other repos? If so, then you are right, and it takes me a while > to understand it and get over it. > Fact: we voted against having it. Fact: you guys continue to use it (did you vote on it?) Guess: If we asked you guys to get rid of the Repo tag in corporation with us, you'd probably say no. Fact: We haven't asked you to remove the repo tag, we respect the decision making process that you used to use a repo tag but we came to a different conclusion for EPEL. Fact: the sky isn't falling. If you have another problem, bring it to us and don't assume we'll be against you. Obviously I can't speak for everyone but I take every decision seriously and based on its merit. You're assuming this is just the start of EPEL completely ignoring 3rd party repos and it's just not. I will say the tone of the email that started this thread is not one of corporation, it's one of flame baiting and instigation, knock it off. -Mike From Axel.Thimm at ATrpms.net Sat Apr 14 17:36:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 14 Apr 2007 19:36:38 +0200 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <46210F6E.1070008@redhat.com> References: <20070414111711.GA25962@neu.nirvana> <46210C57.4030004@leemhuis.info> <20070414172111.GQ25962@neu.nirvana> <46210F6E.1070008@redhat.com> Message-ID: <20070414173638.GS25962@neu.nirvana> On Sat, Apr 14, 2007 at 12:29:18PM -0500, Mike McGrath wrote: > Axel Thimm wrote: > > > >We need to clarify things and agendas, both internally and externally. > > > > But we need to be careful to respect each others autonomy. Working > together, to me, doesn't mean that I'll continue to spout off about > something that atrpms.net does against my will. No one asked you to do anything remotely to that. Every project reserves its right to do something against your will, and you reserve the right to whine about it ;) > Also, this entire thread was started with you claiming we (and myself) > voted politically. I take offense at that. Trying to guess someones > motives based off of their actions is a fallacy. If you think I voted > against the repo tag for any other reason then technical you are just > plain wrong. So when I tagged this decision as being 99% political for several weeks now and even wrote that in the wiki two lines over your actual voting you just didn't pay attention or completely ignored me? Now, who should be rightfully taking offense now? ;) Also it was outlined in several threads on this list and fedora-packaging that the introduction of repotags would not serve any technical benefits (although at the end it turns out that it nicely solves the rebuild problem), so how can you even vote on it with only technical reasons? -- 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 Sat Apr 14 17:45:24 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 14 Apr 2007 19:45:24 +0200 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <46211107.9070909@redhat.com> References: <20070414111711.GA25962@neu.nirvana> <4621060D.3010306@redhat.com> <20070414172534.GR25962@neu.nirvana> <46211107.9070909@redhat.com> Message-ID: <20070414174524.GT25962@neu.nirvana> On Sat, Apr 14, 2007 at 12:36:07PM -0500, Mike McGrath wrote: > Axel Thimm wrote: > >What you are implying, is that your voting was effectively shooting > >down cooperation and coexistance with other 3rd parties. I'm sure > >other people that voted like you have a different interpretation of > >their vote, at least I hope so. > > > >But at the very least this requires the clarification I asked for. Did > >the other 4 people that voted against it also vote against working > >with other repos? If so, then you are right, and it takes me a while > >to understand it and get over it. > > > Fact: we voted against having it. > Fact: you guys continue to use it (did you vote on it?) Fact: The repotag only makes sense cross-repo, and repos using it was because they wanted to 1) keep the package easily identified 2) not place themselves higher in any hierarchy > Guess: If we asked you guys to get rid of the Repo tag in corporation > with us, you'd probably say no. Fact: The moment one repo starts dropping it, it doesn't matter anymore, the system has gone bananas. > Fact: We haven't asked you to remove the repo tag, we respect the > decision making process that you used to use a repo tag but we came to a > different conclusion for EPEL. > > Fact: the sky isn't falling. OK, so back to the real questions I asked about general cooperation and coexitance. Although I said I didn't want to talk about the repotag you get back to it. > If you have another problem, bring it to us and don't assume we'll be > against you. Obviously I can't speak for everyone but I take every > decision seriously and based on its merit. You're assuming this is just > the start of EPEL completely ignoring 3rd party repos and it's just > not. Indeed, that is the suspicion that lies behind it. Several 3rd party repo maintainers vouched for EPEL to carry a repotag and it was a pure political thing to do. You can't hide behind technicalities when such a call is being made. Not to mention that a repotag would even have technical benefits, which was not what it was about at all. > I will say the tone of the email that started this thread is not one > of corporation, it's one of flame baiting and instigation, knock it > off. Just check the tone of your very own mail, you're chopping off all quoting, but a "Hi," and tell people to "get over it", "knock it off", you "take offense" and call other people's post as "flame baiting and instigation". -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Sat Apr 14 18:53:59 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 14 Apr 2007 13:53:59 -0500 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <20070414173638.GS25962@neu.nirvana> References: <20070414111711.GA25962@neu.nirvana> <46210C57.4030004@leemhuis.info> <20070414172111.GQ25962@neu.nirvana> <46210F6E.1070008@redhat.com> <20070414173638.GS25962@neu.nirvana> Message-ID: <46212347.10606@math.unl.edu> Axel Thimm wrote: > so how can you even vote on it with only technical reasons? Perhaps some folks consider that "without technical merit" is justification enough not to support repotags. -- Rex From buildsys at fedoraproject.org Sun Apr 15 03:38:21 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 14 Apr 2007 23:38:21 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-04-14 Message-ID: <20070415033821.83948152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 2 NEW moin-1.5.7-1.el5 NEW tiobench-0.3.3-5.el5 Packages built and released for Fedora EPEL 4: 1 tiobench-0.3.3-5.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From bjohnson at symerix.com Sat Apr 14 16:56:22 2007 From: bjohnson at symerix.com (Bernard Johnson) Date: Sat, 14 Apr 2007 10:56:22 -0600 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <4620F675.8060607@math.unl.edu> References: <20070414111711.GA25962@neu.nirvana> <20070414142152.GL25962@neu.nirvana> <4620F675.8060607@math.unl.edu> Message-ID: <462107B6.8080402@symerix.com> Rex Dieter wrote: > Jeff Sheltren wrote: > >> I'm all for playing nice with other repos, but I still believe that >> trying to work out all the technical and political issues is far more >> trouble than it is worth. >> > > Jeff, I think I know where you're coming from, but you simply can't have > it both ways. One either plays nice or not. > > Frankly, if someone feels that they don't think it important to play > nice (and do the right thing, imo), I would rather they not be involved > in this project. > > Maybe I'm wrong, but I felt that many people, including myself, thought that this was not an EPEL issue but a FPC issue and should be pushed to them instead. I mean really, EPEL is not "Joe's EPEL" it is "Fedora EPEL" and if Fedora as a whole can't/won't adopt this proposal, why should it be our burden? We are simply lower minions of the entire Fedora hierarchy working specifically on EPEL. I think Axel's proposal still has merit, but the right thing is to throw it to FPC. And nothing in the vote says that he can't. In fact, I hope he does. From Axel.Thimm at ATrpms.net Tue Apr 17 12:21:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 17 Apr 2007 14:21:13 +0200 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <462107B6.8080402@symerix.com> References: <20070414111711.GA25962@neu.nirvana> <20070414142152.GL25962@neu.nirvana> <4620F675.8060607@math.unl.edu> <462107B6.8080402@symerix.com> Message-ID: <20070417122113.GQ5695@neu.nirvana> For some reason I only got this mail today, so sorry for the late reply. On Sat, Apr 14, 2007 at 10:56:22AM -0600, Bernard Johnson wrote: > Rex Dieter wrote: > >Jeff Sheltren wrote: > > > >>I'm all for playing nice with other repos, but I still believe that > >>trying to work out all the technical and political issues is far more > >>trouble than it is worth. > >> > > > >Jeff, I think I know where you're coming from, but you simply can't have > >it both ways. One either plays nice or not. > > > >Frankly, if someone feels that they don't think it important to play > >nice (and do the right thing, imo), I would rather they not be involved > >in this project. > > > > > Maybe I'm wrong, but I felt that many people, including myself, thought > that this was not an EPEL issue but a FPC issue and should be pushed to > them instead. > > I mean really, EPEL is not "Joe's EPEL" it is "Fedora EPEL" and if > Fedora as a whole can't/won't adopt this proposal, why should it be our > burden? We are simply lower minions of the entire Fedora hierarchy > working specifically on EPEL. > > I think Axel's proposal still has merit, but the right thing is to throw > it to FPC. And nothing in the vote says that he can't. In fact, I hope > he does. No, I won't, because I don't think that the FPC is the political organ to make the decision to play nice or not, that's either EPEL's or any higher organ's decision, and most of the FPC thinks likewise, and doesn't want to get the old maid passed along. The FPC can help in telling you *how* to do it, or may tell you not to do it due to technical reasons. FWIW the FPC would look quite inclined to simply allow a disttag of .el5.epel or similar, but that's a moot point now. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Apr 17 18:01:15 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Apr 2007 20:01:15 +0200 Subject: Plan for tomorrows EPEL meeting Message-ID: <46250B6B.3060509@leemhuis.info> Hi, I thought it might be a good idea to announce the major topics for tomorrows EPEL meeting beforehand. /topic EPEL Meeting -- RHEL5 on the builders -- dgilmore/mmcgrath /topic EPEL Meeting -- mass rebuild for RHEL5 -- thl /topic EPEL Meeting -- Elect chairmen and discuss responsibilities /topic EPEL Meeting -- Relations to 3rd party distro (?) The next two still need to be discussed on the list, so we'll likely skip this) /topic EPEL Meeting -- Final repolayout -- thl /topic EPEL Meeting -- Communication plan for enterprise customers/ISVs/IHVs -- stahnma, quaid The usual rules apply: if you want to get something discussed send a note and we'll try to visit in the meeting. CU thl P.S.: The schedule in the wiki needs some more love, I'll try to do that over the next week (?) -- this was discussed on the mailing list; we maybe should visit it in the meeting; From fedora at leemhuis.info Tue Apr 17 18:03:54 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Apr 2007 20:03:54 +0200 Subject: Responsibilities of the Steering Committee chairmen (was: Re: Plan for tomorrows EPEL meeting) In-Reply-To: <46250B6B.3060509@leemhuis.info> References: <46250B6B.3060509@leemhuis.info> Message-ID: <46250C0A.4050305@leemhuis.info> Thorsten Leemhuis schrieb: > /topic EPEL Meeting -- Elect chairmen and discuss responsibilities Just to make the meeting a bit easier I'll try to dump the list of responsibilities that a chairmen afaics is responsible for: - prepare the SIG meetings - run the SIG meetings - write the meeting and general "what happened" summaries and send the to the list and FESCo for discussion - report to FESCo, try to be available for questions in FESCo meetings and on the lists - keep the schedule in the wiki up2date - make sure all requests on the mailing lists regarding EPEL feel heard - keeping the pieces together - make sure EPEL is running fine, which to some degree includes "make contributors and users happy" Well, that round about it. Did I miss anything important? Cu thl From sheltren at cs.ucsb.edu Tue Apr 17 19:09:08 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Tue, 17 Apr 2007 15:09:08 -0400 Subject: Plan for tomorrows EPEL meeting In-Reply-To: <46250B6B.3060509@leemhuis.info> References: <46250B6B.3060509@leemhuis.info> Message-ID: On Apr 17, 2007, at 2:01 PM, Thorsten Leemhuis wrote: > Hi, > > I thought it might be a good idea to announce the major topics for > tomorrows EPEL meeting beforehand. > > /topic EPEL Meeting -- RHEL5 on the builders -- dgilmore/mmcgrath > /topic EPEL Meeting -- mass rebuild for RHEL5 -- thl > /topic EPEL Meeting -- Elect chairmen and discuss responsibilities > /topic EPEL Meeting -- Relations to 3rd party distro (?) > > The next two still need to be discussed on the list, so we'll likely > skip this) > > /topic EPEL Meeting -- Final repolayout -- thl > /topic EPEL Meeting -- Communication plan for enterprise > customers/ISVs/IHVs -- stahnma, quaid > > The usual rules apply: if you want to get something discussed send a > note and we'll try to visit in the meeting. > > CU > thl Hi thl, I won't be able to make the meeting tomorrow, so I'll chime in on a couple things FWIW: - mass rebuild -- I'm all for giving maintainers a few days (maybe even a week?) to rebuild their packages once the build systems are ready with RHEL 5 final. After that, bump the release and rebuild automatically for things that haven't been built. - chairman(men?) I think that the responsibilities in your other email seem good. - 3rd party repos -- Like I mentioned before, it is good to work with other repos, but I also feel that EPEL should be pushed as a "central" repo where all those that wish to contribute packages can do so. Users do not need the extra headache of trying to coordinate the packages in multiple repos if it can be avoided. I have something else which I'm not sure has been discussed before, or else I am just blocking it out of my memory :) Yesterday I had EPEL branches created for fortune-mod (how can you run a server without fortunes?), but now I realize that fortune-mod needs recode(- devel), which is part of FE. I do not maintain recode, and I'm not sure that the person who does maintain it would like to do so for EPEL. How can we proceed in cases like this so that I can import my package which has dependencies in FE? -Jeff From mastahnke at gmail.com Tue Apr 17 19:37:05 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 17 Apr 2007 14:37:05 -0500 Subject: Responsibilities of the Steering Committee chairmen (was: Re: Plan for tomorrows EPEL meeting) In-Reply-To: <46250C0A.4050305@leemhuis.info> References: <46250B6B.3060509@leemhuis.info> <46250C0A.4050305@leemhuis.info> Message-ID: <7874d9dd0704171237i34575417q727999cad0b69104@mail.gmail.com> I know we discussed the chairman deciding when we take a vote on an issue. (wiki based voting anyway) Not sure if that was official, or just an idea though. stahnma On 4/17/07, Thorsten Leemhuis wrote: > > > Thorsten Leemhuis schrieb: > > /topic EPEL Meeting -- Elect chairmen and discuss responsibilities > > Just to make the meeting a bit easier I'll try to dump the list of > responsibilities that a chairmen afaics is responsible for: > > - prepare the SIG meetings > - run the SIG meetings > - write the meeting and general "what happened" summaries and send the > to the list and FESCo for discussion > - report to FESCo, try to be available for questions in FESCo meetings > and on the lists > - keep the schedule in the wiki up2date > - make sure all requests on the mailing lists regarding EPEL feel heard > - keeping the pieces together > - make sure EPEL is running fine, which to some degree includes "make > contributors and users happy" > > Well, that round about it. Did I miss anything important? > > Cu > thl > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From mastahnke at gmail.com Wed Apr 18 13:20:54 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 18 Apr 2007 08:20:54 -0500 Subject: Plan for tomorrows EPEL meeting In-Reply-To: References: <46250B6B.3060509@leemhuis.info> Message-ID: <7874d9dd0704180620w752bddebpa106889f79a29630@mail.gmail.com> I probably won't be able to attend. I had a lunch meeting scheduled today that will be difficult to get out of. I will try to attend if I can. I did update the communication plan [1], and spoke briefly with quaid about the plan. A big concern I have is how we plan to get along with the other repos and contributors, both from a governance prospective and from a communication plan prospective. I don't have exact issues thus far, but we have seen a few concerns from major 3rd party repos and downstream contributors. Also, I would like to see the QA and test cycle release process documented. I think this is a major selling point of EPEL to end EL customers. It also probably won't help with my elections for chairperson if I can't make the meeting :) stahnma [1] http://fedoraproject.org/wiki/EPEL/CommunicationPlan On 4/17/07, Jeff Sheltren wrote: > On Apr 17, 2007, at 2:01 PM, Thorsten Leemhuis wrote: > > > Hi, > > > > I thought it might be a good idea to announce the major topics for > > tomorrows EPEL meeting beforehand. > > > > /topic EPEL Meeting -- RHEL5 on the builders -- dgilmore/mmcgrath > > /topic EPEL Meeting -- mass rebuild for RHEL5 -- thl > > /topic EPEL Meeting -- Elect chairmen and discuss responsibilities > > /topic EPEL Meeting -- Relations to 3rd party distro (?) > > > > The next two still need to be discussed on the list, so we'll likely > > skip this) > > > > /topic EPEL Meeting -- Final repolayout -- thl > > /topic EPEL Meeting -- Communication plan for enterprise > > customers/ISVs/IHVs -- stahnma, quaid > > > > The usual rules apply: if you want to get something discussed send a > > note and we'll try to visit in the meeting. > > > > CU > > thl > > Hi thl, I won't be able to make the meeting tomorrow, so I'll chime > in on a couple things FWIW: > > - mass rebuild -- I'm all for giving maintainers a few days (maybe > even a week?) to rebuild their packages once the build systems are > ready with RHEL 5 final. After that, bump the release and rebuild > automatically for things that haven't been built. > > - chairman(men?) I think that the responsibilities in your other > email seem good. > > - 3rd party repos -- Like I mentioned before, it is good to work with > other repos, but I also feel that EPEL should be pushed as a > "central" repo where all those that wish to contribute packages can > do so. Users do not need the extra headache of trying to coordinate > the packages in multiple repos if it can be avoided. > > I have something else which I'm not sure has been discussed before, > or else I am just blocking it out of my memory :) Yesterday I had > EPEL branches created for fortune-mod (how can you run a server > without fortunes?), but now I realize that fortune-mod needs recode(- > devel), which is part of FE. I do not maintain recode, and I'm not > sure that the person who does maintain it would like to do so for > EPEL. How can we proceed in cases like this so that I can import my > package which has dependencies in FE? > > -Jeff > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From fedora at leemhuis.info Wed Apr 18 14:38:19 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 18 Apr 2007 16:38:19 +0200 Subject: Plan for tomorrows EPEL meeting In-Reply-To: References: <46250B6B.3060509@leemhuis.info> Message-ID: <46262D5B.8050101@leemhuis.info> Jeff Sheltren schrieb: > On Apr 17, 2007, at 2:01 PM, Thorsten Leemhuis wrote: >[...] > - mass rebuild -- I'm all for giving maintainers a few days (maybe > even a week?) to rebuild their packages once the build systems are > ready with RHEL 5 final. After that, bump the release and rebuild > automatically for things that haven't been built. Give packagers a chance to rebuild their own stuff was planed -- but I targeted less than a whole week to finally start EPEL5 for real soon. But the exact timeframe should be discussed today in the meeting. >[...] > - 3rd party repos -- Like I mentioned before, it is good to work with > other repos, but I also feel that EPEL should be pushed as a > "central" repo where all those that wish to contribute packages can > do so. Users do not need the extra headache of trying to coordinate > the packages in multiple repos if it can be avoided. I currently think we maybe should put a kind of improved version of https://www.redhat.com/archives/epel-devel-list/2007-April/msg00079.html or something in that direction into the Wiki-FAQ > I have something else which I'm not sure has been discussed before, > or else I am just blocking it out of my memory :) Yesterday I had > EPEL branches created for fortune-mod (how can you run a server > without fortunes?), but now I realize that fortune-mod needs recode(- > devel), which is part of FE. I do not maintain recode, and I'm not > sure that the person who does maintain it would like to do so for > EPEL. How can we proceed in cases like this so that I can import my > package which has dependencies in FE? See http://fedoraproject.org/wiki/EPEL/ContributorStatus and the Section "Questions specific to existing Fedora contributors" on http://fedoraproject.org/wiki/EPEL/FAQ If it's missing something tell me or feel free to improve the wiki yourself. CU thl From Axel.Thimm at ATrpms.net Wed Apr 18 16:57:14 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 18 Apr 2007 18:57:14 +0200 Subject: Responsibilities of the Steering Committee chairmen (was: Re: Plan for tomorrows EPEL meeting) In-Reply-To: <7874d9dd0704171237i34575417q727999cad0b69104@mail.gmail.com> References: <46250B6B.3060509@leemhuis.info> <46250C0A.4050305@leemhuis.info> <7874d9dd0704171237i34575417q727999cad0b69104@mail.gmail.com> Message-ID: <20070418165714.GD8167@neu.nirvana> On Tue, Apr 17, 2007 at 02:37:05PM -0500, Michael Stahnke wrote: > I know we discussed the chairman deciding when we take a vote on an > issue. (wiki based voting anyway) Not sure if that was official, or > just an idea though. That would be an argument against such a dict^W^W^W^Wchairman. In fact shouldn't there actually be a vote first on whether epel actually *needs* a chairman? Only a few weeks ago some people thought epel didn't even need a steering committee. fwiw the fpc has no chairman, at least none of these repsoibilities and powers, the outstanding member of the fpc is spot who runs the meetings, but reports, summaries, vote preparation etc happen in a round-about fashion. > stahnma > > On 4/17/07, Thorsten Leemhuis wrote: > > > > > >Thorsten Leemhuis schrieb: > >> /topic EPEL Meeting -- Elect chairmen and discuss responsibilities > > > >Just to make the meeting a bit easier I'll try to dump the list of > >responsibilities that a chairmen afaics is responsible for: > > > >- prepare the SIG meetings > >- run the SIG meetings > >- write the meeting and general "what happened" summaries and send the > >to the list and FESCo for discussion > >- report to FESCo, try to be available for questions in FESCo meetings > >and on the lists > >- keep the schedule in the wiki up2date > >- make sure all requests on the mailing lists regarding EPEL feel heard > >- keeping the pieces together > >- make sure EPEL is running fine, which to some degree includes "make > >contributors and users happy" > > > >Well, that round about it. Did I miss anything important? > > > >Cu > >thl > > > >_______________________________________________ > >epel-devel-list mailing list > >epel-devel-list at redhat.com > >https://www.redhat.com/mailman/listinfo/epel-devel-list > > > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list -- 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 lists at timj.co.uk Thu Apr 19 11:19:26 2007 From: lists at timj.co.uk (Tim Jackson) Date: Thu, 19 Apr 2007 12:19:26 +0100 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <20070414111711.GA25962@neu.nirvana> References: <20070414111711.GA25962@neu.nirvana> Message-ID: <4627503E.2050507@timj.co.uk> Axel Thimm wrote: > the voting/decision on repotags was labeled as being 99% a political > one, and no one objected against that old statement. I don't think that means you can assume it's correct. If I say "the sky is green" and nobody bothers to disagree, it doesn't make it so. > Does the outcome of EPEL not carrying repotags mean that there is no > interest in cooperation with 3rd party repos? Again, I think you're extrapolating too far here. It seems many people are "ambivalent" about the repo-tag thing, myself included. I can live with it, I can live without it. I don't really care. (Maybe I should, and maybe it's some kind of failure that I don't, but that's how it is). I think you're assuming that everyone feels as strongly about this as you do (either positive or negative), whereas they don't, and you're thus inferring a strong feeling that isn't there, that by not I am not mentioning repotags again; the rest of this post is referring to issues "in general" and NOT specifically repotags. > * Will it jump in the game ignoring that 3rd party repos exist and > let Darwinism prevail? I think that any repo that aims to be self-consistent has to effectively "ignore" other repos from a strictly technical perspective. Either you depend on packages in other repos, or you don't. If you don't, then you have to take responsibility for the self-consistency of your own repo and that's the primary consideration. Fortunately, in many cases it should be possible to achieve that consistency whilst also making sharing/transition with other repos possible. However I think your question is more about people rather than packages. Should we be open and encourage the *people* running existing repos to get involved? Sure! Should we make that as easy to do as possible? Yes! Should be encourage the pooling of efforts with the goal of making the best enterprise OS with the most comprehensive and reliable add-on packages? Yes! However, every repo has its own policies (e.g. on stability, updates etc.). There isn't "one size fits all". So we can never have perfect harmony from a technical perspective, because what's right for one repo might not be right for another. > * Will it try to work together with these repos? If yes, in what > concrete way? Personally I think this should be mostly done at a "grassroots", i.e. per-package level. If I'm maintaining package XYZ and that package (or dependents) also exists in another repo, then it would obviously be a good idea for me to try to talk to the person maintaining it in the other repo and see if we can share resources (which might take many forms from swapping spec files or patches, to both contributors agreeing to focus on a single repo, whichever it is). Similarly, if the two people are going to be maintaining packages that are related then it would make sense to try to maintain certain types of compatibility, for users that choose to use both repos. However, I don't think we can legislate for or enforce this at a high level. > * Does EPEL consider itself at the same level as these repos, or does > it place itself higher, pushing any compatibility issues to the > workload of these repos? I think each *self-consistent* repo is what it is. It's a repository of stuff. If it's self consistent, then compatibility outside of that repo with other repos is up to the end user to assess. Of course, it is *desirable* to "play nice" with other repos, because we all care about making things easy for users, and broadly we're all trying to achieve the same things so duplication of effort is wasteful. However, the self-consistency of a particular repo has got to be the primary consideration, no matter whether that repo is EPEL or A-N-Other Repo. So in that sense, I believe that *all* repos which are self-consistent place themselves "higher" than other repos, within the scope of their own activities. That's natural. Speaking from a personal perspective, like Michael Stahnke, I maintain a couple of private repos with a mixture of custom packages and rebuilds from other repos. Some of those are new packages that aren't in the base OS, and some over-ride base OS packages, in which case I do the appropriate versioning to make sure my custom packages take priority. Now, I don't much enjoy fighting a one-person battle to do all this stuff, but it's necessary in terms of QA. So personally I welcome the chance to put that effort into a more open and collaborative project like EPEL which has documented procedures, standards etc. and many people working towards the same goal, and I will most likely (of choice) make my private repos subordinate to EPEL. However, that's my choice and I don't expect all other repo maintainers to necessarily do the same thing. In summary, whilst I think you're trying to reduce this to a simple black/white issue (to co-operate or not with other repos), I don't think that it's possible to do that. In particular, I see the need to distinguish between other repos and the people running other repos. Would I like your personal experience and skills contributing to EPEL? Yes. Do I think that EPEL's policies should be affected by existing packages in ATrpms? Maybe, BUT only where that is consistent with the goals of EPEL and the opinions of other EPEL contributors. If there is a conflict between what other EPEL contributors want and ATrpms, then that's unfortunate and we should try to avoid it, but at the end of the day the self-consistency and maintainability of EPEL is key and you shouldn't take it as a personal insult. Sometimes there are times where even intelligent, skilled people don't agree. In that case, as a self-consistent repo, EPEL (like all other repos) will need to make a consensus policy, and contributors should all accept and follow that policy, even if they don't agree with it. I know I'm prepared to do that, though I acknowledge that that's easier when I'm only supporting a private population of users. Tim From lists at timj.co.uk Thu Apr 19 11:31:11 2007 From: lists at timj.co.uk (Tim Jackson) Date: Thu, 19 Apr 2007 12:31:11 +0100 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <4627503E.2050507@timj.co.uk> References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> Message-ID: <462752FF.3070700@timj.co.uk> I wrote: > Again, I think you're extrapolating too far here. It seems many people > are "ambivalent" about the repo-tag thing, myself included. I can live > with it, I can live without it. I don't really care. (Maybe I should, > and maybe it's some kind of failure that I don't, but that's how it is). > I think you're assuming that everyone feels as strongly about this as > you do (either positive or negative), whereas they don't, and you're > thus inferring a strong feeling that isn't there, that by not whoops, half sentence. I meant to say: "...that by not having a strong opinion, they are actively opposed to co-operation with other repos". From dag at wieers.com Thu Apr 19 11:58:27 2007 From: dag at wieers.com (Dag Wieers) Date: Thu, 19 Apr 2007 13:58:27 +0200 (CEST) Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <4627503E.2050507@timj.co.uk> References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> Message-ID: On Thu, 19 Apr 2007, Tim Jackson wrote: > Axel Thimm wrote: > > > Does the outcome of EPEL not carrying repotags mean that there is no > > interest in cooperation with 3rd party repos? > > Again, I think you're extrapolating too far here. It seems many people are > "ambivalent" about the repo-tag thing, myself included. I can live with it, I > can live without it. I don't really care. (Maybe I should, and maybe it's some > kind of failure that I don't, but that's how it is). I think you're assuming > that everyone feels as strongly about this as you do (either positive or > negative), whereas they don't, and you're thus inferring a strong feeling that > isn't there, that by not Well, maybe it isn't there inside of the Fedora community. But all the other repositories know better. We represent more people (and definitely more people in the RHEL/CentOS community) than EPEL currently does. Still, nobody listens to the voice me or Axel represents. And I'm sure opponents like to minimize what it represents or the value it has. Fact is that RPMforge and AtRPMS will now drop the repotag now that Fedora rejected the idea. Have fun sorting through a mess where there are different eg. clamav packages with the same version-release and different content. That's what you get when you do not differentiate packages. Fedora/EPEL is actively making sure people cannot use packages from different sources so they can tell people 'we warned you not to use different sources'. It's a shame that such tactics are being used again. The bad thing is that EPEL will not be able to accomodate all the RHEL/CentOS users even if they want to because you have different needs and therefor different policies. So what worked for Fedora may backfire with RHEL/CentOS. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From lists at timj.co.uk Thu Apr 19 13:04:44 2007 From: lists at timj.co.uk (Tim Jackson) Date: Thu, 19 Apr 2007 14:04:44 +0100 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> Message-ID: <462768EC.4050200@timj.co.uk> Dag Wieers wrote: > Still, nobody listens to the voice me or Axel represents. And I'm sure > opponents like to minimize what it represents or the value it has. I don't think that's quite true. Many people, including myself, have expressed publically before how much they appreciate both the work (in terms of existing packages & support) and the input (in terms of knowledge) from yourself, Axel and others. The kmod debate may not have been much fun, and it didn't end up with the result you wanted, but even in that debate you will find many people appreciative of your experience with a large userbase. There is nothing better than yourself & Axel (and all the others with similar experience) contributing to EPEL. I really would like for that to happen, because the end result is better when a whole group of people work together in collaboration and co-operation. I also think you are over-personalising this by talking about "opponents" and suchlike. I can (respectfully) disagree with someone, but it doesn't mean they are an "opponent". Actually, many times we might be trying to achieve the same thing, we just have different opinions. Sometimes there is no right or wrong, just a matter of perspective. > Fact is that RPMforge and AtRPMS will now drop the repotag now that Fedora > rejected the idea. Have fun sorting through a mess where there are > different eg. clamav packages with the same version-release and different > content. That's what you get when you do not differentiate packages. Personally I don't have a problem with this in the slightest, which is part of the reason why I am so ambivalent about repotags. I'm 100% sure that "EPEL doesn't have repotag" DOES NOT mean "Stuff you Axel/Dag". (Actually, I had no participation in the original debate, and I did not vote, so I'm commenting as an observer. But personally I think it is entirely up to you whether you use a repotag or not in your own private repo, I respect that decision either way, and I am quite happy both ways). You & Axel appear to be implying that you removing repotags is some kind of threat, which is going to teach a lesson to some of the people who opposed it in EPEL. Maybe it will, but personally I don't see it as a big deal either way. Again, I'm not actually trying to discuss the repotag issue here - just to point out that co-existence is mutual: nobody in EPEL can criticise you for removing repotags, but I've not heard from anyone that *wants* to criticise you. Perhaps I missed them, but I didn't notice anybody saying "hey, we don't need repotags, because we're special - but Dag does.". So, please, remove your repotag. If anyone in EPEL who opposed repotags in EPEL criticises you, then you can rightly claim they are hypocritical. But I suspect that nobody will actually complain. Well, time will tell. > Fedora/EPEL is actively making sure people cannot use packages from > different sources I don't think this is true. However, I do personally keep my active use of repos to a minimum because I personally find that mixing of sources is incompatible with the reasons I'm using an enterprise distro - regardless of the respective quality of the various repos. However, I don't see anything proposed that actually *stops* people doing that if they really want. It's also important to remember that EPEL is more or less just a bunch of people trying to achieve a similar goal, not some kind of power-crazed organisation. You can be a part of that and influence the outcome, but human nature dictates that it's easier to do that "from the inside" than out. That said, as Axel is demonstrating, merely being part of the group doesn't mean that everyone has to agree with - and at the end of the day you have to decide whether the tradeoff of being part of something collaborative is worth the downside of having to live with decisions you sometimes disagree with. (Which also means sometimes having to sit back and watch some other people learn the hard way about some things and be able to say "I told you so". That's frustrating I know, but it's also life :) Tim From lists at timj.co.uk Thu Apr 19 13:24:42 2007 From: lists at timj.co.uk (Tim Jackson) Date: Thu, 19 Apr 2007 14:24:42 +0100 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <46210C57.4030004@leemhuis.info> References: <20070414111711.GA25962@neu.nirvana> <46210C57.4030004@leemhuis.info> Message-ID: <46276D9A.8000200@timj.co.uk> Thorsten Leemhuis wrote: > Just some random thoughts from me here; I didn't want to reply on Axels > statements directly as I feared that it tracks the discussion and my > answers into a direction I don't want them. [...] I'm a little late to this but thanks for a very balanced response Thorsten. I could not agree more, in particular that this is NOT a repowar (EPEL vs RPMforge). Tim From dag at wieers.com Thu Apr 19 13:30:17 2007 From: dag at wieers.com (Dag Wieers) Date: Thu, 19 Apr 2007 15:30:17 +0200 (CEST) Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <462768EC.4050200@timj.co.uk> References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> <462768EC.4050200@timj.co.uk> Message-ID: On Thu, 19 Apr 2007, Tim Jackson wrote: > Dag Wieers wrote: > > > Still, nobody listens to the voice me or Axel represents. And I'm sure > > opponents like to minimize what it represents or the value it has. > > I don't think that's quite true. Many people, including myself, have expressed > publically before how much they appreciate both the work (in terms of existing > packages & support) and the input (in terms of knowledge) from yourself, Axel > and others. The kmod debate may not have been much fun, and it didn't end up > with the result you wanted, but even in that debate you will find many people > appreciative of your experience with a large userbase. > > There is nothing better than yourself & Axel (and all the others with similar > experience) contributing to EPEL. I really would like for that to happen, > because the end result is better when a whole group of people work together in > collaboration and co-operation. > > I also think you are over-personalising this by talking about "opponents" and > suchlike. I can (respectfully) disagree with someone, but it doesn't mean they > are an "opponent". Actually, many times we might be trying to achieve the same > thing, we just have different opinions. Sometimes there is no right or wrong, > just a matter of perspective. With opponent there, I meant someone oposing the repotag idea. I am not a native English speaker. > > Fact is that RPMforge and AtRPMS will now drop the repotag now that Fedora > > rejected the idea. Have fun sorting through a mess where there are different > > eg. clamav packages with the same version-release and different content. > > That's what you get when you do not differentiate packages. > > Personally I don't have a problem with this in the slightest, which is part of > the reason why I am so ambivalent about repotags. I'm 100% sure that "EPEL > doesn't have repotag" DOES NOT mean "Stuff you Axel/Dag". (Actually, I had no > participation in the original debate, and I did not vote, so I'm commenting as > an observer. But personally I think it is entirely up to you whether you use a > repotag or not in your own private repo, I respect that decision either way, > and I am quite happy both ways). But you do not understand what the implications are. The people that voted did, or should have. And the signal this gives (knowing the implications and still not adding a repotag) is what makes this very negative towards a community that existed. EPEL is the newcomer here. Both RPMforge and EPEL provide clamav packages. (RPMforge was providing them long before Fedora introduced them, but that's just history). Sadly Fedora introduced them completely different. Some subpackages are different in aim and content. Without a repotag you get: EPEL: clamav-0.88.6-1.el5.i386.rpm clamav-data-0.88.6-1.el5.i386.rpm clamav-devel-0.88.6-1.el5.i386.rpm clamav-lib-0.88.6-1.el5.i386.rpm clamav-milter-0.88.6-1.el5.i386.rpm clamav-milter-sysv-0.88.6-1.el5.i386.rpm clamav-server-0.88.6-1.el5.i386.rpm clamav-server-sysv-0.88.6-1.el5.i386.rpm clamav-update-0.88.6-1.el5.i386.rpm RPMforge: clamav-0.88.6-1.el5.i386.rpm clamav-db-0.88.6-1.el5.i386.rpm clamav-devel-0.88.6-1.el5.i386.rpm clamav-milter-0.88.6-1.el5.i386.rpm clamd-0.88.6-1.el5.i386.rpm How would Yum (or a user manually) make sense of this ? Packages may resolve to the wrong thing, but you don't know what is what because there is no unique identifier to match it with. I can hear 2 things now: 'than don't drop the rf repotag' and 'another argument for not mixing repositories'. And both comments would reveal the sorry state of the mind, because you simply do not consider the diversity and the fact that EPEL is just another repository. > You & Axel appear to be implying that you removing repotags is some kind of > threat, which is going to teach a lesson to some of the people who opposed it > in EPEL. Maybe it will, but personally I don't see it as a big deal either > way. Again, I'm not actually trying to discuss the repotag issue here - just > to point out that co-existence is mutual: nobody in EPEL can criticise you for > removing repotags, but I've not heard from anyone that *wants* to criticise > you. Perhaps I missed them, but I didn't notice anybody saying "hey, we don't > need repotags, because we're special - but Dag does.". So, please, remove your > repotag. If anyone in EPEL who opposed repotags in EPEL criticises you, then > you can rightly claim they are hypocritical. But I suspect that nobody will > actually complain. Well, time will tell. Well, again, as a newcomer EPEL gives a bad signal. And the above example is one that is real. Not addopting a repotag is saying to other repositories, we don't care about diversity. We are the one big repository that will rule everything and either you join or we'll crush you. Not adopting a repotag is saying to users, hey, if you have problems, it is all your own fault. We told you not to mix repositories. You should stick to ours. And you know what, in contrast to Fedora, with EPEL there is a clear need for the diversity. Should I stay with a specific version, or do I require the new functionality ? You can't have both in a single repository. Yum can't handle it. > > Fedora/EPEL is actively making sure people cannot use packages from > > different sources > > I don't think this is true. However, I do personally keep my active use of > repos to a minimum because I personally find that mixing of sources is > incompatible with the reasons I'm using an enterprise distro - regardless of > the respective quality of the various repos. However, I don't see anything > proposed that actually *stops* people doing that if they really want. That's fine. But EPEL will not be a solution to everything. And then we're not talking about people that use Yum and enable a complete repository. Then we may be talking about a user that NEEDS postfix 2.3 on RHEL5. Or a user that needs the latest lftp which EPEL does not provide. Not having repotags makes it harder for users. But this is not about users, this is about politics and power plays. As a newcomer there is an interest of making the situation harder so that people move to EPEL. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From rdieter at math.unl.edu Thu Apr 19 14:02:51 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 19 Apr 2007 09:02:51 -0500 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> <462768EC.4050200@timj.co.uk> Message-ID: Dag Wieers wrote: > Both RPMforge and EPEL provide clamav packages. (RPMforge was providing > them long before Fedora introduced them, but that's just history). Sadly > Fedora introduced them completely different. Some subpackages are > different in aim and content. An unfortunate circumstance. Now, are you willing to work together to fix the incompatibilities? This "working together" idea is a 2-way street you know. :) -- Rex From fedora at leemhuis.info Thu Apr 19 14:22:11 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 19 Apr 2007 16:22:11 +0200 Subject: Please rebuild your packages in EPEL5 Message-ID: <46277B13.4030308@leemhuis.info> Hi all! we now (since yesterday) have RHEL5 final on the builders thanks to the great work of Dennis Gilmore. Dgilmore, many thanks for your work. As you might have read from the past EPEL SIG meetings logs the EPEL Steering Committee agreed that it's likely the best to rebuild all the packages from EPEL5 against the final RHEL, as there were lots of changes between the beta1 (against the current packageset was build) and the final. The current plan is to ask everyone to rebuild the arch specific packages by next weeks EPEL Sig meeting -- e.g. next Wednesday, 20070425 at 17:00 UTC. It's up to the packager to decide if noarch packages need a rebuild. In next weeks meeting we'll decide what to do with those arch specific packages which were not rebuild up to then. It is under discussion that somebody will use a script to just add a ".1" to release, commit, tag and build them -- so you have been warned ;-) If there really is a good reason why your package doesn't need a rebuild send me a note my mail please. Thanks for your help. CU thl P.S.: If you doesn't want to do the rebuild yourself just send me a list of package names and use a script to update release and build your packages. From dag at wieers.com Thu Apr 19 14:28:55 2007 From: dag at wieers.com (Dag Wieers) Date: Thu, 19 Apr 2007 16:28:55 +0200 (CEST) Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> <462768EC.4050200@timj.co.uk> Message-ID: On Thu, 19 Apr 2007, Rex Dieter wrote: > Dag Wieers wrote: > > > Both RPMforge and EPEL provide clamav packages. (RPMforge was providing > > them long before Fedora introduced them, but that's just history). Sadly > > Fedora introduced them completely different. Some subpackages are > > different in aim and content. > > An unfortunate circumstance. Now, are you willing to work together to > fix the incompatibilities? This "working together" idea is a 2-way > street you know. :) Sure. But this was just one of the many examples. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From rdieter at math.unl.edu Thu Apr 19 14:55:41 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 19 Apr 2007 09:55:41 -0500 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> <462768EC.4050200@timj.co.uk> Message-ID: <462782ED.2000108@math.unl.edu> Dag Wieers wrote: > On Thu, 19 Apr 2007, Rex Dieter wrote: > >> Dag Wieers wrote: >> >>> Both RPMforge and EPEL provide clamav packages. (RPMforge was providing >>> them long before Fedora introduced them, but that's just history). Sadly >>> Fedora introduced them completely different. Some subpackages are >>> different in aim and content. >> An unfortunate circumstance. Now, are you willing to work together to >> fix the incompatibilities? This "working together" idea is a 2-way >> street you know. :) > > Sure. But this was just one of the many examples. Good, keep 'em coming! I'd much rather help work on getting stuff like this fixed, than to unproductively rehash the unfortunate history of getting to this predicament. :) -- Rex From mmcgrath at redhat.com Thu Apr 19 14:53:11 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 19 Apr 2007 09:53:11 -0500 Subject: What I want in a chair Message-ID: <46278257.2090800@redhat.com> As discussed in the last EPEL meeting we decided it was best to have a chairperson to help EPEL get off the ground over the next 6 months. Here's what I'm looking for in a chairperson 1) Somone who can convey a consistent EPEL message to the public, especially when it is officially launched 2) Must be able to balance what's best for EPEL, the larger community, 3rd party repo's and the users when their needs conflict. 3) Someone who is close to the EPEL community and can put EPEL community needs above their own 4) This person must be accountable (if they go all crazy we can always ask the board to remove them) 5) Primarily a facilitator, when decisions cannot be made, the community is split or opinions are not-obvious, this person can call for a vote or simply make the decision on their own. The idea here is that this person will be here for 6 months which, in Fedora time, is not very long. I have no fears about what this person will do because A) they will be accountable and B) It's just for 6 months. If we don't like what they've done we can remove them at that time or, more likely, pick a different governance model. I don't think EPEL is mature enough to need an extremely formal government which IMHO is perfect for a chairperson. They can listen to what's up and people can go to the chair with concerns they care about. The question now is where does this leave the SIG? Same place, we meet, we discuss, we ultimately do the work. It's the spirit of this agreement that's important and I think in practice we'll find this a very easy / beneficial situation. -Mike From lists at timj.co.uk Thu Apr 19 15:05:08 2007 From: lists at timj.co.uk (Tim Jackson) Date: Thu, 19 Apr 2007 16:05:08 +0100 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> <462768EC.4050200@timj.co.uk> Message-ID: <46278524.9050408@timj.co.uk> Dag Wieers wrote: >> I also think you are over-personalising this by talking about "opponents" and >> suchlike. I can (respectfully) disagree with someone, but it doesn't mean they >> are an "opponent". [...] > With opponent there, I meant someone oposing the repotag idea. I am not a > native English speaker. OK, I understand. Sorry, I do know you're not a native English speaker but your English is so good that it's easy to forget :) ("opponent"/"opposing", to me, has considerably stronger/more aggressive connotations than "disagreement") > Both RPMforge and EPEL provide clamav packages. (RPMforge was providing > them long before Fedora introduced them, but that's just history). Sadly > Fedora introduced them completely different. Some subpackages are > different in aim and content. Actually, this is a very interesting example to me. I have a considerable interest in e-mail handling and virus/spam scanning, and have written some documents and given talks about this topic. (My guide "Spam & Virus Scanning with Exim 4.x" has been downloaded tens of thousands of times over the past 4+ years since I wrote it). I was quite an early user of clamav, and created an RPM very early on (I think even before you, because when I first wrote the spec I'm pretty sure I looked on dag.wieers.com) and definitely before Fedora. I published the specfile on my website and referenced it in my HOWTO. I had many requests about the clamav packaging, even going so far as to install OSes that I don't normally use to help people build clamav RPMs. Eventually, clamav packages were introduced by you and (later) Fedora. Now, even though I had already deployed clamav on my own machines and referenced it in documents, I decided to change my servers and documents to refer to the Fedora packaging instead, not because I liked the packaging better, but because I think Fedora is a good project and I want to encourage it. So I put the project higher than my own personal preferences, even though I had to do extra work. (And actually it saves me work in the end, because I don't maintain clamav in Fedora) > Without a repotag you get: [...differing packages in EPEL and RPMforge...] > How would Yum (or a user manually) make sense of this ? Packages may > resolve to the wrong thing, but you don't know what is what because > there is no unique identifier to match it with. OK, so this is not a great situation I agree. But the point here is the problem is more fundamental than repotags or not. The real problem is collaboration, not repotags. And here's where my point about "co-operation at grassroots" comes in. Because what would ideally be happening here is that the Fedora clamav maintainer, and the RPMforge maintainer (you, if that is you) have some private discussions to agree a common package structure. Then there is no problem, repotags or none. OK, so in some circumstances people will never agree. But generally it seems to me that most packagers have similar goals and most people are open to suggestions. And my original point was that you can't legislate for that kind of co-operation at a high (EPEL) level. It needs to be more personal than that. I do understand how repotags might help users to visually differentiate packages in situations like this, but in my personal opinion that's only a very small advantage, which is why I really don't have strong opinions about it. The real issue is trying to address the root problem. > I can hear 2 things now: 'than don't drop the rf repotag' As I said, anyone saying this from EPEL is being hypocritical if they voted against inclusion of repotags in EPEL. But is anyone actually in that situation? > and 'another argument for not mixing repositories'. Well, this is kind of true, but you're right in that it's missing the point - it would be better if we just collaborated and adopted a common format :) The question is: if some Fedora packagers were prepared to change their packages to be more like RPMforge, would you be prepared to change some of your packages to help the higher goal of cross-repo compatibility? How about even when you think your packaging is OK? If so, great! If not, then what you call "3rd party compatibility" is really just a 1-way thing. Nobody's forcing you to collaborate with EPEL, but by the same token you can't complain about a lack of co-operation if you don't. > Not addopting a repotag is saying to other repositories, we don't care > about diversity. We are the one big repository that will rule everything > and either you join or we'll crush you. Again, like Axel, I think you're finding political implications that simply aren't there. I didn't vote but if I did, I would probably have slightly erred on the "no repotag" side. But that would **not** be because I had the highly-charged opinion above. It would just be that I didn't think there was a strong enough reason to use them. No disrespect to you or others or intention to "crush" your efforts - just a "professional disagreement". I think what you're doing is great (heck, I use some RF packages and I've even sent you a couple of small patches before now), and as Thorsten said, the goals of RPMforge and EPEL are different. But I just don't take the view that "without repotags, co-operation is impossible". As I said to Axel at the start of this thread, you obviously have strong opinions about this issue, and I respect that. But I think you would be making a mistake to misinterpret other people's disagreement as meaning that they hold equally strong opposing opinions. You have a long history with RPMforge; you are absolutely right that EPEL is a "newcomer". You're rightly proud of what you have achieved, and I think as a packaging community we have a lot to thank you, Axel, Matthias and others for. However, that doesn't mean that everyone will always want to follow the same policies as you. More importantly, even when they disagree, it does *not* mean that they intend any disrespect or ill-intent towards you. > Not adopting a repotag is saying to users, hey, if you have problems, it > is all your own fault. We told you not to mix repositories. You should > stick to ours. This is just an opinion; personally I don't get that connotation. > And you know what, in contrast to Fedora, with EPEL there is a clear need > for the diversity. Should I stay with a specific version, or do I require > the new functionality ? You can't have both in a single repository. Yum > can't handle it. Well, there is "includepkgs" which I personally find very useful, but again I'm trying to avoid rehashing the repotag discussion. Your general point is very good, and very important, and looking at the general picture of repo collaboration this is something that we should all be very aware of. Indeed, as I mentioned before, this is something that I am very conscious of: for example I have a lot of CentOS 3/4 boxes, but there are some applications where I *need* newer versions of packages. So I have my own repository with newer packages in, just like RPMforge. This is why RPMforge and EPEL serve different needs and why I personally think that we SHOULD collaborate as much as possible, and have as an ideal goal the ability to mix repos without destroying systems. But again, this is a mostly a per-package personal co-operation issue IMHO. > Not having repotags makes it harder for users. But this is not about > users, this is about politics and power plays. ??? I really don't see the "power plays" here. > As a newcomer there is an > interest of making the situation harder so that people move to EPEL. If there is anyone participating in EPEL with secret agendas like this, I would personally appreciate it if they would make themselves known and/or go away. I don't see any need for such self-serving behaviour. I'm actively interested in EPEL but I definitely have no such agenda, and from my reading of the lists I have not noticed any obvious agenda like that amongst others (even those that voted against repotags). Collaboration is good, but so is diversity: a wish to see EPEL succeed definitely does *not* necessarily imply a wish to see other projects fail. Again, in the absence of compelling evidence to the contrary I think it would be a mistake (and probably rather uncharitable) to equate a specific disagreement on one technical issue with a malicious agenda to crush other repos. I think most (hopefully all!) people involved here are just trying to do useful stuff and make things that are easy to use. We might disagree about *how* to do that from time to time, but that's a world away from actively destroying each other's efforts. Please do consider putting some of your suspicions behind you and joining in. It would be great if you were on board with EPEL. Nobody can promise you that they will always agree with you, but what we can do is jointly try to find some positive, constructive solutions to the problems that exist, like making packages more compatible. Tim From fedora at leemhuis.info Thu Apr 19 16:32:46 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 19 Apr 2007 18:32:46 +0200 Subject: Summary of yesterdays EPEL SIG meeting Message-ID: <462799AE.10708@leemhuis.info> = Meeting 20070419 = == Attending == >From the Steering Committee: * dgilmore * mmcgrath * nirik * quaid * stahnma * thl * thimm Other contributors that joined the meeting: * entr0py, rdieter == Summary == * RHEL5 is now on the builders thx to dgilmore; note that the RHEL5-ppc tree is based on the RHEL5-server version that that misses some packages that are part of the RHEL-desktops (which are only available for x86 and x86_64); see this mail from thimm for details: http://www.redhat.com/archives/epel-devel-list/2007-March/msg00250.html of the differences * Mass rebuild for RHEL5 final -- we give contributors a chance to rebuild their stuff over the next week until the next SIG meeting; arch packages should be build, noarch don't have to; we discuss in the next meeting what to do with those packages that didn't get rebuild * Elect chairmen and discuss responsibilities -- six out of seven Steering Committee members want a chairmen; we discuss responsibleness, expectations and powers of the next week on the list * Relations to 3rd party distro -- hard to write a summary; see 0:44 an later for details; == Full Log == {{{ 00:00 --- | thl has changed the topic to: EPEL meeting 00:00 < thl> | ping dgilmore quaid stahnma thimm nirik mmcgrath 00:00 * | nirik is here. 00:00 * | mmcgrath here 00:01 * | thimm also 00:02 < entr0py> | rabble rabble 00:02 < thl> | hmm, that makes four people 00:03 < thl> | well, maybe others show up over time, so let's start 00:03 --- | thl has changed the topic to: EPEL Meeting -- RHEL5 on the builders -- dgilmore/mmcgrath 00:03 < thl> | dgilmore told be we have RHEL5 on the builders now 00:03 < mmcgrath> | AFAIK we're good to go. 00:03 < thl> | but he said something else: 00:03 < mmcgrath> | We still don't have a good way to keep the builders up to date. 00:03 < thl> | "my only concern is that some ppc builds may fail since there is only a server version for ppc" 00:04 < thl> | mmcgrath, k, I'll put that up the schedule to make sure it doesn't get forgotten 00:04 < thimm> | mmcgrath: what is the issue? 00:04 < thl> | but I'd say it should be fine for now 00:04 < mmcgrath> | thimm: actually getting the RPM's to a location to sync to in an automated fashion. We could use satsync but thats nasty. 00:04 < entr0py> | so go ahead and build but look for problems? 00:04 < mmcgrath> | did RH not release a PPC client version? 00:05 < thl> | entr0py, yes 00:05 < thl> | mmcgrath, no, they didn't 00:05 --> | stahnma (Michael Stahnke) has joined #fedora-meeting 00:05 < thl> | so some packages might be missing 00:05 < thl> | and builds might fail 00:05 < thl> | is " go ahead and build but look for problems " okay for everyone? 00:05 * | stahnma is here (meeting moved) 00:05 < thl> | I asked dgilmore to provide a "ls -l" of the trees 00:06 < thl> | then we can analyse of what to do 00:06 < mmcgrath> | thl: yep 00:06 < thimm> | Out of client, the only thing I would be missing is fribidi 00:07 < thimm> | So not a very big deal 00:07 --> | silug (S. Ill. Linux UG - http://www.silug.org/) has joined #fedora-meeting 00:07 < mmcgrath> | heh, thats funny. 00:07 < thl> | thimm, maybe, I'm not sure of the exact differences 00:07 --> | FrancescoUgolini (Francesco Ugolini) has joined #fedora-meeting 00:07 < mmcgrath> | We can always compile that on our own. 00:07 < thimm> | thl, I have the diffs here 00:07 < nirik> | so we are going to tell people to rebuild? or just mass rebuild? 00:07 < thl> | thimm, can you send them my way please? tia! 00:08 --- | thl has changed the topic to: EPEL Meeting -- mass rebuild for RHEL5 -- thl 00:08 < thl> | nirik, well, I'd say we go further as planed last friday 00:08 --> | rdieter (Rex Dieter) has joined #fedora-meeting 00:08 < thl> | e.g. tell contributors to rebuild their stuff 00:08 < thl> | we wait 3|4|7 days 00:08 < thl> | and then we add a .1 to every pacakge that didn#t get rebuild 00:08 < thimm> | thl: they are on the epel-devel list ... 00:08 < thl> | commit, tag, build 00:09 < mmcgrath> | Playing devil's advocate: Would it be horrible if we didn't require a rebuild and just let people file bugs if any are found? 00:10 < thl> | mmcgrath, I'd prefer a clean build 00:10 < thl> | thimm, "they are on the epel-devel list" -> what do you mean? 00:10 < mmcgrath> | I would to, but its not as simple as snapping ones fingers :-/ 00:10 < thl> | thimm, I wanted to annouce it on epel-devel list 00:10 < thimm> | thl and rest: diffs server/client on http://www.redhat.com/archives/epel-devel-list/2007-March/msg00250.html 00:10 < thimm> | already done 00:10 < thimm> | if you like so 00:10 * | dgilmore is somewhat here 00:11 < thimm> | mmcgrath: is also an option 00:11 < thl> | I got told a lot got changed, z00dax said that and suggested we rebuild everything 00:11 * | quaid is here now 00:11 < thimm> | I can't imagine RHEL5beta2 being further away than RHEL5, than FC6-F7 00:12 < thl> | thimm, it was RHEL5beta1... 00:12 < thimm> | Even so 00:12 < mmcgrath> | thl: I'd defer to z00dax on that. He'd know better than I. 00:12 < thimm> | (who is zoodax?) 00:12 < mmcgrath> | thimm: centos.karan.org 00:12 < thl> | thimm, from centos and http://centos.karan.org/ 00:12 < thimm> | Karanbir Singh? 00:13 < mmcgrath> | 00:13 < thl> | thimm, yes 00:13 < thimm> | k 00:13 < stahnma> | do we expect a lot of people to not rebuild if we ask them to nicely? 00:13 < dgilmore> | stahnma: most will 00:13 < mmcgrath> | especially if we start to nag. 00:13 < thl> | stahnma, it will be a whole lot quicker if we do it outselfes after some days 00:13 < mmcgrath> | I'm fine with either. 00:14 < stahnma> | so, a time limit of 5 or 7 days seems reasonable 00:14 < thl> | I'd say we give them some days, and then to it ourselfs 00:14 < thl> | +1 for 5 to 7 days 00:14 < stahnma> | if they can't meet that, they can always select a co-maintainer also 00:14 < thimm> | I would be upset if I get my spefiles forked ... 00:14 < stahnma> | some people are very concered about forked spec files and some seem not to be, what is the general consensus? 00:14 < thl> | thimm, yeah, but 7 days should be enough normally 00:15 < mmcgrath> | thimm: I feel the same way but we can't say we didn't warn them :-) 00:15 < thl> | mmcgrath, +1 00:15 < stahnma> | if we announce today, and put a due date of next wednesday, how would that be? 00:16 < stahnma> | we can have a status at this meeting next week? 00:16 < thl> | stahnma, should be fine 00:16 < stahnma> | pick up stragglers 00:16 < thimm> | What happens if I know a package of mine needs no rebuild 00:16 < thl> | stahnma, I can annouce the rebuild later 00:16 < stahnma> | then and beat them with 1s and 0s 00:16 < thimm> | For example it is a python app 00:16 < thl> | I actually started to prepare a mail already 00:16 < dgilmore> | thimm: noarch could be excluded 00:17 < thl> | dgilmore, +1 00:17 < thimm> | Can we leave that to packager's discretion? 00:17 < stahnma> | does that make sense in all cases? 00:17 < stahnma> | I am just asking becuase I am not 100% sure 00:17 < dgilmore> | noarch should need no compilation and work regardless 00:17 < thimm> | It need to be checked on a package by package basis 00:17 < stahnma> | that being dgilmore's noarch exclusion above :) 00:17 < thl> | thimm, are you volunteering to do this? 00:18 < thimm> | What? 00:18 < dgilmore> | if it really needs a rebuild it should not be no arch 00:18 < thl> | otherwise we'll never get this of the table 00:18 < thl> | thimm, look "on a package by package basis" 00:18 < thimm> | Yes, for my packages ... 00:18 < thimm> | "Can we leave that to packager's discretion?" 00:18 < stahnma> | that brings us back to a voluntary rebuild from each contributor though right? 00:19 < thimm> | yes 00:19 * | thl wonders thy this comes up now, as the decisions to have a rebuild was done weeks ago 00:19 < thimm> | Consider it the following way: 00:19 < dgilmore> | thimm: they could try sell us on why it doesnt need a rebuild 00:19 * | stahnma was also thinking that 00:19 < thl> | we could have saved a lot of trouble if we would have decided to ahve a colunettered mass rebuild only 00:19 < mmcgrath> | Could we ask a voluntary rebuild and meet about it next week to decide what to do next? 00:19 < thl> | we could use the "needs.rebuild" cvs trick again 00:20 < thl> | mmcgrath, +1 00:20 < nirik> | mmcgrath: +1 00:20 < mmcgrath> | I just want something to happen in epel, it feels like no actual action has taken place in weeks :-/ 00:20 * | nirik has several noarch packages that are very unlikely to be needing rebuild. 00:20 < stahnma> | mmcgrath: ++ 00:20 < thimm> | mmcgrath: I think dgilmore is doing a lot of work 00:20 < thl> | that makes four for "ask a voluntary rebuild and meet about it next week to decide what to do next" 00:20 < mmcgrath> | he got the RHEL5 builders going yes. 00:20 < dgilmore> | mmcgrath: thats fine 00:21 < thl> | five 00:21 < mmcgrath> | dgilmore aside though, nothing has happened :-/ 00:21 < stahnma> | yay dgilmore ! 00:21 < thl> | I'll annouce that on the list then if that's okay for everybody 00:21 < thimm> | thl and I fight every day, does that count? ;) 00:21 < stahnma> | thl +1 00:21 < thl> | thimm, we leave out some days 00:21 < stahnma> | it adds to my amusement :) 00:21 * | dgilmore is unlikely to be able to be here the next 2 weeks 00:21 < thl> | thimm, today iirc ;-) 00:22 < thl> | (well, until now at least) 00:22 < thimm> | day is still young 00:22 < mmcgrath> | :) 00:22 < nirik> | perhaps some days count double. ;) 00:22 < thl> | anyway, anything else? 00:22 < thimm> | OK, 4 of 7 have agreed, go ahead 00:22 < thl> | or move on? 00:22 < dgilmore> | move on 00:22 < nirik> | moveon++ 00:22 < mmcgrath> | Ok, so that email will get sent and then we will discuss next week what to do. 00:22 --- | thl has changed the topic to: EPEL Meeting -- Elect chairmen and discuss responsibilities 00:22 < thl> | thimm, spot is the defacto chairmen of FPC 00:23 < thl> | thimm, he actually started that group and is responsible for it afaik 00:23 < thimm> | He doesn't veto votes ... 00:23 < thl> | afaik 00:23 < thl> | thimm, the chairmen can't veto votes 00:23 < nirik> | wheres the wiki page with proposed duties of the chair? 00:23 --> | GeroldKa (GeroldKa) has joined #fedora-meeting 00:23 < stahnma> | I don't think anyone was proposing veto of votes 00:23 < thl> | he has just to coordinate them 00:23 * | nirik is unconvinced we need one. 00:23 <-- | MauricioPretto has quit ("Leaving") 00:23 < thimm> | nirik++ 00:23 < dgilmore> | thimm: chairperson is to make sure things are happening 00:23 < thimm> | what would a chairman solve? 00:23 < thl> | last week the decisions was to have one 00:23 < thimm> | ??? 00:24 < thimm> | What decision? 00:24 < dgilmore> | thimm: it would solve things seeming to be disorganised 00:24 < thl> | that was afaics the conclusion of last week 00:24 < stahnma> | I thought it was more of an administrivia role and not so much formal power 00:24 < mmcgrath> | a chairman would be someone that has a vision and can make decisions. 00:24 < thl> | stahnma, +1 00:24 < dgilmore> | well because they are 00:24 < mmcgrath> | If we don't like his decisions, we don't re-elect him. 00:24 < stahnma> | and beat him! 00:24 < thimm> | So it is an empowerment position, not administrative 00:25 < thimm> | E.g. not a chairman bit a president 00:25 * | thimm don't like that 00:25 < mmcgrath> | The fact is even the few people we have involved right now are bumping heads regularly. 00:25 < dgilmore> | thimm: bit of both 00:25 < thl> | dgilmore, +1 00:25 < dgilmore> | sometimes things just need doing 00:25 < thimm> | That's why we vote 00:25 < mmcgrath> | thimm: voting is slow. 00:25 < thimm> | We din't get off because there was reluctance to a committee 00:25 < mmcgrath> | and voting on everything shows a lack of vision. 00:26 < thimm> | So fesco/fpc have a lack of vision? 00:26 < mmcgrath> | I'm not talking about fesco or fpc. 00:26 < mmcgrath> | I'm talking about EPEL, specifically the bickering that has started over the last couple of months that is A) counter productive and B) making sure that nothing gets done. 00:27 < thimm> | And a chairman will stop flames on the list? 00:27 < dgilmore> | mmcgrath: indeed 00:27 < mmcgrath> | Not everyone can be happy all the time. 00:27 < mmcgrath> | a chairman will make sure the flames only last a day or so. 00:27 < thimm> | And then? what does he do? 00:28 < mmcgrath> | people on the list are treating every little decision as if they don't get their way means that epel will cease to exist in a few weeks and thats just not the case. 00:28 < thimm> | He contacts the mailman admin to shutdown the thread? 00:28 < thimm> | Or he make a decision on his own? 00:28 < mmcgrath> | No, he makes the decision and tries to find someone to take action unless he takes the action himself. 00:28 < stahnma> | ask to present your case formally, and have both sides present 00:28 < nirik> | or he brings it to a vote? 00:28 < mmcgrath> | he can bring it to a vote if he feels wants. 00:28 < stahnma> | a well informed EPEL group then makes the call (vote possible) 00:28 < nirik> | so this is more of a manager position that a admin of meetings and such? 00:28 < mmcgrath> | we talked about only having a chariman for 6 months anyway right? 00:29 < mmcgrath> | so lets just do it and see where we stand in 6 months. 00:29 < thl> | mmcgrath, yes 00:29 < thl> | mmcgrath, +1 00:29 --- | couf_afk is now known as couf 00:29 < quaid> | nirik: facilitator 00:29 < quaid> | that's the main role of chair, IME 00:29 < dgilmore> | thimm: im the mailman admin for epel im not going to censor any threads 00:29 < quaid> | and occasionally person to make decisions when a decision needs to be done and a consensus is not clear, yet no formal vote is needed 00:30 < nirik> | well, if he's making decisions by himself (or herself) then they are more than a facilitator... 00:30 < quaid> | ok, then 00:30 < quaid> | 70% facilitator 00:30 < thimm> | quaid: And *who* decides whether a formal vote is needed? 00:30 < thl> | nirik, we have this committee for decisions 00:30 < quaid> | 29% front face 00:30 < quaid> | 1% decider 00:30 < thimm> | decider ----- 00:30 <-- | FrancescoUgolini has quit (Remote closed the connection) 00:30 < thimm> | Let's look at the history 00:31 < thimm> | chairman is supposed to solve thl's and my diagreements? 00:31 < quaid> | thimm: I've never made a decision as a chair that wasn't from the FDSCo members asking me to decide 00:31 < dgilmore> | thimm: i dont know if anyone can solve them 00:31 < thimm> | s/solve/end/ 00:31 < nirik> | I guess I would be ok with that, as long as their decisions could be overruled/revisted... 00:31 < mmcgrath> | They won't end or solve them. 00:31 < quaid> | thimm: what is your suggestion as to how to break stalemates? 00:31 < mmcgrath> | but they'll make sure it doesn't get in the way of epel progress. 00:31 < thl> | mmcgrath, +1 00:31 < thimm> | quaid: votes 00:32 < quaid> | chair is to help move things forward 00:32 < thimm> | The issues last week or so was that thl didn't even want my proposed votes to get on the table 00:32 < mmcgrath> | IMHO, someone like a chairman would be perfect to get EPEL off the ground. THen in 6 months we can re-evaluate. 00:32 < quaid> | thimm: how do you know when to stop debate and have a vote? 00:32 < thimm> | I don't see how having thl as a chair will help there 00:32 < mmcgrath> | then don't vote for him. 00:32 < quaid> | thimm: in that case, it was more like .... 00:33 < quaid> | from my perspective ... 00:33 * | quaid tries to think how to put this 00:33 < dgilmore> | thimm: the cair will be responsible for coordinating all vote's as proposed by everyone 00:33 < quaid> | thimm: without a fair chair to mitigate, it felt to me as a committee member that a vote was forced that I was never clear was needed. 00:33 < thimm> | Let's show that votes can be effective 00:33 < quaid> | at least with a chair, I could vote for that person and trust their judgment to know when to vote or not vote. 00:33 < thimm> | Let's just vote on whether we want a chair or not 00:34 < thl> | chair +1 00:34 < dgilmore> | +1 for a chair 00:34 < thimm> | -1 00:34 < mmcgrath> | Ok, Vote on the table: do we want a chair 00:34 < mmcgrath> | +1 for chair for 6 months. 00:34 < stahnma> | +1 chair 00:34 < quaid> | +1 for chair for 6 months (trial) 00:34 < thimm> | OK, vote's done, discussion is over 00:34 < nirik> | +1 as long as we can override or revist their decisions 00:34 < quaid> | again, the biggest value is not in voting 00:34 < quaid> | it is in having a facilitator who is fair 00:35 < stahnma> | quaid: +1 00:35 < mmcgrath> | quaid: exactly. 00:35 < quaid> | if they are not fair, we call them on it - "no, we won't stop discussing, you are wrong" 00:35 < dgilmore> | so we will have a chair for 6 months 00:35 < dgilmore> | stahnma, and thl have been nominated 00:35 < dgilmore> | anyone else wish to nominate someone 00:36 < mmcgrath> | Who are the current nominees? thl and? 00:36 < dgilmore> | stahnma 00:36 < thimm> | What are the powers of the cahir now? 00:36 < thimm> | People here have different POV on that. 00:36 < quaid> | good question 00:37 < thl> | thimm, I wrote something to the list yesterday 00:37 < mmcgrath> | I'll nominate thimm. He's passionate about this and should be in the running. 00:37 < thimm> | what you wrote was purely admin stuff 00:37 < quaid> | do we need to have a week's worth of discussions first? 00:37 < thl> | I added that to the wiki as proposal at http://fedoraproject.org/wiki/EPEL/SteeringCommittee 00:37 < nirik> | yeah, no decision making in that list 00:37 < thimm> | mmcgrath: Thanks, but I cannot step into something I argue shouldn't exist 00:37 < quaid> | ah, the irony! 00:38 < mmcgrath> | thimm: totally fine, I'll remove the nomination. Thought I'd throw it out there if you were interested ;-) 00:38 < thimm> | No, thanks, I'm not 00:38 < thimm> | My nominee was "no chairman", he's out ;) 00:38 < mmcgrath> | So powers of the chair. 00:39 < thl> | so, elect a chairmen today or next week? 00:39 < thimm> | "issue and coordinate the votings in the meetings and in the wiki, to prevent chaos that might arise if anybody would issue votings" 00:39 < thimm> | -1000 00:39 < mmcgrath> | thl: who's going to vote on the chair? Just us or are we going to use the voting app? 00:39 < thimm> | Anyone in the SC should be able to issue votings 00:39 < thl> | mmcgrath, I'd say us 00:39 < mmcgrath> | k 00:39 < thl> | FESCo elects its chair itself, too 00:40 < thl> | thimm, there needs to be some coordination 00:40 < quaid> | yeah, *SCo elects its own chair 00:40 < thl> | the last wiki votings showed why IMHO 00:40 < thimm> | So the chairman can mute SC memebers? 00:40 < thl> | thimm, no 00:40 < mmcgrath> | no one can be muted. 00:40 < dgilmore> | thimm: youu are free to propose them the chairperson is a conduit 00:41 < thimm> | So the chairman auto-issues a vote if one of us proposes one? 00:41 * | spot mutes everyone 00:41 < mmcgrath> | k 00:41 * | dgilmore slaps spot 00:41 < mmcgrath> | :) 00:41 < thl> | thimm, I wrote what I think is important in the wiki 00:41 < thl> | everything else is not written 00:41 < thl> | and thuis doesn#t exists imho 00:41 < dgilmore> | thimm: yes if its proposed it needs to be brought up for discussion 00:41 < thl> | so there are no such powers like "So the chairman auto-issues a vote if one of us proposes one?" afaics 00:41 < mmcgrath> | thl: lets take a week to figure out exactly what we're looking for in a chairman and vote next week? 00:41 < nirik> | thl: what is the wiki page for that? 00:42 < thimm> | dgimore and thl contradict in the interpretation. 00:42 < quaid> | mmcgrath: +1 00:42 < thl> | mmcgrath, fine 00:42 < thl> | nirik, ? 00:42 < thl> | nirik, see http://fedoraproject.org/wiki/EPEL/SteeringCommittee#head-b5f8a5f5e875abbd584ba657548c4f5e9fa9a0d2 00:42 < nirik> | ah, there it is. Thanks. 00:43 < mmcgrath> | Would people be opposed to writing up individually what they're looking for in /wiki/YourWikiName/chair ? 00:43 < thimm> | You mean 7 lists to choose from? 00:43 < thl> | mmcgrath, send it to the list 00:43 < mmcgrath> | k 00:43 < thl> | mmcgrath, that a whole lot easier imho 00:43 * | mmcgrath was trying to keep the flames down :-) 00:43 < mmcgrath> | list works though. 00:43 < quaid> | ... and do it even if you hate the idea 00:44 < thl> | k, so move on? 00:44 < dgilmore> | yup 00:44 < stahnma> | yes 00:44 --- | thl has changed the topic to: EPEL Meeting -- Relations to 3rd party distro 00:44 * | thl send his opinion to the list 00:44 <-- | GeroldKa has quit (Remote closed the connection) 00:45 < nirik> | would it be possible to invite players from the other repos to this meeting? or another irc meeting? 00:45 < mmcgrath> | Do we have relations with any 3rd party repos besides thimm's? 00:45 < nirik> | I would like to hear how we might be able to cooperate more... 00:45 < stahnma> | z00dax has been in #epel quite a bit 00:45 * | mmcgrath atrpms user. 00:45 < stahnma> | and offering insight and having questions about items 00:46 < nirik> | yeah, perhaps a invite to dag/dries/rf folks might be good? 00:46 < mmcgrath> | Some 3rd party repos probably won't want to sign the CLA and stuff. Thats unfortunate but shouldn't really hurt us from working with them. 00:46 < thl> | nirik, dag was on the list 00:46 < stahnma> | should we have a special meeting to work with their discussions/conerncs/improvements etc? 00:46 < thimm> | Dag brought up the repotag issue 00:47 < nirik> | yeah, I would like for there to be communication... I don't know what they would like if they don't tell us... 00:47 < thl> | nirik, agreed, but we can't write anything fomalized down afaics 00:47 < thl> | at least nothing with repo names in it 00:47 < quaid> | no CLA is required for epel-devel-list though 00:47 < thl> | quaid, +1 00:47 < nirik> | right. But we should open some communication and find out their concerns and comments. 00:47 < mmcgrath> | thl: we can always create a 3rd party repo page though. 00:48 < thl> | mmcgrath, there is someting about it in the faw already 00:48 < thimm> | nirik: Dag told us, then there were infinite-size threads on his requests and finally his requets was voted down 00:48 < mmcgrath> | 00:48 < quaid> | I think the point is, we are finally ready to formally engage Fedora with all the third-party repos, and this is the place to do it 00:48 < mmcgrath> | thimm: he had requests? or just the repo-tag? 00:48 < quaid> | so anyone who doesn't want to come here is not really interested in cooperating directly, which is OK 00:48 < thl> | quaid, +1 00:48 < thimm> | s/requests/request/ 00:49 < nirik> | yeah, repotag is all I saw... perhaps he has other things we could look at working with him on? 00:49 < thimm> | AFAIK Dag's been "sent" back home. 00:49 < nirik> | ? 00:49 < stahnma> | part of cooperation is not all request items will be honored. They will be considered though, and hopefully have some thought-provoking ideas around the situation 00:49 < mmcgrath> | thimm: thats unfortunate. 00:50 < thl> | dag he reqested some things nobody stepped on to work on 00:50 < mmcgrath> | We can't just do everything 3rd party repos tell us, any more then 3rd party repos will do whatever we ask them. 00:50 < thimm> | But was predictable 00:50 < thimm> | correct 00:50 < thl> | e.g. some kind of "build different branches from one spec file" 00:50 < nirik> | he also chimed in on the macros, and some work has been done on that... 00:50 --- | BobJensen-Away is now known as BobJensen 00:51 < thl> | nirik, rpmforge servers a whole differente user base imho anyway 00:51 < thl> | it has more new stuff 00:51 < thl> | and replaces "core" pacakges 00:51 < thl> | I think there are users for it 00:51 < rdieter> | afaict, rpmforge and centos/Extras folks consider that they were in this space first, so we(epel) should be going to them for help, answers, cooperation. 00:51 < nirik> | sure, but if we have communication we can try and not conflict, etc. 00:51 < thl> | and for our solution "no replaces, only important updates" 00:51 < quaid> | ah, Eitch was the other admin 00:51 < rdieter> | imo, mostly ego, perception. 00:51 * | quaid wrong channel, sorry 00:52 < thimm> | thl: Are you sure rpmforge replaces "core"? 00:52 < rdieter> | thimm: yes. 00:52 --> | wpc4 (William Curley) has joined #fedora-meeting 00:52 < rdieter> | thimm: dag does anyway. 00:53 < nirik> | I talked with z00dax the other day about centos extras... I would really prefer if we don't conflict there, but we will see... 00:53 < mmcgrath> | nirik: with centosplus you mean or centos.karan.org? 00:53 < thimm> | Doesn't epel and cnetos extras already conflict? 00:53 < thl> | thimm, well, there are for example subversion packages at http://dag.wieers.com/rpm/packages/subversion/ 00:53 < thl> | thimm, build for el5, which has subversion already 00:53 < nirik> | mmcgrath: there is a centos "extras" repo... has things like Xfce in it, etc... 00:53 < mmcgrath> | ahh, yes. 00:54 < thimm> | From Dag's page: 00:54 < thimm> | A3. Why should I use RPMforge repositories ? 00:54 < thimm> | There are many good repositories that you can use. Here are someadvantages to our repositories: We don't replace base libraries or important core packages for repositories that are not EOL. 00:54 < nirik> | http://wiki.centos.org/Repositories 00:54 < mmcgrath> | So what I'm hearing is "Yes, we want to work with 3rd party repos but their concerns are taken one at a time and right now we have no idea what they want" ? 00:54 < quaid> | rdieter: I can agree with that, and I don't think EPEL is bringing ego into things, but the situation is that Fedora work needs to be open/visible where all Fedorans can see it, and that means not on some third-party list site somewhere 00:54 < nirik> | right. I think we want to just tell them "hey, we would like to hear your concerns/ideas and ask if you would like to join us" 00:55 < stahnma> | we also need to take the goals of each repo and be sure we understand them 00:55 < rdieter> | quaid: +1 00:55 < mmcgrath> | is there anything we want from 3rd party repos? 00:55 < stahnma> | that will help us be better and make sure we don't conflict as much as safely possible 00:55 < nirik> | BTW, in centos5 yum is in the extras repo I think (replacing core) 00:55 < quaid> | http://fedoraproject.org/wiki/EPEL/CommunicationPlan#head-be699493fb37a6eb90a4841fbc9eaec4358a0044 00:56 * | thl has to leave soon 00:56 < quaid> | we could improve on the communication plan for third-party repos 00:56 * | stahnma tried to work on a few drafts last night, but wasn't sure where to start 00:56 < quaid> | input from you all in that is heartily welcomed! 00:56 < quaid> | yeah, I'm not familiar enough with the people 00:56 < quaid> | what i wrote there is what I feel :) 00:56 < stahnma> | thimm I think you are a valuable resource when talking about and on behalf of 3rd party repos 00:56 < thimm> | centos had a legal battle with RH a couple of years ago 00:56 < mmcgrath> | If 3rd party repos are going to replace our packages, is there an easy way to ensure that there won't be a conflict? 00:57 < thl> | mmcgrath, no 00:57 < nirik> | I think the next step is to mail the maintainers of those repos and invite them to our meetings/mailing lists 00:57 < thimm> | stahnma: I'm not empowered to talk about any 3rd party 00:57 < mmcgrath> | even with coordination? 00:57 < thl> | nirik, they were invited in the past iirc 00:57 < thimm> | Anything I say is my personal viewpoint 00:57 < nirik> | thl: ah, ok. I didn't know that... 00:57 < rdieter> | nirik: been there, done that, you're welcome to keep trying tho. 00:58 < thl> | rdieter, agreed 00:58 < thl> | we really should move on imho 00:58 < stahnma> | thimm: fair enough. I think you can be more help than you realize though :) 00:58 < nirik> | well, I can try and get more input from z00dax. He seems interested in talking sometimes at least. ;) 00:58 < thl> | try to be nice to everyone (including 3rd party) 00:58 < dgilmore> | thimm: you are your own 00:58 < nirik> | moving on++ 00:58 < thimm> | dgilmore: ??? 00:58 < dgilmore> | thimm: i think its a great thing that you are working with the fedora community as you are :) 00:59 < dgilmore> | thimm: your own 3rd party repo 00:59 --> | giallu (Gianluca Sforna) has joined #fedora-meeting 00:59 < thimm> | Ah, OK, even that is not 100% my repo anymore, but I have the lion's parts 00:59 < mmcgrath> | thl: whats next on the list? 00:59 < mmcgrath> | we're coming up on an hour. 01:00 * | nirik happily uses mythtv from atrpms every day. ;) 01:00 < thimm> | nirik: the the RHEL5 build :) 01:00 < thl> | mmcgrath, I#d say we are finished for today 01:00 < thl> | the other two issues should be brought top the list first 01:00 < dgilmore> | ---------- Meeting 01:00 < dgilmore> | Closed -------------------- }}} From Axel.Thimm at ATrpms.net Thu Apr 19 17:53:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 19 Apr 2007 19:53:15 +0200 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <462768EC.4050200@timj.co.uk> References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> <462768EC.4050200@timj.co.uk> Message-ID: <20070419175315.GC13273@neu.nirvana> On Thu, Apr 19, 2007 at 02:04:44PM +0100, Tim Jackson wrote: > You & Axel appear to be implying that you removing repotags is some kind > of threat, which is going to teach a lesson to some of the people who > opposed it in EPEL. Autsch (or Ouch?), I never threaten anyone, I'm against arms and I'm a vegetarian. ;) The ugly thing about repotags is that it is a global decision. Either all repo use it, or it makes no sense to use it, and in fact is even harmfull if you are the last repo using it. That's why the request for maintaining the unpolluted no-repotag RHEL namespace was important. Freshrpms started by not using the repotag (I don't know the reason, but I suspect it was when Matthias changed his buildsystem, at least I think that's what he wrote back then), and it started to rain bug reports that ATrpms would replace "Fedora's" libquicktime and ffmpeg, and for these I knew I didn't have to check whether Fedora has such packages, but the users are not aware of what packages have patent issues in the U.S. and which don't. But I didn't know which repo did contain these incompatible packages and at the beginning I had to ping-pong with the frustrated users until I found out which repo was doing it and until they understood that ATrpms was *not* replacing Fedora Core packages ... So EPEL is not the first to drop repotags, but the first to do so in the RHEL namespace. Until now the no-repotag namespace was reserved for RHEL and all repos respected this by tagging their packages. Now this simple scheme is gone, and as much as I'm a proponent of repotags, I will certainly not be the one that get's the bug rain for "replacing" RHEL-assumed packages. Simply said: The no-repotag decision is inflicting pain onto other repos and they will have to follow EPEL's "lead" into this state, whether they like it or not. But that's rather self-explained, discussed a miriad times on this list, and was known to all people that voted. No threats and it's not going to teach anyone a lesson, neither a constructive or a negative one, it is just creating user and repo frustration and rifts between the existing repos and RHEL communities and the upcoming EPEL community. No win-win, just lose-lose. -- 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 buildsys at fedoraproject.org Fri Apr 20 02:39:55 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 19 Apr 2007 22:39:55 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-04-19 Message-ID: <20070420023955.A1964152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 42 aiccu-2007.01.15-2.el5 apcupsd-3.14.0-2.el5 firmware-tools-1.2.4-1.el5.1 NEW gpsbabel-1.3.3-1.el5 konversation-1.0.1-3.el5 libnet-1.1.2.1-11.el5 NEW libsieve-2.2.5-1.el5 libsmbios-0.13.5-1.el5.1 NEW mimedefang-2.62-1.el5 nagios-2.7-2.1.el5 NEW nagios-plugins-1.4.6-3.el5 NEW otrs-2.1.5-1.el5 NEW perl-Crypt-PasswdMD5-1.3-2.el5 NEW perl-Date-Pcalc-1.2-4.el5 NEW perl-File-ReadBackwards-1.04-2.el5 NEW perl-HTTP-BrowserDetect-0.98-3.el5 NEW perl-MIME-Lite-3.01-5.el5 NEW perl-Pod-Escapes-1.04-5.el5 NEW perl-Pod-Simple-3.04-3.el5 NEW perl-SOAP-Lite-0.68-4.el5 NEW perl-Spiffy-0.30-6.el5 NEW perl-String-ShellQuote-1.03-4.el5 NEW perl-Test-Pod-1.26-1.el5 NEW perl-Unix-Syslog-0.100-9.el5 NEW php-pear-Auth-SASL-1.0.2-4.el5 NEW php-pear-Console-Getargs-1.3.3-1.el5 NEW php-pear-Console-Table-1.0.6-1.el5 NEW php-pear-HTTP-1.4.0-7.el5 NEW php-pear-Mail-1.1.14-1.el5 NEW php-pear-Net-SMTP-1.2.10-1.el5 NEW php-pear-Net-Socket-1.0.7-1.el5 NEW php-pear-XML-Parser-1.2.8-1.el5 php-pecl-zip-1.8.8-1.el5.1 NEW queuegraph-1.1-1.el5 rbldnsd-0.996a-2.el5.1 NEW rpl-1.5.3-4.el5 ssmtp-2.61-11.1.el5.1 tiobench-0.3.3-6.el5 NEW tmda-1.1.11-3.el5 NEW uuid-1.5.1-3.el5 NEW whatmask-1.2-4.el5 yumex-1.9.6-1.0.el5 Packages built and released for Fedora EPEL 4: 9 NEW perl-File-ReadBackwards-1.04-2.el4 NEW perl-HTTP-BrowserDetect-0.98-3.el4 NEW perl-Pod-Escapes-1.04-5.el4 NEW perl-Pod-Simple-3.04-3.el4 NEW perl-Spiffy-0.30-6.el4 NEW perl-String-ShellQuote-1.03-4.el4 NEW perl-Unix-Syslog-0.100-9.el4 NEW rpl-1.5.3-4.el4 NEW whatmask-1.2-4.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri Apr 20 02:42:39 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 19 Apr 2007 22:42:39 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-04-19 Message-ID: <20070420024239.5A442152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 0 Packages built and released for Fedora EPEL 4: 0 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From mastahnke at gmail.com Sat Apr 21 04:14:13 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Fri, 20 Apr 2007 23:14:13 -0500 Subject: What I want in a chair In-Reply-To: <46278257.2090800@redhat.com> References: <46278257.2090800@redhat.com> Message-ID: <7874d9dd0704202114m135df9f6s2d312c76b209d322@mail.gmail.com> I would like a chairperson who works with RHEL/EL as part of their daily job. I think that means everyone involved in EPEL thus far, but I thought I should clarify that. I am not however, *that* concerned about vision for EPEL. We have a steering committee for vision, and I would hope the entire committee would offer input and make decisions on vision and direction. For a chairperson, I want a person who should represent the SIG. Obviously the SIG could handle all of these functions, but one person as a front for the community is great from a contact standpoint and from a chaos-prevention perspective. * coordination of meetings, and events. * Someone with experience using EL as well as developing on it/for it. * Not a dictator, but a facilitator. * Someone who will hear input from Real EL customers and try to work with them. * Someone who will work very hard to please 3rd party relationships, (or at least not hinder them). * A decent project manager, who's good at meeting timetables and status reports. stahnma From buildsys at fedoraproject.org Sat Apr 21 20:20:53 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 21 Apr 2007 16:20:53 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-04-21 Message-ID: <20070421202053.48257152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 14 NEW environment-modules-3.2.5-1.el5 firmware-addon-dell-1.2.11-1.el5.1 NEW freefont-20060126-4.el5 NEW ftnchek-3.3.1-5.el5 NEW gv-3.6.2-2.el5 NEW hdf-4.2r1-12.el5 NEW hdf5-1.6.5-7.el5 libsmbios-0.13.6-1.el5 otrs-2.1.5-2.el5 NEW perl-Sub-Identify-0.02-2.el5 NEW php-pear-Benchmark-1.2.6-1.el5 NEW python-louie-1.1-1.el5 NEW sparse-0.2-1.el5.1 NEW ttywatch-0.14-7.el5.1 Packages built and released for Fedora EPEL 4: 9 NEW environment-modules-3.2.5-1.el4 NEW freefont-20060126-4.el4 NEW ftnchek-3.3.1-5.el4 NEW gv-3.6.2-2.el4 NEW hdf-4.2r1-8.el4 libsmbios-0.13.6-1.el4 otrs-2.1.5-2.el4 NEW perl-Sub-Identify-0.02-2.el4 NEW python-louie-1.1-1.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From orion at cora.nwra.com Mon Apr 23 15:28:23 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 23 Apr 2007 09:28:23 -0600 Subject: xmlrpc-c for EPEL In-Reply-To: <871wietan4.fsf@kosh.bigo.ensc.de> References: <46294756.6010803@cora.nwra.com> <871wietan4.fsf@kosh.bigo.ensc.de> Message-ID: <462CD097.3050603@cora.nwra.com> Enrico Scholz wrote: > Orion Poplawski writes: > >> I'm trying to get cmake into EPEL but it requires xmlrpc-c. Would >> you be able to maintain it for EPEL, or would you like me (or someone >> else) to maintain it? > > I did not looked into EPEL yet and do not know its requirements and > processes. > You can check out the EPEL pages in the wiki for more info. The main differences are layed out here: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies Mainly that you don't upgrade packages in a release without good reason (security fixes) and you don't break compatibility. Otherwise you cat request EPEL branches (EL-4, EL-5) in the normal way or you can ask Dennis Gilmore to do all of your packages wholesale if you want. > Nevertheless, there will be a chicken-egg problem: xmlrpc-c buildrequires > cmake and cmake buildrequires xmlrpc-c. I'm CCing the epel list for how to get around this. Some notes: - cmake can be built with its own copy of xmlrpc-c. Could do this to get it in then shift to system version. - Perhaps we could could grab older versions of the two packages from a compatible FE release and then rebuild? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From rdieter at math.unl.edu Mon Apr 23 15:34:27 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 23 Apr 2007 10:34:27 -0500 Subject: xmlrpc-c for EPEL References: <46294756.6010803@cora.nwra.com> <871wietan4.fsf@kosh.bigo.ensc.de> <462CD097.3050603@cora.nwra.com> Message-ID: Orion Poplawski wrote: > - cmake can be built with its own copy of xmlrpc-c. Could do this to > get it in then shift to system version. This approach looks like the simplest way to bootstrap things, imo. -- Rex From orion at cora.nwra.com Mon Apr 23 16:26:57 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 23 Apr 2007 10:26:57 -0600 Subject: xmlrpc-c for EPEL In-Reply-To: References: <46294756.6010803@cora.nwra.com> <871wietan4.fsf@kosh.bigo.ensc.de> <462CD097.3050603@cora.nwra.com> Message-ID: <462CDE51.6050109@cora.nwra.com> Rex Dieter wrote: > Orion Poplawski wrote: > > >> - cmake can be built with its own copy of xmlrpc-c. Could do this to >> get it in then shift to system version. > > This approach looks like the simplest way to bootstrap things, imo. Yeah, this is pretty easy to do. I've built cmake for EL-4 and EL-5 using the provided libraries. Once xmlrpc-c is built I'll switch back to using the system libraries. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From orion at cora.nwra.com Mon Apr 23 21:42:21 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 23 Apr 2007 15:42:21 -0600 Subject: perl-TimeDate Message-ID: <462D283D.6010307@cora.nwra.com> So, perl-TimeDate is currently a Core package, but does not appear to be part of RHEL. Can we get it into EPEL? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From buildsys at fedoraproject.org Mon Apr 23 21:45:18 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 23 Apr 2007 17:45:18 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-04-23 Message-ID: <20070423214518.DE317152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 10 apcupsd-3.14.0-3.el5 NEW atomix-2.14.0-2.el5 cfengine-2.1.22-2.el5 NEW cmake-2.4.6-2.el5 NEW ebtables-2.0.8-0.8.rc3.el5 NEW php-pear-Crypt-CHAP-1.0.1-1.el5 NEW php-pear-Date-1.4.7-2.el5 NEW php-pear-Date-Holidays-0.17.0-1.el5 NEW php-pear-XML-Serializer-0.18.0-3.el5 NEW php-pear-XML-Util-1.1.4-2.el5 Packages built and released for Fedora EPEL 4: 3 apcupsd-3.14.0-2.el4 NEW cmake-2.4.6-2.el4 NEW ebtables-2.0.8-0.8.rc3.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From fedora at leemhuis.info Tue Apr 24 04:50:05 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 24 Apr 2007 06:50:05 +0200 Subject: perl-TimeDate In-Reply-To: <462D283D.6010307@cora.nwra.com> References: <462D283D.6010307@cora.nwra.com> Message-ID: <462D8C7D.9080002@leemhuis.info> On 23.04.2007 23:42, Orion Poplawski wrote: > So, perl-TimeDate is currently a Core package, but does not appear to be > part of RHEL. Can we get it into EPEL? Hmmm, we didn't hit this yet afaik. I'd say: if it was reviewed during the merge review you (or somebody else) can request the branch for EPEL and maintain it there. That's similar to how Extras packages can get branched for EPEL if the Extras maintainer doesn't want to maintain EPEL packages; see http://fedoraproject.org/wiki/EPEL/ContributorStatus for some more details. If it wasn't reviewed yet then you should put it up for review. CU thl From rdieter at math.unl.edu Tue Apr 24 14:02:11 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 24 Apr 2007 09:02:11 -0500 Subject: perl-TimeDate In-Reply-To: <462D8C7D.9080002@leemhuis.info> References: <462D283D.6010307@cora.nwra.com> <462D8C7D.9080002@leemhuis.info> Message-ID: Thorsten Leemhuis wrote: > > On 23.04.2007 23:42, Orion Poplawski wrote: >> So, perl-TimeDate is currently a Core package, but does not appear to be >> part of RHEL. Can we get it into EPEL? > > Hmmm, we didn't hit this yet afaik. > > I'd say: if it was reviewed during the merge review you (or somebody > else) can request the branch for EPEL and maintain it there. That's > similar to how Extras packages can get branched for EPEL if the Extras > maintainer doesn't want to maintain EPEL packages; see > http://fedoraproject.org/wiki/EPEL/ContributorStatus > for some more details. > > If it wasn't reviewed yet then you should put it up for review. Or help/finish the Merge Review? -- Rex From steve at silug.org Tue Apr 24 13:56:00 2007 From: steve at silug.org (Steven Pritchard) Date: Tue, 24 Apr 2007 08:56:00 -0500 Subject: perl-TimeDate In-Reply-To: References: <462D283D.6010307@cora.nwra.com> <462D8C7D.9080002@leemhuis.info> Message-ID: <20070424135600.GA20209@osiris.silug.org> On Tue, Apr 24, 2007 at 09:02:11AM -0500, Rex Dieter wrote: > Or help/finish the Merge Review? Already done. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226282 Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From fedora at leemhuis.info Tue Apr 24 16:26:12 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 24 Apr 2007 18:26:12 +0200 Subject: thl: What I want in a chair In-Reply-To: <46278257.2090800@redhat.com> References: <46278257.2090800@redhat.com> Message-ID: <462E2FA4.6010102@leemhuis.info> Hi all! I already wrote some things I expect from a EPEL chairmen last week, but here we go again in a different way In short: I think a chair is very important to keep things rolling and working. The chair should be responsible to do the boring tasks that often nobody else does otherwise. That includes for example stuff around the SIG meetings: prepare the meetings, run them, make sure they stay productive, write the meeting summaries (for the public and FESCo) and keep the schedule in the wiki up2date. IOW: get things organized. Further the chair should be the person the Board or FESCo can contact when they want something from EPEL (which sometimes needs to happen in private) -- both FESCo and the Board afaics want to have a single person to contact that is kind of responsible for EPEL. The chair also should try to be available for and respond to questions in FESCo/Board meetings and on the different fedora-lists regarding EPEL if needed. Coordinate the work with other groups like Ambassadors, Infrastructure or Fedora Packaging is also in parts the job of the chair. Having a single person to contact is also helpful if outsiders want to get in touch with EPEL, but can't or don't want to go to a public mailing list. The chairmen also is kind of representing EPEL to the wider public. The chair in his position should also feel responsible to the whole project area -- e.g. try to keep EPEL running smoothly, make contributors, users and other groups (like 3rd party repos) are happy and make sure they feel heard and respected. The chair for his job shouldn't have much special powers. Only some might be needed to "herd the cats. One of those areas are IMHO votings: the recent wiki votings IMHO have shown that coordination and informations is needed before the voting starts; I also saw some occurrences of confusing or "to early" votings in FESCo meetings in the past, that roughly lead to the decision that only the chairmen of the one that runs a IRC-meeting can issue votings (but htat was never written down iirc). Maybe other special powers are needed over time, but I don't think so atm; if they show up then it can be decided by the Steering Committee as a whole when needed. BTW, neither the Steering Committee or its chair should be kind of dictators. We just need a group of people that does the decisions, that itself needs someone on the top IMHO. But the goal is to balance what's best for EPEL, the larger community with is represented by the EPEL SIG, EPEL contributors and EPEL users. CU thl From notting at redhat.com Tue Apr 24 14:13:16 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 24 Apr 2007 10:13:16 -0400 Subject: perl-TimeDate In-Reply-To: References: <462D283D.6010307@cora.nwra.com> <462D8C7D.9080002@leemhuis.info> Message-ID: <20070424141316.GA9051@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > Or help/finish the Merge Review? Along those lines, if someone would like to help finish the review in bug 222347, it would be appreciated. :) Bill From cmc at math.hmc.edu Tue Apr 24 20:04:49 2007 From: cmc at math.hmc.edu (C.M. Connelly) Date: Tue, 24 Apr 2007 13:04:49 -0700 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <4627503E.2050507@timj.co.uk> References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> Message-ID: <8376.1177445089@vosill.math.hmc.edu> Speaking as an end-user/sysadmin, I'm not clear on why the repotag issue is as controversial as it appears to be. From my perspective, RHEL (really mostly CentOS) is the base OS. On top of that, I expect to layer EPEL packages, very likely some packages from RPMForge, and packages from my own local repos (for special needs or for packages that just aren't (and maybe can't be) available from other sources). Having read all the messages on the topic, I agree that the current EPEL steering committee is not out to take over the world or *intends* to imply that other repositories are less important, but I can definitely see how Axel and Dag can *feel* like that's where the committee is coming from, because that's how it feels to me. My understanding of the argument from the no-repotag side is that EPEL is going to avoid package overlap with RHEL (upstream), so they're not technically necessary. But EPEL is still a supplementary repo, just as RPMForge, ATrpms, and my own repos will be. EPEL may avoid package overlap with RHEL, but it's very likely (almost guaranteed) that we will see overlap between EPEL and other repos. Adding the repotag seems like a fairly neutral, technically free, and politically nice option that will help people sort out potential conflicts. Not having the repotag *implies* that EPEL is upstream, pisses off some very skilled and valuable possible contributors and collaborators [*], and makes life just a little bit harder for end users and system administrators trying to support those end users. Claire [*] Suppose that over time EPEL's users and maintainers decide to add a secondary repo with newer packages. Wouldn't it be great to coordinate that repo with other folks maintaining similar repos? Maybe even get them to maintain those newer packages within the EPEL structure? *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Claire Connelly cmc at math.hmc.edu Systems Administrator (909) 621-8754 Department of Mathematics Harvey Mudd College *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Apr 25 09:37:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 25 Apr 2007 11:37:43 +0200 Subject: thl: What I want in a chair In-Reply-To: <462E2FA4.6010102@leemhuis.info> References: <46278257.2090800@redhat.com> <462E2FA4.6010102@leemhuis.info> Message-ID: <20070425093743.GF22427@neu.nirvana> On Tue, Apr 24, 2007 at 06:26:12PM +0200, Thorsten Leemhuis wrote: > The chair should be responsible to do the boring tasks that often nobody > else does otherwise. That's OK. The following is not. > [which sometimes needs to happen in private], [person for non-public > contact] "Too many secrets", what happend to Fedora's original leitmotiv of full transparency? Sure, some things are discussed in PM, but defining a role as such and even twice? I would go the opposite direction and define the chair as accounting to the committee and asking the committee for any stealth operations. > The chair for his job shouldn't have much special powers. Only some > might be needed to "herd the cats. One of those areas are IMHO votings: Wow, not much special powers, but he decides on when what gets voted? > the recent wiki votings IMHO have shown that coordination and > informations is needed before the voting starts; No. These votings have shown that there were two items that you personally objected against over two months and did all that was in your power to avoid getting it to a vote. These items even made us have a steering committee from your preferred "we decide on consensus"-model (so it really is an irony, that originally you supported an anarchy-model and now you push to a presidency model), so we could finalize them with a vote. But you continued to block voting and raising bars, producing semi-technical arguments until finally the votes had the outcome you desired. So, will such a powerful chairman manage this better? From your POV, if you get elected to be the chair, certainly, from my POV it will become even more difficult to get anything voted lest even to have a vote pass. Last time we needed two months to get to the vote, what will it be with a Thorsten as solely empowered to issue votings? Two years? No, thanks. I think the very bad handling of these votes show that we need a more democratic and open system where everyone in the committee (or even the SIG) can issue votings, not that a chairman can block these to his liking. -- 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 Wed Apr 25 09:49:51 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 25 Apr 2007 11:49:51 +0200 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <8376.1177445089@vosill.math.hmc.edu> References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> <8376.1177445089@vosill.math.hmc.edu> Message-ID: <20070425094951.GG22427@neu.nirvana> On Tue, Apr 24, 2007 at 01:04:49PM -0700, C.M. Connelly wrote: > Speaking as an end-user/sysadmin, I'm not clear on why the repotag > issue is as controversial as it appears to be. > > From my perspective, RHEL (really mostly CentOS) is the base OS. > On top of that, I expect to layer EPEL packages, very likely some > packages from RPMForge, and packages from my own local repos (for > special needs or for packages that just aren't (and maybe can't > be) available from other sources). > > Having read all the messages on the topic, I agree that the > current EPEL steering committee is not out to take over the world > or *intends* to imply that other repositories are less important, > but I can definitely see how Axel and Dag can *feel* like that's > where the committee is coming from, because that's how it feels to > me. It is more than a bad feeling. If one repo drops repotags the whole repotag system is broken. So the continued lack of repotags forces the other repos to follow along even though they are strong belivers of repotags. Someone from the committee said that since he doesn't require the other repos to do anything with their repotags, why should the other repos require him to do something. He didn't realize that choices of EPEL affect other repos (and vice versa, of course). So the external request on repotags was not just a signal to play nice and lay down future politics, but in fact a request to not be disruptive on current RHEL community standards. > My understanding of the argument from the no-repotag side is that > EPEL is going to avoid package overlap with RHEL (upstream), so > they're not technically necessary. Still they are, of will you know by first glance whether yum reporting conflicts between foo-1.2.3-4.el5 and bar-5.6.7-8.el5 will be due to one package or both coming from EPEL and RHEL? Similar issues as with other 3rd parties will pop up. And now that the other repos are forced to drop the repotags mid-term as well, there will also be confusion between RHEL and any 3rd party repo. RHEL support will certainly be fascinated by the outcome of events. > But EPEL is still a supplementary repo, just as RPMForge, ATrpms, > and my own repos will be. EPEL may avoid package overlap with > RHEL, but it's very likely (almost guaranteed) that we will see > overlap between EPEL and other repos. Adding the repotag seems > like a fairly neutral, technically free, and politically nice > option that will help people sort out potential conflicts. Not > having the repotag *implies* that EPEL is upstream, pisses off > some very skilled and valuable possible contributors and > collaborators [*], and makes life just a little bit harder for end > users and system administrators trying to support those end users. Thanks, you couldn't have summarized it better. But the key persons against repotags were aware of this and still voted them down. Now everyone can ask himself why that happened. > Claire > > [*] Suppose that over time EPEL's users and maintainers decide > to add a secondary repo with newer packages. Wouldn't it be > great to coordinate that repo with other folks maintaining > similar repos? Maybe even get them to maintain those newer > packages within the EPEL structure? > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > Claire Connelly cmc at math.hmc.edu > Systems Administrator (909) 621-8754 > Department of Mathematics Harvey Mudd College > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- 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 Wed Apr 25 10:55:49 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 25 Apr 2007 12:55:49 +0200 Subject: Topics for todays EPEL SIG meeting Message-ID: <462F33B5.2090804@leemhuis.info> Hi all! Here are the IMHO main topics the SIG Meeting probably should look at in todays meeting (17:00 UTC, #fedora-meeting on freenode): /topic EPEL Meeting -- mass rebuild for RHEL5 /topic EPEL Meeting -- chairmen /topic EPEL Meeting -- shortcut for branching -- dgilmore? /topic EPEL Meeting -- Communication plan for enterprise customers/ISVs/IHVs -- stahnma, quaid Looks like I'll miss todays meeting as I have to join something work related -- that's scheduled one hour earlier than the EPEL SIG Meeting, and will probably take until after it ends. No keyboards or computers nearby. Sorry. Nevertheless, here are some things from my side: - mass rebuild for RHEL5 -> somebody should check how much stuff got rebuilded; we should decide what to do with the rest of the arch packages. My vote: add a ".1" to release, commit, tag, build after a additional wait period of 48 hours; I really want to get this of the table. - chairmen -> I'm willing to to that job for the next months. Most of you know how I worked in FESCo, which as such is my reference ;-) My main goal is to get EPEL really speed up now. - "shortcut for branching -- dgilmore?" -> Now that we have RHEL5 on the builders and the rebuild is done soon I really want to give a "start now" signal to Fedora contributors that are waiting for it (there are some that do). But I fear questions like "do I have to go through bugzilla for all of my X packages to ask for EPEL branches?" or "what to do with packages that were reviewed in the early days (e.g. before we we used bugzilla)". We should find a solution for those questions and document them somewhere before we give the "start now" signal. But we need a CVS admin for that that tells us how this shortcut could looks like. dgilmore? CU thl From mailing-lists at hughesjr.com Wed Apr 25 12:38:08 2007 From: mailing-lists at hughesjr.com (Johnny Hughes) Date: Wed, 25 Apr 2007 07:38:08 -0500 Subject: Collaboration Message-ID: <1177504688.20302.73.camel@myth.home.local> ===================================================================== Main Entry: col?lab?o?rate Pronunciation: k&-'la-b&-"rAt Etymology: Late Latin collaboratus, past participle of collaborare to labor together, from Latin com- + laborare to labor 1 : to work jointly with others or together especially in an intellectual endeavor 2 : to cooperate with an agency or instrumentality with which one is not immediately connected ===================================================================== Question1: If RPMforge has a perfectly working ClamAV for EL5, and if we are collaborating, why would EPEL build ClamAV? Question2: If ATRPMS has a perfectly working nx/freenx for EL5, and if we are collaborating, why would EPEL build nx / freenx? ===================================================================== Answer to both ... EPEL wants to be "THE" Master 3rd Party repo, not just a 3rd Party Repo. There can be no misinterpreting that, it is just plain fact. If we were collaborating, EPEL would build things not already in RPMforge or ATRPMS or CentOS Extras. We are not collaborating, we are consolidating under the rule of the EPEL team. So if that happens and if EPEL is maintaining 8000 packages with the help of the Dag, Dries, Alex, Rex, the CentOS Devels .. then how long till this bright idea: Hmmm ... This EPEL thing is going so good, what about a collaborative Fedora EL to consolidate all the rebuilds? It is only a matter of time until that happens, as far as I can see. Now, if EPEL is really interested in collaboration, and not domination, then some assigning of master packages to RPMForge and/or ATRPMS ... and using existing RPMForge and ATRPMs binary packages in the mock build repo definitions would go a long way toward quieting the domination speculation. All I see, frankly, is this: EPEL is "THE" 3rd Party repo for Red Hat based EL ... join us, play by our rules, and submit all your packages here. Integration ... sure, the other guys can join us and play by our rules or not. Collaboration ... sure, the other guys can stop what they are doing and join us and play by our rules or not. Why does that make me even the slightest bit nervous ... I mean, Red Hat would never ever pull the plug on supporting Fedora EPEL (Or the mythical Fedora EL, if it happened and put CentOS out of business), would they? Of course they would if it enhanced their business model. Anyone here ever heard of Red Hat 9? I am not ready to hitch CentOS to this model to see it be made irrelevant by the next progression in this process ... so what assurances are there that the master plan is not to totally dominate the community Red Hat based EL market (a position that CentOS currently holds based on the extremely hard work of about 20 people, the donations of hundreds of ISPs and Mirror Providers, etc.). Getting tied back in to same process/entity that fragmented this market in the first place does not seem very logical to me. Thanks, Johnny Hughes -------------- 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 Wed Apr 25 13:24:14 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 25 Apr 2007 08:24:14 -0500 Subject: Collaboration In-Reply-To: <1177504688.20302.73.camel@myth.home.local> References: <1177504688.20302.73.camel@myth.home.local> Message-ID: <462F567E.8030405@redhat.com> Johnny Hughes wrote: > Question1: > If RPMforge has a perfectly working ClamAV for EL5, and if we are > collaborating, why would EPEL build ClamAV? > > You'd have to talk with Enrico Scholz, the ClamAV maintainer. Perhaps the RPMForge RPM did not meet his needs. > Question2: > If ATRPMS has a perfectly working nx/freenx for EL5, and if we are > collaborating, why would EPEL build nx / freenx? > > To my knowledge, they haven't. > Answer to both ... EPEL wants to be "THE" Master 3rd Party repo, not > just a 3rd Party Repo. There can be no misinterpreting that, it is just > plain fact. > > I understand why this fear would exist. Afterall there are hundreds of extras developers. We're not aiming to be 'the one repo to rule them all'. We're aiming to rebuild Fedora's extras packages for Enterprise Linux. I'm not saying I agree or disagree with the thread, but I will say this. The 3rd party repos are holding EPEL to a double standard. Take ClamAV for example. Thimm, rpms.net, and kbs all have clamav RPM's but, for some reason, you expect EPEL not to have one? -Mike From mail-lists at karan.org Wed Apr 25 13:33:08 2007 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 25 Apr 2007 14:33:08 +0100 Subject: Collaboration In-Reply-To: <462F567E.8030405@redhat.com> References: <1177504688.20302.73.camel@myth.home.local> <462F567E.8030405@redhat.com> Message-ID: <462F5894.20303@karan.org> Mike McGrath wrote: > I'm not saying I agree or disagree with the thread, but I will say > this. The 3rd party repos are holding EPEL to a double standard. Take > ClamAV for example. Thimm, rpms.net, and kbs all have clamav RPM's but, > for some reason, you expect EPEL not to have one? Just to be clear here, I saw the issue and I've stopped building clamav, and the last build provided a decent upgrade path to the rpmforge one - since the clamav project itself considers rpmforge to be the official rpm packages. - KB From mmcgrath at redhat.com Wed Apr 25 13:36:28 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 25 Apr 2007 08:36:28 -0500 Subject: Collaboration In-Reply-To: <462F5894.20303@karan.org> References: <1177504688.20302.73.camel@myth.home.local> <462F567E.8030405@redhat.com> <462F5894.20303@karan.org> Message-ID: <462F595C.30104@redhat.com> Karanbir Singh wrote: > Mike McGrath wrote: > >> I'm not saying I agree or disagree with the thread, but I will say >> this. The 3rd party repos are holding EPEL to a double standard. Take >> ClamAV for example. Thimm, rpms.net, and kbs all have clamav RPM's but, >> for some reason, you expect EPEL not to have one? >> > > Just to be clear here, I saw the issue and I've stopped building clamav, > and the last build provided a decent upgrade path to the rpmforge one - > since the clamav project itself considers rpmforge to be the official > rpm packages. > Thimm? -Mike From wolfy at nobugconsulting.ro Wed Apr 25 13:39:14 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 25 Apr 2007 16:39:14 +0300 Subject: Collaboration In-Reply-To: <462F5894.20303@karan.org> References: <1177504688.20302.73.camel@myth.home.local> <462F567E.8030405@redhat.com> <462F5894.20303@karan.org> Message-ID: <462F5A02.6050502@nobugconsulting.ro> Karanbir Singh wrote: > Mike McGrath wrote: > >> I'm not saying I agree or disagree with the thread, but I will say >> this. The 3rd party repos are holding EPEL to a double standard. Take >> ClamAV for example. Thimm, rpms.net, and kbs all have clamav RPM's but, >> for some reason, you expect EPEL not to have one? >> > > Just to be clear here, I saw the issue and I've stopped building clamav, > and the last build provided a decent upgrade path to the rpmforge one - > since the clamav project itself considers rpmforge to be the official > rpm packages. > > - KB FWIW: I am using dag's (rpmforge) clamav on centos 4 and FC1 for quite sometime (2 or maybe 3 years ?) and had 0 issues with it. From mmcgrath at redhat.com Wed Apr 25 13:45:31 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 25 Apr 2007 08:45:31 -0500 Subject: Collaboration In-Reply-To: <1177504688.20302.73.camel@myth.home.local> References: <1177504688.20302.73.camel@myth.home.local> Message-ID: <462F5B7B.9050407@redhat.com> Johnny Hughes wrote: > Question1: > If RPMforge has a perfectly working ClamAV for EL5, and if we are > collaborating, why would EPEL build ClamAV? > Ok, now to get back to business. First of all. We are a reasonable people, seriously. This shouldn't have been a question. This should have been a proposal with a fully working model. As such, I'll try this: RPMforge has a perfectly working ClamAV for EL5 (and presumably EL4). How can we go about getting this RPM as THEE blessed RPM for all of our repos? Well there's a few technical ways to do this that I see. 1) Have 1 authoritative CVS for all of our packages (not practical) 2) On a package by package basis have the MAINTAINERS decide what the authoritative RPM will be 3) Just distribute the binary RPM's blindly never keeping the source on CVS (I don't think anyone would like that) Number 2 actually sounds very reasonable to me for a couple of reasons. 1) It allows ALL repos to have exceptions. For example if thimm wants to put some closed source codec in some package that EPEL just can't... this would allow for that. 2) I have a hunch it will scale well. All of the coordination happens between individuals, no voting. You have to understand. The SIG doesn't build and maintain packages. Individuals do and individuals (like myself at least) could use some help maintaining packages. As a side note, I don't know what the packaging guidelines for the 3rd party repos are. Where can I find them? Remember EPEL won't be updating their packages to the latest and greatest by rule. Do the other repositories follow this guideline? If not then for those packages we're filling different needs. -Mike From mastahnke at gmail.com Wed Apr 25 13:46:59 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 25 Apr 2007 08:46:59 -0500 Subject: Topics for todays EPEL SIG meeting In-Reply-To: <462F33B5.2090804@leemhuis.info> References: <462F33B5.2090804@leemhuis.info> Message-ID: <7874d9dd0704250646m48873242t9d43d8f00f80585b@mail.gmail.com> On 4/25/07, Thorsten Leemhuis wrote: > Hi all! > > Here are the IMHO main topics the SIG Meeting probably should look at in > todays meeting (17:00 UTC, #fedora-meeting on freenode): > > /topic EPEL Meeting -- mass rebuild for RHEL5 > /topic EPEL Meeting -- chairmen > /topic EPEL Meeting -- shortcut for branching -- dgilmore? > /topic EPEL Meeting -- Communication plan for enterprise > customers/ISVs/IHVs -- stahnma, quaid > > Looks like I'll miss todays meeting as I have to join something work > related -- that's scheduled one hour earlier than the EPEL SIG Meeting, > and will probably take until after it ends. No keyboards or computers > nearby. Sorry. > > Nevertheless, here are some things from my side: > > - mass rebuild for RHEL5 -> somebody should check how much stuff got > rebuilded; we should decide what to do with the rest of the arch > packages. My vote: add a ".1" to release, commit, tag, build after a > additional wait period of 48 hours; I really want to get this of the table. > > - chairmen -> I'm willing to to that job for the next months. Most of > you know how I worked in FESCo, which as such is my reference ;-) My > main goal is to get EPEL really speed up now. > > - "shortcut for branching -- dgilmore?" -> Now that we have RHEL5 on the > builders and the rebuild is done soon I really want to give a "start > now" signal to Fedora contributors that are waiting for it (there are > some that do). But I fear questions like "do I have to go through > bugzilla for all of my X packages to ask for EPEL branches?" or "what to > do with packages that were reviewed in the early days (e.g. before we we > used bugzilla)". We should find a solution for those questions and > document them somewhere before we give the "start now" signal. But we > need a CVS admin for that that tells us how this shortcut could looks > like. dgilmore? > > CU > thl > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > I am also unable to attend today. I am traveling on business and have appointments mid-day. (Have I mentioned this time-slot isn't the greatest for those of us who don't work at RH or live in Europe?) Also, I have query to dgilmore about the mirroring and links for epel-release? Can I use mirrorlist now and have the epel-release package work with 5Client, 5Server, 4[AS|ES|WS] ? I haven't made any headway on the communication plan this week. stahnma From rdieter at math.unl.edu Wed Apr 25 15:39:50 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 25 Apr 2007 10:39:50 -0500 Subject: Collaboration References: <1177504688.20302.73.camel@myth.home.local> Message-ID: Johnny Hughes wrote: > Question1: > If RPMforge has a perfectly working ClamAV for EL5, and if we are > collaborating, why would EPEL build ClamAV? > Question2: > If ATRPMS has a perfectly working nx/freenx for EL5, and if we are > collaborating, why would EPEL build nx / freenx? Other reasonable answers to the general assertion of "why does EPEL build package X already in repo Y": * EPEL (and Fedora) is self-hosting and can't BuildRequires/Requires packages from other repos. * why force users to use N different repos to get all the packages they want? > Why does that make me even the slightest bit nervous ... I mean, Red Hat > would never ever pull the plug on supporting Fedora EPEL A good question that deserves a good answer: Red Hat isn't behind EPEL, *Fedora* is. In short, EPEL can/would exist with or without Red Hat's blessing/help (of course, things are much better *with*). > (Or the mythical Fedora EL, if it happened and put CentOS out > of business), would they? Doesn't really fit Fedora's objectives, so I don't see any chance of this (soon, anyway). -- Rex From lists at timj.co.uk Wed Apr 25 16:49:33 2007 From: lists at timj.co.uk (Tim Jackson) Date: Wed, 25 Apr 2007 17:49:33 +0100 Subject: Collaboration In-Reply-To: <1177504688.20302.73.camel@myth.home.local> References: <1177504688.20302.73.camel@myth.home.local> Message-ID: <462F869D.5060600@timj.co.uk> Johnny Hughes wrote: > If RPMforge has a perfectly working ClamAV for EL5, and if we are > collaborating, why would EPEL build ClamAV? a) Because EPEL is independent, and should have infrastructure which is independent of other entities. This is a basic principle of running any self-contained project. It does NOT exclude collaboration, unless your definition of "collaboration" is particularly narrow. b) Because the standards, processes etc. of the repos are different and therefore, as we have already established, they are serving different purposes > Answer to both ... EPEL wants to be "THE" Master 3rd Party repo, not > just a 3rd Party Repo. There can be no misinterpreting that, it is just > plain fact. As an existing user of various repos including Dag & AT, a tentative contributor to EPEL (following FE) then I'm still not sure that that's true and it's definitely not "fact". However, I do believe I understand why you might feel that way - in fact I had a lengthy and good-humoured discussion in person with Dag about this very topic at Linux World last November. BEFORE READING THE FOLLOWING PARAGRAPHS, READ THEM **PROPERLY**, DO NOT INFER THINGS THAT AREN'T THERE AND DO NOT EVEN CONSIDER FLAMING ME UNLESS/UNTIL YOU HAVE READ THEM PROPERLY AND UNLESS YOU RECOGNISE THAT I POSITIVELY AND EXPLICITLY ***LIKE*** DAG/ATRPMS/KB/CENTOS etc. What *I* see is that EPEL has a collaborative element that *in my opinion* is lacking (or at least lacking visibility) to a lesser or greater extent in other repos. That's **not** a criticism, it's an observation. What I mean by this is that, to a large extent, "Dag repo = Dag Wieers", and "ATrpms = Axel Thimm". I could be wrong, but I don't think that Dag, Axel et al. have the kind of procedures, processes, open contributory model etc. that EPEL effectively already has (based on the excellent work of Fedora Extras). Nor do I see that they're likely to grow that any time soon. Let's look at some examples (THIS ***IS*** ***NOT*** bashing of other people's efforts. I cannot emphasise that enough. It is just a superficial look and an attempt to bring this discussion onto some concrete ground) RPMforge http://rpmforge.net/manifest.php is fine, but it's 1 page. http://rpmforge.net/packager/ is minimal at best. "Documentation" is a non-existent link from it. http://rpmforge.net/packager/persona/ indicates that it is still just 3 people. None of this has changed significantly to my recollection since RPMforge.net was set up some time ago. I don't see an easy or visible way for me as an outsider to get involved at a genuine peer level. Karanbir http://centos.karan.org/ has effectively zero docs, and invites all contributions to be directed at Karanbir personally. This has not changed significantly to my recollection since the start. I don't see an easy or visible way for me as an outsider to get involved at a genuine peer level. CentOS http://www.centos.org/ (Information -> Team -> Members) suggests that CentOS Extras is a 1 person effort by Jim Perrin. "Wiki -> Contribution Policy -> Packages" is a 1-pager which tells you how to contribute to the "contrib" repo (not Extras or Addons), and that "contribution" appears to involve passing stuff to someone else, rather than playing an active role yourself. I don't see an easy or visible way for me as an outsider to get involved at a genuine peer level. Fedora/EPEL http://fedoraproject.org/ has hundreds of pages of largely high quality content, contributed by multiple people. It's not always organised or perfect, but it does have tremendous depth from high level/policy issues to low level technical things. It has an open infrastructure, SIGs and a huge base of contributors. It's easy for me as an outsider to see the road towards being involved at a genuine peer level. So, Fedora/EPEL aside, the above projects strike me (rightly or wrongly) as largely "closed" circles. That's *not* to say the people involved are not open-minded or not open to help. But the projects appear to be highly dependent on individuals or very small groups. (This is natural, human, and not something to be surprised about). On the contrary, FE has an established and visibly open model which as a project is increasingly resilient to the disappearance of individuals. (This isn't hypothetical; we already have examples of significant contributors disappearing and yet the project continues OK). Does this make EPEL "better"? Are these things negative reflections on any of the above efforts? Emphatically NO! Specifically, the above projects do nothing but reflect immensely well on the hard-working people behind them. If anything, I think some of the third party repos have the edge, technically, over Fedora/EPEL due to the exceptional technical skills of their owners. The lack of process instead, to me, merely reflects the fact that implementing an open collaborative model is extremely difficult, *enormously* time-consuming and something that no one person (or even a small group) can really do alone. Writing policies, setting up collaboration systems, encouraging others to contribute and dealing with politics/in-fighting is all, frankly, boring and it doesn't get the day job done when you can just go ahead and build what you know are great packages. Heck, that's why I maintain a private repository: I've no way got enough time in the day to do all that stuff. What I see in Fedora Extras (and by extension EPEL) is a project that has enough momentum, enough "grassroots" interest, and the infrastructure in place to facilitate a truly open process, and one which I can become incrementally involved with as I see fit. Now, some people might think all of the above is just unnecessary bureaucracy, and they're 100% entitled to that opinion. They may place a packager's established record and clear personal skill as the #1 priority, with all other things like documentation, processes, collaborative input etc. a distant second. On the other hand, some people feel that the processes are *more* important, that good technical quality will naturally follow almost as a side effect, and that a clear, comprehensive and documented collaboration model (with more or less equal access to all contributors) gives one a sense of confidence that is important (particularly in an EL environment). So you could see this as more of a "bureaucracy" debate rather than a "technical" one, and I see that as one of the potential differences between EPEL and other repos. > If we were collaborating, EPEL would build things not already in > RPMforge or ATRPMS or CentOS Extras. I disagree in the strongest terms. That's a very superficial and specific type of collaboration. Collaboration does not mean "only 1 copy of anything". It means collaborating at an intellectual level (as you yourself quoted!). The binary packages are just the end output. The process to get there is where the real collaboration takes place. There are many other possibilities too: sure, why not make Dag repo the "master" for the packages that Dag wants to "own", assuming that his policies and the EPEL policies precisely correspond in respect of those packages? I would support that. But we should still sync it into EPEL CVS and build it in the EPEL buildsys. (In many ways like Dag/Matthias/Dries have been doing with RPMforge, though I'm not sure to what extent their infrastructure is shared vs independent) And as I said in an earlier post, "collaboration" means personal collaboration, not just technical collaboration. Personal collaboration is the important bit. How that happens technically is an implementation detail. > Why does that make me even the slightest bit nervous ... I mean, Red Hat > would never ever pull the plug on supporting Fedora EPEL (Or the > mythical Fedora EL, if it happened and put CentOS out of business), > would they? Of course they would if it enhanced their business model. > Anyone here ever heard of Red Hat 9? With an open collaborative process, open CVS, open documentation etc. then I don't see what's to stop someone else (e.g. CentOS) taking the whole EPEL thing wholesale tomorrow and continuing the effort even if RH did decide to back out. I'm not sure what relevance RH9 has; frankly, I think that splitting RHL into EL and Fedora was the best thing RH ever did (and no, I'm not an RH employee), but I don't think this is either the time or place to debate that. Tim From nando at ccrma.Stanford.EDU Wed Apr 25 18:14:14 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Wed, 25 Apr 2007 11:14:14 -0700 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <20070425094951.GG22427@neu.nirvana> References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> <8376.1177445089@vosill.math.hmc.edu> <20070425094951.GG22427@neu.nirvana> Message-ID: <1177524854.4080.9.camel@cmn3.stanford.edu> On Wed, 2007-04-25 at 11:49 +0200, Axel Thimm wrote: > On Tue, Apr 24, 2007 at 01:04:49PM -0700, C.M. Connelly wrote: > > Speaking as an end-user/sysadmin, I'm not clear on why the repotag > > issue is as controversial as it appears to be. > > > > From my perspective, RHEL (really mostly CentOS) is the base OS. > > On top of that, I expect to layer EPEL packages, very likely some > > packages from RPMForge, and packages from my own local repos (for > > special needs or for packages that just aren't (and maybe can't > > be) available from other sources). > > > > Having read all the messages on the topic, I agree that the > > current EPEL steering committee is not out to take over the world > > or *intends* to imply that other repositories are less important, > > but I can definitely see how Axel and Dag can *feel* like that's > > where the committee is coming from, because that's how it feels to > > me. > > It is more than a bad feeling. If one repo drops repotags the whole > repotag system is broken. So the continued lack of repotags forces the > other repos to follow along even though they are strong belivers of > repotags. > [MUNCH] I don't get this. If one repo drops repotags (or a newcomer does not adopt them as this seems to be the case to me :-), then that repo does not have repotags. So? That does not force anyone to drop them to match their choice. If there is just _one_ repo that does not use repotags then the "system" still works, anything without repotags belongs to that repo, if more repos do that then things get progressively more confusing. If/when I package for rhel I will keep using ".ccrma" in there. -- Fernando From Axel.Thimm at ATrpms.net Wed Apr 25 18:26:33 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 25 Apr 2007 20:26:33 +0200 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <1177524854.4080.9.camel@cmn3.stanford.edu> References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> <8376.1177445089@vosill.math.hmc.edu> <20070425094951.GG22427@neu.nirvana> <1177524854.4080.9.camel@cmn3.stanford.edu> Message-ID: <20070425182633.GZ11831@neu.nirvana> On Wed, Apr 25, 2007 at 11:14:14AM -0700, Fernando Lopez-Lezcano wrote: > On Wed, 2007-04-25 at 11:49 +0200, Axel Thimm wrote: > > On Tue, Apr 24, 2007 at 01:04:49PM -0700, C.M. Connelly wrote: > > > Speaking as an end-user/sysadmin, I'm not clear on why the repotag > > > issue is as controversial as it appears to be. > > > > > > From my perspective, RHEL (really mostly CentOS) is the base OS. > > > On top of that, I expect to layer EPEL packages, very likely some > > > packages from RPMForge, and packages from my own local repos (for > > > special needs or for packages that just aren't (and maybe can't > > > be) available from other sources). > > > > > > Having read all the messages on the topic, I agree that the > > > current EPEL steering committee is not out to take over the world > > > or *intends* to imply that other repositories are less important, > > > but I can definitely see how Axel and Dag can *feel* like that's > > > where the committee is coming from, because that's how it feels to > > > me. > > > > It is more than a bad feeling. If one repo drops repotags the whole > > repotag system is broken. So the continued lack of repotags forces the > > other repos to follow along even though they are strong belivers of > > repotags. > > [MUNCH] > > I don't get this. > > If one repo drops repotags (or a newcomer does not adopt them as this > seems to be the case to me :-), then that repo does not have repotags. > So? That does not force anyone to drop them to match their choice. If > there is just _one_ repo that does not use repotags then the "system" > still works, anything without repotags belongs to that repo, if more > repos do that then things get progressively more confusing. If/when I > package for rhel I will keep using ".ccrma" in there. freshrpms recently dropped repotags. Ever since for the packages that atrpms and freshrpms share I get reports like "why does atrpms replace ffmpeg and lame from the official Fedora Core distribution". I have these in bugzilla, atrpms list, fedora lists and pm. For users knowledgable about what Fedora can contain or not, this is less an issue, but all the novice, incomplete reports (which are a supporters nightmare) make it to the nice playing party. As it doesn't only affect 3rd party repos cross-relationship, but even the relationship to the vendor itself. E.g. EPEL packages become indistinguishable for RHEL packages and I bet that there will be tickets opened against RHEL because the user thought that foo-1.2.3-4.el5 breaking in presence of bar-1.2.3-4.el5 is a problem of foo, while after wasting RHEL support time it will be discovered that while foo is indeed from RHEL, bar was from EPEL and the whole constallation was unsupported to begin with. But the latter only affects the relationship of EPEL to RHEL. -- 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 buildsys at fedoraproject.org Wed Apr 25 20:33:12 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 25 Apr 2007 16:33:12 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-04-25 Message-ID: <20070425203312.87FEA152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 11 denyhosts-2.6-4.el5 NEW ncftp-3.2.0-3.el5 NEW php-pear-DB-DataObject-1.8.5-2.el5 NEW php-pear-MDB2-2.4.0-1.el5 NEW php-pear-MDB2-Driver-mysql-1.4.0-1.el5 NEW php-pear-Validate-0.7.0-1.el5 NEW php-pear-Validate-Finance-CreditCard-0.5.2-1.el5 NEW php-pear-XML-Beautifier-1.1-2.el5 NEW php-pear-XML-RSS-0.9.10-3.el5 rrdtool-1.2.19-2.el5 NEW spr-05.01.00-3.el5 Packages built and released for Fedora EPEL 4: 5 NEW SIBsim4-0.15-1.el4 denyhosts-2.6-4.el4 NEW ncftp-3.2.0-3.el4 rrdtool-1.2.19-2.el4 NEW spr-05.01.00-3.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From orion at cora.nwra.com Wed Apr 25 20:37:52 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 25 Apr 2007 14:37:52 -0600 Subject: rsync access to EPEL? Message-ID: <462FBC20.6090802@cora.nwra.com> Any rsync access to EPEL yet? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From smooge at gmail.com Wed Apr 25 21:19:17 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 25 Apr 2007 15:19:17 -0600 Subject: Collaboration In-Reply-To: <1177504688.20302.73.camel@myth.home.local> References: <1177504688.20302.73.camel@myth.home.local> Message-ID: <80d7e4090704251419s21d6ad68y134ba732aea4d624@mail.gmail.com> On 4/25/07, Johnny Hughes wrote: > > Answer to both ... EPEL wants to be "THE" Master 3rd Party repo, not > just a 3rd Party Repo. There can be no misinterpreting that, it is just > plain fact. > Or it wants to be another repository. There are multiple reasons for multiple repositories containing the same RPM with different options. No one repository is going to meet those needs and no one repository is going to rule them all. But we all seem to be forgetting that (me included in a nice rant that was almost as long as this one that I didnt send because I couldnt find an appropriate Devils Advocate definition). The questions I have NOT seen really asked or answered with serious thought/debate are: 1) What do system administrators want in the way of packages, and how many different repositories are needed to support say 80% of the audience? Ideas: some people need latest stuff on old OS some people need old stuff on latest OS some people need stuff supported for 7 years some people need stuff supported for 6 months 2) What can help system administrators meet multiple needs of their customers? 3) How can the various repositories advertise what they are aiming towards so that customers know how to meet their needs better? 4) How would documenting outstanding best practices, needs that each repository is using better benefit everyone. 5) How can repositories better figure out where they can share items that meet common best practices. 6) How can we ask the customer questions of: Does mixing repositories have problems? How can I mititagate these problems if I have to mix repos? If I can't mitigate problems.. can there be a common repo where my needs are met? 7) How we can all remember that at the end of the day, most problems are due to incompetence, accident, or forgetting to check ones ego at the door.. and not malice aimed at others. In the end, these are part of the most important questions that any business, consultant, organization can answer: Who is my customer, and how do I give them better service? These are MORE important questions that knowing what options we pass on EL3.8 versus EL4.4 or how many build servers we need, or even repotags (which I like)... because most of the answers to those questions are best answered by knowing what our customers want/need/etc. Does this mean that EPEL should drop what its doing and stop putting packages in its repository.. no more than it means that FreshRPMs, DAG, ATrpms, etc all have to pull out their differing versions of Clamav/perl-yet-another-module/etc. It does mean that each person should come to a to be determined table in the future.. with some idea of how to answer the above questions and know why they differ from the other sites. -- 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 nando at ccrma.Stanford.EDU Wed Apr 25 21:51:50 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Wed, 25 Apr 2007 14:51:50 -0700 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <20070425182633.GZ11831@neu.nirvana> References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> <8376.1177445089@vosill.math.hmc.edu> <20070425094951.GG22427@neu.nirvana> <1177524854.4080.9.camel@cmn3.stanford.edu> <20070425182633.GZ11831@neu.nirvana> Message-ID: <1177537910.4080.36.camel@cmn3.stanford.edu> On Wed, 2007-04-25 at 20:26 +0200, Axel Thimm wrote: > On Wed, Apr 25, 2007 at 11:14:14AM -0700, Fernando Lopez-Lezcano wrote: > > On Wed, 2007-04-25 at 11:49 +0200, Axel Thimm wrote: > > > On Tue, Apr 24, 2007 at 01:04:49PM -0700, C.M. Connelly wrote: > > > > Speaking as an end-user/sysadmin, I'm not clear on why the repotag > > > > issue is as controversial as it appears to be. > > > > > > > > From my perspective, RHEL (really mostly CentOS) is the base OS. > > > > On top of that, I expect to layer EPEL packages, very likely some > > > > packages from RPMForge, and packages from my own local repos (for > > > > special needs or for packages that just aren't (and maybe can't > > > > be) available from other sources). > > > > > > > > Having read all the messages on the topic, I agree that the > > > > current EPEL steering committee is not out to take over the world > > > > or *intends* to imply that other repositories are less important, > > > > but I can definitely see how Axel and Dag can *feel* like that's > > > > where the committee is coming from, because that's how it feels to > > > > me. > > > > > > It is more than a bad feeling. If one repo drops repotags the whole > > > repotag system is broken. So the continued lack of repotags forces the > > > other repos to follow along even though they are strong belivers of > > > repotags. > > > [MUNCH] > > > > I don't get this. > > > > If one repo drops repotags (or a newcomer does not adopt them as this > > seems to be the case to me :-), then that repo does not have repotags. > > So? That does not force anyone to drop them to match their choice. If > > there is just _one_ repo that does not use repotags then the "system" > > still works, anything without repotags belongs to that repo, if more > > repos do that then things get progressively more confusing. If/when I > > package for rhel I will keep using ".ccrma" in there. > > freshrpms recently dropped repotags. Ah, oh, yes... the "let's make a bigger mess of things" reaction (IMHO). So, am I making things worse if I decide to keep repotags? (because then I don't contribute so strongly to the predictable confusion that some hope will highlight how repotags can be useful for no additional cost?[*]). Sounds really really silly to me. Thanks for taking the time to answer in detail... -- Fernando [*] it is not a "solution", but it sure helps. A lot. > Ever since for the packages that > atrpms and freshrpms share I get reports like "why does atrpms replace > ffmpeg and lame from the official Fedora Core distribution". I have > these in bugzilla, atrpms list, fedora lists and pm. > > For users knowledgable about what Fedora can contain or not, this is > less an issue, but all the novice, incomplete reports (which are a > supporters nightmare) make it to the nice playing party. > > As it doesn't only affect 3rd party repos cross-relationship, but even > the relationship to the vendor itself. E.g. EPEL packages become > indistinguishable for RHEL packages and I bet that there will be > tickets opened against RHEL because the user thought that > foo-1.2.3-4.el5 breaking in presence of bar-1.2.3-4.el5 is a problem > of foo, while after wasting RHEL support time it will be discovered > that while foo is indeed from RHEL, bar was from EPEL and the whole > constallation was unsupported to begin with. > > But the latter only affects the relationship of EPEL to RHEL. From Axel.Thimm at ATrpms.net Wed Apr 25 22:13:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Apr 2007 00:13:13 +0200 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <1177537910.4080.36.camel@cmn3.stanford.edu> References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> <8376.1177445089@vosill.math.hmc.edu> <20070425094951.GG22427@neu.nirvana> <1177524854.4080.9.camel@cmn3.stanford.edu> <20070425182633.GZ11831@neu.nirvana> <1177537910.4080.36.camel@cmn3.stanford.edu> Message-ID: <20070425221313.GA4618@neu.nirvana> On Wed, Apr 25, 2007 at 02:51:50PM -0700, Fernando Lopez-Lezcano wrote: > So, am I making things worse if I decide to keep repotags? Only to yourself, you aren't harming anyone else by keeping them. > (because then I don't contribute so strongly to the predictable > confusion that some hope will highlight how repotags can be useful > for no additional cost?[*]). Sounds really really silly to me. The point is that this system only works if all (major) players cooperate. Once one decides to not play nice anymore this system is broken and starts damaging the ones that support it. At the end you will be the last remaining martyr. :/ That's why I went through endless lengths to have epel carry repotags, so we could live all together in the same ecosphere. -- 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 mailing-lists at hughesjr.com Wed Apr 25 22:50:13 2007 From: mailing-lists at hughesjr.com (Johnny Hughes) Date: Wed, 25 Apr 2007 17:50:13 -0500 Subject: Collaboration In-Reply-To: <80d7e4090704251419s21d6ad68y134ba732aea4d624@mail.gmail.com> References: <1177504688.20302.73.camel@myth.home.local> <80d7e4090704251419s21d6ad68y134ba732aea4d624@mail.gmail.com> Message-ID: <1177541413.28104.55.camel@myth.home.local> On Wed, 2007-04-25 at 15:19 -0600, Stephen John Smoogen wrote: > On 4/25/07, Johnny Hughes wrote: > > > > > Answer to both ... EPEL wants to be "THE" Master 3rd Party repo, not > > just a 3rd Party Repo. There can be no misinterpreting that, it is just > > plain fact. > > > > Or it wants to be another repository. There are multiple reasons for > multiple repositories containing the same RPM with different options. > No one repository is going to meet those needs and no one repository > is going to rule them all. But we all seem to be forgetting that (me > included in a nice rant that was almost as long as this one that I > didnt send because I couldnt find an appropriate Devils Advocate > definition). Well ... I don't think that is true for most packages ... but could be true for some packages. I would think that for the vast majority of packages, we could work out a viable definition and build them in one place. That one place could be any of the major players ... and without a good reason, we should make assignments of master repos for individual packages. All the binaries and sources are published for every repo, so that is not hard. It is not good for users to have incompatible versions of packages hanging around, unless there is a specific reason (IMHO). We should at least, in my opinion, agree on a consolidated group of SPEC files. The problem is ... this whole discussion is not on equal footing. Why do RPMForge (Dag), ATRPMS (Axel), KDE-Redhat(Rex), CentOS Extras (Karanbir) count as one vote each to EPEL ... those people are running viable EL enabled Repositories right now that have millions of users combined. EPEL has no current users. I am not trying to be negative, but "it seems that" EPEL just assumes that they will be the defacto standard in this space ... and I am trying to understand how that helps system admins who are trying to deploy EL packages ... or admins who already have those packages deployed from the current repos. In another post, someone suggested that these Repos are minimal things ... but to put this in perspective, CentOS around 200 mirrors and millions of users. The majority of CentOS users use RPMForge or CentOS Extras already ... and many also use ATRPMS and KDE-Redhat. Those things already exist and they serve millions of users today. Yet it seems that a new player comes into this space and all the current people are supposed to stop what they are doing and start doing things the new way. It just seems backwards to me is all ... maybe I am missing something? Thanks, Johnny Hughes -------------- 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 nando at ccrma.Stanford.EDU Wed Apr 25 23:07:12 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Wed, 25 Apr 2007 16:07:12 -0700 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <20070425221313.GA4618@neu.nirvana> References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> <8376.1177445089@vosill.math.hmc.edu> <20070425094951.GG22427@neu.nirvana> <1177524854.4080.9.camel@cmn3.stanford.edu> <20070425182633.GZ11831@neu.nirvana> <1177537910.4080.36.camel@cmn3.stanford.edu> <20070425221313.GA4618@neu.nirvana> Message-ID: <1177542432.4080.48.camel@cmn3.stanford.edu> On Thu, 2007-04-26 at 00:13 +0200, Axel Thimm wrote: > On Wed, Apr 25, 2007 at 02:51:50PM -0700, Fernando Lopez-Lezcano wrote: > > So, am I making things worse if I decide to keep repotags? > > Only to yourself, you aren't harming anyone else by keeping them. > > > (because then I don't contribute so strongly to the predictable > > confusion that some hope will highlight how repotags can be useful > > for no additional cost?[*]). Sounds really really silly to me. > > The point is that this system only works if all (major) players > cooperate. Once one decides to not play nice anymore this system is > broken and starts damaging the ones that support it. At the end you > will be the last remaining martyr. :/ My (potential) packages will be easily identifiable with just an rpm -q. How is that bad? (for Planet CCRMA). Why is it best to hide if others hide? > That's why I went through endless lengths to have epel carry repotags, > so we could live all together in the same ecosphere. Yeah. Predictable result. I think it also took a long time for the RedHat/Fedora/Extras distros to realize it is good practice to add a _distro_ tag to all packages... -- Fernando From lists at timj.co.uk Wed Apr 25 23:51:45 2007 From: lists at timj.co.uk (Tim Jackson) Date: Thu, 26 Apr 2007 00:51:45 +0100 Subject: Collaboration In-Reply-To: <1177541413.28104.55.camel@myth.home.local> References: <1177504688.20302.73.camel@myth.home.local> <80d7e4090704251419s21d6ad68y134ba732aea4d624@mail.gmail.com> <1177541413.28104.55.camel@myth.home.local> Message-ID: <462FE991.3010204@timj.co.uk> Johnny Hughes wrote: > I would think that for the vast majority of packages, we could work out > a viable definition and build them in one place. That one place could > be any of the major players ... and without a good reason, we should > make assignments of master repos for individual packages. I'm not so sure about this. However, what I think many people (myself included) do agree on are your following points: > It is not good for users to have incompatible versions of packages > hanging around, unless there is a specific reason (IMHO). and > We should at least, in my opinion, agree on a consolidated group of SPEC > files. Absolutely. > I am not trying to be negative, but "it seems that" EPEL just assumes > that they will be the defacto standard in this space ... I don't think that's the case; I think users will decide that. > Yet it seems that a new player comes into this space and all the current > people are supposed to stop what they are doing and start doing things > the new way. It's not all that "new"...not if you have been involved in FE, which is already quite a mature project in some ways, even if it was a relatively late starter compared to some other efforts. (And remember that some parts of FE were preceded by fedora.us). > It just seems backwards to me is all ... maybe I am missing > something? You're missing the fact that although EPEL may "on paper" have 0 users right now, it is not coming from nowhere out of the blue: it is an extension of Fedora Extras which is a very popular project. The repos you mention have lots of users, true (I assume), but they have a notably small group of "owners". So if you add together the *collective* time that has gone into Fedora Extras from the many contributors, it's at least possible that it may already exceed that of (Dag + Axel + Matthias + Dries + ...) But anyway, arguing over numbers isn't the point. It's probably fair to say that what 3rd party EL repos really have going for them is deep technical knowledge and extensive real world deployment experience. What EPEL may lack in that area, it probably makes up for in the community/participation aspects *that already exist* and infrastructure. In that specific sense (and only that sense), some of the 3rd parties may have had it *RELATIVELY* (I don't mean to belittle the efforts in the slightest) easy, because those owners have had the freedom to do what they wanted in their repos without having to decide by committee. Now, the end results are good (and one can argue that's all that matters), but to be fair, that acknowledgement should work the other way too, and the inherited experience & infrastructure of FE in EPEL ought to be at least acknowledged. Tim From dennis at ausil.us Thu Apr 26 06:09:42 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 26 Apr 2007 01:09:42 -0500 Subject: rsync access to EPEL? In-Reply-To: <462FBC20.6090802@cora.nwra.com> References: <462FBC20.6090802@cora.nwra.com> Message-ID: <200704260109.42632.dennis@ausil.us> Once upon a time Wednesday 25 April 2007, Orion Poplawski wrote: > Any rsync access to EPEL yet? try rsync://rsync.cica.es/fedora-epel or rsync://mirrors.cat.pdx.edu/fedora/epel Dennis From fedora at leemhuis.info Thu Apr 26 07:17:21 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 26 Apr 2007 09:17:21 +0200 Subject: repotags Message-ID: <46305201.2020703@leemhuis.info> I posted something to fedora-devel for discussion regarding a possible solution for the repotag stuff: see https://www.redhat.com/archives/fedora-devel-list/2007-April/msg01232.html for details and participate there. I didn't want to crosspost it here, as that easily could have lead to split discussions. Sorry for the trouble. CU thl From Axel.Thimm at ATrpms.net Thu Apr 26 07:58:51 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Apr 2007 09:58:51 +0200 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <1177542432.4080.48.camel@cmn3.stanford.edu> References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> <8376.1177445089@vosill.math.hmc.edu> <20070425094951.GG22427@neu.nirvana> <1177524854.4080.9.camel@cmn3.stanford.edu> <20070425182633.GZ11831@neu.nirvana> <1177537910.4080.36.camel@cmn3.stanford.edu> <20070425221313.GA4618@neu.nirvana> <1177542432.4080.48.camel@cmn3.stanford.edu> Message-ID: <20070426075851.GB23704@neu.nirvana> On Wed, Apr 25, 2007 at 04:07:12PM -0700, Fernando Lopez-Lezcano wrote: > On Thu, 2007-04-26 at 00:13 +0200, Axel Thimm wrote: > > On Wed, Apr 25, 2007 at 02:51:50PM -0700, Fernando Lopez-Lezcano wrote: > > > So, am I making things worse if I decide to keep repotags? > > > > Only to yourself, you aren't harming anyone else by keeping them. > > > > > (because then I don't contribute so strongly to the predictable > > > confusion that some hope will highlight how repotags can be useful > > > for no additional cost?[*]). Sounds really really silly to me. > > > > The point is that this system only works if all (major) players > > cooperate. Once one decides to not play nice anymore this system is > > broken and starts damaging the ones that support it. At the end you > > will be the last remaining martyr. :/ > > My (potential) packages will be easily identifiable with just an rpm -q. > How is that bad? (for Planet CCRMA). Why is it best to hide if others > hide? I already outlined, that once a 3rd party repo break this common rule, it automagically becomes the standard base for novice users pushing all issues to the other repos. Here is a typical report I get since freshrpms dropped repotags: "migration to at packages from fc causes (minor) grief" "[... rant ...] was wondering why it is that you do what you do, specificially, replacing FC packages with your own [... rant ...] libquicktime-0.9.10-2.fc6.i386" This is an easy case where I know the packages cannot be from the vendor, since they are banned there. But the users have no idea and their first impulse when foo-1.2.3-4.ccrma and bar-1.2.3-4 break is that it can't be the non-adorned version's fault, since everyone knows that that's the official one. So the repos that drop repotag shift the support issues to the ones that continue carrying it. That's an unfair and unbalanced situation and there is just not enough manpower to waste, so everyone gets forced to drop repotags to restore the balance. You can rightfully argue that if rpmforge, ATrpms and co drop the repotag now, too, they just add to the problem, and that's true for the remaining repos that want to carry one like you want to, but there aren't many degrees of freedom left unless one likes to get more support issues than really neccessary. The second, third, forth and so on repo that will drop the repotags are not to blame, the first one introduced the situation. > > That's why I went through endless lengths to have epel carry repotags, > > so we could live all together in the same ecosphere. > > Yeah. Predictable result. Not at all: At the beginning it looked like epel wouldn't mind repotags, there was only one opponent that finally left this list. And sibling entities like the FPC tended to back up any epel plans to introduce them. When epel finally came close to get some, another opponent woke up and made a lot of noise and created the current situation. > I think it also took a long time for the RedHat/Fedora/Extras > distros to realize it is good practice to add a _distro_ tag to all > packages... Indeed, currently 89% of fedora carry one with a per release increase of >= 10% for the last three releases. So the extrapolation gives that F8 will be covered 98% with disttags unless the disttags are swamped in FUD which some people currently try to do. But that's another sad story. -- 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 deant at hawaii.rr.com Thu Apr 26 08:48:29 2007 From: deant at hawaii.rr.com (Dean Takemori) Date: Wed, 25 Apr 2007 22:48:29 -1000 Subject: Relationship to existing 3rd party repos/CentOS/SL? Message-ID: <68EAFBA6-319A-46FA-951F-1E4E00384E8A@hawaii.rr.com> I hope you all will forgive the newcomer to the discussion. Can someone give or point to a summary of the TECHNICAL REASONS why the EPEL members voted against EPEL using a repotag? -dean takemori From orion at cora.nwra.com Thu Apr 26 16:16:28 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 26 Apr 2007 10:16:28 -0600 Subject: rsync access to EPEL? In-Reply-To: <200704260109.42632.dennis@ausil.us> References: <462FBC20.6090802@cora.nwra.com> <200704260109.42632.dennis@ausil.us> Message-ID: <4630D05C.1040006@cora.nwra.com> Dennis Gilmore wrote: > Once upon a time Wednesday 25 April 2007, Orion Poplawski wrote: >> Any rsync access to EPEL yet? > > > try rsync://rsync.cica.es/fedora-epel or This works. > rsync://mirrors.cat.pdx.edu/fedora/epel This does not appear to exist. Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From Axel.Thimm at ATrpms.net Thu Apr 26 17:26:14 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Apr 2007 19:26:14 +0200 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <68EAFBA6-319A-46FA-951F-1E4E00384E8A@hawaii.rr.com> References: <68EAFBA6-319A-46FA-951F-1E4E00384E8A@hawaii.rr.com> Message-ID: <20070426172614.GD7127@neu.nirvana> On Wed, Apr 25, 2007 at 10:48:29PM -1000, Dean Takemori wrote: > I hope you all will forgive the newcomer to the discussion. Can > someone give or point to a summary of the TECHNICAL REASONS why the > EPEL members voted against EPEL using a repotag? Could you please check the archives or the wiki vote and the irc log? Because this will fuel yet another discussion about whether there were any or not, and you will probably not find anyone unbiased enough to give you an objective answer. -- 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 nando at ccrma.Stanford.EDU Thu Apr 26 18:48:05 2007 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Thu, 26 Apr 2007 11:48:05 -0700 Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <20070426075851.GB23704@neu.nirvana> References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> <8376.1177445089@vosill.math.hmc.edu> <20070425094951.GG22427@neu.nirvana> <1177524854.4080.9.camel@cmn3.stanford.edu> <20070425182633.GZ11831@neu.nirvana> <1177537910.4080.36.camel@cmn3.stanford.edu> <20070425221313.GA4618@neu.nirvana> <1177542432.4080.48.camel@cmn3.stanford.edu> <20070426075851.GB23704@neu.nirvana> Message-ID: <1177613285.7887.35.camel@cmn3.stanford.edu> Axel: in the following I'm __not__ blaming _you_... On Thu, 2007-04-26 at 09:58 +0200, Axel Thimm wrote: > On Wed, Apr 25, 2007 at 04:07:12PM -0700, Fernando Lopez-Lezcano wrote: > > On Thu, 2007-04-26 at 00:13 +0200, Axel Thimm wrote: > > > On Wed, Apr 25, 2007 at 02:51:50PM -0700, Fernando Lopez-Lezcano wrote: > > > > So, am I making things worse if I decide to keep repotags? > > > > > > Only to yourself, you aren't harming anyone else by keeping them. > > > > > > > (because then I don't contribute so strongly to the predictable > > > > confusion that some hope will highlight how repotags can be useful > > > > for no additional cost?[*]). Sounds really really silly to me. > > > > > > The point is that this system only works if all (major) players > > > cooperate. Once one decides to not play nice anymore this system is > > > broken and starts damaging the ones that support it. At the end you > > > will be the last remaining martyr. :/ > > > > My (potential) packages will be easily identifiable with just an rpm -q. > > How is that bad? (for Planet CCRMA). Why is it best to hide if others > > hide? > > I already outlined, that once a 3rd party repo break this common rule, > it automagically becomes the standard base for novice users pushing > all issues to the other repos. Here is a typical report I get since > freshrpms dropped repotags: > > "migration to at packages from fc causes (minor) grief" > > "[... rant ...] was wondering why it is that you do what you do, specificially, > replacing FC packages with your own [... rant ...] > libquicktime-0.9.10-2.fc6.i386" > > This is an easy case where I know the packages cannot be from the > vendor, since they are banned there. But the users have no idea and > their first impulse when foo-1.2.3-4.ccrma and bar-1.2.3-4 break is > that it can't be the non-adorned version's fault, since everyone knows > that that's the official one. Educate users then? Make sure that web sites clearly state facts about repotags? > So the repos that drop repotag shift the support issues to the ones > that continue carrying it. That's an unfair and unbalanced situation > and there is just not enough manpower to waste, so everyone gets > forced to drop repotags to restore the balance. > > You can rightfully argue that if rpmforge, ATrpms and co drop the > repotag now, too, they just add to the problem, Yes, that is what actually happens. I don't think I need to argue about it, sounds to me like fact. > and that's true for > the remaining repos that want to carry one like you want to, but there > aren't many degrees of freedom left unless one likes to get more > support issues than really neccessary. The second, third, forth and so > on repo that will drop the repotags are not to blame, the first one > introduced the situation. I disagree. The second __is__ to blame. Definitely. Come on, if one is off it does not matter, no repotag means users automatically know where it is coming from (same as _having_ a repotag). Now, as for the _second_, there's no excuse for doing that unless you actually believe repotags should die. Non-repo-tagged Extras was actually the situation we were living in before EPEL (ie: Fedora Extras), and it did not suck AFAIK. Now it will suck for both epel and extras. That's progress? I can see your reasoning for the third and so on and so forth - still it sucks. For the _second_ there's no _technical_ reason that I can see. I'm perhaps too stuborn but I don't see why we need to follow the lead and jump off the cliff. It will make matters worse for everyone. > > > That's why I went through endless lengths to have epel carry repotags, > > > so we could live all together in the same ecosphere. > > > > Yeah. Predictable result. > > Not at all: At the beginning it looked like epel wouldn't mind > repotags, there was only one opponent that finally left this list. And > sibling entities like the FPC tended to back up any epel plans to > introduce them. When epel finally came close to get some, another > opponent woke up and made a lot of noise and created the current > situation. Nice. All it takes is just _one_ strong individual to derail things? (hmmm, where's the news? :-) Were there people within EPEL that supported this? How many? If there's effectively a single vote veto then it becomes impossible to do _anything_. There's always going to be a voice against, no matter what you do. > > I think it also took a long time for the RedHat/Fedora/Extras > > distros to realize it is good practice to add a _distro_ tag to all > > packages... > > Indeed, currently 89% of fedora carry one with a per release increase > of >= 10% for the last three releases. So the extrapolation gives that > F8 will be covered 98% with disttags unless the disttags are swamped > in FUD which some people currently try to do. But that's another sad > story. So, what would have happened if all third party distros had dropped the distro tag? I understand people being pissed off (I am right now), but the right answer to repotags not being considered for epel is _not_ to drop them but to _keep_ them. In the hope (as with distro tags) that eventually the advantages will become obvious and they are adopted. Or not. Dropping them is ensuring that can not happen. Not a good choice if you indeed believe they are useful. Sorry, I'll shut up now... this is not going to go anywhere. -- Fernando From smooge at gmail.com Thu Apr 26 22:09:32 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 26 Apr 2007 16:09:32 -0600 Subject: Collaboration In-Reply-To: <462FE991.3010204@timj.co.uk> References: <1177504688.20302.73.camel@myth.home.local> <80d7e4090704251419s21d6ad68y134ba732aea4d624@mail.gmail.com> <1177541413.28104.55.camel@myth.home.local> <462FE991.3010204@timj.co.uk> Message-ID: <80d7e4090704261509x7038a899p739f8a3f180441af@mail.gmail.com> On 4/25/07, Tim Jackson wrote: > Johnny Hughes wrote: > > > We should at least, in my opinion, agree on a consolidated group of SPEC > > files. > > Absolutely. > And on maybe a methodology of how SPEC files are to be written/documented/etc. This would be the biggest win from the Fedora items as the problems that we see in the Enterprise environment can be fed back to make things work better. > > I am not trying to be negative, but "it seems that" EPEL just assumes > > that they will be the defacto standard in this space ... > > I don't think that's the case; I think users will decide that. > I don't think so either. I think that each repository comes across that way at one point or another in the conversations.. if nothing more than we end up identifying with what we work with. That being said, I identify myself with the SmoogeSpace Repo :). > > It just seems backwards to me is all ... maybe I am missing > > something? > > You're missing the fact that although EPEL may "on paper" have 0 users > right now, it is not coming from nowhere out of the blue: it is an > extension of Fedora Extras which is a very popular project. The repos > you mention have lots of users, true (I assume), but they have a notably > small group of "owners". So if you add together the *collective* time > that has gone into Fedora Extras from the many contributors, it's at > least possible that it may already exceed that of (Dag + Axel + Matthias > + Dries + ...) But anyway, arguing over numbers isn't the point. It's I agree with you on that point. Current numbers do not matter in the argument. What one brings to both existing and potential customers is what counts. > probably fair to say that what 3rd party EL repos really have going for > them is deep technical knowledge and extensive real world deployment > experience. What EPEL may lack in that area, it probably makes up for in > the community/participation aspects *that already exist* and > infrastructure. In that specific sense (and only that sense), some of > the 3rd parties may have had it *RELATIVELY* (I don't mean to belittle > the efforts in the slightest) easy, because those owners have had the > freedom to do what they wanted in their repos without having to decide > by committee. Now, the end results are good (and one can argue that's > all that matters), but to be fair, that acknowledgement should work the > other way too, and the inherited experience & infrastructure of FE in > EPEL ought to be at least acknowledged. > I recognize that Fedora Extras has a lot of people who are interested in packaging up stuff. However that does not translate into lots of people wanting to support things for enterprise environment when that entails supporting very old releases, etc. I also see a problem in the case where a package needs to differ from Extras and EPEL because of maintainability or other items. What are the customers that EPEL is trying to 'service'? Are they the customer that wants the same version of clamav on EL2,3,4,5? In some ways I would argue that this is audience that rpmforge/atrpms covers Are they the customer that wants a stable version of clamav for EL2,3,4,5 for a short time? Other repos may cover this??? Are they the customer that wants a stable version of clamav for EL2,3,4,5 for a long time? Are the customers willing to replace EL core packages with 'newer/different' items to make other packages to work [example: update ruby for puppet, update python for plone?] Do the customers want a wide variety of packages? Do the customers want a consolidated working set of packages (say security only, plone website, etc)? While they probably want all of the above, the customer is limited by the fact they are getting this for free.. they can find someone who will pay? EPEL will need to figure out which customers it wants to help service and why it wants to help service them. -- 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 dag at wieers.com Fri Apr 27 00:57:58 2007 From: dag at wieers.com (Dag Wieers) Date: Fri, 27 Apr 2007 02:57:58 +0200 (CEST) Subject: Relationship to existing 3rd party repos/CentOS/SL? In-Reply-To: <1177613285.7887.35.camel@cmn3.stanford.edu> References: <20070414111711.GA25962@neu.nirvana> <4627503E.2050507@timj.co.uk> <8376.1177445089@vosill.math.hmc.edu> <20070425094951.GG22427@neu.nirvana> <1177524854.4080.9.camel@cmn3.stanford.edu> <20070425182633.GZ11831@neu.nirvana> <1177537910.4080.36.camel@cmn3.stanford.edu> <20070425221313.GA4618@neu.nirvana> <1177542432.4080.48.camel@cmn3.stanford.edu> <20070426075851.GB23704@neu.nirvana> <1177613285.7887.35.camel@cmn3.stanford.edu> Message-ID: On Thu, 26 Apr 2007, Fernando Lopez-Lezcano wrote: > I understand people being pissed off (I am right now), but the right > answer to repotags not being considered for epel is _not_ to drop them > but to _keep_ them. In the hope (as with distro tags) that eventually > the advantages will become obvious and they are adopted. Or not. > Dropping them is ensuring that can not happen. Not a good choice if you > indeed believe they are useful. It is unfair that EPEL can get away with it because everybody else has repotags. For that reason I am happy to be the repository without the repotag ! Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From dag at wieers.com Sun Apr 29 11:09:07 2007 From: dag at wieers.com (Dag Wieers) Date: Sun, 29 Apr 2007 13:09:07 +0200 (CEST) Subject: Collaboration In-Reply-To: <462F869D.5060600@timj.co.uk> References: <1177504688.20302.73.camel@myth.home.local> <462F869D.5060600@timj.co.uk> Message-ID: On Wed, 25 Apr 2007, Tim Jackson wrote: > Johnny Hughes wrote: > > > If RPMforge has a perfectly working ClamAV for EL5, and if we are > > collaborating, why would EPEL build ClamAV? > > a) Because EPEL is independent, and should have infrastructure which is > independent of other entities. This is a basic principle of running any > self-contained project. It does NOT exclude collaboration, unless your > definition of "collaboration" is particularly narrow. EPEL is not independent. EPEL is Fedora is Red Hat. It does only include stuff that might be tainted in the US to make sure Red Hat cannot be sued. Red Hat is part of the vision _and_ you endorse that vision to be part of Fedora. It is not independent. > b) Because the standards, processes etc. of the repos are different and > therefore, as we have already established, they are serving different > purposes What is ironic, is that the standards are based on common practices that all the repositories created as part of the packaging community. I started using a disttag to mitigate the dependency hell. And we created common rules in SPEC files even when Red Hat didn't (and sometimes still doesn't). The SPEC files in RPMforge are very consistent and do not leave any room for doubt on how we fix common problems. The SPEC files are even more strict than what is in Fedora's packaging guidelines. The clamav indifferences are not caused by a lack of standards and processes. The clamav package I have was based on the very first clamav RPM package, newrpms modified it, Petr Kristof modified it and all of these were compatible. Fedora introduced the incompatible variant. You see, on one hand Fedora waives with standards and processes, and on the other hand it caused exactly those incompatibilities even when the clamav packages did not break any standard or process. How is that ? Because back in those days, all these repositories existed and there was communication between them. Before you package a clamav package you would look what already existed so that they would not break anyone's system. And back then Fedora stepped in, and redid everything. They could of course because they made the OS, so they would have authority as well for the add-on stuff. I see the same thing happening with Enterprise packages. And before you say "that's in the past, bury the past and life in the present". Well, that's pretty hard if the Fedora past has killed the RPMforge's (and other repo's) presence wrt. Fedora packages and the Fedora past is repeating itself as we speak. The past is pretty current. Why shouldn't I be sceptic ? EPEL is introducing packages that break what is there since 5 years. That breaks my current users. It doesn't even make sense to report each of these instances because that would keep me busy until the end of times. Does anyone at Fedora/EPEL looks at compatibility before they release anything ? No, they put the work on my shoulders. And you know what, they don't even tag those flagrant incompatibilies with their own name. Causing even more people to flame me. So if you thought the repotag was just /me being pedantic, think again. > > Answer to both ... EPEL wants to be "THE" Master 3rd Party repo, not > > just a 3rd Party Repo. There can be no misinterpreting that, it is just > > plain fact. > > As an existing user of various repos including Dag & AT, a tentative > contributor to EPEL (following FE) then I'm still not sure that that's > true and it's definitely not "fact". However, I do believe I understand > why you might feel that way - in fact I had a lengthy and good-humoured > discussion in person with Dag about this very topic at Linux World last > November. If EPEL is not the Master 3rd party repository, then please start to look if what EPEL introduces is compatible with what already exists. Because the clamav packages surely don't play nice with what already existed. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From lists at timj.co.uk Sun Apr 29 12:32:20 2007 From: lists at timj.co.uk (Tim Jackson) Date: Sun, 29 Apr 2007 13:32:20 +0100 Subject: Collaboration In-Reply-To: References: <1177504688.20302.73.camel@myth.home.local> <462F869D.5060600@timj.co.uk> Message-ID: <46349054.8010409@timj.co.uk> Dag Wieers wrote: > On Wed, 25 Apr 2007, Tim Jackson wrote: > >> Johnny Hughes wrote: >> >>> If RPMforge has a perfectly working ClamAV for EL5, and if we are >>> collaborating, why would EPEL build ClamAV? >> a) Because EPEL is independent, and should have infrastructure which is >> independent of other entities. This is a basic principle of running any >> self-contained project. It does NOT exclude collaboration, unless your >> definition of "collaboration" is particularly narrow. > > EPEL is not independent. EPEL is Fedora is Red Hat. You missed my point. I wasn't talking about independence in a political/organisational sense. I simply meant that it is a standalone repository/project. >> b) Because the standards, processes etc. of the repos are different and >> therefore, as we have already established, they are serving different >> purposes > > What is ironic, is that the standards are based on common practices that > all the repositories created as part of the packaging community. That may well be the case. In that case your beef is (mainly) with the individual package contributors who either ignored or didn't bother to check existing packages to see if there was a way to "play nice" before redesigning a package. This is not a failure, per se, of Fedora, but is a result largely of human nature, though the project as a whole of course has to take responsibility. Although we try to present a unified face, no project would exist without the people that contribute to it. So, we need to move the discussion away a little bit from "How Fedora communicates with other repos" and more towards "How the intelligent people that contribute to Fedora communicate with the intelligent people that package stuff in other repos". As you rightly imply, no amount of policies or processes will substitute for good old fashioned person-to-person co-operation. There is however still the fact, as I've pointed out before, that there isn't always an empirically "correct" answer to a problem. There may be two incompatible but equally valid ways to package something. That said, I do agree that in the absence of compelling and observable improvements, given two competing solutions it would be better to stick with the existing one for compatibility. I'm 100% behind you on that. (I'm commenting in general here, rather than specifically about clamav; whether or not clamav in Fedora is a compelling improvement over clamav in RPMforge is a discussion for another time). Actually, due to differing goals, there will probably be times where there simply is no way to produce one package that meets criteria for both Fedora and [other repo]. In that case, we may just have to accept that (and do what we can at a technical level to make things as compatible as possible, e.g. via Requires/Provides). However we should all work hard to make those cases as rare as possible, ideally zero. > And back then Fedora stepped in, and redid everything. They could of > course because they made the OS, so they would have authority as well for > the add-on stuff. I think you're ascribing higher authority and motives here than actually exist. The problem here is communication, plain and simple. "Fedora" didn't make the clamav package, a person did. If the clamav packager didn't look at what other packages were already around, and discuss possible changes with other well-respected maintainers before making the Fedora package, then that's regrettable IMHO, and of course I understand why you, Dag, might feel a bit miffed. (If he did, but the disagreements couldn't be resolved, then that's a slightly different matter as I discussed above). I don't think it helps anyone (including Fedora/EPEL) to reinvent the wheel unnecessarily; we should all be trying to build the best solutions. Which is exactly why I think collaboration is very important. To reiterate though, this is a 2-way thing and if a Fedora packager suggests changes/improvements to you, I would expect you to be receptive to those in the same way that I would expect the packager to be receptive to building packages that are compatible with existing ones from you. > If EPEL is not the Master 3rd party repository, then please start to look > if what EPEL introduces is compatible with what already exists. Because > the clamav packages surely don't play nice with what already existed. On this topic we both agree. I do understand why you are suspicious of EPEL, and I can't blame you for that based on some bad experiences with specific Fedora packages. However, as you can see, I think the views of you (Dag) and me (Tim) are actually very closely aligned, and whilst I can't speak for other contributors, it isn't my impression that my opinions are wildly different to other people's. So that's why I think it would be a shame for you to dismiss EPEL/Fedora entirely when actually with a small amount of work from both sides, we can probably reach a solution that suits everyone. It would be much better to work together instead of fighting, because then we can focus on the real goal of making packages that help people get real work done as simply and easily as possible. We won't always agree 100%, but that's OK as long as we keep the bigger picture in mind. Tim From lists at timj.co.uk Sun Apr 29 13:46:16 2007 From: lists at timj.co.uk (Tim Jackson) Date: Sun, 29 Apr 2007 14:46:16 +0100 Subject: Proposal: Repository Community Collaboration Statement Message-ID: <4634A1A8.7070903@timj.co.uk> I have a feeling I might regret this, but if nobody tries.... I have written up below a proposed simple statement of collaboration which ideally a number of interested parties in different repositories (EPEL, Fedora, RPMforge, AT etc.) could sign up to. At this stage I'm interested mostly in whether people like the broad principle, rather than picking apart specific wording as I'd rather this didn't descend into a discussion about semantics or politics. Basically: is this something that people feel could form the basis of something they'd be willing to sign up to? Or should we all just go back to arguing about repotags? --------------------------------------------------------------------- Repository Community Collaboration Statement --------------------------------------------------------------------- This is a statement signed by a number of groups which produce add-on RPM packages for the following operating systems: - Fedora Linux - Red Hat Enterprise Linux and compatible derivatives This statement is not binding and does not by itself compel anyone to do anything. Any signatory may withdraw at any time. However the signatories have agreed to the principles contained within it and commit to working together for mutual benefit. 1. Statement of goals The signatories have as a high level objective the development of packages for the targeted operating systems which are technically sound, robust and give an excellent user experience. Whilst acknowledging that "mixing repositories" will always be somewhat unpredictable due to differing goals and standards amongst signatories, the signatories aim to promote informed choice amongst users by avoiding unnecessary user inconvenience when switching between competing packages. 2. Acknowledgement of independence Each signatory is independent and fully entitled to operate in a self-sustaining way which does not depend on other signatories. This includes all senses but notably infrastructure and policy. This Agreement does not override the signatories' own policies, though it is expected that signatories will normally make reference to this Agreement in their own policies. 3. Acknowledgement of peer status For the purpose of this Agreement, the signatories agree to act as peers and no signatory is considered superior. 4. Main agreements The signatories agree therefore to promote the following standards amongst their contributors: a)to make reasonable efforts to research existing packages (if any)from other signatories before starting to package a certain item of software from scratch b)to make reasonable ongoing efforts to keep competing packages as similar as possible, particularly in the sense of RPM dependencies and file locations, such that upgrades or migrations between different repositories are not unecessarily difficult for users c)to avoid wherever possible publishing packages which are egregiously incompatible with packages from other signatories, without sound technical reasons d)to attempt to collaborate constructively at an intellectual level with other signatories and their contributors where reasonably possible, particularly where a contributor feels there are specific technical deficiencies in existing signatories' packaging; the signatories acknowledge that it is better to discuss these differences in an open and respectful fashion and try to reach a consensus solution, rather than creating incompatible packages. SIGNATORIES: [list] ----------------------------------------------------------------------- Tim From buildsys at fedoraproject.org Sun Apr 29 21:41:58 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 29 Apr 2007 17:41:58 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-04-29 Message-ID: <20070429214158.91861152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 14 NEW ghex-2.8.2-4.el5 NEW gweled-0.7-8.el5 perl-Net-LibIDN-0.09-2.el5 NEW php-pear-DB-DataObject-FormBuilder-1.0.0-0.4.RC7.el5 NEW php-pear-DB-QueryTool-1.1.0-1.el5 NEW php-pear-File-1.2.2-1.el5 NEW php-pear-HTML-Common-1.2.3-3.el5 NEW php-pear-HTML-QuickForm-3.2.7-3.el5 NEW php-pear-HTML-Table-1.7.5-1.el5 NEW php-pear-Net-URL-1.0.14-1.el5 NEW pop-before-smtp-1.41-2.el5 NEW python-crypto-2.0.1-4.el5 NEW revelation-0.4.11-2.el5 NEW uw-imap-2006g-2.el5 Packages built and released for Fedora EPEL 4: 4 NEW gweled-0.7-8.el4 perl-Net-LibIDN-0.09-2.el4 NEW scim-1.4.4-2.el4 NEW scim-tables-0.5.6-1.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From smooge at gmail.com Sun Apr 29 22:53:50 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 29 Apr 2007 16:53:50 -0600 Subject: Collaboration In-Reply-To: References: <1177504688.20302.73.camel@myth.home.local> <462F869D.5060600@timj.co.uk> Message-ID: <80d7e4090704291553x6c059c5bp7ee06e8d66bf232a@mail.gmail.com> On 4/29/07, Dag Wieers wrote: > On Wed, 25 Apr 2007, Tim Jackson wrote: > And before you say "that's in the past, bury the past and life in the > present". Well, that's pretty hard if the Fedora past has killed the > RPMforge's (and other repo's) presence wrt. Fedora packages and the > Fedora past is repeating itself as we speak. The past is pretty current. > Well at some point, we are going to have to live in the present.. but that just means we have to verify that errors in the past do not get made again. The number of incompatibilities will grow as long as people keep thinking there is some conspiracy on one side or the other. What I see happening is about the same as I see on the playground. We have some 5th graders who have been playing on the field for the longest time and feel some ownership of it... and we have 100+ kindergarteners who were just allowed out for the first time. The 5th graders know not to kick the ball into Mr Okillabuddy's yard and they have their own rules of who gets what corner and what toy so they dont get into fights with each other. The kindergarteners are used to playing on their toy lots which used to be the 5th graders a while back. At this rate, its going to be detention for everyone. -- 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"