On Wed, 2 Mar 2022 at 07:12, Daniel Gustafsson <dan...@yesql.se> wrote:
> Thanks for picking it up and continuing with recent developments. Let me know > if you want a hand in triaging patchsets. While I have the time there may be patches I may need help coming to the right conclusions about what actions to take. I think the main thing I can do to help is to take patches that have no chance of making this release and taking them off our collective plates. -- Hopefully after they've received feedback but as this is the last commitfest of the release that's a secondary concern. But I'm unclear exactly what the consequences in the commitfest app are of specific state changes. As I understand it there are basically two alternatives: 1) Returned with feedback -- does this make it harder for an author to resume work release? Can they simply reactivate the CF entry or do they need to start a new one and then lose history in the app? 2) Moved to next commitfest -- this seems to just drag the pain on. Then it has to get triaged again next commitfest and if it's actually stalled (or progressing fine without needing feedback) that's just extra work for nothing. Do I have this right? What is the right state to put a patch in that means "this patch doesn't need to be triaged again unless the author actually feels progress has been made and needs new feedback or thinks its committable"? -- greg
