All,
As part of the migration from Mailman2 to Mailman3, I have checked which lists are actively used. The outcome allows for some rigorous cleanup.
Out of 236 mailing lists, 180 have not had a mail added to their archives *over the last 5 years(!)*. My proposal is to decommission these mailing lists, meaning that only the archives will be migrated to Mailman3. These mailing lists can always be re-instated at a later time.
Rationale for this clean-up is that some owners of the mailing lists have fallen out of contact, causing additional work to fall on the shoulders of the site maintainers: mailing lists require moderation of non-member posts, where those moderation requests which can't be delivered to the list owner, are sent to the site admins. Additionally, unused mailing lists may accrue spam mail in their archives, lowering the value of the archive. (Temporarily) Closing mailing lists can prevent this.
What do you think?
It concerns these lists:
alexandria-cvs anaphora-cvs anaphora-devel ansi-test-cvs ansi-test-devel armedbear-announce armedbear-cvs asdf-install-devel asdf-packaging-announce aspiwork-pdm-cvs aspiwork-pdm-devel bese-devel bordeaux-threads-announce bordeaux-threads-ticket boston-lisp-announce boston-lisp-organizers cello-devel cells-gtk-devel cffi-objects-cvs cl-berkeley-db-devel cl-bzip2-devel cl-containers-devel cl-dbf-cvs cl-dwim-devel cl-ec2-devel cl-emb-devel cl-facebook-devel cl-fuse-devel cl-glpk-devel cl-graph-devel cl-gsl-devel cl-gtk2-devel cl-heap-announce cl-jpeg-devel cl-json-announce cl-kanren-trs-cvs cl-kanren-trs-devel cl-l10n-devel cl-monad-macros-cvs cl-mpi-devel cl-muproc-devel cl-ncurses-devel cl-neo4j-cvs cl-neo4j-devel cl-openid-devel cl-openid-ticket cl-org-mode-devel cl-pdf-announce cl-pdf-devel cl-perec-devel cl-plus-j-announce cl-plus-j-devel cl-plus-ssl-cvs cl-plus-ssl-devel cl-pop-devel cl-proc-devel cl-sbml-cvs cl-selenium-devel cl-smtp-devel cl-soap-devel cl-sqlite-announce cl-sqlite-devel cl-store-devel cl-table-cvs cl-twitter-devel cl-typesetting-announce cl-typesetting-devel cl-unification-devel cl-utilities-devel cl-walker-devel cl-xmlspam-devel cl-xmpp-devel cl-yacc-ebnf-devel clbuild-devel cldoc-devel cleric-announce cleric-devel clfswm-announce clfswm-cvs clfswm-devel climacs-devel climplayer-devel clonsigna-announce clonsigna-devel closer-announce closer-devel clouchdb-cvs clouchdb-devel clsql-fluid-devel clx-devel cmucl-ticket common-lisp-beginner-cvs de-setf-amqp-cvs definer-announce docudown-devel eager-future-devel ecl-readline-devel eclipse-devel editor-hints-devel elephant-devel elephant-ticket f2cl-ticket fetter-devel fiveam-announce fset-devel gecol-devel ginseng-cvs gsharp-devel gtk-cffi-cvs gtk-cffi-devel heresy-devel implementation-hackers iolib-announce iolib-devel ip-interfaces-devel isidorus-devel kpax-devel l-math-announce l-math-devel langutils-devel lgtk-devel lift-devel linedit-cvs linedit-devel lisp-interface-library-devel lisp-machine lispbox-cvs lispbox-devel lisplab-cvs lisplab-devel lisppaste-devel lisppaste-requests lispy-devel lmud-devel local-time-devel mel-base-devel metabang-bind-devel metacopy-devel metatilities-base-devel mit-cadr-cvs mod-lisp-devel movitz-devel names-and-paths-devel nixies-devel noctool-cvs oct-cvs oct-ticket pal-devel parenscript-announce pg-devel plexippus-xpath-devel protobuf-devel python-on-lisp-devel rfc2388-cvs rucksack-cvs rucksack-devel s-xml-devel sicl-announce sicl-devel slime-cvs snow-announce snow-cvs snow-devel spray-devel teepeedee2-devel the-feebs-war-devel tinaa-devel travisci trivial-backtrace-devel trivial-gray-streams-devel trivial-utf-8-devel uri-template-devel usocket-announce usocket-ticket vivace-graph-devel web4r-devel web4r-devel-ja xcvb-devel xuriella-devel zip-devel
Hi
I can see the rationale about the proposed decommissioning (I see a few ml of mine in the list).
Maybe it'd be a good time to review the lists that get associated with a project too? It used to be that project-help, project-devel and project-announce were pretty much always there. I see many -devel in the list; but maybe these are for "stable" (which may also mean "stable as a corpse" :) ) projects which do not get much development these days?
Marco
On Thu, Jul 13, 2023 at 1:24 PM Erik Huelsmann ehuels@gmail.com wrote:
All,
As part of the migration from Mailman2 to Mailman3, I have checked which lists are actively used. The outcome allows for some rigorous cleanup.
Out of 236 mailing lists, 180 have not had a mail added to their archives *over the last 5 years(!)*. My proposal is to decommission these mailing lists, meaning that only the archives will be migrated to Mailman3. These mailing lists can always be re-instated at a later time.
Rationale for this clean-up is that some owners of the mailing lists have fallen out of contact, causing additional work to fall on the shoulders of the site maintainers: mailing lists require moderation of non-member posts, where those moderation requests which can't be delivered to the list owner, are sent to the site admins. Additionally, unused mailing lists may accrue spam mail in their archives, lowering the value of the archive. (Temporarily) Closing mailing lists can prevent this.
What do you think?
It concerns these lists:
alexandria-cvs anaphora-cvs anaphora-devel ansi-test-cvs ansi-test-devel armedbear-announce armedbear-cvs asdf-install-devel asdf-packaging-announce aspiwork-pdm-cvs aspiwork-pdm-devel bese-devel bordeaux-threads-announce bordeaux-threads-ticket boston-lisp-announce boston-lisp-organizers cello-devel cells-gtk-devel cffi-objects-cvs cl-berkeley-db-devel cl-bzip2-devel cl-containers-devel cl-dbf-cvs cl-dwim-devel cl-ec2-devel cl-emb-devel cl-facebook-devel cl-fuse-devel cl-glpk-devel cl-graph-devel cl-gsl-devel cl-gtk2-devel cl-heap-announce cl-jpeg-devel cl-json-announce cl-kanren-trs-cvs cl-kanren-trs-devel cl-l10n-devel cl-monad-macros-cvs cl-mpi-devel cl-muproc-devel cl-ncurses-devel cl-neo4j-cvs cl-neo4j-devel cl-openid-devel cl-openid-ticket cl-org-mode-devel cl-pdf-announce cl-pdf-devel cl-perec-devel cl-plus-j-announce cl-plus-j-devel cl-plus-ssl-cvs cl-plus-ssl-devel cl-pop-devel cl-proc-devel cl-sbml-cvs cl-selenium-devel cl-smtp-devel cl-soap-devel cl-sqlite-announce cl-sqlite-devel cl-store-devel cl-table-cvs cl-twitter-devel cl-typesetting-announce cl-typesetting-devel cl-unification-devel cl-utilities-devel cl-walker-devel cl-xmlspam-devel cl-xmpp-devel cl-yacc-ebnf-devel clbuild-devel cldoc-devel cleric-announce cleric-devel clfswm-announce clfswm-cvs clfswm-devel climacs-devel climplayer-devel clonsigna-announce clonsigna-devel closer-announce closer-devel clouchdb-cvs clouchdb-devel clsql-fluid-devel clx-devel cmucl-ticket common-lisp-beginner-cvs de-setf-amqp-cvs definer-announce docudown-devel eager-future-devel ecl-readline-devel eclipse-devel editor-hints-devel elephant-devel elephant-ticket f2cl-ticket fetter-devel fiveam-announce fset-devel gecol-devel ginseng-cvs gsharp-devel gtk-cffi-cvs gtk-cffi-devel heresy-devel implementation-hackers iolib-announce iolib-devel ip-interfaces-devel isidorus-devel kpax-devel l-math-announce l-math-devel langutils-devel lgtk-devel lift-devel linedit-cvs linedit-devel lisp-interface-library-devel lisp-machine lispbox-cvs lispbox-devel lisplab-cvs lisplab-devel lisppaste-devel lisppaste-requests lispy-devel lmud-devel local-time-devel mel-base-devel metabang-bind-devel metacopy-devel metatilities-base-devel mit-cadr-cvs mod-lisp-devel movitz-devel names-and-paths-devel nixies-devel noctool-cvs oct-cvs oct-ticket pal-devel parenscript-announce pg-devel plexippus-xpath-devel protobuf-devel python-on-lisp-devel rfc2388-cvs rucksack-cvs rucksack-devel s-xml-devel sicl-announce sicl-devel slime-cvs snow-announce snow-cvs snow-devel spray-devel teepeedee2-devel the-feebs-war-devel tinaa-devel travisci trivial-backtrace-devel trivial-gray-streams-devel trivial-utf-8-devel uri-template-devel usocket-announce usocket-ticket vivace-graph-devel web4r-devel web4r-devel-ja xcvb-devel xuriella-devel zip-devel
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
On 7/13/23 04:23, Erik Huelsmann wrote:
cmucl-ticket
I guess this and other -ticket lists were created for Trac. I guess gitlab doesn't automatically send emails from the issue tracker to any mailing list? I've forgotten how this works, but I'd like to keep this and have gitlab send issues to this mailing list.
I'm also surprised that cmucl-devel and cmucl-help aren't here. These lists (and cmucl-announce) are still on cons.org, but we really wanted to move them to c-l.net, including the mailing list archives. We haven't been able to get a hold of the cons.org owner to get the necessary info. :-(
f2cl-ticket
oct-cvs oct-ticket
I'd like to keep the above. I haven't worked too much on f2cl or oct in a while, but they're not dead; they just work well enough for me now. I guess the burden is on me to have these projects send issue and git emails to the right mailing list.
And thank you so much for getting this all updated!
Hi Raymond,
On Thu, Jul 13, 2023 at 3:36 PM Raymond Toy toy.raymond@gmail.com wrote:
On 7/13/23 04:23, Erik Huelsmann wrote:
cmucl-ticket
I guess this and other -ticket lists were created for Trac. I guess gitlab doesn't automatically send emails from the issue tracker to any mailing list? I've forgotten how this works, but I'd like to keep this and have gitlab send issues to this mailing list.
The commit messages are being sent to an e-mail address (which can be a mailing list) due to project configuration. Maybe that's an option for issue updates too. Not sure.
I'm also surprised that cmucl-devel and cmucl-help aren't here.
Neither of these exist on common-lisp.net, or at least, not if I have to go by https://mailman.common-lisp.net/listinfo. There *is* an archive for cmucl-help@common-lisp.net, but no trace of cmucl-devel@common-lisp.net (there is cmucl-imp@common-lisp.net, though).
These lists (and cmucl-announce) are still on cons.org, but we really wanted to move them to c-l.net, including the mailing list archives.
We'll be happy to host them!
We haven't been able to get a hold of the cons.org owner to get the necessary info. :-(
Hmm. that's too bad. Is that something you need a hand with? We could ask the CLF to contact that person (don't know who it is, so no idea what I'm up against...)
f2cl-ticket
oct-cvs oct-ticket
I'd like to keep the above. I haven't worked too much on f2cl or oct in a while, but they're not dead; they just work well enough for me now.
Mind if I migrate these to mailman3 now then? Once migrated, I won't be looking at them anymore and they're very low volume anyway, so migrating now won't interfere with on-going fierce discussions :-)
I guess the burden is on me to have these projects send issue and git emails to the right mailing list.
Yep. But it should be straight forward, at least for the commit mails. It's even documented in the site FAQ: https://common-lisp.net/faq/emailonpush
Regards,
Erik.
On 7/13/23 12:51, Erik Huelsmann wrote:
Hi Raymond,
On Thu, Jul 13, 2023 at 3:36 PM Raymond Toy toy.raymond@gmail.com wrote:
On 7/13/23 04:23, Erik Huelsmann wrote: > > cmucl-ticket I guess this and other -ticket lists were created for Trac. I guess gitlab doesn't automatically send emails from the issue tracker to any mailing list? I've forgotten how this works, but I'd like to keep this and have gitlab send issues to this mailing list.The commit messages are being sent to an e-mail address (which can be a mailing list) due to project configuration. Maybe that's an option for issue updates too. Not sure.
Yeah, I'll have to dig through the gitlab docs to see how to do that. It's always kind of hard to find it.
I'm also surprised that cmucl-devel and cmucl-help aren't here.Neither of these exist on common-lisp.net http://common-lisp.net, or at least, not if I have to go by https://mailman.common-lisp.net/listinfo. There *is* an archive for cmucl-help@common-lisp.net, but no trace of cmucl-devel@common-lisp.net (there is cmucl-imp@common-lisp.net, though).
Oops. I meant cmucl-imp, not cmucl-devel. The existing cmucl-help and cmucl-imp were created when cmucl moved to c-l.net, but we never actually moved the cons.org lists here.
> f2cl-ticket > > oct-cvs > oct-ticket > I'd like to keep the above. I haven't worked too much on f2cl or oct in a while, but they're not dead; they just work well enough for me now.Mind if I migrate these to mailman3 now then? Once migrated, I won't be looking at them anymore and they're very low volume anyway, so migrating now won't interfere with on-going fierce discussions :-)
Go for it!
Again, thanks for updating the mailing lists.
I guess the burden is on me to have these projects send issue and git emails to the right mailing list.Yep. But it should be straight forward, at least for the commit mails. It's even documented in the site FAQ: https://common-lisp.net/faq/emailonpush
Haha! It even uses cmucl as the example. I had forgotten about this page. :-)
On Thu, Jul 13, 2023 at 10:36 PM Raymond Toy toy.raymond@gmail.com wrote:
f2cl-ticket
oct-cvs oct-ticket
I'd like to keep the above. I haven't worked too much on f2cl or oct in a while, but they're not dead; they just work well enough for me now.
Mind if I migrate these to mailman3 now then? Once migrated, I won't be looking at them anymore and they're very low volume anyway, so migrating now won't interfere with on-going fierce discussions :-)
Go for it!
Done.
Hi,
First of all, Erik, thank you for mustering the energy to take care of this migration and inventorying of the lists. Does anyone volunteer to be part of a Mailing Lists Working Committee which can make a point of periodically inventorying and auditing these lists for spam, active moderators, etc? You would get all the technical support you need.
I note that some of these are still very much active projects but they've scattered elsewhere over the years, for example cl-pdf hosts their code at github and appears to communicate pretty much exclusively through github Issues. Even some active projects hosted at our own gitlab may be communicating through gitlab Issues or other means and thus not register any mailing list traffic through our mailman.
Anyway, if none of a particular project's mailing lists have been active in several years, then it's difficult to make any case for keeping said list active, in the face of the overhead costs Erik mentions, especially if they can be re-activated easily when needed. However, in the Common Lisp space-time continuum, five years is not all that long. I'd be curious what the numbers look like if you go back eight or even 10 years?
Erik, did you say that you sent verification emails to the list owners of these lists? Is the list owner by definition the only moderator, or can they assign other moderators? As I understand it, we can detect non-responsive moderators by seeing mails bounce to an admin account, is that right? If so, how can volunteers sign up to be privvy to those bounced mails and perhaps help to mitigate? Is that just another list to sign up for through the mailman3 web page?
One other question for Erik - are these active lists and archives publicly crawl-able? Because that brings up the whole question of what is CLF's position on serving up for free such content, which is under the stewardship of clnet infrastructure, to all comers, including the slew of neural net training hoovers which now apparently a permanent feature of life online. But that's a discussion for a different thread.
Thanks again!
Dave
On Thu, Jul 13, 2023 at 7:24 AM Erik Huelsmann ehuels@gmail.com wrote:
All,
As part of the migration from Mailman2 to Mailman3, I have checked which lists are actively used. The outcome allows for some rigorous cleanup.
Out of 236 mailing lists, 180 have not had a mail added to their archives *over the last 5 years(!)*. My proposal is to decommission these mailing lists, meaning that only the archives will be migrated to Mailman3. These mailing lists can always be re-instated at a later time.
Rationale for this clean-up is that some owners of the mailing lists have fallen out of contact, causing additional work to fall on the shoulders of the site maintainers: mailing lists require moderation of non-member posts, where those moderation requests which can't be delivered to the list owner, are sent to the site admins. Additionally, unused mailing lists may accrue spam mail in their archives, lowering the value of the archive. (Temporarily) Closing mailing lists can prevent this.
What do you think?
It concerns these lists:
alexandria-cvs anaphora-cvs anaphora-devel ansi-test-cvs ansi-test-devel armedbear-announce armedbear-cvs asdf-install-devel asdf-packaging-announce aspiwork-pdm-cvs aspiwork-pdm-devel bese-devel bordeaux-threads-announce bordeaux-threads-ticket boston-lisp-announce boston-lisp-organizers cello-devel cells-gtk-devel cffi-objects-cvs cl-berkeley-db-devel cl-bzip2-devel cl-containers-devel cl-dbf-cvs cl-dwim-devel cl-ec2-devel cl-emb-devel cl-facebook-devel cl-fuse-devel cl-glpk-devel cl-graph-devel cl-gsl-devel cl-gtk2-devel cl-heap-announce cl-jpeg-devel cl-json-announce cl-kanren-trs-cvs cl-kanren-trs-devel cl-l10n-devel cl-monad-macros-cvs cl-mpi-devel cl-muproc-devel cl-ncurses-devel cl-neo4j-cvs cl-neo4j-devel cl-openid-devel cl-openid-ticket cl-org-mode-devel cl-pdf-announce cl-pdf-devel cl-perec-devel cl-plus-j-announce cl-plus-j-devel cl-plus-ssl-cvs cl-plus-ssl-devel cl-pop-devel cl-proc-devel cl-sbml-cvs cl-selenium-devel cl-smtp-devel cl-soap-devel cl-sqlite-announce cl-sqlite-devel cl-store-devel cl-table-cvs cl-twitter-devel cl-typesetting-announce cl-typesetting-devel cl-unification-devel cl-utilities-devel cl-walker-devel cl-xmlspam-devel cl-xmpp-devel cl-yacc-ebnf-devel clbuild-devel cldoc-devel cleric-announce cleric-devel clfswm-announce clfswm-cvs clfswm-devel climacs-devel climplayer-devel clonsigna-announce clonsigna-devel closer-announce closer-devel clouchdb-cvs clouchdb-devel clsql-fluid-devel clx-devel cmucl-ticket common-lisp-beginner-cvs de-setf-amqp-cvs definer-announce docudown-devel eager-future-devel ecl-readline-devel eclipse-devel editor-hints-devel elephant-devel elephant-ticket f2cl-ticket fetter-devel fiveam-announce fset-devel gecol-devel ginseng-cvs gsharp-devel gtk-cffi-cvs gtk-cffi-devel heresy-devel implementation-hackers iolib-announce iolib-devel ip-interfaces-devel isidorus-devel kpax-devel l-math-announce l-math-devel langutils-devel lgtk-devel lift-devel linedit-cvs linedit-devel lisp-interface-library-devel lisp-machine lispbox-cvs lispbox-devel lisplab-cvs lisplab-devel lisppaste-devel lisppaste-requests lispy-devel lmud-devel local-time-devel mel-base-devel metabang-bind-devel metacopy-devel metatilities-base-devel mit-cadr-cvs mod-lisp-devel movitz-devel names-and-paths-devel nixies-devel noctool-cvs oct-cvs oct-ticket pal-devel parenscript-announce pg-devel plexippus-xpath-devel protobuf-devel python-on-lisp-devel rfc2388-cvs rucksack-cvs rucksack-devel s-xml-devel sicl-announce sicl-devel slime-cvs snow-announce snow-cvs snow-devel spray-devel teepeedee2-devel the-feebs-war-devel tinaa-devel travisci trivial-backtrace-devel trivial-gray-streams-devel trivial-utf-8-devel uri-template-devel usocket-announce usocket-ticket vivace-graph-devel web4r-devel web4r-devel-ja xcvb-devel xuriella-devel zip-devel
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
Hi Dave,
I note that some of these are still very much active projects but they've
scattered elsewhere over the years, for example cl-pdf hosts their code at github and appears to communicate pretty much exclusively through github Issues. Even some active projects hosted at our own gitlab may be communicating through gitlab Issues or other means and thus not register any mailing list traffic through our mailman.
Absolutely. Not suggesting we should clean out any projects on c-l.net in any way, even the code archives present historical value. The mailing lists are just one aspect of our hosting infrastructure for projects.
Anyway, if none of a particular project's mailing lists have been active in several years, then it's difficult to make any case for keeping said list active, in the face of the overhead costs Erik mentions, especially if they can be re-activated easily when needed. However, in the Common Lisp space-time continuum, five years is not all that long. I'd be curious what the numbers look like if you go back eight or even 10 years?
If we go back 8 years the answer is 156 instead of 180. Going back 10 years with the approach that I took isn't so easy, because I was using the timestamps from the filesystem to assert the age of the archive files, but apparently the content of the filesystem has been cleanly set up between 8 and 10 years ago, because the number drops to 0 for 10 years.
Erik, did you say that you sent verification emails to the list owners of these lists?
To announce closing the list, you mean? No, not yet. The mails that go to the owners are mails that request moderation of non-member postings to the list. When those moderation requests bounce, the site owner gets notified, requiring action from the infrastructure team.
Is the list owner by definition the only moderator, or can they assign other moderators?
Moderators and owners are different roles that can be held by different (groups) of people (e-mail addresses, really). Lacking moderators, moderation requests go to the owners.
As I understand it, we can detect non-responsive moderators by seeing mails
bounce to an admin account, is that right?
That's correct. Currently that account is (I think) admin@common-lisp.net.
If so, how can volunteers sign up to be privvy to those bounced mails and perhaps help to mitigate? Is that just another list to sign up for through the mailman3 web page?
Not sure if creating a mailing list for this purpose would work, but it would definitely be an interesting use-case for a mailing list! At the moment, each mailing list has its own set of moderators, though.
One other question for Erik - are these active lists and archives publicly crawl-able?
See https://mailman3.common-lisp.net/hyperkitty/?sort=popular&page=1 ; the HEAD tag contains a tag saying it's both indexable and followable. So, yes: it's crawlable.
In the old archive, this page: https://mailman.common-lisp.net/pipermail/able-cvs/ is marked "no index" but "follow", so it will have its target pages indexed.
Hi Erik,
I'd like to keep iolib-devel and possibly fset-devel (even if I don't own it it's an important project).
Cheers, Stelian
All,
As part of the migration from Mailman2 to Mailman3, I have checked which lists are actively used. The outcome allows for some rigorous cleanup.
Out of 236 mailing lists, 180 have not had a mail added to their archives *over the *last 5 years(!)**. My proposal is to decommission these mailing lists, meaning that only the archives will be migrated to Mailman3. These mailing lists can always be re-instated at a later time.
Rationale for this clean-up is that some owners of the mailing lists have fallen out of contact, causing additional work to fall on the shoulders of the site maintainers: mailing lists require moderation of non-member posts, where those moderation requests which can't be delivered to the list owner, are sent to the site admins. Additionally, unused mailing lists may accrue spam mail in their archives, lowering the value of the archive. (Temporarily) Closing mailing lists can prevent this.
What do you think?
It concerns these lists:
alexandria-cvs anaphora-cvs anaphora-devel ansi-test-cvs ansi-test-devel armedbear-announce armedbear-cvs asdf-install-devel asdf-packaging-announce aspiwork-pdm-cvs aspiwork-pdm-devel bese-devel bordeaux-threads-announce bordeaux-threads-ticket boston-lisp-announce boston-lisp-organizers cello-devel cells-gtk-devel cffi-objects-cvs cl-berkeley-db-devel cl-bzip2-devel cl-containers-devel cl-dbf-cvs cl-dwim-devel cl-ec2-devel cl-emb-devel cl-facebook-devel cl-fuse-devel cl-glpk-devel cl-graph-devel cl-gsl-devel cl-gtk2-devel cl-heap-announce cl-jpeg-devel cl-json-announce cl-kanren-trs-cvs cl-kanren-trs-devel cl-l10n-devel cl-monad-macros-cvs cl-mpi-devel cl-muproc-devel cl-ncurses-devel cl-neo4j-cvs cl-neo4j-devel cl-openid-devel cl-openid-ticket cl-org-mode-devel cl-pdf-announce cl-pdf-devel cl-perec-devel cl-plus-j-announce cl-plus-j-devel cl-plus-ssl-cvs cl-plus-ssl-devel cl-pop-devel cl-proc-devel cl-sbml-cvs cl-selenium-devel cl-smtp-devel cl-soap-devel cl-sqlite-announce cl-sqlite-devel cl-store-devel cl-table-cvs cl-twitter-devel cl-typesetting-announce cl-typesetting-devel cl-unification-devel cl-utilities-devel cl-walker-devel cl-xmlspam-devel cl-xmpp-devel cl-yacc-ebnf-devel clbuild-devel cldoc-devel cleric-announce cleric-devel clfswm-announce clfswm-cvs clfswm-devel climacs-devel climplayer-devel clonsigna-announce clonsigna-devel closer-announce closer-devel clouchdb-cvs clouchdb-devel clsql-fluid-devel clx-devel cmucl-ticket common-lisp-beginner-cvs de-setf-amqp-cvs definer-announce docudown-devel eager-future-devel ecl-readline-devel eclipse-devel editor-hints-devel elephant-devel elephant-ticket f2cl-ticket fetter-devel fiveam-announce fset-devel gecol-devel ginseng-cvs gsharp-devel gtk-cffi-cvs gtk-cffi-devel heresy-devel implementation-hackers iolib-announce iolib-devel ip-interfaces-devel isidorus-devel kpax-devel l-math-announce l-math-devel langutils-devel lgtk-devel lift-devel linedit-cvs linedit-devel lisp-interface-library-devel lisp-machine lispbox-cvs lispbox-devel lisplab-cvs lisplab-devel lisppaste-devel lisppaste-requests lispy-devel lmud-devel local-time-devel mel-base-devel metabang-bind-devel metacopy-devel metatilities-base-devel mit-cadr-cvs mod-lisp-devel movitz-devel names-and-paths-devel nixies-devel noctool-cvs oct-cvs oct-ticket pal-devel parenscript-announce pg-devel plexippus-xpath-devel protobuf-devel python-on-lisp-devel rfc2388-cvs rucksack-cvs rucksack-devel s-xml-devel sicl-announce sicl-devel slime-cvs snow-announce snow-cvs snow-devel spray-devel teepeedee2-devel the-feebs-war-devel tinaa-devel travisci trivial-backtrace-devel trivial-gray-streams-devel trivial-utf-8-devel uri-template-devel usocket-announce usocket-ticket vivace-graph-devel web4r-devel web4r-devel-ja xcvb-devel xuriella-devel zip-devel
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
-- Stelian Ionescu
Hi Stelian,
On Fri, Jul 14, 2023 at 4:52 AM Stelian Ionescu sionescu@cddr.org wrote:
I'd like to keep iolib-devel and possibly fset-devel (even if I don't own it it's an important project).
I've migrated these so they can't be skipped in a larger migration. For maximum clarity, though: even where mailing lists aren't migrated, the associated projects will continue to exist on common-lisp.net.
Hi Erik,
parenscript-announce
should be kept for future releases.
Thank you. -- Vladimir Sedach
On Fri, Jul 14, 2023 at 8:59 PM Vladimir Sedach vas@oneofus.la wrote:
parenscript-announce
Ok. Migrated to Mailman3. Thanks for the reply!
-
Dave Cooper -
Erik Huelsmann -
Marco Antoniotti -
Raymond Toy -
Stelian Ionescu -
Vladimir Sedach