What is the problem with ports PR reaction delays?

Bernhard Fröhlich decke at FreeBSD.org
Wed Jan 29 16:27:12 UTC 2014


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.

> 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

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


More information about the freebsd-ports mailing list