-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Conversation
14e91c6
to
31a254b
Compare
could you backport the rest of the commits of #4795? |
Please no auto merge here, I would like to update the substrate deps once paritytech/substrate#10742 is merged and then merge that one. |
I really don't want to. I checked, functionality wise it is the same. This waiting for CI to finally carry on with tasks is driving me crazy - I want that to finally stop. |
I would prefer a workflow next time, where fixes just go to the release branch and once the release is done, we merge the release branch to master. - Would be way less tedious and error prone. I don't care if @drahnr disagrees 😉 - this manually keeping stuff in sync is just crazy. If we just open a PR, like any other, it would also be quite hard to forget that merge. |
If we only have one release at a time, this might work sufficiently well, iff and only iff master doesn't move too fast. As soon as one has more than one release branch at the same time or master picking up with our team growth, this will become a mess. |
It seems the real problem here is long CI times. My main concern if we're to backport some urgent changes for 0.9.17 to 0.9.16 branch we might end up fixing some merge conflicts, which is unnecessary. |
Once the release is out, this is a different thing- then I am actually fine with back-porting. I am only concerned with the release branch prior to release. |
Yes, long CI times are a big source of delays. Amplified by unnecessary/unknown changes, which cause PRs to fail, although they worked fine when based on master. So you end up not only waiting once for CI, but several times for a single stupid PR, that actually was already fine on master. |
* fixup * fmt * fix tests
Could you please change the base so we merge this PR into |
Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
ecbed48
to
990b8b4
Compare
No description provided.