Re: [mlmmj] Candidate for an 1.4.0.a1, glad for the work

I created a PR for the php-web interface. Although it should be tested
by others, I had to change a "ROOT" in the rtemplate class before it
actually worked :-)
The archiving is for later on, in fact if anybody has a good one I'm
more than willing to switch to that ... the archiving tool I use works
ok, but I feel it is a mess in code

F.

On Wed, 2023-02-08 at 12:20 +0100, Baptiste Daroussin wrote:
> Can you open a merge request so I can merge it in the repo?
> 
> Bapt
> 
> Le 8 février 2023 12:03:32 GMT+01:00, Franky Van Liedekerke <[email protected]> a écrit :
> > For those interested: I updated the php interface to work with 8.*
> > , and added small extra functionality:
> > - edit the text files
> > - see the log
> > - use 2 extra configs to limit the people who can access the php
> > admin itf and/or who can manage the subscribers
> > 
> > I also did my interpretation of an archiver, simple but it works
> > (on linux) using mhonarc and php (control file 'webarchive' to
> > activate archiving per list), and 'webarchiveprotected' to limit
> > who can access the archive. A small
> > demo: https://lists.belnet.be/archive/
> > 
> > Franky
> > 
> > On Wed, 2023-02-08 at 07:44 +0000, Chris Knadle wrote:
> > > Greetings.
> > > 
> > > I want to give anyone working on the 1.4.0.a1 mlmmj candidate my
> > > thanks, it's 
> > > good to see that this work is going on, and I'm looking forward
> > > to packaging it 
> > > and other pieces for it for Debian when it's in a semi-
> > > stable/usable state.
> > > 
> > > I'm personally interested in an mlmmj-archiver web indexing
> > > program, because 
> > > I've had difficulties with other mailing list archivers. Lurker
> > > works but seemed 
> > > relatively inflexible, and Mhonarc required a fair bit of
> > > configuration and I 
> > > never did figure out its configuration language. Debian mailing
> > > lists are 
> > > archived in Mhonarc but I don't currently have access to the
> > > configuration used 
> > > for those.
> > > 
> > > Re: using the mlmmj name, my only thought is perhaps a minor
> > > addition to the 
> > > name to distinguish the fork, such as mlmmj-ng (next-generation)
> > > or mlmmj2. It's 
> > > not a requirement, it's just mentioning what I typically see
> > > other projects do. 
> > > I think the idea is to cover the possibility of upstream picking
> > > up their old 
> > > project again and/or avoiding old/new naming clashes. If the
> > > old/same name is 
> > > stuck with I don't have any objection.
> > > 
> > > Just in case I don't check the mailing list often enough: when
> > > you think the 
> > > program is in a buildable/usable enough state for being packaged
> > > and uploaded to 
> > > Debian, please ping me via email.
> > > 
> > > Thanks
> > >     -- Chris
> > > 
> > > -- 
> > > Chris Knadle
> > > [email protected]
> > > 
> > > Baptiste Daroussin:
> > > > Hello everyone,
> > > > 
> > > > A 1.5 years ago, I migrated FreeBSD's mailing list to mlmmj. So
> > > > far so good we
> > > > are very happy with it.
> > > > 
> > > > Since that date I have been working on modernizing mlmmj
> > > > codebase, integrate our
> > > > patches etc. While the work is clearly not done, I think it is
> > > > advanced enough
> > > > for it to be shared.
> > > 
> > > 
> > >