CI system for PR builds

[Rainer Müller]

On 2018-04-11 16:43, Joshua Root wrote:
> On 2018-4-12 00:37 , Mojca Miklavec wrote:
>> We could move them to something like "changesneeded" (not sure where
>> exactly; they could get a special status, even if closed, but it
>> should be easy enough to find them should anyone have motivation to
>> fix the remaining issues). Just because none of us took the time to
>> review the changes for long enough that all dependency and the
>> software itself became completely outdated in the meantime, doesn't
>> mean that we should make the submissions non-discoverable and give the
>> signal to users that first of all we don't care for 5 years, and when
>> we start caring, we boldly close all the tickets.
>>
>> Very often I see tickets getting status "upstream", "infoneeded" etc.
>> which basically means that developers would ignore such tickets until
>> something happens. Or perhaps "helpneeded" which means that they are
>> genuinely interested in fixing the issue, but have no resources to fix
>> it. We need something similar.
> 
> New ticket resolutions are something we can do.

Those are applied when closing the ticket, which kind of buries the
ticket as it will no longer be returned in queries. That does not seem
appropriate when the underlying issue was in fact not yet resolved,
because you would then miss this ticket when searching for an issue.

However, we could have a new resolution to indicate that it was closed
because there was no response from the submitter, because none of the
existing options seems to fit. Would a resolution of "timeout" likely be
confused with the "maintainer timeout"?

By the way, the Trac ticket workflow can be customized a lot. At the
moment, we are using the default Trac ticket workflow [1]. For example,
it would be possible to have a state like "changesneeded" and the
reporter could be allowed to change the state back to "new".

Rainer

[1] https://trac.edgewall.org/wiki/TracWorkflow#TheDefaultTicketWorkflow