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

[Alec Warner]

On Thu, Jan 16, 2014 at 3:02 PM, Tom Wijsman <TomWij@g.o> 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 <alexander@××××××.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
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@g.o
> 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-----
>