1 |
On giovedì 22 aprile 2021 12:02:20 CEST Michał Górny wrote: |
2 |
> Well, I suppose scanning the dev branch would be preferable over |
3 |
> the master branch. In reality, they are usually only a few hours apart |
4 |
> but it might be useful to know of new breakage in dev before it's merged |
5 |
> to master. |
6 |
> |
7 |
> It would be ideal if you could do a switch when master and dev are |
8 |
> in sync, and just copy the state from master. |
9 |
|
10 |
Hi, |
11 |
|
12 |
I think that your approach could be generally valid but for this use case I'm |
13 |
against because of the following: |
14 |
|
15 |
1) The approach is valid in cases like our github PRs and the bot that |
16 |
approves the commit. In this case, who moves the commit between branches does |
17 |
not know if the scan has been done or not. |
18 |
|
19 |
2) I don't see the reason to scan against something that we don't know if will |
20 |
be the same in master branch |
21 |
|
22 |
3) We are not doing a similar approach for ::gentoo so I don't see why do this |
23 |
for GURU since, after all, it is an overlay |
24 |
|
25 |
4) Packages in master are supposed to be tested at least from 2 different |
26 |
people (who made the commit in dev and who moves the commit to master) so it |
27 |
means less bugspam |
28 |
|
29 |
|
30 |
> One more thing: might be a good idea to consider splitting some |
31 |
> of the 'big' trackers (like CFLAGS) between Gentoo and GURU. I think |
32 |
> solving these bugs in GURU has lower priority than in Gentoo. |
33 |
|
34 |
I think that trackers like CFLAGS/LDFLAGS are here to track how many packages |
35 |
have the problem. I don't see it like (for example) the gcc-porting tracker |
36 |
that gives the idea about how much packages need a fix and how much packages |
37 |
need to be last-rited |
38 |
|
39 |
|
40 |
Agostino |