On Wed, 7 Aug 2013 08:00:51 -0400 Rich Freeman wrote: > On Wed, Aug 7, 2013 at 6:44 AM, Tom Wijsman wrote: > > On Sat, 3 Aug 2013 10:28:59 -0500 > > William Hubbs wrote: > > > >> Markos, to answer your question, there are folks on the team, and > >> at least one user, using OpenRc from git without issues, so as far > >> as I know there shouldn't be any breakage. > > > > A few team developers is not a large enough test base for an > > important package that is to be installed and ran on _hundreds to > > thousands_ of user systems; I think you could reword future > > warnings to invite people to unmask and test this important package > > version bump, and then state it will be unmasked in X days if > > nothing bad gets reported. > > If a maintainer thinks that such a testing period is warranted they're > welcome to call for it. --- TL;DR, clarifying intention --- True, I'm merely outlining the possibility for them to consider. > However, I certainly wouldn't make it a requirement for putting a > package into ~arch - even a system package. This should indeed be no requirement, there isn't really a group of packages you could simply label "must be tested as masked"; taking this thread an example you could say 0.11.x -> 0.12 could use testing whereas 0.12.0 -> 0.12.1 or a future 0.14.x -> 0.15 might/will need not. It kind of depends on the details of the change log; but when a maintainer announces that things might break and only a very small amount of people tested it, it is worth a concern and consideration. --- Reasoning, feel free to ignore --- > If hundreds to thousands of users are running ~arch, then that means > that we have hundreds to thousands of users who don't mind their > systems occasionally not booting after an upgrade. Still, why do we need to break hundreds to thousands of users with something that is easily avoided by first letting some more people test it before releasing it to the masses. Let's say you release it to the masses; there appears to be something heavily broken disallowing a wide enough share of people to not be able to boot their system, then you apply the package mask after the fact. You just got a lot of people to install something that is broken and gets masked just the day after release causing a downgrade again; something that could have been added as masked right away, because really, the maintainer didn't know if it was ready for wide testing. In terms of machine and man power, there's still a huge considerable difference between breaking the system of a few users and some hundreds users; if you can avoid the latter, why not do it? "Broken" is free for interpretation; while most people don't mind that their system does not boot after the upgrade, the story gets somewhat different if their system got in an inconsistent state where a simple downgrade doesn't appear to work. Please note that some people run ~ because they can't mix non-~ and ~, because they need to run GNOME 3, because they find the stable gap too big or are bothered by packages that don't get stabilized on time. Anyhow, discussing the borders is bike shedding; it's just a suggestion. > Besides, who does an emerge -u world without first checking to see > what will be updated? If I see openrc on the list I certainly don't > run the upgrade over ssh while I'm on vacation, and I always make a > binary package with config before doing so. Some people do, but that's not what this is about. > ~arch is for testing. That's what you sign up for if you run it. You > ARE the volunteer. When a maintainer says "might be broken", it means that the maintainer doesn't know whether the package belongs to ~ or package.mask; so, that also means not enough testing has been done to consider adding it to ~. It's at the maintainer's decision to go ahead or not; there's nobody going to stop the maintainer from adding it to ~. But there are people that going to complain (users), take action (QA), ... when hell does break loose because of careless maintenance; putting something in package.mask for some days doesn't hurt people, big breakage does. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D