* Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
@ 2014-01-24 21:55 99% ` Tom Wijsman
0 siblings, 0 replies; 1+ results
From: Tom Wijsman @ 2014-01-24 21:55 UTC (permalink / raw
To: steev; +Cc: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 4669 bytes --]
On Fri, 24 Jan 2014 14:29:02 -0600
Steev Klimaszewski <steev@gentoo.org> wrote:
> On Fri, 2014-01-24 at 20:29 +0100, Tom Wijsman wrote:
> > On Fri, 24 Jan 2014 12:10:30 -0600
> > Steev Klimaszewski <steev@gentoo.org> 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.
> >
>
> 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.
> >
> > Would we say F-word to 'em? No, we give them better working
> > conditions.
> >
>
> 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.
>
> 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=Contributing_to_Gentoo&oldid=11534
to
https://wiki.gentoo.org/index.php?title=Contributing_to_Gentoo&oldid=83101
- Added reference in the devmanual to the developer handbook:
https://github.com/gentoo/devmanual.gentoo.org/commit/ced738e2cf213f7001a4f39cd561983f71631582
- 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
--
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2014-01-15 2:21 [gentoo-dev] rfc: revisiting our stabilization policy Michael Orlitzky
2014-01-15 2:46 ` William Hubbs
2014-01-16 7:28 ` Christopher Head
2014-01-16 22:44 ` Tom Wijsman
2014-01-19 22:31 ` Christopher Head
2014-01-20 0:47 ` Tom Wijsman
2014-01-23 18:12 ` [gentoo-dev] " Steven J. Long
2014-01-23 19:13 ` Tom Wijsman
2014-01-23 20:55 ` Steev Klimaszewski
2014-01-23 22:38 ` Tom Wijsman
2014-01-23 22:42 ` Peter Stuge
2014-01-23 23:50 ` Tom Wijsman
2014-01-24 0:04 ` Steev Klimaszewski
2014-01-24 3:04 ` Tom Wijsman
2014-01-24 3:52 ` Steev Klimaszewski
2014-01-24 17:26 ` Tom Wijsman
2014-01-24 18:10 ` Steev Klimaszewski
2014-01-24 19:29 ` Tom Wijsman
2014-01-24 20:29 ` Steev Klimaszewski
2014-01-24 21:55 99% ` Tom Wijsman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox