Re: MRs on salsa and letting janitor automate things
Hi Dima, * Dima Kogan [2022-12-02 13:53]: The reason is that a package that has Build-Depends: debhelper-compat (=13) will fail to build on any older distro. I maintain some tools where I provide packages for a number of distros, and adding such a Build-Depends would mean I need to do extra work to build the packages. One example of such a project is mrcal. It's in Debian, maintained in debian-science. Its debian/control debhelper dependency: https://salsa.debian.org/science-team/mrcal/-/blob/master/debian/control#L7 If a user of another distro wants to install these tools, they can get them from the mrcal APT server. Public instructions: http://mrcal.secretsauce.net/install.html When building packages for the other distros, I generally just sbuild the same tree using the chroot for the target distro. This would fail with debhelper-compat. From the site those other distros are buster, bullseye, jammy, focal, bionic. For all those debhlper 13 is available (in backports): https://packages.debian.org/search?keywords=debhelper=names=all=all https://packages.ubuntu.com/search?suite=all=names=debhelper Given that new debhelper versions can contain important fixes and that relying on it's magic could create implicit dependencies, I really recommend to use the backported versions. Cheers Jochen signature.asc Description: PGP signature
Re: MRs on salsa and letting janitor automate things
Hi. Andreas Tille writes: > IMHO its sensible to follow the latest toolset version sooner or > later. There are several sensible features and if your packages are > vanilla and simple there is no good reason to stick to any specific > debhelper compat version. The reason is that a package that has Build-Depends: debhelper-compat (=13) will fail to build on any older distro. I maintain some tools where I provide packages for a number of distros, and adding such a Build-Depends would mean I need to do extra work to build the packages. One example of such a project is mrcal. It's in Debian, maintained in debian-science. Its debian/control debhelper dependency: https://salsa.debian.org/science-team/mrcal/-/blob/master/debian/control#L7 If a user of another distro wants to install these tools, they can get them from the mrcal APT server. Public instructions: http://mrcal.secretsauce.net/install.html When building packages for the other distros, I generally just sbuild the same tree using the chroot for the target distro. This would fail with debhelper-compat. (Well, I need to update debian/changelog too, but I shouldn't have to do that either. One issue at a time)
Re: MRs on salsa and letting janitor automate things
Hi Jelmer, Am Thu, Dec 01, 2022 at 04:04:13PM + schrieb Jelmer Vernooij: > One of the things you don't get when running these scripts manually rather > than > waiting or the janitor is that it verifies the package still builds, passes > autotests and generates binary diffs before proposing/pushing changes. Great. But I'm doing these build as well when dealing with the package. ;-) > Although > you do get a lot of those benefits either way, since most of lintian-brush's > bug fixes are driven by the janitor running it across the entire archive. > > Actually, I'm curious what you prefer about routine-update vs the janitor > pushing/creating PRs? Is it just that you control the moment you work on a > package vs having the changes pushed/proposed by an external agent? I simply prefer triggering any changes myself. The tools used by Janitor are really cool and helpful - so thanks for the great work. I simply see no advantage if "someone else" does random commits to the package I'm working on. > > Routine-update is calling lintian-brush which is IMHO what Janitor is > > doing. Jelmer in CC in case I should run more scripts. > > The janitor currently has the following "campaigns" that are part of its > default set: > > * lintian-fixes (fixes various lintian-reported issues) > * apply-multiarch-hints (applies hints from the Multi-Arch hinter) > * deb-scrub-obsolete (remove no longer necessary dependencies, maintscripts, > migrates away from dependencies on transitional >packages) > * orphan (update maintainer for orphaned packages to QA team) > * mia (drop uploaders who have been marked as MIA by the MIA team) I'm happy about all these things done by lintian-brush. > And several that are enabled for a select set of people only, not ready for > mainstream (yet?): > > * fresh-releases (merges new upstream releases, refreshes patches, bumping >dependency versions, etc) > * uncommitted (import archive changes not in VCS, e.g. for NMUs) Thanks a lot for your cool QA tools Andreas. -- http://fam-tille.de
Re: MRs on salsa and letting janitor automate things
(re-sending from my personal address, since I don't have debian.org set up correctly here) On Thu, Dec 01, 2022 at 04:35:02PM +0100, Andreas Tille wrote: > Hi again, > > Am Thu, Dec 01, 2022 at 01:55:43PM +0100 schrieb PICCA Frederic-Emmanuel: > > > As I tried to explain, routine-update does all what Janitor is doing > > > (please let me know if not than I'd include the actual Janitor code) > > > plus other things Janitor can't do. I'm fine with whatever the team > > > might prefer and I can cope with Janitor changes, but its not my > > > preference. > > > > It seems to me that a script provided by janitor should be used by > > routine-update in order to avoid this problem. > > This *is* the case and perfectly intendend. One of the things you don't get when running these scripts manually rather than waiting or the janitor is that it verifies the package still builds, passes autotests and generates binary diffs before proposing/pushing changes. Although you do get a lot of those benefits either way, since most of lintian-brush's bug fixes are driven by the janitor running it across the entire archive. Actually, I'm curious what you prefer about routine-update vs the janitor pushing/creating PRs? Is it just that you control the moment you work on a package vs having the changes pushed/proposed by an external agent? > > Is there a sort of generic command in janitor which run all the janitors > > scripts ? > > Routine-update is calling lintian-brush which is IMHO what Janitor is > doing. Jelmer in CC in case I should run more scripts. The janitor currently has the following "campaigns" that are part of its default set: * lintian-fixes (fixes various lintian-reported issues) * apply-multiarch-hints (applies hints from the Multi-Arch hinter) * deb-scrub-obsolete (remove no longer necessary dependencies, maintscripts, migrates away from dependencies on transitional packages) * orphan (update maintainer for orphaned packages to QA team) * mia (drop uploaders who have been marked as MIA by the MIA team) And several that are enabled for a select set of people only, not ready for mainstream (yet?): * fresh-releases (merges new upstream releases, refreshes patches, bumping dependency versions, etc) * uncommitted (import archive changes not in VCS, e.g. for NMUs) Cheers, Jelmer
Re: MRs on salsa and letting janitor automate things
On Thu, Dec 01, 2022 at 04:35:02PM +0100, Andreas Tille wrote: > Hi again, > > Am Thu, Dec 01, 2022 at 01:55:43PM +0100 schrieb PICCA Frederic-Emmanuel: > > > As I tried to explain, routine-update does all what Janitor is doing > > > (please let me know if not than I'd include the actual Janitor code) > > > plus other things Janitor can't do. I'm fine with whatever the team > > > might prefer and I can cope with Janitor changes, but its not my > > > preference. > > > > It seems to me that a script provided by janitor should be used by > > routine-update in order to avoid this problem. > > This *is* the case and perfectly intendend. One of the things you don't get when running these scripts manually rather than waiting or the janitor is that it verifies the package still builds, passes autotests and generates binary diffs before proposing/pushing changes. Although you do get a lot of those benefits either way, since most of lintian-brush's bug fixes are driven by the janitor running it across the entire archive. Actually, I'm curious what you prefer about routine-update vs the janitor pushing/creating PRs? Is it just that you control the moment you work on a package vs having the changes pushed/proposed by an external agent? > > Is there a sort of generic command in janitor which run all the janitors > > scripts ? > > Routine-update is calling lintian-brush which is IMHO what Janitor is > doing. Jelmer in CC in case I should run more scripts. The janitor currently has the following "campaigns" that are part of its default set: * lintian-fixes (fixes various lintian-reported issues) * apply-multiarch-hints (applies hints from the Multi-Arch hinter) * deb-scrub-obsolete (remove no longer necessary dependencies, maintscripts, migrates away from dependencies on transitional packages) * orphan (update maintainer for orphaned packages to QA team) * mia (drop uploaders who have been marked as MIA by the MIA team) And several that are enabled for a select set of people only, not ready for mainstream (yet?): * fresh-releases (merges new upstream releases, refreshes patches, bumping dependency versions, etc) * uncommitted (import archive changes not in VCS, e.g. for NMUs) Cheers, Jelmer
Re: MRs on salsa and letting janitor automate things
Hi again, Am Thu, Dec 01, 2022 at 01:55:43PM +0100 schrieb PICCA Frederic-Emmanuel: > > As I tried to explain, routine-update does all what Janitor is doing > > (please let me know if not than I'd include the actual Janitor code) > > plus other things Janitor can't do. I'm fine with whatever the team > > might prefer and I can cope with Janitor changes, but its not my > > preference. > > It seems to me that a script provided by janitor should be used by > routine-update in order to avoid this problem. This *is* the case and perfectly intendend. > Is there a sort of generic command in janitor which run all the janitors > scripts ? Routine-update is calling lintian-brush which is IMHO what Janitor is doing. Jelmer in CC in case I should run more scripts. Kind regards Andreas. -- http://fam-tille.de
Re: MRs on salsa and letting janitor automate things
> As I tried to explain, routine-update does all what Janitor is doing > (please let me know if not than I'd include the actual Janitor code) > plus other things Janitor can't do. I'm fine with whatever the team > might prefer and I can cope with Janitor changes, but its not my > preference. It seems to me that a script provided by janitor should be used by routine-update in order to avoid this problem. Is there a sort of generic command in janitor which run all the janitors scripts ? Cheers Fred
Re: MRs on salsa and letting janitor automate things
Hi Stuart, Am Wed, Nov 30, 2022 at 10:58:06AM +1100 schrieb Stuart Prescott: > > While there is a substantial overlap in the feature sets, one is not a > subset of the other. > > - routine-update does some great things like normalising packaging. That's > something Janitor can't do because people would scream about an automated > tool touching their precious whitespace. > > - Janitor applies multi-arch hints, and looks at obsolete versioned > dependencies — these are things that routine-update can't do because it > doesn't have a holistic view of the archive. That's not true since routine-update calls the same routines as Janitor. > Janitor is also run > automatically rather than only when the maintainer is seeking to update the > package, meaning that improvements can accrue over time. IMHO that's quite some advantage. I see no relevance in changes that are just end up inside the git repository and are possibly bit-rotting there. > Janitor updates > also cause CI to be run, meaning that regressions such as a FTBFS caused by > other packages changing get spotted earlier. That's a valid point. > I don't see any reason to say that tools are mutually exclusive — let's let > Janitor make improvements and when packages need updating, we can have > routine-update make some more? As I tried to explain, routine-update does all what Janitor is doing (please let me know if not than I'd include the actual Janitor code) plus other things Janitor can't do. I'm fine with whatever the team might prefer and I can cope with Janitor changes, but its not my preference. Kind regards Andreas. -- http://fam-tille.de
Re: MRs on salsa and letting janitor automate things
Hi Dima, Am Tue, Nov 29, 2022 at 06:56:02PM -0800 schrieb Dima Kogan: > Hi Nilesh and Stuart. That email on debian-devel describes my use case > well. My packages are vanilla-enough that there's little value in doing > anything more than Build-Depends: debhelper (>=11) and sticking "11" in > debian/compat or something like that. Let me know if this has some major > downsides I'm not seeing. IMHO its sensible to follow the latest toolset version sooner or later. There are several sensible features and if your packages are vanilla and simple there is no good reason to stick to any specific debhelper compat version. Kind regards Andreas. -- http://fam-tille.de
Re: MRs on salsa and letting janitor automate things
Hi Nilesh and Stuart. That email on debian-devel describes my use case well. My packages are vanilla-enough that there's little value in doing anything more than Build-Depends: debhelper (>=11) and sticking "11" in debian/compat or something like that. Let me know if this has some major downsides I'm not seeing. Thanks!
Re: MRs on salsa and letting janitor automate things
Hi Andreas I admit I share the old fashioned view and we asket Jelmer to not run Janitor on Debian Med and R-pkg-team. The rationale is that we are running routine-update on all our packages. Routine-update is running all scripts that are called by Janitor and thus you have the same effect. It's not quite the same effect. While there is a substantial overlap in the feature sets, one is not a subset of the other. - routine-update does some great things like normalising packaging. That's something Janitor can't do because people would scream about an automated tool touching their precious whitespace. - Janitor applies multi-arch hints, and looks at obsolete versioned dependencies — these are things that routine-update can't do because it doesn't have a holistic view of the archive. Janitor is also run automatically rather than only when the maintainer is seeking to update the package, meaning that improvements can accrue over time. Janitor updates also cause CI to be run, meaning that regressions such as a FTBFS caused by other packages changing get spotted earlier. I don't see any reason to say that tools are mutually exclusive — let's let Janitor make improvements and when packages need updating, we can have routine-update make some more? regards Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: MRs on salsa and letting janitor automate things
Moin, Am Tue, Nov 29, 2022 at 06:38:00PM +0100 schrieb Christian T. Steigies: > > I admit I share the old fashioned view and we asket Jelmer to not > > run Janitor on Debian Med and R-pkg-team. The rationale is that > > we are running > > > > routine-update > > This sounds cool, but I have not heard of this before, maybe its time to > revive your package-of-the-day posts again? I'm advertising routine-update from time to time here. I do not remember that package-of-the-day posts were done by me. ;-) Kind regards Andreas. -- http://fam-tille.de
Re: MRs on salsa and letting janitor automate things
Moin, On Tue, Nov 29, 2022 at 10:58:19AM +0100, Andreas Tille wrote: > Hi, > > I admit I share the old fashioned view and we asket Jelmer to not > run Janitor on Debian Med and R-pkg-team. The rationale is that > we are running > > routine-update This sounds cool, but I have not heard of this before, maybe its time to revive your package-of-the-day posts again? Christian
Re: MRs on salsa and letting janitor automate things
Hi, Am Sun, Nov 27, 2022 at 08:29:58AM -0400 schrieb David Bremner: > > Personally I often find it hard to prioritize understanding the MRs from > the janitor, and I'm not comfortable with having a bot commit to a repo > that I am responsible for. Perhaps I'm just old fashioned. I'm an > uploader only for a tiny fraction of the team's packages, so my views > should not block anything. I guess I can always pull a few packages from > the team space on Salsa. I admit I share the old fashioned view and we asket Jelmer to not run Janitor on Debian Med and R-pkg-team. The rationale is that we are running routine-update on all our packages. Routine-update is running all scripts that are called by Janitor and thus you have the same effect. However, these changes are made under actual observation when the developer is intending to work on the package possibly with the goal for an upload. I personally prefer routine-update over Janitor and I'd recommend to regularly use it since besides sensible upgrade features it also normalises the format of the team maintained packages. I'm running routine-update -f on packages where no new upstream is available but if I have other reasons to work on the package. Kind regards Andreas. -- http://fam-tille.de
Re: MRs on salsa and letting janitor automate things
Am Mon, Nov 28, 2022 at 09:58:33AM + schrieb Jelmer Vernooij: > debhelper-c that > carries debhelper 13. If you're looking to avoid anything that's not available > in e.g. oldstable or ubuntu lts rather than specifically excluding > "debhelper-compat (= X)", the janitor also has a setting for the minimum > release > to support. Compat=13 forces dh_missing --fail-missing which in several cases breakt the build. While I think compat=13 is a good move and switch all packages I'm touching to it its a change which causes breaks and I can understand developers who do not like it. Kind regards Andreas. -- http://fam-tille.de
Re: MRs on salsa and letting janitor automate things
Stuart Prescott writes: > On 27/11/2022 19:30, Julien Puydt wrote: >> Perhaps people didn't get notified they had MRs ? > > Entirely possible, hence the suggestions in my message were that we should: > > a) automate what can be automated so that attention is not needed > > b) check our individual salsa notification settings for repos we care about I, too, miss MRs until I stumble across them months later, usually by seeing that little exclamation mark stand out on my DDPO page. It's a shame that there doesn't seem to be a setting along the lines of "email me about MRs (and issues) in any project that I am an owner of or that a team I am a member of owns". Or does it, and I just missed it? Best, Gard signature.asc Description: PGP signature
Re: MRs on salsa and letting janitor automate things
On 28/11/2022 18:22, Nilesh Patra wrote: On Mon, Nov 28, 2022 at 05:45:02PM +1100, Stuart Prescott wrote: On 28/11/2022 10:55, Dima Kogan wrote: Hi. I've been manually checking the merge requests, and have been accepting most of them. There is one thing the janitor does that I don't agree with, and I'd be against any automated merging of those patches. This is adding Build-Depends: debhelper-compat (=WHATEVER). Such dependencies break building of the package on anything other than sid, and are thus unhelpful. If you can stop the janitor from making this change, that'd probably be good. Can you expand on this a bit? There are plenty of packages with B-D on debhelper-compat (= 13) that are backported to the current stable and oldstable releases without any changes. I _suppose_ this is their use-case: https://lists.debian.org/debian-devel/2022/07/msg00304.html I short, Dima maintains apt repos for packages that are used in many distributions and setting compat as 13 or whatever breaks the build for them. Sounds like throwing a backport of debhelper into the local repos for backports would be a good idea too. It's a trivially backportable package which then lets everything else backport more easily. (Dima, please let me know if I can help with that) Thanks for the extra context, Nilesh! cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: MRs on salsa and letting janitor automate things
On Mon, Nov 28, 2022 at 08:42:59AM +0530, Nilesh Patra wrote: > On Sun, Nov 27, 2022 at 03:55:05PM -0800, Dima Kogan wrote: > > Hi. I've been manually checking the merge requests, and have been > > accepting most of them. There is one thing the janitor does that I don't > > agree with, and I'd be against any automated merging of those patches. > > This is adding Build-Depends: debhelper-compat (=WHATEVER). Such > > dependencies break building of the package on anything other than sid, > > and are thus unhelpful. If you can stop the janitor from making this > > change, that'd probably be good. > > > > That sounds reasonable. I am adding in Jelmer to the thread, so they could > help tweak it for debian-science@ commits/MRs Done, see https://salsa.debian.org/jelmer/janitor.debian.net/-/commit/465c8a43ad2e70f2acd0f8f8928f80771ed6d483 Please let me know if I should tweak that further, e.g. exclude certain packages or keep certain packages backportable to oldstable. debhelper-c
Re: MRs on salsa and letting janitor automate things
On Mon, Nov 28, 2022 at 05:45:02PM +1100, Stuart Prescott wrote: > On 28/11/2022 10:55, Dima Kogan wrote: > > Hi. I've been manually checking the merge requests, and have been > > accepting most of them. There is one thing the janitor does that I don't > > agree with, and I'd be against any automated merging of those patches. > > This is adding Build-Depends: debhelper-compat (=WHATEVER). Such > > dependencies break building of the package on anything other than sid, > > and are thus unhelpful. If you can stop the janitor from making this > > change, that'd probably be good. > > Can you expand on this a bit? There are plenty of packages with B-D on > debhelper-compat (= 13) that are backported to the current stable and > oldstable releases without any changes. I _suppose_ this is their use-case: https://lists.debian.org/debian-devel/2022/07/msg00304.html I short, Dima maintains apt repos for packages that are used in many distributions and setting compat as 13 or whatever breaks the build for them. But I do agree with you. In debian sid/testing/backporting pov, this does not make any difference. -- Best, Nilesh signature.asc Description: PGP signature
Re: MRs on salsa and letting janitor automate things
Hi Dima On 28/11/2022 10:55, Dima Kogan wrote: Hi. I've been manually checking the merge requests, and have been accepting most of them. There is one thing the janitor does that I don't agree with, and I'd be against any automated merging of those patches. This is adding Build-Depends: debhelper-compat (=WHATEVER). Such dependencies break building of the package on anything other than sid, and are thus unhelpful. If you can stop the janitor from making this change, that'd probably be good. Can you expand on this a bit? There are plenty of packages with B-D on debhelper-compat (= 13) that are backported to the current stable and oldstable releases without any changes. I'm not sure how using debhelper-compat (= X) is any worse than debhelper (> X) + debian/compat=X — in terms of backporting, they all require that the relevant version of debhelper is in the release that you're targetting. The value of the compat level can certainly make a difference to backporting, since you need that version of debhelper in the release or in backports. But with debhelper 12 in oldoldstable-backports and debhelper 13 in oldstable-backports and stable/stable-backports, that's not really a restriction, is it? (likewise in supported ubuntu releases) cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: MRs on salsa and letting janitor automate things
On Sun, Nov 27, 2022 at 03:55:05PM -0800, Dima Kogan wrote: > Hi. I've been manually checking the merge requests, and have been > accepting most of them. There is one thing the janitor does that I don't > agree with, and I'd be against any automated merging of those patches. > This is adding Build-Depends: debhelper-compat (=WHATEVER). Such > dependencies break building of the package on anything other than sid, > and are thus unhelpful. If you can stop the janitor from making this > change, that'd probably be good. > That sounds reasonable. I am adding in Jelmer to the thread, so they could help tweak it for debian-science@ commits/MRs -- Best, Nilesh signature.asc Description: PGP signature
Re: MRs on salsa and letting janitor automate things
Hi. I've been manually checking the merge requests, and have been accepting most of them. There is one thing the janitor does that I don't agree with, and I'd be against any automated merging of those patches. This is adding Build-Depends: debhelper-compat (=WHATEVER). Such dependencies break building of the package on anything other than sid, and are thus unhelpful. If you can stop the janitor from making this change, that'd probably be good.
Re: MRs on salsa and letting janitor automate things
Hi David On 27/11/2022 23:29, David Bremner wrote: Personally I often find it hard to prioritize understanding the MRs from the janitor, and I'm not comfortable with having a bot commit to a repo that I am responsible for. Perhaps I'm just old fashioned. I'm an uploader only for a tiny fraction of the team's packages, so my views should not block anything. A few years ago when Janitor was new, I felt the same uneasiness about letting it commit things. I've since changed my view for a few reasons: * Nothing gets uploaded without human eyes looking at it anyway * It's git, so you can you just revert anything that is a problem, should that actually be the case in reality (and having processed many hundreds of Janitor merges, I am yet to see any that were); and the issues I speculated about at first with this have turned out to be imagined rather than real * Janitor's ability to edit files without reformatting them has improved and so its changes are small, targeted, and easily readable * its commits are small and simple — the vast majority of the commits I just merged from Janitor were (a) fixing whitespace errors, (b) removing obsolete and unneeded version constraints, (c) adding simple multi-arch headers. These are all nice to have, safe, and simple. * Janitor has been a member of some big Debian teams for a couple of years and has been successful in those teams — Janitor has been committing directly to git repos in both the Perl and Python teams for around two years. > I guess I can always pull a few packages from > the team space on Salsa. That is quite contrary to what both Janitor and I are hoping to do here. The point is to enhance the team and to remove the boring work. Given Janitor has been committing directly to Perl repos that you are responsible for already, perhaps this isn't as much of a change as feared? cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: MRs on salsa and letting janitor automate things
On 27/11/2022 19:30, Julien Puydt wrote: Perhaps people didn't get notified they had MRs ? Entirely possible, hence the suggestions in my message were that we should: a) automate what can be automated so that attention is not needed b) check our individual salsa notification settings for repos we care about c) check the dd-list of outstanding MRs Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: MRs on salsa and letting janitor automate things
Stuart Prescott writes: > Hi folks > > tl;dr: there lots of untriaged MRs on salsa; let's permit Janitor to > automatically commit its updates > > > There are lots of MRs on salsa for science-team packages that are open. > Many of these have been open for months and many have no comments, > triage or feedback visible on salsa. Many of these have been made by > first time contributors who, by virtue of their MRs sitting > unacknowledged and unmerged for months, think we don't care. That's not > our intended message! Personally I often find it hard to prioritize understanding the MRs from the janitor, and I'm not comfortable with having a bot commit to a repo that I am responsible for. Perhaps I'm just old fashioned. I'm an uploader only for a tiny fraction of the team's packages, so my views should not block anything. I guess I can always pull a few packages from the team space on Salsa. d
Re: MRs on salsa and letting janitor automate things
Hello, I have the same concern than Anton. if it is easy to black list a bunch of package, it would be great. Most of my packages could benefit from this automatic commit, I am also ok with automatic upgrade of my packages if it works :)) Everything that let me use my time on real packaging failures would be great. Cheers Fred
Re: MRs on salsa and letting janitor automate things
Hello Stuart, thanks for the information! I am personally OK with the idea of committing directly to the Science packages, not sure about the opinions of other team members. But if it improves the overall package quality - I am totally for this. Otherwise, I did not find an opportunity to blacklist some packages for the janitor, not being touched by this tool. There are some difficult ones, so I would prefer to have this option. Do you know, whether it is possible? Thanks! Anton Am So., 27. Nov. 2022 um 06:02 Uhr schrieb Stuart Prescott : > > Hi folks > > tl;dr: there lots of untriaged MRs on salsa; let's permit Janitor to > automatically commit its updates > > > There are lots of MRs on salsa for science-team packages that are open. > Many of these have been open for months and many have no comments, > triage or feedback visible on salsa. Many of these have been made by > first time contributors who, by virtue of their MRs sitting > unacknowledged and unmerged for months, think we don't care. That's not > our intended message! > > Attached are: > > * a list of MRs that are currently open on salsa (sorted by package) > > * associated dd-list of maintainers/uploaders for these packages > > If you don't currently get notified about MRs being opened for packages > you are interested in, I encourage you to tweak your salsa notification > preferences. My approach to this is to "star" packages for which I am > maintainer, uploader, or otherwise interested enough in that I'd like to > see notifications for MRs. > > > In amongst the human-generated MRs, there was also a huge number of > automated MRs from the Janitor bot. Over the last couple of days I've > been through Janitor's MRs (about 200 of them). These are all really > simple changes, each of which I checked and almost all of them I have > merged. > > For those not familiar with Janitor, it looks for easy to fix issues in > the packaging that are flagged by lintian (or other similar tools) and > fixes them. Unlike lintian, it has internet access and knowledge of the > Debian archive, so it can do extra things like update upstream homepages > or remove obsolete version constraints on packages. Janitor's fixes > range from pedantic to very useful; even the more pedantic ones steadily > improve the signal:noise of lintian and so lintian becomes more useful > on those packages. > > https://janitor.debian.net/ > > I propose that we let Janitor make these commits directly rather than > opening MRs; quite a few other teams in Debian have done this and it is > working well. Janitor has proven itself to be reliable and useful. Since > we've now been able to see that Janitor's changes are OK for a few > years, we can safely cut out the manual work and just let the bot get on > with its work. Comments? > > regards > Stuart > > -- > Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net > Debian Developer http://www.debian.org/ stu...@debian.org > GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: MRs on salsa and letting janitor automate things
Hi, Le dim. 27 nov. 2022, 06:02, Stuart Prescott a écrit : > > tl;dr: there lots of untriaged MRs on salsa; let's permit Janitor to > automatically commit its updates Perhaps people didn't get notified they had MRs ? I know for a fact I found out and reacted about a MR months after the fact - I only saw it because I connected to salsa to create a new repository! Cheers, J.Puydt
MRs on salsa and letting janitor automate things
Hi folks tl;dr: there lots of untriaged MRs on salsa; let's permit Janitor to automatically commit its updates There are lots of MRs on salsa for science-team packages that are open. Many of these have been open for months and many have no comments, triage or feedback visible on salsa. Many of these have been made by first time contributors who, by virtue of their MRs sitting unacknowledged and unmerged for months, think we don't care. That's not our intended message! Attached are: * a list of MRs that are currently open on salsa (sorted by package) * associated dd-list of maintainers/uploaders for these packages If you don't currently get notified about MRs being opened for packages you are interested in, I encourage you to tweak your salsa notification preferences. My approach to this is to "star" packages for which I am maintainer, uploader, or otherwise interested enough in that I'd like to see notifications for MRs. In amongst the human-generated MRs, there was also a huge number of automated MRs from the Janitor bot. Over the last couple of days I've been through Janitor's MRs (about 200 of them). These are all really simple changes, each of which I checked and almost all of them I have merged. For those not familiar with Janitor, it looks for easy to fix issues in the packaging that are flagged by lintian (or other similar tools) and fixes them. Unlike lintian, it has internet access and knowledge of the Debian archive, so it can do extra things like update upstream homepages or remove obsolete version constraints on packages. Janitor's fixes range from pedantic to very useful; even the more pedantic ones steadily improve the signal:noise of lintian and so lintian becomes more useful on those packages. https://janitor.debian.net/ I propose that we let Janitor make these commits directly rather than opening MRs; quite a few other teams in Debian have done this and it is working well. Janitor has proven itself to be reliable and useful. Since we've now been able to see that Janitor's changes are OK for a few years, we can safely cut out the manual work and just let the bot get on with its work. Comments? regards Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7Alastair McKinstry cylc libdap paraview (U) qd (U) Andreas Tille python-jsondiff (U) virtuoso-opensource (U) Ansgar dune-pdelab (U) Anton Gladky freeimage (U) libqglviewer (U) solvespace (U) vtk9 (U) Balint Reczey irstlm (U) Debian QA Group bcolz Debian Science Maintainers armadillo bornagain calculix-ccx-doc dune-pdelab freeimage hepmc3 irstlm libqglviewer python-jsondiff python-meshplex qd siconos solvespace tango virtuoso-opensource xtensor Debian Science Team gftl-shared paraview vtk9 Drew Parsons python-meshplex (U) xtensor (U) Gert Wollny vtk9 (U) Ghislain Antony Vaillant freeimage (U) Giulio Paci irstlm (U) HepMC developers hepmc3 (U) Koichi Akabe irstlm (U) Kumar Appaiah armadillo (U) Mika Pflüger bornagain (U) Mo Zhou hepmc3 (U) Nico Schlömer vtk9 (U) Ole Streicher gftl-shared (U) Picca Frédéric-Emmanuel bornagain (U) tango (U) Sebastien Delafond bornagain (U) Stephen Sinclair siconos (U) whitequark solvespace (U) Will Daniels virtuoso-opensource (U) Wolfgang Fütterer calculix-ccx-doc (U) science-team/armadillo Id: 26203 Title: Install cmake package and pkgconfig files. Closes #954927 Author: lasall Status: cannot_be_merged_recheck Url: https://salsa.debian.org/science-team/armadillo/-/merge_requests/1 science-team/aweather Id: 8074 Title: fix libgps API change (Closes: #926534) Author: paelzer-guest Status: can_be_merged Url: https://salsa.debian.org/science-team/aweather/-/merge_requests/1 science-team/bcolz Id: 48290 Title: Import Debian changes 1.2.1+ds2-8 Author: byang Status: can_be_merged Url: https://salsa.debian.org/science-team/bcolz/-/merge_requests/3 Id: 48289 Title: Import Debian changes 1.2.1+ds2-7 Author: byang Status: can_be_merged Url: https://salsa.debian.org/science-team/bcolz/-/merge_requests/2 science-team/bibus Id: 5149 Title: Fix #707338 Author: jscott Status: can_be_merged Url: https://salsa.debian.org/science-team/bibus/-/merge_requests/1 science-team/bornagain Id: 48297 Title: Update watch file Author: mikapfl-guest Status: can_be_merged Url: https://salsa.debian.org/science-team/bornagain/-/merge_requests/1 science-team/calculix-ccx-doc Id: 43365 Title: pristine-tar data for calculix-ccx-doc_2.17.orig.tar.bz2 Author: linqigang Status: can_be_merged Url: https://salsa.debian.org/science-team/calculix-ccx-doc/-/merge_requests/4 Id: 43352 Title: Updates to debian folder
