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 > 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
