All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Stappers <stappers@stappers.nl>
To: mlmmj@mlmmj.org
Subject: Re: [mlmmj] distribution "dead upstream" discussion
Date: Thu, 21 Jan 2021 21:59:50 +0000	[thread overview]
Message-ID: <20210121215950.spymd2wa6qyqi7ym@gpm.stappers.nl> (raw)
In-Reply-To: <b6763fd2-a7ca-1c16-b304-43d1ce0b09da@coredump.us>

On Thu, Jan 21, 2021 at 09:43:40AM -0800, webmaster wrote:
> On 1/21/2021 2:35 AM, Chris Knadle wrote:
> > Today I was contacted and asked about the status of mlmmj upstream
> > because from the point of view of the outside world it looks dead; the
> > mailing list archive stopped working in Dec 2017, there's no new commits
> > to the Mercurial or Git repositories since 2017, and thus no indication
> > that MLMMJ is "alive".

Fact

 
> > I happen to be on the mlmmj "discussion" mailing list because I maintain
> > the 'mlmmj' package in Debian, so I took the time to read through the
> > "Is this list active? Where is "upstream"??" and similar threads, and I
> > see that there's a Git repo fork at https://gitlab.com/mlmmj/mlmmj and
> > had a look at it ... but nobody from the outside world can see that this
> > exists, because that repo is not mentioned on the website nor the
> > mailing list archives.
> > 
> > From the distribution point of view this appears to be "dead upstream"
> > and is a reason for package removal. Debian is about to do a "soft
> > freeze" for preparation for the next release whereby packages in the
> > archive will need bug support for 3 years.
> > 
> > The main thing I want to know is "what should I do about the release?"
> > I'm considering the following choices:
> >   a) release 'mlmmj' as before, with myself as maintainer of the package.
> >   b) orphan the package so that there is no listed maintainer, where the package
> >      might be released with Debian 11 or might get dropped, depending on what
> >      the Release Team decides about the package themselves
> >   c) request removal of the package from the archive
> > 
> > Choice "a)" only fits if someone in "upstream" is willing to try to fix
> > bugs that get reported. Are there others helping with this at present?

Somehow there is consensus about "Somebody ELSE  should do it"    :-/


> > Right now I'm uncomfortable about this because the GitLab repo can't be
> > found from the mlmmj.org web page, and that repo seems to be where bugs
> > are reported and handled lately, as best I can tell. Is that correct?

Yes, mlmmj.org was abandoned.  Luckly is the mailinglist still up.
So https://gitlab.com/mlmmj/mlmmj could be announced and we are
having this mailthread.


> > Side note: In terms of chances of bugs needing upstream help, looking at
> > the Debian "popularity contest" figures I see that the number of users
> > reporting having mlmmj loaded is low but slowly going /up/, which is
> > good but not what I expected to see. (Note: these "popcon" numbers are
> > likely artificially low, because not all machines are set to report
> > popcon data to Debian.)
> > 
> >    https://qa.debian.org/popcon.php?package=mlmmj
> > 
> > Choice "b)" seems the most reasonable to me under the circumstances, but
> > puts the package at risk of removal. This option does not preclude me
> > from continuing to help fix bugs on the package as a "non-maintainer",
> > which is what I would intend to do, for as long as I still use the
> > package.
> > 
> > I'd like to hear other's thoughts about this so we can discuss it some.
> > Thanks.
> >    -- Chris
> > 
> I'm just a site admin who uses mlmmj on several domains, so I can't speak to
> the maintenance issues but only as a user of mlmmj:
> 
> I've recently looked at other mailing list options (again) and I still find
> nothing with the same level of flexibility and ease of use, in terms of
> managing several lists on a domain and being able to write basic PHP to
> manage the lists per my own needs.
> 
> Compared to Mailman... well there is no comparison - I'd rather use mlmmj
> every time.
> 
> mlmmj can be a bit difficult to install, given the sometimes terse and
> incomplete documentation, but once it's working, it IS a joy to work with.
> 
> I too have been concerned that it appears there's been no activity recently,
> but until it breaks or some email security paradigm shifts and makes mlmmj
> un-safe to use, I'll still be a fan, and I'll still recommend it to others. 
> I'm not surprised to hear adoption is currently going up.
> 
> It might get even more adoption if it appeared it was being maintained
> currently. I realize its easy to say this from a user perspective; I'd be
> happy to help in some way if my skill-set would be useful, but I don't have
> a deep knowledge of email systems.
> 
> It would be a great shame to see such a well-structured mailing list app
> fade into history.


True


> just my two cents.
> 
> Philip
> 


My thoughts about this:

* Discuss this further
* Scrape/Mirror/Copy the website   (to prevent making a new design)
* Transfer the domain name to community thrust
* Have somewhere webserver that can serve static webpages
* Update DNS to point to that webserver
* Update website
** mlmmj is mature
** https://gitlab.com/mlmmj/mlmmj
* Have somewhere server that can do mlmmj
* Transfer this mailinglist to that server
* Accept that mlmmj is mature software
Last, but not least
* Make contributing to this mature software possible


Regards
Geert Stappers

P.S.
Mads, what "transfer powers" do you have?
Ben, no need to explain what is keeping you busy,
please make domain transfer possible.
-- 
Silence is hard to parse


  parent reply	other threads:[~2021-01-21 21:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-21 10:35 [mlmmj] distribution "dead upstream" discussion Chris Knadle
2021-01-21 17:43 ` webmaster
2021-01-21 21:59 ` Geert Stappers [this message]
2021-01-21 22:09 ` Eric Wong
2021-01-21 22:40 ` Christof Thalhofer
2021-01-22  3:50 ` Chris Knadle
2021-01-22  3:57 ` Chris Knadle
2021-01-22  6:03 ` Mads Martin Jørgensen
2021-01-25 17:20 ` Thomas Goirand
2021-01-26  0:14 ` Mads Martin Jørgensen
2021-01-27 15:58 ` Chris Knadle
2021-02-02 17:14 ` Thomas Goirand
2021-02-03 21:02 ` Chris Knadle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210121215950.spymd2wa6qyqi7ym@gpm.stappers.nl \
    --to=stappers@stappers.nl \
    --cc=mlmmj@mlmmj.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.