What is the problem with ports PR reaction delays?

Bernhard Fröhlich decke at bluelife.at
Sat Jan 25 13:43:14 UTC 2014

Am 25.01.2014 13:35 schrieb "Big Lebowski" <spankthespam at gmail.com>:
> On Sat, Jan 25, 2014 at 1:13 PM, Bernhard Fröhlich <decke at bluelife.at>
>> Am 25.01.2014 02:12 schrieb "Aryeh Friedman" <aryeh.friedman at gmail.com>:
>> >
>> > >
>> > > I think you've got me wrong - I am following freebsd-virtualization
>> > > very closely, and the matter I've touched here is not my doubt on
>> > > technology I should use, but rather a complaint on the state of jails
>> > > related tools directly leading to the delays in handling of ports
>> > > PR's. I know the technology alternatives, I am decided to jails for a
>> > > reason, and I also know your work on the web interface focusing on
>> > > but its not about it.
>> > >
>> >
>> > My point is writing scripts for VM's is easier (nothing more then copy
>> > master and then do a normal make install/portmaster on the port of you
>> > choice [better to run them one at a time I have found).  When I get
>> > port testing I usually have 3 VM's on the host working on compiling
and 1
>> > for development.   I have yet to find a good way to have 4 jails
running as
>> > independentlu.
>> This thread has taken a different direction at some point so I want to
throw in another view.
>> We already have all that build testing stuff around for various FreeBSD
versions with enough hardware resources and production ready and free for
all. It's called redports.org and I have even already created scripts that
monitor the gnats database for ports PRs with patches, fetch them, apply
them to the redports repository and schedule jobs for it.
>> So it is all there and the reason why it isn't running already are
political ones because I also proposed to automatically send followup mails
to the PR with the buildlog status.
>> http://code.google.com/p/redports/source/browse/#svn%2Ftrunk%2Fscripts
> That sounds great! It would be awesome to introduce both solutions
(automated testing and screening roles with new volunteers - we already
have two of those) to improve the process.

With the scripts it should be possible to fetch the patch of a PR, apply
and commit it to your redports repository and do additional changes until
you are okay with it. What is still missing is a script that helps
committing the changes to the FreeBSD tree but it's really not that
complicated to write that.

> However, I hate when I hear 'politics' in open source projects. Could you
be more specific and name the problem, if you mentioned it?

The raised concerns were that automatic build testing might result in less
testing on committer side. I agree that this might happen and automatic
build testing is only one part of what committers need to do. A huge
backlog and no response for months is definitely nothing we want.

More information about the freebsd-ports mailing list