clo-devel February 2015

clo-devel@common-lisp.net

11 participants
17 discussions

[clo-devel] Resigning as c-l.net administrator
by Hans Hübner 08 Apr '15

08 Apr '15

Hi folks, I have decided that after a few years, I do no longer want to be operating common-lisp.net - It was fun, but it is time to move on. I have been dealing with mailman administration (handling bounces, occasional password changes, list creation), and with user and project administration. I will be responding to RT requests until the end of this year. Afterwards, I won't do it anymore. I'll also revoke my own root access. If anyone reading this wants to seize responsibility and get some guidance from me, let me know. Cheers, Hans

6 5

[Clo-devel] IP4 address change
by Mark Evenson 04 Mar '15

04 Mar '15

We’ve recently changed the IP4 address of common-lisp.net. Is this change intended to be permanent? illin:~$ host lisp.not.org lisp.not.org has address 144.76.188.67 lisp.not.org has IPv6 address 2a01:4f8:200:4310::30 illin:~$ host common-lisp.net common-lisp.net has address 148.251.248.130 common-lisp.net has IPv6 address 2a01:4f8:200:4310::30 common-lisp.net mail is handled by 10 mail.common-lisp.net. -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

2 2

[Clo-devel] Proposed organization of projects, groups and members in GitLab for common-lisp.net
by Erik Huelsmann 24 Feb '15

24 Feb '15

Hi, Trying to keep the mail short; sent too many essays already :-) So, some context regarding GitLab's structure: - each project has: + one repository + at most one issue tracker + at most one wiki + at most one snippets archive + at least one member - each group has: + one or more members + zero or more projects - each user: + has zero or more projects + is a member of zero or more groups and/or projects with a certain access level Now, every member of a group is automatically a member of the group's projects. I propose we map common-lisp.net's projects to gitlab's groups since our projects can (and do) have multiple repositories. Since our current projects don't distinguish in access level between project members, we should map access level to the highest available: owner. Our repositories map to GitLab's projects. All GitLab projects are owned by a group if found in the /project filesystem hierarchy. All personal repositories (those found in /home) will be directly owned to users. Users may choose to assign others access rights other than reading. The system's login accounts will map to GitLab users. GitLab group membership will be determined using the current method of project membership: being member of a certain group in the /etc/group file. Then there's one aspect left not discussed: project visibility. All project repositories (those found in the /project hierarchy) will be assigned to public projects. All public user repositories (those found in /home/<user>/public_html/* or those linked from /var/git/projects/users/*) will be assigned public visibility. All other user repositories will be assigned "Internal" visibility (visible only to logged-in users). Comments? -- Bye, Erik. http:// <http://efficito.com/>efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock in.

1 0

[Clo-devel] Unable to clone (permission denied)
by dalevi＠Safe-mail.net 24 Feb '15

24 Feb '15

I don't know if other projects are affected or if asdf somehow stands alone: $ git clone git://common-lisp.net/project/asdf/asdf.git Cloning into 'asdf'... fatal: remote error: access denied or repository not exported: /project/asdf/asdf.git Matthew

3 2

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

clo-devel February 2015