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 A427E13827E for ; Fri, 24 Jan 2014 19:30:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A3C72E0B70; Fri, 24 Jan 2014 19:30:30 +0000 (UTC) Received: from albert.telenet-ops.be (albert.telenet-ops.be [195.130.137.90]) by pigeon.gentoo.org (Postfix) with ESMTP id 90C34E0B60 for ; Fri, 24 Jan 2014 19:30:29 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by albert.telenet-ops.be with bizsmtp id HvWU1n00j2khLEN06vWUr9; Fri, 24 Jan 2014 20:30:28 +0100 Date: Fri, 24 Jan 2014 20:29:19 +0100 From: Tom Wijsman To: steev@gentoo.org Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy Message-ID: <20140124202919.2dddf2b3@TOMWIJ-GENTOO> In-Reply-To: <1390587030.24681.10.camel@oswin.hackershack.net> References: <52D5F0BF.3060305@gentoo.org> <20140115024604.GA3952@laptop.home> <20140115232804.1c26beda@kruskal.home.chead.ca> <20140116234442.27c361d1@TOMWIJ-GENTOO> <20140119143157.72fc0e91@kruskal.home.chead.ca> <20140120014713.2cafc257@TOMWIJ-GENTOO> <20140123181242.GA17827@rathaus.eclipse.co.uk> <20140123201333.71e52bfc@TOMWIJ-GENTOO> <1390510534.14914.22.camel@oswin.hackershack.net> <20140123233806.4709abd5@TOMWIJ-GENTOO> <20140123224228.1780.qmail@stuge.se> <20140124005040.350249c9@TOMWIJ-GENTOO> <1390521859.3909.3.camel@oswin.hackershack.net> <20140124040444.058bd7a7@TOMWIJ-GENTOO> <1390535567.3909.12.camel@oswin.hackershack.net> <20140124182607.52b3c52c@TOMWIJ-GENTOO> <1390587030.24681.10.camel@oswin.hackershack.net> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.22; 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_/rd_.13W.BR7m22xL.kLoNqK"; protocol="application/pgp-signature" X-Archives-Salt: c1793189-cc1a-475b-92b0-8f5c1e89092b X-Archives-Hash: 9d8d216e698640b13f3b209b4bb9c6fe --Sig_/rd_.13W.BR7m22xL.kLoNqK Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 24 Jan 2014 12:10:30 -0600 Steev Klimaszewski wrote: > The problem isn't finding someone that has everything - we have people > that test on ARMv5, some that test on ARMv6, we have some that test on > ARMv7 - until ALL of them are tested, it doesn't get stabled on ARM. > So again, it just shuffles around the work, and does nothing to > address the actual problem which is manpower with people that have > the slower machines to finish their testing. Unless you would like > to suggest that we maybe just say fuck anyone using a slow machine? Consider how packages would rarely get stabilized if we had to wait for all arches to test them first before adding any stable keyword at all. Organize first, then get more manpower; otherwise we say the F-word to everyone with a faster machine. Joining arm with a slower configuration and have everyone waiting on you is a working condition to avoid; so, we could have the slower configuration stabilize at its own pace. Would we say F-word to 'em? No, we give them better working conditions. > I disagree, and think we should take care of all of our users, not > just the bleeding edge and fast users. Theoretically, yes, everyone wants that; in practice, manpower as well as performance is limited, which makes "taking care of all" a rather hard to aim goal. We still aim to satisfy everyone; I look at discussions from multiple sides to see how we can satisfy as much people as possible, hence providing multiple solutions. It however is rare that a solution works for everyone, there are too much requirements for that to be possible. But, making it hold up other people's work is a recipe for problems, to which point someone comes up with a forced stabilization as you gave as an example. In other words, minor configurations shouldn't stall things forever; just like minor arches shouldn't stall things forever, which would have been a huge problem if we would only allow stable keywords to be added when all the arch teams have tested it. > > > Getting them into the arch team and willing to run stable and > > > actually test programs is a whole other story, which lead to you > > > saying: > > >=20 > > > "People that have certain architectures can just add themselves, > > > no extra work again." > >=20 > > Which is for people already on the arm arch; consider the context > > you quote this from, rather than assuming what is not explicitly > > stated. > >=20 >=20 > That doesn't make any sense - if they are already on the arm arch > team, they are already in the list. Being on the arm arch team alias, they can add themselves to the individual configuration teams aliases; as per the context. > That wasn't the context of the quote AT ALL. It was: @TomWij | Why would it result in more emails? When you are part of multiple aliases you can have it filter down to one; or otherwise, you can just sort them down to folders and only keep the revelant ones. @steev | so we should have armvX aliases? @steev | what if you want package X to be stable on only armv5 and armv7=20 @TomWij | Yes, then you just CC those. @steev | and those go to the arm alias, or we have to create armvX aliases, and add people to that - again, more work for me, less work for you - nothx @TomWij | steev: People that have certain architectures can just add themselves, no extra work again. > And I told you when you > said that it would allow people to add or remove themselves willy > nilly, and that is NOT going to happen - and would NOT be good for QA. You keep bringing up this assumption; it has been made clear multiple times that so far, like for instance right after you have made it: @steev | no. @steev | the point of the arch team isn't so people can randomly pop in, add themselves, do something, then leave the team willy nilly @TomWij | Indeed, as I said half an hour ago. Note that this comes right after the previous quote of the context. And that reference to half an hour ago points to this: @steev | TomWij: because people are breaking stable, and if someone isn't happy with the arch team's speed, they should join the arch team to help out, and realize just how much work it ACTUALLY is @steev | should we allow anyone with an android phone to stable for arm because they can throw a gentoo chroot onto their phone? @TomWij | Under the condition proper arch testing is done, thus according to arm's arch policies; that should be fine to do yes. If you need it tested on multiple configurations, then I guess the person could use multiple phones. > > > What you've thrown out as a possible solution is akin to taking a > > > pile of peas on the plate and moving them around the plate so > > > that the pile doesn't look so big. =20 > >=20 > > In other words, using separation to organize them properly. > >=20 > > > It doesn't change the amount of work, but you do need to look in > > > more places for the work. > >=20 > > Which you can collect back into one place. > >=20 > > > Finding people with the hardware is the main issue, and I think I > > > mentioned before, some people are simply unwilling to invest in > > > "slow" hardware, so we have to rely on the people who DO have it. > > > And if that means things take longer to stable, well, why is that > > > an issue? Stable is supposed to be that - stable. =20 > >=20 > > That is because you only look for people that have all the hardware. > >=20 >=20 > No, we do not look ONLY for people that have all the hardware. But > until it's tested on all of the arm arches, it doesn't get stabled. So > your suggestion is "split it out to blah blah blah blah" - so that > moves it around - but you know what? the slower machines are STILL > going to take forever (because they are slow!) and the ebuilds will > still need to stick around, because we will still be waiting. > Problem NOT solved, problem just moved around a tiny bit. =20 Your configurations problem would be solved, which is a good start; so, let us fix actually fix it, instead of covering it up and waiting. > > > So, as QA, shouldn't you be doing something about that, rather > > > than pointing to some URLs on the web, telling me I'm in the > > > wrong for using the option that is supposed to handle that > > > properly in my stable software? > >=20 > > The problem lies in a different place than the software itself. > >=20 > > Spoken like a true QA person. Glad this is the type of person we have > on our QA team. >=20 > This is why everyone makes fun of our QA team, because we allow people > in who don't actually give a shit about QA, only about covering up > issues so they appear good but don't actually fix shit. Can we talk about the matter instead of about the person? So, how to fix a problem in software when it is not in the software? PS: Note that I have been devaway for almost two weeks. --=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_/rd_.13W.BR7m22xL.kLoNqK Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJS4r8PAAoJEJWyH81tNOV9W/EIAI2ueYbrFI1Gmxkc/2JDBMvB PMfXsLQ2PVbgCWx/QlX7iuS7NKF2egE14/J3ICsz9M1rDJUVxlkc1MmviXmJ/Bfb eU7scOmycGkXUIqkl1C5lDityjgWfyqcY1znItMspfQdtyDsCxEaXFFlXF1OX1wJ fNc4MwZvQYHAKnD27Sg9dXmveXJc/d8UkSpEOmHnt4OJ6lGGBHOlY5zMJQcfkbIb xwOwx9tEqQFiy4572CIBh9P2WEplcPw97Dri9Rza6jVocyN3qAJgWWeAloxUBiuF QWwGATZp2qIThNermG2wYhWWKRrbfQtHslgNSKbkxvj7ITQRdgM5RM4Jazn5aoA= =FRtg -----END PGP SIGNATURE----- --Sig_/rd_.13W.BR7m22xL.kLoNqK--