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 C3FDB138247 for ; Fri, 17 Jan 2014 06:14:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 43D4FE0B89; Fri, 17 Jan 2014 06:14:13 +0000 (UTC) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 72F5FE0B84 for ; Fri, 17 Jan 2014 06:14:12 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id a1so4147917wgh.16 for ; Thu, 16 Jan 2014 22:14:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=OXgopat6ZWpold7I+ecFxEWy4p42U+yQquEty8kcmXs=; b=Hpf/L7xS0DCKwVMvsagLLZXm5y8HQ0PFs54uJ4A0A+rWsJM6uTQysoKbr43/jqanOe qeV79iPK83xF6G6Sph1ADhrMzFQTsBGVT9OlNbCR/fqe1y6pLn1ipF8XwiWXfDrPIbB8 N3ufY/+cdklXsPZVRNbBUm91XEAenOPgkDIW+YKRefAz3LueS75hYcCVVDc9mmv2+2P1 oED90aCT8e4oHnjkUobRcJzXKiatGCNdSo6G2LawMSHKwSZOopOtc5L2f/fc+3ynnJ1d tIPUFyNQw7ZutkpvP1ggYsJxCAT22wL0nIhgO3YgtUXVmtFKHyfm7wEo2e1SRFlYtSAk AOww== X-Gm-Message-State: ALoCoQlePfMgo+kp24a6RZRypz4f4AODq2DYNwmRselgWqQFGmWJmP78xyLq13fvm0uAR0hl/65A Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.194.76.231 with SMTP id n7mr155942wjw.16.1389939250801; Thu, 16 Jan 2014 22:14:10 -0800 (PST) Sender: antarus@scriptkitty.com Received: by 10.216.170.129 with HTTP; Thu, 16 Jan 2014 22:14:10 -0800 (PST) X-Originating-IP: [173.8.165.226] In-Reply-To: <20140117000221.46fbfa2e@TOMWIJ-GENTOO> References: <1389830840-25848-1-git-send-email-tomwij@gentoo.org> <1389830840-25848-2-git-send-email-tomwij@gentoo.org> <20140116221814.2fac526b@TOMWIJ-GENTOO> <52D84DDE.40201@plaimi.net> <20140116225213.18a132bc@TOMWIJ-GENTOO> <52D85BB4.5040109@plaimi.net> <20140117000221.46fbfa2e@TOMWIJ-GENTOO> Date: Thu, 16 Jan 2014 22:14:10 -0800 X-Google-Sender-Auth: BBkGLBegp1o1IgVhLJR_sBSHgfI Message-ID: Subject: Re: [gentoo-portage-dev] [PATCH 1/3] Have repoman check if the packages to unpack rare archive formats from SRC_URI are present in DEPEND (bug #205909). From: Alec Warner To: gentoo-portage-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary=047d7bf0d2dc4dc50f04f0247334 X-Archives-Salt: a9a6f9e1-3f66-42f9-9d61-4f046bb7f717 X-Archives-Hash: 119ed065f17f7703291bcf60631ddf14 --047d7bf0d2dc4dc50f04f0247334 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 16, 2014 at 3:02 PM, Tom Wijsman wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I want to summarize our IRC conversation on the list. > On Thu, 16 Jan 2014 23:22:44 +0100 > Alexander Berntsen wrote: > > > Your ill-placed attempts at being clever are missing the point. > > Why are they missing the point? > I think the point Alexander is trying to make here is also a point I tried to make on IRC. Many times large refactoring projects fail. I've tried to do them in Portage, and they have failed. I think folks are leery of this. We are often more comfortable with incremental changes. That means one change at a time; portage is a large ship and I don't think anyone is under the impression that portage will 'turn on a dime.' What I think we are trying to avoid, is changes that go in the opposite direction. > > > Portage is a mess. We don't need it to become more messy to the point > > of maintainability. > > How do we plan to fix that? Summarizing from our IRC conversation: Generally one of the first things you decide to do when you want to clean something up is to stop making new messes. I think that is the logic we are trying to convey here. Repoman has a giant unreadable loop that runs in module scope. All variables are global shared variables. Trampling on variables used by other functions is commonplace. So when we say 'add new code in a function', we say that because adding functions protects you from this mess. You get your own locals(). Using globals() triggers warnings. Shadowing variables triggers warnings. The function is callable (you could write a test, for instance.) These are all positive things. I realize they are not necessarily the 'refactoring' you want; however I think most people consider these as positive attributes of functions, which is why we are advocating for them. I am in no way claiming that 'putting code in functions' is somehow the best system, or the most maintainable system; merely that it is much better than what we have today. It also costs almost nothing to implement. As we discussed on IRC, even placing this code in a function in repoman itself offers most of these benefits. > > > Yes, no one fixing bugs (because they are all designing a grand > > redesign of Portage) would be bad. > > Do you agree? > Again, I think this is an appeal for incremental changes, and not huge hard-to-grasp changes. > > > However, this is not likely to happen. > > Why do you think so? > > > It hasn't happened before. > > It could happen in the future. > > > And now we have a bunch of great new volunteers. > > Yes, we do. > I'm not really following this part of the conversation. Speaking has someone who has tried the grand refactoring of portage; it has not worked well for me in the past. Incremental changes are easier to get accepted, they get released more often, they are tested faster, and so forth. > > > Sebastian even *told* you specifically how to do this properly. > > I think he was referring to the feedback that Sebestian gave on the thread > later on. I recommend you consider incorporating the feedback into your patch. > I think he was referring to the feedback that Sebastian gave you on the thread later on. > > So please do. > > Why? > Look, I realize Alexander (and probably myself) didn't have a great tone; but I thought Sebastian's feedback was pretty useful. Is there some reason you wouldn't want to incorporate it? -A > > - -- > 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 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQEcBAEBAgAGBQJS2GT9AAoJEJWyH81tNOV95ukH+wZ0yB4KOgfOd6z90cpYC0Ec > 4RLK8HbKVYIIytxnnhR5Ny/BR5/ANlOYQDIFUytkJyKNmVPx3nP6kY+wHD5qOYkF > 3DlJpxRy6wx/E43+wpvVv+dSNDHxkvyy8OeZ5QuAcFi1oYaeYdctfOU4/URihGzO > MjA5h0ydQ8CcHoTMkJsFjS7wL3HdSy1m1SRh9kiOuOr9hz4HqOImjJQ1/6Yb38uS > MVewW2oMEnEB99UANB5CswZHvvHcxU6d4hSmKlL1DfEuEq8hodM552n+WqpTgRhW > YzLmhUFqe0fkS9p4wAa5tPDB8O34P+nEvSAwtVqDFwqJmX0+H+r2INp7LJmDARo= > =FaJT > -----END PGP SIGNATURE----- > --047d7bf0d2dc4dc50f04f0247334 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 16, 2014 at 3:02 PM, Tom Wijsman <TomWij@gentoo.org>= wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I want to summarize our IRC= conversation on the list.=C2=A0

=C2=A0
On Thu, 16 Jan 2014 23:22:44 +0100
Alexander Berntsen <alexander@plaimi.net> wrote:

> Your ill-placed attempts at being clever are missing the point.

Why are they missing the point?

I= think the point Alexander is trying to make here is also a point I tried t= o make on IRC. Many times large refactoring projects fail. I've tried t= o do them in Portage, and they have failed. I think folks are leery of this= . We are often more comfortable with incremental changes. That means one ch= ange at a time; portage is a large ship and I don't think anyone is und= er the impression that portage will 'turn on a dime.'

What I think we are trying to avoid, is changes that go= in the opposite direction.
=C2=A0

> Portage is a mess. We don't need it to become more messy to the po= int
> of maintainability.

How do we plan to fix that?

Summarizi= ng from our IRC conversation:=C2=A0

Generally one = of the first things you decide to do when you want to clean something up is= to stop making new messes. I think that is the logic we are trying to conv= ey here. Repoman has a giant unreadable loop that runs in module scope. All= variables are global shared variables. Trampling on variables used by othe= r functions is commonplace. So when we say 'add new code in a function&= #39;, we say that because adding functions protects you from this mess.

You get your own locals(). Using globals() triggers war= nings. Shadowing variables triggers warnings. The function is callable (you= could write a test, for instance.) These are all positive things. I realiz= e they are not necessarily the 'refactoring' you want; however I th= ink most people consider these as positive attributes of functions, which i= s why we are advocating for them.

I am in no way claiming that 'putting code in funct= ions' is somehow the best system, or the most maintainable system; mere= ly that it is much better than what we have today. It also costs almost not= hing to implement. As we discussed on IRC, even placing this code in a func= tion in repoman itself offers most of these benefits.
=C2=A0

> Yes, no one fixing bugs (because they are all designing a grand
> redesign of Portage) would be bad.

Do you agree?

Again, I think this= is an appeal for incremental changes, and not huge hard-to-grasp changes.<= /div>
=C2=A0

> However, this is not likely to happen.

Why do you think so?

> It hasn't happened before.

It could happen in the future.

> And now we have a bunch of great new volunteers.

Yes, we do.

I'm not really fo= llowing this part of the conversation. Speaking has someone who has tried t= he grand refactoring of portage; it has not worked well for me in the past.= Incremental changes are easier to get accepted, they get released more oft= en, they are tested faster, and so forth.
=C2=A0

> Sebastian even *told* you specifically how to do this properly.

I think he was referring to the feedbac= k that Sebestian gave on the thread later on. I recommend you consider inco= rporating
the feedback into your patch.
=C2=A0<= /div>
I think he was referring to the feedback that Sebastian gave you on th= e thread later on.


> So please do.

Why?

Look, I realize Alexander (and pro= bably myself) didn't have a great tone; but I thought Sebastian's f= eedback was pretty useful. Is there some reason you wouldn't want to in= corporate it?

-A

- --
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address =C2=A0: TomWij@gentoo.org
GPG Public Key =C2=A0: 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 =C2=A0ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJS2GT9AAoJEJWyH81tNOV95ukH+wZ0yB4KOgfOd6z90cpYC0Ec
4RLK8HbKVYIIytxnnhR5Ny/BR5/ANlOYQDIFUytkJyKNmVPx3nP6kY+wHD5qOYkF
3DlJpxRy6wx/E43+wpvVv+dSNDHxkvyy8OeZ5QuAcFi1oYaeYdctfOU4/URihGzO
MjA5h0ydQ8CcHoTMkJsFjS7wL3HdSy1m1SRh9kiOuOr9hz4HqOImjJQ1/6Yb38uS
MVewW2oMEnEB99UANB5CswZHvvHcxU6d4hSmKlL1DfEuEq8hodM552n+WqpTgRhW
YzLmhUFqe0fkS9p4wAa5tPDB8O34P+nEvSAwtVqDFwqJmX0+H+r2INp7LJmDARo=3D
=3DFaJT
-----END PGP SIGNATURE-----

--047d7bf0d2dc4dc50f04f0247334--