Repository navigation
Decide where to develop TUF 1.0.0 #1126
Description
Activity
Maybe I'm wrong, but I feel we can nuke the old code. Only a few people use it in production AFAICT, and it won't be terribly difficult to get them to upgrade.
I'd like to avoid nuking the old code because I worry how that might look and how long the refactor might take. I think we should do the refactor in the current tree and somewhat piecemeal – foundations (incl metadata API), then client, then repository lib, then new tools on top. Building up towards a 1.0 whilst continuing to make releases in the interim.
We could provide an API compatible client built on top of the metadata API and have that available to users even while the repository libs are still the old codebase.
I agree with both of you at different times, i.e. refactor first, then nuke the old code.
Reacted by Trishank Karthik KuppusamyThe more I think about it: the more I'm in favour of archiving 0.9.x in a permanent branch, and develop 1.0.0 in a clean slate on the default branch. I have a feeling this is a community meeting thing.
I’m advocating for doing the refactor in the current tree and somewhat piecemeal – foundations (incl metadata API), then client, then repository lib, then new tools on top. Building up towards a 1.0 whilst continuing to make releases in the interim.
At least in part I want to do this because I'm worried how the project looks if we just nuke everything and start building up a new implementation in the main branch. I'm also worried about maintaining multiple branches with a small team of contributors.
Reacted by Trishank Karthik Kuppusamy, Martin Vrachev and Marina MooreSeems like an agreement has been reached here. Is it the time for an ADR so that we move forward?
... of course I volunteer writing itReacted by Trishank Karthik KuppusamyReacted by Lukas PühringerReacted by Lukas PühringerIn case anyone is interested, I'm writing tuf-on-a-plane as a PoC. Will push there the code I've written when it's ready...
Reacted by Teodora Sechkova and Lukas PühringerI am volunteering too if there is work for both of us. :))
- added 3 commits that reference this issue
on Nov 23, 2020
The current plan is to implement TUF 1.0.0 alongside the current code base, in order to not disrupt existing usage and keep providing a Python 2.7 client (see #1125). We need to decide where to best develop the new TUF. A few ideas:
In its own repo
Con: Given limited engineering power, the old repo is prone to bit rot while we work on the other.
In a separate develop branch of the current tuf implementation
Con: Similar to above + git mental overhead
In a subdirectory of the current tuf implementation (which we already do see Add simple TUF role metadata model #1112)
Con: Messiness in plain sight.