-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decide where to develop TUF 1.0.0 #1126
Comments
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. |
The 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. |
Seems like an agreement has been reached here. Is it the time for an ADR so that we move forward? |
In 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... |
I am volunteering too if there is work for both of us. :)) |
Document the outcome of theupdateframework#1126 to develop TUF 1.0.0 in a subdirectory of the current TUF implementation. Signed-off-by: Teodora Sechkova <[email protected]>
Document the outcome of theupdateframework#1126 to develop TUF 1.0.0 in a subdirectory of the current TUF implementation. Signed-off-by: Teodora Sechkova <[email protected]>
Document the outcome of theupdateframework#1126 to develop TUF 1.0.0 in a subdirectory of the current TUF implementation. Signed-off-by: Teodora Sechkova <[email protected]>
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.
The text was updated successfully, but these errors were encountered: