One of the things that seems like it is and will be a pain point for
folks writing package-specific tasks is how to work through the times
when there was an issue in the task and things didn't run well. At the
moment, the only solution we have is to re-build the affected package
or to pester an adm
On Tue, Apr 18, 2017 at 2:35 PM, Tim Flink wrote:
> One of the things that seems like it is and will be a pain point for
> folks writing package-specific tasks is how to work through the times
> when there was an issue in the task and things didn't run well. At the
> moment, the only solution we
On Tue, 18 Apr 2017 14:53:07 +0200
Kamil Paral wrote:
> On Tue, Apr 18, 2017 at 2:35 PM, Tim Flink wrote:
>
> > One of the things that seems like it is and will be a pain point for
> > folks writing package-specific tasks is how to work through the
> > times when there was an issue in the task
On Tue, 2017-04-18 at 06:35 -0600, Tim Flink wrote:
> One of the things that seems like it is and will be a pain point for
> folks writing package-specific tasks is how to work through the times
> when there was an issue in the task and things didn't run well. At the
> moment, the only solution we
On 04/18/2017 10:08 AM, Adam Williamson wrote:
> One thought: we actually have the same problem for openQA, now it's
> running tests on updates. This isn't very visible at present so devs
> haven't been asking about it, but I suspect as soon as the results show
> up in Bodhi, someone will be wanti
On Tue, 2017-04-18 at 10:18 -0600, Kevin Fenzi wrote:
> On 04/18/2017 10:08 AM, Adam Williamson wrote:
>
> > One thought: we actually have the same problem for openQA, now it's
> > running tests on updates. This isn't very visible at present so devs
> > haven't been asking about it, but I suspect