DOC: Formalize LTS backport policy #11429

pllim · 2021-03-25T22:07:58Z

Description

This pull request is to formalize LTS backport policy.

We have to decide where to best place such a policy and hammer out the wordings.

github-actions · 2021-03-25T22:08:46Z

👋 Thank you for your draft pull request! Do you know that you can use [ci skip] or [skip ci] in your commit messages to skip running continuous integration tests until you are ready?

Cadair

I approve this message.

Cadair · 2021-03-25T22:18:08Z

docs/lts_policy.rst

+*******************
+
+Starting from astropy 5.0, backports to Long-Term Stable (LTS) releases
+will only cover:


After the standard support life cycle.

@Cadair , can you please elaborate on this?

Well why the LTS version is both "the LTS" and the latest release the backport policy is the same as normal?

docs/lts_policy.rst

embray · 2021-05-17T16:42:02Z

I think this is well stated, thank you.

saimn · 2021-05-18T06:56:12Z

After some thought I tend to disagree, or at least that not what LTS means for me. As a comparison, Python releases have bugfix releases during 2 years, and then security/critical fix releases when needed during 3 more years. Changing LTS to security/critical/on-demand fixes only is a regression imo, and not what LTS was intended for, and also not what we have been doing since LTS started.
I understand the maintenance cost but I think that we could reduce this cost with a better backport/release procedure. Also backporting bugfixes is often not that difficult in terms of conflict since bugfixes usually impact limited sections of the code. At least with my io.fits hat, I think that bugfix backport are usually not complicated, and are of great value for LTS users. If we want to stop doing that, it would mean for me the end of LTS. And about backporting security/critical fixes, there is no need for a LTS branch for that. I guess if there was some security/critical fix (which is not so frequent with our codebase, not web oriented etc.) we would try to backport it to any recent enough version we can anyway.

embray · 2021-05-21T16:47:29Z

@saimn I agree with your points overall, and it's how I feel as well. But I didn't really want to push back on this because I know LTS maintenance has been a big burden for all involved, so I'm sympathetic to the desire to change the policy. I know I just wrote earlier that I think this policy is well-said, you have me wanting to backtrack a bit.

I think the backport procedure usually worked pretty well in the past but over time became more complicated for various reasons (mostly to do with CI I think). Now that we are experimenting with meeseeksbot and also have CI a little better straightened out for the 4.0.x branch (#11123) I think we should wait and see if it becomes any easier.

Maybe what we could do is soften this slightly with wording like:

Bug fixes that are trivial to backport, and critical bug fixes.

Where we can define "trivial to backport" as either "automated backports merge / pass CI without any additional intervention" or it would take me at most 5 minutes to resolve any minor merge conflicts. And by "me" I mean I'll volunteer.

saimn · 2021-05-25T21:10:15Z

Indeed, the backport workflow with the bot should help by backporting just after PRs are merged (so changes would still be fresh, and it would be up to the sub-package maintainer to see if it's worth fixing the conflicts) and by running CI on the backport branches more regularly.

pllim · 2021-05-26T14:08:47Z

So, uh, how do we proceed? Should I just close this without merge?

eteq

Some wording suggestions based on some out-of-band discussion.

My two cents is that with the backport bot things should be a bit easier, so "critical" is not mandatory. But it is good to have this here nonetheless to make sure everyone understands that the purpose of LTS and the scope of fixes.

docs/lts_policy.rst

pllim · 2021-06-15T15:38:36Z

docs/lts_policy.rst

+LTS Backport Policy
+*******************
+
+Starting from astropy 5.0, backports to Long-Term Stable (LTS) releases


@Cadair , you mean like this?

Suggested change

Starting from astropy 5.0, backports to Long-Term Stable (LTS) releases

After the standard support life cycle, backports to Long-Term Stable (LTS) releases

pllim · 2021-06-15T15:41:47Z

Update:

I applied new wordings from Erik, so should be less controversial now?
Still not sure what Stuart wanted in his comment above.
Should I move this to the section where it would only be rendered in latest and not stable?

embray · 2021-06-16T18:53:56Z

Should I move this to the section where it would only be rendered in latest and not stable?

I don't know--if that's the policy starting v5.0 I don't see why it shouldn't be in the stable docs. I think we want to defend this policy as "stable" and not be pressured into changing it. If it absolutely must be changed, I think any change to the policy should coincide with a new release. But as it is I'm pretty sure this covers all the bases, including the "pipelines that absolute need it can have backports but they must be willing to help".

hamogu · 2021-07-06T18:17:54Z

docs/lts_policy.rst

+* Critical security fixes.
+* Bug fixes where backporting is straightforward (e.g., no conflicts).
+* More complex fixes are permissible only as resources allow, ideally with
+  backports done by the original author or from institutions who are on LTS


How about "users"? In most cases, those users are institutions, but I don't think that we should write a policy that explicitly excludes non-institutional users.

I added "users". Look better now?

docs/lts_policy.rst

pllim · 2021-07-06T21:57:41Z

Hmm looks like I need to rebase to get rid of failures.

as Stuart Mumford suggested. [ci skip]

[ci skip] Co-authored-by: Erik Tollerud <erik.tollerud@gmail.com>

Apply suggestion from hamogu [ci skip] Co-authored-by: Hans Moritz Günther <moritz.guenther@gmx.de>

pllim · 2021-10-19T13:04:43Z

We can further word-smith this in follow-up PR(s). Thanks for the reviews!

pllim added no-changelog-entry-needed needs-discussion labels Mar 25, 2021

pllim added this to the v4.3 milestone Mar 25, 2021

pllim mentioned this pull request Mar 25, 2021

DOC: Have a formal policy on what goes in LTS or not #11405

Closed

github-actions bot added the Docs label Mar 25, 2021

pllim added the Release label Mar 25, 2021

Cadair approved these changes Mar 25, 2021

View reviewed changes

pllim modified the milestones: v4.3, v5.0 Apr 19, 2021

pllim marked this pull request as ready for review April 19, 2021 17:05

pllim requested a review from saimn May 17, 2021 16:57

pllim requested a review from eteq June 14, 2021 17:21

eteq requested changes Jun 14, 2021

View reviewed changes

docs/lts_policy.rst Outdated Show resolved Hide resolved

docs/lts_policy.rst Outdated Show resolved Hide resolved

pllim commented Jun 15, 2021

View reviewed changes

hamogu reviewed Jul 6, 2021

View reviewed changes

docs/lts_policy.rst Outdated Show resolved Hide resolved

pllim and others added 4 commits July 6, 2021 18:00

DOC: Formalize LTS backport policy [ci skip]

e5b9884

Replace pipelines with users

1b4049c

as Stuart Mumford suggested. [ci skip]

Apply suggestions from eteq

e894a20

[ci skip] Co-authored-by: Erik Tollerud <erik.tollerud@gmail.com>

DOC: Include users in policy

da46b5e

Apply suggestion from hamogu [ci skip] Co-authored-by: Hans Moritz Günther <moritz.guenther@gmx.de>

pllim force-pushed the doc-lts-policy branch from fa697d3 to da46b5e Compare July 6, 2021 22:02

pllim merged commit 086633e into astropy:main Oct 19, 2021

pllim deleted the doc-lts-policy branch October 19, 2021 13:03

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

DOC: Formalize LTS backport policy #11429

DOC: Formalize LTS backport policy #11429

pllim commented Mar 25, 2021

github-actions bot commented Mar 25, 2021

Cadair left a comment

Cadair Mar 25, 2021

pllim Mar 26, 2021

Cadair May 18, 2021

embray commented May 17, 2021

saimn commented May 18, 2021 •

edited

embray commented May 21, 2021

saimn commented May 25, 2021 •

edited

pllim commented May 26, 2021

eteq left a comment

pllim Jun 15, 2021

pllim commented Jun 15, 2021

embray commented Jun 16, 2021

hamogu Jul 6, 2021

pllim Jul 6, 2021

pllim commented Jul 6, 2021

pllim commented Oct 19, 2021

	Starting from astropy 5.0, backports to Long-Term Stable (LTS) releases
	After the standard support life cycle, backports to Long-Term Stable (LTS) releases

DOC: Formalize LTS backport policy #11429

DOC: Formalize LTS backport policy #11429

Conversation

pllim commented Mar 25, 2021

Description

github-actions bot commented Mar 25, 2021

Cadair left a comment

Choose a reason for hiding this comment

Cadair Mar 25, 2021

Choose a reason for hiding this comment

pllim Mar 26, 2021

Choose a reason for hiding this comment

Cadair May 18, 2021

Choose a reason for hiding this comment

embray commented May 17, 2021

saimn commented May 18, 2021 • edited

embray commented May 21, 2021

saimn commented May 25, 2021 • edited

pllim commented May 26, 2021

eteq left a comment

Choose a reason for hiding this comment

pllim Jun 15, 2021

Choose a reason for hiding this comment

pllim commented Jun 15, 2021

embray commented Jun 16, 2021

hamogu Jul 6, 2021

Choose a reason for hiding this comment

pllim Jul 6, 2021

Choose a reason for hiding this comment

pllim commented Jul 6, 2021

pllim commented Oct 19, 2021

saimn commented May 18, 2021 •

edited

saimn commented May 25, 2021 •

edited