Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 671626 - Add a hook rejecting commits made using 'repoman commit --force'
Summary: Add a hook rejecting commits made using 'repoman commit --force'
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Infrastructure
Classification: Unclassified
Component: Git (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Gentoo Infrastructure
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-21 11:44 UTC by Michał Górny
Modified: 2022-07-12 03:18 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-11-21 11:44:52 UTC
It seems that we have quite a few developers who notoriously use 'repoman commit --force'.  In the last 30 days, there were 18 commits made using it:

$ git log --grep=RepoMan.*--force --since='20 Oct' | grep ^commit | wc -l
18

All of the uses I've looked at could be replaced by more appropriate 'repoman commit --straight-to-stable'.  Therefore, I'd like to suggest adding a git hook that rejects commits which indicate the use of 'repoman commit --force', and suggests the developers to use --straight-to-stable instead.

@QA, your opinions?
Comment 1 Ulrich Müller gentoo-dev 2018-11-21 12:49:56 UTC
There are valid use cases for --force, e.g. if repoman is reporting a false positive. I remember that I've had that case at least once in the past.

Also, have the 18 commits that you mention caused any QA violations?
Comment 2 Thomas Deutschmann (RETIRED) gentoo-dev 2018-11-21 13:00:58 UTC
Don't do that:

1) People will stop using repoman at all. So next thing you will ask for is rejecting commits without repoman which will result in much lower acceptance of the whole QA/CI stuff we already have. Better ask why people are using "--force" and try solve this problem.

2) Don't judge just based on numbers like your query revealed. Such an action is only appropriate if these commits have introduced new problems which would have been prevented if repoman would have been used.

Let me comment on my commits:

First of all, I knew there was an option called "--straight-to-stable" but I didn't know how it works. My fault that I only read man page and gave up and never tried to use the option myself yet (for some reason I thought that it will act like "ekeyword" and based on my "ekeyword all" experience which will ignore exp. architectures for example, I thought it was easier for me to prepare the ebuild the way I want it to be and just commit...).

Of course I manually run repoman without "--force" before to check for QA issues because I know that "--force" will bypass entire QA...

I now tested "--straight-to-stable" and it looks like it will only ignore architectures marked as stable but don't change keywords. So for most commits I could have used "--straight-to-stable" (and will in future).

But like said, the lack of knowledge as in my case is no reason to implement a hook and to reject these commits in general until there is a real abuse of that command resulting in real problems which we wouldn't see if people would have used repoman checks.
Comment 3 Alec Warner (RETIRED) archtester gentoo-dev Security 2018-11-21 13:41:49 UTC
(In reply to Michał Górny from comment #0)
> It seems that we have quite a few developers who notoriously use 'repoman
> commit --force'.  In the last 30 days, there were 18 commits made using it:
> 
> $ git log --grep=RepoMan.*--force --since='20 Oct' | grep ^commit | wc -l
> 18
> 
> All of the uses I've looked at could be replaced by more appropriate
> 'repoman commit --straight-to-stable'.  Therefore, I'd like to suggest
> adding a git hook that rejects commits which indicate the use of 'repoman
> commit --force', and suggests the developers to use --straight-to-stable
> instead.
> 
> @QA, your opinions?

I think the premise here (as ulm points out in #1) that repoman would perfectly report problems and I think we can safely say this is not true. I've seen systems set up in the past where such a hook is implemented and there is a bypass (e.g. setting FORCE_REASON="http://bugs.gentoo.org/12345 repoman is buggy" in the commit description) but the implication is that there is someone reading the FORCE_REASONs and fixing the repoman bugs; the number of commits with FORCE_REASON set should be pretty low.

In Gentoo, Repoman ownership has always been pretty vague (who owns it, QA? Portage Team?) and its release schedule imposes challenges on using it for blocking commits in this way.
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-11-21 14:30:48 UTC
Yes, I guess it's inevitable that in the Gentoo kindergarten people will just workaround the check instead of reporting bugs and trying to fix the underlying problem.  I suppose eventually this will require not only making repoman obligatory but also introducing some non-obvious hash in the commit tags generated by repoman that would make working around the check require some real effort.
Comment 5 Mikle Kolyada (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2018-11-21 14:53:17 UTC
Do not restrict its usage, I remember I myself used  --force like twice, We can introduce some double-check variable to be sure people understand what they are going to do (like 'I_KNOW_WHAT_I_AM_DOING' thing).
Comment 6 Ulrich Müller gentoo-dev 2018-11-21 16:25:22 UTC
(In reply to Michał Górny from comment #4)
> Yes, I guess it's inevitable that in the Gentoo kindergarten people will
> just workaround the check instead of reporting bugs and trying to fix the
> underlying problem.

This is not necessarily a contradiction. Even if the repoman bug is reported (which it should), the timescale to have it fixed will usually be too long to wait for it. That's where a workaround like --force is useful.
Comment 7 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-07-12 03:18:42 UTC
repoman support has been removed per bug 835013.

Please file a new bug (or, I suppose, reopen this one) if you feel this check is still applicable to pkgcheck and doesn't already exist.