| 4 Jun 2021 |
 ris_ | yes i still see it as a "one day" thing | 17:58:27 |
 Sandro | Also if I am rocking unstable or even master or Sid on the Debian side that won't work well together | 17:58:41 |
| ris_ | i'd quite like that "one day" to be relatively sooner personally but 🤷♂️ | 17:59:08 |
| Sandro | In reply to @r_i_s:matrix.org
well... what is "our" in this case? are "we" just a bunch of people who have self-selected as people who don't care about supporting old software? I personally don't care to much about old software | 17:59:37 |
 Alyssa Ross | perhaps people this is important to could start maintaining this outside of Nixpkgs, as an alternate Nixpkgs tree or an overlay. | 18:00:28 |
 ajs124 | isn't that what flying circus does? | 18:00:52 |
| Sandro | In reply to @r_i_s:matrix.org
otherwise my organization wouldn't be paying $x,000 to canonical for continued support of 16.04 If you have a lack of monitoring, backups and testing updating can be quiet scary | 18:01:11 |
| Alyssa Ross | this would be different enough to Nixpkgs in its current state that it might make sense for it to be "nixpkgs-lts" or something | 18:01:12 |
| ris_ |
If you have a lack of monitoring, backups and testing updating can be quiet scary
it's... much more complicated than that, but yes it's a bad place to be
| 18:02:40 |
 andi- | In reply to @andreas.schraegle:helsinki-systems.de
isn't that what flying circus does? Yes, they are doing something similiar. I am not sure what the scope of their "security" coverage is but perhaps most famous packages. | 18:04:30 |
| ris_ | i need to go shopping now... go, review some security PRs, people... | 18:05:53 |
 asymmetric | In reply to @andreas.schraegle:helsinki-systems.de
isn't that what flying circus does? do you have more info about this? my company might be interested | 18:06:33 |
 hexa | https://flyingcircus.io | 18:07:02 |
| asymmetric | In reply to @hexa:lossy.network
https://flyingcircus.io right, couldn't find any mention of "lts support for nixpkgs" or similar | 18:07:26 |
| hexa | let's not kid ourselves, I don't think our security state is bad or needs changing into debians direction | 18:07:26 |
| hexa | lts support means somepone has to pay for the shitty backports to happen | 18:07:55 |
| hexa | that can happen outside of nixpkgs, since the nixpkgs model is easy to fork, but alot of being "lts" is about having moldy versions of software, and nobody likes to work with that for free | 18:09:49 |
| hexa | in debian people are paid for maintaining things, this is especially true for the lts extensions of their releases | 18:10:28 |
| hexa | and following debian releases would mean a change to our release cadence, as else you'd need to support multiple stable releases in parallel - not feasible | 18:12:35 |
| hexa | the one month overlap between the old and new stable is annoying enough fwiw | 18:13:47 |
| hexa | * the one month overlap between the old and new stable right now is annoying enough fwiw | 18:13:55 |
| Sandro | In reply to @hexa:lossy.network
and following debian releases would mean a change to our release cadence, as else you'd need to support multiple stable releases in parallel - not feasible right now we release two times a year a big release. Debian does once every few years. | 18:32:00 |
 philipp | Just to be clear I never said we should change the release schedule, I just wondered whether it would be feasible to use debians patches to keep certain packages around a while longer. | 18:33:15 |
| Sandro | you can always just pin the older version and apply the patches yourself but doing a minor or major update is a lot of times easier | 18:35:42 |
| hexa | In reply to @sandro:supersandro.de
right now we release two times a year a big release. Debian does once every few years. roughly every 2 years | 18:44:19 |
| hexa | applying the patches yourself implies you can't be an end-user | 18:44:33 |
| Sandro | In reply to @hexa:lossy.network
roughly every 2 years yeah https://wiki.debian.org/DebianReleases#Production_Releases | 18:49:19 |
| ris_ | hexa: if a need (and the funding/human-power) for LTS emerged, I'd rather they weren't cast out of the project into a fork, where they would need to set up their own infra, hydra, and cause those who find themselves at the end of a regular release's support to have to consciously switch channels etc. | 19:16:34 |
| ris_ | the worst it would mean for us is more noise in github | 19:16:53 |
| hexa | agreed | 19:17:20 |
