On Fri, 18 Mar 2022 at 13:07, Daniel Gruno <[email protected]> wrote: > > On 18/03/2022 14.01, sebb wrote: > > On Fri, 18 Mar 2022 at 12:58, Rich Bowen <[email protected]> wrote: > >> > >>> . I find it > >>> very discouraging to both devs and users if we write "don't use this > >>> software". > >>> > >> > >> +1 > >> > >> Point to a list of open/known issues for sure. But putting "don't use this" > >> in the readme has long term effects on user trust. So many times over the > >> years I have heard people cite long-fixed issues as reasons for avoiding a > >> particular package because it was made part of primary messaging. > >> > >> This kind of blanket "don't use this" messaging is weird and damaging. > > > > The point is that all software has limitations, and we should be open > > about the known issues. > > Users can then decide whether or not the limitations affect them. > > > > It's not whether there are limitations or not, it's a matter of wording. > What was written was a very wide opinionated statement that this > software doesn't work well and should not be used in production, which > is patently false and VERY discouraging to read.
It does not say that. It just says that it is not suitable as an archival solution. > If there are *specific* cases where archiving doesn't work (I don't know > of any specifics here), put that in a document, maybe make a > LIMITATIONS.md file and link to that. But putting in the main readme > that people shouldn't use our software is just rude. If an email is duplicated in transit (this does happen sometimes), subscribers to the list will generally see both copies, depending on their email client. However the duplicates do not appear in Ponymail.
