[mlmmj] distribution "dead upstream" discussion

[mlmmj] distribution "dead upstream" discussion

[Chris Knadle]

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".

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?
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?

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

-- 
Chris Knadle
Chris.Knadle@coredump.us

Re: [mlmmj] distribution "dead upstream" discussion

[webmaster]

[-- Attachment #1: Type: text/plain, Size: 4126 bytes --]

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.

just my two cents.

Philip



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".
>
> 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?
> 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?
>
> 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
>


[-- Attachment #2: Type: text/html, Size: 5383 bytes --]

Re: [mlmmj] distribution "dead upstream" discussion

[Geert Stappers]

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

Re: [mlmmj] distribution "dead upstream" discussion

[Eric Wong]

Chris Knadle <Chris.Knadle@coredump.us> 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".
> 
> 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.

Hi Chris, thanks for maintaining mlmmj for Debian!

For one, I can't use GitLab due to the CAPTCHA and JS requirements.
I find bugs, I'll report bugs via the Debian BTS, here, and maybe
work up a patch.

> 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.

As a mere user of Debian who doesn't care for popcon, I find
the "dead upstream" reason annoying.  Sometimes software is just
"done" and good :)  New features generally leads to more bugs,
which can penalize existing users.

I've already lost "iprint" and "mp3gain" so just end up copying
binaries from old installs, now.

> 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?

I can help with critical bugfixes here or on the Debian BTS via
email.  Don't expect me to use JS or accept terms-of-service(*).

I spent over a decade focused on fixing and preventing bugs in
others' C89/C99 code; so I might still remember some things :>

I also have some experience with Debian packaging from the
early-2000s which may be out-of-date.

> 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?
> 
> 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

Interesting and good to know it's going up.  I don't use popcon
myself since I prefer to run as little software as necessary.

> 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.

"a)" seems to be the safest choice to prevent removal and
perhaps get new users; especially if you keep using and
maintaining it.

Thanks again for your work on Debian and I'll be happy to help
over plain-text email.


(*) To be fair, GitLab's ToS was less horrible than GitHub's
    from what I recall...  The major reason I continue using
    mlmmj and email is I can't stand JS, ToS, GUIs, and
    proprietary messaging systems.

Re: [mlmmj] distribution "dead upstream" discussion

[Christof Thalhofer]

Am 21.01.21 um 22:59 schrieb Geert Stappers:

> 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

Hello, do you have any idea how much traffic the website and mailinglist
generate per month?

Alles Gute

Christof Thalhofer

-- 
[x] nail here for new monitor

Re: [mlmmj] distribution "dead upstream" discussion

[Chris Knadle]

Thomas Goirand:
> On 1/21/21 11: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".
>>
>> 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
> 
> Hi Chris,
> 
> Before doing that, you may consider asking your co-maintainers about it,
> aka: myself. I still want to see MLMMJ in Debian, and I see no reason to
> remove it.

Yes, before actually doing it I would have checked with you -- yes
But being that I had serious concerns about things upstream, it made sense to 
contact upstream about that.  Unless you're saying you're part of upstream?

> MLMMJ is a mature software, with no new feature being added, simply
> because it's feature complete. So it's kind of normal not to see so much
> activity.
> 
> There's currently no RC bug against the Debian package, so there's no
> reason to remove it because of that.

Library and compiler changes commonly cause new build bugs if nothing else, and 
it's very common for unmaintained software to eventually get removed because of 
that kind of breakage.  As such it makes sense to contact upstream to discuss 
the situation now.

>> 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?
>> 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?
> 
> What's the numerous problems you've found against MLMMJ that you're
> discussing here? I see MLMMJ as a package with really minimum issue.

I've already explained my concerns in the email I sent to the list.  What about 
what I said wasn't clear?  All MLMMJ development has stopped, the mailing list 
archives stopped working in 2017, there's a repo fork that isn't listed anywhere 
on the site, and I wanted to know how to report bugs upstream because that was 
up in the air.  Are you saying you consider all of that as being "just fine"?

    -- Chris

-- 
Chris Knadle
Chris.Knadle@coredump.us

Re: [mlmmj] distribution "dead upstream" discussion

[Chris Knadle]

Eric Wong:
> Chris Knadle <Chris.Knadle@coredump.us> wrote:
[...]
>>  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.
> 
> As a mere user of Debian who doesn't care for popcon, I find
> the "dead upstream" reason annoying.  Sometimes software is just
> "done" and good :)  New features generally leads to more bugs,
> which can penalize existing users.

Debian Developers are intended to remain in contact with upstream developers for 
a number of reasons; DDs are not expected to fix non-Debian related bugs, for 
instance.

https://www.debian.org/doc/manuals/developers-reference/developer-duties.en.html#coordination-with-upstream-developers

And yes, the "dead upstream" reason for package removal is annoying, but it's 
one of the most common reasons I see cited for package removal when there's also 
bugs that upstream would normally be the one to handle handle.

> I've already lost "iprint" and "mp3gain" so just end up copying
> binaries from old installs, now.

Debian has quite a number of packages (1189) that are "orphaned" and still in 
the archive.

https://www.debian.org/devel/wnpp/orphaned

    -- Chris

-- 
Chris Knadle
Chris.Knadle@coredump.us

Re: [mlmmj] distribution "dead upstream" discussion

[Mads Martin Jørgensen]

Hello all,

> On 22 Jan 2021, at 04.50, Chris Knadle <Chris.Knadle@coredump.us> wrote:
> 
> I've already explained my concerns in the email I sent to the list.  What about what I said wasn't clear?  All MLMMJ development has stopped, the mailing list archives stopped working in 2017, there's a repo fork that isn't listed anywhere on the site, and I wanted to know how to report bugs upstream because that was up in the air.  Are you saying you consider all of that as being "just fine"?

I also haven't heard from Ben since 2018, so maybe it's time to move the website somewhere else and find a fresh maintainer. Would really hope the transition could be with Bens blessing, but as the original developer I do have access to the people who own the mlmmj.org domain.

Best wishes,
Mads Martin
--
"Why make things difficult, when it is possible to make them cryptic and
totally illogical, with just a little bit more effort?" - A. P. J

Re: [mlmmj] distribution "dead upstream" discussion

[Thomas Goirand]

On 1/22/21 4:50 AM, Chris Knadle wrote:
> Thomas Goirand:
>> There's currently no RC bug against the Debian package, so there's no
>> reason to remove it because of that.
> 
> Library and compiler changes commonly cause new build bugs if nothing
> else, and it's very common for unmaintained software to eventually get
> removed because of that kind of breakage.  As such it makes sense to
> contact upstream to discuss the situation now.

It's been years this didn't happen to MLMMJ, because it's using a very
clean C code, which doesn't involve lots of moving parts. Have you
notice how much the MLMMJ Build-Depends: is empty? How much MLMMJ only
relies on the standard C libs? That's also one very strong point of
MLMMJ and why I like it so much.

MLMMJ is of very low need for maintenance, both upstream or in the
Debian package. So much that our Debian source package is bit-rotting,
and would need a real clean-up (to switch to the dh sequencer, for a
start, and probably many other stuff...).

>> What's the numerous problems you've found against MLMMJ that you're
>> discussing here? I see MLMMJ as a package with really minimum issue.
> 
> I've already explained my concerns in the email I sent to the list. 
> What about what I said wasn't clear?  All MLMMJ development has stopped,
> the mailing list archives stopped working in 2017, there's a repo fork
> that isn't listed anywhere on the site, and I wanted to know how to
> report bugs upstream because that was up in the air.  Are you saying you
> consider all of that as being "just fine"?

It's not fine, it's best when the site is well maintained, I agree. But
I do not consider MLMMJ itself unmaintained like you thought. At least,
the currently situation isn't as bad as enough to remove MLMMJ from Debian.

My reasoning is also triggered by the fact I would trust Martin to help
in case there's nobody else available. Martin, can you confirm that?

Cheers,

Thomas Goirand (zigo)

Re: [mlmmj] distribution "dead upstream" discussion

[Mads Martin Jørgensen]

I’m more than ready to step back in as maintainer for now. Then we can always see what happens. But let’s stabilize it again, go through all of the stuff, and see where we end up.

> On 25 Jan 2021, at 18.20, Thomas Goirand <thomas@goirand.fr> wrote:
> 
> My reasoning is also triggered by the fact I would trust Martin to help
> in case there's nobody else available. Martin, can you confirm that?

Re: [mlmmj] distribution "dead upstream" discussion

[Chris Knadle]

Thomas Goirand:
> On 1/22/21 4:50 AM, Chris Knadle wrote:
>> Thomas Goirand:
>>> There's currently no RC bug against the Debian package, so there's no
>>> reason to remove it because of that.
>>
>> Library and compiler changes commonly cause new build bugs if nothing
>> else, and it's very common for unmaintained software to eventually get
>> removed because of that kind of breakage.  As such it makes sense to
>> contact upstream to discuss the situation now.
> 
> It's been years this didn't happen to MLMMJ, because it's using a very
> clean C code, which doesn't involve lots of moving parts. Have you
> notice how much the MLMMJ Build-Depends: is empty? How much MLMMJ only
> relies on the standard C libs? That's also one very strong point of
> MLMMJ and why I like it so much.

If mlmmj were to become orphaned then this would become an important factor as 
to how long the software would survive in distributions, but other than that I 
don't see the above as relevant at the moment.

> MLMMJ is of very low need for maintenance, both upstream or in the
> Debian package. So much that our Debian source package is bit-rotting,
> and would need a real clean-up (to switch to the dh sequencer, for a
> start, and probably many other stuff...).

Yes, the Debian mlmmj package is bit-rotting some, because there's no new 
versions to upload nor new bugs to prompt making a new upload. I don't see the 
point of updating the debian/rules file to dh unless MLMMJ development is picked 
up again, but I am interested in doing that if that happens.

Speaking of bit-rotting, I'd appreciate it if you could look at bug #622621, 
because I've looked at that bug several times over several years and I don't 
know how to complete the documentation updates that the user was told you'd do. 
As it's documentation updates this is also something upstream would normally 
need to be involved in.

https://bugs.debian.org/622621

>>> What's the numerous problems you've found against MLMMJ that you're
>>> discussing here? I see MLMMJ as a package with really minimum issue.
>>
>> I've already explained my concerns in the email I sent to the list.
>> What about what I said wasn't clear?  All MLMMJ development has stopped,
>> the mailing list archives stopped working in 2017, there's a repo fork
>> that isn't listed anywhere on the site, and I wanted to know how to
>> report bugs upstream because that was up in the air.  Are you saying you
>> consider all of that as being "just fine"?
> 
> It's not fine, it's best when the site is well maintained, I agree. But
> I do not consider MLMMJ itself unmaintained like you thought. At least,
> the currently situation isn't as bad as enough to remove MLMMJ from Debian.

I don't agree that MLMMJ is maintained -- for the moment it isn't, but there's 
some hope that that may change soon, or at least that's what I'm hoping for.

> My reasoning is also triggered by the fact I would trust Martin to help
> in case there's nobody else available. Martin, can you confirm that?

Nope. I appreciate that we got the answer to that though, as it helps plan what 
to try to do next.

    -- Chris

-- 
Chris Knadle
Chris.Knadle@coredump.us

Re: [mlmmj] distribution "dead upstream" discussion

[Thomas Goirand]

On 1/27/21 4:58 PM, Chris Knadle wrote:
>> MLMMJ is of very low need for maintenance, both upstream or in the
>> Debian package. So much that our Debian source package is bit-rotting,
>> and would need a real clean-up (to switch to the dh sequencer, for a
>> start, and probably many other stuff...).
> 
> Yes, the Debian mlmmj package is bit-rotting some, because there's no
> new versions to upload nor new bugs to prompt making a new upload. I
> don't see the point of updating the debian/rules file to dh unless MLMMJ
> development is picked up again, but I am interested in doing that if
> that happens.

The point is that it helps to keep your package up-to-date for new
stuff. For example, the current version of the package doesn't call
dh_strip_nondeterminism which is a new thing, and which dh calls.

Cheers,

Thomas Goirand (zigo)

Re: [mlmmj] distribution "dead upstream" discussion

[Chris Knadle]

Thomas Goirand:
> On 1/27/21 4:58 PM, Chris Knadle wrote:
>>> MLMMJ is of very low need for maintenance, both upstream or in the
>>> Debian package. So much that our Debian source package is bit-rotting,
>>> and would need a real clean-up (to switch to the dh sequencer, for a
>>> start, and probably many other stuff...).
>>
>> Yes, the Debian mlmmj package is bit-rotting some, because there's no
>> new versions to upload nor new bugs to prompt making a new upload. I
>> don't see the point of updating the debian/rules file to dh unless MLMMJ
>> development is picked up again, but I am interested in doing that if
>> that happens.
> 
> The point is that it helps to keep your package up-to-date for new
> stuff. For example, the current version of the package doesn't call
> dh_strip_nondeterminism which is a new thing, and which dh calls.

I think this is a "red herring".

- The purpose of dh_strip_nondeterminism is to remove build-time changes
   that would cause the package not to be reproducible -- but the mlmmj
   package has been reproducible for a long time.

    https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mlmmj.html

- dh_strip_nondeterminism could be called without switching to dh
- A switch to dh in debian/rules is an invasive change (i.e. it commonly
   causes some bugs to start with) and so it's not something I'd want to do
   close to freeze time, which is exactly where we are.



I haven't heard any reply about bug #622621 which is something that I think 
would be good to address before the Debian release. I'm making a second request: 
can you please look at that bug and discuss it?

    -- Chris

-- 
Chris Knadle
Chris.Knadle@coredump.us