Re: getmail failing for messages with invalid uncode

Michael Grant <[email protected]> wrote:
> 
> It seems to me that ultimately getting getmail to work in python3

I have never contested this would be a good thing.

> It seems like Roland and Remco have done something that works except
> for the bug that I ran into which he says is fixed.

Oh, you have no idea.  I have had a long stream of reports to me directly (and
others to this mailing list) which I spent time investigating, only to later
figure out that the reporter was using "getmail6" and not getmail.  Some of
them didn't even know they had "getmail6"!  They upgraded Debian versions and
getmail was removed and "getmail6" installed without any notice...

> I mean, I did not even realize I was using their version until the other
> day!

... like you.

> Just a quick look at the directory struture of both, they look very
> similar.  It does not look like they re-architected getmail.

I don't know if there is a "they".  Roland appears to have run getmail through
the 2to3 converter and then started hacking in fixes until it ran.  Some of
his changes have worked, some have introduced bugs, and others are bugs that
no one has reported yet because they're in lesser-used features.

> line but in Python 3.  There's some chunks of code that differe but
> these may be just the different base versions.  My initial assessment
> here is with some cooperation, maybe things could be merged quite
> quickly.

You don't know what you're talking about; this isn't your codebase.  It's
mine, and the state of "getmail6" is in no way ready for integration into
getmail.  I have given specific, detailed instructions on how it could be
integrated; that hasn't happened yet.

> I know Charles, you want to refactor it and clean it up when you move
> to python 3 and that's great.

It's my choice.

> How terrible would it be if you and Roland took the intermediate step to
> work together fully get to Python 3 for now

In my judgement?  That reduces to "take getmail6 as is now" and that is an
awful idea.  It will cause me, and getmail users, untold pain.  And my
judgement is the one that matters in this case.

> Charles says the patch huge and buggy.

It is huge and buggy, but the point is, it is *completely unreviewable*.

This is exactly like when someone rips out the Linux kernel scheduler or
memory manager and replaces it wholesale, then sends in one huge patch that
touches almost every file in the damned tree.

Linus correctly says, "This can't be reviewed, go away and do it right so we
can review it if you want it merged".

I'm saying the same thing.

> Maybe there is something that can be done to look over it and see if the
> logic

I have no idea if you're a programmer/software engineer, or if you maintain
any popular free software packages, or what.  However...

You keep proposing things which put work on *my* plate but which bring no
benefits to me.

I'll turn it around: if you want to fork getmail, or work with Roland on his
fork, and then send me nice, clean, self-contained, single-feature,
compatible, high-quality documented patches for inclusion into getmail which
gradually migrate it to a codebase that is Python-2.7 and Python-3 compatible,
then I will be happy to review them and integrate them.

> Can the patch be split

How many times have I got to say the same damned thing?  I have said exactly
that is the way forward.

> for Roland to take in the changes from 5.15 and get the code to be as
> close as possible to it to make it easier to look at side by side.

That has *nothing* to do with the process I've described.  Anyone can do that:

    diff --side-by-side getmail/ "getmail6"/

... but the result of that is NOT USEFUL TO THE MAINTAINER.  That's
effectively what he sent me.

> From all this banter between you, it sounds like Charles is willing to
> consider the patch if it were easier for him to integrate and it

I never said differently!

Roland, please change the name of your project.  getmail is my trademark, and
you are polluting it.  You are free to fork getmail and call it SOMETHING
ELSE.

> It seems to me that Roland and Remco were trying to do you a favor

Not even close.  Zero input from me; it was presented to me as a fait accompli
and he/they have ignored me since.

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at:               http://pyropus.ca/software/
-----------------------------------------------------------------------