PatrickD Garvey
2015-Jan-14 23:09 UTC
[CentOS-docs] Pull Request wiki.c.o/AdditionalResources/Repositories
On Tue, Jan 13, 2015 at 10:04 AM, Karanbir Singh <mail-lists at karan.org> wrote:> On 01/09/2015 11:49 PM, Tom Sorensen wrote: >> KB -- I made those changes several months ago (Sep/Oct I believe), with >> discussion in IRC. This was after a spate of people in the main channel >> having issues with Atomic (there's a name that's going to end up causing >> problems...) and the continued use of RPMForge/RepoForge, with no >> indication that they're really really bad. As well as the recognition of >> the reality that there are a very few repos that are frequently >> recommended (and, in the case of EPEL, now easily enabled in CentOS). > > I think we should do a bit of work and find a tangiable set of standards > that a repo needs to meet in order to be 'endorsed' or rated at a > certain level. Because at the moment it does seem to add value to a repo > or two over others, based on personal opinion. > > I am willing to write code to do this validation, but were going to need > a set of good rules to implement. > > regards and thanks > > - KB >Maybe it isn't code that needs to be generated. I obviously wasn't around for any IRC discussion of this page and its implications. I don't imagine there is any sort of log of that discussion I could review. Rhetorical questions and comments: Is it true some of these repos exist because CentOS wasn't adequate for some particular purpose, but someone thought they could provide a parallel resource to easily install additional software? I imagine another motivation would be a quasi-fork. That is, someone was offended that a particular decision was not to their satisfaction, but thought a repo could be used to eliminate the bad decision and implement their proposal.>From Tom's comment I infer there was a need to warn people away from using somerepos that were consuming significant resources to help folks who had trusted them. It also appears that somehow Fedora's efforts have been mutually beneficial. With these thoughts as background for my thinking, my brainstorm is that the Special Interest Groups and spins may be the path to solving the need to have additional non-CentOS resources and know they are sufficiently cooperative. Proposal: The Third Party Repositories section should not list any other repositories, but should only note there are difficulties in making several independent repositories safely usable and give a thorough explaination of what has happened in the past without naming names. The offer to help through Special Interest Groups and spins can then be noted. This would be used to enter into a cooperative arrangement with each group that wishes to start with the CentOS repositories and "improve" them. If one implements a set of software tests for the quality of other folks work, one is effectively committing to maintain those tests, which have no purpose within the CentOS project. That means a CentOS project member is diverting time from the CentOS project. Joint ventures, with agreements about how they will work, leverage the expertise of all participants for the benefit of all the projects. Unilateral Quality Assurance tests consume time just generating debates about the quality of the tests, even before the maintenance issue comes up. Atomic has a SIG. Maybe, EPEL needs one.
John R. Dennison
2015-Jan-14 23:26 UTC
[CentOS-docs] Pull Request wiki.c.o/AdditionalResources/Repositories
On Wed, Jan 14, 2015 at 03:09:01PM -0800, PatrickD Garvey wrote:> > Proposal: > The Third Party Repositories section should not list any other repositories, > but should only note there are difficulties in making several independent > repositories safely usable and give a thorough explaination of what has happened > in the past without naming names.You are looking for problems to fix where there are none. The overall state of that page is and has been fine for many years. EL requires external third- party repos. It has always been this way and it will always continue to be the case. Your proposal to remove the listings that are there now serves no one and will only create more of a support burden on the people that are volunteering their time. John -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://lists.centos.org/pipermail/centos-docs/attachments/20150114/ac01acb4/attachment-0002.sig>
PatrickD Garvey
2015-Jan-14 23:38 UTC
[CentOS-docs] Pull Request wiki.c.o/AdditionalResources/Repositories
On Wed, Jan 14, 2015 at 3:26 PM, John R. Dennison <jrd at gerdesas.com> wrote:> On Wed, Jan 14, 2015 at 03:09:01PM -0800, PatrickD Garvey wrote: >> >> Proposal: >> The Third Party Repositories section should not list any other repositories, >> but should only note there are difficulties in making several independent >> repositories safely usable and give a thorough explaination of what has happened >> in the past without naming names. > > You are looking for problems to fix where there are none. The overall state of > that page is and has been fine for many years. EL requires external third- > party repos. It has always been this way and it will always continue to > be the case. Your proposal to remove the listings that are there now > serves no one and will only create more of a support burden on the > people that are volunteering their time. > > JohnI view your comments as an opportunity to understand an experience I have yet to have. Please share which repository you use and how it depends upon CentOS and how the CentOS community depends upon it. I view the entire FLOSS community as interdependent. I hope to make this page an asset for that interdependence. That's why I worked on the link rot. Karanbir seems to feel that certain phrases in the page unduly favor some of the repositories and that requires an objective evaluation. Please help us (me, especially) understand what we may be doing to the detriment of your use of CentOS and thereby avoid that negative result.
Manuel Wolfshant
2015-Jan-15 03:39 UTC
[CentOS-docs] Pull Request wiki.c.o/AdditionalResources/Repositories
On 01/15/2015 01:09 AM, PatrickD Garvey wrote:> On Tue, Jan 13, 2015 at 10:04 AM, Karanbir Singh <mail-lists at karan.org> wrote: >> On 01/09/2015 11:49 PM, Tom Sorensen wrote: >>> KB -- I made those changes several months ago (Sep/Oct I believe), with >>> discussion in IRC. This was after a spate of people in the main channel >>> having issues with Atomic (there's a name that's going to end up causing >>> problems...) and the continued use of RPMForge/RepoForge, with no >>> indication that they're really really bad. As well as the recognition of >>> the reality that there are a very few repos that are frequently >>> recommended (and, in the case of EPEL, now easily enabled in CentOS). >> I think we should do a bit of work and find a tangiable set of standards >> that a repo needs to meet in order to be 'endorsed' or rated at a >> certain level. Because at the moment it does seem to add value to a repo >> or two over others, based on personal opinion. >> >> I am willing to write code to do this validation, but were going to need >> a set of good rules to implement. >> >> regards and thanks >> >> - KB >> > Maybe it isn't code that needs to be generated. > > I obviously wasn't around for any IRC discussion of this page and its > implications. > I don't imagine there is any sort of log of that discussion I could review. > > Rhetorical questions and comments: > Is it true some of these repos exist because CentOS wasn't adequate for some > particular purpose, but someone thought they could provide a parallel resource > to easily install additional software?Yes, it is. Some people need newer versions for applications than what the distro can provide. Other need complementary stuff which the distro or better said RHEL is not willing or not able to provide. [...]> > From Tom's comment I infer there was a need to warn people away from using some > repos that were consuming significant resources to help folks who had > trusted them.Right. Some repos lead to problems similar to: / Aug 28 14:27:15 <TheAlien> hey there, im having trouble updating packages on my server. yum update gives a long list of needed updates and sumarises 'Install 3 Package(s)// // / Upgrade 132 Package(s) / Remove 1 Package(s)' but then says 'package mysql-5.5.25-1.el5.remi.x86_64 (which is newer than mysql-5.0.95-5.el5_9.i386) is already installe//d' --// //Aug 28 14:27:24 <TheAlien> plus several messages like 'file /usr/bin/mysqlaccess from install of mysql-5.0.95-5.el5_9.i386 conflicts with file from package mysql-5.5.25-1.el5.r// / Others simply are no longer properly maintained, for instance still shipping older versions of applications which have known vulnerabilities. // [...]> > It also appears that somehow Fedora's efforts have been mutually beneficial.Yes, they have but this has nothing to do with the wiki page we speak about. Incidentally EPEL aims to a high standard so as to make it suitable for an enterprise-grade distro which CentOS aims to be and that is why we recommend to all others packagers to follow similar rules ( when possible and if they make sense, of course ). However this is by no means a requirement that must be met in order to have a 3rd party repository listed in the CentOS wiki.> With these thoughts as background for my thinking, my brainstorm is that the > Special Interest Groups and spins may be the path to solving the need to have > additional non-CentOS resources and know they are sufficiently cooperative. > > Proposal: > The Third Party Repositories section should not list any other repositories, > but should only note there are difficulties in making several independent > repositories safely usable and give a thorough explaination of what has happened > in the past without naming names.I can only concur with what John has said. You are looking for problems to fix where there are none. 3 months ago Tom has made a great job in cleaning the page up ( and several of us assisted him when he asked for opinions ) and - AFAIK - its current shape expresses the views of most of the regulars who provide help via the various CentOS support channels. If and when needed we modify the page but as it is now it is completely satisfactory for its purpose. Even if the feelings of some people get hurt by our opinions about the quality of their work ( i.e. of the packages they provide ). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-docs/attachments/20150115/f6dc6366/attachment-0002.html>
PatrickD Garvey
2015-Jan-15 04:34 UTC
[CentOS-docs] Pull Request wiki.c.o/AdditionalResources/Repositories
On Wed, Jan 14, 2015 at 7:39 PM, Manuel Wolfshant <wolfy at nobugconsulting.ro> wrote:> On 01/15/2015 01:09 AM, PatrickD Garvey wrote: > > On Tue, Jan 13, 2015 at 10:04 AM, Karanbir Singh <mail-lists at karan.org> > wrote: > > On 01/09/2015 11:49 PM, Tom Sorensen wrote: > > KB -- I made those changes several months ago (Sep/Oct I believe), with > discussion in IRC. This was after a spate of people in the main channel > having issues with Atomic (there's a name that's going to end up causing > problems...) and the continued use of RPMForge/RepoForge, with no > indication that they're really really bad. As well as the recognition of > the reality that there are a very few repos that are frequently > recommended (and, in the case of EPEL, now easily enabled in CentOS). > > I think we should do a bit of work and find a tangiable set of standards > that a repo needs to meet in order to be 'endorsed' or rated at a > certain level. Because at the moment it does seem to add value to a repo > or two over others, based on personal opinion. > > I am willing to write code to do this validation, but were going to need > a set of good rules to implement. > > regards and thanks > > - KB > > Maybe it isn't code that needs to be generated. > > I obviously wasn't around for any IRC discussion of this page and its > implications. > I don't imagine there is any sort of log of that discussion I could review. > > Rhetorical questions and comments: > Is it true some of these repos exist because CentOS wasn't adequate for some > particular purpose, but someone thought they could provide a parallel > resource > to easily install additional software? > > Yes, it is. Some people need newer versions for applications than what the > distro can provide. Other need complementary stuff which the distro or > better said RHEL is not willing or not able to provide. > > > [...] > > From Tom's comment I infer there was a need to warn people away from using > some > repos that were consuming significant resources to help folks who had > trusted them. > > Right. Some repos lead to problems similar to: > > Aug 28 14:27:15 <TheAlien> hey there, im having trouble updating > packages on my server. yum update gives a long list of needed updates and > sumarises 'Install 3 Package(s) > / Upgrade 132 Package(s) / Remove 1 Package(s)' but then says > 'package mysql-5.5.25-1.el5.remi.x86_64 (which is newer than > mysql-5.0.95-5.el5_9.i386) is already installed' -- > Aug 28 14:27:24 <TheAlien> plus several messages like 'file > /usr/bin/mysqlaccess from install of mysql-5.0.95-5.el5_9.i386 conflicts > with file from package mysql-5.5.25-1.el5.r > > Others simply are no longer properly maintained, for instance still shipping > older versions of applications which have known vulnerabilities. > > > [...] > > It also appears that somehow Fedora's efforts have been mutually beneficial. > > > Yes, they have but this has nothing to do with the wiki page we speak about. > Incidentally EPEL aims to a high standard so as to make it suitable for an > enterprise-grade distro which CentOS aims to be and that is why we recommend > to all others packagers to follow similar rules ( when possible and if they > make sense, of course ). However this is by no means a requirement that must > be met in order to have a 3rd party repository listed in the CentOS wiki. > > > With these thoughts as background for my thinking, my brainstorm is that the > Special Interest Groups and spins may be the path to solving the need to > have > additional non-CentOS resources and know they are sufficiently cooperative. > > Proposal: > The Third Party Repositories section should not list any other repositories, > but should only note there are difficulties in making several independent > repositories safely usable and give a thorough explaination of what has > happened > in the past without naming names. > > I can only concur with what John has said. You are looking for problems to > fix where there are none. 3 months ago Tom has made a great job in cleaning > the page up ( and several of us assisted him when he asked for opinions ) > and - AFAIK - its current shape expresses the views of most of the regulars > who provide help via the various CentOS support channels. If and when needed > we modify the page but as it is now it is completely satisfactory for its > purpose. Even if the feelings of some people get hurt by our opinions about > the quality of their work ( i.e. of the packages they provide ). > > > _______________________________________________ > CentOS-docs mailing list > CentOS-docs at centos.org > http://lists.centos.org/mailman/listinfo/centos-docs >Thank you for the comments on my conjectures. I will integrate them with my previous data about how this project works. I guess I'm learning I should have let Karanbir Singh handle his own suggestion that if the article seemed to grade the various repos, someone needed to create an objective yardstick. I hope you'll remember I offered some up-to-date contents for the link anchors to those repositories. No one seems to have examined them for validity. I have never used yum or git. I have no way to evaluate the utility of the links that are now in the article. Should they be improved?
Possibly Parallel Threads
- Pull Request wiki.c.o/AdditionalResources/Repositories
- Pull Request wiki.c.o/AdditionalResources/Repositories
- Pull Request wiki.c.o/AdditionalResources/Repositories
- Pull Request wiki.c.o/AdditionalResources/Repositories
- Pull Request wiki.c.o/AdditionalResources/Repositories