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

Handing this create to Release Engineering #5

Closed
jsdw opened this issue Jan 6, 2023 · 5 comments
Closed

Handing this create to Release Engineering #5

jsdw opened this issue Jan 6, 2023 · 5 comments

Comments

@jsdw
Copy link
Collaborator

jsdw commented Jan 6, 2023

I'd propose that, now Substrate crates are being released automatically using a branched version of this tool, that we have no need to keep the tool around in its current form and it can be taken on by the @paritytech/release-engineering guys to modify as they see fit for the automated releasing.

Any objections?

CC @ascjones @paritytech/tools-team

@chevdor
Copy link
Contributor

chevdor commented Jan 9, 2023

cc @joao-paulo-parity as he has been working on that topic recently.

@joao-paulo-parity
Copy link

I'm fine with the plan in general, just have one remark about this part

now Substrate crates are being released automatically using a branched version of this tool, that we have no need to keep the tool around in its current form

For context I'll post an exchange between me and @jsdw on Matrix

JP: That releng branch is WIP and currently doesn't cater to the same use-cases as the current subpub master, so I think you'll still need the current implementation for the time being.

James: It doesn't cater to the same use cases, but with your work, I don't think we need the original Subpub use cases any more (I only wrote it to help release substrate crates, and you're automating that now anyway :)

To me the biggest difference between those branches lies within expectations. I expect - and it might be a wrong expectation since I'm an "outsider" to this project - that the current subpub implementation is tailored for humans, i.e. meant for whoever wants to use the tool manually from the CLI. That's not the case for the WIP branch which currently

  • Is only meant to be used by Release Engineering's scripts, which has further implications e.g. CLI options might be unintuitive since no effort has gone into making them user-friendly
  • Has under-development features which offer no stability guarantees
  • Doesn't take into account any consumers which are not Release Engineering's scripts

Moving the code to master, from my viewpoint, entails more than simply "having code that works": it opens the implementation for general use and all the implications that come with it. I don't see any benefit in doing that at the moment for the WIP branch given the circumstances mentioned above. Not only the features, but even the use-cases are still being planned. For instance, we'll still have to fit it for different publishing strategies for each repository (see https://github.com/paritytech/release-engineering/issues/143#issuecomment-1363961410) and that effort has only started recently. Eventually the implementation should take not-Release-Engineering users into account and be tailored for a broader public - that's when, to me, it would make sense to prep it for master (and there's a ticket for that already).

On another note, by #4 and #2 I infer that subpub already has some users. Since the WIP branch doesn't work the same way as master does, I first thought it'd be sensible to keep master's implementation until the WIP branch can cater to the same use-cases. However, given @jsdw 's response we wouldn't need to care about the current use-cases anymore, which means having less things to do before upstreaming the changes; still, for all the reasons laid out above, I don't like the idea of moving the WIP branch to master at the moment.

From my perspective we should keep the branches as-is until https://github.com/paritytech/release-engineering/issues/140 is ready, i.e. until the code of the WIP branch can transition into master. If you no longer want to maintain master's implementation I suggest simply putting up a notice in the README for the time being.

@jsdw
Copy link
Collaborator Author

jsdw commented Jan 10, 2023

#4 and #2 are just us trying to release Substrate crates manually, because there was no process in place.

So unless anybody else pipes up, I think that this tool was only ever used by us trying to release the odd Substrate crates as needed occasionally for Subxt. So as far as I'm concerned, you are welcome to take this repository on and build what you like for the automated releasing, or fork it or whatever else you're comfortable with :)

@chevdor
Copy link
Contributor

chevdor commented Aug 23, 2023

cc @Morganamilo

In the end, I don't think we will need subpub for the crates release so I am closing this issue. Please feel free to re-open if I missed a point that would motivate keeping this issue open.

@jsdw you mentioned there may still be usage for the tool so we can simply keep it as it is.

@chevdor chevdor closed this as completed Aug 23, 2023
@jsdw
Copy link
Collaborator Author

jsdw commented Aug 23, 2023

Yeah happy to leave it as is :) I'm not sure what the plan is now for automated crate releases, but of course if this tool can help there then I'm happy to help make it so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants