CI system for PR builds

[Craig Treleaven]

> On Apr 11, 2018, at 10:37 AM, Mojca Miklavec <mojca at macports.org> wrote:
> 
> On 11 April 2018 at 16:18, Joshua Root wrote:
>> 
>> Certainly let's encourage contributors who have something to submit to
>> use PRs. But I don't know that simply moving existing tickets over to
>> PRs without the involvement of the original contributor will be useful.
> 
> In any case I don't think that just transfering the commit without:
> - making sure that lint passes
> - making sure that livecheck passes and reports no newer version
> - making sure that the port builds on at least one OS version and that
> it at least runs
> makes much sense. It doesn't have to be the original author who does that.
> 
>> Most of the open submission tickets have problems that need to be
>> addressed before they are committed.
> 
> In many cases there was just lack of feedback from committers, even if
> some issues were addressed.
> 
>> And yes, if a submission has been reviewed and changes have been
>> requested, and the contributor has not responded after a reasonable
>> amount of time, and nobody else has volunteered to fix it, the ticket
>> can be closed.
> 
> 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.

At the moment, only 18 of 403 open submission tickets are less than 12 months old.  A further 23 are between 12 months and 2 years old.  

In the past, I have browsed non-current submission tickets looking for any that I can handle (eg bibclen).  However, most of the open submission tickets I’ve looked at, I’m unable to help with.  Usually they involve a technology or build system  that I don’t know (Rust, Java, etc).  Other tickets are stuck for various reasons such as an inexplicable build failure, etc.

IOW, there is very little low-hanging fruit among the 400 open tickets.  

Mass converting to pull requests is likely to just clog the PR queue with, essentially, dead submissions.

Perhaps it is rude, but I think we should auto-close submission (and request) tickets that haven’t had any activity for a period (say 4-6 months, maybe less).  The close message should encourage the submitter to try reopen, if they wish, thus resetting the clock.  Perhaps there should be an automatic warning after a shorter period of inactivity that the next step will be to auto-close.  

How many submitters would actually wait for any length of time?  If you need or want a piece of sotware enough to create a submission ticket, why would you wait passively for months or years?  If a ticket isn’t acted on in, at most, a few months the submitter must have found another way to scratch their itch.  Or the itch wasn’t serious.

IMHO, YMMV, …

Craig