[snip] >> On 08/08/2013 05:26 PM, Rich Freeman wrote: >>> OpenRC is just one init system that Gentoo supports. Gentoo does >>> not require the use of OpenRC any more than it requires the use of >>> portage as the package manager. >> >> So would you stabilize a package that works with paludis, but not with >> portage? Ouch. It should probably not be in the tree in the first >> place, but I that's not what I have in mind here. > > This isn't a good example, because the PMS compliance governs over this. >
It is an excellent example. If it doesn't work with portage that's a QA-failure and reason to mask until fixed. As PMS is incomplete and often not reflecting reality it's not a good baseline. >> I generally expect packages to work with... now be surprised... BOTH >> init systems, although I don't like systemd. If it doesn't work with >> one, then it's a bug. Bugs block stabilization. >> It is a _REGRESSION_. Ask the arch team about the meaning of >> regression if unsure. > > It's not a regression; actually, it's quite common to drop features > that can no longer be supported. I don't see us blocking stabilization > for other cases in the Portage tree where a feature has been dropped. > It is a regression: If it doesn't work with OpenRC I can't use it (same with portage), and thus it deserves a liberal dose of bugs and masking if bugs don't get fixed on time. What makes this situation so difficult is that it's not a single random package, but one of the bigger desktop environments that has painted itself into a corner. (Plus an uncooperative upstream, so all the "blame" gets thrown at the gentoo maintainers from both sides. Awesome way to destroy crew morale :) )
