| 1 |
On Thu, Apr 22, 2021 at 8:39 AM Agostino Sarubbo <ago@g.o> wrote: |
| 2 |
> |
| 3 |
> On giovedì 22 aprile 2021 12:02:20 CEST Michał Górny wrote: |
| 4 |
> > Well, I suppose scanning the dev branch would be preferable over |
| 5 |
> > the master branch. In reality, they are usually only a few hours apart |
| 6 |
> > but it might be useful to know of new breakage in dev before it's merged |
| 7 |
> > to master. |
| 8 |
> > |
| 9 |
> > It would be ideal if you could do a switch when master and dev are |
| 10 |
> > in sync, and just copy the state from master. |
| 11 |
> |
| 12 |
> Hi, |
| 13 |
> |
| 14 |
> I think that your approach could be generally valid but for this use case I'm |
| 15 |
> against because of the following: |
| 16 |
> |
| 17 |
> 1) The approach is valid in cases like our github PRs and the bot that |
| 18 |
> approves the commit. In this case, who moves the commit between branches does |
| 19 |
> not know if the scan has been done or not. |
| 20 |
> |
| 21 |
> 2) I don't see the reason to scan against something that we don't know if will |
| 22 |
> be the same in master branch |
| 23 |
> |
| 24 |
> 3) We are not doing a similar approach for ::gentoo so I don't see why do this |
| 25 |
> for GURU since, after all, it is an overlay |
| 26 |
> |
| 27 |
> 4) Packages in master are supposed to be tested at least from 2 different |
| 28 |
> people (who made the commit in dev and who moves the commit to master) so it |
| 29 |
> means less bugspam |
| 30 |
> |
| 31 |
|
| 32 |
Perhaps another approach could be to add a third branch, "staging". |
| 33 |
Any reviewers could move the appropriate ebuilds to "staging" once all |
| 34 |
the reviews and discussions are done but before moving to "master" |
| 35 |
|
| 36 |
In fact, probably a github action could be set up to automatically |
| 37 |
move to "master" after the CI stuff passes. |
Archives