public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Tom Wijsman <TomWij@gentoo.org>
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).
Date: Sat, 18 Jan 2014 00:35:07 +0100	[thread overview]
Message-ID: <20140118003507.4169f9a6@TOMWIJ-GENTOO> (raw)
In-Reply-To: <CAAr7Pr-oRY6XmZ4ip6zrgiV7UFKKk+OWpsGuM9DV007TkzPNoA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3801 bytes --]

On Thu, 16 Jan 2014 22:14:10 -0800
Alec Warner <antarus@gentoo.org> 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
> 
> 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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  reply	other threads:[~2014-01-17 23:36 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-16  0:07 [gentoo-portage-dev] Repoman patches for bugs #205909, #245305 and #482084 Tom Wijsman
2014-01-16  0:07 ` [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) Tom Wijsman
2014-01-16  1:44   ` Alec Warner
2014-01-16 21:18     ` Tom Wijsman
2014-01-16 21:23       ` Alexander Berntsen
2014-01-16 21:52         ` Tom Wijsman
2014-01-16 22:22           ` Alexander Berntsen
2014-01-16 23:02             ` Tom Wijsman
2014-01-17  6:14               ` Alec Warner
2014-01-17 23:35                 ` Tom Wijsman [this message]
2014-01-17  0:33     ` Tom Wijsman
2014-01-16  7:03   ` Sebastian Luther
2014-01-16 21:40     ` Tom Wijsman
2014-01-17  8:35       ` Sebastian Luther
2014-01-17 23:00         ` Tom Wijsman
2014-01-18  6:49           ` Sebastian Luther
2014-01-17  8:28   ` Sebastian Luther
2014-01-17 16:40     ` Tom Wijsman
2014-01-17 23:03   ` [gentoo-portage-dev] [PATCH 1/3 v2] " Tom Wijsman
2014-01-19  9:38     ` Mike Frysinger
2014-01-20  2:23       ` Tom Wijsman
2014-01-20  2:43         ` Alec Warner
2014-01-21 15:32           ` Tom Wijsman
2014-01-16  0:07 ` [gentoo-portage-dev] [PATCH 2/3] Have repoman check that a package directory contains at least one ebuild (bug #245305) Tom Wijsman
2014-01-16  1:07   ` Jesus Rivero (Neurogeek)
2014-01-16  1:45     ` Alec Warner
2014-01-17 21:36   ` [gentoo-portage-dev] [PATCH 2/3 v2] " Tom Wijsman
2014-01-17 22:34     ` Jesus Rivero (Neurogeek)
2014-01-16  0:07 ` [gentoo-portage-dev] [PATCH 3/3] Have repoman deprecate G2CONF for the GNOME team. (bug #482084) Tom Wijsman
2014-01-16  1:23   ` Jesus Rivero (Neurogeek)
2014-01-16 21:56     ` Tom Wijsman
2014-01-19  9:26   ` Mike Frysinger
2014-01-19  9:28   ` Mike Frysinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140118003507.4169f9a6@TOMWIJ-GENTOO \
    --to=tomwij@gentoo.org \
    --cc=antarus@gentoo.org \
    --cc=gentoo-portage-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox