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 AAC641380DC for ; Thu, 6 Feb 2014 03:05:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E76C8E0BF7; Thu, 6 Feb 2014 03:04:58 +0000 (UTC) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 77473E0B59 for ; Thu, 6 Feb 2014 03:04:57 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id rd3so1136509pab.16 for ; Wed, 05 Feb 2014 19:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Q+yXeFbl+AoT0QqAmm3UhuMghYj86VfC8FuyglYblZY=; b=tHB2C9fcHzW6N3rTa9m8NVwgRza9sHK7frQpCYZJvoCnWWdfud9DGk7pp+4Yy4VX7i h70exlPfoCu+T3DBoQGq0/iUDx3ChEmZLUb0PQmkFRr15ooRCQU5ThFTsuxCBaOlTbzp kx8jRshJTFLjDDfsG0RlLiixFAsoxgVTYZrTqFrKf1Gpgs4fmQDQDpujYnCgg6s2vHKP jftqpXyIjJtnrk3cVZWdBlkma8Cqh7SC/mHeTrB2hbjD1yYTl5GIyKnZWkZuaIcasONM vAua66nNPTzQAE7nPo/rCAberxoddGV1GmiJjDMV2sXIN//SQIINAXuvukuylToXStPQ 3NNA== 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 X-Received: by 10.68.203.102 with SMTP id kp6mr8207032pbc.14.1391655896472; Wed, 05 Feb 2014 19:04:56 -0800 (PST) Received: by 10.68.185.2 with HTTP; Wed, 5 Feb 2014 19:04:56 -0800 (PST) Received: by 10.68.185.2 with HTTP; Wed, 5 Feb 2014 19:04:56 -0800 (PST) In-Reply-To: <20140206025135.64290406@TOMWIJ-GENTOO> References: <52E7DBC1.5020102@gentoo.org> <20140128182304.7d458a17@marga.jer-c2.orkz.net> <20140203062524.GA7467@rathaus.eclipse.co.uk> <20140203104341.2add2760@TOMWIJ-GENTOO> <20140204210319.GA1935@rathaus.eclipse.co.uk> <20140205010833.1bcf8dca@TOMWIJ-GENTOO> <1391559808.3520.2.camel@oswin.hackershack.net> <20140205020742.048cef9f@TOMWIJ-GENTOO> <1391564122.3520.4.camel@oswin.hackershack.net> <20140205024806.7d08cb63@TOMWIJ-GENTOO> <1391570147.3520.7.camel@oswin.hackershack.net> <20140205055544.6c3affea@TOMWIJ-GENTOO> <1391616442.3160.6.camel@oswin.hackershack.net> <20140205224815.70832b2d@TOMWIJ-GENTOO> <52F2B594.5050500@gentoo.org> <20140206014838.054be1ab@TOMWIJ-GENTOO> <52F2DEB9.2000901@gentoo.org> <20140206025135.64290406@TOMWIJ-GENTOO> Date: Wed, 5 Feb 2014 19:04:56 -0800 Message-ID: Subject: Re: [gentoo-dev] Re: Re: dropping redundant stable keywords From: Tyler Pohl To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary=047d7b10cf675bdfd004f1b42336 X-Archives-Salt: db1271d3-03d6-4982-b2e5-83fac4cdb658 X-Archives-Hash: 8fe0d80266341dba4b336cc0c70434d5 --047d7b10cf675bdfd004f1b42336 Content-Type: text/plain; charset=ISO-8859-1 why cant there be a second repository for all old source, ebuilds, and patches and the stable and testing repository can be rolling like it already is. slower archs can then sync the old repository and the new one. On Feb 5, 2014 5:54 PM, "Tom Wijsman" wrote: > On Wed, 05 Feb 2014 20:00:41 -0500 > "Rick \"Zero_Chaos\" Farina" 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 > > --047d7b10cf675bdfd004f1b42336 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

why cant there be a second repository for all old source, ebuilds, and p= atches and the stable and testing repository can be rolling like it already= is.=A0 slower archs can then sync the old repository and the new one.

On Feb 5, 2014 5:54 PM, "Tom Wijsman" = <TomWij@gentoo.org> wrote:
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=3D500014

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 l= onger 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. =A0This 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<= br> > >> against policy.
> >
> > The QA policy meant to override this; to avoid confusion, I mean<= br> > > including the proper workflow involved in this. But this has rais= ed
> > concerns on IRC today, as it was made clear what the reasons are<= br> > > that I was asking for; it's good that we do a new vote on thi= s to
> > properly reflect what we really intend, rather than some poor
> > voting that went through a quick vote and didn't take everyth= ing in
> > consideration.
> >
> Nothing in the QA policy says "ignore standard removal policy&quo= t;. =A0Here
> is the standard removal policy, and I expect it to be followed:
>
> https://devmanual.gentoo.org/ebuild-writi= ng/ebuild-maintenance/index.html

We do however "revisit" it (subject of original thread); the work= flow
(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&qu= ot; he
> doesn't mean "steal a faster car, speed as much as possible, = and don't
> stop at red lights". =A0Doing so would obviously be dangerous, an= d 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. =A0YOURS. YOUR actions= and responses in
> >>>> this thread. =A0And the fact that the QA team allows = you to
> >>>> continue to be on it, despite your obvious lack of in= terest in
> >>>> ACTUALLY having quality assurance. My actions are aff= ected by it
> >>>> because I have to continue to attempt to discuss the = issue with
> >>>> others who actually give a shit, and you just swoop i= n 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. T= his 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 otherwis= e?
> >
> >> You are speaking for yourself here and no one else.
> >
> > I'm quoting QA team policy, agreed on by at least 8 individua= ls;
> > that policy can be read at the following URL:
> >
> > https://wiki.gentoo.org/wiki/Project:Quality_A= ssurance/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-writi= ng/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 myse= lf?
>
> As I am also a member of the QA team, clearly there isn't a consen= sus
> 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 w= ithout
> >> 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 w= hat I
> >>> receive in return is "pure and utter bullshit" = on a "brick wall",
> >>> maybe someone else would say "no" here but if y= ou take a closer
> >>> look this as well as the previous mail contains multiple = questions
> >>> for you.
> >>>
> >>> These questions show interest in assuring quality here; i= t's
> >>> actually what makes up for a defensive style of discussio= n, 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 pa= ckage
> >> on an arch without a whole lot of things that I definitely ne= ver
> >> say happen. Honestly, if I even knew what you two were discus= sing
> >> in specific I'd likely be reverting the stupid drop inste= ad 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 misinterpret= ed.
> >
> >>>> (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. = =A0Instead of the
> >>>> line saying:
> >>>>
> >>>> The -* keyword is special. It is used to indicate pac= kage
> >>>> versions which are not worth trying to test on unlist= ed archs.
> >>>>
> >>>> Would changing it to read
> >>>>
> >>>> The -* keyword is special. It is used to indicate pac= kage
> >>>> 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 Gen= too
> >>> Council.
> >>
> >> No changes are required. Everyone with 2 brain cells knows th= at -*
> >> means "cannot work on other arches". Things like bi= nary packages,
> >> etc.
> >
> > And thus -* is not a solution to this thread.
>
> Agreed. If "slow arch" is causing issues, it would seem simp= le enough
> to drop all the keywords except "slow arch" on the older ebu= ild. It
> reduces maintenance burden while not breaking anyway. =A0Amazing how > the simple ones elude us sometimes.

+1

> >> Now, before you continue "discussing" this issue he= re 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 contribut= e
> 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&= quot;
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<= br> 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-writi= ng/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).<= br>
Consider this instead:

# This last stable version has been masked on your architecture because: #
# =A0 =A0 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 =A0: TomWij@gentoo.org<= /a>
GPG Public Key =A0: 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 =A0ABF0 95B2 1FCD 6D34 E57D

--047d7b10cf675bdfd004f1b42336--