Le lundi 15 février 2021 à 13:52 +0100, Andreas Tille a écrit : > On Sat, Feb 13, 2021 at 04:29:59PM +0100, Sébastien Villemot wrote: > > > That's correct but no argument against using an automated tool. > > > > Sure. But there is the risk of forgetting to do the manual task > > associated to what the tool has done automatically. I like to be forced > > to do something manually in order not to forget those steps. > > > > Maybe routine-update could be improved by printing a message about what > > has to be done manually whenever it does something automatically (e.g. > > checking the copyright/licences changes, > > Routine-update does *nothing* with copyright/licenses. I have no idea > how to automate this step and its up to the maintainer (no matter > whether an automated tool is used or not). Actually I was just suggesting that routine-update print a message to remind that copyright/licenses need to be verified. Also note that there exist tools for updating d/copyright more or less automatically, but none is a perfect substitute to manual intervention. > > checking the policy upgrade > > list, checking the debhelper compat level upgrade list). > > I've just pushed this[1]. Thanks for that. > > > I admit I simply trust lintian to do this job. > > > > In practice there are many aspects of the policy that are not checked > > by lintian. > > > > lintian-brush does some of those upgrades automatically, but only for > > specific pairs of older/newer policy versions, when it can be > > ascertained automatically that compliance is effective. > > That's true. But honestly, what policy breaking changes do you expect > in R package upgrades? I was speaking on a general level. I agree that for R packages, since they almost all follow the same structure, the risk is lesser (and if something needs to be updated, an ad hoc change to routine-update could be implemented to update all packages). > > > If the package builds correctly and passes its autopkgtest I assume the > > > compat level bump had no negative effect and should be done. > > > > Again, that is not generally true. It is impossible in practice to > > create an autopkgtest that checks every aspect of a package. > > Yes. In R packages we are checking what upstream provides as test. Do > you want to tell me you are testing more in the R packages you are > maintaining. How should this scale for nearly 1000 R packages? The > motivation of writing routine-update was the perception that we are not > doing very well in coping with frequent upstream changes and the Debian > R ecosystem tended to lag behind upstream more and more. Thanks to > routine-update we manage quite OK to be up to date with upstream in > unstable - at least to my perception - and thus detect required new > packages sufficiently well to be in sync with upstream at freeze time. > (It should probably discussed in a separate thread whether we stop > upgrading packages now since we are in soft freeze or whether we > should upload new upstream versions until hard freeze.) > > I personally would not manage to upload more than 1000 packages per > year[2] without that level of automatisation. I think expecting the > team will increase by about 10 maintainers sharing that work amongst > each other doing the manual inspection you seem to prefer is not > realistic. I perfectly understand your point, and I am not criticizing the way you’re doing things. Basically you’ve taken an approach which consists in detecting some problems ex post rather than ex ante, because doing all ex ante checks would not be practically feasible. I think this is a perfectly reasonable approach, given the constraints that you’re facing. I was just trying to explain why I prefer not to use a fully automated approach. But I admit that my workflow would probably not manageable if I were maintaining more R packages than I currently do (i.e. only a dozen). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ https://www.debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part