On Fri, 09 Aug 2013 08:27:23 +0800 Patrick Lauer <[email protected]> wrote:
> [snip] > >> 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. So, this can also be interpreted as masking Portage until it is fixed; there is no implication that the package not working with Portage is a QA failure of the package, as it might be Portage having a PMS failure which the package. This is not an excellent example, it is confusing... I do not argue that packages get masked due to QA failures; but I don't see how GNOME 3.8 only working with systemd, is to be a QA failure? So, unless you come with a better example and show it is a QA failure, I won't see what meaning this confusing example has in this discussion. > >> 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. It doesn't intend to work with OpenRC; so, it is not a regression. Regression testing is done to test whether functionality broke, functionality that is specified as requirements of the package; as OpenRC is no longer a requirement, it can not be a regression. There are also no bugs as a result of that, or at least not in the terms of those that need fixing; they are rather a feature request. > 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. It's better for them to be vivid in a corner than for them to dry out; the situation might or might not be interpretable as difficult, either way things are the way things are and it's not so easy to change. > (Plus an uncooperative upstream, so all the "blame" gets thrown at > the gentoo maintainers from both sides. Awesome way to destroy crew > morale :) ) Why should upstream do additional work, causing them extra time, keeping them back from progressing; there is much more work they need to do than to support an alternative init system some minority uses. If we can't write up the patches to make it work, why can they; they need to do the equal amount of work that we do. For this to happen some big initiatives are needed; ranging from trying to really convince upstream people to do the work, or convincing downstream people to jump in and help port it to work with the alternative init system. Until either of that happens; upstream won't really see the need and downstream won't be able to provide a patch, so "uncooperative" people upstream and "blame" downstream are just normal things. What we're really missing is enough people that want to make it happen; which means, they give up part of their time to it that they could perhaps invest in something else that might be more necessary. Though, an init system standard might be the most promising approach. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : [email protected] GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
