| 1 |
On Tue, 01 Oct 2013 00:23:16 +0800 |
| 2 |
Patrick Lauer <patrick@g.o> wrote: |
| 3 |
|
| 4 |
> On 09/30/2013 07:45 PM, Chí-Thanh Christopher Nguyễn wrote: |
| 5 |
> > due to technical issues with the robo-stable scripts. |
| 6 |
> |
| 7 |
> > due to technical issues with the robo-stable scripts. |
| 8 |
> |
| 9 |
> let me summarize my response as "WAT" |
| 10 |
|
| 11 |
I call, and raise you a "THIS". |
| 12 |
|
| 13 |
> Maybe we should just have a cronjob that just does all that |
| 14 |
> automatically? |
| 15 |
|
| 16 |
Having been doing stabilisation for nearly eight years, I have often |
| 17 |
*thought* about ways to automate architecture testing/stabilisation. |
| 18 |
|
| 19 |
I have invested in tools and scripts that help me run certain steps |
| 20 |
along the way. I have never invested time or effort in automating |
| 21 |
the process entirely, because it will cause failures. |
| 22 |
|
| 23 |
Actually looking at stabilisation targets (the relevance USE flags, code |
| 24 |
in the actual ebuilds, DEPENDs), assessing the targets' importance (for |
| 25 |
instance, in checking what RDEPENDs on them), and testing accordingly, |
| 26 |
is the only way to ensure that a stabilisation request is sane and |
| 27 |
doable, and only then can you execute it. |
| 28 |
|
| 29 |
Since we have had automated stabilisation requests filed, it has |
| 30 |
become even more important to not automate stabilisation itself. |
| 31 |
|
| 32 |
Not automating the entire process involves more manual steps, and most |
| 33 |
of the time it isn't very rewarding, but it does get the job done of |
| 34 |
catching out nearly all of the superficial bugs (like, does this |
| 35 |
library actually work with stable RDEPENDs). |
| 36 |
|
| 37 |
|
| 38 |
jer |
Archives