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 C0AAD138247 for ; Fri, 17 Jan 2014 23:36:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0E7A1E0A70; Fri, 17 Jan 2014 23:36:08 +0000 (UTC) Received: from michel.telenet-ops.be (michel.telenet-ops.be [195.130.137.88]) by pigeon.gentoo.org (Postfix) with ESMTP id 3DA76E0A4F for ; Fri, 17 Jan 2014 23:36:07 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by michel.telenet-ops.be with bizsmtp id FBc61n0042khLEN06Bc6XE; Sat, 18 Jan 2014 00:36:06 +0100 Date: Sat, 18 Jan 2014 00:35:07 +0100 From: Tom Wijsman To: antarus@gentoo.org Cc: gentoo-portage-dev@lists.gentoo.org 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). Message-ID: <20140118003507.4169f9a6@TOMWIJ-GENTOO> In-Reply-To: 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> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.22; x86_64-pc-linux-gnu) 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 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/jKAjhdHXhNear5O=x0_ZFpp"; protocol="application/pgp-signature" X-Archives-Salt: 9d650b86-2eae-448e-a1ac-cf524510de8d X-Archives-Hash: 65c048c372ce6071eea7a5f8fcfb8316 --Sig_/jKAjhdHXhNear5O=x0_ZFpp Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 16 Jan 2014 22:14:10 -0800 Alec Warner wrote: > 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. Repoman's code base is of small enough size for it to succeed for sure. > I've tried to do them in Portage, and they have failed. Portage is indeed quite a bit bigger, that's why I might look at that from a software re-engineering perspective with the necessary practices that are done in that particular field to deal with legacy code. But, in one of the bugs I indeed have seen such a smaller attempt; if we want to see Portage itself refactored, it will require agreement and cooperation. Otherwise the refactoring commits would never be accepted. Definitely we will want to look into reproducible and incremental operations; so, we shouldn't so much send-email a huge diff, but rather send scripted commands for review that are easier to understand. Eg. move function1 to file1 rename functin2 to function3 ... Of course not everything can be written down that way; but the big stuff can, and that's exactly the stuff which in the diff form would be much harder to accept. > I think folks are leery of this. Yes, the more manual work of refactoring can break things; good coverage testing can help keep this minimal, I see Portage has quite some tests which is a good thing but I'm not sure how well they cover Portage. > We are often more comfortable with incremental changes. That means > one change at a time; portage is large ship and I don't think anyone > is under the impression that portage will 'turn on a dime.' The only thing I like to see here is that these small incremental changes work towards a good design; there's a difference between doing it just because you can and doing it on purpose. > What I think we are trying to avoid, is changes that go in the > opposite direction. "Yes, we will not sail there; but where do we go to instead?" > 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. Your first comment was clear to me, I didn't object to putting it in a function. But anything more than that needs a proper discussion, as just creating a random file and putting it in there is a mess as well. :) (My response was based on that I _want_ to refactor it, hence the care) > 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. What caused trouble doing this? > Incremental changes are easier to get accepted, they get released > more often, they are tested faster, and so forth. A refactor attempt can be planned to be done in incremental steps. > > > 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 >=20 > the feedback into your patch. > > I think he was referring to the feedback that Sebastian gave you on > the thread later on. The feedback has no mention of what is referred to as far as I can see. > 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? It is incorporated in v2 of the patch. --=20 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 --Sig_/jKAjhdHXhNear5O=x0_ZFpp Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJS2b4rAAoJEJWyH81tNOV9djUIAMT3exG6ukwpbme9+SphVYr0 STbUZ9pAiuNnxmIl9ZwhsQTseqDXTKma+rXns7WUtMQweFRakzAk+uCYLC8xq2zo NS0e6puFrOovaUMop4Fyic+2LLT9+WDISN7qOUFE7IOcFA8ren6Tfzsowy44RMP7 lPeBpqRxHwNU6eqZB7uHvybZILwt3qUxezZCWQvGR8lSBQIIi6IU5rfSEMXJ9Qaq i+94qmFPlRJV0j4DRO4jNfNp3wZpLU/WN7gdyT6pWJdyo35Dg+xiYxIcreejxpFF Fn6ZumFPqZcwZgzSSf3ex7+6q2cdbBM4V06qJL8SihoZyWOg6/9bxoVmFnX6SdI= =rhFP -----END PGP SIGNATURE----- --Sig_/jKAjhdHXhNear5O=x0_ZFpp--