What is the problem with ports PR reaction delays?

[Fernando Apesteguía]

On Wed, Jan 29, 2014 at 10:27 AM, Kurt Jaeger <lists at opsec.eu> wrote:

> Hi!
>
> > Unfortunately, nothing is happening. I expected to hear some voices about
> > certain ideas that have popped up, like:
> >
> > * can we cut off old and 'unloved' PR's in order to reduce the amount of
> > work and make reassessment of that amount
>
> There is the other view of this which says "PRs do not eat hay, closing
> them does not really fix anything". I think this one is still open
> for debate.
>
> > * can we use people who volunteered to work on the PR's
>
> There are people submitting PRs, and those committing changes,
> and in between them those people that check/confirm PRs.
>
> They could do that before and they can still do it now, if they want to.
>
> So besides *doing* this there is not much "push" that can help here.
>
> > * can we incorporate automation in the PR workflow, for example, the one
> > provided by redports
>
> I've read through the thread and would like to hear more about
> this. Can anybody with knowledge about it please remind us of the
> details to this idea ?
>

redports is a great service to check ports. I use it after testing my
changes in local (with port test and such). Then I upload the changes to
redports and wait for it to compile in multiple groups (different archs and
releases). Once it's compiled succesfully I add the proper log to my PR
submission. This way the commiter (or whoever is looking at it) would save
_a lot of time_ instead of trying to compile again the port just to see if
it is fine. He/She could even try it again in his/her redports account!

I think sending the redports log along with the PR should be kind of
mandatory. And, although I don't know the infrastructure details, it should
be possible to send the redports commit reference, and retrieve the patch
automatically. That would save time.

But again, this is about tooling. Since nobody collected any data (I tried,
but I can't filter GNATS by date for example) we don't what the problem is.


>
> > * can we introduce new levels of access, the commiters that are commiting
> > on the ports they're maintaining
>
> I would welcome this, and by doing this, I would learn more about
> the committing process and would probably apply this to other
> ports in the future.
>
> There is another option, which needs to be debated:
>
> Start regular money collection which pays for some full-time staff
> that does commits etc.
>
> The downside might be that the volunteers see themselves less valued
> and become less involved in committing/reviewing etc, because
> "someone else ist paid for it and I'm not". This might be
> a serious issue, so how could we solve this motivational effect ?
>
> --
> pi at opsec.eu            +49 171 3101372                         6 years to
> go !
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
>