On Tue, Aug 18, 2020 at 6:25 PM Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > > On Tue, Aug 18, 2020 at 05:21:59PM +0300, Amir Goldstein wrote: > > On Tue, Aug 18, 2020 at 2:24 AM Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > > > > > > From: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > > > > > > Define explicit limits on the range of quota grace period expiration > > > timeouts and refactor the code that modifies the timeouts into helpers > > > that clamp the values appropriately. > > > > > > Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > > > > There is no refactoring here, but I suppose you want to keep the commit > > names aligned with kernel commits, so > > FWIW, these patches of mine where (1) 'xfs: ' is in the subject; (2) the > changes only touch things in libxfs and the bare minimum to avoid build > breakage; and (3) whose commit log don't really match the changes are > straight ports of the kernel-space patches. > > I hesitate to use the libxfs-apply script for these patches (even though > Eric will do that when he's resyncing for real) because the source > commit ids will probably never match what ends up in Linus tree. > > I don't know if anyone /else/ follows this convention, but in my > xfsprogs series, I try to prefix patches that change /only/ userspace > libxfs with the tag 'libxfs: ', so that reviewers can spend more time on > the patches that tag either libxfs directly or some userspace program. > > That said, this is really not obvious. I've wondered if I should amend > libxfs-apply to be able to quote the source commit subject line so that > it's more obvious when a patch is simply a userspace port. Would that > help? > This wasn't a problem for me when reviewing the patches. Kernel patches were fresh in my head and I could tell when patches were partially applied. I think it is more of a concern for long term maintenance of xfsprogs - having patches with obscure commit messages that do not match the change, so it is really up to Eric and you guys as main stakeholders. FWIW, quoting the kernel source commit sounds like a good idea. Thanks, Amir.
