Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Tom Wijsman <TomWij@gentoo.org>]

On Wed, 05 Feb 2014 20:00:41 -0500
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:

> > Can this be proven? Why are maintainers like WilliamH upset about
> > this?
> > 
> > Reference: http://article.gmane.org/gmane.linux.gentoo.devel/90063
> 
> I've already voiced my concern on his bug:
> https://bugs.gentoo.org/show_bug.cgi?id=500014

Yes; there is some unclear wording causing misconceptions as well as
that you oppose in a way that makes it worth to clarify and vote again,
and I'll ACK hard enough to not discuss this without your presence. 

> > 
> >> If the maintainer doesn't wish to support version X any longer then
> >> they can close bugs wontfix.
> > 
> > +1, but what about stabilization bugs that block other bugs?
> 
> They stay open as a tracker, bugs track all arches.  This doesn't
> prevent the work being done on the faster arches, all it does is leave
> bugs hanging around when certain devs think more closed bugs is more
> better.

My concern with this is that that list is growing; and when that
happens, I'm not so much for "closed bugs", but rather about shifting
our priority to more important bugs, getting new people, better arch
testing quality, and the list goes on...

We could for example use Tinderbox and have it send success / failure
results, build logs and binpkg(s) (for download) to the arch team,
which makes the arch team just have to solely do a quick inspeciton
of the build log and test the binpkg; this automation can cut down on a
lot of manual testing. On top of that, you have Tinderbox's build log
checking on top of that; which can catch some things the eye might not
see at a first take. This was an example from #gentoo-dev yesterday.

> >> Removing the last stable version on an arch from the tree is
> >> against policy.
> > 
> > The QA policy meant to override this; to avoid confusion, I mean
> > including the proper workflow involved in this. But this has raised
> > concerns on IRC today, as it was made clear what the reasons are
> > that I was asking for; it's good that we do a new vote on this to
> > properly reflect what we really intend, rather than some poor
> > voting that went through a quick vote and didn't take everything in
> > consideration.
> > 
> Nothing in the QA policy says "ignore standard removal policy".  Here
> is the standard removal policy, and I expect it to be followed:
> 
> https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html

We do however "revisit" it (subject of original thread); the workflow
(masking, news, ...) of course should not be ignored, however we do
ignore that it says "not to remove the last stable ebuild".

> When a doctor tells you "go to the hospital as fast as you can" he
> doesn't mean "steal a faster car, speed as much as possible, and don't
> stop at red lights".  Doing so would obviously be dangerous, and cause
> additional problems, just like ignoring the standard keyword/ebuild
> removal policy.

Consider that the person will however at least try to test the limits;
and even with those limits in place and following them, the person can
still slowly crash into something. Attention and thoughts are involved.

> >>>> Not the QA team's actions.  YOURS. YOUR actions and responses in
> >>>> this thread.  And the fact that the QA team allows you to
> >>>> continue to be on it, despite your obvious lack of interest in
> >>>> ACTUALLY having quality assurance. My actions are affected by it
> >>>> because I have to continue to attempt to discuss the issue with
> >>>> others who actually give a shit, and you just swoop in and say
> >>>> no, that absolutely is unacceptable as a solution
> >>>
> >>> The policy is made by the QA team; you are attempting to object to
> >>> the policy, therefore this is the QA team's action. This is their
> >>> action.
> >>
> >> Please don't claim you speak for the QA team when in fact, you have
> >> not discussed it with any of us,
> > 
> > We did discuss this QA policy during the QA meeting.
> > 
> >> and the QA lead told you to cool it on irc hours ago.
> > 
> > That was minutes ago, you are replying to is written before that;
> > furthermore, I believe things are cool. Why do you think otherwise?
> > 
> >> You are speaking for yourself here and no one else.
> > 
> > I'm quoting QA team policy, agreed on by at least 8 individuals;
> > that policy can be read at the following URL:
> > 
> > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies
> > 
> That policy doesn't permit removal of keywords/ebuilds without
> following gentoo standard policy, standard policy is available here:
> https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html

Maybe, maybe not; that can be misinterpreted. But what does it permit?

> > If you still think so, can you show me where I did speak for myself?
> 
> As I am also a member of the QA team, clearly there isn't a consensus
> on this topic.

So, there isn't an occasion where I spoke for myself?

> >> There is NO policy that allows for dropping a stable ebuild without
> >> masks, discussion, and significant passage of time.
> >>
> >>> It is rather that I ask question to clarify what you are trying to
> >>> say as to get more useful and meaningful responses; but what I
> >>> receive in return is "pure and utter bullshit" on a "brick wall",
> >>> maybe someone else would say "no" here but if you take a closer
> >>> look this as well as the previous mail contains multiple questions
> >>> for you.
> >>>
> >>> These questions show interest in assuring quality here; it's
> >>> actually what makes up for a defensive style of discussion, making
> >>> sure that we keep our quality as opposed to applying the first
> >>> interesting solution that we come across. If you deem the QA
> >>> team's policy doesn't do that, and that it has a detriment in
> >>> quality; can you please let us know why?
> >>>
> >>
> >> Again, there is no policy that allows you to drop a stable package
> >> on an arch without a whole lot of things that I definitely never
> >> say happen. Honestly, if I even knew what you two were discussing
> >> in specific I'd likely be reverting the stupid drop instead of
> >> pointing out things in this thread which is wasting my time, and
> >> everyone else's.
> > 
> > Indeed, there isn't; where did I say there is?
> > 
> > Now that it has been said so on IRC, I see it can be misinterpreted.
> > 
> >>>> (even though it doesn't affect me!) because this page here says
> >>>> that it can't
> >>>> - we can change that definition if you'd like.  Instead of the
> >>>> line saying:
> >>>>
> >>>> The -* keyword is special. It is used to indicate package
> >>>> versions which are not worth trying to test on unlisted archs.
> >>>>
> >>>> Would changing it to read
> >>>>
> >>>> The -* keyword is special. It is used to indicate package
> >>>> versions which are not for use on unlisted archs.
> >>>>
> >>>> Would that make it acceptable? 
> >>>
> >>> Feel free to propose that to the QA team and / or the Gentoo
> >>> Council.
> >>
> >> No changes are required. Everyone with 2 brain cells knows that -*
> >> means "cannot work on other arches". Things like binary packages,
> >> etc.
> > 
> > And thus -* is not a solution to this thread.
> 
> Agreed. If "slow arch" is causing issues, it would seem simple enough
> to drop all the keywords except "slow arch" on the older ebuild. It
> reduces maintenance burden while not breaking anyway.  Amazing how
> the simple ones elude us sometimes.

+1

> >> Now, before you continue "discussing" this issue here on the list,
> >> perhaps you should turn around and talk to the QA team about what
> >> needs changed and discussed.
> > 
> > +1
> > 
> The goal of QA is to maintain the quality of the tree. Randomly
> removing packages that are blocking closing bugs doesn't contribute
> to tree quality, it degrades it.

This discussion isn't about removing packages; it is about removing
keywords or ebuilds, which doesn't break things if done properly.

It can just as well improve tree quality, as it can remove creeping
breakage; you can't black on white say whether it improves / degrades
the tree quality, as there is too much involved in that. To put it in
Jeroen's words "there's no simple policy for a complex problem" to some
extent applies here; and hence you have to deal with "simple problems"
as they appear, and then adapt policy (or the problem) to make a fit.

So, I'm not convinced that it degrades it; can you show commits that do?

Neither will you be convinced that it improves it yet; as the commits to
show you still have to be made, we can at least agree that we can't
determine together what really happens to the quality.

I'm however convinced it will make our stabilization efforts of higher
quality; as we move work from non-important to important business, in
upper management terms, to reach more effective and efficient results.

> I think we can all agree we are here to make gentoo better, so let's
> work together instead of against each other.

+1

> No one is going to remove a stable ebuild for an arch without
> discussion with the maintainer and following proper policy outlined
> here:
> https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html

The policy is that it is at the maintainer's discretion; furthermore, I
agree that workflow should be followed and not just a plain `rm ...` as
that would put people as a surprise (and doesn't invite arch mentees).

Consider this instead:

# This last stable version has been masked on your architecture because:
#
#     Solid reason, bugs #1, #2, #3, ...
#
# To continue to stabilize this package on your architecture, we
# currently run short in manpower to keep up with stabilizing it; if you
# want to help us out, you can contact us at [reference: staffing page]
# and read more about how arch testing works at [reference: arch
testing].

-- 
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