[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog

[Markos Chandras]

On 1 March 2013 08:16, Mike Frysinger (vapier) <vap...@gentoo.org> wrote:
> vapier 13/03/01 08:16:02
>
> Modified: confuse-2.7.ebuild ChangeLog
> Log:
> Add arm lovin.
>
> (Portage version: 2.2.0_alpha163/cvs/Linux x86_64, signed Manifest commit with key FB7C4156)
>
> Revision Changes Path
> 1.13 dev-libs/confuse/confuse-2.7.ebuild
>
> file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-libs/confuse/confuse-2.7.ebuild?rev=1.13&view=markup
> plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-libs/confuse/confuse-2.7.ebuild?rev=1.13&content-type=text/plain
> diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-libs/confuse/confuse-2.7.ebuild?r1=1.12&r2=1.13
>
> Index: confuse-2.7.ebuild
> ===================================================================
> RCS file: /var/cvsroot/gentoo-x86/dev-libs/confuse/confuse-2.7.ebuild,v
> retrieving revision 1.12
> retrieving revision 1.13
> diff -u -r1.12 -r1.13
> --- confuse-2.7.ebuild 30 Oct 2012 11:18:49 -0000 1.12
> +++ confuse-2.7.ebuild 1 Mar 2013 08:16:02 -0000 1.13
> @@ -1,6 +1,6 @@
> -# Copyright 1999-2012 Gentoo Foundation
> +# Copyright 1999-2013 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> -# $Header: /var/cvsroot/gentoo-x86/dev-libs/confuse/confuse-2.7.ebuild,v 1.12 2012/10/30 11:18:49 blueness Exp $
> +# $Header: /var/cvsroot/gentoo-x86/dev-libs/confuse/confuse-2.7.ebuild,v 1.13 2013/03/01 08:16:02 vapier Exp $
>
> EAPI=3
>
> @@ -10,7 +10,7 @@
>
> LICENSE="ISC"
> SLOT="0"
> -KEYWORDS="alpha amd64 hppa ia64 ~mips ppc ppc64 sparc x86 ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~x86-solaris"
> +KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 sparc x86 ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~x86-solaris"
> IUSE="nls static-libs"
>
> DEPEND="sys-devel/flex
>

straight to stable? Not even keeping it to testing just for a week or so?

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

[Mike Frysinger]

On Friday 01 March 2013 07:45:28 Markos Chandras wrote:
> On 1 March 2013 08:16, Mike Frysinger (vapier) <vap...@gentoo.org> wrote:
> > vapier 13/03/01 08:16:02
> >
> > Modified: confuse-2.7.ebuild ChangeLog
> > Log:
> > Add arm lovin.
> >

> > --- confuse-2.7.ebuild 30 Oct 2012 11:18:49 -0000 1.12
> > +++ confuse-2.7.ebuild 1 Mar 2013 08:16:02 -0000 1.13
> >

> > -KEYWORDS="alpha amd64 hppa ia64 ~mips ppc ppc64 sparc x86 ~sparc-fbsd
> > ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos
> > ~x86-solaris" +KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 sparc
> > x86 ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux
> > ~ppc-macos ~x86-macos ~x86-solaris"
>

> straight to stable? Not even keeping it to testing just for a week or so?

looks that way
-mike

[Mike Frysinger]

On Saturday 02 March 2013 20:50:17 Markos Chandras wrote:

> On Mar 3, 2013 1:43 AM, "Mike Frysinger" <vap...@gentoo.org> wrote:
> > On Friday 01 March 2013 07:45:28 Markos Chandras wrote:

> > > On 1 March 2013 08:16, Mike Frysinger wrote:
> > > > vapier 13/03/01 08:16:02
> > > >
> > > > Modified: confuse-2.7.ebuild ChangeLog
> > > > Log:
> > > > Add arm lovin.
> > > >
> > > > --- confuse-2.7.ebuild 30 Oct 2012 11:18:49 -0000 1.12
> > > > +++ confuse-2.7.ebuild 1 Mar 2013 08:16:02 -0000 1.13
> > > >
> > > > -KEYWORDS="alpha amd64 hppa ia64 ~mips ppc ppc64 sparc x86
> > > > ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux
> > > > ~ppc-macos ~x86-macos ~x86-solaris" +KEYWORDS="alpha amd64 arm hppa
> > > > ia64 ~mips ppc ppc64 sparc
> > > > x86 ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux
> > > > ~ppc-macos ~x86-macos ~x86-solaris"
> > >
> > > straight to stable? Not even keeping it to testing just for a week or
> > so?
> >
> > looks that way
>

> Ok good to know you break the rules on purpose

complain to me when all these arm systems that totally had confuse already
installed go down in fire. it literally makes 0 difference here.
-mike

[Markos Chandras]

On Mar 3, 2013 1:43 AM, "Mike Frysinger" <vap...@gentoo.org> wrote:
>

Ok good to know you break the rules on purpose

[Markos Chandras]

Why would they have it installed (in stable) if it had no keywords? and if it is such an important package why it didn't have testing keywords in the first place? I did't say it broke something, it just feels strange and this is why I asked

[Mike Frysinger]

On Saturday 02 March 2013 21:01:39 Markos Chandras wrote:
> On Mar 3, 2013 1:55 AM, "Mike Frysinger" <vap...@gentoo.org> wrote:
> > complain to me when all these arm systems that totally had confuse
> > already installed go down in fire. it literally makes 0 difference
> > here.
>

> Why would they have it installed (in stable) if it had no keywords? and if
> it is such an important package why it didn't have testing keywords in the
> first place? I did't say it broke something, it just feels strange and this
> is why I asked

sounds like there's no further clarification necessary
-mike

[Peter Stuge]

Markos Chandras wrote:
> it just feels strange

I hear they call it "getting stuff done"..


//Peter

[Markos Chandras]

good thing you are not a dev then.
Thanks for the heads up in case you ever want to become one

[Tomáš Chvátal]

If I remember correctly the damn rule is to put it for 30 days into testing, and as you said there was no previous version on arm so users could've reported some issues, i agree that sometimes you have to ignore the rules to really fix stable, but was this such case for sure?

Dne 3.3.2013 3:43 "Mike Frysinger" <vap...@gentoo.org> napsal(a):

[Peter Stuge]

Markos Chandras wrote:
> > > it just feels strange
> >
> > I hear they call it "getting stuff done"..
>

> good thing you are not a dev then.
> Thanks for the heads up in case you ever want to become one

I explain to you what happened and you, a recruiter, proceed to
threaten me in case I want to become a developer.

And people wonder if anything is wrong with Gentoo recruitment..


Back on topic: It seems that you must immediately retire Mike.

(Or the rule..)


//Peter

[Markos Chandras]

On 3 March 2013 12:01, Peter Stuge <pe...@stuge.se> wrote:
> Markos Chandras wrote:
>> > > it just feels strange
>> >
>> > I hear they call it "getting stuff done"..
>>
>> good thing you are not a dev then.
>> Thanks for the heads up in case you ever want to become one
>
> I explain to you what happened

"getting stuff done" is not an answer. I still don't understand why
stable keywords had to be added directly. Do you understand why Mike
did that
or just playing smart here? Instead of you giving me cryptic and
"smart" answers, you could have explained to me why it was necessary
and job done.

> and you, a recruiter, proceed to threaten me in case I want to become a developer.
>
> And people wonder if anything is wrong with Gentoo recruitment..
>

If you can't play by the rules, either try to change them or go away
or at least try to explain why you break them.

[Peter Stuge]

Markos Chandras wrote:
> > I explain to you what happened
>
> "getting stuff done" is not an answer. I still don't understand why
> stable keywords had to be added directly. Do you understand why Mike
> did that or just playing smart here?

To me it's obvious that he did it because it made something easier
for him. By breaking the Gentoo rule he got something done.

> Instead of you giving me cryptic and "smart" answers, you could
> have explained to me why it was necessary and job done.

I have no idea what exactly became easier for him, and what it is may
be none of our business.

> > and you, a recruiter, proceed to threaten me in case I want to become a developer.
> >
> > And people wonder if anything is wrong with Gentoo recruitment..
>
> If you can't play by the rules, either try to change them or go away
> or at least try to explain why you break them.

Again, I guess you have to make Mike go away now.


On rules:

It's very easy to create bad rules while having the best intentions.
"The road to hell is paved with good intentions."

It takes immense effort to change such rules, and an establishment
which has grown fond of them. It sadly seems much easier to maintain
a whole separate portage tree than to fix broken rules. :\

That said, I don't know what route I'll choose if I ever have to.


//Peter

[Rich Freeman]

On Sun, Mar 3, 2013 at 7:38 AM, Peter Stuge <pe...@stuge.se> wrote:
>
> To me it's obvious that he did it because it made something easier
> for him. By breaking the Gentoo rule he got something done.

Rules exist for a reason. If we're bending them because we're
accomplishing the goal of the rules in a better way that makes sense.
If we're just breaking them because following them is inconvenient
then we're causing harm.

The purpose of the 30-day rule is so that stable is, well, stable.
Stable doesn't mean "I think this should work." Stable means that it
has been tested and found to work - a time delay is almost essential
to the definition of "stability."

There is room for an exception if there is some serious problem in
stable and the risk of causing harm is low compared to the pain
already being felt. Security bugs usually involve breaking the 30-day
rule, for example. In these cases the spirit of the rule is contrary
to the letter of the rule, and we rightly violate the letter as a
result.

There is no harm in pointing out that a rule was broken. If there is
a good reason it will be produced and everybody will nod, and if not,
well, then hopefully there will be an apology and we'll just move on.
Neither blacklisting nor banishment are the right first response to a
minor offense, but devs have been booted for consistently violating
rules like the 30 day rule, and I would expect mentors and recruiters
to ensure that new recruits understand and intend to follow this rule.
Anybody who runs a stable system is better off for it.

Countless threads on -dev (mail or irc) amount to "I'd like to violate
this rule for a good reason." There is some debate, and we either do
it or not. Rules aren't intended to prevent progress, but quality is
important and if a rule is standing in your way there might be some
side of the problem that you're not seeing. It never hurts to ask
before breaking a rule.

Rich

[Markos Chandras]

On 3 March 2013 12:38, Peter Stuge <pe...@stuge.se> wrote:
> Markos Chandras wrote:
>> > I explain to you what happened
>>
>> "getting stuff done" is not an answer. I still don't understand why
>> stable keywords had to be added directly. Do you understand why Mike
>> did that or just playing smart here?
>
> To me it's obvious that he did it because it made something easier
> for him. By breaking the Gentoo rule he got something done.

I asked why he did it, and you keep telling me because he had to. When
you are in place
to give me a more detailed answer please do so otherwise I am asking
you to stop making noise
on the list.

>
>
>> Instead of you giving me cryptic and "smart" answers, you could
>> have explained to me why it was necessary and job done.
>
> I have no idea what exactly became easier for him, and what it is may
> be none of our business.

Maybe it is not your business, but I am reviewing commits from time to
time because:

a) I often see useful tricks in ebuild writing so it is a good
learning procedure and
b) because some people may did a bad commit so I would like to be
there and point them at it

In this case, I would like to know the reasoning behind that commit.
I am not the "Gentoo police", just trying to understand the commits that
don't make sense to me. It this *that* hard for you to understand it?

>
> Again, I guess you have to make Mike go away now.
>

I never said that so please just stop it.

[Peter Stuge]

Markos Chandras wrote:
> >> "getting stuff done" is not an answer.
> >

> > it made something easier for him
>

> I asked why he did it, and you keep telling me because he had to.

I'm guessing that it didn't have much to do with Gentoo. Maybe he'll
fill in.

> I am reviewing commits from time to time because:
>

> b) people may did a bad commit so I would like to be there and point them

>
> I am not the "Gentoo police"

That looks really confusing. I think you are contradicting yourself.
But I guess never mind.

> > Again, I guess you have to make Mike go away now.
>
> I never said that so please just stop it.

You threatened to preempt me if I wanted to become a developer and
found his practise OK - meaning that the behavior is unacceptable.
If you are to be the least consistent you really need to also
threaten to remove him. (It would be pretty ridiculously hipocratic
and of course harmful for project evolution if the rules apply only
to aspiring devs.)

But I'd obviously prefer if you didn't do that to him.


//Peter

[Andreas K. Huettel]

Am Montag, 4. März 2013, 03:19:17 schrieb Peter Stuge:
>
> > > Again, I guess you have to make Mike go away now.
> >
> > I never said that so please just stop it.
>
> You threatened to preempt me if I wanted to become a developer and
> found his practise OK - meaning that the behavior is unacceptable.
> If you are to be the least consistent you really need to also
> threaten to remove him. (It would be pretty ridiculously hipocratic
> and of course harmful for project evolution if the rules apply only
> to aspiring devs.)
>
> But I'd obviously prefer if you didn't do that to him.
>

Seriously. While I'm all for sticking to the rules, I'm also sometimes glad
that Gentoo is not as bad as proverbial German bureaucracy.

The fact is, people who have been around for a long time, do a lot of
important work and are trusted by the dev community may be able to bend the
rules *for good reason*. [I personally would prefer if that would occur less
frequently though.]

This discussion is about whether it was really necessary (the "for good
reason" part) or could have been done in other ways.

Starting as a developer or aspiring to become one with that attitude is not
acceptable. No discussion of that needed.

--
Andreas K. Huettel
Gentoo Linux developer
dilf...@gentoo.org
http://www.akhuettel.de/

[Peter Stuge]

Andreas K. Huettel wrote:
> Starting as a developer or aspiring to become one with that
> attitude is not acceptable.

That doesn't make sense to me.

If the reason is good, surely it does not matter who is doing the breaking?


//Peter

[Alec Warner]

Well there is an implication that new developers are not experienced
and are more prone to making choices with faulty reasoning. This is
obviously not true of all new developers, but likely remains a good
heuristic.

-A

>
>
> //Peter

[Jeroen Roovers]

On Sun, 3 Mar 2013 12:44:18 +0100
Tomáš Chvátal <tomas....@gmail.com> wrote:

> If I remember correctly the damn rule is to put it for 30 days into
> testing, and as you said there was no previous version on arm so users
> could've reported some issues, i agree that sometimes you have to
> ignore the rules to really fix stable, but was this such case for
> sure?

I've done straight to stable keywording _many_ times. The rationale is
that with no previous version stable for a particular architecture,
there really are no users who could see _regressions_, hence waiting
the nominal thirty days is meaningless in this case.


jer

[hasufell]

another note:
I was told a while back (I might still have it in irc logs), that 30
days is NOT a rule. It's common sense, but in the end the maintainer
decides when to request stabilization, no one else.

Blame people if they break something, not if they ignore soft policies.

[Michael Orlitzky]

What's broken is the expectation that the package was tested by more
than one person. The "soft policy" is here:

http://devmanual.gentoo.org/keywording/index.html#moving-from-~arch-to-arch

And you're right, ~30 days is simply a suggestion. But the rule is "The
package has spent a reasonable amount of time in ~arch first." A further
non-suggestion is "The package must be widely tested."

If a package is marked stable, I expect it to have seen some testing,
and not just on the maintainers personal machine. I don't rely 100% on
the stable designation, but it does affect the amount of testing that I
personally will do. Please help me do my job by not perverting the
meaning of stable.

[Duncan]

hasufell posted on Sun, 10 Mar 2013 19:11:52 +0100 as excerpted:

> I was told a while back (I might still have it in irc logs), that 30
> days is NOT a rule. It's common sense, but in the end the maintainer
> decides when to request stabilization, no one else.

I can confirm the 30-day-guideline policy was just that, a maintainer-
discretion guideline, back in 2005/2006 or so when I first became aware
of the concept via discussion. It was explained as maintainer knows
their packages best, with the caveat that arch-teams also knew their archs
best and could choose not to stabilize right away if they decided the
request wasn't appropriate for their arch.

I've seen no council, etc. decision changing that, over the years.

Sometime a bit thereafter, various understaffed archs began to yield
stabilizing authority to non-arch-team maintainers on a package-by-
package basis, generally with at least the requirement that said
maintainer actually had access to and had tested on that arch. AFAIK,
before that maintainers weren't to stabilize at all on archs they weren't
team members of, but they could still do so if they were a member of the
arch-team, provided of course that they were following arch-team policy
in the process.

Meanwhile, jer's explanation, that on an arch where the package was not
previously stable, there could be no stable users of the app to see
regressions, so straight to stable makes a bit more sense, makes perfect
sense to me. =:^)

If I'm arguably too verbose, vapier's arguably not verbose enough. Had
he just said something like either of these instead of simply punting
with his replies... I guess it would have stopped there.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

[Samuli Suominen]

agreed, this is how I work too