What is the problem with ports PR reaction delays?

[Aryeh Friedman]

On Sat, Jan 25, 2014 at 9:04 PM, Alfred Perlstein <alfred at freebsd.org>wrote:

> On 1/25/14 3:48 PM, Aryeh Friedman wrote:
>
>> 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
>>
>
> You just don't get it.
>
> Again, you just really, really, don't get it.
>
> You WANT a gateway to a remote service that the project does not have to
> handle.
>

I am sorry your the one who does not get it.. not everything is either
testable remotely or should be... how do you propose to test device drivers
for example?


> Why?  Because then we offload the problem to another org.
>

With a hybrid cloud with most of the work being done on the
commiters/developers machine where is the overhead?


>
> The FreeBSD project should be about innovation in OS design, platform and
> software.  Ops work is bunk and just slows us down.
>

Sorry to tell you but the ability to handle a complex automated system is
one of the key things a OS must do... what better test then to build it
self?


>
> The more we can outsource the better we'll be.  (and what if that service
> blows up?  well we move on!  it's simple!)
>

What a total cop out if the service blows up fix it... or should we end up
with some of the real atrocities of linux like I/O times that are
impossible (claiming it takes less then a second to copy 10GB for
example)... note the above timing issue it makes resource scheduling next
to impossible in a distributed environment if you get different timings for
the same operation... bottom line writing and maintain a OS *IS* about
operations and nothing else.


> Continuing to insist that we run the services ourselves it just wasting
> our limited resources.  Not only that but we get emotionally attached to
> technologies that are old, dying and dead when off the shelf stuff works
> just fine.
>

I never said our selves it is outsourced to the developer/maintainer with
100% automated stuff... once I am doing with the next small version of
petitecloud I will post the 6 line script we use to test the port
(including cranking up a few vm's)... have fun doing that anywhere else

>
> -Alfred
>



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