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 94216138A2F for ; Fri, 24 Jan 2014 21:56:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C6217E0BCF; Fri, 24 Jan 2014 21:56:19 +0000 (UTC) Received: from andre.telenet-ops.be (andre.telenet-ops.be [195.130.132.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 817A5E0BAF for ; Fri, 24 Jan 2014 21:56:18 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by andre.telenet-ops.be with bizsmtp id HxwH1n00H2khLEN01xwHKV; Fri, 24 Jan 2014 22:56:17 +0100 Date: Fri, 24 Jan 2014 22:55:08 +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: <20140124225508.392c53d4@TOMWIJ-GENTOO> In-Reply-To: <1390595342.24681.14.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> <20140124202919.2dddf2b3@TOMWIJ-GENTOO> <1390595342.24681.14.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_/+RZJUDthmm+m_wpE1BSVU3T"; protocol="application/pgp-signature" X-Archives-Salt: f57c5b61-7345-48d2-9dc1-e24bed4a02a4 X-Archives-Hash: 3185bb54198dbcf39db8ab76480a575f --Sig_/+RZJUDthmm+m_wpE1BSVU3T Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 24 Jan 2014 14:29:02 -0600 Steev Klimaszewski wrote: > On Fri, 2014-01-24 at 20:29 +0100, Tom Wijsman wrote: > > On Fri, 24 Jan 2014 12:10:30 -0600 > > Steev Klimaszewski wrote: > >=20 > > > 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? > >=20 > > 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. > >=20 >=20 > Theoretical, again, as always, and not even worth considering because > it doesn't reflect reality. We are talking about reality here, while expanding it on a larger scale; as to make it more clear how that wouldn't work out well in reality. > > 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. > >=20 > > Would we say F-word to 'em? No, we give them better working > > conditions. > >=20 >=20 > We're all adults here, you can say fuck. What about better working conditions? > For the record, the ARM team does just fine in stabling things in a > reasonable amount of time, so no, we aren't going to change our > working methods. That is a contradiction with what you have said earlier. So, is there an ACTUAL problem with the ARM team or not? In context, you have demonstrated a result of that problem here: @steev | and then you end up with stuff like git is broken on armv7 uclibc @TomWij | steev: Better to know that than to know that it is broken on arm uclibc. @steev | TomWij: it was known that it's broken, it was stabled anyway, which makes it worse @steev | because i commented and said DO NOT STABLE IT > The point of this email thread was we all need to stable faster, That is just a deduction from your point of view; as stated before, that's a possible deduction you can easily make now. But, deducing it every time without guaranteeing that the arch teams improve can lead to it worsening over time; which is something we need to look out for. > and slower arches need to just become unstable only, What about slower configurations keeping up slower arches? > and fuck them. And I'm saying everyone needs to step back because > stabling things faster and faster doesn't allow for proper testing. >=20 > As QA, you should be focusing on making stable, actually stable, not > more bleeding edge. That's the task of the mentors, recruiters and the arch teams; the QA team is there to ensure quality, not performance. If performance limits us from stabilizing everything we want to see stabilized properly, that means that there is simply a lack of interest; then this thread as well as QA comes in to reorganize our efforts as well as policy to be more efficient and effective. The delays that can be witnessed in the actual problem you have brought forward is one example of what can be reorganized to not delay stabilization; another example of what I am working towards is to try to get more people by making our documents for new developers more accessible, some examples: - Revised https://wiki.gentoo.org/index.php?title=3DContributing_to_Gentoo&oldid= =3D11534 to https://wiki.gentoo.org/index.php?title=3DContributing_to_Gentoo&oldid= =3D83101 - Added reference in the devmanual to the developer handbook: https://github.com/gentoo/devmanual.gentoo.org/commit/ced738e2cf213f7001= a4f39cd561983f71631582 - Start a guide that introduces how to write an ebuild from scratch: https://wiki.gentoo.org/wiki/Basic_guide_to_write_Gentoo_Ebuilds Yes, QA is doing something about that. To take this whole thread a step further, it is proposed as an agenda topic for the first QA meeting. https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Agenda --=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_/+RZJUDthmm+m_wpE1BSVU3T Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJS4uE8AAoJEJWyH81tNOV9YTwH/1Lsqeq3kJctQajvZjBzDtdH OELpfLXFwha1ZCRcXGKdzIRKA/rOTcAYjbvrIYnBKjml+TnuaZnmgRZJccwcPuQR GRKUxcZOf4dHsFiK1SGcHNUkyQPF4rJ6dH0YGoSn0rjuNM5ErkY5oD3rLcRqzgCL TR78OMQF9CFExHrxbj8BbG4szKLU9MWWGINI7WSNIS612C68S64UAIjsQXyqU6au EQw+XNC1GfOOkb/hFMI1AOXQAqm5uqUXp9VjI6NGwxb14MdxmgtK6qdk62KGGAax Pr9FtTDal7IjEN4Oe3M98Pr5dAyu3AoQUWGbglX9GagzhCE5IrrIsIAb1vphR8o= =98kv -----END PGP SIGNATURE----- --Sig_/+RZJUDthmm+m_wpE1BSVU3T--