<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body>A new request with request id 15128 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is : <br><br>Title : Koha-devel Digest, Vol 191, Issue 5<br>Category : <br>Description : <div>Send Koha-devel mailing list submissions to<br> koha-devel@lists.koha-community.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>or, via email, send a message with subject or body 'help' to<br> koha-devel-request@lists.koha-community.org<br><br>You can reach the person managing the list at<br> koha-devel-owner@lists.koha-community.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Koha-devel digest..."<br><br><br>Today's Topics:<br><br> 1. Re: Workflow improvement suggestions for security releases<br> (Kyle Hall)<br> 2. Re: Issues fetching from Koha Git due to Let's Encrypt root<br> certificate expiry (Fridolin SOMERS)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Thu, 7 Oct 2021 07:15:43 -0400<br>From: Kyle Hall <kyle.m.hall@gmail.com><br>To: Jonathan Druart <jonathan.druart@bugs.koha-community.org><br>Cc: koha-devel <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] Workflow improvement suggestions for<br> security releases<br>Message-ID:<br> <CACpVHfw8zpDd8B2hkO-fHKOrg1n+Q_efoq-C3BTLb+VB5=-ktg@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>><br>> 1. LTS<br>> I think it's time to have a Long Term Support release. We noticed that<br>> some people are still using very old versions, having a version that<br>> is maintained several years could help them.<br>> We could backport critical security bugs only. 4 (5?) years would be great.<br>><br><br>This has been proposed in the past. The general consensus at the time was<br>that we as a community want to encourage libraries to stay on the latest<br>versions of Koha and not to hang back on older versions.<br>I'm not necessarily opposed, but such a role will require quite a<br>commitment.<br><br><br>> 2. Communication<br>> Once the issues have been reported and fixed, I've alerted the first<br>> cycle of people around me. Their job was to alert a second cycle.<br>> Should we have a list of people we trust? Ask the (general) mailing<br>> list who wants to be in the loop? That means adding them to the<br>> security group on bugzilla (or at least adding them when the bug has a<br>> fix) and CC them when private discussions take place.<br>><br><br>Sounds good!<br><br><br>> 3. Synchronisation<br>> Release maintainers are spread around the world (and timezones suck).<br>> Getting feedback can take time, several days (like: "try", "don't<br>> work", "try again", it's 3 days!).<br>> Then when you plan to release on Wednesday, and things are only ready<br>> on Thursday you need to wait until Monday as part of the world is<br>> still enjoying the weekend!<br>> I don't have a solution for that, apart from the Monday postpone or...<br>> more anticipation.<br>> Same problem for the time of the release, I've picked 12 UTC as the<br>> "most convenient" slot for a release, but it won't (ofc) fit<br>> everybody's needs. My point was that if we communicated enough<br>> beforehand (but not publicly) it should not be a problem.<br>> Let me know if you have ideas to improve that!<br>><br><br>We can already schedule our news posts in advance. Perhaps rmaints should<br>have a non-public area on the ftp server where we could put our tarballs<br>and such, and a cronjob that would automatically move them to the public<br>folder and update the symlinks at 12 UTC every day ( if there are files to<br>move ). I'm not sure how to synchronize the community apt server into this,<br>but I imagine it could be done. If we get into the habit of scheduling<br>everything for release at 12 UTC, security release or not, we can probably<br>get pretty good at it, ironing out the kinks before we have another<br>security release to deal with.<br><br><br>> 4. Infrastructure improvement<br>> We don't have CI/Jenkins for the security repository. We need one!<br>> That must be a top priority of the next cycle. We need to help RMaints<br>> and make the security release process easier and less stressful.<br>><br><br>Agreed!<br><br><br>> 5. Apply patches<br>> We need a script to apply the patches on the different branches,<br>> automatically. That's an easy bit to develop and it will help us a<br>> lot.<br>><br><br>I'm not sure what you mean? Do you mean something that would apply a bug's<br>patch set to say master, stable and oldstable and report on the bug if it<br>doesn't apply to one? Or script in qa-test-tools to do that? Something else<br>entirely?<br><br><br>> 6. More visibility on the status of the patches<br>> RM and RMaints must put their progress on the bug report itself. A<br>> comment "Will be pushed, RM had a look at this" or "Backported for..."<br>> should be added.<br>> That must be added to the "Release process" wiki page.<br>><br><br>Sounds good!<br><br>Kyle<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20211007/57bef723/attachment-0001.htm><br><br>------------------------------<br><br>Message: 2<br>Date: Thu, 7 Oct 2021 20:17:56 -1000<br>From: Fridolin SOMERS <fridolin.somers@biblibre.com><br>To: koha-devel@lists.koha-community.org<br>Subject: Re: [Koha-devel] Issues fetching from Koha Git due to Let's<br> Encrypt root certificate expiry<br>Message-ID: <6112e5a7-1f0c-cf11-a017-c44b15125b9d@biblibre.com><br>Content-Type: text/plain; charset=UTF-8; format=flowed<br><br>Thanks a lot David.<br>This certificate expiry has many huge impacts, like some package <br>repositories acess.<br>Be sure to upgrade all your servers.<br><br>Best regards<br><br>Le 05/10/2021 à 18:56, dcook@prosentient.com.au a écrit :<br>> Hi all,<br>> <br>> Some people might have found they aren’t able to fetch from the Koha Git <br>> (in koha-testing-docker for instance). They might be getting the <br>> following error:<br>> <br>> fatal: unable to access <br>> 'https://git.koha-community.org/Koha-community/Koha.git/': server <br>> certificate verification failed. CAfile: none CRLfile: none<br>> <br>> That seems to be due to the Let’s Encrypt root certificate expiry. I <br>> imagine the latest koha-testing-docker probably doesn’t have this <br>> problem, but if you’re lazy or time poor like me, you can just run the <br>> following to get your existing koha-testing-docker to work again:<br>> <br>> apt-get update<br>> <br>> apt-get install ca-certificates<br>> <br>> Cheers,<br>> <br>> David Cook<br>> <br>> Senior Software Engineer<br>> <br>> Prosentient Systems<br>> <br>> Suite 7.03<br>> <br>> 6a Glen St<br>> <br>> Milsons Point NSW 2061<br>> <br>> Australia<br>> <br>> Office: 02 9212 0899<br>> <br>> Online: 02 8005 0595<br>> <br>> <br>> _______________________________________________<br>> Koha-devel mailing list<br>> Koha-devel@lists.koha-community.org<br>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>> website : https://www.koha-community.org/<br>> git : https://git.koha-community.org/<br>> bugs : https://bugs.koha-community.org/<br>> <br><br>-- <br>Fridolin SOMERS <fridolin.somers@biblibre.com><br>Software and system maintainer 🦄<br>BibLibre, France<br><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>Koha-devel mailing list<br>Koha-devel@lists.koha-community.org<br>https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>website : https://www.koha-community.org/<br>git : https://git.koha-community.org/<br>bugs : https://bugs.koha-community.org/<br><br><br>------------------------------<br><br>End of Koha-devel Digest, Vol 191, Issue 5<br>******************************************<br></div><br><br>NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.<br></body></html>