What is the problem with ports PR reaction delays?

Aryeh Friedman aryeh.friedman at gmail.com
Sat Jan 25 23:48:40 UTC 2014

On Sat, Jan 25, 2014 at 6:41 PM, Yuri <yuri at rawbw.com> wrote:

> On 01/25/2014 14:44, Aryeh Friedman wrote:
>> The key seems to be that no one has time to do the stuff they really want
>> to do (get new ports into the system)... to that end automating everything
>> that can be automated is sure help free up comitter time so they can look
>> at what is interesting
> Yes. I just can't imagine any generic port tests that can't be automated
> and coded into the script once and for good.
> Ideal system should be like github with the added automated testing
> between pull request submission and merge. It should either fail and notify
> the submitter, or succeed and notify the committers.

Git hup (or *ANY* remote service for that matter) is a no go IMO

> Today all committers do for ports is running some generic tests by hand,
> like 'lint' with various flags. Install/uninstall/etc. No wonder this isn't
> very a rewarding activity, and committers probably perceive it as a
> necessary evil. The way how it is, it causes a waste of their time.

That's why I keep suggesting devel/aegis it does *EVERYTHING* git/git hub
does but all locally and has the added benefit that you can not change the
change set (aka port submission) until it has passed all 3 of the following
(you can turn all but the last two off at runtime and the first only needs
to build to pass at a min):

1. Develop change
   (To leave development it must build and pass *NEW* tests, this is where
the automation should go)

2. Review (this is where human eyes come in once all the automated tests
are passed)

3. Intergration make sure it plays well with others

Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org

More information about the freebsd-ports mailing list