What is the problem with ports PR reaction delays?

[Fernando Apesteguía]

On Wed, Jan 29, 2014 at 5:27 PM, Bernhard Fröhlich <decke at freebsd.org>wrote:

> On Wed, Jan 29, 2014 at 11:12 AM, Fernando Apesteguía
> <fernando.apesteguia at gmail.com> wrote:
> > 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 ?
>
> The idea is pretty simple. redports.org is able to build various
> "patches" on
> top of the FreeBSD portstree already. So all that is missing is just a
> small
> script that runs periodically and fetches the patches from GNATS and
> commits them to the redports repository to trigger automated builds. The
> resulting buildlogs can be send to the GNATS database as a followup to
> nform the submitter about failures. Well the code for that has been written
> in large parts a year ago already. So all it needs is a consensus that this
> is a good thing and some cleanup to get it ready for automatic operation.
>

That's good to hear.


>
> > 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.
>
> Yeah I am working on some scripts that help with that and also allow to
> work
> more efficient with port PRs. Right now all people I know have written
> their own
> set of scripts to kind of optimize their workflow but most of them are
> quite
> simple and don't work for more than one person.
>
> With redports.org being the central place where more people work in a
> similar
> fashion I think it makes sense to write some tools that help with the
> usual tasks.
>
> The result is rptools which is still quite rough so don't use it yet
> please unless
> you want to help developing it:
>
> https://redports.org/browser/decke/ports-mgmt/rptools
> https://github.com/decke/rptools
>
>
Thanks, I'll have a look at it.

On the other side of the story, can you confirm if the rate of new ports
(or updates to existent ports) has increased? Or is the rate of commited
patches decreased? Do we _actually_ know what the problem is?



> --
> Bernhard Froehlich
> http://www.bluelife.at/
>