I gave my Midburn creating an open source community talk in Hacktoberfest 2017 @ Tel Aviv. This is the local version of an initiative by DigitalOcean and GitHub. I was surprised about the vibe both the location and the organizers gave the event, and the fact they could easily arrange t-shirts, pizzas and beer. Looking at the github search, it seem the worldwide event brings many new contributions. I think we have something to learn how to do a mass concept like that. Especially when it crosses both project limits and country limits. (e.g. not a local bug squashing party).
Filed under: Open source businesses

While dealing with d-i s translation last month in FOSScamp, I was kinda surprised it s still on SVN. While reviewing PO files from others, I couldn t select specific parts to commit. Debian does have a git server, and many DDs (Debian Developers) use it for their Debian work, but it s not as public as I wish it to be. Meaning I lack the pull / merge request abilities as well as the review process. Recently I got a reminder that the D-I s Hebrew translation needs some love. I asked my local community for help. Receiving a PO file by mail, reminded me of the SVN annoyance. So this time I decided to convert it to git and ask people to send me pull requests. Another benefit would be making the process more transparent as others could see these PRs (and hopefully comment if needed). For this experiment, I opened a repository on GitHub at https://github.com/kaplanlior/debian-installer I know they aren t open source as GitLab, but they are a popular choice which is a good start for my experiment. If and when it succeeds, we can discuss the platform. (featured image by Jonathan Carter)
Filed under: Debian GNU/Linux

The Document foundation blog have a post about LibreOffice 7th anniversary:

Berlin, September 28, 2017 Today, the LibreOffice community celebrates the 7th anniversary of the leading free office suite, adopted by millions of users in every continent. Since 2010, there have been 14 major releases and dozens of minor ones, fulfilling the personal productivity needs of both individuals and enterprises, on Linux, macOS and Windows.

I wanted to take a moment to remind people that 7 years ago the community decided to make the de facto fork of OpenOffice.org official after life under Sun (and then Oracle) were problematic. From the very first hours the project showed its effectiveness. See my post about LibreOffice first steps. Not to mention what it achieved in the past 7 years. This is still one of my favourite open source contributions, not because it was sophisticated or hard, but because it as about using the freedom part of the free software:
Replace hardcoded product by Oracle with product by %OOOVENDOR . On a personal note, for me, after years of trying to help with OOo l10n for Hebrew and RTL support, things started to go forward in a reasonable pace, getting patches in after years of trying, having upstream fix some of the issues, and actually able doing the translation. We made it to 100% with LibreOffice 3.5.0 in February 2012 (something we should redo soon ).
Filed under: i18n & l10n, Israeli Community, LibreOffice

Part of services of Kaplan open source consulting is recruiting services to help companies find good open source people. In addition, we also try to help the community to find open source friendly businesses to work at. Expect the Usual Suspects (e.g. RedHat), I encounter job descriptions which convince me these companies know the advantages of using open source projects and hiring open source people. A few recent examples I found in Israel:

• Advantages: People who like to build stuff (we really like people who maintain/contribute to open source projects) (Wizer Research)
• You will: Incubate and contribute to open source projects (iguazio)
• The X factor significant contribution to an open-source community (unnamed startup)
• An example open source project our team released is CoreML (Apple)
• Job Responsibilities: Write open-source tools and contribute to open-source projects. (unnamed startup)
• We d like to talk to people who: Appreciate open-source culture and philosophy. (Seeking Alpha)

From the applicant side, the possibility to know which code base he or she is going to work on could help do a better and more educated choice about the offered position. While from the company side, getting hard evidence of what are the applicant capabilities and code looks like instead of just describing them or trying to demonstrate them on short tests. Not to mention the applicant s ability to work as part of a team or community. For the Israeli readers, you can see the full list at https://kaplanopensource.co.il/jobs/
Filed under: Israeli Community, Open source businesses

An open letter published today to the EU government says:

Why is software created using taxpayers money not released as Free Software?
We want legislation requiring that publicly financed software developed for the public sector be made publicly available under a Free and Open Source Software licence. If it is public money, it should be public code as well. Code paid by the people should be available to the people!

See https://publiccode.eu/ for the campaign details. This makes me think of starting an Israeli version
Filed under: Uncategorized

Early September, it s about 3 months before PHP 7.2 is expected to be release (schedule here). One of the changes is the removal of the mcrypt extension after it was deprecated in PHP 7.1. The main problem with mcrypt extension is that it is based on libmcrypt that was abandoned by it s upstream since 2007. That s 10 years of keeping a library alive, moving the burden to distribution s security teams. But this isn t new, Remi already wrote about this two years ago: About libmcrypt and php-mcrypt . But with removal of the extension from the PHP code base (about F**King time), it would force the recommendation was done nicely till now. And forcing people means some noise, although an alternative is PHP s owns openssl extension. But as many migrations that require code change it s going slow. The goal of this post is to reach to the PHP eco system and map the components (mostly frameworks and applications) to still require/recommend mcyrpt and to pressure them to fix it before PHP 72 is released. I ll appreciate the readers help with this mapping in the comments. For example, Laravel s release notes for 5.1:

In previous versions of Laravel, encryption was handled by the mcrypt PHP extension. However, beginning in Laravel 5.1, encryption is handled by the openssl extension, which is more actively maintained.

Or, on the other hand Joomla 3 requirements still mentions mcrypt. mcrypt safe:

• Drupal 7 and up, see https://www.drupal.org/docs/7/system-requirements/php
• Lavavel 5.1 and up, see https://laravel.com/docs/5.1/releases

mcrypt dependant:

• Joomla, see https://downloads.joomla.org/technical-requirements
• Magento, see http://devdocs.magento.com/guides/v2.2/install-gde/system-requirements-tech.html
  (Checking 2.2 RC release, as it just added support for PHP 7.1)

For those who really need mcrypt, it is part of PECL, PHP s extensions repository. You re welcome to compile it on your own risk.
Filed under: Debian GNU/Linux, PHP

The 3rd day should have started with a Debian sprint and then a LibreOffice one, taking advantage I m still attending, as that s my last day. But plans don t always work out and we started 2 hours later. When everybody arrive we got everyone together for a short daily meeting (scrum style). The people were divided to 3 teams for translating: Debian Installer, LibreOffice and Gnome. For each team we did a short list of what left and with what to start. And in the end how does what so there will be no toe stepping. I was really proud with this and felt it was time well spent. The current translation percentage for Albanian in LibreOffice is 60%. So my recommendation to the team is translate master only and do not touch the help translation. My plans ahead would be to improve the translation as much as possible for LibreOffice 6.0 and near the branching point (Set to November 20th by the release schedule) decide if it s doable for the 6.0 life time or to set the goal at 6.1. In the 2nd case, we might try to backport translation back to 6.0. For the translation itself, I ve mentioned to the team about KeyID language pack and referred them to the nightly builds. These tools should help with keeping the translation quality high. For the Debian team, after deciding who works on what, I ve asked Silva to do review for the others, as doing it myself started to take more and more of my time. It s also good that the reviewer know the target language and not like me, can catch more the syntax only mistakes. Another point, as she s available more easily to the team while I m leaving soon, so I hope this role of reviewer will stay as part of the team. With the time left I mostly worked on my own tasks, which were packaging the Albanian dictionary, resulting in https://packages.debian.org/sid/myspell-sq and making sure the dictionary is also part of LibreOffice resulting in https://gerrit.libreoffice.org/#/c/41906/ . When it is accepted, I want to upload it to the LibreOffice repository so all users can download and use the dictionary. During the voyage home (ferry, bus, plain and train), I mailed Sergio Durigan Junior, my NM applicant, with a set of questions. My first action as an AM (: Overall FOSScamp results for Albanian translation were very close to the goal I set (100%):

• Albanian (sq) level1 99%
• Albanian (sq) level2 25% (the rest is pending at #874497)
• Albanian (sq) level3 100%

That s the result of work by Silva Arapi, Eva Vranici, Redon Skikuli, Anisa Kuci and Nafie Shehu.
Filed under: Debian GNU/Linux, i18n & l10n, LibreOffice

The morning stated by taking the bus to Kini beach. After some to enjoy the water (which were still cold in the morning), we sat for talking about the local Debian community and how can we help it grow. The main topic was localization (l10n), but we soon started to check other options. I reminded them that l10n isn t only translation and we also talked about dictionaries for spell checking, fonts and local software which might be relevant (e.g. hdate for the Jewish/Hebrew calendar or Jcal for the Jalali calendar). For example it seems that regular Latin fonts are missing two Albanian characters. We also talked about how to use Open Labs to better work together with two hats member of the local FOSS community and also as members of various open source projects (not forgetting open content / data ones projects as well). So people can cooperate both on the local level, the international level or to mix (using the other s project international resources). In short: connections, connections, connections. Another aspect I tried to push the guys toward is cooperating with local companies about open source, whether it s the local market, the municipal and general government. Such cooperation can take many forms, sponsoring events / giving resources (computers, physical space or employee s time) and of course creating more jobs for open source people, which in turn will support more people doing open source for longer period. One of the guys thought benefit the local community will benefit from a mirror server, but that also requires to see the network topology of Albania to make sure it makes sense to invest in one (resources and effort). We continued to how it would be best to contribute to open source, mostly that Debian, although great isn t always the best target, and they should always try to work with the relevant upstream. It s better to translate gnome upstream then sending the Debian maintainer the translation to be included in the package. That shortcut can work if there s something urgent like a really problematic typo or something what unless done before the release would require a long long wait (e.g. the next Debian release). I gave an example that for important RTL bugs in LibreOffice I ve asked Rene Engelhard to include the patch instead of waiting for the next release and its inclusion in Debian. When I started the conversation I mentioned that we have 33% females out of the 12 participants. And that s considered good comparing to other computer/technical events, especially open source. To my surprise the guys told me that in the Open Labs hackerspace the situation is the opposite, they have more female members than male (14 female to 12 male). Also in their last OSCAL event they had 220 women and 100 men. I think there s grounds to learn what happens there, as the gals do something damn right over there. Maybe Outreachy rules for Albania should be different (: Later that day I did another session with Redon Skikuli to be more practical, so I started to search on an Albanian dictionary for spell checking, found an old one and asked Redon to check the current status with the guy. And also check info about such technical stuff with Social Sciences and Albanological Section of the Academy of Sciences of Albania, who is officially the regulator for Albanian. In parallel I started to check how to include the dictionary in LibreOffice, and asked Rene Engelhard to enable Albanian language pack in Debian (as upstream already provide one). Checking the dictionaries I ve took the opportunity to update the Hebrew. It took me a little longer as I needed to get rust off my LibreOffice repositories (dictionaries is a different repository) and also the gerrit setup. But in the end: https://gerrit.libreoffice.org/#/c/41864/ With the talks toady and the starting to combine both Debian and LibreOffice work today (although much of it was talking) I felt like I m the right person on the right place. I m happy to be here and contribute to two projects in parallel (:
Filed under: Debian GNU/Linux, i18n & l10n, LibreOffice

During Debconf17 I was asked by Daniel Pocock if I can attend FOSScamp Syros to help with Debian s l10n in the Balkans. I said I would be happy to, although my visit would be short (2.5 days) due to previous plans. The main idea of camp is to have FOSS people meet for about 1 week near a beach. So it s sun, water and free software. This year it takes place in Syros, Greece. After take the morning ferry, I met with the guys at noon. I didn t know how would it be, as it s my first time with this group/meeting, but they were very nice and welcoming. 10 minutes after my arrival I found myself setting with two of the female attendees starting to work on Albanian (sq) translation of Debian Installer. It took my a few minutes to find my where to check out the current level1 files, as I thought they aren t in SVN anymore, but ended up learning the PO files is the only part of the installer still on SVN. As the girls were quick with the assinged levle1 sublevels, I started to look for the level2 and level3 files, and it was annoying to have the POT files very accessible, but no links to the relevant git repositories. I do want to have all the relevant links in one central place, so people who want to help with translation could do that. While some of the team member just used a text editor to edit the files, I suggested to them using either poedit or granslator, both I used a few years ago. Yaron Shahrabani also recommended virtaal to me, but after trying it for a while I didn t like it (expect it s great feature showing the diff with fuzzy messages). For the few people who also have Windows on their machine, both poedit and Virtaal have windows binaries for download. So you don t have to have Linux in order to help with translations. In parallel, I used the free time to work on the Hebrew translation for level1, as it s been a while since either me or Omer Zak worked on it. Quite soon the guys started to send me the files for review, and I did find some errors using diff. Especially when not everyone use a PO editor. I also missed a few strings during the review, which got fixed later on by Christian Perrier. Team work indeed (: I found it interesting to see the reactions and problems for the team to work with the PO files, and most projects now use some system (e.g. Pootle) for online web translation. Which saves some of the head ace, but also prevents from making some review and quality check before submitting the files. It s a good idea to explore this option for Debian as well. A tip for those who do want to work with PO files, either use git s diff features or use colordiff to check your changes (notice less will require -R parameter to keep the color). Although I met the guys only at noon, the day was very fruitful for Debian Installer l10n:

• Albanian (sq) level1 from 78% to 82% (Eva Vranici, Silva Arapi)
• Albanian (sq) level2 from 20% to 24% (Nafie Shehu)
• Hebrew (he) level1 from 96% to 97% (me)
• Greek (el) level1 from 96% to 97% (Sotirios Vrachas)

Some files are still work in progress and will be completed tomorrow. My goal is to have Albanian at 100% during the camp and ready for the next d-i alpha. I must admit that I remember d-i to have many more strings as part of the 3 levels, especially levels 2+3 which were huge (e.g. the iso codes). Except all the work and FOSS related conversations, I found a great group who welcomed me quickly, made me feel comfortable and taught me a thing or two about Greece and the Syros specifically. TIP: try the dark chocolate with red hot chili pepper in the icecream shop.
Filed under: Debian GNU/Linux, i18n & l10n

As part of my work at Zend (now a RogueWave company), I maintain the various patch sets. One of those is the changes for PDO_IBM extension for PHP. After some patch exchange I decided it s would be easier to manage the whole process over a public git repository, and maybe gain some more review / feedback along the way. Info at https://github.com/kaplanlior/pecl-database-pdo_ibm/commits/zend-patches Another aspect of this, is having IBMi specific patches from YIPS (young i professionals) at http://www.youngiprofessionals.com/wiki/index.php/XMLService/PHP, which itself are patches on top of vanilla releases. Info at https://github.com/kaplanlior/pecl-database-pdo_ibm/commits/zend-patches-for-yips So keeping track over these changes as well is easier while using git s ability to rebase efficiently, so when a new release is done, I can adapt my patches quite easily. Make sure the changes can be back and forward ported between vanilla and IBMi versions of the extension.
Filed under: PHP

This year I decided to participate in Midburn, the Israeli version of burning man. Whiling thinking of doing something different from my usual habit, I found myself with volunteering in the midburn IT department and getting a task to make it an open source project. Back into my comfort zone, while trying to escape it. I found a community of volunteers from the Israeli high tech scene who work together for building the infrastructure for Midburn. In many ways, it s already an open source community by the way it works. One critical and formal fact was lacking, and that s the license for the code. After some discussion we decided on using Apache License 2.0 and I started the process of changing the license, taking it seriously, making sure it goes by the rules . Our code is available on GitHub at https://github.com/Midburn/. And while it still need to be more tidy, I prefer the release early and often approach. The main idea we want to bring to the Burn infrastructure is using Spark as a database and have already began talking with parallel teams of other burn events. I ll follow up on our technological agenda / vision. In the mean while, you are more than welcome to comment on the code or join one of the teams (e.g. volunteers module to organize who does which shift during the event).
Filed under: Israeli Community

I recently checked the Debian PHP 5.4 changelog and found out this message (5.4.45-0+deb7u3 and 5.4.45-0+deb7u4):

* most patches taken from https://github.com/kaplanlior/php-src
Thanks a lot to Lior Kaplan for providing them.

I was very pleased to see my work being used, and I hope this would save other time while providing PHP long term support. Also, while others do similar work (e.g. Remi from RedHat), it seems I m the only when that make this over GIT and with full references (e.g. commit info, CVE info and bug number). Comments and suggestions are always welcome either mail or even better a pull request.
Filed under: Debian GNU/Linux, PHP

A year ago I ve blogged about people requesting CVE without letting upstream know. On the other hand, per requests from Debian, I m working on improving PHP upstream CVE request process. For the last few release this means I ask the security list members which issues they think should have CVE and ask for them in parallel to the release being made (usually in the space between the release being tagged publicly and is actually announced). In the last week, I ve encountered a case where a few CVE were assigned to old PHP issues without any public notice. The fixes for these issues have been published a year ago (August 2015). And I find out about these assignment through warning published by the distributions (mostly Debian, which I m close to). Sometimes things fall between the chairs, and it s perfectly OK to ask for CVE to make sure security issues do get attention even if time has passed. But after the issues (and fixes) are public, I don t see a reason to do so without making the request itself public as well. And even if the request wasn t public, at least notify upstream so this info can be added to the right places. Most of these bug were found out when I started to add sequential number into the CVE search after getting an a notice from Debian for two of the issues.

• CVE-2015-8873 for PHP #69793
• CVE-2015-8874 for PHP #66387
• CVE-2015-8876 for PHP #70121
• CVE-2015-8877 for PHP #70064
• CVE-2015-8878 for PHP #70002
• CVE-2015-8879 for PHP #69975
• CVE-2015-8880 for PHP aa8cac57 (Dec 2015)

And while working on processing these issues for PHP, I also notice they weren t updated for libGD where appropriate (including recent issues). Beyond keeping the eco-system up to date, another aspect of publicity is getting opinions from other parties. For example, in the case of CVE-2015-8879, RedHat doesn t agree with the classification of the bug as security. To give an example of a way things should happen is the request of CVE for PHP 5.5.34 in April, in which the Gentoo security team asked for assignment without upstream knowledge, Debian representative CCs upstream (Thanks!) and also asks CVE for issues covered by Ubuntu, to which the Ubuntu guy then adds some details. I hope this blog post will reach the anonymous people behind these CVE requests, and also the people assigning them. Without transparency and keeping things in synchronization, the idea of having a centralized location for security warning is not going to accomplish its goals.
Filed under: Debian GNU/Linux, PHP

I recently joined Linnovate, and while working on one of the open source projects the company produces, we needed to process video content according to NATO s standard agreement (STANAG) 4609: NATO Digital Motion Imagery Standard. Obviously we started with trying to find code already done, but we only found some implementation in Java, while our project is written in JavaScript. We decided to just implement the standard in the way most convenient to us, and later refactoring the project when more standards (STANAGs) will get implemented. So I m happy to introduce our new project: STANAG at https://github.com/linnovate/stanag , also available with NPM (see https://www.npmjs.com/package/stanag).
Filed under: Linnovate

4 months ago I wrote my thoughts about PHP support during the PHP 5 support timeline vote:

I think we should limit what we guarantee (meaning keeping only one year of security support till end of 2017), and encourage project members and the eco-system (e.g. Linux distributions) to maintain further security based on best effort. This is already the case for out of official support releases like the 5.3 and 5.4 branches (examples for backports done by Debian: 5.3 and 5.4). And of course, we also have companies that make their money out of long term support (e.g. RedHat). On the other hand, we should help the eco system in doing such extended support, and hosting backported fixes in the project s git repo instead of having each Linux disto do the same patch work on its own.

But suggesting to others what they should do is easy, so I decided to finally find the time to also implement this myself. I ve started with back porting PHP 5.5 fixes to PHP 5.4, resulting in a GitHub repository with all the fixes, including CVE info NEWS file entries and references to the original commits. See https://github.com/kaplanlior/php-src/commits/PHP-5.4-security-backports . I hope this would later on find it s way into PHP LTS packages for Debian Wheezy. Next step would be to start doing the same for PHP 5.3 (back porting from PHP 5.4, and later on also from PHP 5.5). This can be in use for RHEL 6.x (as LTS support for Debian Squeeze was recently finished). The main idea of this repo, is to have a more central location for such work, hoping people would review and contribute fixes that should be taken into consideration. During the process of digging into the CVE information and the commits, I m also filling up a info such as CVE IDs to the NEWS file (e.g. https://github.com/php/php-src/pull/1892/files) and the web changelog (e.g. https://github.com/php/web-php/commits?author=kaplanlior), so users and researchers would find this info where it should be instead of digging themselves.
Filed under: Debian GNU/Linux, PHP

With the new year starting the PHP project is being asked to decide about the PHP 5 support timeline. While Aligning PHP 5.6 support timeline with the release date of PHP 7.0 seems like common sense to keep the support schedule continuous, there s a big question whether to extend it further to an additional one year of security support till the end of 2018. This would make PHP 5.6, the last of the PHP 5 branch, to have 2 years of security support and de facto getting the same life span as PHP 7.0 would (ending support of both in Dec 2018). But beside of support issues, this also affects adoption rate of PHP 7.0, serving as a catalyst due to end of support for the PHP 5 branch. My concerns are that with the additional security support the project would need to deal with the many branches (5.6, 7.0, 7.1, 7.2 and then to be 7.3 branch). I think we should limit what we guarantee (meaning keeping only one year of security support till end of 2017), and encourage project members and the eco-system (e.g. Linux distributions) to maintain further security based on best effort. This is already the case for out of official support releases like the 5.3 and 5.4 branches (examples for backports done by Debian: 5.3 and 5.4). And of course, we also have companies that make their money out of long term support (e.g. RedHat). On the other hand, we should help the eco system in doing such extended support, and hosting backported fixes in the project s git repo instead of having each Linux disto do the same patch work on its own.
Filed under: PHP

In the last few years I wasn t really maintaining my GPG keys. I ve created a new one (B4E14499) in 2011 during DebConf11, after the older primary one (99E81DA0) became too weak (1024D). I thought that I didn t have enough signatures on the new key and almost lost my place on the debian keyring due to removal on the old one (without adding the new key). Due to my confusion with the key signature, I didn t really take the time to sign other people keys. But that doesn t mean I ignored them completely, as I kept all the information from Debconf11 (yes, 4 years ago) and also the slips I was handed since. Today, I finally took the time to finish the backlog and sign all the keys which are strong enough and still valid (haven t expired / revoked). One less item on the todo list. For those who got my signatures I m sorry for the delay, but better later than never, right ?
Filed under: Debian GNU/Linux Tagged: gpg

In the past few months I ve been dealing with aligning PHP CVE information to enable easier tracking of security fixes. The two main locations are the NEWS file which is part of each release and the changelog available on the website which is more popular (and easier to update). Usually the CVE are assigned per PHP.net security team request or with cooperation with one of the Linux distribution s teams (either PHP or security), as should be in a good ecosystem. Recently I got a few notifications issued by Debian about its PHP package, which I wasn t familiar with these CVE IDS. When checking this, I found out a few CVE assigned per 3rd party (Linux distribution, bug reporter, etc ) request without upstream knowledge. Digging deeper I found out that some CVE were assigned a month after the fixes were released, while others were only a week or two after. While this makes sure the security information is documented, it s harder to add the information after tagging and releasing. In another case, while discussing about a CVE for a specific bug, we found out one was already assigned per the reporter s request but without the our or the upstream library knowledge. Even if the issue isn t severe, upstream should get a fair chance to fix issue before making them public. Which also leads to a problem with requesting CVE IDs on a public mailing list which in some cases leads to security information leakage. We should balance transparency with some grace period for upstreams (as projects share code).
Filed under: Debian GNU/Linux, PHP

For many the PHP JSON extension license might look like a storm in a teacup, but for many Linux distributions the bits of the free software licenses are very important. That was the case when Debian decided (#692613) to remove the non-free JSON extension as part of the transition to PHP 5.5 in May 2013 (after the Debian 7 release). This change was done with the help of Remi Collet (from Fedora / Red Hat) who wrote an alternative extension based on JSON-C implementation. A similar change was done by other Linux distributions, and this became the defacto standard for most Linux users. The situation has recently changed with the acceptance of the Jakub Zelenka s jsond RFC to replace the current non-free implementation with a free one. The change was committed to the code base on early February (Closing #63520) and expected to be released later this year as part of PHP7.
Filed under: Free software licenses, PHP

Many package maintainers need to decide when to upload a new version to Debian. Should the upload be done only after the official release, or is there a place for uploads during the development process. In the latter case there s a need to balance between the benefit of early testing and feedback with the stability and not completely breaking user s environment (and package relationships) too often. With the coming PHP 5.6.0 release, Debian kept being on the cutting edge. Thanks to Ond ej, the new version was available in experimental since alpha1 and in unstable/testing since beta3. Considering the timing of the PHP release related to the Debian freeze, I m happy we started early, and did the transition to PHP 5.6 a few months ago. But just following the development releases (betas ,RCs) isn t enough. Both Ond ej and myself are part of the PHP community, and know the planned timelines, current status and what are the critical points. Such knowledge was very useful this week, when we new 5.6.0 was pending finale tagging before release (after RC4). This made take the report of Debian bug #759381: php5: TLS connections broken in 5.6.0 RC4 seriously and contact the release managers. First it was a heads up and then a real problem. After a quick discussion (both private mails by me and on github by Ond ej), the relevant commit was reverted by the release managers (Julien Pauli & Ferenc Kovacs), and 5.6.0 was retagged. The issue will get more checks towards 5.6.1 without any time pressure. Although 5.6.0 isn t in production for anyone (yet), and like any major release can have issues, the close connectivity between everyone saved complaints from the PHP users and ecosystem. I don t imagine the issue been sorted so quickly 16 hours later. This is also due to the bug been reported on difference between two close release (regression in RC4 comparing to RC3). To close the loop, if we ve uploaded 5.6.0 only after the release, the report would be regression between 5.5.x and 5.6.0, which is obviously much harder to pinpoint. So, I m not sure I have a good answer for the question in the beginning of the post, but for this case our policy proved itself.
Filed under: Debian GNU/Linux, PHP