ADR0002: document deprecation strategy for current release series post 1.0

[joshuagl]

Description of the changes being introduced by the pull request:

Per the discussion in #1127 opt to support the old release on a best-effort
basis.

Please verify and check that the pull request fulfills the following
requirements:

• The code follows the Code Style Guidelines
• Tests have been added for the bug fix or new feature
• Docs have been added for the bug fix or new feature

[trishankatdatadog]

Thanks for documenting this, Joshua!

Do we have a policy for backporting security fixes?

[joshuagl]

Do you think security fixes should be handled differently to what is proposed here? If so, what additional steps do you think the maintainers should commit to?

I'm absolutely open to input here, I'm just not sure what to propose we commit to.

[trishankatdatadog]

Do you think security fixes should be handled differently to what is proposed here? If so, what additional steps do you think the maintainers should commit to?

I'm absolutely open to input here, I'm just not sure what to propose we commit to.

I think we should at least commit in writing to prioritizing and guaranteeing security fixes for Python 2, but nothing else. WDYT?

[joshuagl]

Do you think security fixes should be handled differently to what is proposed here? If so, what additional steps do you think the maintainers should commit to?
I'm absolutely open to input here, I'm just not sure what to propose we commit to.

I think we should at least commit in writing to prioritizing and guaranteeing security fixes for Python 2, but nothing else. WDYT?

Prioritising and guaranteeing review/merge/release of security fixes seems reasonable. Is that what you're suggesting? Or did you mean to also suggest implementation of security fixes?

[trishankatdatadog]

Prioritising and guaranteeing review/merge/release of security fixes seems reasonable. Is that what you're suggesting? Or did you mean to also suggest implementation of security fixes?

Both

[mnm678]

I think that we can reasonable commit to review and merge security fixes, but actually implementing the fixes may require more resources. To mitigate this, we can adopt a reporting strategy so that any users of the Python 2 implementation will be notified before any security issues become public, and will have a change to submit a patch.

[trishankatdatadog]

I think that we can reasonable commit to review and merge security fixes, but actually implementing the fixes may require more resources. To mitigate this, we can adopt a reporting strategy so that any users of the Python 2 implementation will be notified before any security issues become public, and will have a change to submit a patch.

If someone else privately reports a security issue to us, then we could ask them to submit a patch, too. But what if we find the issue ourselves?

[lukpueh]

Why the change of heart, @trishankatdatadog?

@joshuagl already described the strategy proposed here in #1127 (comment), and you seemed to deem it reasonable. (#1127 (comment)).

I admit that in the original proposal the best-effort basis sounded a bit more optimistic ...

• that we will review any functional bug and security fixes proposed to the branch (PRs)
• that severe security issues and functional bugs will be addressed on a best effort basis
• that we will release updates with any generated fixes in a timely fashion

... than it does now ...

Bugs reported with tuf versions prior to 1.0.0 will likely not be addressed directly by tuf’s maintainers.

But I think the essence is the same.

[lukpueh]

Many thanks for the great write-up, @joshuagl! In #1127 you talked about:

a deprecation strategy for the current release series [...] and
a deprecation/API stability strategy for releases after the refactor.

IIUC this document only addresses the former. Would you mind clarifying the distinction in the title (and maybe document name)?

[trishankatdatadog]

Why the change of heart, @trishankatdatadog?

Sorry, what change of heart?

[lukpueh]

Sorry, what change of heart?

Oh, apologies, I missed an important pronoun in my comment above.

I was just curious why you now wanted to commit to more (#1203 (comment)) than what @joshuagl had already described in #1127 (comment), which you seemed to deem reasonable (#1127 (comment)).

[trishankatdatadog]

I was just curious why you now wanted to commit to more (#1203 (comment)) than what @joshuagl had already described in #1127 (comment), which you seemed to deem reasonable (#1127 (comment)).

I see. Yes, I still agree. I just think it's important to clearly state we should make an exception for security fixes, just like Python 2... until I saw that, nope, they don't guarantee security fixes either. Huh, wow. If that's the case, it may not be a terrible precedent. May encourage people to seriously upgrade. Not a bad idea. I know we're a more security-based project, but that doesn't mean we have to support everything forever. Ok, let's stick to the original plan.

[sechkova]

I think this should be a reference to ADR 0001

[joshuagl]

Absolutely right, good catch!

[joshuagl]

Thank you all for continuing the discussion in my absence.

Many thanks for the great write-up, @joshuagl! In #1127 you talked about:

a deprecation strategy for the current release series [...] and
a deprecation/API stability strategy for releases after the refactor.

IIUC this document only addresses the former. Would you mind clarifying the distinction in the title (and maybe document name)?

Well spotted, thank you for the thorough review. I've pushed a fixup commit 8685898 which renames the document and changes the document title.

[lukpueh]

Please update link, other than that LGTM! :)

[lukpueh]

Suggested change

	-[ADR-0002](0002-deprecation-strategy.md) - Deprecation strategy
	-[ADR-0002](0002-pre-1-0-deprecation-strategy.md) - Deprecation strategy

[lukpueh]

Thanks for the updates, @joshuagl. No need to wait for appveyor here. Merging...