- clo-devel - mailman3.common-lisp.net

[Clo-devel] Last test, confirmation.
by Erik Huelsmann 20 Feb '15

20 Feb '15

Regards, Erik.

1 0

[Clo-devel] Test to check mail headers
by Erik Huelsmann 20 Feb '15

20 Feb '15

Sorry I had to send a mail to one of the common-lisp.net mailing lists to check whether the X-List-Archive header gets through correctly now. Regards, Erik.

1 0

[Clo-devel] Intended policy changes for mailing list setup
by Erik Huelsmann 19 Feb '15

19 Feb '15

Dear common-lisp.net users, mailing list owners, You're receiving this message because you're listed as a mailing list owner or because you have a common-lisp.net login account. If you have different mail addresses associated with both, you may get multiple copies. Apologies for that in advance. We're sending this mail to announce policy changes intended to be executed as of March 15th regarding mailing list setup. [For further discussion, please direct to clo-devel(a)common-lisp.net.] Changes to mailing list headers and footer ========================================== Google is tightening their DKIM validation; most of our mailing lists cause invalid DKIM signatures on out-going mails: * Adding the Subject prefix '[<mailing list>]' invalidates the DKIM signature of the original sender * Adding the e-mail footer may invalidate the e-mail's DKIM signature Since Google, Yahoo! and other big mail providers are moving to signing their outgoing mail, the percentage of invalid mail sent by common-lisp.net increases. This hurts our reputation as a mail sender and has led to problems with Google accepting common-lisp.net mail. (Admitted, DKIM was not the only reason.) Due to the above, we will change the mailing list setup for all mailing lists: * No longer add the mailing list subject prefix * No longer add the mailing list footer * Add the List-* headers as per RFC-2369, filtering of mailing list messages can be done using these fields Change to moderation expiration ======================== Additionally, we've found that many mailing lists have been set to not expire mails in the moderation queue, resulting in a moderation queue of 10-thousands of mails some more than 8 months old. Recognizing most of these mails are probably not being moderated because they are spam, we intend to change all mailing lists which do not expire their moderation queue to expire moderation requests after 90 days. Again, the above is an intended policy change. Please send feedback on clo-devel(a)common-lisp.net. Kind regards, common-lisp.net admins

2 1

[Clo-devel] Follow up to "proposed direction for common-lisp.net in 2015" -- the steps
by Erik Huelsmann 16 Feb '15

16 Feb '15

Hi everybody, As a follow-up to the changes that I proposed for common-lisp.net to be implemented over the course of 2015 [ https://mailman.common-lisp.net/pipermail/clo-devel/2015-February/000161.ht…] I've been looking at the more detailed steps to be executed to implement the proposal. Remember that the changes are targetting a more modern, but also a simplified (for users *and* admins) system. It's an investment, but one in simpler maintenance while improving user experience. Currently, I'm thinking that the steps (no timing yet) should be: 0. Install a Code Commenting plugin on Trac to make it match the GitLab code commenting capabilities 1. Finish my experiments regarding the GitLab setup / installation 2. Install GitLab on common-lisp.net (under the gitlab.common-lisp.net domain? or should we prefer git.common-lisp.net?) 3. Run the migration to create all users and groups in GitLab --> do we want all project which we know *don't* use Git to be created in GitLab too? 4. Import the CMUCL git repositories (using the script to be used for all projects) 5. Run a trial period of 2 months with Raymond Toy and CMUCL to iron out any unnoticed issues 6. Import the user's git repositories 7. Import all other projects with Git repositories 8. Turn off gitweb --> introduce rewrite rules to point to gitlab 9. Turn off git plugin for Trac --> introduce rewrite rules to point to gitlab 10. Turn off git-daemon (fully depend on https checkouts) 11. Convert all project darcs repositories to git --> Notify all darcs project owners before we do about a planning/timing 12. Import the converted darcs repositories 13. Convert users' darcs repositories --> Notify all darcs users before we do about a planning/timing 14. Import converted users' darcs repositories 15. Turn off darcsweb webbrowsing --> introduce rewrite rules to point to gitlab 16. Contact CVS repository owners to ask if they want to migrate to Subversion or Git --> Which do we default to in case of no answer? 17. Convert CVS repositories to Subversion (where requested / defaulted) 18. Convert CVS repositories to Git (where requested / defaulted) 19. Import git-converted CVS repositories 20. Turn off ViewVC (Subversion & CVS) web-browsing --> introduce rewrite rules to point to gitlab/Trac 21. Turn off cvsd and related cron jobs 22. Turn off svnserve (fully depend on https checkouts) "Import git repository" here means "move into gitlab space", which means the user will *only* be able to access the repository through GitLab's access methods (HTTPS and SSH(git user)) . Before we go to that step, we'll probably need to announce this step to all users who have git repositories in their home directories. (So they can object to the move -- if they do, the repository won't be moved, but we *will* scrap gitweb and git-daemon...) Every step which says "Import" or "Convert" entails the creation (and testing) of a scripted procedure, as far as I'm concerned. Some steps will necessarily be executed in sequence. However some parts may be executed in parallel (e.g. contacting users about preferences and developing the scripted procedure). I'm hoping that when I sign up for this task, others pick up the rest of the work that relates to cl-net, such as fixing the mailing list archives or getting OAuth working for both Trac and GitLab (assuming we want that; do we?). The order above is explicitly selected to benefit as soon as possible from having GitLab up and running, with namespaces reserved (hence the full group and user creation right at the start), but possibly unused at first (due to later imports of projects and repositories). I'm not completely sure about steps 10 and 22; if we can make step 10 work, I'm inclined to research if we can keep step 22 as well. So, judging by the number of steps to be executed, this may take all year, with one or two steps every month. I don't have a problem with that, though thought it'd be good to set expectations. So, apart from the fact that it looks like an enormous amount of work, what are your comments? (Note that I see this as a consequence of years and years maintenance backlog; so, it's not something that I expect to be solved in a day or two.) -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

5 7

[Clo-devel] mit-cadr-cvs mailing list
by Robert Swindells 11 Feb '15

11 Feb '15

Please could the admin password for mit-cadr-cvs be reset and the new one sent to me. Robert Swindells

2 1

[Clo-devel] Lost contact details of mailing list owners
by Erik Huelsmann 10 Feb '15

10 Feb '15

Hi, As to be expected when a site passes a certain age, people originally active in a community first go silent and then drop out of sight. No problem, of course. If the positions they filled are still very much desired to be filled by the community, it's good to identify that they are out of reach and find either their current contact data or to replace them with people up for the task. To identify the state of affairs with respect to common-lisp.net, I've created a list of mailing lists of which we're aware we don't have contact details. The list can be found at https://common-lisp.net/orphaned-mailing-lists/ Please check the list for your favorite mailing list or your own name! -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

Re: [Clo-devel] Proposed direction for common-lisp.net in 2015
by Andrew Kirkpatrick 07 Feb '15

07 Feb '15

Hi Erik, Thanks for the welcome. To clarify, common-lisp.net is a valuable resource already and it provides repo hosting, so they aren't necessarily incompatible, but I worry that maintaining and improving the services that are available elsewhere comes at an opportunity cost that seems all the greater due to the small size of the CL community. Of course, there's a lot of history and context I'm missing, that's just my take as a relative outsider. I joined this list a week or so ago to ask how to clone a hosted repo. I could see the gitweb but there was no clone url provided. I was about to write to the list when, on reading another thread I saw a clone url for a different project and worked out the required transform from project to git url. I'd be happy to look into how CL resources are and could be indexed. Though time is always limited, happily CL is now my day job so I hope to become a more effective user of the language this year. BTW my email to you and the list bounced from the list. The uribl service said that one of the urls in the email was rejected, but I've entered all of them into the uribl site and they are either unknown or whitelisted. I hope this message gets through. Cheers, Andy On 7 February 2015 at 09:00, Erik Huelsmann <ehuels(a)gmail.com> wrote: > Hi Andrew, > > Thank you for responding! > > On Fri, Feb 6, 2015 at 4:10 PM, Andrew Kirkpatrick <ubermonk(a)gmail.com> > wrote: >> >> Hi Erik, >> >> I'm new to this list and haven't requested any further access to the >> services you linked to. > > > Welcome! Hope you find your way around soon. Your opinion as a potential > user is just as important as one of long-time users: if we succeed to > convert potential users into actual users, we're achieving the goal of > supporting the Common Lisp community, I'd hope. > >> >> Coming from the Perl world, what I'd like to >> see is something like MetaCPAN https://metacpan.org > > > I love metacpan indeed and I like how it uses the META.yml file to generate > a lot of information. I'm not sure if the ASDF files that are currently > around have enough information in them to be useful in this respect. > However, it would definitely seem like something to stimulate in library > authors to add the "required" elements to the ASDF files. > >> It is essentially a nice web interface and index to a bunch of >> services, most of which exist independently. > > >> A large number of Perl >> modules use github for repository hosting, some use bitbucket or >> otherwise. > > > Right. In Common Lisp it's no different these days. > >> >> For issue tracking, some use the official Perl >> RequestTracker instance, others use github or bitbucket. Testing >> happens both via the Perl testers network and TravisCI on github. > > > For issue tracking, there's no central "standard" that projects use in > Common Lisp: some have a BUGS file in the root of their development tree, > others use launchpad, github or trac.common-lisp.net. As for CI, there's > really no CI for individual projects within the Common Lisp community at the > moment, although I know Zach Beane - maintainer of quicklisp - runs daily > builds for the entire quicklisp world. Those are - as far as I understand - > just builds. Not test suites. > >> >> What enables this is the CPAN::Meta spec, which is reminiscent of >> ASDF: https://metacpan.org/pod/CPAN::Meta::Spec >> >> Gitlab is nice enough but it can be a pain to administer (I crashed a >> local install recently with a not-so-unusual construct in an Org >> format readme file). > > > Ok. Thanks for the warning :-) However, currently we have a lot of > git/darcs/hg/cvs/svn repositories on a host with very little structure on > the DVCS side of things. Even to the extent that Marco Antoniotti seems to > have been working more than a month to migrate a project of his to Git and > get common-lisp.net services working with it. One of the reasons behind this > proposal is to increase the value of common-lisp.net to projects as well as > new-comers like you: if there's more structure, it's easier to document for > the site's maintainers how things work and for project owners to contribute > to multiple projects and for newcomers to find the projects they want to > contribute to. > >> I guess my question is, what if the site just focused on the core >> business of being an index to a federated community of resources? > > > I think your idea is perfect. We don't have such an index yet; we do have > similar "services which exist independently": Quicklisp, Quickdocs, > cl-user.net, cliki.net and common-lisp.net to name some. I absolutely do > think there's room for such a meta service in the community. > > Do I understand your suggestion correctly that you see no value in hosting > any kind of code or project on common-lisp.net? Over the past 10 years, > common-lisp.net has been hosting Common Lisp projects, providing them > more-or-less with the services they needed. Due to the number of projects > being hosted on the infrastructure it also became more-or-less of an index. > However, the more-or-less-index roles can also be claimed by cliki.net and > cl-user.net. > > While there is absolutely an opportunity to grow common-lisp.net with the > meta function, I personally (in the shorter term) only have time to work on > the hugely necessary improvements to be made to common-lisp.net, the current > site and infrastructure itself. The board of the Common Lisp Foundation (the > stewards of the common-lisp.net domain) heartily welcome efforts to support > the use of Common Lisp. Do you feel that you could work on an ASDF based > meta index? > > Next to that, there could be other services for which we think there's room > also room for CI (Continuous Integration) specifically directed at Common > Lisp projects (there's cl-test-grid, which is great, but doesn't provide > continuous integration for individual Common Lisp projects - rather it has > been targetted so far at assessing quality of Quicklisp distributions and > providing feedback thereof to library and implementation developers). > >> Hopefully I haven't offended anyone with these suggestions. > > > Definitely not offended here. I'm glad you took the time to respond. > > -- > Bye, > > Erik. > > http://efficito.com -- Hosted accounting and ERP. > Robust and Flexible. No vendor lock-in.

2 1

Re: [Clo-devel] Proposed direction for common-lisp.net in 2015
by Erik Huelsmann 06 Feb '15

06 Feb '15

Hi Andrew, Thank you for responding! On Fri, Feb 6, 2015 at 4:10 PM, Andrew Kirkpatrick <ubermonk(a)gmail.com> wrote: > Hi Erik, > > I'm new to this list and haven't requested any further access to the > services you linked to. Welcome! Hope you find your way around soon. Your opinion as a potential user is just as important as one of long-time users: if we succeed to convert potential users into actual users, we're achieving the goal of supporting the Common Lisp community, I'd hope. > Coming from the Perl world, what I'd like to > see is something like MetaCPAN https://metacpan.org > I love metacpan indeed and I like how it uses the META.yml file to generate a lot of information. I'm not sure if the ASDF files that are currently around have enough information in them to be useful in this respect. However, it would definitely seem like something to stimulate in library authors to add the "required" elements to the ASDF files. It is essentially a nice web interface and index to a bunch of > services, most of which exist independently. A large number of Perl > modules use github for repository hosting, some use bitbucket or > otherwise. Right. In Common Lisp it's no different these days. > For issue tracking, some use the official Perl > RequestTracker instance, others use github or bitbucket. Testing > happens both via the Perl testers network and TravisCI on github. > For issue tracking, there's no central "standard" that projects use in Common Lisp: some have a BUGS file in the root of their development tree, others use launchpad, github or trac.common-lisp.net. As for CI, there's really no CI for individual projects within the Common Lisp community at the moment, although I know Zach Beane - maintainer of quicklisp - runs daily builds for the entire quicklisp world. Those are - as far as I understand - just builds. Not test suites. > What enables this is the CPAN::Meta spec, which is reminiscent of > ASDF: https://metacpan.org/pod/CPAN::Meta::Spec > > Gitlab is nice enough but it can be a pain to administer (I crashed a > local install recently with a not-so-unusual construct in an Org > format readme file). > Ok. Thanks for the warning :-) However, currently we have a lot of git/darcs/hg/cvs/svn repositories on a host with very little structure on the DVCS side of things. Even to the extent that Marco Antoniotti seems to have been working more than a month to migrate a project of his to Git and get common-lisp.net services working with it. One of the reasons behind this proposal is to increase the value of common-lisp.net to projects as well as new-comers like you: if there's more structure, it's easier to document for the site's maintainers how things work and for project owners to contribute to multiple projects and for newcomers to find the projects they want to contribute to. I guess my question is, what if the site just focused on the core > business of being an index to a federated community of resources? > I think your idea is perfect. We don't have such an index yet; we do have similar "services which exist independently": Quicklisp, Quickdocs, cl-user.net, cliki.net andcommon-lisp.net to name some. I absolutely do think there's room for such a meta service in the community. Do I understand your suggestion correctly that you see no value in hosting any kind of code or project on common-lisp.net? Over the past 10 years, common-lisp.net has been hosting Common Lisp projects, providing them more-or-less with the services they needed. Due to the number of projects being hosted on the infrastructure it also became more-or-less of an index. However, the more-or-less-index roles can also be claimed by cliki.net and cl-user.net. While there is absolutely an opportunity to grow common-lisp.net with the meta function, I personally (in the shorter term) only have time to work on the hugely necessary improvements to be made to common-lisp.net, the current site and infrastructure itself. The board of the Common Lisp Foundation (the stewards of the common-lisp.netdomain) heartily welcome efforts to support the use of Common Lisp. Do you feel that you could work on an ASDF based meta index? Next to that, there could be other services for which we think there's room also room for CI (Continuous Integration) specifically directed at Common Lisp projects (there's cl-test-grid, which is great, but doesn't provide continuous integration for individual Common Lisp projects - rather it has been targetted so far at assessing quality of Quicklisp distributions and providing feedback thereof to library and implementation developers). Hopefully I haven't offended anyone with these suggestions. > Definitely not offended here. I'm glad you took the time to respond. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

[Clo-devel] Proposed direction for common-lisp.net in 2015
by Erik Huelsmann 06 Feb '15

06 Feb '15

Hi all, Over the past months, I've observed a few issues with common-lisp.net in its current state (none of them particularly new, it's just that I now have taken the time to think about them): - Its way of becoming a "member" of the site is very archaic (writing to a mailing list to ask for membership) - The site has adapted badly to the new era of DVCSes: Even for long-time users, it isn't straightforward how to publish new git repositories in a way that web-browsing and http downloading are supported - The site's services use a wide range of non-integrated applications * which need to be set up on every migration (every some 3 years) * easily break in some ways or others due to the sheer number of different services and configurations - Some (many?) functionalities are duplicated - i.e. provided by multiple services An example being Subversion and Git repository web browsing which are provided by Trac and ViewVC/gitweb respectively For a full listing of all currently available (end-user) services hosted on the site, please see http://trac.common-lisp.net/clo/wiki/UserServices . Concluding from the above, due to the evolutionary growth of the site, a large number of services have been instated which are now blocking further development of the site and even blocking the ultimate goals of the site by blocking access for new-comers. Please note that some may argue that the site needs very little maintenance. This is currently true due to the nature of the activity on the site: there are hardly any new users and hardly any activity in terms of new projects being created. The proposal below tries to change that, meaning that maintenance of common-lisp.net *will* require more work from the site/server's maintainers. To address the problems identified above, I'm submitting the following proposal about a new target infrastructure that makes the system both much more user friendly as well as much more maintainer friendly. (a) Structure DVCS hosting by installing [http://gitlab.org/ GitLab] This would mean moving all Git repositories within the management realms of this Git hosting management solution, empowering users to create their own repositories, wiki's, ticket lists, projects, etc. (b) Stop supporting CVS repositories Repositories can be migrated to Git or Subversion, based on project members' preference (c) Stop supporting Darcs repositories Repositories can be migrated to Git By using GitLab, there's a single place for users to search and find all git repositories hosted on the site. They can create their own, both as projects and in their private (but not hidden) namespace. In addition to this (searchable) structure, GitLab provides a consistent interface for services that are currently not even supported (merge/pull requests, commits review and snippets) or available separately (source browsing). The idea is to continue Subversion support because we have active projects using it and because it has HTTP support ("the modern web") as well as active security support. Next to that, with Trac, we can come close to the functionalities offered by GitLab -- a suite of functionalities I consider "complete". The list of changes above means the following benefits for the maintainers: As a consequence of (a), we can: * Stop running gitweb * Stop supporting Trac's 'git' plugin --> GitLab includes repository browsing As a consequence of (b), we can: * Stop running cvsd * Stop running ViewVC --> Repository browsing for Subversion supported through Trac, Git through GitLab As a consequence of (c), we can: * Stop running darcsweb The darcs, hg and cvs binaries will remain available on the common-lisp.net machine, but their use will not be encouraged, nor will there be webbased source browsing or other support. Note that I'm submitting this proposal for discussion -- nothing is set in stone and I'm soliciting your feedback. I'm aware that a more detailed plan and especially timeline will need to follow. There isn't one (yet), because I'd like to know your opinions on this first. Also, even if the feedback on this proposal is positive, things are not going to change over night: the installation of GitLab and the migration of repositories into it, will take some time (especially for the development of the correct migration/seeding scripts/programs). I've asked your feedback, please start feeding back! :-) -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

[Clo-devel] Modern internet mail rules and mailing list Subject rewriting
by Erik Huelsmann 04 Feb '15

04 Feb '15

Hi, Monitoring the mail system, I've found that Google still has us rate limited. Trying to understand why, I've come up with the following reason: Google verifies DKIM as part of their criteria for identifying SPAM. We sign our outgoing mail, so, there shouldn't be a problem. However, some mail *already* has a DKIM signature. Still no problem, but most mailing lists change the Subject: line by prepending the mailing list name. Now *that*'s a problem: it invalidates the pre-existing signature! So, simply strip the old DKIM headers, you might say. That will make the problem go away. Well, in fact it probably doesn't: domains which use DKIM can also state a policy that all mail from the domain should be signed. Stripping the DKIM signature makes the mail invalid with respect to that policy, again triggering the SPAM rules. My conclusion: we have to stop munging the Subject: line in the mailman mailing lists. Any comments? -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

3 3