Re: OT: Roland Puntaier / "getmail6" drama

Roland Puntaier <[email protected]> wrote:
> On Tue 21Oct26 08:42, Charles Cazabon wrote:
> >
> > [...] Roland has continued to tell me he will send me "a patch" to
> > integrate his changes from "getmail6" into getmail, continuing to ignore
> > the detailed information I gave on how to send his changes as a series of
> > patches.
> 
> When I first wanted to make the Python 3 changes,
> I couldn't find the link to the repo with all the history.

As I have said on this list a number of times, and which I have explicitly
told you personally multiple times, I do not currently use a public repo or
forge for development of getmail.  The fact that you keep disingenuously
asking questions that imply you don't know this is perplexing; it suggests
you're trolling.  That's not helpful.

> Why don't you adopt a more open "open source development"?  It makes
> contributing easier.

This is absolutely open-source, or Free Software, development.  Perhaps it's a
different methodology that you're used to; that's fine, we each have our own
methods.

I have had contributions from dozens of getmail users over the years; not one
of them has ever had a problem collaborating in this fashion.  You are the
only one who claims this workflow makes it impossible to contribute:

> If you insist on your old-fashioned methodology, we cannot work together.

Dozens of contributors would disagree that a patch workflow makes it
impossible to work together.

Calling me or this workflow old-fashioned doesn't advance anything; it's just
ad hominem and raises tensions.  It's not helpful.  You could say "this is not
the way I am used to working", which would be fine.  Instead, you are saying
"the way you work is incorrect and you should change it", which is, again, not
helpful.

For what it's worth, this email & patch workflow has worked well in the Free
Software community for fifty years, and continues to be used today with no ill
effects.  The fact that public forge workflows also exist now is great; more
choices is good.  But we don't tell people "you're not allowed to walk to the
town centre anymore because buses now exist" is obnoxious.

> I could send you all the commits in getmail6 as patches in emails.

So, it's NOT impossible to work this way?  Good to hear.

However, you still have not acknowledged in any way how I have described
submission of large changes must occur.  I don't want one big patch, or one
patch for each commit you happened to make in your local repository.

The work needs to be reviewable, so that regressions and bugs can be spotted.
This means the work needs to be split into patches that:

    1) each are about fixing/changing one thing, i.e. they're divided into
    functional blocks in a series, not organized by whatever random order
    they were comitted.

    2) each makes the changes in the code base such that the result, the
    intermediate stage between patches, is a fully-functioning version.
    Each one builds on the changes introduced in the last one, if necessary.
    But if two patches which address unrelated X and Y functionality are
    sent and I think X needs changes, I should be able to apply Y without
    X, because the patches are separated by function.

    3) Each is at least minimally documented.  "This patch changes all the
    X because in Python 3 it has this side-effect that doesn't happen in
    Python 2", etc.

This is not some weird requirement that I have invented.  It is a
longstanding, widely-used development practice.  Insisting on patches/changes
being reviewable is the normal way to approach development; I would argue any
projects that do not insist on this are by far the exception, and probably
have unstable results.

The Linux kernel development process uses exactly this process.  Linus insists
on the above separate-patch methodology, and submissions to him are by email
for review/acceptance.

The Linux kernel repository is almost 30 million lines of code.  So please
don't tell me that this approach cannot work for getmail.  For one random
recent example of a patch series being submitted, see 
https://lkml.org/lkml/2021/4/14/1024 .

> That is not the modern way to do things.
> It involves manual steps that in the meantime are part of git.
> You can directly pull or cherry-pick.
> So I asked you to make a gitlab or github repo with all the history.
> I would then make a pull request with the commits of getmail6 on top of your
> HEAD.

Forcefully telling me that I am running my project inccorectly and how you
want me to run my project is off-putting.

The fact that (based on your apparent age in online profiles), I have been
distributing getmail as Free Software since you were in elementary school, is
pretty damn presumptuous.  And I have other Free Software projects I have been
distributing longer than that.

> Merging means also merging our way how to do things.
> If you insist on your old-fashioned methodology, we cannot work together.
> I'm quite sure the community also does not want to make a step backward in
> methodology.

You do not speak for "the community".  Neither do I.  But this process works,
as evidenced by the fact that it *has* worked for getmail for 23 years, and
for other projects for *fifty* years or more.  And it will continue to work.

Will getmail ever be in a public repository?  Probably, yes.  Today is not
that day.

> We can also not work together,
> if you are constantly offended about your great name or whatever.

getmail has built up a loyal userbase and excellent reputation, specifically
because of the quality standards I have demanded of myself in the getmail
codebase.  That all flows from my most important principle behind getmail:
email is crucial, and getmail should never, ever corrupt or lose your mail, or
fail to retrieve your mail when you need it to.

You have barged in, ignored my patient attempts to educate you on how to
collaborate, have forked a buggy version and released it using my project name
which makes users think getmail is a buggy mess, have shown no ability or
willingness to even be polite, much less to follow common practice such as
renaming your fork when I explicitly ask you to, and do nothing but tell me
how I run my project is wrong, and continue to demonstrate that you will
ignore my information that is *specifically designed to help you get your
changes integrated into getmail*.

I think I'm entitled to protect the "great name or whatever" of my project,
and I'm also entitled to be disappointed in you when you shit on it.

> Getmail is just a small wrapper around the Python email libraries.
> What's there so special about it?

Ad hominem again.  Not helpful.

If it's a "small wrapper" and "not special", I invite you to discard all of
getmail's code, and write your own project from scratch.  It's only a small
wrapper around the stdlib, after all - you should be able to bash that out in
an afternoon, surely?

> That is what open source is about: that you can change what you use.
> And you can also share your changes.

And as I have mentioned, when the upstream of your fork asks you to change the
name of your fork to eliminate confusion and unwarranted support burden, it is
absolutely common practice and *polite* practice to do that change.  Most
forks do it even without an explicit request from the upstream project, as I
posted examples of earlier.

Again, you completely ignore this.

When you want to collaborate, I'm here, even if you're still behaving the way
you are now.  I can hold my nose and accept correct patches even from people
that I find presumptuous, arrogant, cocky, smug, uncooperative,
uncollaborative, commanding, prescribing, and disrespectful of ownership,
pride, quality, and community.

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