Skip to content
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

Closed
lukpueh opened this issue Sep 10, 2020 · 8 comments · Fixed by #1220
Closed

Decide where to develop TUF 1.0.0 #1126

lukpueh opened this issue Sep 10, 2020 · 8 comments · Fixed by #1220
Labels
decision record Outcome of this discussion should be tracked in a decision record discussion Discussions related to the design, implementation and operation of the project documentation Documentation of the project as well as procedural documentation

Comments

@lukpueh
Copy link
Member

lukpueh commented Sep 10, 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.

@lukpueh lukpueh added the discussion Discussions related to the design, implementation and operation of the project label Sep 10, 2020
@joshuagl joshuagl added the documentation Documentation of the project as well as procedural documentation label Sep 10, 2020
@lukpueh lukpueh added the decision record Outcome of this discussion should be tracked in a decision record label Sep 10, 2020
@trishankatdatadog
Copy link
Member

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.

@joshuagl
Copy link
Member

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.

@lukpueh
Copy link
Member Author

lukpueh commented Sep 11, 2020

I agree with both of you at different times, i.e. refactor first, then nuke the old code.

@trishankatdatadog
Copy link
Member

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.

@joshuagl
Copy link
Member

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.

@sechkova
Copy link
Contributor

Seems like an agreement has been reached here. Is it the time for an ADR so that we move forward?
... of course I volunteer writing it

@trishankatdatadog
Copy link
Member

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...

@MVrachev
Copy link
Collaborator

I am volunteering too if there is work for both of us. :))

sechkova added a commit to sechkova/tuf that referenced this issue Nov 23, 2020
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]>
sechkova added a commit to sechkova/tuf that referenced this issue Nov 24, 2020
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]>
sechkova added a commit to sechkova/tuf that referenced this issue Nov 27, 2020
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
decision record Outcome of this discussion should be tracked in a decision record discussion Discussions related to the design, implementation and operation of the project documentation Documentation of the project as well as procedural documentation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants