devel

devel@lists.centos.org

7 participants
4633 discussions

testing / qa process
by Karanbir Singh 20 Oct '06

20 Oct '06

Dear centos-devel'ers, We have a problem that needs fixing. The strategy to release testable rpms to dev.centos.org, then request feedback and move the rpms to stable, when we have enough positive - isnt working. We're not getting that feedback, either positive or negative. End result is that we have packages going stale and now some of those packages need updates in themselves. Looking at the logs, I can assure you that people are using those packages, just not telling us anything about them. There is one chain of though, that such request based qa process's dont work and have been tried by other Open Source projects before and not really had much of a success rate. Now, there are a few options and alternative process's that I've been thinking about, but rather than throw that out here, I'd really like to see what everyone on this list thinks and what options / process's / workaround's we might be able to come up with here. So the issue : The CentOS Project provides packages in addition to the packages from RH's sources. We need to ensure that these packages are tested in a user environment for a while, and only released to the public via the mirror.centos.org network once there is some reasonable surety as to the functional and bugs situation with the package. ideas / comments / noise welcome.. -- Karanbir Singh : http://www.karan.org/ : 2522219@icq

8 15

Re: Metalinks for CentOS (all mirrors & checksums in one file)
by Anthony L. Bryan 17 Oct '06

17 Oct '06

> We spoke about this earlier, and I also asked for comments - we didnt > get too many here on this list. But, it would still be a good idea to > get this somehow integrated into the CentOS release process. > > Making it easier and adding more options to spread loads is always a > good idea IMHO. Yes, some comments would be encouraging but I guess this isn't all that interesting. Anything I can do to make metalink more useful to you, let me know. I agree, spreading load & making things easier is good. I definitely think metalink could simplify your ISO download page as well. How about an alternate page for ISO downloads to test metalink out? Have a link for feedback on what people think. If it's positive, make it more prominent. I think once you start using it, you'll prefer it, like the groups using it now. Metalink tools (http://prog.infosnel.nl/metalinks/) generates them easily. It either creates all the hashes for files, or can read an md5sum file and generate them from a list of mirrors. I have a text list of your mirrors but it might not be fully up to date. I used it to make the ones at http://www.metalinker.org/samples.html#isos for the live CD, install CDs, & DVD for i386. (( Anthony Bryan )) Metalink [ http://www.metalinker.org ]

1 0

Re: [CentOS-devel] CentOS-4.4 yumconf
by C.M. Connelly 17 Oct '06

17 Oct '06

"CMC" == C.M. Connelly <cmc(a)math.hmc.edu> "JH" == Johnny Hughes <mailing-lists(a)hughesjr.com> I'm sorry if my comment was misconstrued -- I do appreciate the (unpaid) time and energy you and others devote to CentOS, but as an end user, while I can and do try to contribute in some ways (such as filing bugs and reading and participating in mailing lists), I cannot justify hanging out on IRC in the hope that something I need to know might get discussed. [...] JH> If that is not the kind of OS you want, then you can pay JH> $2500.00 a pop for a much more professional one. Oh, but JH> every update cycle, they still make major changes. Look JH> at the new things added this update cycle. I did. I read through the upstream release notes before the packages were built for CentOS. There's nothing in RH's notes about the change in YUM/up2date configuration files. Looking at the notes again now, I see that they have lots of changelog extracts from various packages. But not for redhat-release. The CentOS release notes also don't mention the change. JH> That might be true and MANY things are worked out devel JH> list. MANY, MANY things are discussed here. However, the JH> yum configuration files, as well as the ones for up2date JH> and any other update mechanism need to be in JH> centos-release ... and that is where they are staying. Ultimately I don't care where the files live, but it would have been nice to have had a heads-up about the change so that my machines didn't suddenly start updating from random mirrors. And it would have been even nicer to have had some advice from the CentOS developers on the ``right way'' to change the configuration so that it wouldn't break. JH> I apologize for not discussing this issue on this list JH> before it was done, however it is still where those files JH> belong. One of the things that is in our goals is to be JH> more like upstream. It just makes sense to do it the same JH> way where ever possible ... I am sorry that this affected JH> some power users in an unexpected way, but it is still JH> where the files belong. As it happens, all it really did was to make my workstation and a test machine start getting packages from other mirrors, as I haven't yet rolled CentOS 4 out more widely. I wasn't angry about the change, just a bit annoyed that I hadn't known about it beforehand and that there didn't seem to be a clear way to set things up so that they would work properly. I think that we have that now (any of several possible solutions that include removing CentOS-Base.repo and replace with an empty file), so I'm satisfied. (Keeping the separate yumconf package would have been easier for me, but I totally understand where you're coming from in wanting to track upstream closely, and it's clear from Fedora that that's where RH is going with these files.) I'm sorry that you and Karanbir took my and others technical criticism so personally. I *greatly* appreciate the work of the CentOS developers -- you've saved me an enormous amount of work, as the announcement of CentOS came when I was in the process of doing a major reassessment of our OS plans after Red Hat had announced the end of life of Red Hat Linux and before they'd said anything about academic pricing. CentOS allowed me to build on the work I'd already done to support deployment and maintenance instead of starting from scratch with a new distro. At this point, we could buy licenses from RH for a much lower academic price, but the department doesn't really have that kind of money. CentOS allows me to run an OS that has better support than RH's current offerings for academia (i.e., *any*); is more up to date than some other options (e.g., Debian), but still quite stable; and also allows me to contribute something back to the community in the form of feedback and bug reports, as well as the mirror we provide for the releases and architectures that we currently run. Thank you both for your work (as well as the other developers not participating in this thread). And thank you for your apology for not discussing the change on the list. Claire *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Claire Connelly cmc(a)math.hmc.edu Systems Administrator (909) 621-8754 Department of Mathematics Harvey Mudd College *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

1 0

Metalinks for CentOS (all mirrors & checksums in one file)
by Anthony L. Bryan 16 Oct '06

16 Oct '06

Hi, Still seeing if you'd like to use metalinks for your ISO downloads. Metalinks contain mirror and p2p locations along with checksums and other metadata for faster and easier downloads. Downloads are distributed between mirrors and checksums are automatically verified when it finishes. Here's a good description: 'Metalink makes complex download pages obsolete by replacing long lists of download mirrors and BitTorrent trackers with a single .metalink file. As you might have already guessed, a .metalink file is a file that tells a download manager all the different ways it can download a file. The file itself takes the form of an open XML standard that can list an unlimited number of HTTP and FTP sources as well as BitTorrent trackers and ed2k and magnet links.' (http://www.downloadsquad.com/2006/08/28/metalinks-integrated-bittorrent-htt p-and-ftp-downloads/) There's a metalink for CentOS at http://www.metalinker.org/samples/CentOS-4.4-i386-LiveCD.iso.metalink if anyone wants to try it out. Here's what part of it looks like: <file name="CentOS-4.4-i386-LiveCD.iso"> <version>4.4</version> <verification> <hash type="md5">747c9e33a10fdbf5919d9fd188ab7d23</hash> </verification> <resources> <url type="http" preference="100">http://altruistic.lbl.gov/mirrors/centos/4.4/isos/i386/Cent OS-4.4-i386-LiveCD.iso</url> <url type="http" preference="100">http://centos.mirror.nac.net/4.4/isos/i386/CentOS-4.4-i386- LiveCD.iso</url> <url type="http" preference="100">http://dist1.800hosting.com/centos/4.4/isos/i386/CentOS-4.4 -i386-LiveCD.iso</url> <url type="http" location="us" preference="100">http://ftp.osuosl.org/pub/centos/4.4/isos/i386/CentOS-4.4-i 386-LiveCD.iso</url> </resources> Download clients are available for Unix, Mac, & Windows. aria2 RPMs for Red Hat Enterprise Linux 4 are at http://dries.ulyssis.org/rpm/packages/aria2/info.html OpenOffice.org and many Linux/BSD distributions are using metalink. Here's a few places: http://distribution.openoffice.org/p2p/magnet.html http://en.opensuse.org/Released_Version#Metalink http://desktopbsd.net/index.php?id=73 http://www.pcbsd.org/?p=download http://www.archlinux.org/download/ http://www.redwall-firewall.com/content/view/14/33/ http://yui.mine.nu/berry/edownload.php http://puppylinux.org/wikka/Puppy210 (( Anthony Bryan )) Metalink [ http://www.metalinker.org ]

2 1

Holger Daehre/SPOERLE ist außer Haus.
by Holger Daehre 15 Oct '06

15 Oct '06

Ich werde ab 02.10.2006 nicht im Büro sein. Ich kehre zurück am 30.10.2006. Ich werde Ihre Nachricht nach meiner Rückkehr beantworten.

2 1

Re: [CentOS-devel] CentOS-4.4 yumconf
by C.M. Connelly 14 Oct '06

14 Oct '06

"JP" == Jim Perrin <jperrin(a)gmail.com> Jim, JP> This was discussed before implementation, in the -devel JP> channel on IRC. The full ramifications weren't felt JP> initially because it worked fine for stock centos. If JP> you'd like to participate in the discussions, you're JP> welcome to join the irc channel. Like, I suspect, most people using CentOS, I'm not paid to work on the OS, and I don't have time to hang out on IRC on the off chance that someone will bring up something that might completely screw up my systems down the road. To be frank, saying, ``Oh, we talked about that on IRC,'' is about as useful as saying, ``Jennie, Bob, and I talked about it over a drink at the Boo Bar.'' IRC is a great place to work out implementation details and maybe even do some thought experiments to imagine what the impact might be, but mailing lists are a much better place to have real discussions, especially when your changes might impact people outside the tiny circle of people who frequent the IRC channel. Claire *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Claire Connelly cmc(a)math.hmc.edu Systems Administrator (909) 621-8754 Department of Mathematics Harvey Mudd College *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

9 14

RE: [CentOS-devel] Re: testing / qa process
by Alex Palenschat 13 Oct '06

13 Oct '06

> Instead of blocking on (lack-of) feedback, I'd suggest > considering something > like: > 1. Put pkgs in "testing" > 2. If no bugs reported after X days/weeks, move out of testing > > At least this way nothing gets perpetually stalled in testing. > > -- Rex > Just my 2 cents, but I have used some packages in the testing repo successfully. I certainly am not in a position to test them in a large production/enterprise environment and outside of the testing repo I try really hard to stay as vanilla as I can with my boxes. But I'm not certain what I can do except troll this list and say WorksForMe when somebody asks. I wouldn't guess that the signal-to-noise-ratio would be acceptable if everytime I successfully installed and used for a week package x that I post a new thread saying it worked. Perhaps you could find a method of requiring prospective users of the testing repo to subscribe to this mailing list. That way more users would see when a question/poll was asked in regards to a given package. Just an idea, Alex

2 1

Re: [CentOS-devel] CentOS-4.4 yumconf
by C.M. Connelly 11 Oct '06

11 Oct '06

"JN" == John Newbigin <jnewbigin(a)ict.swin.edu.au> JN> The easiest workaround I found was to add reposdir= JN> to your /etc/yum.conf [main] section. JN> This means you can't add other repos into that directory JN> but I don't normally do that anyway. Good if you don't, but if you wanted to, say, also use the RPMForge repositories, their package installs new .repo files into /etc/yum.repos.d. I'd imagine that most yumconf packages would do the same, as /etc/yum.repos.d is the standard location for those packages. Claire *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Claire Connelly cmc(a)math.hmc.edu Systems Administrator (909) 621-8754 Department of Mathematics Harvey Mudd College *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

2 1

Re: [CentOS-devel] CentOS-4.4 yumconf
by C.M. Connelly 11 Oct '06

11 Oct '06

"KS" == Karanbir Singh <mail-lists(a)karan.org> KS> rm /etc/yum.repos.d/CentOS-Base.repo KS> touch /etc/yum.repos.d/CentOS-Base.repo KS> and the file wont get in the way anymore / anyless than it KS> did previously. That seems to work and I can easily add code to my setup script to do just that. It would be nice, however, if any future changes made by the CentOS team to the way fundamental aspects of the OS work were discussed before they're made, instead of making changes, breaking things, and then being abusive to everyone who has problems. Claire *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Claire Connelly cmc(a)math.hmc.edu Systems Administrator (909) 621-8754 Department of Mathematics Harvey Mudd College *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

2 1

Re: [CentOS-devel] CentOS-4.4 yumconf
by C.M. Connelly 11 Oct '06

11 Oct '06

"KS" == Karanbir Singh <mail-lists(a)karan.org> KS> Just to do a recap to make sure we all understand the KS> position here. KS> There are 4 sorts of user cases, been addressed so far. [...] KS> did i miss someone ? Yes. 5. People who have replaced the centos-yumconf package (not just files in that package) with their own yumconf package that does not provide repository configuration files with the same names as the (old) centos-yumconf and the (current) centos-release package; i.e., CentOS-Base.repo. For those folks, the 4.4 redhat-release package plunks down a CentOS-Base.repo file. As my repo file is called HMC-Math-Base.repo, yum ignores my file and uses the new CentOS-Base.repo file instead for repository sections defined in both files. Adding ``enabled=0'' lines to the repository section in the CentOS-Base.repo file causes yum to complain about multiply defined repositories. Being able to replace the centos-yumconf package was a fairly low-key intervention that allowed me to maintain a pristine mirror of the upstream CentOS tree and do a basic install from that tree using a kickstart file, then, in a setup script run on first reboot, replace the centos-yumconf with my own, do updates, install local packages, and so forth. I'm not eager to have to rebuild the centos-release package for each update, so maybe the answer is to make my yumconf package supply CentOS-Base.repo and install it with the --force flag, but I preferred having a different name so that it would be obvious that we were using a local mirror. From my perspective, having the separate centos-yumconf preserves this behavior while remaining transparent to users who don't need to override repositories. Claire *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Claire Connelly cmc(a)math.hmc.edu Systems Administrator (909) 621-8754 Department of Mathematics Harvey Mudd College *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

4 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel