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 some repos 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.