On 22/04/2021 14:39, Agostino Sarubbo wrote:
On giovedì 22 aprile 2021 12:02:20 CEST Michał Górny wrote:
Well, I suppose scanning the dev branch would be preferable over
the master branch. In reality, they are usually only a few hours apart
but it might be useful to know of new breakage in dev before it's merged
to master.
It would be ideal if you could do a switch when master and dev are
in sync, and just copy the state from master.
Hi,
I think that your approach could be generally valid but for this use case I'm
against because of the following:
1) The approach is valid in cases like our github PRs and the bot that
approves the commit. In this case, who moves the commit between branches does
not know if the scan has been done or not.
2) I don't see the reason to scan against something that we don't know if will
be the same in master branch
3) We are not doing a similar approach for ::gentoo so I don't see why do this
for GURU since, after all, it is an overlay
4) Packages in master are supposed to be tested at least from 2 different
people (who made the commit in dev and who moves the commit to master) so it
means less bugspam
Well, not quite, packages in master have been manually/visually checked
for obvious (QA) mistakes and have been automatically checked by
repoman/pkgcheck. In principle the role of the Trusted Contributor is
first of all to ensure that no malicious commits make it into the master
branch, as described on the wiki[1]. In practice this means that we also
do basic QA checks and look at the repoman/pkgcheck results, since we
are looking at the commit anyway. We do not actually run emerge on the
ebuild, back in the early days I used to do that, but the amount of
commits has grown enormously and it is no longer practically possible to
do this (and here is where the tinderbox comes in handy).
Furthermore, as per [1] we are not supposed to postpone a merge just
because a commit has QA issues, fails to build or whatever. The only
situation in which we do not merge a commit, is if it is malicious. QA
issues or obvious mistakes are reported back to the author, or fixed
immediately, but they do not disqualify a commit for merging to the
master branch.
On the matter of running the tinderbox on the master branch or the dev
branch, I am undecided. It makes sense to do the checks as soon as
possible and to fix things before they reach the master branch. On the
other hand there are sometimes very big issues (missing dependencies and
such) and I am not sure how the tinderbox will behave in these cases.
Filing bugs for things which the Trusted Contributors can see in
repoman/pkgcheck (such as missing dependencies) is a waste of cpu power,
and only serves to increase the number of emails, so if the tinderbox
would also file reports for these issues I would advise to run the
tinderbox only on the master branch. (Then there is also the matter to
consider that in theory the dev branch could contain malicious code,
whereas the master branch is guaranteed to be free of this. So if the
tinderbox runs on the dev branch, then in theory a hypothetical
malicious commit might break the tinderbox.)
Tl;dr Commits are checked, not actually tested.
[1]
https://wiki.gentoo.org/wiki/Project:GURU/Information_for_Trusted_Contributor
One more thing: might be a good idea to consider splitting some
of the 'big' trackers (like CFLAGS) between Gentoo and GURU. I think
solving these bugs in GURU has lower priority than in Gentoo.
I think that trackers like CFLAGS/LDFLAGS are here to track how many packages
have the problem. I don't see it like (for example) the gcc-porting tracker
that gives the idea about how much packages need a fix and how much packages
need to be last-rited
Agostino
