On Wed, Jan 24, 2024 at 03:19:27PM -0500, Roberto C. Sánchez wrote: > On Tue, Jan 23, 2024 at 02:30:27PM -0800, Bruce Byfield wrote: > > > > I will need answers by Monday, January 29. Please cc to [email protected]. > > If > > you want a hardcopy of the issue the column is in, contact > > [email protected] in North America or [email protected] in the > > rest > > of the world. > > > I am working on getting the responses put together. > Hi Bruce,
I have attached a document with your questions and answers to each. Please feel free to follow-up as needed and I'll do my best to answer promptly. Regards, -Roberto -- Roberto C. Sánchez
------ -Why did LTS become an option? In particular, how did the Debian project begin? Why is the Old Stable repository not sufficient? Historically, the Security Team had committed to supporting a particular stable release until one year after the release of its successor. During the time when the Debian project was producing new stable releases less frequently than at present, the security support time frame worked out to around 4-5 years. Some years ago, the Debian project decided to move to a more consistent release tempo of approximately 24 months between stable releases. The resources of the Security Team did not allow them to extend the support commitment, as it was not possibile for them to support three Debian stable releases simultaneously. As a result of this, the Security Team is now committed to supporting each Debian stable release for 3 years. However, the popularity of Ubuntu's LTS releases and Red Hat's RHEL demonstrated that demand existed for Linux distributions that have support timeframes of 5 years or more. Your question "how did the Debian project begin?" seems somewhat overly broad, so I am going to proceed with the assumption to that you meant to ask "how did the Debian *LTS* project begin?" In 2014, Debian Developer Raphaël Hertzog, owner of the French IT consultancy Freexian SARL, commenced an initiative to seek out sponsors to provide funding in support of providing an additional 2 years of support for Debian stable (version 6, "squeeze", being the stable release at that time) to provide users a Debian stable release that would receive security updates for 5 years from its initial date of release. Raphaël also set about recruiting interested Debian Developers who could perform the work of preparing the required updates (as well as other tasks associated with providing this security support). The oldstable repository is perhaps not the best way to think about this. Rather, when a stable release is made the particular set of packages present in the archive are frozen. After that, uploads targeting the stable release are permitted only for a small set of reasons (security updates being the most common). When the next stable release is made, the previous stable release continues to exist. The labels 'stable' and 'oldstable' are aliases for the current stable release and its predecessor, respectively. Looking at it that way, the time from when a particular stable release is displaced by its successor (and thus takes on the alias 'oldstable') until the Security Team drops support for it is generally about one year. The LTS effort continues uploading to that same oldstable release target. This means that users do not have to do anything special in order to use LTS. So, for instance, if a user installed Debian 12 bookworm today and configured the standard archive mirror sources (including the security archive), then that user can expect to receive package updates until around mid-2028 for that system (5 years after the initial release of bookworm). The key takeaway is that the efforts of LTS contributors result in package uploads using the same tools and infrastructure as the Security Team's uploads, which results in a nearly seamless experience for users. - What are the reasons/ advantages of using LTS? Any disadvantages? There is not really a concept of "using LTS" that is somehow distinct from using a Debian stable release. Simply put, a user can install a Debian stable release with confidence that it will continue receiving security updates until 5 years from its initial release. That said, there are some disadvantages which can come into play in the latter part of the 5 year timeframe. As software ages, it can become more difficult to maintain. From a user perspective this means that some security updates may be slower to arrive and also that some packages may have to be dropped from support. This is not common and it is something which may also happen during the earlier part of the life of a stable release, meaning that this is not unique to the LTS effort. - Who is the audience for LTS? To what extent are the sponsors of Debian LTS a reflection of the audience? Who else uses LTS? The audience for LTS is really all Debian users. The term or label "LTS" can be used in multiple distinct ways. Ubuntu, as well as some upstream projects, use the LTS label to designate particular releases as those which have support for a longer timeframe, whereas other releases receive support for a shorter time. The way the Debian LTS effort is structured is such that every Debian stable release receives 5 years of security update support. That makes LTS more like a lifecycle phase for every Debian stable release, rather than a designation which applies to some Debian releases and not to others. The LTS effort is sponsored primarily by companies, organizations, and government entities (https://www.freexian.com/lts/debian/) who see a benefit in having Debian stable releases with a 5 year support lifecycle. Since the sponsors are entities which presumably try to control the costs associated with their technology infrastructure, it stands to reason that supporting the LTS effort is a cost-effective alternative to them as compared to more frequent upgrades. We do not collect data on who uses LTS directly. - What does Debian LTS' work consist of? Security and bug fixes? Anything else, like maybe new packages that are needed? The most common task is CVE triage. Each new security vulnerability is assigned a CVE (common vulnerabilities and exposures) ID by a responsible entity. This allows different organizations (vendors, developers, etc) to coordinate their efforts. Each new CVE must be assessed to determine if it is applicable to Debian (many CVEs are for software packages and products not shipped by Debian), then those which are potentially applicable must be further assessed to determine which packages in Debian are affected and which versions of those packages. The Security Team already does a great deal of this and the LTS Team supplements this by focusing on assessing the CVEs to determine if they affect packages under the responsibility of the LTS Team. After triage, the next most common activity is preparing security fixes. This may be as simple as applying a patch developed by someone else (an upstream developer, the security team of another Linux distro, or someone else entirely). Sometimes the patch may require modification and other times an entirely new patch must be developed (either because an existing patch does not work with the package in Debian or because no patch has been developed by anyone else). In some instances, a package cannot be supported in its current state and it is instead updated to a new version, though this is very uncommon. Other types of updates which the LTS Team prepares includes firmware updates and "volatile" packages (e.g., antivirus and timezone data files) which require periodic updates even when no vulnerability exists. LTS contributors funded through Freexian are also encouraged to go beyond simply preparing updates for LTS. For example, if a given package is not fixed in any Debian suite, then the contributor will often prepare an update for stable (in coordination with the Security Team and/or Release Managers) and sometimes also an update for unstable (in coordination with the package maintainer). - Why are some architectures unsupported? A lack of audience? Resources? Something else? Certain architectures are considerably less popular than others and the less popular architecures are generally also more difficult to support. There are a variety of reasons for this. Among those reasons are that some architectures have fewer build resources available (all security updates must be built for all supported hardware architectures), and also that when the build resources are available then dealing with architecture-specific bugs and regressions can be a very time-consuming process. The currently supported list of architectures for LTS covers greater than 99.8% of reported Debian users (https://popcon.debian.org/). The exclusion of hardware architectures which have very low usage rates and which are also more difficult to support allows the Debian LTS Team to much more efficiently apply limited resources. - Other distribution have LTS releases supported for 5 years. From the chart on the web page, Debian's supported for less time. Why is that? I am not sure which web page you mean here. As I explained in an earlier answer, LTS is not a designation given to some Debian releases but not given to others. Rather, it is a phase in the lifecycle of every Debian release. The Debian project is committed to supporting each stable release for 5 years from its initial release date. - How does Debian LTS' security and back ports compare to that of the main releases? And how does the LTS team interact with the main Debian security team? The LTS Team follows a set of procedures that very closely parallels the procedures of the Security Team. As a result, updates prepared by the LTS Team adhere to the same quality criteria as updates prepared by the Security Team. The only meaningful difference when it comes to updates prepared by the LTS Team is that during the LTS phase of the lifecycle there are no point releases. To elaborate, not all updates to a Debian stable release are made by the Security Team. Certain bug fixes and lower priority security issues are fixed by point releases (e.g., 12.2, 12.3, etc.). Point releases require infrastructure and the involvement of other teams which lack the resources to extend support up to 5 years. Because of this, the LTS Team prepares updates which may at times be more minor than those which the Security Team would handle during the first 3 years of a release. The LTS Team interacts with the Security Team on an ongoing basis. We work in the same instance of the Debian Security tracker and LTS contributors regularly communicate with members of the Security Team via email and IRC. Members of the Security Team are also often present in the LTS IRC channel. - How is Debian LTS organized and funded? How are decisions made? What is Freexian's role? The LTS Team is organized in a manner similar to many other Debian teams. The key difference is that most active LTS contributors are funded through Freexian. Freexian solicits sponsorships, acting as the receiver of sponsor funds and disbursing funds to contributors performing the LTS work. Because LTS contributors funded through Freexian are all experienced Debian Developers, they work mostly independently. Freexian establishes general guidelines based on the expectations that have been communicated to sponsors about how funds will be used and contributors are expected to work professionally and in accordance with those guidelines. However, LTS contributors still have a great deal of freedom in deciding how they work, and they use their experience and judgment to decide this. Contributors frequently communicate and collaborate via various means, often requesting that another contributor review a patch, assist with testing, etc. That said, Debian LTS is not at all restricted to Freexian. Any Debian Developer is allowed to upload updates to the Debian LTS repository, and there are some Debian contributors that maintain their packages also in Debian LTS, independently of the Freexian umbrella. Debian LTS is actually quite an open project. - How does end of life for LTS releases affect users? Are they not recommended? Simply reference material? This question does not make sense to me, so apologize if my answer does not address what you intended to ask. The way that the LTS effort is currently structured, as a lifecycle phase of each stable release, then after 5 years from the initial release an announcement is made to inform users the date when security updates will cease. Users who require support beyond the 5 year lifecycle are able to subscribe to Freexian's Extended LTS support offering. - Is there anything the project would like to do, but can't? If so, why? I am assuming that by "the project" you are referring specifically within the scope of the LTS project. There is not anything specific we would like to do within the scope of LTS that we are not already doing. We are able to effectively manage the flow of new CVEs, we are working towards partnering with upstream developers and other interested parties on more robust LTS-type support from certain upstream projects, and LTS contributors also work towards improving Debian as a whole. - Any stats about the number of downloads? Commits? We do not collect specific statistics related to LTS utilization in the way of package downloads. However, the Debian popularity contest site https://popcon.debian.org/ may provide data that can be used to infer usage statistics. - Is there anything else that readers should know about Debian LTS? Nothing that I can think of.
