From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 289041381F3 for ; Fri, 9 Aug 2013 09:20:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D0D4FE0A88; Fri, 9 Aug 2013 09:20:22 +0000 (UTC) Received: from juliette.telenet-ops.be (juliette.telenet-ops.be [195.130.137.74]) by pigeon.gentoo.org (Postfix) with ESMTP id 9B773E08BD for ; Fri, 9 Aug 2013 09:20:21 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by juliette.telenet-ops.be with bizsmtp id AZLL1m00j2khLEN06ZLLLb; Fri, 09 Aug 2013 11:20:20 +0200 Date: Fri, 9 Aug 2013 11:16:37 +0200 From: Tom Wijsman To: gentoo-dev@lists.gentoo.org Cc: patrick@gentoo.org Subject: Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8 Message-ID: <20130809111637.014e32ea@TOMWIJ-GENTOO> In-Reply-To: <5204376B.60305@gentoo.org> References: <5202416C.5@gentoo.org> <1375881254.7753.41.camel@rook> <5202DD20.8050906@gentoo.org> <5203A880.1050306@gentoo.org> <5203B190.80306@gentoo.org> <20130808172340.7d2424af@TOMWIJ-GENTOO> <5203C908.1000304@gentoo.org> <20130808185357.4208db83@TOMWIJ-GENTOO> <5204376B.60305@gentoo.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.20; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/S2scbQ0YDRqiuRI6NvuXeyE"; protocol="application/pgp-signature" X-Archives-Salt: d0189cf5-5561-495b-8055-a879c492a713 X-Archives-Hash: 07365dfc426603e2d620e02217b5b357 --Sig_/S2scbQ0YDRqiuRI6NvuXeyE Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 09 Aug 2013 08:27:23 +0800 Patrick Lauer 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. > >=20 > > This isn't a good example, because the PMS compliance governs over > > this. > >=20 >=20 > 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. > >=20 > > 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. >=20 > 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. --=20 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 --Sig_/S2scbQ0YDRqiuRI6NvuXeyE Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBAgAGBQJSBLN1AAoJEJWyH81tNOV9GoMIAMVT8uW8oH/nbtJqr+GbQBII yJ0taprliObQMpGj84xu9HBZrB0txUzKxYTf/AkFlNAELbDlvr31G4S22G7Tzw7n NYYJfHEnDFEeoc9de2J3hHAdvZYqqq+2pugyL6cLK8Bp599gUiCjr7LYghHek4Yl sPKJ1oEb9DllJFir3FBxk6zBU4bMco3PHfb5gS1SeEkaitCD4xDR+NMsUu1gp0+q I7jY+8yOPbkj+pgE/yiYlYbf58i5DjEiDu8iK2iWea0OSob3Tdv2lqfZzXO6GjLu aaZJxEJCIu38D7mdtqmSqe9bqbgTaW6L91glqS/fyGjUX6XNUybpm9ODq9fiNGA= =NbxJ -----END PGP SIGNATURE----- --Sig_/S2scbQ0YDRqiuRI6NvuXeyE--