yt
yt copied to clipboard
yt-project
DOC: update "how to release" docs
PR Summary
close https://github.com/yt-project/yt/issues/3448
I sill have a couple questions that would need answers to complete this:
- I don't know what to do with the "Uploading to yt-project.org" section. Should it be dropped, or updated ? (apparently it hasn't been used since the 3.6.1 release)
- should we archive yt-project/yt-wheels ?
- is
pr_backport.pystill usable/maintained ? Do we want to keep it ? - what about documentation ? I do not know at which stage this happens or wether it's been automated
I've also written this in the assumption that #3758 gets merged
Don't think I can help resolve the open questions but I will say the updated docs read nicely! Except for the pr_backport.py bit, which I was confused by until I re-read the open question about whether or not that section should be removed entirely.
We can probably get rid of the pr backport stuff since we now use a backport service.
This seems to be blocked for lack of a consensus. I still believe the docs should reflect current and actual release practices, but if we can't resolve this discussion I'd rather close this PR than leave it hanging forever.
I think all of us believe the docs should reflect current release practices. The issues on consensus here were because proposed changes deviated from existing practices at the time. I suspect you can find consensus with reviewers here but you'll need to re-engage in conversation rather than closing the PR.
I suspect you can find consensus with reviewers here but you'll need to re-engage in conversation rather than closing the PR.
For the record I did that 2 weeks ago and didn't get any answers since. I don't have the bandwidth needed to cling to dead conversations for years, and I will close this sooner rather than later.
Your tone here feels argumentative, and I don’t want to escalate conflict. I’m cognizant of the fact that you’ve put a lot of effort into this project and this PR. However, the changes that you’ve proposed still put in place a policy rather than exclusively documenting our release practices. Changing policy necessitates community consensus. Ending the conversation in this PR without closing the loop regarding the feedback that you’ve been given would be fairly disrespectful of the time that I (and the other reviewers) have also invested in review. I think we all want this to succeed, and any critiques that we’ve provided have been for the purpose of strengthening the published docs here.
Ending the conversation in this PR without closing the loop regarding the feedback that you’ve been given would be fairly disrespectful of the time that I (and the other reviewers) have also invested in review.
I've been trying to close the loop the right way but I've been waiting for an answer on your part for over a year now. At this point, my priority has shifted from making this PR succeed to getting out of the conversation. I am sorry that you feel your time is being disrespected but so do I.
You're both right that this PR has sat idle for a long while, and it should be addressed for everyone's benefit. Let's figure out a solution, so we can move forward with things.
It seems like the hold up is on the policy surrounding deprecation and then removal between subsequent minor releases. Right now, the policy that is effectively being stated in this docs PR is one of allowing for code that can be deprecated in one minor version and then removed in the subsequent minor version. What this means is that a user could be on version 4.0 using some function/class, then upgrade to 4.2 and their scripts could be broken without any notice. I'm not sure I really like that. As a user, I can see where that would be sufficiently problematic to potentially quit using a code. Is there any problem with just having deprecations remain until a major release (i.e., 5.0) when they get removed?
I'm not sure where the best place to have this policy discussion is other than a PR conversation, just to make sure everyone knows about a potential policy change.
After a fresh read of the relevant discussion, let's move this forward -- @neutrinoceros, please make a YTEP PR outlining a deprecation proposal. If you don't have time to do it now, then someone else should volunteer to do it and make sure that @neutrinoceros's proposal is correctly expressed as outlined here. That's the right venue for it and we can make sure it gets out to yt-dev. We can set a reasonable deadline for comments/changes/feedback.
On the basis of the results of that we can return to this--we should aim to finish this up within a month if possible.
To resolve the current issue and merge this PR, is it possible to just remove the text surrounding the deprecation cycle policy that still seems under discussion? I don't think there are any hangups on the remaining text in this particular PR, so once that gets removed, I think we can merge the rest of this. Then we can discuss the deprecation policy in a YTEP or in one of the user+dev group meetings that we'll be having in the next couple of months? How does that sound as a means forward for everyone?
I reverted my changes to the paragraph "minor releases" (I hope that's the one you were talking about). I did start to draft a YTEP to formalise my proposed deprecation policy, but it's not ready yet.
Okay I think enough time has passed now that I can consider there are no objections to merging in the current state, so let's try getting this in: @yt-fido test this please
@neutrinoceros not a big deal, but next time could you get somebody else to merge? I don't think we were waiting on anything, but self-merging after the big discussion is a bit tricky.