Vagrant Cascadian writes: > [[PGP Signed Part:Undecided]] > On 2022-12-08, Christopher Baines wrote: >> Only suggest waiting one week for review for simpler changes, wait two weeks >> for more significant changes. > ... >> +Changes should be posted to @email{guix-patches@@gnu.org}. This mailing >> +list fills the patch-tracking database (@pxref{Tracking Bugs and >> +Patches}). It also allows patches to be picked up and tested by the >> +quality assurance tooling; the result of that testing eventually shows >> +up on the dashboard at >> +@indicateurl{https://qa.guix.gnu.org/issue/@var{number}}, where >> +@var{number} is the number assigned by the issue tracker. Leave time >> +for a review, without committing anything (@pxref{Submitting Patches}). >> +If you didn’t receive any reply after one week (two weeks for more >> +significant changes), and if you're confident, it's OK to commit. > > My one concern here for things that I tend to work on is > diffoscope... it has such a large dependency graph(?) because it > supports so many file formats, it pulls in quite a lot for the test > suites... > > In a week or two of changes between submission and being able to push to > master, I'd worry that you could end up with a diffoscope that wouldn't > build because of changes to one of it's (native-)inputs or whatnot > because of changes to master in the previous week... > > > That said, overall, I think sending everything through guix-patches is a > good change, even if my lazier self pouts a little at having to deal > with more process for seemingly simple things. :) I think that's a valid concern. The QA tooling is affected similarly, in that it tests against the latest processed revision when the patch is picked up, but things could change in between the testing happening and it being merged. Remember that these time periods are only when no review takes place. My hope is that manual review can happen sooner than one or two weeks after patch submission, therefore enabling making changes more quickly. Thanks, Chris