1 |
On Thu, 2021-04-22 at 14:39 +0200, Agostino Sarubbo wrote: |
2 |
> On giovedì 22 aprile 2021 12:02:20 CEST Michał Górny wrote: |
3 |
> > Well, I suppose scanning the dev branch would be preferable over |
4 |
> > the master branch. In reality, they are usually only a few hours apart |
5 |
> > but it might be useful to know of new breakage in dev before it's merged |
6 |
> > to master. |
7 |
> > |
8 |
> > It would be ideal if you could do a switch when master and dev are |
9 |
> > in sync, and just copy the state from master. |
10 |
> |
11 |
> Hi, |
12 |
> |
13 |
> I think that your approach could be generally valid but for this use case I'm |
14 |
> against because of the following: |
15 |
> |
16 |
> 1) The approach is valid in cases like our github PRs and the bot that |
17 |
> approves the commit. In this case, who moves the commit between branches does |
18 |
> not know if the scan has been done or not. |
19 |
> |
20 |
> 2) I don't see the reason to scan against something that we don't know if will |
21 |
> be the same in master branch |
22 |
> |
23 |
> 3) We are not doing a similar approach for ::gentoo so I don't see why do this |
24 |
> for GURU since, after all, it is an overlay |
25 |
> |
26 |
> 4) Packages in master are supposed to be tested at least from 2 different |
27 |
> people (who made the commit in dev and who moves the commit to master) so it |
28 |
> means less bugspam |
29 |
> |
30 |
|
31 |
This is not how GURU works. The dev->master merges are always fast- |
32 |
forward, and are only reviewed to prevent malicious actions. |
33 |
|
34 |
-- |
35 |
Best regards, |
36 |
Michał Górny |