Re: [pbs-devel] [PATCH proxmox-backup v2 0/7] Add Prune Options to Sync Jobs

[Stefan Hanreich <s.hanreich@proxmox.com>]

On 11/30/22 17:23, Thomas Lamprecht wrote:
> Am 30/11/2022 um 16:00 schrieb Stefan Hanreich:
>> This patch adds the possibility of configuring prune options for sync jobs. This
>> runs a prune job after a successful sync job that prunes the backup groups that
>> got synced by the respective sync job (meaning this respects group-filter,
>> max-depth, target namespace and so on).
> 
> Why? Ain't the existing prune job and their flexible schedules enough? Why
> should one conflate syncing with pruning? Isn't that just complicating things
> (many interfaces that can do everything of other interfaces).
> 

It's what me and Fabian came up with in response to #3701. The idea 
behind it was that it would be a convenience feature, so one doesn't 
have to additionally assemble a second prune command with the exact same 
options. Particularly because this prune operation would honor the 
group-filter option from the sync job, which is currently not possible 
with prune jobs alone. Maybe we could approach it from the other way and 
make something like group-filter possible for prune jobs?

> Am 30/11/2022 um 16:00 schrieb Stefan Hanreich:
>>    Add KeepOptions parameters to pull & sync-job
>>    refactor prune.rs - add PruneJob struct for handling prune jobs
>>    Add pruning parameters to the pull command
>>    use new PruneJob in prune command
>>    use new PruneJob struct in Prune Jobs implementation
>>    add KeepOptions to Web UI of Sync Jobs
>>    Add documentation for prune options in Sync Jobs
> 
> having a lot of changelogs written, especially recently the lacks of human
> readable tags (e.g., "docs:", "ui:" "sync job:", ...) and mixed casing stuck
> quite out, even much more so the use of filenames in commit subjects which I
> already pointed out quite directly and visible as being useless and annoying.
> Structs are not always as worse, but not very often _that_ useful either for
> skimming a bigger git log or assembling change somewhat meaningful logs.
> 
I thought in this case it would be okay to include the filename, since I 
wasn't sure how to otherwise refer to the part of the code I refactored. 
I guess that was a lapse in judgement, would it be better to just refer 
to the respective functions? I also should have included the respective 
Bugzilla id for context. I don't know how I missed that in hindsight.