| 1 |
On 25/11/16 18:51, Kent Fredric wrote: |
| 2 |
> On Fri, 25 Nov 2016 14:40:36 +0800 |
| 3 |
> Jason Zaman <perfinion@g.o> wrote: |
| 4 |
> |
| 5 |
>> One way would be to use a plain text attachment with a standardized |
| 6 |
>> filename. If there are updates to the list then the new should obsolete |
| 7 |
>> the old and the script can pull non-obsoleted ones. |
| 8 |
>> The problem then is how do you search for them properly? put them all |
| 9 |
>> in the title anyway? then its duplicated. |
| 10 |
>> |
| 11 |
>> When i do big lists of packages the title is eg "XFCE Stabilization for |
| 12 |
>> Nov 2016" which is not duplicated and okay. |
| 13 |
>> For single packages the title is just "cat/pkg-1.2.3 stablereq" so then |
| 14 |
>> we duplicate anyway? |
| 15 |
> |
| 16 |
> If you standardized the format / filename, you could have some process |
| 17 |
> that monitors bugzilla and indexes its contents and computes overlaps, |
| 18 |
> and provides per-arch aggregates grouped by bugs. |
| 19 |
> |
| 20 |
> Then the "tester" would get it in the format: |
| 21 |
> |
| 22 |
> =cat/pn-VERSION #4145 #678345 |
| 23 |
> =cat/pn-VERSION #4145 |
| 24 |
> =cat/pn-VERSION #678345 |
| 25 |
> |
| 26 |
> Having it in a standardized form would also potentially make it repoman-checkable |
| 27 |
> via automation: |
| 28 |
> |
| 29 |
> Just like our current QA bots do, a QA Bot could fetch the keywording/stabilization |
| 30 |
> "recipie" and locally apply the requisite changes, and then do a basic repoman sanity |
| 31 |
> check to ensure coherence. |
| 32 |
|
| 33 |
I'm not sure what you mean. A standardised format and a bot to repoman |
| 34 |
check lists in this format is part of my original post. |
| 35 |
|
| 36 |
> But at this point we're dove tailing good ideas into a fundamentally limited system |
| 37 |
> where we probably should have some dedicated interface (and tools) to automate and |
| 38 |
> verify these things. |
| 39 |
|
| 40 |
A dedicated portal for handling this type of thing would of course be |
| 41 |
preferable, and work is ongoing on such a tool. However, completing and |
| 42 |
rolling out such a system could take a very long time. Improvements to |
| 43 |
the stabilisation process via Bugzilla can be rolled out in very little |
| 44 |
time. |
| 45 |
|
| 46 |
Let's not block incremental progress in favour of a perfect solution |
| 47 |
that doesn't exist yet. |
| 48 |
|
| 49 |
> |
| 50 |
> Automating the *tests* is a contentious idea to some extent, but I doubt we'd see opposition |
| 51 |
> for the idea of "throw repoman at it at least and make sure it doesnt' barf" |
| 52 |
|
| 53 |
That depends on how you define 'test'. This proposal (part 1) deals |
| 54 |
exclusively with repoman, primarily to make sure that we don't waste |
| 55 |
time working on requests where the maintained failed to include all |
| 56 |
required atoms. |
| 57 |
|
| 58 |
A future proposal will certainly involve fully-automated build testing |
| 59 |
of all requests, allowing effort to be better focused on runtime |
| 60 |
testing. I'm unsure how that could be controversial. |
Archives