Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

[Tom Wijsman]

On Fri, 24 Jan 2014 14:29:02 -0600
Steev Klimaszewski <steev@g.o> 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@g.o> 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@g.o
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D