Bug#996569: getmail6 naming issues
Sudip Mukherjee wrote: > > iiuc, getmail6 is not a "hostile fork". It is; I could explain it, but I already have. Quoting from the getmail documentation: Why do I say it's a "hostile" fork? Because I have communicated with the maintainer and indicated I would be thrilled to accept their changes bringing Python 3 compatibility, as long as they were in reviewable condition, so that I could be sure I wasn't introducing bugs into getmail when I merged their changes. [...] That maintainer has shown precisely zero interest in submitting his changes for me to merge into getmail; he literally ignores every question/request I have made on the subject. > getmail6 is a Python3 based fork which all the distros had to package > because you have declined to support Python3. Please do not put words into my mouth. I have never - not one single time - said anything to suggest I would, will, or do refuse to support Python 3. In fact, I have said exactly the opposite countless times. In case there is any doubt: there will be a Python 3 version of getmail. > Roland has offered to send you ( I think already sent you) patches. That would be another misunderstanding, then. He has never sent me any patch, much less anything reviewable. All I want is a simple, self-contained series of patches that change things in a way that is reviewable - you know, the standard way to submit patches, like the Linux kernel workflow and countless others. A single diff that just runs getmail through the 2to3 tool and then hacks on fixes until it runs will touch virtually every line in the code. That would be completely unreviewable, and nobody would expect that to be a workable way of submitting changes - but that's immaterial, as he hasn't even done that. > If I rename the package then I will need to add another transitional > package linking getmail6 with the new package which will not do > anything to help your problem. On the contrary -- it will help me *in future*. Please do rename the package and executable. > Renaming the executable is not possible as that will break lots of > user's scripts. Just have apt-listchanges tell people to change their scripts or crontabs from "getmail" to "wonderfulmailpuller" or whatever. I see these sorts of announcements regularly when I upgrade Debian packages, and particularly when updating a major version. You are removing getmail and installing a different package - you do this sort of thing all the time. It's a trivial fix, and I would argue it's *less* disruptive to users, because then at least people will be able to find the correct place to get support, rather than searching "getmail" and finding nothing related to their problem at all (because the bug isn't in getmail, and whereupon they then contact me). > And if the executables need to be renamed then that needs to be done from > upstream so that it is consistent in all other distros and pypi. Please > discuss that with Roland, the getmail6 upstream maintainer. As I have said, he obstinately refuses any name change, claiming equal rights to the name I have built up for 23 years. I'm really disappointed that Debian - or this package maintainer - doesn't give a damn about doing the right, ethical thing here. Charles -- -- Charles Cazabon Software, consulting, and services available at http://pyropus.ca/ --
Bug#996569: getmail6 naming issues
On Sun, Nov 7, 2021 at 11:39 PM Charles Cazabon wrote: > > Sudip Mukherjee wrote: > > > > So, my preference is: > > 1. rename the package and executable. As I have pointed out, this is the > normal, polite, accepted best practice when forking a project. The fact that > Roland claims to have "as much right to the getmail name" as I, the author, > do, just means that Debian should rename their package without waiting for > Roland to do the right thing. As I said, Debian is supposed to be about doing > what is ethical - so why do you object to renaming a hostile fork of an > actively-developed project which is namesquatting on the original project > name? iiuc, getmail6 is not a "hostile fork". getmail6 is a Python3 based fork which all the distros had to package because you have declined to support Python3. Roland has offered to send you ( I think already sent you) patches. There are many other projects whose python3 fork is now coexisting with the original project and the maintainers have realised the need to support the python3 fork. If I rename the package then I will need to add another transitional package linking getmail6 with the new package which will not do anything to help your problem. Renaming the executable is not possible as that will break lots of user's scripts. And if the executables need to be renamed then that needs to be done from upstream so that it is consistent in all other distros and pypi. Please discuss that with Roland, the getmail6 upstream maintainer. > > 2. If (1) is rejected, then drop "getmail6" completely. Restore the getmail > package that depends on python2.7 and everything will continue to work for > users who have getmail installed pre-upgrade, or who want to install it > afterwards. Not possible. Python 2.7 is there only for the build process and not for running applications. The following is quoted from Debian Bullseye release notes: Python 2 is already beyond its End Of Life, and will receive no security updates. It is not supported for running applications, and packages relying on it have either been switched to Python 3 or removed. However, Debian bullseye does still include a version of Python 2.7, as well as a small number of Python 2 build tools such as python-setuptools. These are present only because they are required for a few application build processes that have not yet been converted to Python 3. Not just Debian but all the distros need to have a Python3 version of getmail and getmail6 is the only alternative available now. I will be very very happy to remove getmail6 when you release a Python3 version of getmail. But until then I will only remove the transitional package. I don't see the need to communicate any further on this and to summarise what I have said: 1) I will remove the transitional package for now using this bug report. 2) Please do let me know after you have released a Python3 version of getmail and i will remove getmail6. -- Regards Sudip
Bug#996569: getmail6 naming issues
Sudip Mukherjee wrote: > > 1) The Debian maintainers of getmail have offered to help with > supporting python3 and have even submitted patches or pointed to their > wip branches in github which I think were all rejected. I have not rejected anything. I have asked questions of people who submitted patches *which currently do nothing except kill support for Python < 2.7*. > 2) The previous Debian maintainers have also requested Charles to do > the python3 development in open so that the effort is not duplicated. I do not currently use a public forge for getmail development. I have reasons. > 3) Reading https://marc.info/?l=getmail=151542154628352=2 I am not > really convinced that Charles will ever support Python3. You're wrong, then -- I'm not sure what you're basing that opinion on, besides your own unsupported supposition. I have already done part of the rewrite for Python 3; I just don't have 10+ hours a week to devote to open-source/free software the way I did two decades ago. That message just says getmail would not be Python 3 compatible that year - it says nothing whatsoever about getmail never supporting Python 3. > 4) Charles says his getmail users' mailing list has been inundated > with support requests. I have gone through the last 1 year history of > the mailing list and could only find the last one from Michael and > another one in December,2020 Then you missed some. > 5) Also noticed getmail user's positive experience upgrading to > getmail6 at https://marc.info/?l=getmail=160131249528542=2 So some users have *not* hit bugs when running "getmail6". I never said differently. > 6) https://marc.info/?l=getmail=160060476624283=2 shows the plight > of a user who tried to continue using getmail with Debin testing. That problem does not appear to actually be related to getmail. It appears to be a user running with a Python 2.7 that was compiled without SSL support. I thought getmail caught this error and issued a diagnostic, but maybe not -- it's been a long, long time since I used a Python that didn't have SSL. There is no "plight" to running getmail on current Debian. The complete process is: 1. apt-get install python2.7 2. install real getmail, or don't even install it, just unpack it That's it. It works. See: /tmp/getmail-test$ tar xzf ~/projects/getmail-trunk/dist/getmail-5.16.tar.gz /tmp/getmail-test$ dpkg -l python2.7 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---==> ii python2.7 2.7.18-8 amd64Interactive high-level object-orie> charlesc@vetinari:/tmp/getmail-test$ cd getmail-5.16/ charlesc@vetinari:/tmp/getmail-test/getmail-5.16$ ./getmail --help Usage: getmail [options] Options: --version show program's version number and exit -h, --helpshow this help message and exit -g DIR, --getmaildir=DIR look in DIR for config/data files -r FILE, --rcfile=FILE load configuration from FILE (may be given multiple times) --dumpdump configuration and exit (debugging) --trace print extended trace information (extremely verbose) -i FOLDER, --idle=FOLDER maintain connection and listen for new messages in FOLDER. Only applies if a single rc file is given with a connection to an IMAP server that supports the IDLE command Overrides: The following options override those specified in any getmailrc file. -v, --verbose operate more verbosely (may be given multiple times) --fingerprint show SSL/TLS fingerprint and connection information -q, --quiet operate quietly (only report errors) -d, --deletedelete messages from server after retrieving -l, --dont-delete do not delete messages from server after retrieving -a, --all retrieve all messages -n, --new retrieve only unread messages > 1) Since the development of getmail is not in the open it's possible > that users have sent personal mail to Charles asking for support and It's not "possible", it actually happens. A lot. About a lot of different bugs. See the "getmail6" changelog for the number of fixes, each one of which I've probably received multiple support requests about. > We think the best way is to remove the transitional package which will > break the link between getmail and getmail6 so that Debian users who > are using getmail will not automatically be upgraded to
Bug#996569: getmail6 naming issues
I have thought about it again while going through all the old mails of getmail mailing list and also https://bugs.debian.org/936604 and these are my thoughts: 1) The Debian maintainers of getmail have offered to help with supporting python3 and have even submitted patches or pointed to their wip branches in github which I think were all rejected. 2) The previous Debian maintainers have also requested Charles to do the python3 development in open so that the effort is not duplicated. 3) Reading https://marc.info/?l=getmail=151542154628352=2 I am not really convinced that Charles will ever support Python3. 4) Charles says his getmail users' mailing list has been inundated with support requests. I have gone through the last 1 year history of the mailing list and could only find the last one from Michael and another one in December,2020 - https://marc.info/?l=getmail=160716812508287=2 (but more on this below) 5) Also noticed getmail user's positive experience upgrading to getmail6 at https://marc.info/?l=getmail=160131249528542=2 6) https://marc.info/?l=getmail=160060476624283=2 shows the plight of a user who tried to continue using getmail with Debin testing. I have also discussed about this issue with few other DDs and we think: 1) Since the development of getmail is not in the open it's possible that users have sent personal mail to Charles asking for support and that is really not fair if Charles receives a support request about another project. 2) Removing getmail6 is not an option as: a) getmail and getmail6 are considered as separate upstream projects. b) Debian users who are using getmail6 will be left without anything. c) I personally know a few users of getmail/getmail6 whose employer's corporate policy forbids them to install anything which is not in Debian. If getmail6 is removed then these types of users will not have anything. 3) Renaming getmail6 package is not going to help anything if the transitional package continues to link getmail with getmail6 (or whatever the renamed package is). We think the best way is to remove the transitional package which will break the link between getmail and getmail6 so that Debian users who are using getmail will not automatically be upgraded to getmail6 and they will explicitly need to install getmail6 if they want to. That should solve the problem for which Charles has opened this bug report as the users will already know that they do not have getmail and they are installing something else. I will use this bug to remove the transitional package and will also ask the release team if this can be included in the next Point Release. -- Regards Sudip
Bug#996569: getmail6 naming issues
I'd like to strongly object to the removal of this package from Debian. As per the Debian social contract: "4. Our priorities are our users and free software. We will be guided by the needs of our users and the free software community. *We will place their interests first in our priorities*". It is my understanding that the needs of our users was the main reason that Charles' getmail was replaced by the getmail6 fork. What has changed since then? Also, per the same social contract: "4. Integrity of the Author's Source Code (...) The license may require derived works to carry a different name or version number from the original software. (This is a compromise. The Debian group encourages all authors not to restrict any files, source or binary, from being modified)". As far as I am aware, the license under which getmail is distributed does not have this requirement other than that "(y)ou must cause the the modified files to carry prominent notices stating that you changed the files and the date of any change." I believe getmail6 sufficiently meets this requirement. If it doesn't, please point out how and where it doesn't so this can be addressed.
Bug#996569: getmail6 naming issues
Hi, On Mon, 18 Oct 2021 12:09:56 +0100 Sudip Mukherjee wrote: > > I think I was not able to explain properly. Even if I rename or remove > the package now, it will only affect Debian unstable and testing > releases. It will not affect Debian Bullseye release. Surely such a change can be pushed for the current version as an update. Even if not, will you please do change the package name for unstable and testing? Even if for some reason it cannot be fixed in stable, I would like to ensure this doesn't continue to pollute getmail's reputation forever. > ooi, are you going to ask all the other distro and pypi to rename or > remove getmail ? "getmail6"? Yes, I will. I'm asking Debian first because I use Debian myself. > And, can you please send me the links to your mailing list mail > archive where Debian users have asked for support after upgrading.. > If I search for "getmail6" or "debian" in your mailing list I can only This is the point. Users report problems *without* saying they're using "getmail6". There are a number of other reports that have come though my mailing list, and 15-20 in private email. But regardless, I'm sure Debian's position isn't "we'll change the package name IFF in our opinion it causes too much work for the original author" ? Surely Debian will respect an explicit request from the project owner? > So, I am a little bit puzzled now when you say "imposing a significant > support burden". Since I'm the one that burden is imposed on, and you cannot even see it, I'm curious why you belive you would be able to judge whether that burden is significant or not. Charles -- -- Charles Cazabon Software, consulting, and services available at http://pyropus.ca/ --
Bug#996569: getmail6 naming issues
On Sun, Oct 17, 2021 at 11:38 PM Charles Cazabon wrote: > > Hi, Sudip, > > Thanks for the response. > > > > On Fri, 15 Oct 2021 10:55:40 -0600 Charles Cazabon wrote: > > > > > > > > I would appreciate it if this package/project was renamed to something > > > > that does not contain the word "getmail" or anything confusingly > > > > similar. > > > > "getmail" and "getmail6" are separate source packages and they were > > kept separate with the hope that you will release the python3 version > > one day and then getmail can be reintroduced. > > That's fine as far as it goes, but you have not addressed my concern and the > reason I filed this report. I think I was not able to explain properly. Even if I rename or remove the package now, it will only affect Debian unstable and testing releases. It will not affect Debian Bullseye release. ooi, are you going to ask all the other distro and pypi to rename or remove getmail ? just fyi - https://repology.org/project/getmail6/versions And, can you please send me the links to your mailing list mail archive where Debian users have asked for support after upgrading.. If I search for "getmail6" or "debian" in your mailing list I can only see one issue that has been reported by "Michael Grant" in 2021. And afaik, that issue has been fixed in the latest version of getmail6. So, I am a little bit puzzled now when you say "imposing a significant support burden". -- Regards Sudip
Bug#996569: getmail6 naming issues
Hi, Sudip, Thanks for the response. > > On Fri, 15 Oct 2021 10:55:40 -0600 Charles Cazabon wrote: > > > > > > I would appreciate it if this package/project was renamed to something > > > that does not contain the word "getmail" or anything confusingly > > > similar. > > "getmail" and "getmail6" are separate source packages and they were > kept separate with the hope that you will release the python3 version > one day and then getmail can be reintroduced. That's fine as far as it goes, but you have not addressed my concern and the reason I filed this report. I did not consent to the fork using my project name. I am explicitly asking it to be changed to something that does not infringe on my trademark "getmail". I would think that the Debian project is about acting ethically, and when the owner of the upstream project explicitly asks a forked, buggy version to use a different name, the ethical thing to do is to respect that request and pick a new name. > I am not sure how this is going to help. Any change I do now will be > affecting the next Debian release in 2023. Packages change in Debian all the time. This can be changed. > I will remove the transitional package before Debian Bookworm is > released so that getmail and getmail6 will not be linked anymore. You still have not committed to removing the name "getmail" from this project. Can you please commit to doing this promptly, and let me know when it will be done? Charles -- -- Charles Cazabon Software, consulting, and services available at http://pyropus.ca/ --
Bug#996569: getmail6 naming issues
Hi Charles, On Sat, Oct 16, 2021 at 8:33 PM Charles Cazabon wrote: > > On Fri, 15 Oct 2021 10:55:40 -0600 Charles Cazabon wrote: > > > > So: fork is fine. Imposing a large support burden on the original project > > is > > not. I would appreciate it if this package/project was renamed to something > > that does not contain the word "getmail" or anything confusingly similar. "getmail" and "getmail6" are separate source packages and they were kept separate with the hope that you will release the python3 version one day and then getmail can be reintroduced. getmail -> https://tracker.debian.org/pkg/getmail getmail6 -> https://tracker.debian.org/pkg/getmail6 > > I have a specific suggestion for Debian to address this issue. > > 1. The upstream author, or if he refuses, the Debian package maintainer, can > pick a new package name that does not pollute my getmail package, > community, mailing list, and trademark, and which will stop imposing this > unwelcome support burden on me and the getmail mailing list/community. > I don't know what name you'll pick; for the rest of this proposal, let's > use "go-grab-my-email" as an example. I am really sorry that users are asking you for support instead of opening bugs with Debian, which was giving us the impression that getmail6 is working fine. But again, the README and the manpage clearly says that bugs should be reported to https://github.com/getmail6/getmail6. > > 2. Package it for Debian. Have it use the `Obsoletes: getmail` metadata so > that users upgrading a Debian system have getmail correctly removed and > the go-grab-my-email package installed, similar to what happens with the > "getmail6" package now. It initially had "Conflicts: getmail" to make sure getmail is uninstalled before any user tries to install getmail6 but then one user of getmail asked for them to be linked. You can see the details at https://bugs.debian.org/979060 > > 3. Additionally, make the new package display an informational screen via > apt-listchanges when getmail is removed and go-grab-my-email is installed. > It should say something like: I am not sure how this is going to help. Any change I do now will be affecting the next Debian release in 2023. When users of getmail upgrades to Debian Bullseye they will always get getmail6 because of the transitional package. I will remove the transitional package before Debian Bookworm is released so that getmail and getmail6 will not be linked anymore. -- Regards Sudip
Bug#996569: getmail6 naming issues
On Fri, 15 Oct 2021 10:55:40 -0600 Charles Cazabon wrote: > > So: fork is fine. Imposing a large support burden on the original project is > not. I would appreciate it if this package/project was renamed to something > that does not contain the word "getmail" or anything confusingly similar. I have a specific suggestion for Debian to address this issue. 1. The upstream author, or if he refuses, the Debian package maintainer, can pick a new package name that does not pollute my getmail package, community, mailing list, and trademark, and which will stop imposing this unwelcome support burden on me and the getmail mailing list/community. I don't know what name you'll pick; for the rest of this proposal, let's use "go-grab-my-email" as an example. 2. Package it for Debian. Have it use the `Obsoletes: getmail` metadata so that users upgrading a Debian system have getmail correctly removed and the go-grab-my-email package installed, similar to what happens with the "getmail6" package now. 3. Additionally, make the new package display an informational screen via apt-listchanges when getmail is removed and go-grab-my-email is installed. It should say something like: The getmail package has been deprecated because the current version depends on Python 2.7, which has been removed from Debian Foo. From now on, run `go-grab-my-email` instead of `getmail`. This package aims to be a backwards-compatible Python 3 port of getmail. This provides a seamless upgrade path for current getmail users, explicitly deprecates the getmail package and explains why to the user, installs the replacement package, and tells the user what happened and how to continue with their current getmail configuration. And since they're no longer installing "getmail" or running "getmail", my getmail users' mailing list and my personal email are no longer inundated with poorly-documented support requests arising from users' confusion over the "getmail6" name, or indeed their complete ignorance of the fact that getmail has been removed and getmail6 installed on their system. I have had a number of requests from users who reported problems to me and were not even aware this package had been installed on their system in place of getmail during an upgrade. Thank you, Charles -- -- Charles Cazabon Software, consulting, and services available at http://pyropus.ca/ --
Bug#996569: getmail6 naming issues
Package: getmail6 Version: 6.14-1 Hi, I'm the original author of getmail, which was included in the Debian repositories for a long time (until you dropped most packages depending on Python 2). getmail6 is a fork of getmail. I'm fine with forking; I chose the GPLv2 for a reason. However, the getmail6 package contains numerous bugs that are not present in getmail (they keep coming up, and I have reasons to believe this will continue to be the case for a significant time), and this is imposing a significant support burden on me. It also is harming the reputation of getmail, which has a long (23 years) history of very, very few bugs. No matter what the getmail6 documentation says, when users hit a problem with getmail6, they just web-search "getmail" and end up reporting it to my getmail users' mailing list, or directly to my personal email. And they generally do not mention the version number they're using. It takes signficant time and work to actually get to the point where I can point out that they're using getmail6 and not getmail, and that the bug they've hit is not present in getmail. So: fork is fine. Imposing a large support burden on the original project is not. I would appreciate it if this package/project was renamed to something that does not contain the word "getmail" or anything confusingly similar. I don't particularly care what - just as long as the package/project does not contain "getmail", which will significantly reduce the likelihood of users of that project from contacting me for support. I have requested this of the getmail6 author but have not had a positive response from him yet. Perhaps Sudip Mukherjee, the Debian package maintainer, can either help persuade the author of that package to change its name, or can rename the Debian package if not. Thank you, Charles -- -- Charles Cazabon Software, consulting, and services available at http://pyropus.ca/ --
